linux.git/drivers/tty/serial, branch v5.18

fsl_lpuart: Don't enable interrupts too early

2022-05-05T21:00:21+00:00

If an irq is pending when devm_request_irq() is called, the irq
handler will cause a NULL pointer access because initialisation
is not done yet.

Fixes: 9d7ee0e28da59 ("tty: serial: lpuart: avoid report NULL interrupt")
Cc: stable 
Signed-off-by: Indan Zupancic 
Link: https://lore.kernel.org/r/20220505114750.45423-1-Indan.Zupancic@mep-info.com
Signed-off-by: Greg Kroah-Hartman

serial: 8250_mtk: Fix register address for XON/XOFF character

2022-05-05T20:59:10+00:00

The XON1/XOFF1 character registers are at offset 0xa0 and 0xa8
respectively, so we cannot use the definition in serial_port.h.

Fixes: bdbd0a7f8f03 ("serial: 8250-mtk: modify baudrate setting")
Signed-off-by: AngeloGioacchino Del Regno 
Cc: stable 
Link: https://lore.kernel.org/r/20220427132328.228297-4-angelogioacchino.delregno@collabora.com
Signed-off-by: Greg Kroah-Hartman

serial: 8250_mtk: Make sure to select the right FEATURE_SEL

2022-05-05T20:59:10+00:00

Set the FEATURE_SEL at probe time to make sure that BIT(0) is enabled:
this guarantees that when the port is configured as AP UART, the
right register layout is interpreted by the UART IP.

Signed-off-by: AngeloGioacchino Del Regno 
Cc: stable 
Link: https://lore.kernel.org/r/20220427132328.228297-3-angelogioacchino.delregno@collabora.com
Signed-off-by: Greg Kroah-Hartman

serial: 8250_mtk: Fix UART_EFR register address

2022-05-05T20:59:10+00:00

On MediaTek SoCs, the UART IP is 16550A compatible, but there are some
specific quirks: we are declaring a register shift of 2, but this is
only valid for the majority of the registers, as there are some that
are out of the standard layout.

Specifically, this driver is using definitions from serial_reg.h, where
we have a UART_EFR register defined as 2: this results in a 0x8 offset,
but there we have the FCR register instead.

The right offset for the EFR register on MediaTek UART is at 0x98,
so, following the decimal definition convention in serial_reg.h and
accounting for the register left shift of two, add and use the correct
register address for this IP, defined as decimal 38, so that the final
calculation results in (0x26 << 2) = 0x98.

Fixes: bdbd0a7f8f03 ("serial: 8250-mtk: modify baudrate setting")
Signed-off-by: AngeloGioacchino Del Regno 
Cc: stable 
Link: https://lore.kernel.org/r/20220427132328.228297-2-angelogioacchino.delregno@collabora.com
Signed-off-by: Greg Kroah-Hartman

tty/serial: digicolor: fix possible null-ptr-deref in digicolor_uart_probe()

2022-05-05T20:58:36+00:00

It will cause null-ptr-deref when using 'res', if platform_get_resource()
returns NULL, so move using 'res' after devm_ioremap_resource() that
will check it to avoid null-ptr-deref.
And use devm_platform_get_and_ioremap_resource() to simplify code.

Fixes: 5930cb3511df ("serial: driver for Conexant Digicolor USART")
Signed-off-by: Yang Yingliang 
Reviewed-by: Baruch Siach 
Cc: stable 
Link: https://lore.kernel.org/r/20220505124621.1592697-1-yangyingliang@huawei.com
Signed-off-by: Greg Kroah-Hartman

serial: 8250: Correct the clock for EndRun PTP/1588 PCIe device

2022-04-22T14:38:10+00:00

The EndRun PTP/1588 dual serial port device is based on the Oxford
Semiconductor OXPCIe952 UART device with the PCI vendor:device ID set
for EndRun Technologies and is therefore driven by a fixed 62.5MHz clock
input derived from the 100MHz PCI Express clock.  The clock rate is
divided by the oversampling rate of 16 as it is supplied to the baud
rate generator, yielding the baud base of 3906250.

Replace the incorrect baud base of 4000000 with the right value of
3906250 then, complementing commit 6cbe45d8ac93 ("serial: 8250: Correct
the clock for OxSemi PCIe devices").

Signed-off-by: Maciej W. Rozycki 
Cc: stable 
Fixes: 1bc8cde46a159 ("8250_pci: Added driver for Endrun Technologies PTP PCIe card.")
Reviewed-by: Andy Shevchenko 
Link: https://lore.kernel.org/r/alpine.DEB.2.21.2204181515270.9383@angie.orcam.me.uk
Signed-off-by: Greg Kroah-Hartman

serial: 8250: Also set sticky MCR bits in console restoration

2022-04-22T14:38:06+00:00

Sticky MCR bits are lost in console restoration if console suspending
has been disabled.  This currently affects the AFE bit, which works in
combination with RTS which we set, so we want to make sure the UART
retains control of its FIFO where previously requested.  Also specific
drivers may need other bits in the future.

Signed-off-by: Maciej W. Rozycki 
Fixes: 4516d50aabed ("serial: 8250: Use canary to restart console after suspend")
Cc: stable@vger.kernel.org # v4.0+
Reviewed-by: Andy Shevchenko 
Link: https://lore.kernel.org/r/alpine.DEB.2.21.2204181518490.9383@angie.orcam.me.uk
Signed-off-by: Greg Kroah-Hartman

Revert "serial: sc16is7xx: Clear RS485 bits in the shutdown"

2022-04-22T14:37:00+00:00

This reverts commit 927728a34f11b5a27f4610bdb7068317d6fdc72a.

Once the uart_port->rs485->flag is set to SER_RS485_ENABLED, the port
should always work in RS485 mode. If users want the port to leave
RS485 mode, they need to call ioctl() to clear SER_RS485_ENABLED.

So here we shouldn't clear the RS485 bits in the shutdown().

Fixes: 927728a34f11 ("serial: sc16is7xx: Clear RS485 bits in the shutdown")
Signed-off-by: Hui Wang 
Link: https://lore.kernel.org/r/20220418094339.678144-1-hui.wang@canonical.com
Signed-off-by: Greg Kroah-Hartman

serial: 8250: Fix runtime PM for start_tx() for empty buffer

2022-04-15T09:42:09+00:00

Commit 932d596378b0 ("serial: 8250: Return early in .start_tx() if there
are no chars to send") caused a regression where the drivers implementing
runtime PM stopped idling. This is because serial8250_rpm_put_tx() is now
unbalanced on early return, it normally gets called at __stop_tx().

Fixes: 932d596378b0 ("serial: 8250: Return early in .start_tx() if there are no chars to send")
Cc: Steffen Trumtrar 
Cc: Uwe Kleine-König 
Reviewed-by: Johan Hovold 
Reviewed-by: Uwe Kleine-König 
Signed-off-by: Tony Lindgren 
Link: https://lore.kernel.org/r/20220411111657.16744-1-tony@atomide.com
Signed-off-by: Greg Kroah-Hartman

serial: imx: fix overrun interrupts in DMA mode

2022-04-15T09:41:58+00:00

Commit 76821e222c18 ("serial: imx: ensure that RX irqs are off if RX is
off") accidentally enabled overrun interrupts unconditionally when
deferring DMA enable until after the receiver has been enabled during
startup.

Fix this by using the DMA-initialised instead of DMA-enabled flag to
determine whether overrun interrupts should be enabled.

Note that overrun interrupts are already accounted for in
imx_uart_clear_rx_errors() when using DMA since commit 41d98b5da92f
("serial: imx-serial - update RX error counters when DMA is used").

Fixes: 76821e222c18 ("serial: imx: ensure that RX irqs are off if RX is off")
Cc: stable@vger.kernel.org      # 4.17
Cc: Uwe Kleine-König 
Signed-off-by: Johan Hovold 
Link: https://lore.kernel.org/r/20220411081957.7846-1-johan@kernel.org
Signed-off-by: Greg Kroah-Hartman