The LPUART doesn't have the ability to control the RTS or CTS line
manually. Instead it will set it automatically when data is send or
handle it when data is received. Thus drop the wrong code in set_mctrl.
For the 32 bit version this was already done in the commit 2b30efe2
("tty: serial: lpuart: Remove unnecessary code from set_mctrl"). Keep
the 8-bit version in sync and remove it there, too.
Signed-off-by: NMichael Walle <michael@walle.cc>
Link: https://lore.kernel.org/r/20210512141255.18277-8-michael@walle.ccSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The wrong code in set_mctrl() was already removed in commit 2b30efe2
("tty: serial: lpuart: Remove unnecessary code from set_mctrl"), but the
code in get_mctrl() wasn't removed. It will not return the state of the
RTS or CTS line but whether automatic flow control is enabled, which is
wrong for the get_mctrl(). Thus remove it.

Fixes: 2b30efe2 ("tty: serial: lpuart: Remove unnecessary code from set_mctrl")
Signed-off-by: NMichael Walle <michael@walle.cc>
Link: https://lore.kernel.org/r/20210512141255.18277-7-michael@walle.ccSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Although there is already sysrq characters handling, a break condition
was never detected. Add support for it.

The LPUART can't distinguish between a framing error and a break
condition. We assume it is a break if the received data is all zero.
Signed-off-by: NMichael Walle <michael@walle.cc>
Link: https://lore.kernel.org/r/20210512141255.18277-6-michael@walle.ccSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Instead of uart_handle_sysrq_char() use uart_prepare_sysrq_char() and
uart_unlock_and_check_sysrq(). This will call handle_sysrq() without
holding the port lock, which in turn let us drop the spin_trylock hack.
Suggested-by: NJohan Hovold <johan@kernel.org>
Signed-off-by: NMichael Walle <michael@walle.cc>
Link: https://lore.kernel.org/r/20210512141255.18277-5-michael@walle.ccSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

>From commit 75f4e830 ("serial: do not restore interrupt state in
sysrq helper"):

  Since commit 81e2073c ("genirq: Disable interrupts for force
  threaded handlers") interrupt handlers that are not explicitly
  requested as threaded are always called with interrupts disabled and
  there is no need to save the interrupt state when taking the port
  lock.

Apply this also to fsl_lpuart in prepartion for sysrq handling with
uart_unlock_and_check_sysrq().
Signed-off-by: NMichael Walle <michael@walle.cc>
Link: https://lore.kernel.org/r/20210512141255.18277-4-michael@walle.ccSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Use the corresponding macro instead of the magic number. While at it,
drop the useless cast to "unsigned char".
Signed-off-by: NMichael Walle <michael@walle.cc>
Link: https://lore.kernel.org/r/20210512141255.18277-3-michael@walle.ccSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

lpuart_rx_dma_startup() is used for both the 8 bit and the 32 bit
version of the LPUART. Modify the UARTCR only for the 8 bit version.

Fixes: f4eef224 ("serial: fsl_lpuart: add sysrq support when using dma")
Signed-off-by: NMichael Walle <michael@walle.cc>
Link: https://lore.kernel.org/r/20210512141255.18277-2-michael@walle.ccSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

We should be very careful about the register values that will be used
for division or modulo operations, althrough the possibility that the
UARTBAUD register value is zero is very low, but we had better to deal
with the "bad data" of hardware in advance to avoid division or modulo
by zero leading to undefined kernel behavior.
Signed-off-by: NSherry Sun <sherry.sun@nxp.com>
Link: https://lore.kernel.org/r/20210427021226.27468-1-sherry.sun@nxp.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The retrieval of driver data via of_device_get_match_data() can make
the code simpler.

Use of_device_get_match_data() to simplify the code.
Signed-off-by: NFabio Estevam <festevam@gmail.com>
Link: https://lore.kernel.org/r/20210118124447.1632092-1-festevam@gmail.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Prior to the commit that this one fixes, the FIFO size was derived from
the read-only register LPUARTx_FIFO[TXFIFOSIZE] using the following
formula:

TX FIFO size = 2 ^ (LPUARTx_FIFO[TXFIFOSIZE] - 1)

The documentation for LS1021A is a mess. Under chapter 26.1.3 LS1021A
LPUART module special consideration, it mentions TXFIFO_SZ and RXFIFO_SZ
being equal to 4, and in the register description for LPUARTx_FIFO, it
shows the out-of-reset value of TXFIFOSIZE and RXFIFOSIZE fields as "011",
even though these registers read as "101" in reality.

And when LPUART on LS1021A was working, the "101" value did correspond
to "16 datawords", by applying the formula above, even though the
documentation is wrong again (!!!!) and says that "101" means 64 datawords
(hint: it doesn't).

So the "new" formula created by commit f77ebb24 has all the premises
of being wrong for LS1021A, because it relied only on false data and no
actual experimentation.

Interestingly, in commit c2f448cf ("tty: serial: fsl_lpuart: add
LS1028A support"), Michael Walle applied a workaround to this by manually
setting the FIFO widths for LS1028A. It looks like the same values are
used by LS1021A as well, in fact.

When the driver thinks that it has a deeper FIFO than it really has,
getty (user space) output gets truncated.

Many thanks to Michael for pointing out where to look.

Fixes: f77ebb24 ("tty: serial: fsl_lpuart: correct the FIFO depth size")
Suggested-by: NMichael Walle <michael@walle.cc>
Signed-off-by: NVladimir Oltean <vladimir.oltean@nxp.com>
Link: https://lore.kernel.org/r/20201023013429.3551026-1-vladimir.oltean@nxp.com
Reviewed-by：Fugang Duan <fugang.duan@nxp.com>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Add handling of magic sysrq keys when using dma/edma.

Tested by sending BREAK followed by a sysrq command inside
a 5 secs time window, by:

echo 1 > /proc/sys/kernel/sysrq

BREAK + h, t, e, b, c

Tested also sending a command after 5 secs after BREAK, that's
properly ignored.
Signed-off-by: NAngelo Dureghello <angelo.dureghello@timesys.com>
Link: https://lore.kernel.org/r/20201004161144.1307174-1-angelo.dureghello@timesys.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The watermark is set to 1, so we need to input two chars to trigger RDRF
using the original logic. With the new logic, we could always get the
char when there is data in FIFO.
Suggested-by: NFugang Duan <fugang.duan@nxp.com>
Signed-off-by: NPeng Fan <peng.fan@nxp.com>
Link: https://lore.kernel.org/r/20200929095509.21680-1-peng.fan@nxp.com
Cc: stable <stable@vger.kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The 2nd and 3rd parameter were wrongly used, and cause kernel abort when
doing kgdb debug.

Fixes: 1da17d7c ("tty: serial: fsl_lpuart: Use appropriate lpuart32_* I/O funcs")
Cc: stable <stable@vger.kernel.org>
Signed-off-by: NPeng Fan <peng.fan@nxp.com>
Link: https://lore.kernel.org/r/20200929091920.22612-1-peng.fan@nxp.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Fix two occurrences where "transfer" is spelled incorrectly.
Signed-off-by: NFabio Estevam <festevam@gmail.com>
Link: https://lore.kernel.org/r/20200818224457.16507-1-festevam@gmail.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The formula for the baud rate is
baud rate = "baud clock / ((OSR+1) × SBR)

Algorithm used in function lpuart32_serial_setbrg() only changes
the SBR. Even with maxmum value put in, OSR stays at 0x7 and the
lowest baud rate would be ~ 2600 bps

Update the algorithm to allow driver operation at 1200,2400 or 600 bps
Signed-off-by: NVabhav Sharma <vabhav.sharma@nxp.com>
Link: https://lore.kernel.org/r/1593170434-13524-1-git-send-email-vabhav.sharma@oss.nxp.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Use __maybe_unused for power management related functions to simplify
the code.
Signed-off-by: NAnson Huang <Anson.Huang@nxp.com>
Link: https://lore.kernel.org/r/1589547481-25932-1-git-send-email-Anson.Huang@nxp.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

We're about to amend uart_get_rs485_mode() to support a GPIO pin for
rs485 bus termination.  Retrieving the GPIO descriptor may fail, so
allow uart_get_rs485_mode() to return an errno and change all callers
to check for failure.

The GPIO descriptor is going to be stored in struct uart_port.  Pass
that struct to uart_get_rs485_mode() in lieu of a struct device and
struct serial_rs485, both of which are directly accessible from struct
uart_port.

A few drivers call uart_get_rs485_mode() before setting the struct
device pointer in struct uart_port.  Shuffle those calls around where
necessary.

[Heiko Stuebner did the ar933x_uart.c portion, hence his Signed-off-by.]
Signed-off-by: NHeiko Stuebner <heiko@sntech.de>
Signed-off-by: NLukas Wunner <lukas@wunner.de>
Link: https://lore.kernel.org/r/271e814af4b0db3bffbbb74abf2b46b75add4516.1589285873.git.lukas@wunner.deSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Currently the following messages are seen when booting i.MX8QXP:

fsl-lpuart 5a060000.serial: DMA tx channel request failed, operating without tx DMA (-19)
fsl-lpuart 5a060000.serial: DMA rx channel request failed, operating without rx DMA (-19)

It is not really useful to have such messages on every boot, so change
them to debug level instead.
Signed-off-by: NFabio Estevam <festevam@gmail.com>
Link: https://lore.kernel.org/r/20200416153453.18825-1-festevam@gmail.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Coverity reports the following:

  var_compare_op: Comparing chan to null implies that chan might be null.

  1234        if (chan)
  1235                dmaengine_terminate_all(chan);
  1236

  Dereference after null check (FORWARD_NULL)
  var_deref_op: Dereferencing null pointer chan.

  1237        dma_unmap_sg(chan->device->dev, &sport->rx_sgl, 1, DMA_FROM_DEVICE);

Technically, this is correct. But lpuart_dma_rx_free() is guarded by
lpuart_dma_rx_use which is only true if there is a dma channel, see
lpuart_rx_dma_startup(). In any way, this looks bogus. So remove
the superfluous "if (chan)" check and make coverity happy.

Fixes: a092ab25 ("tty: serial: fsl_lpuart: fix DMA mapping")
Signed-off-by: NMichael Walle <michael@walle.cc>
Reported-by: NColin Ian King <colin.king@canonical.com>
Acked-by: NJiri Slaby <jslaby@suse.cz>
Reviewed-by: NFabio Estevam <festevam@gmail.com>
Link: https://lore.kernel.org/r/20200403174942.9594-1-michael@walle.ccSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The return value of lpuart_dma_tx_request() is an negative errno on
failure and zero on success.

Fixes: 159381df ("tty: serial: fsl_lpuart: fix DMA operation when using IOMMU")
Reported-by: NLeonard Crestez <leonard.crestez@nxp.com>
Signed-off-by: NMichael Walle <michael@walle.cc>
Reviewed-by: NFugang Duan <fugang.duan@nxp.com>
Link: https://lore.kernel.org/r/20200325090658.25967-2-michael@walle.ccSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Move dma_request_chan() out of the atomic context. First this call
should not be in the atomic context at all and second the
dev_info_once() may cause a hang because because the console takes this
spinlock, too.

Fixes: 159381df ("tty: serial: fsl_lpuart: fix DMA operation when using IOMMU")
Reported-by: NLeonard Crestez <leonard.crestez@nxp.com>
Signed-off-by: NMichael Walle <michael@walle.cc>
Reviewed-by: NFugang Duan <fugang.duan@nxp.com>
Tested-by: NLeonard Crestez <leonard.crestez@nxp.com>
Link: https://lore.kernel.org/r/20200325090658.25967-1-michael@walle.ccSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Add a early_console_setup() for the LS1028A SoC with 32bit, little
endian access. If the bootloader does a fixup of the clock-frequency
node the baudrate divisor register will automatically be set.
Signed-off-by: NMichael Walle <michael@walle.cc>
Link: https://lore.kernel.org/r/20200306214433.23215-5-michael@walle.ccSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The LS1028A uses little endian register access and has a different FIFO
size encoding.
Signed-off-by: NMichael Walle <michael@walle.cc>
Link: https://lore.kernel.org/r/20200306214433.23215-4-michael@walle.ccSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Use the correct device to request the DMA mapping. Otherwise the IOMMU
doesn't get the mapping and it will generate a page fault.

The error messages look like:
[   19.012140] arm-smmu 5000000.iommu: Unhandled context fault: fsr=0x402, iova=0xbbfff800, fsynr=0x3e0021, cbfrsynra=0x828, cb=9
[   19.023593] arm-smmu 5000000.iommu: Unhandled context fault: fsr=0x402, iova=0xbbfff800, fsynr=0x3e0021, cbfrsynra=0x828, cb=9

This was tested on a custom board with a LS1028A SoC.
Signed-off-by: NMichael Walle <michael@walle.cc>
Link: https://lore.kernel.org/r/20200306214433.23215-3-michael@walle.ccSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The DMA channel might not be available at probe time. This is esp. the
case if the DMA controller has an IOMMU mapping.

There is also another caveat. If there is no DMA controller at all,
dma_request_chan() will also return -EPROBE_DEFER. Thus we cannot test
for -EPROBE_DEFER in probe(). Otherwise the lpuart driver will fail to
probe if, for example, the DMA driver is not enabled in the kernel
configuration.

To workaround this, we request the DMA channel in _startup(). Other
serial drivers do it the same way.
Signed-off-by: NMichael Walle <michael@walle.cc>
Link: https://lore.kernel.org/r/20200306214433.23215-2-michael@walle.ccSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Since commit 3bc3206e ("serial: fsl_lpuart: Remove the alias node
dependence") the port line number can also be allocated by IDA, but in
case of an error the ID will no be removed again. More importantly, any
ID will be freed in remove(), even if it wasn't allocated but instead
fetched by of_alias_get_id(). If it was not allocated by IDA there will
be a warning:
  WARN(1, "ida_free called for id=%d which is not allocated.\n", id);

Move the ID allocation more to the end of the probe() so that we still
can use plain return in the first error cases.

Fixes: 3bc3206e ("serial: fsl_lpuart: Remove the alias node dependence")
Signed-off-by: NMichael Walle <michael@walle.cc>
Cc: stable <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20200303174306.6015-3-michael@walle.ccSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

This reverts commit a659652f.

This broke the earlycon on LS1021A processors because the order of the
earlycon_setup() functions were changed. Before the commit the normal
lpuart32_early_console_setup() was called. After the commit the
lpuart32_imx_early_console_setup() is called instead.

Fixes: a659652f ("tty: serial: fsl_lpuart: drop EARLYCON_DECLARE")
Signed-off-by: NMichael Walle <michael@walle.cc>
Link: https://lore.kernel.org/r/20200303174306.6015-2-michael@walle.ccSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

i.MX8QXP lpuart is compatible with i.MX7ULP, so no need
an extra  entry for i.MX8QXP.
Signed-off-by: NPeng Fan <peng.fan@nxp.com>
Link: https://lore.kernel.org/r/1576822230-23125-4-git-send-email-peng.fan@nxp.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

"earlycon" no need to specify the value string since it uses
stdout-path parameters. However when earlycon and normal console
are not using the same uart port, we need specify value string
to earlycon, this is what we need to do when support dual linux
using jailhouse hypervisor. The 2nd linux will use the uart
of the 1st linux as earlycon.

earlycon=lpuart32,mmio32,0x5a060010,115200 not work for i.MX8QXP.
It is because lpuart32_early_console_setup not support little endian.

Since the original code is to support UPIO_MEM32BE, so if not
UPIO_MEM32, we still take it as UPIO_MEM32BE
Acked-by: NFugang Duan <fugang.duan@nxp.com>
Signed-off-by: NPeng Fan <peng.fan@nxp.com>
Link: https://lore.kernel.org/r/1576822230-23125-3-git-send-email-peng.fan@nxp.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

EARLYCON_DECLARE is just a wrapper of OF_EARLYCON_DECLARE,
since we already have OF_EARLYCON_DECLARE for lpuart and lpuart32,
so no need EARLYCON_DECLARE.
Signed-off-by: NPeng Fan <peng.fan@nxp.com>
Link: https://lore.kernel.org/r/1576822230-23125-2-git-send-email-peng.fan@nxp.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The SUPPORT_SYSRQ ifdeffery is not nice as:
- May create misunderstanding about sizeof(struct uart_port) between
  different objects
- Prevents moving functions from serial_core.h
- Reduces readability (well, it's ifdeffery - it's hard to follow)

In order to remove SUPPORT_SYSRQ, has_sysrq variable has been added.
Initialise it in driver's probe and remove ifdeffery.
Signed-off-by: NDmitry Safonov <dima@arista.com>
Link: https://lore.kernel.org/r/20191213000657.931618-19-dima@arista.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The dmaengine_prep_slave_sg needs to use sg count returned
by dma_map_sg, not use sport->dma_tx_nents, because the return
value of dma_map_sg is not always same with "nents".

When enabling iommu for lpuart + edma, iommu framework may concatenate
two sgs into one.

Fixes: 6250cc30 ("tty: serial: fsl_lpuart: Use scatter/gather DMA for Tx")
Cc: <stable@vger.kernel.org>
Signed-off-by: NPeng Fan <peng.fan@nxp.com>
Link: https://lore.kernel.org/r/1572932977-17866-1-git-send-email-peng.fan@nxp.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>

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>

In a mixed DMA/IRQ use-case (e.g.: DMA for TX, IRQ for RX), interrupt
handler might try to handle Rx/Tx condition it shouldn't. Change the
code to only handle TX/RX event if corresponding path isn't being
handled by DMA.
Signed-off-by: NAndrey Smirnov <andrew.smirnov@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: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Jiri Slaby <jslaby@suse.com>
Cc: linux-imx@nxp.com
Cc: linux-serial@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Link: https://lore.kernel.org/r/20190805185701.22863-7-andrew.smirnov@gmail.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Enabling TIE in .startup() callback causes the driver to start (or at
least try) to transmit data before .start_tx() is called. Which, while
harmless (since TIE handler will immediately disable it), is a no-op
and shouldn't really happen. Drop UARTCR2_TIE from list of bits set in
lpuart_startup().

This change will also not enable TIE in .resume(), but it seems that,
similart to .startup(), transmit interrupt shouldn't be enabled there
either.
Signed-off-by: NAndrey Smirnov <andrew.smirnov@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: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Jiri Slaby <jslaby@suse.com>
Cc: linux-imx@nxp.com
Cc: linux-serial@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Link: https://lore.kernel.org/r/20190805185701.22863-6-andrew.smirnov@gmail.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Most users of lpuart*_setup_watermark() enable identical set of flags
right after the call, so combine those two action into a subroutine
and make use of it.
Signed-off-by: NAndrey Smirnov <andrew.smirnov@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: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Jiri Slaby <jslaby@suse.com>
Cc: linux-imx@nxp.com
Cc: linux-serial@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Link: https://lore.kernel.org/r/20190805185701.22863-5-andrew.smirnov@gmail.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Code doing final steps of TX/RX configuration in lpuart32_startup()
and lpuart_resume() is identical, so move it into a standalone
subroutine.
Signed-off-by: NAndrey Smirnov <andrew.smirnov@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: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Jiri Slaby <jslaby@suse.com>
Cc: linux-imx@nxp.com
Cc: linux-serial@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Link: https://lore.kernel.org/r/20190805185701.22863-4-andrew.smirnov@gmail.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>