linux.git/drivers/tty/serial/8250, branch v4.11

serial: 8250_EXAR: fix duplicate Kconfig text and add missing help text

2017-03-31T15:26:20+00:00

In commit d0aeaa83f0b0f7a92615bbdd6b1f96812f7dcfd2 ("serial: exar:
split out the exar code from 8250_pci") the exar driver got its own
Kconfig.  However the text for the new option was never changed from
the original 8250_PCI text, and hence it appears confusing when you
get asked the same question twice:

  8250/16550 PCI device support (SERIAL_8250_PCI) [Y/n/m/?] (NEW)
    8250/16550 PCI device support (SERIAL_8250_EXAR) [Y/n/m] (NEW)

Adding to the confusion, is that there is no help text for this new
option to indicate it is specific to a certain family of cards.

Fix both issues at the same time, as well as the space vs. tab issues
introduced in the same commit.

Fixes: d0aeaa83f0b0 ("serial: exar: split out the exar code from 8250_pci")
Cc: Jiri Slaby 
Cc: linux-serial@vger.kernel.org
Signed-off-by: Paul Gortmaker 
Acked-by: Sudip Mukherjee 
Reviewed-by: Andy Shevchenko 
Signed-off-by: Greg Kroah-Hartman

serial: 8250_dw: Fix breakage when HAVE_CLK=n

2017-03-14T02:48:11+00:00

Commit 6a171b299379 ("serial: 8250_dw: Allow hardware flow control to be
used") recently broke the 8250_dw driver on platforms which don't select
HAVE_CLK, as dw8250_set_termios() gets confused by the behaviour of the
fallback HAVE_CLK=n clock API in linux/clk.h which pretends everything
is fine but returns (valid) NULL clocks and 0 HZ clock rates.

That 0 rate is written into the uartclk resulting in a crash at boot,
e.g. on Cavium Octeon III based UTM-8 we get something like this:

1180000000800.serial: ttyS0 at MMIO 0x1180000000800 (irq = 41, base_baud = 25000000) is a OCTEON
------------[ cut here ]------------
WARNING: CPU: 2 PID: 1 at drivers/tty/serial/serial_core.c:441 uart_get_baud_rate+0xfc/0x1f0
...
Call Trace:
...
[] uart_get_baud_rate+0xfc/0x1f0
[] serial8250_do_set_termios+0xb0/0x440
[] uart_set_options+0xe8/0x190
[] serial8250_console_setup+0x84/0x158
[] univ8250_console_setup+0x54/0x70
[] register_console+0x1c8/0x418
[] uart_add_one_port+0x434/0x4b0
[] serial8250_register_8250_port+0x2d8/0x440
[] dw8250_probe+0x388/0x5e8
...

The clock API is defined such that NULL is a valid clock handle so it
wouldn't be right to check explicitly for NULL. Instead treat a
clk_round_rate() return value of 0 as an error which prevents uartclk
being overwritten.

Fixes: 6a171b299379 ("serial: 8250_dw: Allow hardware flow control to be used")
Signed-off-by: James Hogan 
Cc: Kefeng Wang 
Cc: David Daney 
Cc: Russell King 
Cc: linux-serial@vger.kernel.org
Cc: linux-clk@vger.kernel.org
Cc: linux-mips@linux-mips.org
Cc: bcm-kernel-feedback-list@broadcom.com
Reviewed-by: Andy Shevchenko 
Reviewed-by: Jason Uy 
Reviewed-by: Heiko Stuebner 
Signed-off-by: Greg Kroah-Hartman

serial: 8250_dw: Honor clk_round_rate errors in dw8250_set_termios

2017-03-14T02:48:11+00:00

clk_round_rate returns a signed long and may possibly return errors
in it, for example if there is no possible rate.

Till now dw8250_set_termios ignored any error, the signednes and would
just use the value as input to clk_set_rate. This of course falls apart
if there is an actual error, so check for errors and only try to set
a rate if the value is actually valid.

This turned up on some Rockchip platforms after commit
6a171b299379 ("serial: 8250_dw: Allow hardware flow control to be used")
enabled set_termios callback in all cases, not only ACPI.

Fixes: 6a171b299379 ("serial: 8250_dw: Allow hardware flow control to be used")
Signed-off-by: Heiko Stuebner 
Reviewed-by: Andy Shevchenko 
Signed-off-by: Greg Kroah-Hartman

serial: exar: Enable MSI support

2017-02-10T14:13:26+00:00

Use pci_alloc_irq_vectors to enable MSI when available. At least the
XR17V352 supports this.

Signed-off-by: Jan Kiszka 
Reviewed-by: Andy Shevchenko 
Signed-off-by: Greg Kroah-Hartman

serial: exar: Move register defines from uapi header to consumer site

2017-02-10T14:13:26+00:00

None of these registers is relevant for the userspace API.

Signed-off-by: Jan Kiszka 
Signed-off-by: Greg Kroah-Hartman

serial: pci: Remove unused pci_boards entries

2017-02-10T14:12:39+00:00

Became obsolete with the split-out of 8250_exar.

Signed-off-by: Jan Kiszka 
Signed-off-by: Greg Kroah-Hartman

serial: exar: Move Commtech adapters to 8250_exar as well

2017-02-10T14:12:38+00:00

Those are Exar-based, too.

With the required refactoring of the code to fit into 8250_exar, we
automatically fix the same issue pci_xr17v35x_setup had before: 8XMODE,
FCTL, TXTRG and RXTRG were always only set for port 0. Now they are
initialized for the correct target port by using port.membase.

Now we can also cleanly fix the blacklist of 8250_pci so that all
Commtech devices are rejected and 8250_exar can handle them.

Signed-off-by: Jan Kiszka 
Reviewed-by: Andy Shevchenko 
Signed-off-by: Greg Kroah-Hartman

serial: exar: Fix initialization of EXAR registers for ports > 0

2017-02-10T14:12:38+00:00

So far, pci_xr17v35x_setup always initialized 8XMODE, FCTR & Co. for
port 0 because it used the address of that port instead of moving the
pointer according to the port number. Fix this and remove the unneeded
temporary ioremap by moving default_setup up and reusing the membase it
fills into the port structure.

Fixes: 14faa8cce88e ("tty/8250 Add support for Commtech's Fastcom Async-335 and Fastcom Async-PCIe cards")
Signed-off-by: Jan Kiszka 
Reviewed-by: Andy Shevchenko 
Signed-off-by: Greg Kroah-Hartman

serial: exar: Fix mapping of port I/O resources

2017-02-10T14:12:38+00:00

pcim_iomap_table only returns the table of mapping, it does not perform
them. For that, we need to call pcim_iomap, but only if that mapping was
not done before.

Fixes: d0aeaa83f0b0 ("serial: exar: split out the exar code from 8250_pci")
Signed-off-by: Jan Kiszka 
Reviewed-by: Andy Shevchenko 
Signed-off-by: Greg Kroah-Hartman

serial: 8250_dw: Avoid "too much work" from bogus rx timeout interrupt

2017-02-10T14:10:16+00:00

On a Rockchip rk3399-based board during suspend/resume testing, we
found that we could get the console UART into a state where it would
print this to the console a lot:
  serial8250: too much work for irq42

Followed eventually by:
  NMI watchdog: BUG: soft lockup - CPU#0 stuck for 11s!

Upon debugging I found that we're in this state:
  iir = 0x000000cc
  lsr = 0x00000060

It appears that somehow we have a RX Timeout interrupt but there is no
actual data present to receive.  When we're in this state the UART
driver claims that it handled the interrupt but it actually doesn't
really do anything.  This means that we keep getting the interrupt
over and over again.

Normally we don't actually need to do anything special to handle a RX
Timeout interrupt.  We'll notice that there is some data ready and
we'll read it, which will end up clearing the RX Timeout.  In this
case we have a problem specifically because we got the RX TImeout
without any data.  Reading a bogus byte is confirmed to get us out of
this state.

It's unclear how exactly the UART got into this state, but it is known
that the UART lines are essentially undriven and unpowered during
suspend, so possibly during resume some garbage / half transmitted
bits are seen on the line and put the UART into this state.

The UART on the rk3399 is a DesignWare based 8250 UART.  From mailing
list posts, it appears that other people have run into similar
problems with DesignWare based IP.  Presumably this problem is unique
to that IP, so I have placed the workaround there to avoid possibly of
accidentally triggering bad behavior on other IP.  Also note the RX
Timeout behaves very differently in the DMA case, for for now the
workaround is only applied to the non-DMA case.

Signed-off-by: Douglas Anderson 
Signed-off-by: Greg Kroah-Hartman