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

serial: 8250_lpss: Unconditionally set PCI master for Quark

2017-06-24T05:06:16+00:00

commit 7cd3e9dbdd4c0025d0e37c8c73a2ac8641fc55bc upstream.

MSI needs it as well.

Should have no practical impact, though, as DMA is always available on
the Quark. But given the few users of pci_alloc_irq_vectors so far, this
incorrect pattern may spread otherwise.

Fixes: 3f3a46951e02 ("serial: 8250_lpss: set PCI master only for private DMA")
Signed-off-by: Jan Kiszka 
Reviewed-by: Andy Shevchenko 
Signed-off-by: Greg Kroah-Hartman

serial: exar: Fix stuck MSIs

2017-06-14T13:07:36+00:00

commit 2c0ac5b48a3586f612b85755b041ed7733dc8e6b upstream.

After migrating 8250_exar to MSI in 172c33cb61da, we can get stuck
without further interrupts because of the special wake-up event these
chips send. They are only cleared by reading INT0. As we fail to do so
during startup and shutdown, we can leave the interrupt line asserted,
which is fatal with edge-triggered MSIs.

Add the required reading of INT0 to startup and shutdown. Also account
for the fact that a pending wake-up interrupt means we have to return 1
from exar_handle_irq. Drop the unneeded reading of INT1..3 along with
this - those never reset anything.

An alternative approach would have been disabling the wake-up interrupt.
Unfortunately, this feature (REGB[17] = 1) is not available on the
XR17D15X.

Fixes: 172c33cb61da ("serial: exar: Enable MSI support")
Signed-off-by: Jan Kiszka 
Reviewed-by: Andy Shevchenko 
Signed-off-by: Greg Kroah-Hartman

drivers/tty: 8250: only call fintek_8250_probe when doing port I/O

2017-06-07T10:10:06+00:00

commit 4c4fc90964b1cf205a67df566cc82ea1731bcb00 upstream.

Commit fa01e2ca9f53 ("serial: 8250: Integrate Fintek into 8250_base")
modified the probing logic for PNP0501 devices, to remove a collision
between the generic 16550A driver and the Fintek driver, which reused
the same ACPI _HID.

The Fintek device probe is now incorporated into the common 8250 probe
path, and gets called for all discovered 16550A compatible devices,
including ones that are MMIO mapped rather than IO mapped. However,
the Fintek driver assumes the port base is a I/O address, and proceeds
to probe some arbitrary offsets above it.

This is generally a wrong thing to do, but on ARM systems (having no
native port I/O), this may result in faulting accesses of completely
unrelated MMIO regions in the PCI I/O space. Given that this is at
serial probe time, this results in hard to diagnose crashes at boot.

So let's restrict the Fintek probe to devices that we know are using
port I/O in the first place.

Fixes: fa01e2ca9f53 ("serial: 8250: Integrate Fintek into 8250_base")
Suggested-by: Arnd Bergmann 
Reviewed-by: Ricardo Ribalda 
Signed-off-by: Ard Biesheuvel 
Signed-off-by: Greg Kroah-Hartman

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