The driver uses clk_prepare_enable in ulite_probe but uses clk_unprepare
in ulite_remove, which does not match.
Replace clk_unprepare with clk_disable_unprepare to fix it.
Signed-off-by: NChuhong Yuan <hslester96@gmail.com>
Link: https://lore.kernel.org/r/20191101085433.10399-1-hslester96@gmail.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

As platform_get_irq() now prints an error when the interrupt does not
exist, this warnings are printed on bananapi-r2:

[    4.935780] mt6577-uart 11004000.serial: IRQ index 1 not found
[    4.962589] 11002000.serial: ttyS1 at MMIO 0x11002000 (irq = 202, base_baud = 1625000) is a ST16650V2
[    4.972127] mt6577-uart 11002000.serial: IRQ index 1 not found
[    4.998927] 11003000.serial: ttyS2 at MMIO 0x11003000 (irq = 203, base_baud = 1625000) is a ST16650V2
[    5.008474] mt6577-uart 11003000.serial: IRQ index 1 not found

Fix this by calling platform_get_irq_optional() instead.

now it looks like this:

[    4.872751] Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled

Fixes: 7723f4c5 ("driver core: platform: Add an error message to platform_get_irq*()")
Signed-off-by: NFrank Wunderlich <frank-w@public-files.de>
Cc: stable <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20191027062117.20389-1-frank-w@public-files.deSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Since the commit 7723f4c5 ("driver core: platform: Add an error message
to platform_get_irq*()") platform_get_irq() started issuing an error message.
Thus, there is no need to have the same in the driver

Fixes: 7723f4c5 ("driver core: platform: Add an error message to platform_get_irq*()")
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Cc: stable <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20191023103558.51862-1-andriy.shevchenko@linux.intel.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

hci_qca interfaces to the wcn3990 via a uart_dm on the msm8998 mtp and
Lenovo Miix 630 laptop.  As part of initializing the wcn3990, hci_qca
disables flow, configures the uart baudrate, and then reenables flow - at
which point an event is expected to be received over the uart from the
wcn3990.  It is observed that this event comes after the baudrate change
but before hci_qca re-enables flow. This is unexpected, and is a result of
msm_reset() being broken.

According to the uart_dm hardware documentation, it is recommended that
automatic hardware flow control be enabled by setting RX_RDY_CTL.  Auto
hw flow control will manage RFR based on the configured watermark.  When
there is space to receive data, the hw will assert RFR.  When the watermark
is hit, the hw will de-assert RFR.

The hardware documentation indicates that RFR can me manually managed via
CR when RX_RDY_CTL is not set.  SET_RFR asserts RFR, and RESET_RFR
de-asserts RFR.

msm_reset() is broken because after resetting the hardware, it
unconditionally asserts RFR via SET_RFR.  This enables flow regardless of
the current configuration, and would undo a previous flow disable
operation.  It should instead de-assert RFR via RESET_RFR to block flow
until the hardware is reconfigured.  msm_serial should rely on the client
to specify that flow should be enabled, either via mctrl() or the termios
structure, and only assert RFR in response to those triggers.

Fixes: 04896a77 ("msm_serial: serial driver for MSM7K onboard serial peripheral.")
Signed-off-by: NJeffrey Hugo <jeffrey.l.hugo@gmail.com>
Reviewed-by: NBjorn Andersson <bjorn.andersson@linaro.org>
Cc: stable <stable@vger.kernel.org>
Reviewed-by: NAndy Gross <agross@kernel.org>
Link: https://lore.kernel.org/r/20191021154616.25457-1-jeffrey.l.hugo@gmail.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

This commits adds RS485 support for LPUART hardware that uses 32-bit
registers. These are typically found in i.MX8 processors.
Signed-off-by: NPhilippe Schenker <philippe.schenker@toradex.com>
Reviewed-by: NFugang Duan <fugang.duan@nxp.com>

Link: https://lore.kernel.org/r/20191017141428.10330-3-philippe.schenker@toradex.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Use define from the 32-bit register description UARTMODIR_* instead of
UARTMODEM_*. The value is the same, so there is no functional change.
Signed-off-by: NPhilippe Schenker <philippe.schenker@toradex.com>
Reviewed-by: NStefan Agner <stefan.agner@toradex.com>
Reviewed-by: NFugang Duan <fugang.duan@nxp.com>

Link: https://lore.kernel.org/r/20191017141428.10330-2-philippe.schenker@toradex.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Currently flow control is not working due to lpuart32_set_mctrl that is
clearing TXCTSE bit in all cases. This bit gets earlier setup by
lpuart32_set_termios.

As I read in Documentation set_mctrl is also not meant for hardware
flow control rather than gpio setting and clearing a RTS signal.
Therefore I guess it is safe to remove the whole code in
lpuart32_set_mctrl.

This was tested with console on a i.MX8QXP SoC.
Signed-off-by: NPhilippe Schenker <philippe.schenker@toradex.com>
Reviewed-by: NFugang Duan <fugang.duan@nxp.com>

Link: https://lore.kernel.org/r/20191017141428.10330-1-philippe.schenker@toradex.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

For consistency reasons, spell the controller name as "LINFlexD" in
comments and documentation.
Signed-off-by: NStefan-Gabriel Mirea <stefan-gabriel.mirea@nxp.com>
Link: https://lore.kernel.org/r/1571230107-8493-4-git-send-email-stefan-gabriel.mirea@nxp.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

This reverts commit 91daae03.

The origin patch is causing an issue on r8a7791/koelsch and
r8a7795/salvator-xs platforms where cons->index is not initialized to
expected value.
It is safer to revert this patch for now till it is clear why this is
happening.
Reported-by: NGeert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: NMichal Simek <michal.simek@xilinx.com>
Link: https://lore.kernel.org/r/59f51af6bb03fce823663764d17ad0291aa01ab2.1571222199.git.michal.simek@xilinx.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The current checking for failure on the number of ports fails when
-ENODEV is returned from the call to get_num_ports. Fix this by making
num_ports and loop counter i signed rather than unsigned ints. Also
add check for num_ports being less than zero to check for -ve error
returns.

Addresses-Coverity: ("Unsigned compared against 0")
Fixes: e2fea54e ("8250-men-mcb: add support for 16z025 and 16z057")
Signed-off-by: NColin Ian King <colin.king@canonical.com>
Reviewed-by: NMichael Moese <mmoese@suse.de>
Link: https://lore.kernel.org/r/20191013220016.9369-1-colin.king@canonical.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

There is a one more step to consolidate Exar bits under 8250_exar umbrella.
This time we introduce a custom ->startup() callback where the Exar specific
settings are applied.

Cc: Robert Middleton <robert.middleton@rm5248.com>
Cc: Sudip Mukherjee <sudip.mukherjee@codethink.co.uk>
Cc: Aaron Sierra <asierra@xes-inc.com>
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://lore.kernel.org/r/20191011115610.81507-1-andriy.shevchenko@linux.intel.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The sirfsoc_usp and sirfsoc_uart objects are not
used outside of the drivers/tty/serial/sirfsoc_uart.o
so make them static. Fixes following sparse warnings:

drivers/tty/serial/sirfsoc_uart.h:123:30: warning: symbol 'sirfsoc_usp' was not declared. Should it be static?
drivers/tty/serial/sirfsoc_uart.h:189:30: warning: symbol 'sirfsoc_uart' was not declared. Should it be static?
Signed-off-by: NBen Dooks <ben.dooks@codethink.co.uk>
Link: https://lore.kernel.org/r/20191009135356.11180-1-ben.dooks@codethink.co.ukSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Add system wakeup capability over UART RX line for wakeup capable UART.
When system is suspended, RX line act as an interrupt to wakeup system
for any communication requests from peer.
Signed-off-by: NAkash Asthana <akashast@codeaurora.org>
Link: https://lore.kernel.org/r/1570700803-17566-1-git-send-email-akashast@codeaurora.orgSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Move ISR registration from startup to probe function to avoid registering
it everytime when the port open is called for driver.
Signed-off-by: NAkash Asthana <akashast@codeaurora.org>
Link: https://lore.kernel.org/r/1570700763-17319-1-git-send-email-akashast@codeaurora.orgSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

All i.MX SoCs except i.MX1 have ONLY one necessary IRQ, use
platform_get_irq_optional() to get second/third IRQ which are
optional to avoid below error message during probe:

[    0.726219] imx-uart 30860000.serial: IRQ index 1 not found
[    0.731329] imx-uart 30860000.serial: IRQ index 2 not found

Fixes: 7723f4c5 ("driver core: platform: Add an error message to platform_get_irq*()")
Signed-off-by: NAnson Huang <Anson.Huang@nxp.com>
Link: https://lore.kernel.org/r/1570614559-11900-1-git-send-email-Anson.Huang@nxp.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Fix Sphinx warning in serial_core.c:

../drivers/tty/serial/serial_core.c:1969: WARNING: Definition list ends without a blank line; unexpected unindent.

Fixes: 73abaf87 ("serial: earlycon: Refactor parse_options into serial core")
Signed-off-by: NRandy Dunlap <rdunlap@infradead.org>
Cc: Peter Hurley <peter@hurleysoftware.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Link: https://lore.kernel.org/r/e989641c-224a-1090-e596-e7cc800bed44@infradead.orgSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

There are two checks to see if the manual gpio is configured, but
these the check is seeing if the structure is NULL instead it
should check to see if there are CTS and/or RTS pins defined.

This patch uses checks for those individual pins instead of
checking for the structure itself to restore auto RTS/CTS.
Signed-off-by: NAdam Ford <aford173@gmail.com>
Reviewed-by: NYegor Yefremov <yegorslists@googlemail.com>
Link: https://lore.kernel.org/r/20191006163314.23191-2-aford173@gmail.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

When using mctrl_gpio_to_gpiod, it dereferences gpios into a single
requested GPIO.  This dereferencing can break if gpios is NULL,
so this patch adds a NULL check before dereferencing it.  If
gpios is NULL, this function will also return NULL.
Signed-off-by: NAdam Ford <aford173@gmail.com>
Reviewed-by: NYegor Yefremov <yegorslists@googlemail.com>
Link: https://lore.kernel.org/r/20191006163314.23191-1-aford173@gmail.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Fix incorrect read-modify-write sequence in lpuart_flush_buffer() that
was reading from UARTPFIFO and writing to UARTCFIFO instead of
operating solely on the latter.

Fixes: 9bc19af9 ("tty: serial: fsl_lpuart: Flush HW FIFOs in .flush_buffer")
Signed-off-by: NAndrey Smirnov <andrew.smirnov@gmail.com>
Reported-by: NVivien Didelot <vivien.didelot@gmail.com>
Tested-by: NVivien Didelot <vivien.didelot@gmail.com>
Tested-by: NAndrew Lunn <andrew@lunn.ch>
Reviewed-by: NFabio Estevam <festevam@gmail.com>
Cc: Stefan Agner <stefan@agner.ch>
Cc: Chris Healy <cphealy@gmail.com>
Cc: Cory Tusar <cory.tusar@zii.aero>
Cc: Lucas Stach <l.stach@pengutronix.de>
Cc: Jiri Slaby <jslaby@suse.com>
Link: https://lore.kernel.org/r/20191004215537.5308-1-andrew.smirnov@gmail.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

There are two parts which should be fixed. The first one is to assigned
uartps_major at the end of probe() to avoid complicated logic when
something fails.
The second part is initialized uartps_major number to 0 when last device is
removed. This will ensure that on next probe driver will ask for new
dynamic major number.

Fixes: ab262666 ("serial: uartps: Use the same dynamic major number for all ports")
Reported-by: NPaul Thomas <pthomas8589@gmail.com>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: NMichal Simek <michal.simek@xilinx.com>
Link: https://lore.kernel.org/r/d2652cda992833315c4f96f06953eb547f928918.1570194248.git.michal.simek@xilinx.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Make the SIRQ polarity for Aspeed AST24xx/25xx VUART configurable via
sysfs. This setting need to be changed on specific host platforms
depending on the selected host interface (LPC / eSPI).

The setting is configurable via sysfs rather than device-tree to stay in
line with other related configurable settings.

On AST2500 the VUART SIRQ polarity can be auto-configured by reading a
bit from a configuration register, e.g. the LPC/eSPI interface
configuration bit.

Tested: Verified on TYAN S7106 mainboard.
Signed-off-by: NOskar Senft <osk@google.com>
Link: https://lore.kernel.org/r/20190905144130.220713-1-osk@google.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Call uart_unregister_driver() conditionally instead of
unconditionally, only if it has been previously registered.

This uses driver.state, just as the sh-sci.c driver does.

Fixes this null pointer dereference in tty_unregister_driver(),
since the 'driver' argument is null:

  general protection fault: 0000 [#1] PREEMPT SMP KASAN PTI
  RIP: 0010:tty_unregister_driver+0x25/0x1d0

Fixes: 238b8721 ("[PATCH] serial uartlite driver")
Signed-off-by: NRandy Dunlap <rdunlap@infradead.org>
Cc: stable <stable@vger.kernel.org>
Cc: Peter Korsgaard <jacmet@sunsite.dk>
Link: https://lore.kernel.org/r/9c8e6581-6fcc-a595-0897-4d90f5d710df@infradead.orgSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Following an incorrect indentation reported to me by Dan Carpenter, I
noticed that the SysRq lines were inherited from the lpuart driver[1] (note
how the 'continue' is aligned to 'sport->port.sysrq = 0') and we have never
actually tested the SysRq support.

'sport->sysrq = 0' is not necessary neither before nor after 'continue',
because sysrq will already be 0 after uart_handle_sysrq_char() will finish.
Also, since the LINFlexD driver never called uart_handle_break(), sysrq
would have never been set to a nonzero value, so uart_handle_sysrq_char()
was not going to do anything.

Break conditions are detected based on a null data byte along with a
framing error (stop bit sampled to 0).

[1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/tty/serial/fsl_lpuart.c?h=b3e3bf2ef2c74f5ce5c19510edbbb9bfc1d249c2#n659

Fixes: 09864c1c ("tty: serial: Add linflexuart driver for S32V234")
Signed-off-by: NStefan-Gabriel Mirea <stefan-gabriel.mirea@nxp.com>
Reported-by: Nkbuild test robot <lkp@intel.com>
Reported-by: NDan Carpenter <dan.carpenter@oracle.com>
Link: https://lore.kernel.org/r/20190918184439.7465-1-stefan-gabriel.mirea@nxp.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

As platform_get_irq() now prints an error when the interrupt does not
exist, scary warnings may be printed for optional interrupts:

    sh-sci e6550000.serial: IRQ index 1 not found
    sh-sci e6550000.serial: IRQ index 2 not found
    sh-sci e6550000.serial: IRQ index 3 not found
    sh-sci e6550000.serial: IRQ index 4 not found
    sh-sci e6550000.serial: IRQ index 5 not found

Fix this by calling platform_get_irq_optional() instead for all but the
first interrupts, which are optional.

Fixes: 7723f4c5 ("driver core: platform: Add an error message to platform_get_irq*()")
Signed-off-by: NGeert Uytterhoeven <geert+renesas@glider.be>
Reviewed-by: NStephen Boyd <swboyd@chromium.org>
Reviewed-by: NYoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Tested-by: NYoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Link: https://lore.kernel.org/r/20191001180743.1041-1-geert+renesas@glider.beSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The sifive serial driver implements earlycon support, but unless
another driver is built in that supports earlycon support it won't
be usable.  Explicitly select SERIAL_EARLYCON instead.
Signed-off-by: NChristoph Hellwig <hch@lst.de>
Reviewed-by: NPaul Walmsley <paul.walmsley@sifive.com>
Link: https://lore.kernel.org/r/20190910055923.28384-1-hch@lst.deSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

'exit' functions should be marked as __exit, not __init.

Fixes: c10b1332 ("tty: serial: Add RDA8810PL UART driver")
Signed-off-by: NChristophe JAILLET <christophe.jaillet@wanadoo.fr>
Link: https://lore.kernel.org/r/20190910041702.7357-1-christophe.jaillet@wanadoo.frSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

'exit' functions should be marked as __exit, not __init.

Fixes: fc60a8b6 ("tty: serial: owl: Implement console driver")
Signed-off-by: NChristophe JAILLET <christophe.jaillet@wanadoo.fr>
Link: https://lore.kernel.org/r/20190910041129.6978-1-christophe.jaillet@wanadoo.frSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Simplify the code which fetches the input clock by using
devm_clk_get_optional(). This comes with a small functional change: previously
all errors were ignored except deferred probe. Now all errors are
treated as errors. If no input clock is present devm_clk_get_optional() will
return NULL instead of an error which matches the behavior of the old code.
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://lore.kernel.org/r/20190925162617.30368-1-andriy.shevchenko@linux.intel.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Some devices support MSI interrupts. Let's at least try to use them in
platforms that provide MSI capability.

While at that, remove the now duplicated code from qrp_serial_setup().
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>
Link: https://lore.kernel.org/r/20191001115825.795700-1-felipe.balbi@linux.intel.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

pl011_dma_probe() is only used in pl011_dma_startup() which does only
exist when CONFIG_DMA_ENGINE=y, so remove the unused dummy version to
silence the warning.
Signed-off-by: NQian Cai <cai@lca.pw>
Link: https://lore.kernel.org/r/1568726340-4518-1-git-send-email-cai@lca.pwSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The reason for this patch is xilinx_uartps driver which create one dynamic
instance per IP with unique major and minor combinations. drv->nr is in
this case all the time setup to 1. That means that uport->line is all the
time setup to 0 and drv->tty_driver->name_base is doing shift in name to
for example ttyPS3.

register_console() is looping over console_cmdline array and looking for
proper name/index combination which is in our case ttyPS/3.
That's why every instance of driver needs to be registered with proper
combination of name/number (ttyPS/3). Using uport->line is doing
registration with ttyPS/0 which is wrong that's why proper console index
should be used which is in cons->index field.

Also it is visible that recording console should be done based on
information about console not about the port but in most cases numbers are
the same and xilinx_uartps is only one exception now.
Signed-off-by: NMichal Simek <michal.simek@xilinx.com>
Link: https://lore.kernel.org/r/4a877f1c7189a7c45b59a6ebfc3de607e8758949.1567434470.git.michal.simek@xilinx.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Use software emulated RS485 direction control to provide RS485 API

Currently it is not possible to use rs485 as pointer to
rs485_config struct in struct uart_port is NULL in case we
configure the port through device tree.
Signed-off-by: NHeiko Schocher <hs@denx.de>

Link: https://lore.kernel.org/r/20190913050105.1132080-1-hs@denx.deSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

In order to access the UART without the interrupts, the kernel uses
the basic polling methods for IO with the device. With these methods
implemented, it is now possible to enable kgdb during early boot over serial.
Signed-off-by: NLanqing Liu <liuhhome@gmail.com>
Reviewed-by: NBaolin Wang <baolin.wang@linaro.org>
Tested-by: NBaolin Wang <baolin.wang@linaro.org>
Link: https://lore.kernel.org/r/f112a741c053ac5fb0637e2f058be81e17f78ccc.1568862391.git.liuhhome@gmail.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Using only 4 DMA periods for UART RX is very few if we have a high
frequency of small transfers - like in our case using Bluetooth with
many small packets via UART - causing many dma transfers but in each
only filling a fraction of a single buffer. Such a case may lead to
the situation that DMA RX transfer is triggered but no free buffer is
available. When this happens dma channel ist stopped - with the patch
"dmaengine: imx-sdma: fix dma freezes" temporarily only - with the
possible consequences that:
with disabled hw flow control:
  If enough data is incoming on UART port the RX FIFO runs over and
  characters will be lost. What then happens depends on upper layer.

with enabled hw flow control:
  If enough data is incoming on UART port the RX FIFO reaches a level
  where CTS is deasserted and remote device sending the data stops.
  If it fails to stop timely the i.MX' RX FIFO may run over and data
  get lost. Otherwise it's internal TX buffer may getting filled to
  a point where it runs over and data is again lost. It depends on
  the remote device how this case is handled and if it is recoverable.

Obviously we want to avoid having no free buffers available. So we
decrease the size of the buffers and increase their number and the
total buffer size.
Signed-off-by: NPhilipp Puschmann <philipp.puschmann@emlix.com>
Reviewed-by: NLucas Stach <l.stach@pengutronix.de>
Link: https://lore.kernel.org/r/20190923135916.1212-1-philipp.puschmann@emlix.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Add PIO mode support in receive and transmit path with RX interrupt
trigger of 16 bytes for Tegra194 and older chips.
Signed-off-by: NShardar Shariff Md <smohammed@nvidia.com>
Signed-off-by: NKrishna Yarlagadda <kyarlagadda@nvidia.com>
Link: https://lore.kernel.org/r/1567572187-29820-13-git-send-email-kyarlagadda@nvidia.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Standard UART controllers support +/-4% baud rate error tolerance.
Tegra186 only supports 0% to +4% error tolerance whereas other Tegra
chips support standard +/-4% rate. Add chip data for knowing error
tolerance level for each soc. Creating new compatible for Tegra194
chip as it supports baud rate error tolerance of -2 to +2%, different
from older chips.
Signed-off-by: NShardar Shariff Md <smohammed@nvidia.com>
Signed-off-by: NKrishna Yarlagadda <kyarlagadda@nvidia.com>
Link: https://lore.kernel.org/r/1567572187-29820-12-git-send-email-kyarlagadda@nvidia.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Add support to adjust baud rates to fall under supported tolerance
range through DT.

Tegra186 chip has a hardware issue resulting in frame errors when
tolerance level for baud rate is negative. Provided entries to adjust
baud rate to be within acceptable range and work with devices that
can send negative baud rate. Also report error when baud rate set is
out of tolerance range of controller updated in device tree.
Signed-off-by: NShardar Shariff Md <smohammed@nvidia.com>
Signed-off-by: NKrishna Yarlagadda <kyarlagadda@nvidia.com>
Link: https://lore.kernel.org/r/1567572187-29820-11-git-send-email-kyarlagadda@nvidia.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Add support to use 8 bytes trigger for Tegra186 SOC.
Signed-off-by: NShardar Shariff Md <smohammed@nvidia.com>
Signed-off-by: NKrishna Yarlagadda <kyarlagadda@nvidia.com>
Link: https://lore.kernel.org/r/1567572187-29820-9-git-send-email-kyarlagadda@nvidia.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Set maximum number of UART ports to 8 as older chips have 5 ports and
Tergra186 and later chips will have 8 ports. Add this info to chip
data. Read device tree compatible of this driver and register uart
driver with max ports of matching chip data.
Signed-off-by: NShardar Shariff Md <smohammed@nvidia.com>
Signed-off-by: NKrishna Yarlagadda <kyarlagadda@nvidia.com>
Link: https://lore.kernel.org/r/1567572187-29820-8-git-send-email-kyarlagadda@nvidia.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Chips prior to Tegra186 needed delay of 3 UART clock cycles to avoid
data loss. This issue is fixed in Tegra186 and a new flag is added to
check if FIFO mode is enabled. chip data updated to check if this flag
is available for a chip. Tegra186 has new compatible to enable this
flag.
Signed-off-by: NShardar Shariff Md <smohammed@nvidia.com>
Signed-off-by: NKrishna Yarlagadda <kyarlagadda@nvidia.com>
Link: https://lore.kernel.org/r/1567572187-29820-7-git-send-email-kyarlagadda@nvidia.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>