aboutsummaryrefslogtreecommitdiffstats
path: root/drivers/tty/serial
AgeCommit message (Collapse)Author
2021-12-08serial: core: fix transmit-buffer reset and memleakJohan Hovold
commit 00de977f9e0aa9760d9a79d1e41ff780f74e3424 upstream. Commit 761ed4a94582 ("tty: serial_core: convert uart_close to use tty_port_close") converted serial core to use tty_port_close() but failed to notice that the transmit buffer still needs to be freed on final close. Not freeing the transmit buffer means that the buffer is no longer cleared on next open so that any ioctl() waiting for the buffer to drain might wait indefinitely (e.g. on termios changes) or that stale data can end up being transmitted in case tx is restarted. Furthermore, the buffer of any port that has been opened would leak on driver unbind. Note that the port lock is held when clearing the buffer pointer due to the ldisc race worked around by commit a5ba1d95e46e ("uart: fix race between uart_put_char() and uart_shutdown()"). Also note that the tty-port shutdown() callback is not called for console ports so it is not strictly necessary to free the buffer page after releasing the lock (cf. d72402145ace ("tty/serial: do not free trasnmit buffer page under port lock")). Link: https://lore.kernel.org/r/319321886d97c456203d5c6a576a5480d07c3478.1635781688.git.baruch@tkos.co.il Fixes: 761ed4a94582 ("tty: serial_core: convert uart_close to use tty_port_close") Cc: stable@vger.kernel.org # 4.9 Cc: Rob Herring <robh@kernel.org> Reported-by: Baruch Siach <baruch@tkos.co.il> Tested-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Johan Hovold <johan@kernel.org> Link: https://lore.kernel.org/r/20211108085431.12637-1-johan@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-12-08serial: pl011: Add ACPI SBSA UART match idPierre Gondois
commit ac442a077acf9a6bf1db4320ec0c3f303be092b3 upstream. The document 'ACPI for Arm Components 1.0' defines the following _HID mappings: -'Prime cell UART (PL011)': ARMH0011 -'SBSA UART': ARMHB000 Use the sbsa-uart driver when a device is described with the 'ARMHB000' _HID. Note: PL011 devices currently use the sbsa-uart driver instead of the uart-pl011 driver. Indeed, PL011 devices are not bound to a clock in ACPI. It is not possible to change their baudrate. Cc: <stable@vger.kernel.org> Signed-off-by: Pierre Gondois <Pierre.Gondois@arm.com> Link: https://lore.kernel.org/r/20211109172248.19061-1-Pierre.Gondois@arm.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-12-08tty: serial: msm_serial: Deactivate RX DMA for polling supportSven Eckelmann
commit 7492ffc90fa126afb67d4392d56cb4134780194a upstream. The CONSOLE_POLLING mode is used for tools like k(g)db. In this kind of setup, it is often sharing a serial device with the normal system console. This is usually no problem because the polling helpers can consume input values directly (when in kgdb context) and the normal Linux handlers can only consume new input values after kgdb switched back. This is not true anymore when RX DMA is enabled for UARTDM controllers. Single input values can no longer be received correctly. Instead following seems to happen: * on 1. input, some old input is read (continuously) * on 2. input, two old inputs are read (continuously) * on 3. input, three old input values are read (continuously) * on 4. input, 4 previous inputs are received This repeats then for each group of 4 input values. This behavior changes slightly depending on what state the controller was when the first input was received. But this makes working with kgdb basically impossible because control messages are always corrupted when kgdboc tries to parse them. RX DMA should therefore be off when CONSOLE_POLLING is enabled to avoid these kind of problems. No such problem was noticed for TX DMA. Fixes: 99693945013a ("tty: serial: msm: Add RX DMA support") Cc: stable@vger.kernel.org Signed-off-by: Sven Eckelmann <sven@narfation.org> Link: https://lore.kernel.org/r/20211113121050.7266-1-sven@narfation.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-11-26serial: xilinx_uartps: Fix race condition causing stuck TXAnssi Hannula
[ Upstream commit 88b20f84f0fe47409342669caf3e58a3fc64c316 ] xilinx_uartps .start_tx() clears TXEMPTY when enabling TXEMPTY to avoid any previous TXEVENT event asserting the UART interrupt. This clear operation is done immediately after filling the TX FIFO. However, if the bytes inserted by cdns_uart_handle_tx() are consumed by the UART before the TXEMPTY is cleared, the clear operation eats the new TXEMPTY event as well, causing cdns_uart_isr() to never receive the TXEMPTY event. If there are bytes still queued in circbuf, TX will get stuck as they will never get transferred to FIFO (unless new bytes are queued to circbuf in which case .start_tx() is called again). While the racy missed TXEMPTY occurs fairly often with short data sequences (e.g. write 1 byte), in those cases circbuf is usually empty so no action on TXEMPTY would have been needed anyway. On the other hand, longer data sequences make the race much more unlikely as UART takes longer to consume the TX FIFO. Therefore it is rare for this race to cause visible issues in general. Fix the race by clearing the TXEMPTY bit in ISR *before* filling the FIFO. The TXEMPTY bit in ISR will only get asserted at the exact moment the TX FIFO *becomes* empty, so clearing the bit before filling FIFO does not cause an extra immediate assertion even if the FIFO is initially empty. This is hard to reproduce directly on a normal system, but inserting e.g. udelay(200) after cdns_uart_handle_tx(port), setting 4000000 baud, and then running "dd if=/dev/zero bs=128 of=/dev/ttyPS0 count=50" reliably reproduces the issue on my ZynqMP test system unless this fix is applied. Fixes: 85baf542d54e ("tty: xuartps: support 64 byte FIFO size") Signed-off-by: Anssi Hannula <anssi.hannula@bitwise.fi> Link: https://lore.kernel.org/r/20211026102741.2910441-1-anssi.hannula@bitwise.fi Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-11-26serial: 8250_dw: Drop wrong use of ACPI_PTR()Andy Shevchenko
[ Upstream commit ebabb77a2a115b6c5e68f7364b598310b5f61fb2 ] ACPI_PTR() is more harmful than helpful. For example, in this case if CONFIG_ACPI=n, the ID table left unused which is not what we want. Instead of adding ifdeffery here and there, drop ACPI_PTR(). Fixes: 6a7320c4669f ("serial: 8250_dw: Add ACPI 5.0 support") Reported-by: Daniel Palmer <daniel@0x0f.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://lore.kernel.org/r/20211005134516.23218-1-andriy.shevchenko@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-11-26serial: core: Fix initializing and restoring termios speedPali Rohár
commit 027b57170bf8bb6999a28e4a5f3d78bf1db0f90c upstream. Since commit edc6afc54968 ("tty: switch to ktermios and new framework") termios speed is no longer stored only in c_cflag member but also in new additional c_ispeed and c_ospeed members. If BOTHER flag is set in c_cflag then termios speed is stored only in these new members. Therefore to correctly restore termios speed it is required to store also ispeed and ospeed members, not only cflag member. In case only cflag member with BOTHER flag is restored then functions tty_termios_baud_rate() and tty_termios_input_baud_rate() returns baudrate stored in c_ospeed / c_ispeed member, which is zero as it was not restored too. If reported baudrate is invalid (e.g. zero) then serial core functions report fallback baudrate value 9600. So it means that in this case original baudrate is lost and kernel changes it to value 9600. Simple reproducer of this issue is to boot kernel with following command line argument: "console=ttyXXX,86400" (where ttyXXX is the device name). For speed 86400 there is no Bnnn constant and therefore kernel has to represent this speed via BOTHER c_cflag. Which means that speed is stored only in c_ospeed and c_ispeed members, not in c_cflag anymore. If bootloader correctly configures serial device to speed 86400 then kernel prints boot log to early console at speed speed 86400 without any issue. But after kernel starts initializing real console device ttyXXX then speed is changed to fallback value 9600 because information about speed was lost. This patch fixes above issue by storing and restoring also ispeed and ospeed members, which are required for BOTHER flag. Fixes: edc6afc54968 ("[PATCH] tty: switch to ktermios and new framework") Cc: stable@vger.kernel.org Signed-off-by: Pali Rohár <pali@kernel.org> Link: https://lore.kernel.org/r/20211002130900.9518-1-pali@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-10-06serial: mvebu-uart: fix driver's tx_empty callbackPali Rohár
commit 74e1eb3b4a1ef2e564b4bdeb6e92afe844e900de upstream. Driver's tx_empty callback should signal when the transmit shift register is empty. So when the last character has been sent. STAT_TX_FIFO_EMP bit signals only that HW transmit FIFO is empty, which happens when the last byte is loaded into transmit shift register. STAT_TX_EMP bit signals when the both HW transmit FIFO and transmit shift register are empty. So replace STAT_TX_FIFO_EMP check by STAT_TX_EMP in mvebu_uart_tx_empty() callback function. Fixes: 30530791a7a0 ("serial: mvebu-uart: initial support for Armada-3700 serial port") Cc: stable <stable@vger.kernel.org> Signed-off-by: Pali Rohár <pali@kernel.org> Link: https://lore.kernel.org/r/20210911132017.25505-1-pali@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-09-22serial: 8250_pci: make setup_port() parameters explicitly unsignedGreg Kroah-Hartman
[ Upstream commit 3a96e97ab4e835078e6f27b7e1c0947814df3841 ] The bar and offset parameters to setup_port() are used in pointer math, and while it would be very difficult to get them to wrap as a negative number, just be "safe" and make them unsigned so that static checkers do not trip over them unintentionally. Cc: Jiri Slaby <jirislaby@kernel.org> Reported-by: Jordy Zomer <jordy@pwning.systems> Link: https://lore.kernel.org/r/20210726130717.2052096-1-gregkh@linuxfoundation.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-09-22serial: 8250: Define RX trigger levels for OxSemi 950 devicesMaciej W. Rozycki
[ Upstream commit d7aff291d069c4418285f3c8ee27b0ff67ce5998 ] Oxford Semiconductor 950 serial port devices have a 128-byte FIFO and in the enhanced (650) mode, which we select in `autoconfig_has_efr' with the ECB bit set in the EFR register, they support the receive interrupt trigger level selectable with FCR bits 7:6 from the set of 16, 32, 112, 120. This applies to the original OX16C950 discrete UART[1] as well as 950 cores embedded into more complex devices. For these devices we set the default to 112, which sets an excessively high level of 112 or 7/8 of the FIFO capacity, unlike with other port types where we choose at most 1/2 of their respective FIFO capacities. Additionally we don't make the trigger level configurable. Consequently frequent input overruns happen with high bit rates where hardware flow control cannot be used (e.g. terminal applications) even with otherwise highly-performant systems. Lower the default receive interrupt trigger level to 32 then, and make it configurable. Document the trigger levels along with other port types, including the set of 16, 32, 64, 112 for the transmit interrupt as well[2]. References: [1] "OX16C950 rev B High Performance UART with 128 byte FIFOs", Oxford Semiconductor, Inc., DS-0031, Sep 05, Table 10: "Receiver Trigger Levels", p. 22 [2] same, Table 9: "Transmit Interrupt Trigger Levels", p. 22 Signed-off-by: Maciej W. Rozycki <macro@orcam.me.uk> Link: https://lore.kernel.org/r/alpine.DEB.2.21.2106260608480.37803@angie.orcam.me.uk Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-09-22tty: serial: jsm: hold port lock when reporting modem line changesZheyu Ma
[ Upstream commit 240e126c28df084222f0b661321e8e3ecb0d232e ] uart_handle_dcd_change() requires a port lock to be held and will emit a warning when lockdep is enabled. Held corresponding lock to fix the following warnings. [ 132.528648] WARNING: CPU: 5 PID: 11600 at drivers/tty/serial/serial_core.c:3046 uart_handle_dcd_change+0xf4/0x120 [ 132.530482] Modules linked in: [ 132.531050] CPU: 5 PID: 11600 Comm: jsm Not tainted 5.14.0-rc1-00003-g7fef2edf7cc7-dirty #31 [ 132.535268] RIP: 0010:uart_handle_dcd_change+0xf4/0x120 [ 132.557100] Call Trace: [ 132.557562] ? __free_pages+0x83/0xb0 [ 132.558213] neo_parse_modem+0x156/0x220 [ 132.558897] neo_param+0x399/0x840 [ 132.559495] jsm_tty_open+0x12f/0x2d0 [ 132.560131] uart_startup.part.18+0x153/0x340 [ 132.560888] ? lock_is_held_type+0xe9/0x140 [ 132.561660] uart_port_activate+0x7f/0xe0 [ 132.562351] ? uart_startup.part.18+0x340/0x340 [ 132.563003] tty_port_open+0x8d/0xf0 [ 132.563523] ? uart_set_options+0x1e0/0x1e0 [ 132.564125] uart_open+0x24/0x40 [ 132.564604] tty_open+0x15c/0x630 Signed-off-by: Zheyu Ma <zheyuma97@gmail.com> Link: https://lore.kernel.org/r/1626242003-3809-1-git-send-email-zheyuma97@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-09-22tty: serial: fsl_lpuart: fix the wrong mapbase valueAndy Duan
[ Upstream commit d5c38948448abc2bb6b36dbf85a554bf4748885e ] Register offset needs to be applied on mapbase also. dma_tx/rx_request use the physical address of UARTDATA. Register offset is currently only applied to membase (the corresponding virtual addr) but not on mapbase. Fixes: 24b1e5f0e83c ("tty: serial: lpuart: add imx7ulp support") Reviewed-by: Leonard Crestez <leonard.crestez@nxp.com> Signed-off-by: Adriana Reus <adriana.reus@nxp.com> Signed-off-by: Sherry Sun <sherry.sun@nxp.com> Signed-off-by: Andy Duan <fugang.duan@nxp.com> Link: https://lore.kernel.org/r/20210819021033.32606-1-sherry.sun@nxp.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-08-15serial: 8250: Mask out floating 16/32-bit bus bitsMaciej W. Rozycki
commit e5227c51090e165db4b48dcaa300605bfced7014 upstream. Make sure only actual 8 bits of the IIR register are used in determining the port type in `autoconfig'. The `serial_in' port accessor returns the `unsigned int' type, meaning that with UPIO_AU, UPIO_MEM16, UPIO_MEM32, and UPIO_MEM32BE access types more than 8 bits of data are returned, of which the high order bits will often come from bus lines that are left floating in the data phase. For example with the MIPS Malta board's CBUS UART, where the registers are aligned on 8-byte boundaries and which uses 32-bit accesses, data as follows is returned: YAMON> dump -32 0xbf000900 0x40 BF000900: 1F000942 1F000942 1F000900 1F000900 ...B...B........ BF000910: 1F000901 1F000901 1F000900 1F000900 ................ BF000920: 1F000900 1F000900 1F000960 1F000960 ...........`...` BF000930: 1F000900 1F000900 1F0009FF 1F0009FF ................ YAMON> Evidently high-order 24 bits return values previously driven in the address phase (the 3 highest order address bits used with the command above are masked out in the simple virtual address mapping used here and come out at zeros on the external bus), a common scenario with bus lines left floating, due to bus capacitance. Consequently when the value of IIR, mapped at 0x1f000910, is retrieved in `autoconfig', it comes out at 0x1f0009c1 and when it is right-shifted by 6 and then assigned to 8-bit `scratch' variable, the value calculated is 0x27, not one of 0, 1, 2, 3 expected in port type determination. Fix the issue then, by assigning the value returned from `serial_in' to `scratch' first, which masks out 24 high-order bits retrieved, and only then right-shift the resulting 8-bit data quantity, producing the value of 3 in this case, as expected. Fix the same issue in `serial_dl_read'. The problem first appeared with Linux 2.6.9-rc3 which predates our repo history, but the origin could be identified with the old MIPS/Linux repo also at: <git://git.kernel.org/pub/scm/linux/kernel/git/ralf/linux.git> as commit e0d2356c0777 ("Merge with Linux 2.6.9-rc3."), where code in `serial_in' was updated with this case: + case UPIO_MEM32: + return readl(up->port.membase + offset); + which made it produce results outside the unsigned 8-bit range for the first time, though obviously it is system dependent what actual values appear in the high order bits retrieved and it may well have been zeros in the relevant positions with the system the change originally was intended for. It is at that point that code in `autoconf' should have been updated accordingly, but clearly it was overlooked. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: stable@vger.kernel.org # v2.6.12+ Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Signed-off-by: Maciej W. Rozycki <macro@orcam.me.uk> Link: https://lore.kernel.org/r/alpine.DEB.2.21.2106260516220.37803@angie.orcam.me.uk Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-07-20tty: serial: 8250: serial_cs: Fix a memory leak in error handling pathChristophe JAILLET
[ Upstream commit fad92b11047a748c996ebd6cfb164a63814eeb2e ] In the probe function, if the final 'serial_config()' fails, 'info' is leaking. Add a resource handling path to free this memory. Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Link: https://lore.kernel.org/r/dc25f96b7faebf42e60fe8d02963c941cf4d8124.1621971720.git.christophe.jaillet@wanadoo.fr Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-07-20tty: serial: fsl_lpuart: fix the potential risk of division or modulo by zeroSherry Sun
[ Upstream commit fcb10ee27fb91b25b68d7745db9817ecea9f1038 ] We should be very careful about the register values that will be used for division or modulo operations, althrough the possibility that the UARTBAUD register value is zero is very low, but we had better to deal with the "bad data" of hardware in advance to avoid division or modulo by zero leading to undefined kernel behavior. Signed-off-by: Sherry Sun <sherry.sun@nxp.com> Link: https://lore.kernel.org/r/20210427021226.27468-1-sherry.sun@nxp.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-07-20serial_cs: remove wrong GLOBETROTTER.cis entryOndrej Zary
commit 11b1d881a90fc184cc7d06e9804eb288c24a2a0d upstream. The GLOBETROTTER.cis entry in serial_cs matches more devices than intended and breaks them. Remove it. Example: # pccardctl info PRODID_1="Option International " PRODID_2="GSM-Ready 56K/ISDN " PRODID_3="021 " PRODID_4="A " MANFID=0013,0000 FUNCID=0 result: pcmcia 0.0: Direct firmware load for cis/GLOBETROTTER.cis failed with error -2 The GLOBETROTTER.cis is nowhere to be found. There's GLOBETROTTER.cis.ihex at https://netdev.vger.kernel.narkive.com/h4inqdxM/patch-axnet-cs-fix-phy-id-detection-for-bogus-asix-chip#post41 It's from completely diffetent card: vers_1 4.1, "Option International", "GSM/GPRS GlobeTrotter", "001", "A" Signed-off-by: Ondrej Zary <linux@zary.sk> Cc: stable <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20210611201940.23898-1-linux@zary.sk Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-07-20serial_cs: Add Option International GSM-Ready 56K/ISDN modemOndrej Zary
commit d495dd743d5ecd47288156e25c4d9163294a0992 upstream. Add support for Option International GSM-Ready 56K/ISDN PCMCIA modem card. Signed-off-by: Ondrej Zary <linux@zary.sk> Cc: stable <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20210611201940.23898-2-linux@zary.sk Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-07-20serial: sh-sci: Stop dmaengine transfer in sci_stop_tx()Yoshihiro Shimoda
commit 08a84410a04f05c7c1b8e833f552416d8eb9f6fe upstream. Stop dmaengine transfer in sci_stop_tx(). Otherwise, the following message is possible output when system enters suspend and while transferring data, because clearing TIE bit in SCSCR is not able to stop any dmaengine transfer. sh-sci e6550000.serial: ttySC1: Unable to drain transmitter Note that this driver has already used some #ifdef in the .c file so that this patch also uses #ifdef to fix the issue. Otherwise, build errors happens if the CONFIG_SERIAL_SH_SCI_DMA is disabled. Fixes: 73a19e4c0301 ("serial: sh-sci: Add DMA support.") Cc: <stable@vger.kernel.org> # v4.9+ Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Link: https://lore.kernel.org/r/20210610110806.277932-1-yoshihiro.shimoda.uh@renesas.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-06-03serial: max310x: unregister uart driver in case of failure and abortAtul Gopinathan
[ Upstream commit 3890e3dea315f1a257d1b940a2a4e2fa16a7b095 ] The macro "spi_register_driver" invokes the function "__spi_register_driver()" which has a return type of int and can fail, returning a negative value in such a case. This is currently ignored and the init() function yields success even if the spi driver failed to register. Fix this by collecting the return value of "__spi_register_driver()" and also unregister the uart driver in case of failure. Cc: Jiri Slaby <jirislaby@kernel.org> Signed-off-by: Atul Gopinathan <atulgopinathan@gmail.com> Link: https://lore.kernel.org/r/20210503115736.2104747-12-gregkh@linuxfoundation.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-06-03serial: rp2: use 'request_firmware' instead of 'request_firmware_nowait'Zheyu Ma
commit 016002848c82eeb5d460489ce392d91fe18c475c upstream. In 'rp2_probe', the driver registers 'rp2_uart_interrupt' then calls 'rp2_fw_cb' through 'request_firmware_nowait'. In 'rp2_fw_cb', if the firmware don't exists, function just return without initializing ports of 'rp2_card'. But now the interrupt handler function has been registered, and when an interrupt comes, 'rp2_uart_interrupt' may access those ports then causing NULL pointer dereference or other bugs. Because the driver does some initialization work in 'rp2_fw_cb', in order to make the driver ready to handle interrupts, 'request_firmware' should be used instead of asynchronous 'request_firmware_nowait'. This report reveals it: INFO: trying to register non-static key. the code is fine but needs lockdep annotation. turning off the locking correctness validator. CPU: 2 PID: 0 Comm: swapper/2 Not tainted 4.19.177-gdba4159c14ef-dirty #45 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.12.0-59- gc9ba5276e321-prebuilt.qemu.org 04/01/2014 Call Trace: <IRQ> __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0xec/0x156 lib/dump_stack.c:118 assign_lock_key kernel/locking/lockdep.c:727 [inline] register_lock_class+0x14e5/0x1ba0 kernel/locking/lockdep.c:753 __lock_acquire+0x187/0x3750 kernel/locking/lockdep.c:3303 lock_acquire+0x124/0x340 kernel/locking/lockdep.c:3907 __raw_spin_lock include/linux/spinlock_api_smp.h:142 [inline] _raw_spin_lock+0x32/0x50 kernel/locking/spinlock.c:144 spin_lock include/linux/spinlock.h:329 [inline] rp2_ch_interrupt drivers/tty/serial/rp2.c:466 [inline] rp2_asic_interrupt.isra.9+0x15d/0x990 drivers/tty/serial/rp2.c:493 rp2_uart_interrupt+0x49/0xe0 drivers/tty/serial/rp2.c:504 __handle_irq_event_percpu+0xfb/0x770 kernel/irq/handle.c:149 handle_irq_event_percpu+0x79/0x150 kernel/irq/handle.c:189 handle_irq_event+0xac/0x140 kernel/irq/handle.c:206 handle_fasteoi_irq+0x232/0x5c0 kernel/irq/chip.c:725 generic_handle_irq_desc include/linux/irqdesc.h:155 [inline] handle_irq+0x230/0x3a0 arch/x86/kernel/irq_64.c:87 do_IRQ+0xa7/0x1e0 arch/x86/kernel/irq.c:247 common_interrupt+0xf/0xf arch/x86/entry/entry_64.S:670 </IRQ> RIP: 0010:native_safe_halt+0x28/0x30 arch/x86/include/asm/irqflags.h:61 Code: 00 00 55 be 04 00 00 00 48 c7 c7 00 c2 2f 8c 48 89 e5 e8 fb 31 e7 f8 8b 05 75 af 8d 03 85 c0 7e 07 0f 00 2d 8a 61 65 00 fb f4 <5d> c3 90 90 90 90 90 90 0f 1f 44 00 00 55 48 89 e5 41 57 41 56 41 RSP: 0018:ffff88806b71fcc8 EFLAGS: 00000246 ORIG_RAX: ffffffffffffffde RAX: 0000000000000000 RBX: ffffffff8bde7e48 RCX: ffffffff88a21285 RDX: 0000000000000000 RSI: 0000000000000004 RDI: ffffffff8c2fc200 RBP: ffff88806b71fcc8 R08: fffffbfff185f840 R09: fffffbfff185f840 R10: 0000000000000001 R11: fffffbfff185f840 R12: 0000000000000002 R13: ffffffff8bea18a0 R14: 0000000000000000 R15: 0000000000000000 arch_safe_halt arch/x86/include/asm/paravirt.h:94 [inline] default_idle+0x6f/0x360 arch/x86/kernel/process.c:557 arch_cpu_idle+0xf/0x20 arch/x86/kernel/process.c:548 default_idle_call+0x3b/0x60 kernel/sched/idle.c:93 cpuidle_idle_call kernel/sched/idle.c:153 [inline] do_idle+0x2ab/0x3c0 kernel/sched/idle.c:263 cpu_startup_entry+0xcb/0xe0 kernel/sched/idle.c:369 start_secondary+0x3b8/0x4e0 arch/x86/kernel/smpboot.c:271 secondary_startup_64+0xa4/0xb0 arch/x86/kernel/head_64.S:243 BUG: unable to handle kernel NULL pointer dereference at 0000000000000010 PGD 8000000056d27067 P4D 8000000056d27067 PUD 56d28067 PMD 0 Oops: 0000 [#1] PREEMPT SMP KASAN PTI CPU: 2 PID: 0 Comm: swapper/2 Not tainted 4.19.177-gdba4159c14ef-dirty #45 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.12.0-59- gc9ba5276e321-prebuilt.qemu.org 04/01/2014 RIP: 0010:readl arch/x86/include/asm/io.h:59 [inline] RIP: 0010:rp2_ch_interrupt drivers/tty/serial/rp2.c:472 [inline] RIP: 0010:rp2_asic_interrupt.isra.9+0x181/0x990 drivers/tty/serial/rp2.c: 493 Code: df e8 43 5d c2 05 48 8d 83 e8 01 00 00 48 89 85 60 ff ff ff 48 c1 e8 03 42 80 3c 30 00 0f 85 aa 07 00 00 48 8b 83 e8 01 00 00 <8b> 40 10 89 c1 89 85 68 ff ff ff 48 8b 83 e8 01 00 00 89 48 10 83 RSP: 0018:ffff88806c287cd0 EFLAGS: 00010046 RAX: 0000000000000000 RBX: ffff88806ade6820 RCX: ffffffff814300b1 RDX: 1ffff1100d5bcd06 RSI: 0000000000000004 RDI: ffff88806ade6820 RBP: ffff88806c287db8 R08: ffffed100d5bcd05 R09: ffffed100d5bcd05 R10: 0000000000000001 R11: ffffed100d5bcd04 R12: ffffc90001e00000 R13: ffff888069654e10 R14: dffffc0000000000 R15: ffff888069654df0 FS: 0000000000000000(0000) GS:ffff88806c280000(0000) knlGS: 0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000010 CR3: 000000006892c000 CR4: 00000000000006e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <IRQ> rp2_uart_interrupt+0x49/0xe0 drivers/tty/serial/rp2.c:504 __handle_irq_event_percpu+0xfb/0x770 kernel/irq/handle.c:149 handle_irq_event_percpu+0x79/0x150 kernel/irq/handle.c:189 handle_irq_event+0xac/0x140 kernel/irq/handle.c:206 handle_fasteoi_irq+0x232/0x5c0 kernel/irq/chip.c:725 generic_handle_irq_desc include/linux/irqdesc.h:155 [inline] handle_irq+0x230/0x3a0 arch/x86/kernel/irq_64.c:87 do_IRQ+0xa7/0x1e0 arch/x86/kernel/irq.c:247 common_interrupt+0xf/0xf arch/x86/entry/entry_64.S:670 </IRQ> RIP: 0010:native_safe_halt+0x28/0x30 arch/x86/include/asm/irqflags.h:61 Code: 00 00 55 be 04 00 00 00 48 c7 c7 00 c2 2f 8c 48 89 e5 e8 fb 31 e7 f8 8b 05 75 af 8d 03 85 c0 7e 07 0f 00 2d 8a 61 65 00 fb f4 <5d> c3 90 90 90 90 90 90 0f 1f 44 00 00 55 48 89 e5 41 57 41 56 41 RSP: 0018:ffff88806b71fcc8 EFLAGS: 00000246 ORIG_RAX: ffffffffffffffde RAX: 0000000000000000 RBX: ffffffff8bde7e48 RCX: ffffffff88a21285 RDX: 0000000000000000 RSI: 0000000000000004 RDI: ffffffff8c2fc200 RBP: ffff88806b71fcc8 R08: fffffbfff185f840 R09: fffffbfff185f840 R10: 0000000000000001 R11: fffffbfff185f840 R12: 0000000000000002 R13: ffffffff8bea18a0 R14: 0000000000000000 R15: 0000000000000000 arch_safe_halt arch/x86/include/asm/paravirt.h:94 [inline] default_idle+0x6f/0x360 arch/x86/kernel/process.c:557 arch_cpu_idle+0xf/0x20 arch/x86/kernel/process.c:548 default_idle_call+0x3b/0x60 kernel/sched/idle.c:93 cpuidle_idle_call kernel/sched/idle.c:153 [inline] do_idle+0x2ab/0x3c0 kernel/sched/idle.c:263 cpu_startup_entry+0xcb/0xe0 kernel/sched/idle.c:369 start_secondary+0x3b8/0x4e0 arch/x86/kernel/smpboot.c:271 secondary_startup_64+0xa4/0xb0 arch/x86/kernel/head_64.S:243 Modules linked in: Dumping ftrace buffer: (ftrace buffer empty) CR2: 0000000000000010 ---[ end trace 11804dbb55cb1a64 ]--- RIP: 0010:readl arch/x86/include/asm/io.h:59 [inline] RIP: 0010:rp2_ch_interrupt drivers/tty/serial/rp2.c:472 [inline] RIP: 0010:rp2_asic_interrupt.isra.9+0x181/0x990 drivers/tty/serial/rp2.c: 493 Code: df e8 43 5d c2 05 48 8d 83 e8 01 00 00 48 89 85 60 ff ff ff 48 c1 e8 03 42 80 3c 30 00 0f 85 aa 07 00 00 48 8b 83 e8 01 00 00 <8b> 40 10 89 c1 89 85 68 ff ff ff 48 8b 83 e8 01 00 00 89 48 10 83 RSP: 0018:ffff88806c287cd0 EFLAGS: 00010046 RAX: 0000000000000000 RBX: ffff88806ade6820 RCX: ffffffff814300b1 RDX: 1ffff1100d5bcd06 RSI: 0000000000000004 RDI: ffff88806ade6820 RBP: ffff88806c287db8 R08: ffffed100d5bcd05 R09: ffffed100d5bcd05 R10: 0000000000000001 R11: ffffed100d5bcd04 R12: ffffc90001e00000 R13: ffff888069654e10 R14: dffffc0000000000 R15: ffff888069654df0 FS: 0000000000000000(0000) GS:ffff88806c280000(0000) knlGS: 0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000010 CR3: 000000006892c000 CR4: 00000000000006e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Reported-by: Zheyu Ma <zheyuma97@gmail.com> Signed-off-by: Zheyu Ma <zheyuma97@gmail.com> Link: https://lore.kernel.org/r/1621577323-1541-1-git-send-email-zheyuma97@gmail.com Cc: stable <stable@vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-06-03serial: sh-sci: Fix off-by-one error in FIFO threshold register settingGeert Uytterhoeven
commit 2ea2e019c190ee3973ef7bcaf829d8762e56e635 upstream. The Receive FIFO Data Count Trigger field (RTRG[6:0]) in the Receive FIFO Data Count Trigger Register (HSRTRGR) of HSCIF can only hold values ranging from 0-127. As the FIFO size is equal to 128 on HSCIF, the user can write an out-of-range value, touching reserved bits. Fix this by limiting the trigger value to the FIFO size minus one. Reverse the order of the checks, to avoid rx_trig becoming zero if the FIFO size is one. Note that this change has no impact on other SCIF variants, as their maximum supported trigger value is lower than the FIFO size anyway, and the code below takes care of enforcing these limits. Fixes: a380ed461f66d1b8 ("serial: sh-sci: implement FIFO threshold register setting") Reported-by: Linh Phung <linh.phung.jy@renesas.com> Reviewed-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Reviewed-by: Ulrich Hecht <uli+renesas@fpond.eu> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Cc: stable <stable@vger.kernel.org> Link: https://lore.kernel.org/r/5eff320aef92ffb33d00e57979fd3603bbb4a70f.1620648218.git.geert+renesas@glider.be Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-05-22serial: 8250: fix potential deadlock in rs485-modeTomas Melin
[ Upstream commit b86f86e8e7c5264bb8f5835d60f9ec840d9f5a7a ] Canceling hrtimer when holding uart spinlock can deadlock. CPU0: syscall write -> get uart port spinlock -> write uart -> start_tx_rs485 -> hrtimer_cancel -> wait for hrtimer callback to finish CPU1: hrtimer IRQ -> run hrtimer -> em485_handle_stop_tx -> get uart port spinlock CPU0 is waiting for the hrtimer callback to finish, but the hrtimer callback running on CPU1 is waiting to get the uart port spinlock. This deadlock can be avoided by not canceling the hrtimers in these paths. Setting active_timer=NULL can be done without accessing hrtimer, and that will effectively cancel operations that would otherwise have been performed by the hrtimer callback. Signed-off-by: Tomas Melin <tomas.melin@vaisala.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-05-22serial: stm32: fix tx_empty conditionErwan Le Ray
[ Upstream commit 3db1d52466dc11dca4e47ef12a6e6e97f846af62 ] In "tx_empty", we should poll TC bit in both DMA and PIO modes (instead of TXE) to check transmission data register has been transmitted independently of the FIFO mode. TC indicates that both transmit register and shift register are empty. When shift register is empty, tx_empty should return TIOCSER_TEMT instead of TC value. Cleans the USART_CR_TC TCCF register define (transmission complete clear flag) as it is duplicate of USART_ICR_TCCF. Fixes: 48a6092fb41f ("serial: stm32-usart: Add STM32 USART Driver") Signed-off-by: Erwan Le Ray <erwan.leray@foss.st.com> Link: https://lore.kernel.org/r/20210304162308.8984-13-erwan.leray@foss.st.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-05-22serial: stm32: fix incorrect characters on consoleErwan Le Ray
[ Upstream commit f264c6f6aece81a9f8fbdf912b20bd3feb476a7a ] Incorrect characters are observed on console during boot. This issue occurs when init/main.c is modifying termios settings to open /dev/console on the rootfs. This patch adds a waiting loop in set_termios to wait for TX shift register empty (and TX FIFO if any) before stopping serial port. Fixes: 48a6092fb41f ("serial: stm32-usart: Add STM32 USART Driver") Signed-off-by: Erwan Le Ray <erwan.leray@foss.st.com> Link: https://lore.kernel.org/r/20210304162308.8984-4-erwan.leray@foss.st.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-12-29serial_core: Check for port state when tty is in error stateAlexey Kardashevskiy
commit 2f70e49ed860020f5abae4f7015018ebc10e1f0e upstream. At the moment opening a serial device node (such as /dev/ttyS3) succeeds even if there is no actual serial device behind it. Reading/writing/ioctls fail as expected because the uart port is not initialized (the type is PORT_UNKNOWN) and the TTY_IO_ERROR error state bit is set fot the tty. However setting line discipline does not have these checks 8250_port.c (8250 is the default choice made by univ8250_console_init()). As the result of PORT_UNKNOWN, uart_port::iobase is NULL which a platform translates onto some address accessing which produces a crash like below. This adds tty_port_initialized() to uart_set_ldisc() to prevent the crash. Found by syzkaller. Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru> Link: https://lore.kernel.org/r/20201203055834.45838-1-aik@ozlabs.ru Cc: stable <stable@vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-12-29serial: 8250_omap: Avoid FIFO corruption caused by MDR1 accessAlexander Sverdlin
commit d96f04d347e4011977abdbb4da5d8f303ebd26f8 upstream. It has been observed that once per 300-1300 port openings the first transmitted byte is being corrupted on AM3352 ("v" written to FIFO appeared as "e" on the wire). It only happened if single byte has been transmitted right after port open, which means, DMA is not used for this transfer and the corruption never happened afterwards. Therefore I've carefully re-read the MDR1 errata (link below), which says "when accessing the MDR1 registers that causes a dummy under-run condition that will freeze the UART in IrDA transmission. In UART mode, this may corrupt the transferred data". Strictly speaking, omap_8250_mdr1_errataset() performs a read access and if the value is the same as should be written, exits without errata-recommended FIFO reset. A brief check of the serial_omap_mdr1_errataset() from the competing omap-serial driver showed it has no read access of MDR1. After removing the read access from omap_8250_mdr1_errataset() the data corruption never happened any more. Link: https://www.ti.com/lit/er/sprz360i/sprz360i.pdf Fixes: 61929cf0169d ("tty: serial: Add 8250-core based omap driver") Cc: stable@vger.kernel.org Signed-off-by: Alexander Sverdlin <alexander.sverdlin@gmail.com> Link: https://lore.kernel.org/r/20201210055257.1053028-1-alexander.sverdlin@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-11-24tty: serial: imx: keep console clocks always onFugang Duan
commit e67c139c488e84e7eae6c333231e791f0e89b3fb upstream. For below code, there has chance to cause deadlock in SMP system: Thread 1: clk_enable_lock(); pr_info("debug message"); clk_enable_unlock(); Thread 2: imx_uart_console_write() clk_enable() clk_enable_lock(); Thread 1: Acuired clk enable_lock -> printk -> console_trylock_spinning Thread 2: console_unlock() -> imx_uart_console_write -> clk_disable -> Acquite clk enable_lock So the patch is to keep console port clocks always on like other console drivers. Fixes: 1cf93e0d5488 ("serial: imx: remove the uart_console() check") Acked-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Fugang Duan <fugang.duan@nxp.com> Link: https://lore.kernel.org/r/20201111025136.29818-1-fugang.duan@nxp.com Cc: stable <stable@vger.kernel.org> [fix up build warning - gregkh] Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-11-10serial: txx9: add missing platform_driver_unregister() on error in ↵Qinglang Miao
serial_txx9_init commit 0c5fc92622ed5531ff324b20f014e9e3092f0187 upstream. Add the missing platform_driver_unregister() before return from serial_txx9_init in the error handling case when failed to register serial_txx9_pci_driver with macro ENABLE_SERIAL_TXX9_PCI defined. Fixes: ab4382d27412 ("tty: move drivers/serial/ to drivers/tty/serial/") Signed-off-by: Qinglang Miao <miaoqinglang@huawei.com> Link: https://lore.kernel.org/r/20201103084942.109076-1-miaoqinglang@huawei.com Cc: stable <stable@vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-11-10serial: 8250_mtk: Fix uart_get_baud_rate warningClaire Chang
commit 912ab37c798770f21b182d656937072b58553378 upstream. Mediatek 8250 port supports speed higher than uartclk / 16. If the baud rates in both the new and the old termios setting are higher than uartclk / 16, the WARN_ON in uart_get_baud_rate() will be triggered. Passing NULL as the old termios so uart_get_baud_rate() will use uartclk / 16 - 1 as the new baud rate which will be replaced by the original baud rate later by tty_termios_encode_baud_rate() in mtk8250_set_termios(). Fixes: 551e553f0d4a ("serial: 8250_mtk: Fix high-speed baud rates clamping") Signed-off-by: Claire Chang <tientzu@chromium.org> Link: https://lore.kernel.org/r/20201102120749.374458-1-tientzu@chromium.org Cc: stable <stable@vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-10-29tty: serial: fsl_lpuart: fix lpuart32_poll_get_charPeng Fan
commit 29788ab1d2bf26c130de8f44f9553ee78a27e8d5 upstream. The watermark is set to 1, so we need to input two chars to trigger RDRF using the original logic. With the new logic, we could always get the char when there is data in FIFO. Suggested-by: Fugang Duan <fugang.duan@nxp.com> Signed-off-by: Peng Fan <peng.fan@nxp.com> Link: https://lore.kernel.org/r/20200929095509.21680-1-peng.fan@nxp.com Cc: stable <stable@vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-10-29tty: serial: earlycon dependencyTong Zhang
[ Upstream commit 0fb9342d06b0f667b915ba58bfefc030e534a218 ] parse_options() in drivers/tty/serial/earlycon.c calls uart_parse_earlycon in drivers/tty/serial/serial_core.c therefore selecting SERIAL_EARLYCON should automatically select SERIAL_CORE, otherwise will result in symbol not found error during linking if SERIAL_CORE is not configured as builtin Fixes: 9aac5887595b ("tty/serial: add generic serial earlycon") Signed-off-by: Tong Zhang <ztong0001@gmail.com> Link: https://lore.kernel.org/r/20200828123949.2642-1-ztong0001@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-10-01tty: serial: samsung: Correct clock selection logicJonathan Bakker
[ Upstream commit 7d31676a8d91dd18e08853efd1cb26961a38c6a6 ] Some variants of the samsung tty driver can pick which clock to use for their baud rate generation. In the DT conversion, a default clock was selected to be used if a specific one wasn't assigned and then a comparison of which clock rate worked better was done. Unfortunately, the comparison was implemented in such a way that only the default clock was ever actually compared. Fix this by iterating through all possible clocks, except when a specific clock has already been picked via clk_sel (which is only possible via board files). Signed-off-by: Jonathan Bakker <xc-racer2@live.ca> Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org> Link: https://lore.kernel.org/r/BN6PR04MB06604E63833EA41837EBF77BA3A30@BN6PR04MB0660.namprd04.prod.outlook.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-10-01serial: uartps: Wait for tx_empty in console setupRaviteja Narayanam
[ Upstream commit 42e11948ddf68b9f799cad8c0ddeab0a39da33e8 ] On some platforms, the log is corrupted while console is being registered. It is observed that when set_termios is called, there are still some bytes in the FIFO to be transmitted. So, wait for tx_empty inside cdns_uart_console_setup before calling set_termios. Signed-off-by: Raviteja Narayanam <raviteja.narayanam@xilinx.com> Reviewed-by: Shubhrajyoti Datta <shubhrajyoti.datta@xilinx.com> Link: https://lore.kernel.org/r/1586413563-29125-2-git-send-email-raviteja.narayanam@xilinx.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-10-01serial: 8250: 8250_omap: Terminate DMA before pushing data on RX timeoutVignesh Raghavendra
[ Upstream commit 7cf4df30a98175033e9849f7f16c46e96ba47f41 ] Terminate and flush DMA internal buffers, before pushing RX data to higher layer. Otherwise, this will lead to data corruption, as driver would end up pushing stale buffer data to higher layer while actual data is still stuck inside DMA hardware and has yet not arrived at the memory. While at that, replace deprecated dmaengine_terminate_all() with dmaengine_terminate_async(). Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com> Link: https://lore.kernel.org/r/20200319110344.21348-2-vigneshr@ti.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-10-01serial: 8250_omap: Fix sleeping function called from invalid context during ↵Peter Ujfalusi
probe [ Upstream commit 4ce35a3617c0ac758c61122b2218b6c8c9ac9398 ] When booting j721e the following bug is printed: [ 1.154821] BUG: sleeping function called from invalid context at kernel/sched/completion.c:99 [ 1.154827] in_atomic(): 0, irqs_disabled(): 128, non_block: 0, pid: 12, name: kworker/0:1 [ 1.154832] 3 locks held by kworker/0:1/12: [ 1.154836] #0: ffff000840030728 ((wq_completion)events){+.+.}, at: process_one_work+0x1d4/0x6e8 [ 1.154852] #1: ffff80001214fdd8 (deferred_probe_work){+.+.}, at: process_one_work+0x1d4/0x6e8 [ 1.154860] #2: ffff00084060b170 (&dev->mutex){....}, at: __device_attach+0x38/0x138 [ 1.154872] irq event stamp: 63096 [ 1.154881] hardirqs last enabled at (63095): [<ffff800010b74318>] _raw_spin_unlock_irqrestore+0x70/0x78 [ 1.154887] hardirqs last disabled at (63096): [<ffff800010b740d8>] _raw_spin_lock_irqsave+0x28/0x80 [ 1.154893] softirqs last enabled at (62254): [<ffff800010080c88>] _stext+0x488/0x564 [ 1.154899] softirqs last disabled at (62247): [<ffff8000100fdb3c>] irq_exit+0x114/0x140 [ 1.154906] CPU: 0 PID: 12 Comm: kworker/0:1 Not tainted 5.6.0-rc6-next-20200318-00094-g45e4089b0bd3 #221 [ 1.154911] Hardware name: Texas Instruments K3 J721E SoC (DT) [ 1.154917] Workqueue: events deferred_probe_work_func [ 1.154923] Call trace: [ 1.154928] dump_backtrace+0x0/0x190 [ 1.154933] show_stack+0x14/0x20 [ 1.154940] dump_stack+0xe0/0x148 [ 1.154946] ___might_sleep+0x150/0x1f0 [ 1.154952] __might_sleep+0x4c/0x80 [ 1.154957] wait_for_completion_timeout+0x40/0x140 [ 1.154964] ti_sci_set_device_state+0xa0/0x158 [ 1.154969] ti_sci_cmd_get_device_exclusive+0x14/0x20 [ 1.154977] ti_sci_dev_start+0x34/0x50 [ 1.154984] genpd_runtime_resume+0x78/0x1f8 [ 1.154991] __rpm_callback+0x3c/0x140 [ 1.154996] rpm_callback+0x20/0x80 [ 1.155001] rpm_resume+0x568/0x758 [ 1.155007] __pm_runtime_resume+0x44/0xb0 [ 1.155013] omap8250_probe+0x2b4/0x508 [ 1.155019] platform_drv_probe+0x50/0xa0 [ 1.155023] really_probe+0xd4/0x318 [ 1.155028] driver_probe_device+0x54/0xe8 [ 1.155033] __device_attach_driver+0x80/0xb8 [ 1.155039] bus_for_each_drv+0x74/0xc0 [ 1.155044] __device_attach+0xdc/0x138 [ 1.155049] device_initial_probe+0x10/0x18 [ 1.155053] bus_probe_device+0x98/0xa0 [ 1.155058] deferred_probe_work_func+0x74/0xb0 [ 1.155063] process_one_work+0x280/0x6e8 [ 1.155068] worker_thread+0x48/0x430 [ 1.155073] kthread+0x108/0x138 [ 1.155079] ret_from_fork+0x10/0x18 To fix the bug we need to first call pm_runtime_enable() prior to any pm_runtime calls. Reported-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Link: https://lore.kernel.org/r/20200320125200.6772-1-peter.ujfalusi@ti.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-10-01serial: 8250_port: Don't service RX FIFO if throttledVignesh Raghavendra
[ Upstream commit f19c3f6c8109b8bab000afd35580929958e087a9 ] When port's throttle callback is called, it should stop pushing any more data into TTY buffer to avoid buffer overflow. This means driver has to stop HW from receiving more data and assert the HW flow control. For UARTs with auto HW flow control (such as 8250_omap) manual assertion of flow control line is not possible and only way is to allow RX FIFO to fill up, thus trigger auto HW flow control logic. Therefore make sure that 8250 generic IRQ handler does not drain data when port is stopped (i.e UART_LSR_DR is unset in read_status_mask). Not servicing, RX FIFO would trigger auto HW flow control when FIFO occupancy reaches preset threshold, thus halting RX. Since, error conditions in UART_LSR register are cleared just by reading the register, data has to be drained in case there are FIFO errors, else error information will lost. Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com> Link: https://lore.kernel.org/r/20200319103230.16867-2-vigneshr@ti.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-10-01serial: 8250: Avoid error message on reprobeLukas Wunner
commit e0a851fe6b9b619527bd928aa93caaddd003f70c upstream. If the call to uart_add_one_port() in serial8250_register_8250_port() fails, a half-initialized entry in the serial_8250ports[] array is left behind. A subsequent reprobe of the same serial port causes that entry to be reused. Because uart->port.dev is set, uart_remove_one_port() is called for the half-initialized entry and bails out with an error message: bcm2835-aux-uart 3f215040.serial: Removing wrong port: (null) != (ptrval) The same happens on failure of mctrl_gpio_init() since commit 4a96895f74c9 ("tty/serial/8250: use mctrl_gpio helpers"). Fix by zeroing the uart->port.dev pointer in the probe error path. The bug was introduced in v2.6.10 by historical commit befff6f5bf5f ("[SERIAL] Add new port registration/unregistration functions."): https://git.kernel.org/tglx/history/c/befff6f5bf5f The commit added an unconditional call to uart_remove_one_port() in serial8250_register_port(). In v3.7, commit 835d844d1a28 ("8250_pnp: do pnp probe before legacy probe") made that call conditional on uart->port.dev which allows me to fix the issue by zeroing that pointer in the error path. Thus, the present commit will fix the problem as far back as v3.7 whereas still older versions need to also cherry-pick 835d844d1a28. Fixes: 835d844d1a28 ("8250_pnp: do pnp probe before legacy probe") Signed-off-by: Lukas Wunner <lukas@wunner.de> Cc: stable@vger.kernel.org # v2.6.10 Cc: stable@vger.kernel.org # v2.6.10: 835d844d1a28: 8250_pnp: do pnp probe before legacy Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://lore.kernel.org/r/b4a072013ee1a1d13ee06b4325afb19bda57ca1b.1589285873.git.lukas@wunner.de [iwamatsu: Backported to 4.14, 4.19: adjust context] Signed-off-by: Nobuhiro Iwamatsu (CIP) <nobuhiro1.iwamatsu@toshiba.co.jp> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-09-23serial: 8250_pci: Add Realtek 816a and 816bTobias Diedrich
commit 3c5a87be170aba8ac40982182f812dcff6ed1ad1 upstream. These serial ports are exposed by the OOB-management-engine on RealManage-enabled network cards (e.g. AMD DASH enabled systems using Realtek cards). Because these have 3 BARs, they fail the "num_iomem <= 1" check in serial_pci_guess_board. I've manually checked the two IOMEM regions and BAR 2 doesn't seem to respond to reads, but BAR 4 seems to be an MMIO version of the IO ports (untested). With this change, the ports are detected: 0000:02:00.1: ttyS0 at I/O 0x2200 (irq = 82, base_baud = 115200) is a 16550A 0000:02:00.2: ttyS1 at I/O 0x2100 (irq = 55, base_baud = 115200) is a 16550A lspci output: 02:00.1 0700: 10ec:816a (rev 0e) (prog-if 02 [16550]) Subsystem: 17aa:5082 Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort+ <TAbort- <MAbort- >SERR- <PERR- INTx- Interrupt: pin B routed to IRQ 82 IOMMU group: 11 Region 0: I/O ports at 2200 [size=256] Region 2: Memory at fd715000 (64-bit, non-prefetchable) [size=4K] Region 4: Memory at fd704000 (64-bit, non-prefetchable) [size=16K] Capabilities: [40] Power Management version 3 Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=375mA PME(D0+,D1+,D2+,D3hot+,D3cold+) Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=0 PME- Capabilities: [50] MSI: Enable- Count=1/1 Maskable- 64bit+ Address: 0000000000000000 Data: 0000 Capabilities: [70] Express (v2) Endpoint, MSI 01 DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s unlimited, L1 <64us ExtTag- AttnBtn- AttnInd- PwrInd- RBE+ FLReset- SlotPowerLimit 0.000W DevCtl: CorrErr- NonFatalErr- FatalErr- UnsupReq- RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop- MaxPayload 128 bytes, MaxReadReq 512 bytes DevSta: CorrErr+ NonFatalErr- FatalErr- UnsupReq+ AuxPwr+ TransPend- LnkCap: Port #0, Speed 2.5GT/s, Width x1, ASPM L0s L1, Exit Latency L0s unlimited, L1 <64us ClockPM+ Surprise- LLActRep- BwNot- ASPMOptComp+ LnkCtl: ASPM L1 Enabled; RCB 64 bytes, Disabled- CommClk+ ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt- LnkSta: Speed 2.5GT/s (ok), Width x1 (ok) TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt- DevCap2: Completion Timeout: Range ABCD, TimeoutDis+ NROPrPrP- LTR+ 10BitTagComp- 10BitTagReq- OBFF Via message/WAKE#, ExtFmt- EETLPPrefix- EmergencyPowerReduction Not Supported, EmergencyPowerReductionInit- FRS- TPHComp- ExtTPHComp- AtomicOpsCap: 32bit- 64bit- 128bitCAS- DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis- LTR- OBFF Disabled, AtomicOpsCtl: ReqEn- LnkSta2: Current De-emphasis Level: -6dB, EqualizationComplete- EqualizationPhase1- EqualizationPhase2- EqualizationPhase3- LinkEqualizationRequest- Retimer- 2Retimers- CrosslinkRes: unsupported Capabilities: [b0] MSI-X: Enable- Count=4 Masked- Vector table: BAR=4 offset=00000000 PBA: BAR=4 offset=00000800 Capabilities: [d0] Vital Product Data Not readable Capabilities: [100 v2] Advanced Error Reporting UESta: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol- UEMsk: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol- UESvrt: DLP+ SDES+ TLP- FCP+ CmpltTO- CmpltAbrt- UnxCmplt- RxOF+ MalfTLP+ ECRC- UnsupReq- ACSViol- CESta: RxErr- BadTLP- BadDLLP- Rollover- Timeout- AdvNonFatalErr+ CEMsk: RxErr- BadTLP- BadDLLP- Rollover- Timeout- AdvNonFatalErr+ AERCap: First Error Pointer: 00, ECRCGenCap+ ECRCGenEn- ECRCChkCap+ ECRCChkEn- MultHdrRecCap- MultHdrRecEn- TLPPfxPres- HdrLogCap- HeaderLog: 00000000 00000000 00000000 00000000 Capabilities: [160 v1] Device Serial Number 00-00-00-00-00-00-00-00 Capabilities: [170 v1] Latency Tolerance Reporting Max snoop latency: 0ns Max no snoop latency: 0ns Capabilities: [178 v1] L1 PM Substates L1SubCap: PCI-PM_L1.2+ PCI-PM_L1.1+ ASPM_L1.2+ ASPM_L1.1+ L1_PM_Substates+ PortCommonModeRestoreTime=150us PortTPowerOnTime=150us L1SubCtl1: PCI-PM_L1.2- PCI-PM_L1.1- ASPM_L1.2- ASPM_L1.1- T_CommonMode=0us LTR1.2_Threshold=0ns L1SubCtl2: T_PwrOn=10us 02:00.2 0700: 10ec:816b (rev 0e) [...same...] Signed-off-by: Tobias Diedrich <tobiasdiedrich@gmail.com> Cc: stable <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20200914173628.GA22508@yamamaya.is-a-geek.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-09-03serial: 8250: change lock order in serial8250_do_startup()Sergey Senozhatsky
commit 205d300aea75623e1ae4aa43e0d265ab9cf195fd upstream. We have a number of "uart.port->desc.lock vs desc.lock->uart.port" lockdep reports coming from 8250 driver; this causes a bit of trouble to people, so let's fix it. The problem is reverse lock order in two different call paths: chain #1: serial8250_do_startup() spin_lock_irqsave(&port->lock); disable_irq_nosync(port->irq); raw_spin_lock_irqsave(&desc->lock) chain #2: __report_bad_irq() raw_spin_lock_irqsave(&desc->lock) for_each_action_of_desc() printk() spin_lock_irqsave(&port->lock); Fix this by changing the order of locks in serial8250_do_startup(): do disable_irq_nosync() first, which grabs desc->lock, and grab uart->port after that, so that chain #1 and chain #2 have same lock order. Full lockdep splat: ====================================================== WARNING: possible circular locking dependency detected 5.4.39 #55 Not tainted ====================================================== swapper/0/0 is trying to acquire lock: ffffffffab65b6c0 (console_owner){-...}, at: console_lock_spinning_enable+0x31/0x57 but task is already holding lock: ffff88810a8e34c0 (&irq_desc_lock_class){-.-.}, at: __report_bad_irq+0x5b/0xba which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #2 (&irq_desc_lock_class){-.-.}: _raw_spin_lock_irqsave+0x61/0x8d __irq_get_desc_lock+0x65/0x89 __disable_irq_nosync+0x3b/0x93 serial8250_do_startup+0x451/0x75c uart_startup+0x1b4/0x2ff uart_port_activate+0x73/0xa0 tty_port_open+0xae/0x10a uart_open+0x1b/0x26 tty_open+0x24d/0x3a0 chrdev_open+0xd5/0x1cc do_dentry_open+0x299/0x3c8 path_openat+0x434/0x1100 do_filp_open+0x9b/0x10a do_sys_open+0x15f/0x3d7 kernel_init_freeable+0x157/0x1dd kernel_init+0xe/0x105 ret_from_fork+0x27/0x50 -> #1 (&port_lock_key){-.-.}: _raw_spin_lock_irqsave+0x61/0x8d serial8250_console_write+0xa7/0x2a0 console_unlock+0x3b7/0x528 vprintk_emit+0x111/0x17f printk+0x59/0x73 register_console+0x336/0x3a4 uart_add_one_port+0x51b/0x5be serial8250_register_8250_port+0x454/0x55e dw8250_probe+0x4dc/0x5b9 platform_drv_probe+0x67/0x8b really_probe+0x14a/0x422 driver_probe_device+0x66/0x130 device_driver_attach+0x42/0x5b __driver_attach+0xca/0x139 bus_for_each_dev+0x97/0xc9 bus_add_driver+0x12b/0x228 driver_register+0x64/0xed do_one_initcall+0x20c/0x4a6 do_initcall_level+0xb5/0xc5 do_basic_setup+0x4c/0x58 kernel_init_freeable+0x13f/0x1dd kernel_init+0xe/0x105 ret_from_fork+0x27/0x50 -> #0 (console_owner){-...}: __lock_acquire+0x118d/0x2714 lock_acquire+0x203/0x258 console_lock_spinning_enable+0x51/0x57 console_unlock+0x25d/0x528 vprintk_emit+0x111/0x17f printk+0x59/0x73 __report_bad_irq+0xa3/0xba note_interrupt+0x19a/0x1d6 handle_irq_event_percpu+0x57/0x79 handle_irq_event+0x36/0x55 handle_fasteoi_irq+0xc2/0x18a do_IRQ+0xb3/0x157 ret_from_intr+0x0/0x1d cpuidle_enter_state+0x12f/0x1fd cpuidle_enter+0x2e/0x3d do_idle+0x1ce/0x2ce cpu_startup_entry+0x1d/0x1f start_kernel+0x406/0x46a secondary_startup_64+0xa4/0xb0 other info that might help us debug this: Chain exists of: console_owner --> &port_lock_key --> &irq_desc_lock_class Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(&irq_desc_lock_class); lock(&port_lock_key); lock(&irq_desc_lock_class); lock(console_owner); *** DEADLOCK *** 2 locks held by swapper/0/0: #0: ffff88810a8e34c0 (&irq_desc_lock_class){-.-.}, at: __report_bad_irq+0x5b/0xba #1: ffffffffab65b5c0 (console_lock){+.+.}, at: console_trylock_spinning+0x20/0x181 stack backtrace: CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.4.39 #55 Hardware name: XXXXXX Call Trace: <IRQ> dump_stack+0xbf/0x133 ? print_circular_bug+0xd6/0xe9 check_noncircular+0x1b9/0x1c3 __lock_acquire+0x118d/0x2714 lock_acquire+0x203/0x258 ? console_lock_spinning_enable+0x31/0x57 console_lock_spinning_enable+0x51/0x57 ? console_lock_spinning_enable+0x31/0x57 console_unlock+0x25d/0x528 ? console_trylock+0x18/0x4e vprintk_emit+0x111/0x17f ? lock_acquire+0x203/0x258 printk+0x59/0x73 __report_bad_irq+0xa3/0xba note_interrupt+0x19a/0x1d6 handle_irq_event_percpu+0x57/0x79 handle_irq_event+0x36/0x55 handle_fasteoi_irq+0xc2/0x18a do_IRQ+0xb3/0x157 common_interrupt+0xf/0xf </IRQ> Signed-off-by: Sergey Senozhatsky <sergey.senozhatsky@gmail.com> Fixes: 768aec0b5bcc ("serial: 8250: fix shared interrupts issues with SMP and RT kernels") Reported-by: Guenter Roeck <linux@roeck-us.net> Reported-by: Raul Rangel <rrangel@google.com> BugLink: https://bugs.chromium.org/p/chromium/issues/detail?id=1114800 Link: https://lore.kernel.org/lkml/CAHQZ30BnfX+gxjPm1DUd5psOTqbyDh4EJE=2=VAMW_VDafctkA@mail.gmail.com/T/#u Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: Guenter Roeck <linux@roeck-us.net> Tested-by: Guenter Roeck <linux@roeck-us.net> Cc: stable <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20200817022646.1484638-1-sergey.senozhatsky@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-09-03serial: 8250_exar: Fix number of ports for Commtech PCIe cardsValmer Huhn
commit c6b9e95dde7b54e6a53c47241201ab5a4035c320 upstream. The following in 8250_exar.c line 589 is used to determine the number of ports for each Exar board: nr_ports = board->num_ports ? board->num_ports : pcidev->device & 0x0f; If the number of ports a card has is not explicitly specified, it defaults to the rightmost 4 bits of the PCI device ID. This is prone to error since not all PCI device IDs contain a number which corresponds to the number of ports that card provides. This particular case involves COMMTECH_4222PCIE, COMMTECH_4224PCIE and COMMTECH_4228PCIE cards with device IDs 0x0022, 0x0020 and 0x0021. Currently the multiport cards receive 2, 0 and 1 port instead of 2, 4 and 8 ports respectively. To fix this, each Commtech Fastcom PCIe card is given a struct where the number of ports is explicitly specified. This ensures 'board->num_ports' is used instead of the default 'pcidev->device & 0x0f'. Fixes: d0aeaa83f0b0 ("serial: exar: split out the exar code from 8250_pci") Signed-off-by: Valmer Huhn <valmer.huhn@concurrent-rt.com> Tested-by: Valmer Huhn <valmer.huhn@concurrent-rt.com> Cc: stable <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20200813165255.GC345440@icarus.concurrent-rt.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-09-03serial: pl011: Don't leak amba_ports entry on driver register errorLukas Wunner
commit 89efbe70b27dd325d8a8c177743a26b885f7faec upstream. pl011_probe() calls pl011_setup_port() to reserve an amba_ports[] entry, then calls pl011_register_port() to register the uart driver with the tty layer. If registration of the uart driver fails, the amba_ports[] entry is not released. If this happens 14 times (value of UART_NR macro), then all amba_ports[] entries will have been leaked and driver probing is no longer possible. (To be fair, that can only happen if the DeviceTree doesn't contain alias IDs since they cause the same entry to be used for a given port.) Fix it. Fixes: ef2889f7ffee ("serial: pl011: Move uart_register_driver call to device") Signed-off-by: Lukas Wunner <lukas@wunner.de> Cc: stable@vger.kernel.org # v3.15+ Cc: Tushar Behera <tushar.behera@linaro.org> Link: https://lore.kernel.org/r/138f8c15afb2f184d8102583f8301575566064a6.1597316167.git.lukas@wunner.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-09-03serial: pl011: Fix oops on -EPROBE_DEFERLukas Wunner
commit 27afac93e3bd7fa89749cf11da5d86ac9cde4dba upstream. If probing of a pl011 gets deferred until after free_initmem(), an oops ensues because pl011_console_match() is called which has been freed. Fix by removing the __init attribute from the function and those it calls. Commit 10879ae5f12e ("serial: pl011: add console matching function") introduced pl011_console_match() not just for early consoles but regular preferred consoles, such as those added by acpi_parse_spcr(). Regular consoles may be registered after free_initmem() for various reasons, one being deferred probing, another being dynamic enablement of serial ports using a DeviceTree overlay. Thus, pl011_console_match() must not be declared __init and the functions it calls mustn't either. Stack trace for posterity: Unable to handle kernel paging request at virtual address 80c38b58 Internal error: Oops: 8000000d [#1] PREEMPT SMP ARM PC is at pl011_console_match+0x0/0xfc LR is at register_console+0x150/0x468 [<80187004>] (register_console) [<805a8184>] (uart_add_one_port) [<805b2b68>] (pl011_register_port) [<805b3ce4>] (pl011_probe) [<80569214>] (amba_probe) [<805ca088>] (really_probe) [<805ca2ec>] (driver_probe_device) [<805ca5b0>] (__device_attach_driver) [<805c8060>] (bus_for_each_drv) [<805c9dfc>] (__device_attach) [<805ca630>] (device_initial_probe) [<805c90a8>] (bus_probe_device) [<805c95a8>] (deferred_probe_work_func) Fixes: 10879ae5f12e ("serial: pl011: add console matching function") Signed-off-by: Lukas Wunner <lukas@wunner.de> Cc: stable@vger.kernel.org # v4.10+ Cc: Aleksey Makarov <amakarov@marvell.com> Cc: Peter Hurley <peter@hurleysoftware.com> Cc: Russell King <linux@armlinux.org.uk> Cc: Christopher Covington <cov@codeaurora.org> Link: https://lore.kernel.org/r/f827ff09da55b8c57d316a1b008a137677b58921.1597315557.git.lukas@wunner.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-09-03serial: samsung: Removes the IRQ not found warningTamseel Shams
commit 8c6c378b0cbe0c9f1390986b5f8ffb5f6ff7593b upstream. In few older Samsung SoCs like s3c2410, s3c2412 and s3c2440, UART IP is having 2 interrupt lines. However, in other SoCs like s3c6400, s5pv210, exynos5433, and exynos4210 UART is having only 1 interrupt line. Due to this, "platform_get_irq(platdev, 1)" call in the driver gives the following false-positive error: "IRQ index 1 not found" on newer SoC's. This patch adds the condition to check for Tx interrupt only for the those SoC's which have 2 interrupt lines. Tested-by: Alim Akhtar <alim.akhtar@samsung.com> Tested-by: Marek Szyprowski <m.szyprowski@samsung.com> Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org> Reviewed-by: Alim Akhtar <alim.akhtar@samsung.com> Signed-off-by: Tamseel Shams <m.shams@samsung.com> Cc: stable <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20200810030021.45348-1-m.shams@samsung.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-07-29serial: 8250_mtk: Fix high-speed baud rates clampingSerge Semin
commit 551e553f0d4ab623e2a6f424ab5834f9c7b5229c upstream. Commit 7b668c064ec3 ("serial: 8250: Fix max baud limit in generic 8250 port") fixed limits of a baud rate setting for a generic 8250 port. In other words since that commit the baud rate has been permitted to be within [uartclk / 16 / UART_DIV_MAX; uartclk / 16], which is absolutely normal for a standard 8250 UART port. But there are custom 8250 ports, which provide extended baud rate limits. In particular the Mediatek 8250 port can work with baud rates up to "uartclk" speed. Normally that and any other peculiarity is supposed to be handled in a custom set_termios() callback implemented in the vendor-specific 8250-port glue-driver. Currently that is how it's done for the most of the vendor-specific 8250 ports, but for some reason for Mediatek a solution has been spread out to both the glue-driver and to the generic 8250-port code. Due to that a bug has been introduced, which permitted the extended baud rate limit for all even for standard 8250-ports. The bug has been fixed by the commit 7b668c064ec3 ("serial: 8250: Fix max baud limit in generic 8250 port") by narrowing the baud rates limit back down to the normal bounds. Unfortunately by doing so we also broke the Mediatek-specific extended bauds feature. A fix of the problem described above is twofold. First since we can't get back the extended baud rate limits feature to the generic set_termios() function and that method supports only a standard baud rates range, the requested baud rate must be locally stored before calling it and then restored back to the new termios structure after the generic set_termios() finished its magic business. By doing so we still use the serial8250_do_set_termios() method to set the LCR/MCR/FCR/etc. registers, while the extended baud rate setting procedure will be performed later in the custom Mediatek-specific set_termios() callback. Second since a true baud rate is now fully calculated in the custom set_termios() method we need to locally update the port timeout by calling the uart_update_timeout() function. After the fixes described above are implemented in the 8250_mtk.c driver, the Mediatek 8250-port should get back to normally working with extended baud rates. Link: https://lore.kernel.org/linux-serial/20200701211337.3027448-1-danielwinkler@google.com Fixes: 7b668c064ec3 ("serial: 8250: Fix max baud limit in generic 8250 port") Reported-by: Daniel Winkler <danielwinkler@google.com> Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru> Cc: stable <stable@vger.kernel.org> Tested-by: Claire Chang <tientzu@chromium.org> Link: https://lore.kernel.org/r/20200714124113.20918-1-Sergey.Semin@baikalelectronics.ru Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-07-29serial: 8250: fix null-ptr-deref in serial8250_start_tx()Yang Yingliang
commit f4c23a140d80ef5e6d3d1f8f57007649014b60fa upstream. I got null-ptr-deref in serial8250_start_tx(): [ 78.114630] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 [ 78.123778] Mem abort info: [ 78.126560] ESR = 0x86000007 [ 78.129603] EC = 0x21: IABT (current EL), IL = 32 bits [ 78.134891] SET = 0, FnV = 0 [ 78.137933] EA = 0, S1PTW = 0 [ 78.141064] user pgtable: 64k pages, 48-bit VAs, pgdp=00000027d41a8600 [ 78.147562] [0000000000000000] pgd=00000027893f0003, p4d=00000027893f0003, pud=00000027893f0003, pmd=00000027c9a20003, pte=0000000000000000 [ 78.160029] Internal error: Oops: 86000007 [#1] SMP [ 78.164886] Modules linked in: sunrpc vfat fat aes_ce_blk crypto_simd cryptd aes_ce_cipher crct10dif_ce ghash_ce sha2_ce sha256_arm64 sha1_ce ses enclosure sg sbsa_gwdt ipmi_ssif spi_dw_mmio sch_fq_codel vhost_net tun vhost vhost_iotlb tap ip_tables ext4 mbcache jbd2 ahci hisi_sas_v3_hw libahci hisi_sas_main libsas hns3 scsi_transport_sas hclge libata megaraid_sas ipmi_si hnae3 ipmi_devintf ipmi_msghandler br_netfilter bridge stp llc nvme nvme_core xt_sctp sctp libcrc32c dm_mod nbd [ 78.207383] CPU: 11 PID: 23258 Comm: null-ptr Not tainted 5.8.0-rc6+ #48 [ 78.214056] Hardware name: Huawei TaiShan 2280 V2/BC82AMDC, BIOS 2280-V2 CS V3.B210.01 03/12/2020 [ 78.222888] pstate: 80400089 (Nzcv daIf +PAN -UAO BTYPE=--) [ 78.228435] pc : 0x0 [ 78.230618] lr : serial8250_start_tx+0x160/0x260 [ 78.235215] sp : ffff800062eefb80 [ 78.238517] x29: ffff800062eefb80 x28: 0000000000000fff [ 78.243807] x27: ffff800062eefd80 x26: ffff202fd83b3000 [ 78.249098] x25: ffff800062eefd80 x24: ffff202fd83b3000 [ 78.254388] x23: ffff002fc5e50be8 x22: 0000000000000002 [ 78.259679] x21: 0000000000000001 x20: 0000000000000000 [ 78.264969] x19: ffffa688827eecc8 x18: 0000000000000000 [ 78.270259] x17: 0000000000000000 x16: 0000000000000000 [ 78.275550] x15: ffffa68881bc67a8 x14: 00000000000002e6 [ 78.280841] x13: ffffa68881bc67a8 x12: 000000000000c539 [ 78.286131] x11: d37a6f4de9bd37a7 x10: ffffa68881cccff0 [ 78.291421] x9 : ffffa68881bc6000 x8 : ffffa688819daa88 [ 78.296711] x7 : ffffa688822a0f20 x6 : ffffa688819e0000 [ 78.302002] x5 : ffff800062eef9d0 x4 : ffffa68881e707a8 [ 78.307292] x3 : 0000000000000000 x2 : 0000000000000002 [ 78.312582] x1 : 0000000000000001 x0 : ffffa688827eecc8 [ 78.317873] Call trace: [ 78.320312] 0x0 [ 78.322147] __uart_start.isra.9+0x64/0x78 [ 78.326229] uart_start+0xb8/0x1c8 [ 78.329620] uart_flush_chars+0x24/0x30 [ 78.333442] n_tty_receive_buf_common+0x7b0/0xc30 [ 78.338128] n_tty_receive_buf+0x44/0x2c8 [ 78.342122] tty_ioctl+0x348/0x11f8 [ 78.345599] ksys_ioctl+0xd8/0xf8 [ 78.348903] __arm64_sys_ioctl+0x2c/0xc8 [ 78.352812] el0_svc_common.constprop.2+0x88/0x1b0 [ 78.357583] do_el0_svc+0x44/0xd0 [ 78.360887] el0_sync_handler+0x14c/0x1d0 [ 78.364880] el0_sync+0x140/0x180 [ 78.368185] Code: bad PC value SERIAL_PORT_DFNS is not defined on each arch, if it's not defined, serial8250_set_defaults() won't be called in serial8250_isa_init_ports(), so the p->serial_in pointer won't be initialized, and it leads a null-ptr-deref. Fix this problem by calling serial8250_set_defaults() after init uart port. Signed-off-by: Yang Yingliang <yangyingliang@huawei.com> Cc: stable <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20200721143852.4058352-1-yangyingliang@huawei.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-07-29serial: exar: Fix GPIO configuration for Sealevel cards based on XR17V35XMatthew Howell
[ Upstream commit 5fdbe136ae19ab751daaa4d08d9a42f3e30d17f9 ] Sealevel XR17V35X based devices are inoperable on kernel versions 4.11 and above due to a change in the GPIO preconfiguration introduced in commit 7dea8165f1d. This patch fixes this by preconfiguring the GPIO on Sealevel cards to the value (0x00) used prior to commit 7dea8165f1d With GPIOs preconfigured as per commit 7dea8165f1d all ports on Sealevel XR17V35X based devices become stuck in high impedance mode, regardless of dip-switch or software configuration. This causes the device to become effectively unusable. This patch (in various forms) has been distributed to our customers and no issues related to it have been reported. Fixes: 7dea8165f1d6 ("serial: exar: Preconfigure xr17v35x MPIOs as output") Signed-off-by: Matthew Howell <matthew.howell@sealevel.com> Link: https://lore.kernel.org/r/alpine.DEB.2.21.2007221605270.13247@tstest-VirtualBox Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-06-25serial: amba-pl011: Make sure we initialize the port.lock spinlockJohn Stultz
[ Upstream commit 8508f4cba308f785b2fd4b8c38849c117b407297 ] Valentine reported seeing: [ 3.626638] INFO: trying to register non-static key. [ 3.626639] the code is fine but needs lockdep annotation. [ 3.626640] turning off the locking correctness validator. [ 3.626644] CPU: 7 PID: 51 Comm: kworker/7:1 Not tainted 5.7.0-rc2-00115-g8c2e9790f196 #116 [ 3.626646] Hardware name: HiKey960 (DT) [ 3.626656] Workqueue: events deferred_probe_work_func [ 3.632476] sd 0:0:0:0: [sda] Optimal transfer size 8192 bytes not a multiple of physical block size (16384 bytes) [ 3.640220] Call trace: [ 3.640225] dump_backtrace+0x0/0x1b8 [ 3.640227] show_stack+0x20/0x30 [ 3.640230] dump_stack+0xec/0x158 [ 3.640234] register_lock_class+0x598/0x5c0 [ 3.640235] __lock_acquire+0x80/0x16c0 [ 3.640236] lock_acquire+0xf4/0x4a0 [ 3.640241] _raw_spin_lock_irqsave+0x70/0xa8 [ 3.640245] uart_add_one_port+0x388/0x4b8 [ 3.640248] pl011_register_port+0x70/0xf0 [ 3.640250] pl011_probe+0x184/0x1b8 [ 3.640254] amba_probe+0xdc/0x180 [ 3.640256] really_probe+0xe0/0x338 [ 3.640257] driver_probe_device+0x60/0xf8 [ 3.640259] __device_attach_driver+0x8c/0xd0 [ 3.640260] bus_for_each_drv+0x84/0xd8 [ 3.640261] __device_attach+0xe4/0x140 [ 3.640263] device_initial_probe+0x1c/0x28 [ 3.640265] bus_probe_device+0xa4/0xb0 [ 3.640266] deferred_probe_work_func+0x7c/0xb8 [ 3.640269] process_one_work+0x2c0/0x768 [ 3.640271] worker_thread+0x4c/0x498 [ 3.640272] kthread+0x14c/0x158 [ 3.640275] ret_from_fork+0x10/0x1c Which seems to be due to the fact that after allocating the uap structure, nothing initializes the spinlock. Its a little confusing, as uart_port_spin_lock_init() is one place where the lock is supposed to be initialized, but it has an exception for the case where the port is a console. This makes it seem like a deeper fix is needed to properly register the console, but I'm not sure what that entails, and Andy suggested that this approach is less invasive. Thus, this patch resolves the issue by initializing the spinlock in the driver, and resolves the resulting warning. Cc: Andy Shevchenko <andy.shevchenko@gmail.com> Cc: Russell King <linux@armlinux.org.uk> Cc: Jiri Slaby <jslaby@suse.com> Cc: linux-serial@vger.kernel.org Reported-by: Valentin Schneider <valentin.schneider@arm.com> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Signed-off-by: John Stultz <john.stultz@linaro.org> Reviewed-and-tested-by: Valentin Schneider <valentin.schneider@arm.com> Link: https://lore.kernel.org/r/20200428184050.6501-1-john.stultz@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-06-20serial: imx: Fix handling of TC irq in combination with DMAUwe Kleine-König
commit 1866541492641c02874bf51f9d8712b5510f2c64 upstream. When using RS485 half duplex the Transmitter Complete irq is needed to determine the moment when the transmitter can be disabled. When using DMA this irq must only be enabled when DMA has completed to transfer all data. Otherwise the CPU might busily trigger this irq which is not properly handled and so the also pending irq for the DMA transfer cannot trigger. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> [Backport to v4.14] Signed-off-by: Frieder Schrempf <frieder.schrempf@kontron.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-06-03sc16is7xx: move label 'err_spi' to correct sectionGuoqing Jiang
commit e00164a0f000de893944981f41a568c981aca658 upstream. err_spi is used when SERIAL_SC16IS7XX_SPI is enabled, so make the label only available under SERIAL_SC16IS7XX_SPI option. Otherwise, the below warning appears. drivers/tty/serial/sc16is7xx.c:1523:1: warning: label ‘err_spi’ defined but not used [-Wunused-label] err_spi: ^~~~~~~ Signed-off-by: Guoqing Jiang <gqjiang@suse.com> Fixes: ac0cdb3d9901 ("sc16is7xx: missing unregister/delete driver on error in sc16is7xx_init()") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Cc: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-05-02serial: sh-sci: Make sure status register SCxSR is read in correct sequenceKazuhiro Fujita
commit 3dc4db3662366306e54ddcbda4804acb1258e4ba upstream. For SCIF and HSCIF interfaces the SCxSR register holds the status of data that is to be read next from SCxRDR register, But where as for SCIFA and SCIFB interfaces SCxSR register holds status of data that is previously read from SCxRDR register. This patch makes sure the status register is read depending on the port types so that errors are caught accordingly. Cc: <stable@vger.kernel.org> Signed-off-by: Kazuhiro Fujita <kazuhiro.fujita.jg@renesas.com> Signed-off-by: Hao Bui <hao.bui.yg@renesas.com> Signed-off-by: KAZUMI HARADA <kazumi.harada.rh@renesas.com> Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> Tested-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://lore.kernel.org/r/1585333048-31828-1-git-send-email-kazuhiro.fujita.jg@renesas.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-03-11serial: 8250_exar: add support for ACCES cardsJay Dolan
commit 10c5ccc3c6d32f3d7d6c07de1d3f0f4b52f3e3ab upstream. Add ACCES VIDs and PIDs that use the Exar chips Signed-off-by: Jay Dolan <jay.dolan@accesio.com> Cc: stable <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20200305140504.22237-1-jay.dolan@accesio.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
generated by cgit 1.2.3-korg (git 2.39.0) at 2024-06-30 08:28:21 +0000