linux-stable.git/drivers/tty/serial/8250, branch linux-4.16.y

serial: 8250: omap: Fix idling of clocks for unused uarts

2018-06-16T07:43:44+00:00

commit 13dc04d0e5fdc25c8f713ad23fdce51cf2bf96ba upstream.

I noticed that unused UARTs won't necessarily idle properly always
unless at least one byte tx transfer is done first.

After some debugging I narrowed down the problem to the scr register
dma configuration bits that need to be set before softreset for the
clocks to idle. Unless we do this, the module clkctrl idlest bits
may be set to 1 instead of 3 meaning the clock will never idle and
is blocking deeper idle states for the whole domain.

This might be related to the configuration done by the bootloader
or kexec booting where certain configurations cause the 8250 or
the clkctrl clock to jam in a way where setting of the scr bits
and reset is needed to clear it. I've tried diffing the 8250
registers for the various modes, but did not see anything specific.
So far I've only seen this on omap4 but I'm suspecting this might
also happen on the other clkctrl using SoCs considering they
already have a quirk enabled for UART_ERRATA_CLOCK_DISABLE.

Let's fix the issue by configuring scr before reset for basic dma
even if we don't use it. The scr register will be reset when we do
softreset few lines after, and we restore scr on resume. We should
do this for all the SoCs with UART_ERRATA_CLOCK_DISABLE quirk flag
set since the ones with UART_ERRATA_CLOCK_DISABLE are all based
using clkctrl similar to omap4.

Looks like both OMAP_UART_SCR_DMAMODE_1 | OMAP_UART_SCR_DMAMODE_CTL
bits are needed for the clkctrl to idle after a softreset.

And we need to add omap4 to also use the UART_ERRATA_CLOCK_DISABLE
for the related workaround to be enabled. This same compatible
value will also be used for omap5.

Fixes: cdb929e4452a ("serial: 8250_omap: workaround errata around idling UART after using DMA")
Cc: Keerthy 
Cc: Matthijs van Duin 
Cc: Sekhar Nori 
Cc: Tero Kristo 
Signed-off-by: Tony Lindgren 
Cc: stable 
Signed-off-by: Greg Kroah-Hartman

serial: 8250: Don't service RX FIFO if interrupts are disabled

2018-05-25T14:46:19+00:00

[ Upstream commit 2e9fe539108320820016f78ca7704a7342788380 ]

Currently, data in RX FIFO is read based on UART_LSR register state even
if RDI and RLSI interrupts are disabled in UART_IER register.
This is because when IRQ handler is called due to TX FIFO empty event,
RX FIFO is serviced based on UART_LSR register status instead of
UART_IIR status. This defeats the purpose of disabling UART RX
FIFO interrupts during throttling(see, omap_8250_throttle()) as IRQ
handler continues to drain UART RX FIFO resulting in overflow of buffer
at tty layer.
Fix this by making sure that driver drains UART RX FIFO only when
UART_IIR_RDI is set along with UART_LSR_BI or UART_LSR_DR bits.

Signed-off-by: Vignesh R 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

serial: 8250: Add Nuvoton NPCM UART

2018-04-08T12:29:49+00:00

commit f597fbce38d230af95384f4a04e0a13a1d0ad45d upstream.

The Nuvoton UART is almost compatible with the 8250 driver when probed
via the 8250_of driver, however it requires some extra configuration
at startup.

Reviewed-by: Rob Herring 
Signed-off-by: Joel Stanley 
Cc: stable 
Signed-off-by: Greg Kroah-Hartman

serial: 8250_pci: Add Brainboxes UC-260 4 port serial device

2018-02-28T12:48:21+00:00

Add PCI ids for two variants of Brainboxes UC-260 quad port
PCI serial cards.

Suggested-by: Andy Shevchenko 
Signed-off-by: Nikola Ciprich 
Cc: stable 
Signed-off-by: Greg Kroah-Hartman

serial: 8250_pci: Don't fail on multiport card class

2018-02-28T12:48:21+00:00

Do not fail on multiport cards in serial_pci_is_class_communication().

It restores behaviour for SUNIX multiport cards, that enumerated by
class and have a custom board data.

Moreover it allows users to reenumerate port-by-port from user space.

Fixes: 7d8905d06405 ("serial: 8250_pci: Enable device after we check black list")
Reported-by: Nikola Ciprich 
Signed-off-by: Andy Shevchenko 
Tested-by: Nikola Ciprich 
Signed-off-by: Greg Kroah-Hartman

tty: serial: exar: Relocate sleep wake-up handling

2018-01-25T11:44:50+00:00

Exar sleep wake-up handling has been done on a per-channel basis by
virtue of INT0 being accessible from each channel's address space. I
believe this was initially done out of necessity, but now that Exar
devices have their own driver, we can do things more efficiently by
registering a dedicated INT0 handler at the PCI device level.

I see this change providing the following benefits:

    1. If more than one port is active, eliminates the redundant bus
       cycles for reading INT0 on every interrupt.
    2. This note associated with hooking in the per-channel handler in
       8250_port.c is resolved:
        /* Fixme: probably not the best place for this */

Cc: Matt Schulte 
Signed-off-by: Aaron Sierra 
Signed-off-by: Greg Kroah-Hartman

serial: 8250_dw: Revert "Improve clock rate setting"

2018-01-22T13:13:40+00:00

The commit

  de9e33bdfa22 ("serial: 8250_dw: Improve clock rate setting")

obviously tries to cure symptoms, and not a root cause.

The root cause is the non-flexible rate calculation inside the
corresponding clock driver. What we need is to provide maximum UART
divisor value to the clock driver to allow it do the job transparently
to the caller.

Since from the initial commit message I have got no clue which clock
driver actually needs to be amended, I leave this exercise to the people
who know better the case.

Moreover, it seems [1] the fix introduced a regression. And possible
even one more [2].

Taking above, revert the commit de9e33bdfa22 for now.

[1]: https://www.spinics.net/lists/linux-serial/msg28872.html
[2]: https://github.com/Dunedan/mbp-2016-linux/issues/29#issuecomment-357583782

Fixes: de9e33bdfa22 ("serial: 8250_dw: Improve clock rate setting")
Cc: stable  # 4.15
Cc: Ed Blake 
Cc: Heikki Krogerus 
Cc: Lukas Wunner 
Signed-off-by: Andy Shevchenko 
Signed-off-by: Greg Kroah-Hartman

serial: 8250_ingenic: Parse earlycon options

2018-01-09T15:49:14+00:00

In the devicetree, it is possible to specify the baudrate, parity,
bits, flow of the early console, by passing a configuration string like
this:

aliases {
	serial0 = &uart0;
};

chosen {
	stdout-path = "serial0:57600n8";
};

This, for instance, will configure the early console for a baudrate of
57600 bps, no parity, and 8 bits per baud.

This patches implements parsing of this configuration string in the
8250_ingenic driver, which previously just ignored it.

Signed-off-by: Paul Cercueil 
Signed-off-by: Greg Kroah-Hartman

serial: 8250_ingenic: Add support for the JZ4770 SoC

2018-01-09T15:49:14+00:00

The JZ4770 SoC's UART is no different from the other JZ SoCs, so this
commit simply adds the ingenic,jz4770-uart compatible string.

Signed-off-by: Paul Cercueil 
Acked-by: Rob Herring 
Signed-off-by: Greg Kroah-Hartman

serial: 8250_of: fix return code when probe function fails to get reset

2018-01-09T15:46:26+00:00

The error pointer from devm_reset_control_get_optional_shared() is
not propagated.

One of the most common problem scenarios is it returns -EPROBE_DEFER
when the reset controller has not probed yet.  In this case, the
probe of the reset consumer should be deferred.

Fixes: e2860e1f62f2 ("serial: 8250_of: Add reset support")
Cc: stable@vger.kernel.org # v4.13+
Signed-off-by: Masahiro Yamada 
Reviewed-by: Philipp Zabel 
Signed-off-by: Greg Kroah-Hartman