user/sven/linux.git/drivers/tty/serial, branch v6.7.2

serial: apbuart: fix console prompt on qemu

2024-01-25T23:45:24Z

[ Upstream commit c6dcd8050fb7c2efec6946ae9c49bc186b0a7475 ] When using a leon kernel with qemu there where no console prompt. The root cause is the handling of the fifo size in the tx part of the apbuart driver. The qemu uart driver only have a very rudimentary status handling and do not report the number of chars queued in the tx fifo in the status register. So the driver ends up with a fifo size of 1. In the tx path the fifo size is divided by 2 - resulting in a fifo size of zero. The original implementation would always try to send one char, but after the introduction of uart_port_tx_limited() the fifo size is respected even for the first char. There seems to be no good reason to divide the fifo size with two - so remove this. It looks like something copied from the original amba driver. With qemu we now have a minimum fifo size of one char, so we show the prompt. Signed-off-by: Sam Ravnborg Fixes: d11cc8c3c4b6 ("tty: serial: use uart_port_tx_limited()") Cc: Andreas Larsson Cc: Greg Kroah-Hartman Cc: Jiri Slaby Cc: Cc: Link: https://lore.kernel.org/r/20231226121607.GA2622970@ravnborg.org Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin

serial: imx: Correct clock error message in function probe()

2024-01-25T23:45:24Z

[ Upstream commit 3e189470cad27d41a3a9dc02649f965b7ed1c90f ] Correct the clock error message by changing the clock name. Fixes: 1e512d45332b ("serial: imx: add error messages when .probe fails") Signed-off-by: Christoph Niedermaier Reviewed-by: Uwe Kleine-König Link: https://lore.kernel.org/r/20231224093209.2612-1-cniedermaier@dh-electronics.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin

serial: imx: fix tx statemachine deadlock

2024-01-25T23:45:21Z

[ Upstream commit 78d60dae9a0c9f09aa3d6477c94047df2fe6f7b0 ] When using the serial port as RS485 port, the tx statemachine is used to control the RTS pin to drive the RS485 transceiver TX_EN pin. When the TTY port is closed in the middle of a transmission (for instance during userland application crash), imx_uart_shutdown disables the interface and disables the Transmission Complete interrupt. afer that, imx_uart_stop_tx bails on an incomplete transmission, to be retriggered by the TC interrupt. This interrupt is disabled and therefore the tx statemachine never transitions out of SEND. The statemachine is in deadlock now, and the TX_EN remains low, making the interface useless. imx_uart_stop_tx now checks for incomplete transmission AND whether TC interrupts are enabled before bailing to be retriggered. This makes sure the state machine handling is reached, and is properly set to WAIT_AFTER_SEND. Fixes: cb1a60923609 ("serial: imx: implement rts delaying for rs485") Signed-off-by: Paul Geurts Tested-by: Rasmus Villemoes Tested-by: Eberhard Stoll Link: https://lore.kernel.org/r/AM0PR09MB26758F651BC1B742EB45775995B8A@AM0PR09MB2675.eurprd09.prod.outlook.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin

serial: 8250: omap: Don't skip resource freeing if pm_runtime_resume_and_get() failed

2024-01-25T23:45:20Z

[ Upstream commit ad90d0358bd3b4554f243a425168fc7cebe7d04e ] Returning an error code from .remove() makes the driver core emit the little helpful error message: remove callback returned a non-zero value. This will be ignored. and then remove the device anyhow. So all resources that were not freed are leaked in this case. Skipping serial8250_unregister_port() has the potential to keep enough of the UART around to trigger a use-after-free. So replace the error return (and with it the little helpful error message) by a more useful error message and continue to cleanup. Fixes: e3f0c638f428 ("serial: 8250: omap: Fix unpaired pm_runtime_put_sync() in omap8250_remove()") Signed-off-by: Uwe Kleine-König Reviewed-by: Tony Lindgren Link: https://lore.kernel.org/r/20231110152927.70601-2-u.kleine-koenig@pengutronix.de Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin

serial: sc16is7xx: set safe default SPI clock frequency

2024-01-25T23:45:17Z

commit 3ef79cd1412236d884ab0c46b4d1921380807b48 upstream. 15 MHz is supported only by 76x variants. If the SPI clock frequency is not specified, use a safe default clock value of 4 MHz that is supported by all variants. Also use HZ_PER_MHZ macro to improve readability. Fixes: 2c837a8a8f9f ("sc16is7xx: spi interface is added") Cc: Signed-off-by: Hugo Villeneuve Link: https://lore.kernel.org/r/20231221231823.2327894-4-hugo@hugovil.com Signed-off-by: Greg Kroah-Hartman

serial: sc16is7xx: add check for unsupported SPI modes during probe

2024-01-25T23:45:17Z

commit 6d710b769c1f5f0d55c9ad9bb49b7dce009ec103 upstream. The original comment is confusing because it implies that variants other than the SC16IS762 supports other SPI modes beside SPI_MODE_0. Extract from datasheet: The SC16IS762 differs from the SC16IS752 in that it supports SPI clock speeds up to 15 Mbit/s instead of the 4 Mbit/s supported by the SC16IS752... In all other aspects, the SC16IS762 is functionally and electrically the same as the SC16IS752. The same is also true of the SC16IS760 variant versus the SC16IS740 and SC16IS750 variants. For all variants, only SPI mode 0 is supported. Change comment and abort probing if the specified SPI mode is not SPI_MODE_0. Fixes: 2c837a8a8f9f ("sc16is7xx: spi interface is added") Cc: Signed-off-by: Hugo Villeneuve Link: https://lore.kernel.org/r/20231221231823.2327894-3-hugo@hugovil.com Signed-off-by: Greg Kroah-Hartman

serial: omap: do not override settings for RS485 support

2024-01-25T23:45:12Z

commit 51f93776b84dee23e44a7be880736669a01cec2b upstream. The drivers RS485 support is deactivated if there is no RTS GPIO available. This is done by nullifying the ports rs485_supported struct. After that however the settings in serial_omap_rs485_supported are assigned to the same structure unconditionally, which results in an unintended reactivation of RS485 support. Fix this by moving the assignment to the beginning of serial_omap_probe_rs485() and thus before uart_get_rs485_mode() gets called. Also replace the assignment of rs485_config() to have the complete RS485 setup in one function. Fixes: e2752ae3cfc9 ("serial: omap: Disallow RS-485 if rts-gpio is not specified") Cc: Signed-off-by: Lino Sanfilippo Reviewed-by: Ilpo Järvinen Link: https://lore.kernel.org/r/20240103061818.564-7-l.sanfilippo@kunbus.com Signed-off-by: Greg Kroah-Hartman

serial: 8250_exar: Set missing rs485_supported flag

2024-01-25T23:45:12Z

commit 0c2a5f471ce58bca8f8ab5fcb911aff91eaaa5eb upstream. The UART supports an auto-RTS mode in which the RTS pin is automatically activated during transmission. So mark this mode as being supported even if RTS is not controlled by the driver but the UART. Also the serial core expects now at least one of both modes rts-on-send or rts-after-send to be supported. This is since during sanitization unsupported flags are deleted from a RS485 configuration set by userspace. However if the configuration ends up with both flags unset, the core prints a warning since it considers such a configuration invalid (see uart_sanitize_serial_rs485()). Cc: Reviewed-by: Ilpo Järvinen Signed-off-by: Lino Sanfilippo Link: https://lore.kernel.org/r/20240103061818.564-8-l.sanfilippo@kunbus.com Signed-off-by: Greg Kroah-Hartman

serial: imx: Ensure that imx_uart_rs485_config() is called with enabled clock

2024-01-25T23:45:12Z

commit 7c45eaa813476bd195ac1227a64b52f9cf2e2030 upstream. There are register accesses in the function imx_uart_rs485_config(). The clock must be enabled for these accesses. This was ensured by calling it via the function uart_rs485_config() in the probe() function within the range where the clock is enabled. With the commit 7c7f9bc986e6 ("serial: Deassert Transmit Enable on probe in driver-specific way") it was removed from the probe() function and is now only called through the function uart_add_one_port() which is located at the end of the probe() function. But the clock is already switched off in this area. To ensure that the clock is enabled during register access, move the disabling of the clock to the very end of the probe() function. To avoid leaking enabled clocks on error also add an error path for exiting with disabling the clock. Fixes: 7c7f9bc986e6 ("serial: Deassert Transmit Enable on probe in driver-specific way") Cc: stable Signed-off-by: Christoph Niedermaier Reviewed-by: Lukas Wunner Link: https://lore.kernel.org/r/20231226113647.39376-1-cniedermaier@dh-electronics.com Signed-off-by: Greg Kroah-Hartman

serial: core, imx: do not set RS485 enabled if it is not supported

2024-01-25T23:45:12Z

commit 74eab89b26ac433ad857292f4707b43c1a8f0209 upstream. If the imx driver cannot support RS485 it nullifies the ports rs485_supported structure. But it still calls uart_get_rs485_mode() which may set the RS485_ENABLED flag nevertheless. This may lead to an attempt to configure RS485 even if it is not supported when the flag is evaluated in uart_configure_port() at port startup. Avoid this by bailing out of uart_get_rs485_mode() if the RS485_ENABLED flag is not supported by the caller. With this fix a check for RTS availability is now obsolete in the imx driver, since it can not evaluate to true any more. So remove this check. Furthermore the explicit nullifcation of rs485_supported is not needed, since the memory has already been set to zeros at allocation. So remove this, too. Fixes: 00d7a00e2a6f ("serial: imx: Fill in rs485_supported") Cc: Shawn Guo Cc: Sascha Hauer Cc: Suggested-by: Uwe Kleine-König Signed-off-by: Lino Sanfilippo Reviewed-by: Ilpo Järvinen Link: https://lore.kernel.org/r/20240103061818.564-6-l.sanfilippo@kunbus.com Signed-off-by: Greg Kroah-Hartman