linux.git/drivers/tty/serial/8250, branch v5.10

serial: 8250_mtk: Fix uart_get_baud_rate warning

2020-11-06T16:23:03+00:00

Mediatek 8250 port supports speed higher than uartclk / 16. If the baud
rates in both the new and the old termios setting are higher than
uartclk / 16, the WARN_ON in uart_get_baud_rate() will be triggered.
Passing NULL as the old termios so uart_get_baud_rate() will use
uartclk / 16 - 1 as the new baud rate which will be replaced by the
original baud rate later by tty_termios_encode_baud_rate() in
mtk8250_set_termios().

Fixes: 551e553f0d4a ("serial: 8250_mtk: Fix high-speed baud rates clamping")
Signed-off-by: Claire Chang 
Link: https://lore.kernel.org/r/20201102120749.374458-1-tientzu@chromium.org
Cc: stable 
Signed-off-by: Greg Kroah-Hartman

serial: 8250_dw: Fix clk-notifier/port suspend deadlock

2020-09-30T12:52:42+00:00

It has been discovered that there is a potential deadlock between
the clock-change-notifier thread and the UART port suspending one:

   CPU0 (suspend CPU/UART)   CPU1 (update clock)
            ----                    ----
   lock(&port->mutex);
                             lock((work_completion)(&data->clk_work));
                             lock(&port->mutex);
   lock((work_completion)(&data->clk_work));

   *** DEADLOCK ***

The best way to fix this is to eliminate the CPU0
port->mutex/work-completion scenario. So we suggest to register and
unregister the clock-notifier during the DW APB UART port probe/remove
procedures, instead of doing that at the points of the port
startup/shutdown.

Link: https://lore.kernel.org/linux-serial/f1cd5c75-9cda-6896-a4e2-42c5bfc3f5c3@redhat.com

Fixes: cc816969d7b5 ("serial: 8250_dw: Fix common clocks usage race condition")
Reported-by: Hans de Goede 
Tested-by: Hans de Goede 
Signed-off-by: Serge Semin 
Link: https://lore.kernel.org/r/20200923161950.6237-4-Sergey.Semin@baikalelectronics.ru
Signed-off-by: Greg Kroah-Hartman

serial: 8250: Skip uninitialized TTY port baud rate update

2020-09-30T12:52:42+00:00

It is erroneous to update the TTY port baud rate if it hasn't been
initialized yet, because in that case the TTY struct isn't set. So there
is no termios structure to get and re-calculate the baud if the current
baud can't be reached. Let's skip the baud rate update then until the port
is fully initialized.

Note the update UART clock method still sets the uartclk member with a new
ref clock value even if the port is turned off. The new UART ref clock
rate will be used later on the port starting up procedure.

Fixes: 868f3ee6e452 ("serial: 8250: Add 8250 port clock update method")
Tested-by: Hans de Goede 
Signed-off-by: Serge Semin 
Link: https://lore.kernel.org/r/20200923161950.6237-3-Sergey.Semin@baikalelectronics.ru
Signed-off-by: Greg Kroah-Hartman

serial: 8250: Discard RTS/DTS setting from clock update method

2020-09-30T12:52:42+00:00

It has been a mistake to add the MCR register RTS/DTS fields setting in
the generic method of the UART reference clock update. There is no point
in asserting these lines at that procedure. Just discard the
serial8250_out_MCR() mathod invocation from there then.

Fixes: 868f3ee6e452 ("serial: 8250: Add 8250 port clock update method")
Tested-by: Hans de Goede 
Signed-off-by: Serge Semin 
Link: https://lore.kernel.org/r/20200923161950.6237-2-Sergey.Semin@baikalelectronics.ru
Signed-off-by: Greg Kroah-Hartman

serial: 8250_fsl: Fix TX interrupt handling condition

2020-09-30T12:31:04+00:00

This is the port of the commit db1b5bc047b3 ("serial: 8250: Fix TX
interrupt handling condition") to the 8250_fsl irq handling logic.

Interrupt handler checked THRE bit (transmitter holding register
empty) in LSR to detect if TX fifo is empty.
In case when there is only receive interrupts the TX handling
got called because THRE bit in LSR is set when there is no
transmission (FIFO empty). TX handling caused TX stop, which in
RS-485 half-duplex mode actually resets receiver FIFO. This is not
desired during reception because of possible data loss.

The fix is to check if THRI is set in IER in addition of the TX
fifo status. THRI in IER is set when TX is started and cleared
when TX is stopped.
This ensures that TX handling is only called when there is really
transmission on going and an interrupt for THRE and not when there
are only RX interrupts.

Signed-off-by: Andrij Abyzov 
Link: https://lore.kernel.org/r/20200928144127.87156-1-aabyzov@slb.com
Signed-off-by: Greg Kroah-Hartman

Merge 5.9.0-rc6 into tty-next

2020-09-21T07:23:55+00:00

We need the tty/serial fixes in here and this resolves a merge issue in
the 8250 driver.

Signed-off-by: Greg Kroah-Hartman

serial: 8250_pci: Add Realtek 816a and 816b

2020-09-16T11:23:33+00:00

These serial ports are exposed by the OOB-management-engine on
RealManage-enabled network cards (e.g. AMD DASH enabled systems using
Realtek cards).

Because these have 3 BARs, they fail the "num_iomem <= 1" check in
serial_pci_guess_board.

I've manually checked the two IOMEM regions and BAR 2 doesn't seem to
respond to reads, but BAR 4 seems to be an MMIO version of the IO ports
(untested).

With this change, the ports are detected:
0000:02:00.1: ttyS0 at I/O 0x2200 (irq = 82, base_baud = 115200) is a 16550A
0000:02:00.2: ttyS1 at I/O 0x2100 (irq = 55, base_baud = 115200) is a 16550A

lspci output:
02:00.1 0700: 10ec:816a (rev 0e) (prog-if 02 [16550])
        Subsystem: 17aa:5082
        Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
        Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort+ SERR- 
Cc: stable 
Link: https://lore.kernel.org/r/20200914173628.GA22508@yamamaya.is-a-geek.org
Signed-off-by: Greg Kroah-Hartman

tty: serial: 8250_mtk: set regshift for mmio32

2020-09-16T11:17:17+00:00

To use mmio32, we also need to set regshift.

Signed-off-by: Hsin-Yi Wang 
Acked-by: Eddie Huang 
Link: https://lore.kernel.org/r/20200915054825.3289105-2-hsinyi@chromium.org
Signed-off-by: Greg Kroah-Hartman

serial: 8250_pci: Remove unused function get_pci_irq()

2020-09-16T11:14:50+00:00

It is not used since commit 8428413b1d14 ("serial: 8250_pci: Implement MSI(-X) support")

Signed-off-by: YueHaibing 
Link: https://lore.kernel.org/r/20200909135103.17768-1-yuehaibing@huawei.com
Signed-off-by: Greg Kroah-Hartman

serial: 8250_fsl: Add ACPI support

2020-09-04T15:17:17+00:00

This adds support for ACPI enumerated FSL 16550 UARTs.
For supporting ACPI, I added a wrapper so that this driver
can be used if firmware has exposed the HID "NXP0018" in
DSDT table.

This will be built as object file if config "SERIAL_8250_FSL"
is enabled which depends on config "SERIAL_8250_CONSOLE".

Signed-off-by: kuldip dwivedi 
Link: https://lore.kernel.org/r/20200903113402.12371-1-kuldip.dwivedi@puresoftware.com
Signed-off-by: Greg Kroah-Hartman