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: NDouglas Anderson <dianders@chromium.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

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: NWei Yongjun <weiyongjun1@huawei.com>
Reviewed-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The initial binding 'st,hw-flow-control' isn't used anywhere, in neither
in upstream nor downstream kernels.  It isn't even documented in
dt-bindings, so we can safely assume it's safe to swap to the generic
one.
Acked-by: NPeter Griffin <peter.griffin@linaro.org>
Signed-off-by: NLee Jones <lee.jones@linaro.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

When hardware flow-control is disabled, manual toggling of the UART's
reset line (RTS) using userland applications (e.g. stty) is not
possible, since the ASC IP does not provide this functionality in the
same was as some other IPs do.  Thus, we have to do this manually.

This patch ensures that when HW flow-control is disabled the RTS/CTS
lines are free to be registered via the GPIO API.  It also ensures
any registered GPIO lines are unregistered when HW flow-control is
requested, allowing the IP to control them automatically.
Acked-by: NPeter Griffin <peter.griffin@linaro.org>
Signed-off-by: NLee Jones <lee.jones@linaro.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

There are now 2 possible separate/different Pinctrl states which can
be provided from platform data.  One which encompasses the lines
required for HW flow-control (CTS/RTS) and another which does not
specify these lines, such that they can be used via GPIO mechanisms
for manually toggling (i.e. from a request by `stty`).
Acked-by: NPeter Griffin <peter.griffin@linaro.org>
Signed-off-by: NLee Jones <lee.jones@linaro.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Until this point, it has not been possible for userland serial
applications (e.g. stty) to toggle the UART RTS line.  This can
be useful with certain configurations. For example, when using
a Mezzanine on a Linaro 96board, RTS line is used to take the
on-board microcontroller in and out of reset.
Acked-by: NPeter Griffin <peter.griffin@linaro.org>
Signed-off-by: NLee Jones <lee.jones@linaro.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The datasheet states:

"If the MODE field selects an 8-bit frame then this [parity error] bit
 is undefined. Software should ignore this bit when reading 8-bit frames."
Acked-by: NPeter Griffin <peter.griffin@linaro.org>
Signed-off-by: NLee Jones <lee.jones@linaro.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

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: NIan Abbott <abbotti@mev.co.uk>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Allows tuning of the RX FIFO fill threshold and timeout. (The latter is
only applicable to SCIFA and SCIFB).
Signed-off-by: NUlrich Hecht <ulrich.hecht+renesas@gmail.com>
Reviewed-by: NGeert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Implements support for FIFO fill thresholds greater than one with software
timeout.

This mechanism is not possible (or at least not useful) on SCIF family
hardware other than SCIFA and SCIFB because they do not support turning off
the DR hardware timeout interrupt separately from the RI interrupt.
Signed-off-by: NUlrich Hecht <ulrich.hecht+renesas@gmail.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Sets reasonable trigger defaults for the various SCIF variants.
Also corrects the FIFO size for SH7705-style ports.
Signed-off-by: NUlrich Hecht <ulrich.hecht+renesas@gmail.com>
Reviewed-by: NGeert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Sets the closest match for a desired RX trigger level.
Signed-off-by: NUlrich Hecht <ulrich.hecht+renesas@gmail.com>
Reviewed-by: NGeert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

To allow operation with a higher RX FIFO interrupt threshold in PIO
mode, it is necessary to consider the DR bit ("FIFO not full, but no
data received for 1.5 frames") as an indicator that data can be read.
Otherwise the driver will let data rot in the FIFO until the threshold
is reached.
Signed-off-by: NUlrich Hecht <ulrich.hecht+renesas@gmail.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Defines the bits controlling FIFO thresholds, adds the additional
HSCIF registers to the register map.
Signed-off-by: NUlrich Hecht <ulrich.hecht+renesas@gmail.com>
Reviewed-by: NGeert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Instead of open-coding loop with of_find_node_by_type(), let's use canned
macro.
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Commit c7cef0a8 ("console: Add extensible console matching") added
match() method to struct console which allows the console to perform
console command line matching instead of (or in addition to) default
console matching (ie., by fixed name and index).

Commit ad1696f6 ("ACPI: parse SPCR and enable matching console")
introduced support for SPCR as matching console.

Commit 10879ae5 ("serial: pl011: add console matching function")
added the match method for pl011 console which checks for the console
string to be "pl011"

Now on a platform which has both SPCR in the ACPI tables and ttyAMA in
the command line, the ttyAMA is chosen as "selected console" but it
doesn't pass the matching console method which results in CON_CONSDEV
not being set on the "selected console".

As a result of that, the bootconsole(SPCR in the above case) is not
unregistered and all the beginning boot messages are seen twice.

This patch adds "ttyAMA" so that it's considered to match pl011 console.

Fixes: 10879ae5 ("serial: pl011: add console matching function")
Cc: Russell King <linux@armlinux.org.uk>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Jiri Slaby <jslaby@suse.com>
Cc: Peter Hurley <peter@hurleysoftware.com>
Cc: Aleksey Makarov <aleksey.makarov@linaro.org>
Signed-off-by: NSudeep Holla <sudeep.holla@arm.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Ensure that the uart clock is enabled prior to writing to the
interrupt mask register in s3c24xx_serial_resume_noirq function.
Without enabing the uart clock, the uart register cannot be accessed.
Signed-off-by: NYoungmin Nam <youngmin.nam@samsung.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

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: NAndy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: NSudip Mukherjee <sudip.mukherjee@codethink.co.uk>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Add the serial driver for the Exar chips. And also register the
platform device for the GPIO provided by the Exar chips.
Reviewed-by: NAndy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: NSudip Mukherjee <sudip.mukherjee@codethink.co.uk>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

When userspace passes the SER_RS485_RTS_ON_SEND flag it means that the
CTS_B pin should go to logic level high before the transmission begins.

CTS_B goes to logic level high when both CTSC and CTS bits are cleared.

When userspace passes the SER_RS485_RTS_AFTER_SEND flag it means that the
CTS_B pin should go to logic level low after the transmission finishes.

CTS_B goes to logic level low when CTSC bit is cleared and CTS bit is set.

So fix the CTS_B polarity logic.
Signed-off-by: NFabio Estevam <fabio.estevam@nxp.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

On a board that needs to drive RTS GPIO high in order to enable the
transmission of a RS485 transceiver the following description is
passed in the devide tree:

&uart4 {
        pinctrl-names = "default";
        pinctrl-0 = <&pinctrl_uart4>;
        rts-gpios = <&gpio6 2 GPIO_ACTIVE_HIGH>;
        status = "okay";
};

and userspace configures the uart port as follows:

/* enable RS485 mode: */
rs485conf.flags |= SER_RS485_ENABLED;

/* set logical level for RTS pin equal to 1 when sending: */
rs485conf.flags |= SER_RS485_RTS_ON_SEND;

/* set logical level for RTS pin equal to 0 after sending: */
rs485conf.flags &= ~(SER_RS485_RTS_AFTER_SEND);

However the RTS GPIO polarity observed in the oscilloscope is inverted.

When the SER_RS485_RTS_ON_SEND flag is set the imx_port_rts_active()
function should be called and following the same logic when
SER_RS485_RTS_AFTER_SEND flag is cleared the imx_port_rts_inactive()
should be called.

Do such logic change so that RS485 communication in half duplex can
work successfully when the RTS GPIO pin is passed via device tree.
Signed-off-by: NFabio Estevam <fabio.estevam@nxp.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

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: NArnd Bergmann <arnd@arndb.de>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

As the function header of sci_parse_dt() is split in an unusual way,
"git diff" gets confused when changes to the body of the function are
made, and attributes them to the wrong function.

Reformat the function header to fix this.
Signed-off-by: NGeert Uytterhoeven <geert+renesas@glider.be>
Reviewed-by: NSimon Horman <horms+renesas@verge.net.au>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Declare uart_ops structures as const as they are only stored in the ops
field of an uart_port structure. This field is of type const, so
uart_ops structures having this property can be made const too.

File size details before and after patching.
First line of every .o file shows the file size before patching
and second line shows the size after patching.

   text	   data	    bss	    dec	    hex	filename

   2977	    456	     64	   3497	    da9	drivers/tty/serial/amba-pl010.o
   3169	    272	     64	   3505	    db1	drivers/tty/serial/amba-pl010.o

   3109	    456	      0	   3565	    ded	drivers/tty/serial/efm32-uart.o
   3301	    272	      0	   3573	    df5	drivers/tty/serial/efm32-uart.o

  10668	    753	      1	  11422	   2c9e	drivers/tty/serial/icom.o
  10860	    561	      1	  11422	   2c9e	drivers/tty/serial/icom.o

  23904	    408	      8	  24320	   5f00	drivers/tty/serial/ioc3_serial.o
  24088	    224	      8	  24320	   5f00	drivers/tty/serial/ioc3_serial.o

  10516	    560	      4	  11080	   2b48	drivers/tty/serial/ioc4_serial.o
  10709	    368	      4	  11081	   2b49	drivers/tty/serial/ioc4_serial.o

   7853	    648	   1216	   9717	   25f5	drivers/tty/serial/mpsc.o
   8037	    456	   1216	   9709	   25ed	drivers/tty/serial/mpsc.o

  10248	    456	      0	  10704	   29d0	drivers/tty/serial/omap-serial.o
  10440	    272	      0	  10712	   29d8	drivers/tty/serial/omap-serial.o

   8122	    532	   1984	  10638	   298e	drivers/tty/serial/pmac_zilog.o
   8306	    340	   1984	  10630	   2986	drivers/tty/serial/pmac_zilog.o

   3808	    456	      0	   4264	   10a8	drivers/tty/serial/pxa.o
   4000	    264	      0	   4264	   10a8	drivers/tty/serial/pxa.o

  21781	   3864	      0	  25645	   642d	drivers/tty/serial/serial-tegra.o
  22037	   3608	      0	  25645	   642d	drivers/tty/serial/serial-tegra.o

   2481	    456	     96	   3033	    bd9	drivers/tty/serial/sprd_serial.o
   2673	    272	     96	   3041	    be1	drivers/tty/serial/sprd_serial.o

   5534	    300	    512	   6346	   18ca	drivers/tty/serial/vr41xx_siu.o
   5630	    204	    512	   6346	   18ca	drivers/tty/serial/vr41xx_siu.o

   6730	   1576	    128	   8434	   20f2	drivers/tty/serial/vt8500_serial.o
   6986	   1320	    128	   8434	   20f2	drivers/tty/serial/vt8500_serial.o

Cross compiled for mips architecture.

   3005	    488	      0	   3493	    da5	drivers/tty/serial/pnx8xxx_uart.o
   3189	    304	      0	   3493	    da5	drivers/tty/serial/pnx8xxx_uart.o

   4272	    196	   1056	   5524	   1594	drivers/tty/serial/dz.o
   4368	    100	   1056	   5524	   1594	drivers/tty/serial/dz.o

   6551	    144	     16	   6711	   1a37	drivers/tty/serial/ip22zilog.o
   6647	     48	     16	   6711	   1a37	drivers/tty/serial/ip22zilog.o

   9612	    428	   1520	  11560	   2d28	drivers/tty/serial/serial_txx9.o
   9708	    332	   1520	  11560	   2d28	drivers/tty/serial/serial_txx9.o

   4156	    296	     16	   4468	   1174	drivers/tty/serial/ar933x_uart.o
   4252	    200	     16	   4468	   1174	drivers/tty/serial/ar933x_uart.o

Cross compiled for arm archiecture.

  11716	   1780	     44	  13540	   34e4	drivers/tty/serial/sirfsoc_uart.o
  11808	   1688	     44	  13540	   34e4	drivers/tty/serial/sirfsoc_uart.o

  13352	    596	     56	  14004	   36b4	drivers/tty/serial/amba-pl011.o
  13444	    504	     56	  14004	   36b4	drivers/tty/serial/amba-pl011.o

Cross compiled for sparc architecture.

   4664	    528	     32	   5224	   1468	drivers/tty/serial/sunhv.o
   4848	    344	     32	   5224	   1468	drivers/tty/serial/sunhv.o

   8080	    332	     28	   8440	   20f8	drivers/tty/serial/sunzilog.o
   8184	    228	     28	   8440	   20f8	drivers/tty/serial/sunzilog.o

Cross compiled for ia64 architecture.

  10226	    549	    472	  11247	   2bef	drivers/tty/serial/sn_console.o
  10414	    365	    472	  11251	   2bf3	drivers/tty/serial/sn_console.o

The files drivers/tty/serial/zs.o, drivers/tty/serial/lpc32xx_hs.o and
drivers/tty/serial/lantiq.o did not compile.
Signed-off-by: NBhumika Goyal <bhumirks@gmail.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

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: 61929cf0 ("tty: serial: Add 8250-core based omap driver")
Signed-off-by: NTony Lindgren <tony@atomide.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

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: NPaul Gortmaker <paul.gortmaker@windriver.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

This patch adds xilinx uart loopback support by modifying the
cdns_uart_set_mctrl function to handle the switch to loopback mode.
After this patch, the loopback mode can be enabled/disabled by
setting/clearing the TIOCM_LOOP modem bit via TIOCMBIS/TIOCMBIC
ioctls respectively.
Signed-off-by: NYasir-Khan <yasir_khan@mentor.com>
Signed-off-by: NMichal Simek <michal.simek@xilinx.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

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: NVignesh R <vigneshr@ti.com>
Acked-by: NTony Lindgren <tony@atomide.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

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: NVignesh R <vigneshr@ti.com>
Acked-by: NTony Lindgren <tony@atomide.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

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: NVignesh R <vigneshr@ti.com>
Acked-by: NTony Lindgren <tony@atomide.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The vendor driver allows setting baud-rates higher than 115200 baud.
There is a check in the vendor driver which prevents using more than
115200 baud during startup, however it does not have such a check in
.set_termios.
Higher baud-rates are often used by the bluetooth modules embedded into
the SDIO wifi chips (Amlogic devices use brcmfmac based wifi chips quite
often, 2000000 baud seems to be a common value for the UART baud-rate in
Amlogic's "libbt").

I have tested this on a Meson GXL device with uart_A (to which the
bluetooth module is connected, where initialization times out with
115200 baud) and uart_AO (which I manually set to 2000000 baud  and then
connected with my USB UART adapter to that).
Signed-off-by: NMartin Blumenstingl <martin.blumenstingl@googlemail.com>
Acked-by: NKevin Hilman <khilman@baylibre.com>
Tested-by: NAndreas Färber <afaerber@suse.de>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

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: NArvind Yadav <arvind.yadav.cs@gmail.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Add DT earlycon for omap_serial driver. This boot console is included
with CONFIG_SERIAL_EARLYCON=y, CONFIG_OF=y, CONFIG_SERIAL_OMAP=y, and
CONFIG_OF_EARLY_FLATTREE=y.

This boot console is enabled with the command line option "earlycon"
(without "=<name>...") when the DT 'stdout-path' property matches a
compatible uart.
Signed-off-by: NLokesh Vutla <lokeshvutla@ti.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Exactly as in a80c49db ("serial8250: Mark console as CON_ANYTIME"),
to enable printk() during CPU hot-plugging.

Actually most of the serial console drivers do not use per-cpu resources
and can be marked as CON_ANYTIME.
Signed-off-by: NAlexander Sverdlin <alexander.sverdlin@nokia.com>
Cc: Russell King <linux@armlinux.org.uk>
Cc: Jiri Slaby <jslaby@suse.com>
Cc: linux-serial@vger.kernel.org
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Declare dev_pm_ops structures as const as they are only stored in the pm
field of a device_driver structure. This field is of type const, so
dev_pm_ops structures having similar properties can be declared const
too.

Size details after cross compiling the .o file for blackfin architecture.

File size before:
  text	   data	    bss	    dec	    hex	filename
   3572	    320	     16	   3908	    f44 tty/serial/bfin_sport_uart.o

File size after:
   text	   data	    bss	    dec	    hex	filename
   3664	    228	     16	   3908	    f44 tty/serial/bfin_sport_uart.o
Signed-off-by: NBhumika Goyal <bhumirks@gmail.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

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: NHeikki Krogerus <heikki.krogerus@linux.intel.com>
Reviewed-by: NJan Kiszka <jan.kiszka@siemens.com>
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Enable MSI type of interrupt if PCI BIOS supports it.
Reviewed-by: NHeikki Krogerus <heikki.krogerus@linux.intel.com>
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

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: NHeikki Krogerus <heikki.krogerus@linux.intel.com>
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Acked-by: NVinod Koul <vinod.koul@intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

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: NScott Branden <scott.branden@broadcom.com>
Reviewed-by: NRay Jui <ray.jui@broadcom.com>
Signed-off-by: NJason Uy <jason.uy@broadcom.com>
Reviewed-by: NKefeng Wang <wangkefeng.wang@huawei.com>
Reviewed-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

SCI instances found in SH SoCs have different spacing between registers
depending on the SoC. The platform data contains a regshift field that
tells the driver by how many bits to shift the register offset to
compute its address. We can compute the regshift value automatically
based on the memory resource size, there's no need to pass the value
through platform data.

Fix the sh7750 SCI and sh7760 SIM port memory resources length to ensure
proper computation of the regshift value.
Signed-off-by: NLaurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Reviewed-by: NGeert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>