linux.git/drivers/tty/serial/8250, branch v6.5

serial: 8250: drop lockdep annotation from serial8250_clear_IER()

2023-08-11T19:19:18+00:00

The port lock is not always held when calling serial8250_clear_IER().
When an oops is in progress, the lock is tried to be taken and when it
is not, a warning is issued:
 WARNING: CPU: 0 PID: 1 at drivers/tty/serial/8250/8250_port.c:707 	+0x57/0x60
 Modules linked in:
 CPU: 0 PID: 1 Comm: init Not tainted 6.5.0-rc5-1.g225bfb7-default+ #774 00f1be860db663ed29479b8255d3b01ab1135bd3
 Hardware name: QEMU Standard PC ...
 RIP: 0010:serial8250_clear_IER+0x57/0x60
...
 Call Trace:
  
  serial8250_console_write+0x9e/0x4b0
  console_flush_all+0x217/0x5f0
...

Therefore, remove the annotation as it doesn't hold for all invocations.

The other option would be to make the lockdep test conditional on
'oops_in_progress' or pass 'locked' from serial8250_console_write(). I
don't think, that is worth it.

Signed-off-by: "Jiri Slaby (SUSE)" 
Reported-by: Vlastimil Babka 
Cc: John Ogness 
Fixes: d0b309a5d3f4 (serial: 8250: synchronize and annotate UART_IER access)
Link: https://lore.kernel.org/r/20230811064340.13400-1-jirislaby@kernel.org
Signed-off-by: Greg Kroah-Hartman

serial: 8250: Fix oops for port->pm on uart_change_pm()

2023-08-04T15:14:38+00:00

Unloading a hardware specific 8250 driver can produce error "Unable to
handle kernel paging request at virtual address" about ten seconds after
unloading the driver. This happens on uart_hangup() calling
uart_change_pm().

Turns out commit 04e82793f068 ("serial: 8250: Reinit port->pm on port
specific driver unbind") was only a partial fix. If the hardware specific
driver has initialized port->pm function, we need to clear port->pm too.
Just reinitializing port->ops does not do this. Otherwise serial8250_pm()
will call port->pm() instead of serial8250_do_pm().

Fixes: 04e82793f068 ("serial: 8250: Reinit port->pm on port specific driver unbind")
Signed-off-by: Tony Lindgren 
Link: https://lore.kernel.org/r/20230804131553.52927-1-tony@atomide.com
Signed-off-by: Greg Kroah-Hartman

serial: 8250: Reinit port_id when adding back serial8250_isa_devs

2023-08-04T13:11:59+00:00

After fixing the serial core port device to use port->port_id instead of
port->line, unloading a hardware specific 8250 port driver started
producing an error for "sysfs: cannot create duplicate filename".

This is happening as we are wrongly initializing port->port_id to zero
when adding back serial8250_isa_devs instances, and the serial8250:0.0
sysfs entry may already exist. For serial8250 devices, we typically have
multiple devices mapped to a single driver instance. For the
serial8250_isa_devs instances, the port->port_id is the same as port->line.

Let's fix the issue by re-initializing port_id when adding back the
serial8250_isa_devs instances in serial8250_unregister_port().

Fixes: d962de6ae51f ("serial: core: Fix serial core port id to not use port->line")
Signed-off-by: Tony Lindgren 
Link: https://lore.kernel.org/r/20230804123546.25293-1-tony@atomide.com
Signed-off-by: Greg Kroah-Hartman

serial: core: Fix serial core port id to not use port->line

2023-08-01T05:48:55+00:00

The serial core port id should be serial core controller specific port
instance, which is not always the port->line index.

For example, 8250 driver maps a number of legacy ports, and when a
hardware specific device driver takes over, we typically have one
driver instance for each port. Let's instead add port->port_id to
keep track serial ports mapped to each serial core controller instance.

Currently this is only a cosmetic issue for the serial core port device
names. The issue can be noticed looking at /sys/bus/serial-base/devices
for example though. Let's fix the issue to avoid port addressing issues
later on.

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

serial: 8250_dw: Preserve original value of DLF register

2023-07-25T18:31:31+00:00

Preserve the original value of the Divisor Latch Fraction (DLF) register.
When the DLF register is modified without preservation, it can disrupt
the baudrate settings established by firmware or bootloader, leading to
data corruption and the generation of unreadable or distorted characters.

Fixes: 701c5e73b296 ("serial: 8250_dw: add fractional divisor support")
Cc: stable 
Signed-off-by: Ruihong Luo 
Link: https://lore.kernel.org/stable/20230713004235.35904-1-colorsu1922%40gmail.com
Reviewed-by: Ilpo Järvinen 
Reviewed-by: Andy Shevchenko 
Link: https://lore.kernel.org/r/20230713004235.35904-1-colorsu1922@gmail.com
Signed-off-by: Greg Kroah-Hartman

Revert "8250: add support for ASIX devices with a FIFO bug"

2023-06-21T15:55:53+00:00

This reverts commit eb26dfe8aa7eeb5a5aa0b7574550125f8aa4c3b3.

Commit eb26dfe8aa7e ("8250: add support for ASIX devices with a FIFO
bug") merged on Jul 13, 2012 adds a quirk for PCI_VENDOR_ID_ASIX
(0x9710). But that ID is the same as PCI_VENDOR_ID_NETMOS defined in
1f8b061050c7 ("[PATCH] Netmos parallel/serial/combo support") merged
on Mar 28, 2005. In pci_serial_quirks array, the NetMos entry always
takes precedence over the ASIX entry even since it was initially
merged, code in that commit is always unreachable.

In my tests, adding the FIFO workaround to pci_netmos_init() makes no
difference, and the vendor driver also does not have such workaround.
Given that the code was never used for over a decade, it's safe to
revert it.

Also, the real PCI_VENDOR_ID_ASIX should be 0x125b, which is used on
their newer AX99100 PCIe serial controllers released on 2016. The FIFO
workaround should not be intended for these newer controllers, and it
was never implemented in vendor driver.

Fixes: eb26dfe8aa7e ("8250: add support for ASIX devices with a FIFO bug")
Cc: stable 
Signed-off-by: Jiaqing Zhao 
Reviewed-by: Andy Shevchenko 
Link: https://lore.kernel.org/r/20230619155743.827859-1-jiaqing.zhao@linux.intel.com
Signed-off-by: Greg Kroah-Hartman

serial: 8250_omap: Use force_suspend and resume for system suspend

2023-06-15T10:20:49+00:00

We should not rely on autosuspend timeout for system suspend. Instead,
let's use force_suspend and force_resume functions. Otherwise the serial
port controller device may not be idled on suspend.

As we are doing a register write on suspend to configure the serial port,
we still need to runtime PM resume the port on suspend.

While at it, let's switch to pm_runtime_resume_and_get() and check for
errors returned. And let's add the missing line break before return to the
suspend function while at it.

Fixes: 09d8b2bdbc5c ("serial: 8250: omap: Provide ability to enable/disable UART as wakeup source")
Signed-off-by: Tony Lindgren 
Tested-by: Dhruva Gole 
Message-ID: <20230614045922.4798-1-tony@atomide.com>
Signed-off-by: Greg Kroah-Hartman

serial: 8250: Apply FSL workarounds also without SERIAL_8250_CONSOLE

2023-06-13T10:27:05+00:00

The need to handle the FSL variant of 8250 in a special way is also
present without console support. So soften the dependency for
SERIAL_8250_FSL from SERIAL_8250_CONSOLE to SERIAL_8250. To handle
SERIAL_8250=m, the FSL code can be modular, too, thus SERIAL_8250_FSL
becomes tristate.

Compiling 8250_fsl as a module requires adding a module license so this
is added, too. While add it also add a appropriate module description.

As then SERIAL_OF_PLATFORM=y + SERIAL_8250_FSL=m is a valid combination
(if COMPILE_TEST is enabled on a platform that is neither PPC, ARM nor
ARM64), the check in 8250_of.c must be weakened a bit.

Signed-off-by: Uwe Kleine-König 
Reviewed-by: Andy Shevchenko 
Message-ID: <20230609133932.786117-3-u.kleine-koenig@pengutronix.de>
Signed-off-by: Greg Kroah-Hartman

serial: 8250_mtk: Simplify clock sequencing and runtime PM

2023-06-06T12:43:13+00:00

The 8250_mtk driver's runtime PM support has some issues:

- The bus clock is enabled (through runtime PM callback) later than a
  register write
- runtime PM resume callback directly called in probe, but no
  pm_runtime_set_active() call is present
- UART PM function calls the callbacks directly, _and_ calls runtime
  PM API
- runtime PM callbacks try to do reference counting, adding yet another
  count between runtime PM and clocks

This fragile setup worked in a way, but broke recently with runtime PM
support added to the serial core. The system would hang when the UART
console was probed and brought up.

Tony provided some potential fixes [1][2], though they were still a bit
complicated. The 8250_dw driver, which the 8250_mtk driver might have
been based on, has a similar structure but simpler runtime PM usage.

Simplify clock sequencing and runtime PM support in the 8250_mtk driver.
Specifically, the clock is acquired enabled and assumed to be active,
unless toggled through runtime PM suspend/resume. Reference counting is
removed and left to the runtime PM core. The serial pm function now
only calls the runtime PM API.

[1] https://lore.kernel.org/linux-serial/20230602092701.GP14287@atomide.com/
[2] https://lore.kernel.org/linux-serial/20230605061511.GW14287@atomide.com/

Fixes: 84a9582fd203 ("serial: core: Start managing serial controllers to enable runtime PM")
Suggested-by: Tony Lindgren 
Signed-off-by: Chen-Yu Tsai 
Reviewed-by: AngeloGioacchino Del Regno 
Reviewed-by: Tony Lindgren 
Message-ID: <20230606091747.2031168-1-wenst@chromium.org>
Signed-off-by: Greg Kroah-Hartman

Merge 6.4-rc5 into tty-next

2023-06-05T05:41:04+00:00

We need the tty fixes in here as well.

Signed-off-by: Greg Kroah-Hartman