Commit Graph

642 Commits

Author SHA1 Message Date
Jan Kiszka
172c33cb61 serial: exar: Enable MSI support
Use pci_alloc_irq_vectors to enable MSI when available. At least the
XR17V352 supports this.

Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-02-10 15:13:26 +01:00
Jan Kiszka
7e12357ed6 serial: exar: Move register defines from uapi header to consumer site
None of these registers is relevant for the userspace API.

Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-02-10 15:13:26 +01:00
Jan Kiszka
0d560a1d54 serial: pci: Remove unused pci_boards entries
Became obsolete with the split-out of 8250_exar.

Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-02-10 15:12:39 +01:00
Jan Kiszka
fc6cc96157 serial: exar: Move Commtech adapters to 8250_exar as well
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 <jan.kiszka@siemens.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-02-10 15:12:38 +01:00
Jan Kiszka
5b5f252d67 serial: exar: Fix initialization of EXAR registers for ports > 0
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: 14faa8cce8 ("tty/8250 Add support for Commtech's Fastcom Async-335 and Fastcom Async-PCIe cards")
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-02-10 15:12:38 +01:00
Jan Kiszka
24572af4fb serial: exar: Fix mapping of port I/O resources
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: d0aeaa83f0 ("serial: exar: split out the exar code from 8250_pci")
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-02-10 15:12:38 +01:00
Douglas Anderson
424d79183a serial: 8250_dw: Avoid "too much work" from bogus rx timeout interrupt
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 <dianders@chromium.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-02-10 15:10:16 +01:00
Wei Yongjun
80cd94e759 serial: 8250_pci: make pciserial_detach_ports() static
Fixes the following sparse warning:

drivers/tty/serial/8250/8250_pci.c:3916:6: warning:
 symbol 'pciserial_detach_ports' was not declared. Should it be static?

Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-02-09 13:54:49 +01:00
Ian Abbott
1c9c858e2f serial: 8250_pci: Add MKS Tenta SCOM-0800 and SCOM-0801 cards
The MKS Instruments SCOM-0800 and SCOM-0801 cards (originally by Tenta
Technologies) are 3U CompactPCI serial cards with 4 and 8 serial ports,
respectively.  The first 4 ports are implemented by an OX16PCI954 chip,
and the second 4 ports are implemented by an OX16C954 chip on a local
bus, bridged by the second PCI function of the OX16PCI954.  The ports
are jumper-selectable as RS-232 and RS-422/485, and the UARTs use a
non-standard oscillator frequency of 20 MHz (base_baud = 1250000).

Signed-off-by: Ian Abbott <abbotti@mev.co.uk>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-02-06 09:47:52 +01:00
Sudip Mukherjee
5d1a2388ed serial: 8250_pci: remove exar code
Remove the Exar specific codes from 8250_pci and blacklist those chips
so that the new Exar serial driver binds to the devices.

Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: Sudip Mukherjee <sudip.mukherjee@codethink.co.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-02-03 10:12:16 +01:00
Sudip Mukherjee
d0aeaa83f0 serial: exar: split out the exar code from 8250_pci
Add the serial driver for the Exar chips. And also register the
platform device for the GPIO provided by the Exar chips.

Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: Sudip Mukherjee <sudip.mukherjee@codethink.co.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-02-03 10:12:16 +01:00
Arnd Bergmann
aa42db44f6 8250: of: remove remnants of generic of_serial driver
During build testing, I ran into a warning in a driver that I
had written myself at some point:

drivers/tty/serial/8250/8250_of.c: In function 'of_platform_serial_probe':
drivers/tty/serial/8250/8250_of.c:233:1: error: the frame size of 1200 bytes is larger than 1152 bytes [-Werror=frame-larger-than=]

This is harmless by itself, but it shows two other problems in
the driver:

- It still tries to be generic enough to handle all kinds of serial
  ports, where in reality the driver has been 8250-only for a while,
  and every other uart has its own DT support

- As a result of that generalization, we keep two copies of
  'struct uart_port' on the stack during probe(). This is completely
  unnessary.

Removing the last code dealing with unsupported port_type values
solves both problems nicely, and reduces the stack size.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-01-27 09:23:36 +01:00
Tony Lindgren
4e0f5cc650 serial: 8250_omap: Fix probe and remove for PM runtime
Otherwise the interconnect related code implementing PM runtime will
produce these errors on a failed probe:

omap_uart 48066000.serial: omap_device: omap_device_enable() called from invalid state 1
omap_uart 48066000.serial: use pm_runtime_put_sync_suspend() in driver?

Note that we now also need to check for priv in omap8250_runtime_suspend()
as it has not yet been registered if probe fails. And we need to use
pm_runtime_put_sync() to properly idle the device like we already do
in omap8250_remove().

Fixes: 61929cf016 ("tty: serial: Add 8250-core based omap driver")
Signed-off-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-01-25 11:08:30 +01:00
Paul Gortmaker
f99b63afb9 serial: hp300: mask the warning for people just doing build coverage
Currently this warning is triggered for allmodconfig on m68k.  It is
well intentioned, in that if you are building the driver but not
enabling one of the platforms where the hardware exists, you get a
warning.

The warning dates back to pre-git days, and now we have COMPILE_TEST
so we can use that to mask the warning for people who are obviously
just doing build coverage on tree wide changes.

Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Jiri Slaby <jslaby@suse.com>
Cc: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: linux-m68k@lists.linux-m68k.org
Cc: linux-serial@vger.kernel.org
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-01-25 11:08:30 +01:00
Vignesh R
aa75941ca1 serial: 8250_omap: Remove rx_dma_broken flag
8250 UART DMA support was marked broken by default as it was not
possible to pause ongoing RX DMA transfer. Now that both SDMA and
EDMA can support pause operation for RX DMA transactions, don't set
rx_dma_broken to true by default. With this patch 8250_omap driver will
use DMA by default.

Signed-off-by: Vignesh R <vigneshr@ti.com>
Acked-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-01-20 14:44:37 +01:00
Vignesh R
b6ffcf2108 serial: 8250_omap: Add OMAP_DMA_TX_KICK quirk for AM437x
UART uses as EDMA as dma engine on AM437x SoC and therefore, requires
OMAP_DMA_TX_KICK quirk just like AM33xx. So, enable OMAP_DMA_TX_KICK
quirk for AM437x platform as well. While at that, drop use of
of_machine_is_compatible() and instead pass quirks via device data.

Signed-off-by: Vignesh R <vigneshr@ti.com>
Acked-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-01-20 14:44:37 +01:00
Vignesh R
75f54acc08 serial: 8250_omap: pause DMA only if DMA transfer in progress
It is possible that DMA transfer is already complete but, completion
handler is yet to be called, when dmaengine_pause() is called in case of
error condition(like break/rx timeout). This leads to dmaengine_pause()
API to return EINVAL (as descriptor is already NULL) causing
rx_dma_broken flag to be set and effectively disabling RX DMA.
Fix this by calling dmaengine_pause() only when transfer is in progress.

Signed-off-by: Vignesh R <vigneshr@ti.com>
Acked-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-01-20 14:44:37 +01:00
Arvind Yadav
2cc32b18d1 tty: serial: 8250: 8250_gsc:- Handle return NULL error from ioremap_nocache
Here, If ioremap_nocache will fail. It will return NULL.
Kernel can run into a NULL-pointer dereference.
This error check will avoid NULL pointer dereference.

Signed-off-by: Arvind Yadav <arvind.yadav.cs@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-01-19 14:20:23 +01:00
Andy Shevchenko
216e234d66 serial: 8250_mid: set PCI master only for DMA capable device
There is no need to set PCI bus mastering when device is not doing any DMA. It
includes MSI type of interrupts. Currently only UART on Denverton, which is DMA
capable, might have MSI enabled.

Taking above into account enable bus mastering for Denverton case only.

Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Reviewed-by: Jan Kiszka <jan.kiszka@siemens.com>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-01-19 14:20:23 +01:00
Andy Shevchenko
6d59225f2d serial: 8250_mid: enable MSI on Denverton
Enable MSI type of interrupt if PCI BIOS supports it.

Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-01-19 14:20:23 +01:00
Andy Shevchenko
4831e0d905 serial: 8250_mid: handle interrupt correctly in DMA case
Starting from Tangier B0 and continuing on Anniedale the HSU DMA interrupt
line is actually shared with UART. Handling them independently is racy and
quite often comes with the following traceback.

 irq 54: nobody cared (try booting with the "irqpoll" option)
 CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.9.0-rc6-edison64-86244934+ #1
 Hardware name: Intel Corporation Merrifield/BODEGA BAY, BIOS 542 2015.01.21:18.19.48
  ffff88003f203eb0 ffffffff8130e718 ffff880032627000 ffff88003262709c
  ffff88003f203ed8 ffffffff810a3960 ffff880032627000 0000000000000000
  ffff880032627000 ffff88003f203f10 ffffffff810a3cc7 ffff880032627000
 Call Trace:
  <IRQ>
  [<ffffffff8130e718>] dump_stack+0x4d/0x65
  [<ffffffff810a3960>] __report_bad_irq+0x30/0xc0
  [<ffffffff810a3cc7>] note_interrupt+0x227/0x270
  [<ffffffff810a1380>] handle_irq_event_percpu+0x40/0x50
  [<ffffffff810a13b7>] handle_irq_event+0x27/0x50
  [<ffffffff810a42d5>] handle_fasteoi_irq+0x85/0x150
  [<ffffffff8101d7fe>] handle_irq+0x6e/0x120
  [<ffffffff8105b8bc>] ? _local_bh_enable+0x1c/0x50
  [<ffffffff8101d0d6>] do_IRQ+0x46/0xd0
  [<ffffffff818cef3f>] common_interrupt+0x7f/0x7f
  <EOI>
  [<ffffffff818cdead>] ? mwait_idle+0x7d/0x140
  [<ffffffff81024c9a>] arch_cpu_idle+0xa/0x10
  [<ffffffff818ce150>] default_idle_call+0x20/0x30
  [<ffffffff810908fd>] cpu_startup_entry+0x16d/0x1d0
  [<ffffffff818c882d>] rest_init+0x6d/0x70
  [<ffffffff81f93e8f>] start_kernel+0x3e2/0x3ef
  [<ffffffff81f9343d>] x86_64_start_reservations+0x38/0x3a
  [<ffffffff81f93529>] x86_64_start_kernel+0xea/0xed
 handlers:
 [<ffffffff81411670>] serial8250_interrupt
 Disabling IRQ #54

Fix this by handling interrupt only in one place.

The issue is discussed here: https://github.com/andy-shev/linux/issues/5

Moreover this also fixes another bug when Rx DMA returns wrong residue and we
can't rely on it.

Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Acked-by: Vinod Koul <vinod.koul@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-01-19 14:20:23 +01:00
Jason Uy
6a171b2993 serial: 8250_dw: Allow hardware flow control to be used
In the most common use case, the Synopsys DW UART driver does not
set the set_termios callback function.  This prevents UPSTAT_AUTOCTS
from being set when the UART flag CRTSCTS is set.  As a result, the
driver will use software flow control as opposed to hardware flow
control.

To fix the problem, the set_termios callback function is set to the
DW specific function.  The logic to set UPSTAT_AUTOCTS is moved so
that any clock error will not affect setting the hardware flow
control.

Reviewed-by: Scott Branden <scott.branden@broadcom.com>
Reviewed-by: Ray Jui <ray.jui@broadcom.com>
Signed-off-by: Jason Uy <jason.uy@broadcom.com>
Reviewed-by: Kefeng Wang <wangkefeng.wang@huawei.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-01-19 14:20:23 +01:00
Greg Kroah-Hartman
11cca3d12f Merge 4.10-rc4 into tty-next
We want the serial/tty fixes in here as well to build on top of.

Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-01-16 16:57:54 +01:00
David Lechner
a2d6a987bf serial: 8250: Add new port type for TI DA8xx/66AK2x
This adds a new UART port type for TI DA8xx/OMAPL13x/AM17xx/AM18xx/66AK2x.
These SoCs have standard 8250 registers plus some extra non-standard
registers.

The UART will not function unless the non-standard Power and Emulation
Management Register (PWREMU_MGMT) is configured correctly. This is
currently handled in arch/arm/mach-davinci/serial.c for non-device-tree
boards. Making this part of the UART driver will allow UART to work on
device-tree boards as well and the mach code can eventually be removed.

Signed-off-by: David Lechner <david@lechnology.com>
Acked-by: Sekhar Nori <nsekhar@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-01-12 11:51:25 +01:00
Jean Delvare
194588930c serial: 8250_mid: make option visible
Hiding tristate options with "if EXPERT" is usually not a good idea.
You can decide that the driver should be included by default, but you
don't know if the user wants it built-in or as a module. Hiding the
option prevents the user from making that decision.

This is even more problematic when said option selects other options.
You end up with several device drivers forcibly built into the kernel.

In this specific case, drivers 8250_mid, virt-dma, hsu_dma and
hsu_dma_pci end up being built-in as soon as SERIAL_8250=y. It is
very common for distribution kernels to build the subsystem core code
into the kernel, because almost everybody will need it, but build all
the device drivers as modules. This should be made possible.

So drop the "if EXPERT" and make SERIAL_8250_MID visible.

Signed-off-by: Jean Delvare <jdelvare@suse.de>
Fixes: 1fc969c759 ("serial: 8250_mid: make module available only on X86")
Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Cc: Jiri Slaby <jslaby@suse.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-01-12 11:51:25 +01:00
Jean Delvare
dce22df190 serial: 8250_lpss: make option visible
Hiding tristate options with "if EXPERT" is usually not a good idea.
You can decide that the driver should be included by default, but you
don't know if the user wants it built-in or as a module. Hiding the
option prevents the user from making that decision.

This is even more problematic when said option selects other options.
You end up with several device drivers forcibly built into the kernel.

In this specific case, drivers 8250_lpss, dw_dmac_core and
dw_dmac_pci end up being built-in as soon as SERIAL_8250=y. It is
very common for distribution kernels to build the subsystem core code
into the kernel, because almost everybody will need it, but build all
the device drivers as modules. This should be made possible.

So drop the "if EXPERT" and make SERIAL_8250_LPSS visible.

Signed-off-by: Jean Delvare <jdelvare@suse.de>
Fixes: a13e19cf3d ("serial: 8250_lpss: split LPSS driver to separate module")
Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Cc: Jiri Slaby <jslaby@suse.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-01-12 11:51:25 +01:00
Jean Delvare
f1e8c710e2 serial: 8250_pci: make option visible
Hiding tristate options with "if EXPERT" is usually not a good idea.
You can decide that the driver should be included by default, but you
don't know if the user wants it built-in or as a module. Hiding the
option prevents the user from making that decision.

In this specific case, driver 8250_pci ends up being built-in as soon
as SERIAL_8250=y. It is very common for distribution kernels to build
the subsystem core code into the kernel, because almost everybody
will need it, but build all the device drivers as modules. This
should be made possible.

So drop the "if EXPERT" and make SERIAL_8250_PCI visible.

Signed-off-by: Jean Delvare <jdelvare@suse.de>
Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Cc: Jiri Slaby <jslaby@suse.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-01-12 11:51:25 +01:00
Alexey Brodkin
699a11ba7e serial: 8250_port: Remove dangerous pr_debug()
With CONFIG_DYNAMIC_DEBUG if dyndbg enables debug output in
8250_port.c deadlock happens inevitably on UART IRQ handling.

That's the problematic execution path:
---------------------------->8------------------------
UART IRQ:
  serial8250_interrupt() ->
    serial8250_handle_irq(): lock "port->lock" ->
      pr_debug() ->
        serial8250_console_write(): bump in locked "port->lock".

      OR (if above pr_debug() gets removed):
      serial8250_tx_chars() ->
        pr_debug() ->
          serial8250_console_write(): bump in locked "port->lock".
---------------------------->8------------------------

So let's get rid of those not that much useful debug entries.

Discussed problem could be easily reproduced with QEMU for x86_64.
As well as this fix could be mimicked with muting of dynamic debug for
the problematic lines as simple as:
---------------------------->8------------------------
dyndbg="+p; file 8250_port.c line 1756 -p; file 8250_port.c line 1822 -p"
---------------------------->8------------------------

Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
Cc: Jiri Slaby <jslaby@suse.com>
Cc: Peter Hurley <peter@hurleysoftware.com>
Cc: Phillip Raffeck <phillip.raffeck@fau.de>
Cc: Anton Wuerfel <anton.wuerfel@fau.de>
Cc: "Matwey V. Kornilov" <matwey@sai.msu.ru>
Cc: Yegor Yefremov <yegorslists@googlemail.com>
Cc: Thor Thayer <tthayer@opensource.altera.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-01-12 11:51:25 +01:00
Andy Shevchenko
3f08087826 serial: 8250_lpss: avoid potential kernel crash when remove
This is a follow up to the commit a9b01b5823 ("serial: 8250_mid fix calltrace
when hotplug 8250 serial controller") in which the kernel crash was described
for another 8250 based driver. It appears that we have the very same issue in
8250_lpss. Fix it by unregistering serial driver first.

Cc: Liwei Song <liwei.song@windriver.com>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-01-12 11:51:25 +01:00
Matwey V. Kornilov
9c4b60fe53 serial: 8250: moxa: Store num_ports in brd
When struct moxa8250_board is allocated, then num_ports should
be initialized in order to use it later in moxa8250_remove.

Signed-off-by: Matwey V. Kornilov <matwey@sai.msu.ru>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-01-12 11:51:25 +01:00
Ji-Ze Hong (Peter Hong)
6def047c29 serial: 8250_fintek: Add resource check for Fintek F81504/508/512
Add resource type check for Fintek F81504/508/512, BAR3/4/5 must be
IORESOURCE_IO.

Fintek is trying to make F81504/508/512 works on MMIO interface, but
it's still in progress. We found some issue when the experiment IC
when the BAR3/4/5 is IORESOURCE_MEM. It'll cause wrong operation with
IO resource. So we'll add the resource check for this.

Signed-off-by: Ji-Ze Hong (Peter Hong) <hpeter+linux_kernel@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-01-12 11:51:24 +01:00
Herbert Xu
6741f551a0 Revert "tty: serial: 8250: add CON_CONSDEV to flags"
This commit needs to be reverted because it prevents people from
using the serial console as a secondary console with input being
directed to tty0.

IOW, if you boot with console=ttyS0 console=tty0 then all kernels
prior to this commit will produce output on both ttyS0 and tty0
but input will only be taken from tty0.  With this patch the serial
console will always be the primary console instead of tty0,
potentially preventing people from getting into their machines in
emergency situations.

Fixes: d03516df83 ("tty: serial: 8250: add CON_CONSDEV to flags")
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-01-11 08:35:17 +01:00
Daniel Jedrychowski
2bed8a8e70 Clearing FIFOs in RS485 emulation mode causes subsequent transmits to break
When in RS485 emulation mode, __do_stop_tx_rs485() calls
serial8250_clear_fifos().  This not only clears the FIFOs, but also sets
all bits in their control register (UART_FCR) to 0.

One of the effects of this is the disabling of the FIFOs, which turns
them into single-byte holding registers.  The rest of the driver doesn't
know this, which results in the lions share of characters passed into a
write call to be dropped.

(I can supply logic analyzer screenshots if necessary)

This fix replaces the serial8250_clear_fifos() call to
serial8250_clear_and_reinit_fifos() - this prevents the "dropped
characters" issue from manifesting again while retaining the requirement
of clearing the RX FIFO after transmission if the SER_RS485_RX_DURING_TX
flag is disabled.

Signed-off-by: Daniel Jedrychowski <avistel@gmail.com>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-01-11 08:35:17 +01:00
Gabriel Krisman Bertazi
c130b666a9 8250_pci: Fix potential use-after-free in error path
Commit f209fa03fc ("serial: 8250_pci: Detach low-level driver during
PCI error recovery") introduces a potential use-after-free in case the
pciserial_init_ports call in serial8250_io_resume fails, which may
happen if a memory allocation fails or if the .init quirk failed for
whatever reason).  If this happen, further pci_get_drvdata will return a
pointer to freed memory.

This patch reworks the PCI recovery resume hook to restore the old priv
structure in this case, which should be ok, since the ports were already
detached. Such error during recovery causes us to give up on the
recovery.

Fixes: f209fa03fc ("serial: 8250_pci: Detach low-level driver during
  PCI error recovery")
Reported-by: Michal Suchanek <msuchanek@suse.com>
Signed-off-by: Gabriel Krisman Bertazi <krisman@linux.vnet.ibm.com>
Signed-off-by: Guilherme G. Piccoli <gpiccoli@linux.vnet.ibm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-01-11 08:35:17 +01:00
Linus Torvalds
e3842cbfe0 dmaengine updates for 4.10-rc1
Fairly routine update this time around with all changes specific to drivers.
 
  o New driver for STMicroelectronics FDMA
  o Memory-to-memory transfers on dw dmac
  o Support for slave maps on pl08x devices
  o Bunch of driver fixes to use dma_pool_zalloc
  o Bunch of compile and warning fixes spread across drivers
 -----BEGIN PGP SIGNATURE-----
 Version: GnuPG v1
 
 iQIcBAABAgAGBQJYUg7NAAoJEHwUBw8lI4NH5/gP/j81+2RzCUX8PiLQxNUt0Vj+
 tVJEizpWCwN1cnhc8ibZdI1DAwyj+GbN2lghYTjqqEng4yOm3czPzUl99grBrpQl
 t+Qylr9PSpck/paRhd2lgZzG8Nk+B5HJDcxBQbW4pwmbc69YAbqYzt44i4bDpR5K
 u3mBve1Ulng7peP45EZB8BA32ffCpOEAC/9SdkaPokrSv6XxxPEFvzewy+mLtioU
 a0zY0iuHqVGpOTABK65fXO/zkGiZLPXJ1T5vK7Iz8mOwuvtYVif0yktQSrx3BWbc
 9r64W7Si633wWt/C9LkuMMSmQ7nI/PyHk811cDOcxp3SA79JV5SWwdQl+5QPdtoP
 hyToaISfAY0BiNI9ltdscx3MPjlwSp08xXvi46RjSs8E2TXnbHUw+J5mTsxYuocl
 Yi61nlL5ClhCbySf9Q3GFsuAJ3O2Nq9WkCTNRIvJtrMhe3NeqDDTfBZJRD4Bfg1G
 q8RAc5oqGZDtqKHtLfwULr7Ec2Ru0hIZAyN907OwW+4jBR/eBJB1y+nGrNPtTWPT
 OOcvrxe85/+ZNROGCZKr0L8UA/MBBMZtjvMY8RMXjBE4YJbakq7tV+7l5VolKeNH
 G6I/1CC06qVPHrnetM6YejhtnmOQ4F8P1sE0wvpG0QTyHJoFq+aOhHNKJC8F9Eln
 CQM2apvL4BHvS7OHt9XL
 =Pf0d
 -----END PGP SIGNATURE-----

Merge tag 'dmaengine-4.10-rc1' of git://git.infradead.org/users/vkoul/slave-dma

Pull dmaengine updates from Vinod Koul:
 "Fairly routine update this time around with all changes specific to
  drivers:

   - New driver for STMicroelectronics FDMA
   - Memory-to-memory transfers on dw dmac
   - Support for slave maps on pl08x devices
   - Bunch of driver fixes to use dma_pool_zalloc
   - Bunch of compile and warning fixes spread across drivers"

[ The ST FDMA driver already came in earlier through the remoteproc tree ]

* tag 'dmaengine-4.10-rc1' of git://git.infradead.org/users/vkoul/slave-dma: (68 commits)
  dmaengine: sirf-dma: remove unused ‘sdesc’
  dmaengine: pl330: remove unused ‘regs’
  dmaengine: s3c24xx: remove unused ‘cdata’
  dmaengine: stm32-dma: remove unused ‘src_addr’
  dmaengine: stm32-dma: remove unused ‘dst_addr’
  dmaengine: stm32-dma: remove unused ‘sfcr’
  dmaengine: pch_dma: remove unused ‘cookie’
  dmaengine: mic_x100_dma: remove unused ‘data’
  dmaengine: img-mdc: remove unused ‘prev_phys’
  dmaengine: usb-dmac: remove unused ‘uchan’
  dmaengine: ioat: remove unused ‘res’
  dmaengine: ioat: remove unused ‘ioat_dma’
  dmaengine: ioat: remove unused ‘is_raid_device’
  dmaengine: pl330: do not generate unaligned access
  dmaengine: k3dma: move to dma_pool_zalloc
  dmaengine: at_hdmac: move to dma_pool_zalloc
  dmaengine: at_xdmac: don't restore unsaved status
  dmaengine: ioat: set error code on failures
  dmaengine: ioat: set error code on failures
  dmaengine: DW DMAC: add multi-block property to device tree
  ...
2016-12-14 20:42:45 -08:00
Liwei Song
a9b01b5823 serial: 8250_mid fix calltrace when hotplug 8250 serial controller
Fix the following Calltrace:
[   77.768221] WARNING: CPU: 5 PID: 645 at drivers/dma/dmaengine.c:1069 dma_async_device_unregister+0xe2/0xf0
[   77.775058] dma_async_device_unregister called while 1 clients hold a reference
[   77.825048] CPU: 5 PID: 645 Comm: sh Not tainted 4.8.8-WR9.0.0.0_standard+ #3
[   77.832550] Hardware name: Intel Corp. Aspen Cove/Server, BIOS HAVLCRB1.X64.0012.D58.1604140405 04/14/2016
[   77.840396]  0000000000000000 ffffc90008adbc80 ffffffff81403456 ffffc90008adbcd0
[   77.848245]  0000000000000000 ffffc90008adbcc0 ffffffff8105e2e1 0000042d08adbf20
[   77.855934]  ffff88046a861c18 ffff88046a85c420 ffffffff820d4200 ffff88046ae92318
[   77.863601] Call Trace:
[   77.871113]  [<ffffffff81403456>] dump_stack+0x4f/0x69
[   77.878655]  [<ffffffff8105e2e1>] __warn+0xd1/0xf0
[   77.886102]  [<ffffffff8105e34f>] warn_slowpath_fmt+0x4f/0x60
[   77.893508]  [<ffffffff814187a9>] ? find_next_bit+0x19/0x20
[   77.900730]  [<ffffffff814bf83e>] ? dma_channel_rebalance+0x23e/0x270
[   77.907814]  [<ffffffff814bfee2>] dma_async_device_unregister+0xe2/0xf0
[   77.914992]  [<ffffffff814c53aa>] hsu_dma_remove+0x1a/0x60
[   77.921977]  [<ffffffff814ee14c>] dnv_exit+0x1c/0x20
[   77.928752]  [<ffffffff814edff6>] mid8250_remove+0x26/0x40
[   77.935607]  [<ffffffff8144f1b9>] pci_device_remove+0x39/0xc0
[   77.942292]  [<ffffffff8160cfea>] __device_release_driver+0x9a/0x140
[   77.948836]  [<ffffffff8160d0b3>] device_release_driver+0x23/0x30
[   77.955364]  [<ffffffff81447dcc>] pci_stop_bus_device+0x8c/0xa0
[   77.961769]  [<ffffffff81447f0a>] pci_stop_and_remove_bus_device_locked+0x1a/0x30
[   77.968113]  [<ffffffff81450d4e>] remove_store+0x5e/0x70
[   77.974267]  [<ffffffff81607ed8>] dev_attr_store+0x18/0x30
[   77.980243]  [<ffffffff8123006a>] sysfs_kf_write+0x3a/0x50
[   77.986180]  [<ffffffff8122f5ab>] kernfs_fop_write+0x10b/0x190
[   77.992118]  [<ffffffff811bf1c8>] __vfs_write+0x18/0x40
[   77.998032]  [<ffffffff811bfdee>] vfs_write+0xae/0x190
[   78.003747]  [<ffffffff811c1016>] SyS_write+0x46/0xb0
[   78.009234]  [<ffffffff81a4c31b>] entry_SYSCALL_64_fastpath+0x13/0x8f
[   78.014809] ---[ end trace 0c36dd73b7408eb2 ]---

This happens when the 8250 serial controller is hotplugged as follows:
echo 1 > /sys/bus/pci/devices/0000:00:1a.0/remove

This trace happens due to the serial port still holding a reference when
the dma device is unregistered.
The dma unregister routine will check if there is still a reference exist,
if so it will give the WARNING(here serial port still was not unregister).

To fix this, We need to unregister the serial port first, then do DMA
device unregister to make sure there is no reference when to DMA routine.

Signed-off-by: Liwei Song <liwei.song@windriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-11-30 13:06:08 +01:00
Eugeniy Paltsev
bd2c6636cc dmaengine: DW DMAC: add multi-block property to device tree
Several versions of DW DMAC have multi block transfers hardware
support. Hardware support of multi block transfers is disabled
by default if we use DT to configure DMAC and software emulation
of multi block transfers used instead.
Add multi-block property, so it is possible to enable hardware
multi block transfers (if present) via DT.

Switch from per device is_nollp variable to multi_block array
to be able enable/disable multi block transfers separately per
channel.

Acked-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Eugeniy Paltsev <Eugeniy.Paltsev@synopsys.com>
Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2016-11-30 08:57:50 +05:30
Gabriel Krisman Bertazi
f209fa03fc serial: 8250_pci: Detach low-level driver during PCI error recovery
During a PCI error recovery, like the ones provoked by EEH in the ppc64
platform, all IO to the device must be blocked while the recovery is
completed.  Current 8250_pci implementation only suspends the port
instead of detaching it, which doesn't prevent incoming accesses like
TIOCMGET and TIOCMSET calls from reaching the device.  Those end up
racing with the EEH recovery, crashing it.  Similar races were also
observed when opening the device and when shutting it down during
recovery.

This patch implements a more robust IO blockage for the 8250_pci
recovery by unregistering the port at the beginning of the procedure and
re-adding it afterwards.  Since the port is detached from the uart
layer, we can be sure that no request will make through to the device
during recovery.  This is similar to the solution used by the JSM serial
driver.

I thank Peter Hurley <peter@hurleysoftware.com> for valuable input on
this one over one year ago.

Signed-off-by: Gabriel Krisman Bertazi <krisman@linux.vnet.ibm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-11-29 20:20:07 +01:00
Ed Blake
0e0b989eb3 serial: 8250_dw: Add support for IrDA SIR mode
Add a set_ldisc function to enable/disable IrDA SIR mode according to
the new line discipline, if IrDA SIR mode is supported by the hardware
configuration.

Signed-off-by: Ed Blake <ed.blake@imgtec.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-11-16 10:59:38 +01:00
Ed Blake
db405a8f8b serial: 8250: Expose set_ldisc function
Expose set_ldisc() function so that it can be overridden with a
platform specific implementation.

Signed-off-by: Ed Blake <ed.blake@imgtec.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-11-16 10:59:38 +01:00
Ed Blake
98838d9507 serial: 8250: Add IrDA to UART capabilities
Add an IrDA UART capability flag and change the type of
uart_8250_port.capabilities to be u32 rather than unsigned short to
accommodate the additional flag.

Signed-off-by: Ed Blake <ed.blake@imgtec.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-11-16 10:59:38 +01:00
Andy Shevchenko
5fe8667484 serial: 8250_dma: power off device after TX is done
When any 8250 based driver sets up DMA and has UART_CAP_RPM capability enabled
the device is left powered on after transfer is done. We need to schedule a
device suspend operation when DMA completes the transfer.

The patch is based on the work done by the reporter.

Reported-by: Huiquan Zhong <huiquan.zhong@intel.com>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-11-16 10:57:26 +01:00
Andy Shevchenko
7d4e00c625 serial: 8250_port: export serial8250_rpm_{get|put}_tx()
The following fix of runtime PM use in DMA mode requires at least
serial8250_rpm_put_tx() to be available. Export both calls.

Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-11-16 10:57:26 +01:00
Arnd Bergmann
65dabaf532 serial: pxa2xx: mark PM functions as __maybe_unused
The fresh new serial driver for pxa produces warnings when
CONFIG_PM_SLEEP is disabled:

drivers/tty/serial/8250/8250_pxa.c:50:12: error: 'serial_pxa_resume' defined but not used [-Werror=unused-function]
drivers/tty/serial/8250/8250_pxa.c:41:12: error: 'serial_pxa_suspend' defined but not used [-Werror=unused-function]

This removes the #ifdef around the two functions and instead marks both
as __maybe_unused, which is more robust and avoids the warning.

Fixes: ab28f51c77 ("serial: rewrite pxa2xx-uart to use 8250_core")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Robert Jarzmik <robert.jarzmik@free.fr>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-11-10 14:50:46 +01:00
Angelo Butti
5c31ef91c0 8250: FIX Fourth port offset of Pericom PI7C9X7954 boards
Hi,
below patch to fix Fourth port offset of Percom PI7C9X7954 boards.

I had a problem using Fourth port on a pci express serial board based on Pericom
PI7C9X7954. Reading datasheet I notice a "special" offset assign to this port
when used in I/O mode.

Offset 0x0 ->  UART 0
Offset 0x8 ->  UART 1
Offset 0x10 ->  UART 2
Offset 0x38 ->  UART 3  <<---- This don't follow a logical sequence

This patch add a different init to last port, to have right offset.

I check also Pericom 7952 and 7958 but that devices follow logical sequence,
so they are ok.

Regards,
Angelo

Signed-off-by: Angelo Butti <buttiangelo@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-11-10 14:41:25 +01:00
Arnd Bergmann
9211432b4a serial: 8250_pxa: hide early console setup when disabled
The newly added pxa glue driver for 8250 supports console output, but
fails to build if the 8250 console is disabled:

drivers/tty/serial/8250/8250_pxa.o: In function `early_serial_pxa_setup':
8250_pxa.c:(.init.text+0x50): undefined reference to `early_serial8250_setup'

This adds an #ifdef like the other glue drivers have it.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Robert Jarzmik <robert.jarzmik@free.fr>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-11-10 14:34:27 +01:00
Masahiro Yamada
da7fa058a3 serial: 8250_uniphier: avoid locking for FCR register write
The hardware book says, the FCR is combined with a register called
CHAR (it will trigger interrupt when a specific character is
received).  At first, I used lock/read/modify/write/unlock dance for
the FCR to not affect the upper bits, but the CHAR is actually never
used.  It should not hurt to always clear the CHAR and to handle the
FCR as a normal case.  It can save the costly locking.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Suggested-by: Denys Vlasenko <dvlasenk@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-11-10 14:30:09 +01:00
Masahiro Yamada
94cbb6978b serial: 8250_uniphier: hardcode regshift to avoid unneeded memory read
For this driver, uart_port::regshift is always 2.  Hardcode the
shift value instead of reading ->regshift to get an already known
value.  (pointed out by Denys Vlasenko)

Furthermore, I am using register macros that are already shifted,
which will save code a bit.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-11-10 14:30:08 +01:00
Greg Kroah-Hartman
5131dcd781 Merge 4.9-rc3 into tty-next
We want the serial/tty fixes in here as well.

Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-10-30 06:42:10 -04:00
Steve Shih
ecb988a3b7 tty: serial: 8250: 8250_core: NXP SC16C2552 workaround
NXP SC16C2552 requires that we always write a reset to the RX FIFO and
TX FIFO whenever we enable the FIFOs

Cc: xe-kernel@external.cisco.com
Signed-off-by: Steve Shih <sshih@cisco.com>
Signed-off-by: David Singleton <davsingl@cisco.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-10-27 16:41:56 +02:00