linux.git/drivers/tty/serial/serial_core.c, branch v6.10

Revert "serial: core: Add support for DEVNAME:0.0 style naming for kernel console"

2024-06-25T05:58:00+00:00

This reverts commit 787a1cabac01c99846070fcf702e53befaf89f79.

Let's roll back all of the serial core and printk console changes that
went into 6.10-rc1 as there still are problems with them that need to be
sorted out.

Link: https://lore.kernel.org/r/ZnpRozsdw6zbjqze@tlindgre-MOBL1
Reported-by: Petr Mladek 
Reported-by: Tony Lindgren 
Cc: Jiri Slaby 
Cc: John Ogness 
Cc: Sergey Senozhatsky 
Cc: Andy Shevchenko 
Cc: Ilpo Järvinen 
Signed-off-by: Greg Kroah-Hartman

serial: drop debugging WARN_ON_ONCE() from uart_write()

2024-06-04T12:10:43+00:00

syzbot is reporting lockdep warning upon

  int disc = 7;
  ioctl(open("/dev/ttyS3", O_RDONLY), TIOCSETD, &disc);

sequence. Do like what commit 5f1149d2f4bf ("serial: drop debugging
WARN_ON_ONCE() from uart_put_char()") does.

Reported-by: syzbot+f78380e4eae53c64125c@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=f78380e4eae53c64125c
Signed-off-by: Tetsuo Handa 
Acked-by: Jiri Slaby 
Link: https://lore.kernel.org/r/d775ae2d-a2ac-439e-8e2b-134749f60f30@I-love.SAKURA.ne.jp
Signed-off-by: Greg Kroah-Hartman

serial: Clear UPF_DEAD before calling tty_port_register_device_attr_serdev()

2024-05-10T10:49:23+00:00

If a serdev_device_driver is already loaded for a serdev_tty_port when it
gets registered by tty_port_register_device_attr_serdev() then that
driver's probe() method will be called immediately.

The serdev_device_driver's probe() method should then be able to call
serdev_device_open() successfully, but because UPF_DEAD is still dead
serdev_device_open() will fail with -ENXIO in this scenario:

  serdev_device_open()
  ctrl->ops->open()	/* this callback being ttyport_open() */
  tty->ops->open()	/* this callback being uart_open() */
  tty_port_open()
  port->ops->activate()	/* this callback being uart_port_activate() */
  Find bit UPF_DEAD is set in uport->flags and fail with errno -ENXIO.

Fix this be clearing UPF_DEAD before tty_port_register_device_attr_serdev()
note this only moves up the UPD_DEAD clearing a small bit, before:

  tty_port_register_device_attr_serdev();
  mutex_unlock(&tty_port.mutex);
  uart_port.flags &= ~UPF_DEAD;
  mutex_unlock(&port_mutex);

after:

  uart_port.flags &= ~UPF_DEAD;
  tty_port_register_device_attr_serdev();
  mutex_unlock(&tty_port.mutex);
  mutex_unlock(&port_mutex);

Reported-by: Weifeng Liu 
Closes: https://lore.kernel.org/platform-driver-x86/20240505130800.2546640-1-weifeng.liu.z@gmail.com/
Tested-by: Weifeng Liu 
Signed-off-by: Hans de Goede 
Link: https://lore.kernel.org/r/20240509141549.63704-1-hdegoede@redhat.com
Signed-off-by: Greg Kroah-Hartman

serial: core: Call device_set_awake_path() for console port

2024-05-04T16:11:58+00:00

In case the UART port is used as a console, no_console_suspend is
available in bootargs and UART port is part of a software-controlled power
domain we need to call device_set_awake_path(). This lets the power
domain core code know that this domain should not be powered off
during system suspend. Otherwise, the UART port power domain is turned off,
nothing is printed while suspending and the suspend/resume process is
blocked. This was detected on the Renesas RZ/G3S SoC while adding support
for power domains.

Based on code investigation (on v6.9-rc5), this issue is present on other
SoCs (e.g., Renesas R-Mobile A1 [1], IMX8QXP [2]) and different SoCs have
particular implementation to handle it. Due to this the patch added the
call of device_set_awake_path() in uart_suspend_port() instead of having
it in the platform specific UART driver.

[1] drivers/pmdomain/renesas/rmobile-sysc.c:116
[2] drivers/pmdomain/imx/scu-pd.c:357

Suggested-by: Ulf Hansson 
Suggested-by: Geert Uytterhoeven 
Reviewed-by: Ulf Hansson 
Reviewed-by: Andy Shevchenko 
Reviewed-by: Tony Lindgren 
Reviewed-by: Geert Uytterhoeven 
Tested-by: Geert Uytterhoeven 
Signed-off-by: Claudiu Beznea 
Link: https://lore.kernel.org/r/20240430095930.2806067-1-claudiu.beznea.uj@bp.renesas.com
Signed-off-by: Greg Kroah-Hartman

Merge 6.9-rc5 into tty-next

2024-04-23T11:24:45+00:00

We want the tty fixes in here as well, and it resolves a merge conflict
in:
	drivers/tty/serial/serial_core.c
as well.

Signed-off-by: Greg Kroah-Hartman

serial: core: Extract uart_alloc_xmit_buf() and uart_free_xmit_buf()

2024-04-17T11:10:51+00:00

After conversion to the kfifo, it becomes possible to extract two helper
functions for better maintenance and code deduplication. Do it here.

Signed-off-by: Andy Shevchenko 
Link: https://lore.kernel.org/r/20240409174057.1104262-1-andriy.shevchenko@linux.intel.com
Signed-off-by: Greg Kroah-Hartman

serial: drop debugging WARN_ON_ONCE() from uart_put_char()

2024-04-17T11:09:52+00:00

Pengfei Xu reports, that the -next commit 1788cf6a91d9 (tty: serial:
switch from circ_buf to kfifo) tries to emit a WARNING and that leads to
lockdep errors. Obviously we cannot print anything from uart_put_char()!

This WARN_ON_ONCE() was/is a debug aid to check if the condition in
uart_put_char() can happen at all. Pengfei Xu confirmed it can. Unlike
me and kbuild bot in my queue.

Second, I completely forgot about it, so I did not remove it in the
final version, nor mentioned it in the commit log.

Drop it now as we are all good. And we even have stack traces (and a
reproducer)!

Signed-off-by: Jiri Slaby (SUSE) 
Reported-by: Pengfei Xu 
Link: https://lore.kernel.org/r/20240416071904.21440-1-jirislaby@kernel.org
Signed-off-by: Greg Kroah-Hartman

serial: core: Fix missing shutdown and startup for serial base port

2024-04-11T12:21:11+00:00

We are seeing start_tx being called after port shutdown as noted by Jiri.
This happens because we are missing the startup and shutdown related
functions for the serial base port.

Let's fix the issue by adding startup and shutdown functions for the
serial base port to block tx flushing for the serial base port when the
port is not in use.

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

serial: core: Clearing the circular buffer before NULLifying it

2024-04-09T15:00:10+00:00

The circular buffer is NULLified in uart_tty_port_shutdown()
under the spin lock. However, the PM or other timer based callbacks
may still trigger after this event without knowning that buffer pointer
is not valid. Since the serial code is a bit inconsistent in checking
the buffer state (some rely on the head-tail positions, some on the
buffer pointer), it's better to have both aligned, i.e. buffer pointer
to be NULL and head-tail possitions to be the same, meaning it's empty.
This will prevent asynchronous calls to dereference NULL pointer as
reported recently in 8250 case:

  BUG: kernel NULL pointer dereference, address: 00000cf5
  Workqueue: pm pm_runtime_work
  EIP: serial8250_tx_chars (drivers/tty/serial/8250/8250_port.c:1809)
  ...
  ? serial8250_tx_chars (drivers/tty/serial/8250/8250_port.c:1809)
  __start_tx (drivers/tty/serial/8250/8250_port.c:1551)
  serial8250_start_tx (drivers/tty/serial/8250/8250_port.c:1654)
  serial_port_runtime_suspend (include/linux/serial_core.h:667 drivers/tty/serial/serial_port.c:63)
  __rpm_callback (drivers/base/power/runtime.c:393)
  ? serial_port_remove (drivers/tty/serial/serial_port.c:50)
  rpm_suspend (drivers/base/power/runtime.c:447)

The proposed change will prevent ->start_tx() to be called during
suspend on shut down port.

Fixes: 43066e32227e ("serial: port: Don't suspend if the port is still busy")
Cc: stable 
Reported-by: kernel test robot 
Closes: https://lore.kernel.org/oe-lkp/202404031607.2e92eebe-lkp@intel.com
Signed-off-by: Andy Shevchenko 
Link: https://lore.kernel.org/r/20240404150034.41648-1-andriy.shevchenko@linux.intel.com
Signed-off-by: Greg Kroah-Hartman

serial: core: Fix regression when runtime PM is not enabled

2024-04-09T13:56:50+00:00

Commit 45a3a8ef8129 ("serial: core: Revert checks for tx runtime PM state")
caused a regression for Sun Ultra 60 for the sunsab driver as reported by
Nick Bowler .

We need to add back the check runtime PM enabled state for serial port
controller device, I wrongly assumed earlier we could just remove it.

Fixes: 45a3a8ef8129 ("serial: core: Revert checks for tx runtime PM state")
Cc: stable 
Reported-by: Nick Bowler 
Signed-off-by: Tony Lindgren 
Link: https://lore.kernel.org/r/20240325071649.27040-1-tony@atomide.com
Signed-off-by: Greg Kroah-Hartman