linux-stable.git/drivers/tty/serial/serial_core.c, branch linux-6.5.y

serial: core: Fix runtime PM handling for pending tx

2023-11-08T13:09:07+00:00

commit 6f699743aebf07538e506a46c5965eb8bdd2c716 upstream.

Richard reported that a serial port may end up sometimes with tx data
pending in the buffer for long periods of time.

Turns out we bail out early on any errors from pm_runtime_get(),
including -EINPROGRESS. To fix the issue, we need to ignore -EINPROGRESS
as we only care about the runtime PM usage count at this point. We check
for an active runtime PM state later on for tx.

Fixes: 84a9582fd203 ("serial: core: Start managing serial controllers to enable runtime PM")
Cc: stable 
Reported-by: Richard Purdie 
Cc: Bruce Ashfield 
Cc: Mikko Rapeli 
Cc: Paul Gortmaker 
Cc: Randy MacLeod 
Signed-off-by: Tony Lindgren 
Tested-by: Richard Purdie 
Link: https://lore.kernel.org/r/20231023074856.61896-1-tony@atomide.com
Signed-off-by: Greg Kroah-Hartman

serial: core: Fix checks for tx runtime PM state

2023-10-19T21:11:04+00:00

commit 81a61051e0ce5fd7e09225c0d5985da08c7954a7 upstream.

Maximilian reported that surface_serial_hub serdev tx does not work during
system suspend. During system suspend, runtime PM gets disabled in
__device_suspend_late(), and tx is unable to wake-up the serial core port
device that we use to check if tx is safe to start. Johan summarized the
regression noting that serdev tx no longer always works as earlier when the
serdev device is runtime PM active.

The serdev device and the serial core controller devices are siblings of
the serial port hardware device. The runtime PM usage count from serdev
device does not propagate to the serial core device siblings, it only
propagates to the parent.

In addition to the tx issue for suspend, testing for the serial core port
device can cause an unnecessary delay in enabling tx while waiting for the
serial core port device to wake-up. The serial core port device wake-up is
only needed to flush pending tx when the serial port hardware device was
in runtime PM suspended state.

To fix the regression, we need to check the runtime PM state of the parent
serial port hardware device for tx instead of the serial core port device.

As the serial port device drivers may or may not implement runtime PM, we
need to also add a check for pm_runtime_enabled().

Reported-by: Maximilian Luz 
Cc: stable 
Fixes: 84a9582fd203 ("serial: core: Start managing serial controllers to enable runtime PM")
Signed-off-by: Tony Lindgren 
Tested-by: Maximilian Luz 
Reviewed-by: Andy Shevchenko 
Link: https://lore.kernel.org/r/20231005075644.25936-1-tony@atomide.com
Signed-off-by: Greg Kroah-Hartman

serial: Reduce spinlocked portion of uart_rs485_config()

2023-10-19T21:11:04+00:00

commit 8679328eb859d06a1984ab48d90ac35d11bbcaf1 upstream.

Commit 44b27aec9d96 ("serial: core, 8250: set RS485 termination GPIO in
serial core") enabled support for RS485 termination GPIOs behind i2c
expanders by setting the GPIO outside of the critical section protected
by the port spinlock.  Access to the i2c expander may sleep, which
caused a splat with the port spinlock held.

Commit 7c7f9bc986e6 ("serial: Deassert Transmit Enable on probe in
driver-specific way") erroneously regressed that by spinlocking the
GPIO manipulation again.

Fix by moving uart_rs485_config() (the function manipulating the GPIO)
outside of the spinlocked section and acquiring the spinlock inside of
uart_rs485_config() for the invocation of ->rs485_config() only.

This gets us one step closer to pushing the spinlock down into the
->rs485_config() callbacks which actually need it.  (Some callbacks
do not want to be spinlocked because they perform sleepable register
accesses, see e.g. sc16is7xx_config_rs485().)

Stack trace for posterity:

 Voluntary context switch within RCU read-side critical section!
 WARNING: CPU: 0 PID: 56 at kernel/rcu/tree_plugin.h:318 rcu_note_context_switch
 Call trace:
 rcu_note_context_switch
 __schedule
 schedule
 schedule_timeout
 wait_for_completion_timeout
 bcm2835_i2c_xfer
 __i2c_transfer
 i2c_transfer
 i2c_transfer_buffer_flags
 regmap_i2c_write
 _regmap_raw_write_impl
 _regmap_bus_raw_write
 _regmap_write
 _regmap_update_bits
 regmap_update_bits_base
 pca953x_gpio_set_value
 gpiod_set_raw_value_commit
 gpiod_set_value_nocheck
 gpiod_set_value_cansleep
 uart_rs485_config
 uart_add_one_port
 pl011_register_port
 pl011_probe

Fixes: 7c7f9bc986e6 ("serial: Deassert Transmit Enable on probe in driver-specific way")
Suggested-by: Lino Sanfilippo 
Signed-off-by: Lukas Wunner 
Cc: stable@vger.kernel.org # v6.1+
Link: https://lore.kernel.org/r/f3a35967c28b32f3c6432d0aa5936e6a9908282d.1695307688.git.lukas@wunner.de
Signed-off-by: Greg Kroah-Hartman

serial: core: Fix error handling for serial_core_ctrl_device_add()

2023-06-02T07:30:55+00:00

Checking for NULL is incorrect as serial_base_ctrl_add() uses ERR_PTR().

Let's also pass any returned error along, there's no reason to translate
all errors to -ENODEV.

Fixes: 84a9582fd203 ("serial: core: Start managing serial controllers to enable runtime PM")
Signed-off-by: Tony Lindgren 
Reviewed-by: Jiri Slaby 
Link: https://lore.kernel.org/r/20230602070007.59268-1-tony@atomide.com
Signed-off-by: Greg Kroah-Hartman

serial: core: Don't drop port_mutex in serial_core_remove_one_port

2023-06-01T13:04:01+00:00

Commit 84a9582fd203 ("serial: core: Start managing serial controllers to
enable runtime PM") required the caller to hold port_mutex rather than
taking it locally. However the mutex_unlock() call wasn't removed
causing the mutex to be dropped unexpectly. Remove the call to
mutex_unlock() (and fix up the early return) to restore correct
behaviour.

Fixes: 84a9582fd203 ("serial: core: Start managing serial controllers to enable runtime PM")
Signed-off-by: Steven Price 
Reviewed-by: Tony Lindgren 
Link: https://lore.kernel.org/r/20230601105548.29965-1-steven.price@arm.com
Signed-off-by: Greg Kroah-Hartman

serial: core: Start managing serial controllers to enable runtime PM

2023-05-31T09:46:59+00:00

We want to enable runtime PM for serial port device drivers in a generic
way. To do this, we want to have the serial core layer manage the
registered physical serial controller devices.

To manage serial controllers, let's set up a struct bus and struct device
for the serial core controller as suggested by Greg and Jiri. The serial
core controller devices are children of the physical serial port device.
The serial core controller device is needed to support multiple different
kind of ports connected to single physical serial port device.

Let's also set up a struct device for the serial core port. The serial
core port instances are children of the serial core controller device.

With the serial core port device we can now flush pending TX on the
runtime PM resume as suggested by Johan.

Suggested-by: Andy Shevchenko 
Suggested-by: Greg Kroah-Hartman 
Suggested-by: Jiri Slaby 
Suggested-by: Johan Hovold 
Signed-off-by: Tony Lindgren 
Reviewed-by: Andy Shevchenko 
Link: https://lore.kernel.org/r/20230525113034.46880-1-tony@atomide.com
Signed-off-by: Greg Kroah-Hartman

serial: core: lock port for start_rx() in uart_resume_port()

2023-05-30T10:45:42+00:00

The only user of the start_rx() callback (qcom_geni) directly calls
its own stop_rx() callback. Since stop_rx() requires that the
port->lock is taken and interrupts are disabled, the start_rx()
callback has the same requirement.

Fixes: cfab87c2c271 ("serial: core: Introduce callback for start_rx and do stop_rx in suspend only if this callback implementation is present.")
Signed-off-by: John Ogness 
Reviewed-by: Douglas Anderson 
Link: https://lore.kernel.org/r/20230525093159.223817-5-john.ogness@linutronix.de
Signed-off-by: Greg Kroah-Hartman

serial: core: lock port for stop_rx() in uart_suspend_port()

2023-05-30T10:45:42+00:00

The uarts_ops stop_rx() callback expects that the port->lock is
taken and interrupts are disabled.

Fixes: c9d2325cdb92 ("serial: core: Do stop_rx in suspend path for console if console_suspend is disabled")
Signed-off-by: John Ogness 
Reviewed-by: Douglas Anderson 
Link: https://lore.kernel.org/r/20230525093159.223817-3-john.ogness@linutronix.de
Signed-off-by: Greg Kroah-Hartman

serial: Make uart_remove_one_port() return void

2023-05-13T10:48:16+00:00

The return value is only ever used as a return value for remove callbacks
of platform drivers. This return value is ignored by the driver core.
(The only effect is an error message, but uart_remove_one_port() already
emitted one in this case.)

So the return value isn't used at all and uart_remove_one_port() can be
changed to return void without any loss. Also this better matches the
Linux device model as remove functions are not supposed to fail.

Signed-off-by: Uwe Kleine-König 
Link: https://lore.kernel.org/r/20230512173810.131447-3-u.kleine-koenig@pengutronix.de
Signed-off-by: Greg Kroah-Hartman

serial: core: Disable uart_start() on uart_remove_one_port()

2023-04-20T11:43:44+00:00

While rebinding a uart device in a loop I noticed we may see a tx related
race on uart_remove_one_port():

uart_write from n_tty_write
n_tty_write from file_tty_write.constprop.0
file_tty_write.constprop.0 from vfs_write
vfs_write from ksys_write
ksys_write from ret_fast_syscall

Let's disallow tx on port->UPF_DEAD. This flag gets set before we start
tearing down the port in uart_remove_one_port().

Signed-off-by: Tony Lindgren 
Link: https://lore.kernel.org/r/20230419115423.59957-1-tony@atomide.com
Signed-off-by: Greg Kroah-Hartman