- 07 Jan, 2020 40 commits
-
-
Qian Cai authored
BugLink: https://bugs.launchpad.net/bugs/1858489 [ Upstream commit 0fbc9b8b ] This fixes a compilation warning in sysfs.c drivers/infiniband/hw/mlx4/sysfs.c:360:2: warning: 'strncpy' output may be truncated copying 8 bytes from a string of length 31 [-Wstringop-truncation] By eliminating the temporary stack buffer. Signed-off-by:
Qian Cai <cai@gmx.us> Reviewed-by:
Leon Romanovsky <leonro@mellanox.com> Signed-off-by:
Jason Gunthorpe <jgg@mellanox.com> Signed-off-by:
Sasha Levin <sashal@kernel.org> Signed-off-by:
Connor Kuehl <connor.kuehl@canonical.com> Signed-off-by:
Kleber Sacilotto de Souza <kleber.souza@canonical.com>
-
zhengbin authored
BugLink: https://bugs.launchpad.net/bugs/1858489 [ Upstream commit 255fbca6 ] As the man(2) page for utime/utimes states, EPERM is returned when the second parameter of utime or utimes is not NULL, the caller's effective UID does not match the owner of the file, and the caller is not privileged. However, in a NFS directory mounted from knfsd, it will return EACCES (from nfsd_setattr-> fh_verify->nfsd_permission). This patch fixes that. Signed-off-by:
zhengbin <zhengbin13@huawei.com> Signed-off-by:
J. Bruce Fields <bfields@redhat.com> Signed-off-by:
-
Aaro Koskinen authored
BugLink: https://bugs.launchpad.net/bugs/1858489 [ Upstream commit 1c6121c3 ] cn58xx is compatible with cn50xx, so use the latter. Signed-off-by:
Aaro Koskinen <aaro.koskinen@iki.fi> [paul.burton@mips.com: s/cn52xx/cn50xx/ in commit message.] Signed-off-by:
Paul Burton <paul.burton@mips.com> Cc: Ralf Baechle <ralf@linux-mips.org> Cc: James Hogan <jhogan@kernel.org> Cc: linux-mips@vger.kernel.org Signed-off-by:
-
Joel Stanley authored
BugLink: https://bugs.launchpad.net/bugs/1858489 [ Upstream commit b682c869 ] The add_ssaaaa, sub_ddmmss, umul_ppmm and udiv_qrnnd macros originate from GCC's longlong.h which in turn was copied from GMP's longlong.h a few decades ago. This was found when compiling with clang: arch/powerpc/math-emu/fnmsub.c:46:2: error: invalid use of a cast in a inline asm context requiring an l-value: remove the cast or build with -fheinous-gnu-extensions FP_ADD_D(R, T, B); ^~~~~~~~~~~~~~~~~ ... ./arch/powerpc/include/asm/sfp-machine.h:283:27: note: expanded from macro 'sub_ddmmss' : "=r" ((USItype)(sh)), \ ~~~~~~~~~~^~~ Segher points out: this was fixed in GCC over 16 years ago ( https://gcc.gnu.org/r56600 ), and in GMP (where it comes from) presumably before that. Update the add_ssaaaa, sub_ddmmss, umul_ppmm and udiv_qrnnd macros to the latest GCC version in order to git rid of the invalid casts. These were taken as-is from GCC's longlong in order to make future syncs obvious. Other parts of sfp-machine.h were left as-is as the file contains more features than present in longlong.h. Link: https://github.com/ClangBuiltLinux/linux/issues/260Signed-off-by:
Joel Stanley <joel@jms.id.au> Reviewed-by:
Nick Desaulniers <ndesaulniers@google.com> Reviewed-by:
Segher Boessenkool <segher@kernel.crashing.org> Signed-off-by:
Michael Ellerman <mpe@ellerman.id.au> Signed-off-by:
-
David Teigland authored
BugLink: https://bugs.launchpad.net/bugs/1858489 [ Upstream commit 3595c559 ] The warning added in commit 3b0e761b "dlm: print log message when cluster name is not set" did not account for the fact that lockspaces created from userland do not supply a cluster name, so bogus warnings are printed every time a userland lockspace is created. Signed-off-by:
David Teigland <teigland@redhat.com> Signed-off-by:
-
Daniel Mack authored
BugLink: https://bugs.launchpad.net/bugs/1858489 [ Upstream commit c40ad242 ] PXA25xx SoCs don't have a USB controller, so drop the node from the common pxa2xx.dtsi base file. Both pxa27x and pxa3xx have a dedicated node already anyway. While at it, unify the names for the nodes across all pxa platforms. Signed-off-by:
Daniel Mack <daniel@zonque.org> Reported-by:
Sergey Yanovich <ynvich@gmail.com> Link: https://patchwork.kernel.org/patch/8375421/Signed-off-by:
Robert Jarzmik <robert.jarzmik@free.fr> Signed-off-by:
-
Masahiro Yamada authored
BugLink: https://bugs.launchpad.net/bugs/1858489 [ Upstream commit e07db28e ] Building a single target in an external module fails due to missing .tmp_versions directory. For example, $ make -C /lib/modules/$(uname -r)/build M=$PWD foo.o will fail in the following way: CC [M] /home/masahiro/foo/foo.o /bin/sh: 1: cannot create /home/masahiro/foo/.tmp_versions/foo.mod: Directory nonexistent This is because $(cmd_crmodverdir) is executed only before building /, %/, %.ko single targets of external modules. Create .tmp_versions in the 'prepare' target. Signed-off-by:
Masahiro Yamada <yamada.masahiro@socionext.com> Signed-off-by:
-
Paul Walmsley authored
BugLink: https://bugs.launchpad.net/bugs/1858489 [ Upstream commit a4d26f1a ] During development of a serial console driver with a gcc 8.2.0 toolchain for RISC-V, the following modpost warning appeared: ---- WARNING: vmlinux.o(.data+0x19b10): Section mismatch in reference from the variable .LANCHOR1 to the function .init.text:sifive_serial_console_setup() The variable .LANCHOR1 references the function __init sifive_serial_console_setup() If the reference is valid then annotate the variable with __init* or __refdata (see linux/init.h) or name the variable: *_template, *_timer, *_sht, *_ops, *_probe, *_probe_one, *_console ---- ".LANCHOR1" is an ELF local symbol, automatically created by gcc's section anchor generation code: https://gcc.gnu.org/onlinedocs/gccint/Anchored-Addresses.html https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/varasm.c;h=cd9591a45617464946dcf9a126dde277d9de9804;hb=9fb89fa845c1b2e0a18d85ada0b077c84508ab78#l7473 This was verified by compiling the kernel with -fno-section-anchors and observing that the ".LANCHOR1" ELF local symbol disappeared, and modpost no longer warned about the section mismatch. The serial driver code idiom triggering the warning is standard Linux serial driver practice that has a specific whitelist inclusion in modpost.c. I'm neither a modpost nor an ELF expert, but naively, it doesn't seem useful for modpost to report section mismatch warnings caused by ELF local symbols by default. Local symbols have compiler-generated names, and thus bypass modpost's whitelisting algorithm, which relies on the presence of a non-autogenerated symbol name. This increases the likelihood that false positive warnings will be generated (as in the above case). Thus, disable section mismatch reporting on ELF local symbols. The rationale here is similar to that of commit 2e3a10a1 ("ARM: avoid ARM binutils leaking ELF local symbols") and of similar code already present in modpost.c: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/scripts/mod/modpost.c?h=v4.19-rc4&id=7876320f88802b22d4e2daf7eb027dd14175a0f8#n1256 This third version of the patch implements a suggestion from Masahiro Yamada <yamada.masahiro@socionext.com> to restructure the code as an additional pattern matching step inside secref_whitelist(), and further improves the patch description. Signed-off-by:
Paul Walmsley <paul.walmsley@sifive.com> Signed-off-by:
Paul Walmsley <paul@pwsan.com> Acked-by:
Sam Ravnborg <sam@ravnborg.org> Signed-off-by:
-
Yuchung Cheng authored
BugLink: https://bugs.launchpad.net/bugs/1858489 [ Upstream commit 3976535a ] Previously there is an off-by-one bug on determining when to abort a stalled window-probing socket. This patch fixes that so it is consistent with tcp_write_timeout(). Signed-off-by:
Yuchung Cheng <ycheng@google.com> Signed-off-by:
Eric Dumazet <edumazet@google.com> Signed-off-by:
Neal Cardwell <ncardwell@google.com> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
-
Lubomir Rintel authored
BugLink: https://bugs.launchpad.net/bugs/1858489 [ Upstream commit 40058398 ] gpio-pxa uses two cell to encode the interrupt source: the pin number and the trigger type. Adjust the device node accordingly. Signed-off-by:
Lubomir Rintel <lkundrak@v3.sk> Acked-by:
Pavel Machek <pavel@ucw.cz> Signed-off-by:
Olof Johansson <olof@lixom.net> Signed-off-by:
-
Martin Schiller authored
BugLink: https://bugs.launchpad.net/bugs/1858489 [ Upstream commit 06137619 ] o x25_find_listener(): the compare for the null_x25_address was wrong. We have to check the x25_addr of the listener socket instead of the x25_addr of the incomming call. o x25_bind(): it was not possible to bind a socket to null_x25_address Signed-off-by:
Martin Schiller <ms@dev.tdt.de> Signed-off-by:
-
Martin Schiller authored
BugLink: https://bugs.launchpad.net/bugs/1858489 [ Upstream commit d449ba3d ] The length of the called and calling address was not calculated correctly (BCD encoding). Signed-off-by:
-
Aaro Koskinen authored
BugLink: https://bugs.launchpad.net/bugs/1858489 [ Upstream commit 04a92358 ] Currently we get extra newlines on OMAP1/2 when the SoC name is printed: [ 0.000000] OMAP1510 [ 0.000000] revision 2 handled as 15xx id: bc058c9b93111a16 [ 0.000000] OMAP2420 [ 0.000000] Fix by using pr_cont. Signed-off-by:
Tony Lindgren <tony@atomide.com> Signed-off-by:
-
Scott Mayhew authored
BugLink: https://bugs.launchpad.net/bugs/1858489 [ Upstream commit b493fd31 ] __cld_pipe_upcall() emits a "do not call blocking ops when !TASK_RUNNING" warning due to the dput() call in rpc_queue_upcall(). Fix it by using a completion instead of hand coding the wait. Signed-off-by:
Scott Mayhew <smayhew@redhat.com> Signed-off-by:
-
Wen Yang authored
BugLink: https://bugs.launchpad.net/bugs/1858489 [ Upstream commit f31a8969 ] kmem_cache_destroy(NULL) is safe, so removes NULL check before freeing the mem. This patch also fix ifnullfree.cocci warnings. Signed-off-by:
Wen Yang <wen.yang99@zte.com.cn> Signed-off-by:
-
Lucas Stach authored
BugLink: https://bugs.launchpad.net/bugs/1858489 [ Upstream commit fece4978 ] Probe deferral is a normal operating condition in the probe function, so don't spam the log with an error in this case. Signed-off-by:
Lucas Stach <l.stach@pengutronix.de> Acked-by:
Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by:
Wolfram Sang <wsa@the-dreams.de> Signed-off-by:
-
Stefan Agner authored
BugLink: https://bugs.launchpad.net/bugs/1858489 [ Upstream commit 63fd4b94 ] The ipg clock only needs to be unprepared in case preparing per clock fails. The ipg clock has already disabled at the point. Fixes: 1cf93e0d ("serial: imx: remove the uart_console() check") Signed-off-by:
Stefan Agner <stefan@agner.ch> Reviewed-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
-
Colin Ian King authored
BugLink: https://bugs.launchpad.net/bugs/1858489 [ Upstream commit 9ccb6456 ] Currently the null check on key is occurring after the strcasecmp on the key, hence there is a potential null pointer dereference on key. Fix this by checking if key is null first. Also replace the == 0 check on strcasecmp with just the ! operator. Detected by CoverityScan, CID#1248787 ("Dereference before null check") Fixes: fa766c9b ("[media] Altera FPGA firmware download module") Signed-off-by:
Colin Ian King <colin.king@canonical.com> Signed-off-by:
-
Niklas Söderlund authored
BugLink: https://bugs.launchpad.net/bugs/1858489 [ Upstream commit c9d76d06 ] The function dma_set_max_seg_size() can return either 0 on success or -EIO on error. Change its return type from unsigned int to int to capture this. Signed-off-by:
Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se> Reviewed-by:
Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by:
Christoph Hellwig <hch@lst.de> Signed-off-by:
-
Alexey Dobriyan authored
BugLink: https://bugs.launchpad.net/bugs/1858489 [ Upstream commit f8c6d140 ] acpi_find_child_device() accepts boolean not pointer as last argument. Signed-off-by:
Alexey Dobriyan <adobriyan@gmail.com> [ rjw: Subject ] Signed-off-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by:
-
Vinod Koul authored
BugLink: https://bugs.launchpad.net/bugs/1858489 commit 35faaf0d upstream. Commit 627469e4 ("dmaengine: coh901318: Fix a double-lock bug") left flags variable unused, so remove it to fix the warning. drivers/dma/coh901318.c: In function 'coh901318_config': drivers/dma/coh901318.c:1805:16: warning: unused variable 'flags' [-Wunused-variable] unsigned long flags; ^~~~~ Fixes: 627469e4 ("dmaengine: coh901318: Fix a double-lock bug") Reported-By:
Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by:
Vinod Koul <vkoul@kernel.org> Signed-off-by:
-
Jia-Ju Bai authored
BugLink: https://bugs.launchpad.net/bugs/1858489 [ Upstream commit 627469e4 ] The function coh901318_alloc_chan_resources() calls spin_lock_irqsave() before calling coh901318_config(). But coh901318_config() calls spin_lock_irqsave() again in its definition, which may cause a double-lock bug. Because coh901318_config() is only called by coh901318_alloc_chan_resources(), the bug fix is to remove the calls to spin-lock and -unlock functions in coh901318_config(). Signed-off-by:
Jia-Ju Bai <baijiaju1990@gmail.com> Reviewed-by:
Linus Walleij <linus.walleij@linaro.org> Signed-off-by:
-
Marek Szyprowski authored
BugLink: https://bugs.launchpad.net/bugs/1858489 [ Upstream commit 6035cbcc ] DWC2 hardware module integrated in Samsung SoCs requires some quirks to operate properly, so use Samsung SoC specific compatible to notify driver to apply respective fixes. Signed-off-by:
Marek Szyprowski <m.szyprowski@samsung.com> Signed-off-by:
Krzysztof Kozlowski <krzk@kernel.org> Signed-off-by:
-
Baruch Siach authored
BugLink: https://bugs.launchpad.net/bugs/1858489 [ Upstream commit 73852e56 ] The abracon,tc-resistor property value is in kOhm. Signed-off-by:
Baruch Siach <baruch@tkos.co.il> Signed-off-by:
Alexandre Belloni <alexandre.belloni@bootlin.com> Signed-off-by:
-
Christophe JAILLET authored
BugLink: https://bugs.launchpad.net/bugs/1858489 [ Upstream commit 41ef3878 ] In case of error, we return 0. This is spurious and not consistent with the other functions of the driver. Propagate the error code instead. Signed-off-by:
Christophe JAILLET <christophe.jaillet@wanadoo.fr> Signed-off-by:
-
Vincent Chen authored
BugLink: https://bugs.launchpad.net/bugs/1858489 [ Upstream commit 83312f1b ] _FP_ROUND_ZERO is defined as 0 and used as a statemente in macro _FP_ROUND. This generates "error: statement with no effect [-Werror=unused-value]" from gcc. Defining _FP_ROUND_ZERO as (void)0 to fix it. This modification is quoted from glibc 'commit <In libc/:> (8ed1e7d5894000c155acbd06f)' Signed-off-by:
Vincent Chen <vincentc@andestech.com> Acked-by:
Greentime Hu <greentime@andestech.com> Signed-off-by:
-
Aaro Koskinen authored
BugLink: https://bugs.launchpad.net/bugs/1858489 [ Upstream commit 2cf1c893 ] Use correct type for fdt_property nameoff field. Signed-off-by:
-
Mark Brown authored
BugLink: https://bugs.launchpad.net/bugs/1858489 [ Upstream commit f1abf672 ] The stub implementation of _set_load() returns a mode value which is within the bounds of valid return codes for success (the documentation just says that failures are negative error codes) but not sensible or what the actual implementation does. Fix it to just return 0. Reported-by:
Cheng-Yi Chiang <cychiang@chromium.org> Signed-off-by:
Mark Brown <broonie@kernel.org> Reviewed-by:
Douglas Anderson <dianders@chromium.org> Signed-off-by:
-
Shreeya Patel authored
BugLink: https://bugs.launchpad.net/bugs/1858489 [ Upstream commit 688cd642 ] adt7316_i2c_read function nowhere sets the data field. It is necessary to have an appropriate value for it. Hence, assign the value stored in 'ret' variable to data field. This is an ancient bug, and as no one seems to have noticed, probably no sense in applying it to stable. Signed-off-by:
Shreeya Patel <shreeya.patel23498@gmail.com> Signed-off-by:
Jonathan Cameron <Jonathan.Cameron@huawei.com> Signed-off-by:
-
Brian Masney authored
BugLink: https://bugs.launchpad.net/bugs/1858489 [ Upstream commit 7ed07855 ] When attempting to setup up a gpio hog, device probing will repeatedly fail with -EPROBE_DEFERED errors. It is caused by a circular dependency between the gpio and pinctrl frameworks. If the gpio-ranges property is present in device tree, then the gpio framework will handle the gpio pin registration and eliminate the circular dependency. See Christian Lamparter's commit a86caa9b ("pinctrl: msm: fix gpio-hog related boot issues") for a detailed commit message that explains the issue in much more detail. The code comment in this commit came from Christian's commit. I did not test this change against any hardware supported by this particular driver, however I was able to validate this same fix works for pinctrl-spmi-gpio.c using a LG Nexus 5 (hammerhead) phone. Signed-off-by:
Brian Masney <masneyb@onstation.org> Reviewed-by:
Bjorn Andersson <bjorn.andersson@linaro.org> Signed-off-by:
-
Steffen Maier authored
BugLink: https://bugs.launchpad.net/bugs/1858489 [ Upstream commit 0c902936 ] This was introduced with v4.18 commit 8c3d20aa ("scsi: zfcp: fix missing REC trigger trace for all objects in ERP_FAILED") but would now suppress helpful -Wswitch compiler warnings when building with W=1 such as the following forced example: drivers/s390/scsi/zfcp_erp.c: In function 'zfcp_erp_handle_failed': drivers/s390/scsi/zfcp_erp.c:126:2: warning: enumeration value 'ZFCP_ERP_ACTION_REOPEN_PORT_FORCED' not handled in switch [-Wswitch] switch (want) { ^~~~~~ But then again, only with W=1 we would notice unhandled enum cases. Without the default cases and a missed unhandled enum case, the code might perform unforeseen things we might not want... As of today, we never run through the removed default case, so removing it is no functional change. In the future, we never should run through a default case but introduce the necessary specific case(s) to handle new functionality. Signed-off-by:
Steffen Maier <maier@linux.ibm.com> Reviewed-by:
Benjamin Block <bblock@linux.ibm.com> Signed-off-by:
Martin K. Petersen <martin.petersen@oracle.com> Signed-off-by:
-
Maciej W. Rozycki authored
BugLink: https://bugs.launchpad.net/bugs/1858489 [ Upstream commit 756d6d83 ] The LittleSur board is marked for high memory support and therefore clearly must provide a way to have enough memory installed for some to be present outside the low 4GiB physical address range. With the memory map of the BCM1250 SOC it has been built around it means over 1GiB of actual DRAM, as only the first 1GiB is mapped in the low 4GiB physical address range[1]. Complement commit cce335ae ("[MIPS] 64-bit Sibyte kernels need DMA32.") then and also enable ZONE_DMA32 for LittleSur. References: [1] "BCM1250/BCM1125/BCM1125H User Manual", Revision 1250_1125-UM100-R, Broadcom Corporation, 21 Oct 2002, Section 3: "System Overview", "Memory Map", pp. 34-38 Signed-off-by:
Maciej W. Rozycki <macro@linux-mips.org> Signed-off-by:
-
David Teigland authored
BugLink: https://bugs.launchpad.net/bugs/1858489 [ Upstream commit 8fc6ed9a ] Which would leak memory for the idr internals. Signed-off-by:
-
Heiko Stuebner authored
BugLink: https://bugs.launchpad.net/bugs/1858489 [ Upstream commit ac8cb538 ] Similar to commit a9f0c0e5 ("clk: rockchip: fix rk3188 sclk_smc gate data") there is one other gate clock in the rk3188 clock driver with a similar wrong ordering, the sclk_mac_lbtest. So fix it as well. Signed-off-by:
Heiko Stuebner <heiko@sntech.de> Signed-off-by:
-
Finley Xiao authored
BugLink: https://bugs.launchpad.net/bugs/1858489 [ Upstream commit a9f0c0e5 ] Fix sclk_smc gate data. Change variable order, flags come before the register address. Signed-off-by:
Finley Xiao <finley.xiao@rock-chips.com> Signed-off-by:
Johan Jonker <jbx9999@hotmail.com> Signed-off-by:
-
Marek Szyprowski authored
BugLink: https://bugs.launchpad.net/bugs/1858489 [ Upstream commit a2dc5091 ] MAX8997 driver disables automatic path selection from MicroUSB connector and manually sets path to either UART or USB lines. However the code for setting USB path worked only for USB host mode (when ID pin is set to ground). When standard USB cable (USB device mode) is connected, path registers are not touched. This means that once the non-USB accessory is connected to MAX8997-operated micro USB port, the path is no longer set to USB and USB device mode doesn't work. This patch fixes it by setting USB path both for USB and USB host modes. Signed-off-by:
Chanwoo Choi <cw00.choi@samsung.com> Signed-off-by:
-
Vincent Whitchurch authored
BugLink: https://bugs.launchpad.net/bugs/1858489 [ Upstream commit 344eb553 ] getuser() and putuser() (and there underscored variants) use two strb[t]/ldrb[t] instructions when they are asked to get/put 16-bits. This means that the read/write is not atomic even when performed to a 16-bit-aligned address. This leads to problems with vhost: vhost uses __getuser() to read the vring's 16-bit avail.index field, and if it happens to observe a partial update of the index, wrong descriptors will be used which will lead to a breakdown of the virtio communication. A similar problem exists for __putuser() which is used to write to the vring's used.index field. The reason these functions use strb[t]/ldrb[t] is because strht/ldrht instructions did not exist until ARMv6T2/ARMv7. So we should be easily able to fix this on ARMv7. Also, since all ARMv6 processors also don't actually use the unprivileged instructions anymore for uaccess (since CONFIG_CPU_USE_DOMAINS is not used) we can easily fix them too. Signed-off-by:
Vincent Whitchurch <vincent.whitchurch@axis.com> Signed-off-by:
Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by:
-
Andrei Otcheretianski authored
BugLink: https://bugs.launchpad.net/bugs/1858489 [ Upstream commit dc1aca22 ] TDLS discovery response frame is a unicast direct frame to the peer. Since we don't have a STA for this peer, this frame goes through iwl_tx_skb_non_sta(). As the result aux_sta and some completely arbitrary queue would be selected for this frame, resulting in a queue hang. Fix that by sending such frames through AP sta instead. Signed-off-by:
Andrei Otcheretianski <andrei.otcheretianski@intel.com> Signed-off-by:
Luca Coelho <luciano.coelho@intel.com> Signed-off-by:
-
Douglas Anderson authored
BugLink: https://bugs.launchpad.net/bugs/1858489 [ Upstream commit d6e19358 ] Right now serial drivers process sysrq keys deep in their character receiving code. This means that they've already grabbed their port->lock spinlock. This can end up getting in the way if we've go to do serial stuff (especially kgdb) in response to the sysrq. Serial drivers have various hacks in them to handle this. Looking at '8250_port.c' you can see that the console_write() skips locking if we're in the sysrq handler. Looking at 'msm_serial.c' you can see that the port lock is dropped around uart_handle_sysrq_char(). It turns out that these hacks aren't exactly perfect. If you have lockdep turned on and use something like the 8250_port hack you'll get a splat that looks like: WARNING: possible circular locking dependency detected [...] is trying to acquire lock: ... (console_owner){-.-.}, at: console_unlock+0x2e0/0x5e4 but task is already holding lock: ... (&port_lock_key){-.-.}, at: serial8250_handle_irq+0x30/0xe4 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #1 (&port_lock_key){-.-.}: _raw_spin_lock_irqsave+0x58/0x70 serial8250_console_write+0xa8/0x250 univ8250_console_write+0x40/0x4c console_unlock+0x528/0x5e4 register_console+0x2c4/0x3b0 uart_add_one_port+0x350/0x478 serial8250_register_8250_port+0x350/0x3a8 dw8250_probe+0x67c/0x754 platform_drv_probe+0x58/0xa4 really_probe+0x150/0x294 driver_probe_device+0xac/0xe8 __driver_attach+0x98/0xd0 bus_for_each_dev+0x84/0xc8 driver_attach+0x2c/0x34 bus_add_driver+0xf0/0x1ec driver_register+0xb4/0x100 __platform_driver_register+0x60/0x6c dw8250_platform_driver_init+0x20/0x28 ... -> #0 (console_owner){-.-.}: lock_acquire+0x1e8/0x214 console_unlock+0x35c/0x5e4 vprintk_emit+0x230/0x274 vprintk_default+0x7c/0x84 vprintk_func+0x190/0x1bc printk+0x80/0xa0 __handle_sysrq+0x104/0x21c handle_sysrq+0x30/0x3c serial8250_read_char+0x15c/0x18c serial8250_rx_chars+0x34/0x74 serial8250_handle_irq+0x9c/0xe4 dw8250_handle_irq+0x98/0xcc serial8250_interrupt+0x50/0xe8 ... other info that might help us debug this: Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(&port_lock_key); lock(console_owner); lock(&port_lock_key); lock(console_owner); *** DEADLOCK *** The hack used in 'msm_serial.c' doesn't cause the above splats but it seems a bit ugly to unlock / lock our spinlock deep in our irq handler. It seems like we could defer processing the sysrq until the end of the interrupt handler right after we've unlocked the port. With this scheme if a whole batch of sysrq characters comes in one irq then we won't handle them all, but that seems like it should be a fine compromise. Signed-off-by:
-
Chuhong Yuan authored
BugLink: https://bugs.launchpad.net/bugs/1858489 [ Upstream commit 3df70afe ] The driver calls release_resource in remove to match request_mem_region in probe, which is incorrect. Fix it by using the right one, release_mem_region. Signed-off-by:
Chuhong Yuan <hslester96@gmail.com> Signed-off-by:
-
