linux/drivers/tty/serial/8250/8250_port.c, branch v5.2-rc1

Merge tag 'tty-4.21-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty

2018-12-29T04:33:54Z

Pull tty/serial driver updates from Greg KH: "Here is the large TTY/Serial driver set of patches for 4.21-rc1. A number of small serial driver changes along with some good tty core fixes for long-reported issues with locking. There is also a new console font added to the tree, for high-res screens, so that should be helpful for many. The last patch in the series is a revert of an older one in the tree, it came late but it resolves a reported issue that linux-next was having for some people. Full details are in the shortlog, and all of these, with the exception of the revert, have been in linux-next for a while with no reported issues" * tag 'tty-4.21-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty: (85 commits) Revert "serial: 8250: Default SERIAL_OF_PLATFORM to SERIAL_8250" serial: sccnxp: Allow to use non-standard baud rates serial: sccnxp: Adds a delay between sequential read/write cycles tty: serial: qcom_geni_serial: Fix UART hang tty: serial: qcom_geni_serial: Fix wrap around of TX buffer serial: max310x: Fix tx_empty() callback dt-bindings: serial: sh-sci: Document r8a774c0 bindings dt-bindings: serial: sh-sci: Document r8a774a1 bindings Fonts: New Terminus large console font dt-bindings: serial: lpuart: add imx8qxp compatible string serial: uartps: Fix interrupt mask issue to handle the RX interrupts properly serial: uartps: Fix error path when alloc failed serial: uartps: Check if the device is a console serial: uartps: Add the device_init_wakeup tty: serial: samsung: Increase maximum baudrate tty: serial: samsung: Properly set flags in autoCTS mode tty: Use of_node_name_{eq,prefix} for node name comparisons tty/serial: do not free trasnmit buffer page under port lock serial: 8250: Rate limit serial port rx interrupts during input overruns dt-bindings: serial: 8250: Add rate limit for serial port input overruns ...

Revert "serial: 8250: Fix clearing FIFOs in RS485 mode again"

2018-12-17T15:18:29Z

Commit f6aa5beb45be ("serial: 8250: Fix clearing FIFOs in RS485 mode again") makes a change to FIFO clearing code which its commit message suggests was intended to be specific to use with RS485 mode, however: 1) The change made does not just affect __do_stop_tx_rs485(), it also affects other uses of serial8250_clear_fifos() including paths for starting up, shutting down or auto-configuring a port regardless of whether it's an RS485 port or not. 2) It makes the assumption that resetting the FIFOs is a no-op when FIFOs are disabled, and as such it checks for this case & explicitly avoids setting the FIFO reset bits when the FIFO enable bit is clear. A reading of the PC16550D manual would suggest that this is OK since the FIFO should automatically be reset if it is later enabled, but we support many 16550-compatible devices and have never required this auto-reset behaviour for at least the whole git era. Starting to rely on it now seems risky, offers no benefit, and indeed breaks at least the Ingenic JZ4780's UARTs which reads garbage when the RX FIFO is enabled if we don't explicitly reset it. 3) By only resetting the FIFOs if they're enabled, the behaviour of serial8250_do_startup() during boot now depends on what the value of FCR is before the 8250 driver is probed. This in itself seems questionable and leaves us with FCR=0 & no FIFO reset if the UART was used by 8250_early, otherwise it depends upon what the bootloader left behind. 4) Although the naming of serial8250_clear_fifos() may be unclear, it is clear that callers of it expect that it will disable FIFOs. Both serial8250_do_startup() & serial8250_do_shutdown() contain comments to that effect, and other callers explicitly re-enable the FIFOs after calling serial8250_clear_fifos(). The premise of that patch that disabling the FIFOs is incorrect therefore seems wrong. For these reasons, this reverts commit f6aa5beb45be ("serial: 8250: Fix clearing FIFOs in RS485 mode again"). Signed-off-by: Paul Burton Fixes: f6aa5beb45be ("serial: 8250: Fix clearing FIFOs in RS485 mode again"). Cc: Greg Kroah-Hartman Cc: Daniel Jedrychowski Cc: Marek Vasut Cc: linux-mips@vger.kernel.org Cc: linux-serial@vger.kernel.org Cc: stable # 4.10+ Signed-off-by: Greg Kroah-Hartman

serial: 8250: Process sysrq at port unlock time

2018-11-09T17:07:18Z

Let's take advantage of the new ("serial: core: Allow processing sysrq at port unlock time") to handle sysrqs more cleanly. Signed-off-by: Douglas Anderson Signed-off-by: Greg Kroah-Hartman

serial: 8250: Fix clearing FIFOs in RS485 mode again

2018-09-18T14:07:25Z

The 8250 FIFOs indeed need to be cleared after stopping transmission in RS485 mode without SER_RS485_RX_DURING_TX flag set. But there are two problems with the approach taken by the previous patch from Fixes tag. First, serial8250_clear_fifos() should clear fifos, but what it really does is it enables the FIFOs unconditionally if present, clears them and then sets the FCR register to zero, which effectively disables the FIFOs. In case the FIFO is disabled, enabling it and clearing it makes no sense and in fact can trigger misbehavior of the 8250 core. Moreover, the FCR register may contain other FIFO configuration bits which may not be writable unconditionally and writing them incorrectly can trigger misbehavior of the 8250 core too. (ie. AM335x UART swallows the first byte and retransmits the last byte twice because of this FCR write). Second, serial8250_clear_and_reinit_fifos() completely reloads the FCR, but what really has to happen at the end of the RS485 transmission is clearing of the FIFOs and nothing else. This patch repairs serial8250_clear_fifos() so that it really only clears the FIFOs by operating on FCR[2:1] bits and leaves all the other bits alone. It also undoes serial8250_clear_and_reinit_fifos() from __do_stop_tx_rs485() as serial8250_clear_fifos() is sufficient. Signed-off-by: Marek Vasut Fixes: 2bed8a8e7072 ("Clearing FIFOs in RS485 emulation mode causes subsequent transmits to break") Cc: Daniel Jedrychowski Cc: Greg Kroah-Hartman Cc: stable # let it bake a bit before merging Signed-off-by: Greg Kroah-Hartman

tty: serial: 8250: Revert NXP SC16C2552 workaround

2018-08-12T16:53:30Z

Revert commit ecb988a3b7985913d1f0112f66667cdd15e40711: tty: serial: 8250: 8250_core: NXP SC16C2552 workaround The above commit causes userland application to no longer write correctly its first write to a dumb terminal connected to /dev/ttyS0. This commit seems to be the culprit. It's as though the TX FIFO is being reset during that write. What should be displayed is: PSW 80000000 INST 00000000 HALT // What is displayed is some variation of: T 00000000 HAL// Reverting this commit via this patch fixes my problem. Signed-off-by: Mark Hounschell Fixes: ecb988a3b798 ("tty: serial: 8250: 8250_core: NXP SC16C2552 workaround") Cc: stable Signed-off-by: Greg Kroah-Hartman

serial: 8250: Use cached port name directly in messages

2018-07-25T10:51:23Z

Since we have port name stored in struct uart_port, we better to use that one instead of open coding. This will make it one place source for easier maintenance or modifications. While here, replace printk_ratelimited(KERN_INFO ) by pr_info_ratelimited(). It seems last printk() call in 8250_port.c. Signed-off-by: Andy Shevchenko Signed-off-by: Greg Kroah-Hartman

serial: 8250: export serial8250_do_set_divisor()

2018-07-12T15:07:26Z

Some drivers could call serial8250_do_set_divisor() to complete its own set_divisor routine. Export this symbol for code reusing. Signed-off-by: Jisheng Zhang Reviewed-by: Andy Shevchenko Signed-off-by: Greg Kroah-Hartman

serial: 8250: introduce get_divisor() and set_divisor() hook

2018-07-12T15:07:26Z

Add these two hooks so that they can be overridden with driver specific implementations. Signed-off-by: Jisheng Zhang Reviewed-by: Andy Shevchenko Signed-off-by: Greg Kroah-Hartman

serial: 8250: let serial8250_get_divisor() get uart_port * as param

2018-07-06T14:45:38Z

Align serial8250_get_divisor() with serial8250_set_divisor() to accept uart_port pointer as the first parameter. No functionality changes. Signed-off-by: Jisheng Zhang Reviewed-by: Andy Shevchenko Signed-off-by: Greg Kroah-Hartman

serial: 8250: Add missing rxtrig_bytes on Altera 16550 UART

2018-05-14T11:51:11Z

The Altera 16550 UART core supports FCR Rx Trigger Level setting, but the port definition in the driver is missing the rxtrig_bytes array specifying the trigger levels. Add the array to make the Rx Trigger Level setting available on this type of 16550 UART. Signed-off-by: Marek Vasut Cc: Thor Thayer Signed-off-by: Greg Kroah-Hartman