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>

Add ACCES VIDs and PIDs that use the Exar chips
Signed-off-by: NJay Dolan <jay.dolan@accesio.com>
Cc: stable <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20200305140504.22237-1-jay.dolan@accesio.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

in this place, the function should return a
negative value and the PTR_ERR already returns
a negative,so return -PTR_ERR() is wrong.
Signed-off-by: Ntangbin <tangbin@cmss.chinamobile.com>
Cc: stable <stable@vger.kernel.org>
Acked-by: NJiri Slaby <jslaby@suse.cz>
Link: https://lore.kernel.org/r/20200305013823.20976-1-tangbin@cmss.chinamobile.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Christophe reports that powerpc 8xx silently fails to 5.6-rc1. It turns
out I was wrong about nobody relying on the lazy initialization of the
cpm/qe muram in commit b6231ea2 (soc: fsl: qe: drop broken lazy
call of cpm_muram_init()).

Rather than reinstating the somewhat dubious lazy call (initializing a
currently held spinlock, and implicitly doing a GFP_KERNEL under that
spinlock), make sure that cpm_muram_init() is called early enough - I
thought the calls from the subsys_initcalls were good enough, but when
used by console drivers, that's obviously not the
case. cpm_muram_init() is safe to call twice (there's an early return
if it is already initialized), so keep the call from cpm_init() - in
case SERIAL_CPM_CONSOLE=n.

Fixes: b6231ea2 (soc: fsl: qe: drop broken lazy call of cpm_muram_init())
Reported-by: NChristophe Leroy <christophe.leroy@c-s.fr>
Signed-off-by: NRasmus Villemoes <linux@rasmusvillemoes.dk>
Tested-by: NChristophe Leroy <christophe.leroy@c-s.fr>
Link: https://lore.kernel.org/r/20200213114342.21712-1-linux@rasmusvillemoes.dkSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

RX cancel command fails when BT is switched on and off multiple times.

To handle this, poll for the cancel bit in SE_GENI_S_IRQ_STATUS register
instead of SE_GENI_S_CMD_CTRL_REG.

As per the HPG update, handle the RX last bit after cancel command
and flush out the RX FIFO buffer.
Signed-off-by: Nsatya priya <skakit@codeaurora.org>
Cc: stable <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/1581415982-8793-1-git-send-email-skakit@codeaurora.orgSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The commit 54e53b2e
  ("tty: serial: 8250: pass IRQ shared flag to UART ports")
nicely explained the problem:

---8<---8<---

On some systems IRQ lines between multiple UARTs might be shared. If so, the
irqflags have to be configured accordingly. The reason is: The 8250 port startup
code performs IRQ tests *before* the IRQ handler for that particular port is
registered. This is performed in serial8250_do_startup(). This function checks
whether IRQF_SHARED is configured and only then disables the IRQ line while
testing.

This test is performed upon each open() of the UART device. Imagine two UARTs
share the same IRQ line: On is already opened and the IRQ is active. When the
second UART is opened, the IRQ line has to be disabled while performing IRQ
tests. Otherwise an IRQ might handler might be invoked, but the IRQ itself
cannot be handled, because the corresponding handler isn't registered,
yet. That's because the 8250 code uses a chain-handler and invokes the
corresponding port's IRQ handling routines himself.

Unfortunately this IRQF_SHARED flag isn't configured for UARTs probed via device
tree even if the IRQs are shared. This way, the actual and shared IRQ line isn't
disabled while performing tests and the kernel correctly detects a spurious
IRQ. So, adding this flag to the DT probe solves the issue.

Note: The UPF_SHARE_IRQ flag is configured unconditionally. Therefore, the
IRQF_SHARED flag can be set unconditionally as well.

Example stack trace by performing `echo 1 > /dev/ttyS2` on a non-patched system:

|irq 85: nobody cared (try booting with the "irqpoll" option)
| [...]
|handlers:
|[<ffff0000080fc628>] irq_default_primary_handler threaded [<ffff00000855fbb8>] serial8250_interrupt
|Disabling IRQ #85

---8<---8<---

But unfortunately didn't fix the root cause. Let's try again here by moving
IRQ flag assignment from serial_link_irq_chain() to serial8250_do_startup().

This should fix the similar issue reported for 8250_pnp case.

Since this change we don't need to have custom solutions in 8250_aspeed_vuart
and 8250_of drivers, thus, drop them.

Fixes: 1c2f0493 ("serial: 8250: add IRQ trigger support")
Reported-by: NLi RongQing <lirongqing@baidu.com>
Cc: Kurt Kanzenbach <kurt@linutronix.de>
Cc: Vikram Pandita <vikram.pandita@ti.com>
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Cc: stable <stable@vger.kernel.org>
Acked-by: NKurt Kanzenbach <kurt@linutronix.de>
Link: https://lore.kernel.org/r/20200211135559.85960-1-andriy.shevchenko@linux.intel.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

There has oops as below happen on i.MX8MP EVK platform that has
6G bytes DDR memory.

when (xmit->tail < xmit->head) && (xmit->head == 0),
it setups one sg entry with sg->length is zero:
	sg_set_buf(sgl + 1, xmit->buf, xmit->head);

if xmit->buf is allocated from >4G address space, and SDMA only
support <4G address space, then dma_map_sg() will call swiotlb_map()
to do bounce buffer copying and mapping.

But swiotlb_map() don't allow sg entry's length is zero, otherwise
report BUG_ON().

So the patch is to correct the tx DMA scatter list.

Oops:
[  287.675715] kernel BUG at kernel/dma/swiotlb.c:497!
[  287.680592] Internal error: Oops - BUG: 0 [#1] PREEMPT SMP
[  287.686075] Modules linked in:
[  287.689133] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.4.3-00016-g3fdc4e0-dirty #10
[  287.696872] Hardware name: FSL i.MX8MP EVK (DT)
[  287.701402] pstate: 80000085 (Nzcv daIf -PAN -UAO)
[  287.706199] pc : swiotlb_tbl_map_single+0x1fc/0x310
[  287.711076] lr : swiotlb_map+0x60/0x148
[  287.714909] sp : ffff800010003c00
[  287.718221] x29: ffff800010003c00 x28: 0000000000000000
[  287.723533] x27: 0000000000000040 x26: ffff800011ae0000
[  287.728844] x25: ffff800011ae09f8 x24: 0000000000000000
[  287.734155] x23: 00000001b7af9000 x22: 0000000000000000
[  287.739465] x21: ffff000176409c10 x20: 00000000001f7ffe
[  287.744776] x19: ffff000176409c10 x18: 000000000000002e
[  287.750087] x17: 0000000000000000 x16: 0000000000000000
[  287.755397] x15: 0000000000000000 x14: 0000000000000000
[  287.760707] x13: ffff00017f334000 x12: 0000000000000001
[  287.766018] x11: 00000000001fffff x10: 0000000000000000
[  287.771328] x9 : 0000000000000003 x8 : 0000000000000000
[  287.776638] x7 : 0000000000000000 x6 : 0000000000000000
[  287.781949] x5 : 0000000000200000 x4 : 0000000000000000
[  287.787259] x3 : 0000000000000001 x2 : 00000001b7af9000
[  287.792570] x1 : 00000000fbfff000 x0 : 0000000000000000
[  287.797881] Call trace:
[  287.800328]  swiotlb_tbl_map_single+0x1fc/0x310
[  287.804859]  swiotlb_map+0x60/0x148
[  287.808347]  dma_direct_map_page+0xf0/0x130
[  287.812530]  dma_direct_map_sg+0x78/0xe0
[  287.816453]  imx_uart_dma_tx+0x134/0x2f8
[  287.820374]  imx_uart_dma_tx_callback+0xd8/0x168
[  287.824992]  vchan_complete+0x194/0x200
[  287.828828]  tasklet_action_common.isra.0+0x154/0x1a0
[  287.833879]  tasklet_action+0x24/0x30
[  287.837540]  __do_softirq+0x120/0x23c
[  287.841202]  irq_exit+0xb8/0xd8
[  287.844343]  __handle_domain_irq+0x64/0xb8
[  287.848438]  gic_handle_irq+0x5c/0x148
[  287.852185]  el1_irq+0xb8/0x180
[  287.855327]  cpuidle_enter_state+0x84/0x360
[  287.859508]  cpuidle_enter+0x34/0x48
[  287.863083]  call_cpuidle+0x18/0x38
[  287.866571]  do_idle+0x1e0/0x280
[  287.869798]  cpu_startup_entry+0x20/0x40
[  287.873721]  rest_init+0xd4/0xe0
[  287.876949]  arch_call_rest_init+0xc/0x14
[  287.880958]  start_kernel+0x420/0x44c
[  287.884622] Code: 9124c021 9417aff8 a94363f7 17ffffd5 (d4210000)
[  287.890718] ---[ end trace 5bc44c4ab6b009ce ]---
[  287.895334] Kernel panic - not syncing: Fatal exception in interrupt
[  287.901686] SMP: stopping secondary CPUs
[  288.905607] SMP: failed to stop secondary CPUs 0-1
[  288.910395] Kernel Offset: disabled
[  288.913882] CPU features: 0x0002,2000200c
[  288.917888] Memory Limit: none
[  288.920944] ---[ end Kernel panic - not syncing: Fatal exception in interrupt ]---
Reported-by: NEagle Zhou <eagle.zhou@nxp.com>
Tested-by: NEagle Zhou <eagle.zhou@nxp.com>
Signed-off-by: NFugang Duan <fugang.duan@nxp.com>
Cc: stable <stable@vger.kernel.org>
Fixes: 7942f857 ("serial: imx: TX DMA: clean up sg initialization")
Reviewed-by: NUwe Kleine-König <u.kleine-koenig@pengutronix.de>
Link: https://lore.kernel.org/r/1581401761-6378-1-git-send-email-fugang.duan@nxp.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

It is possible to get an instant RX timeout or end-of-transfer interrupt
before RX DMA was started, if transaction is less than 16 bytes. Transfer
should be handled in PIO mode in this case because DMA can't handle it.
This patch brings back the original behaviour of the driver that was
changed by accident by a previous commit, it fixes occasional Bluetooth HW
initialization failures which I started to notice recently.

Fixes: d5e3fadb ("tty: serial: tegra: Activate RX DMA transfer by request")
Signed-off-by: NDmitry Osipenko <digetx@gmail.com>
Link: https://lore.kernel.org/r/20200209164415.9632-1-digetx@gmail.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

In atmel_shutdown() we call atmel_stop_rx() and atmel_stop_tx() functions.
Prevent the rx restart that is implemented in RS485 or ISO7816 modes when
calling atmel_stop_tx() by using the atomic information tasklet_shutdown
that is already in place for this purpose.

Fixes: 98f2082c ("tty/serial: atmel: enforce tasklet init and termination sequences")
Signed-off-by: NNicolas Ferre <nicolas.ferre@microchip.com>
Cc: stable <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20200210152053.8289-1-nicolas.ferre@microchip.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

On AR934x this UART is usually not initialized by the bootloader
as it is only used as a secondary serial port while the primary
UART is a newly introduced NS16550-compatible.
In order to make use of the ar933x-uart on AR934x without RTS/CTS
hardware flow control, one needs to set the
UART_CS_{RX,TX}_READY_ORIDE bits as other than on AR933x where this
UART is used as primary/console, the bootloader on AR934x typically
doesn't set those bits.
Setting them explicitely on AR933x should not do any harm, so just
set them unconditionally.
Tested-by: NChuanhong Guo <gch981213@gmail.com>
Signed-off-by: NDaniel Golle <daniel@makrotopia.org>
Link: https://lore.kernel.org/r/20200207095335.GA179836@makrotopia.orgSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

This is a merge error on my part - the driver was merged into mainline
by commit c5951e7c ("Merge tag 'mips_5.6' of git://../mips/linux")
over a week ago, but nobody apparently noticed that it didn't actually
build due to still having a reference to the devm_ioremap_nocache()
function, removed a few days earlier through commit 6a1000bd ("Merge
tag 'ioremap-5.6' of git://../ioremap").

Apparently this didn't get any build testing anywhere.  Not perhaps all
that surprising: it's restricted to 64-bit MIPS only, and only with the
new SGI_MFD_IOC3 support enabled.

I only noticed because the ioremap conflicts in the ARM SoC driver
update made me check there weren't any others hiding, and I found this
one.
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

The kgdb invokes the poll_put_char and poll_get_char when communicating
with the host. This patch implement the serial polling hooks for the
meson_uart to be used for KGDB debugging over serial line.
Signed-off-by: NJulien Masson <jmasson@baylibre.com>
Link: https://lore.kernel.org/r/867e1klo48.fsf@julienm-fedora-R90NQGV9.i-did-not-set--mail-host-address--so-tickle-meSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The main irq handler function starts by first masking disabled
interrupts in the status register values to ensure to only handle
enabled interrupts. This is important as when the RX path in the
hardware is disabled reading the RX fifo results in an external abort.

This checking must be done under the port lock, otherwise the following
can happen:

     CPU1                            | CPU2
                                     |
     irq triggers as there are chars |
     in the RX fifo                  |
				     | grab port lock
     imx_uart_int finds RRDY enabled |
     and calls imx_uart_rxint which  |
     has to wait for port lock       |
                                     | disable RX (e.g. because we're
                                     | using RS485 with !RX_DURING_TX)
                                     |
                                     | release port lock
     read from RX fifo with RX       |
     disabled => exception           |

So take the port lock only once in imx_uart_int() instead of in the
functions called from there.
Reported-by: NAndre Renaud <arenaud@designa-electronics.com>
Cc: stable@vger.kernel.org
Signed-off-by: NUwe Kleine-König <u.kleine-koenig@pengutronix.de>
Link: https://lore.kernel.org/r/20200121071702.20150-1-u.kleine-koenig@pengutronix.deSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Document the driver private data of the BCM2835 auxiliary UART so that
upcoming commits may add further members with proper kerneldoc.
Signed-off-by: NLukas Wunner <lukas@wunner.de>
Reviewed-by: NMatthias Brugger <mbrugger@suse.com>
Reviewed-by: NNicolas Saenz Julienne <nsaenzjulienne@suse.de>
Tested-by: NNicolas Saenz Julienne <nsaenzjulienne@suse.de>
Link: https://lore.kernel.org/r/aea363c27fd541dba96d2ebfeee4f596c6d34932.1579175223.git.lukas@wunner.deSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

On probe the bcm2835aux UART driver misreports the register base address
as 0x0:

ttyS0 at MMIO 0x0 (irq = 53, base_baud = 50000000) is a 16550

That's because the driver remaps the registers itself.  Take advantage
of the generic remapping code in serial8250_request_std_resource() to
get a message with the correct address and to simplify the driver.
Signed-off-by: NLukas Wunner <lukas@wunner.de>
Cc: Martin Sperl <kernel@martin.sperl.org>
Reviewed-by: NNicolas Saenz Julienne <nsaenzjulienne@suse.de>
Tested-by: NNicolas Saenz Julienne <nsaenzjulienne@suse.de>
Link: https://lore.kernel.org/r/7d1a9bdb05090d8e465fd15cd26d6e81538d07f9.1579175223.git.lukas@wunner.deSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The bcm2835aux UART driver stores a struct uart_8250_port in its private
data even though it's only passed once to serial8250_register_8250_port()
(which copies all relevant data) and becomes obsolete afterwards.
Allocate the struct on the stack instead for simplicity and to conserve
memory.

The driver also initializes a spinlock in the struct which is never used.
Drop that as well.
Signed-off-by: NLukas Wunner <lukas@wunner.de>
Cc: Martin Sperl <kernel@martin.sperl.org>
Reviewed-by: NMatthias Brugger <mbrugger@suse.com>
Reviewed-by: NNicolas Saenz Julienne <nsaenzjulienne@suse.de>
Tested-by: NNicolas Saenz Julienne <nsaenzjulienne@suse.de>
Link: https://lore.kernel.org/r/421d3aed4c34cc8447ac9c26c320961f1b787f11.1579175223.git.lukas@wunner.deSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Suppress a gratuitous error message if serial8250_register_8250_port()
returns -EPROBE_DEFER.
Signed-off-by: NLukas Wunner <lukas@wunner.de>
Reviewed-by: NMatthias Brugger <mbrugger@suse.com>
Reviewed-by: NNicolas Saenz Julienne <nsaenzjulienne@suse.de>
Tested-by: NNicolas Saenz Julienne <nsaenzjulienne@suse.de>
Link: https://lore.kernel.org/r/6aea0eacf3bfa73fe2d81082cc723265413410c8.1579175223.git.lukas@wunner.deSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Suppress a gratuitous error message if devm_clk_get() returns
-EPROBE_DEFER.
Signed-off-by: NPhil Elwell <phil@raspberrypi.org>
[lukas: extend commit message]
Signed-off-by: NLukas Wunner <lukas@wunner.de>
Reviewed-by: NMatthias Brugger <mbrugger@suse.com>
Reviewed-by: NNicolas Saenz Julienne <nsaenzjulienne@suse.de>
Tested-by: NNicolas Saenz Julienne <nsaenzjulienne@suse.de>
Link: https://lore.kernel.org/r/deafc13cdfd7a31c6a81b0db95adcd3599accc26.1579175223.git.lukas@wunner.deSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Unbinding the bcm2835aux UART driver raises the following error if the
maximum number of 8250 UARTs is set to 1 (via the 8250.nr_uarts module
parameter or CONFIG_SERIAL_8250_RUNTIME_UARTS):

(NULL device *): Removing wrong port: a6f80333 != fa20408b

That's because bcm2835aux_serial_probe() retrieves UART line number 1
from the devicetree and stores it in data->uart.port.line, while
serial8250_register_8250_port() instead uses UART line number 0,
which is stored in data->line.

On driver unbind, bcm2835aux_serial_remove() uses data->uart.port.line,
which contains the wrong number.  Fix it.

The issue does not occur if the maximum number of 8250 UARTs is >= 2.

Fixes: bdc5f300 ("serial: bcm2835: add driver for bcm2835-aux-uart")
Signed-off-by: NLukas Wunner <lukas@wunner.de>
Cc: stable@vger.kernel.org # v4.6+
Cc: Martin Sperl <kernel@martin.sperl.org>
Reviewed-by: NNicolas Saenz Julienne <nsaenzjulienne@suse.de>
Tested-by: NNicolas Saenz Julienne <nsaenzjulienne@suse.de>
Link: https://lore.kernel.org/r/912ccf553c5258135c6d7e8f404a101ef320f0f4.1579175223.git.lukas@wunner.deSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

set_mctrl now sets RTS and DTR.
Signed-off-by: NMaarten Brock <m.brock@vanmierlo.com>
Signed-off-by: NShubhrajyoti Datta <shubhrajyoti.datta@xilinx.com>
Link: https://lore.kernel.org/r/1574687731-21563-3-git-send-email-shubhrajyoti.datta@gmail.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Let set_termios enable/disable automatic flow control.
set_mctrl should not touch automatic flow control.
Signed-off-by: NMaarten Brock <m.brock@vanmierlo.com>
Signed-off-by: NShubhrajyoti Datta <shubhrajyoti.datta@xilinx.com>
Link: https://lore.kernel.org/r/1574687731-21563-2-git-send-email-shubhrajyoti.datta@gmail.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Some of the applications like microcom do not work if
modem is disabled. To fix them we always return
TIOCM_CTS | TIOCM_DSR | TIOCM_CAR instead of 0 when
using cts_override. Make get_mctrl return actual status
when not using cts_override.
Signed-off-by: NMaarten Brock <m.brock@vanmierlo.com>
Signed-off-by: NShubhrajyoti Datta <shubhrajyoti.datta@xilinx.com>
Link: https://lore.kernel.org/r/1574687731-21563-1-git-send-email-shubhrajyoti.datta@gmail.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Fixes coccicheck warning:

drivers/tty/serial/8250/8250_exar.c:189:6-17: WARNING: Assignment of 0/1 to bool variable
drivers/tty/serial/8250/8250_exar.c:197:3-14: WARNING: Assignment of 0/1 to bool variable
drivers/tty/serial/8250/8250_exar.c:199:3-14: WARNING: Assignment of 0/1 to bool variable
Reported-by: NHulk Robot <hulkci@huawei.com>
Signed-off-by: NZheng Bin <zhengbin13@huawei.com>
Link: https://lore.kernel.org/r/1578881777-65475-5-git-send-email-zhengbin13@huawei.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Fixes coccicheck warning:

drivers/tty/serial/atmel_serial.c:1062:1-23: WARNING: Assignment of 0/1 to bool variable
drivers/tty/serial/atmel_serial.c:1261:1-23: WARNING: Assignment of 0/1 to bool variable
drivers/tty/serial/atmel_serial.c:1688:3-25: WARNING: Assignment of 0/1 to bool variable
Reported-by: NHulk Robot <hulkci@huawei.com>
Signed-off-by: NZheng Bin <zhengbin13@huawei.com>
Link: https://lore.kernel.org/r/1578881777-65475-4-git-send-email-zhengbin13@huawei.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Fixes coccicheck warning:

drivers/tty/serial/kgdb_nmi.c:121:6-13: WARNING: Assignment of 0/1 to bool variable
drivers/tty/serial/kgdb_nmi.c:133:2-9: WARNING: Assignment of 0/1 to bool variable
Reported-by: NHulk Robot <hulkci@huawei.com>
Signed-off-by: NZheng Bin <zhengbin13@huawei.com>
Link: https://lore.kernel.org/r/1578881777-65475-3-git-send-email-zhengbin13@huawei.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

During db410c stress test and when the system is low on memory,
the UART/console becomes unresponsive and never recover back.
This has been narrowed down to the msm_start_rx_dma which does
not manage error cases correctly (e.g. dma mapping failure),
indeed, when an error happens, dma transfer is simply discarded
and so never completed, leading to unconfigured RX path.

This patch fixes this issue by switching to SW/FIFO mode in case
of DMA issue. This mainly consists in resetting the receiver to
apply RX BAM/DMA disabling change and re-enabling the RX level
and stale interrupts (previously disabled for DMA transfers).

The DMA will be re-enabled once memory is available since the
SW/FIFO read function (msm_handle_rx_dm) retries to start dma
on completion.
Signed-off-by: NLoic Poulain <loic.poulain@linaro.org>
Link: https://lore.kernel.org/r/1578646684-17379-1-git-send-email-loic.poulain@linaro.orgSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The 8250 driver can probe for many variants of the venerable 16550A
serial port. Some of those probes involve long (20ms) mdelay calls,
which delay system boot. Modern systems and virtual machines don't have
those variants.

Provide a Kconfig option to disable probes for 16550A variants.
Disabling this speeds up the boot of a virtual machine with a serial
console by more than 20ms (a substantial fraction of the ~100ms needed
to boot a carefully configured VM).

Before:
[  +0.021919] 00:04: ttyS0 at I/O 0x3f8 (irq = 4, base_baud = 115200) is a 16550A
After:
[  +0.000097] 00:04: ttyS0 at I/O 0x3f8 (irq = 4, base_baud = 115200) is a 16550A
Signed-off-by: NJosh Triplett <josh@joshtriplett.org>
Link: https://lore.kernel.org/r/20200111022513.GA166267@localhostSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Synchronize only the dirty part of DMA buffer in order to avoid
unnecessary overhead of syncing of the clean part, which is the case
of every serial DMA transfer in practice.
Signed-off-by: NDmitry Osipenko <digetx@gmail.com>
Link: https://lore.kernel.org/r/20200112180919.5194-3-digetx@gmail.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

This allows DMA engine to go into runtime-suspended mode whenever there is
no data to receive, instead of keeping DMA active all the time while TTY
is opened (i.e. permanently active in practice, like in the case of UART
Bluetooth).
Signed-off-by: NDmitry Osipenko <digetx@gmail.com>
Link: https://lore.kernel.org/r/20200112180919.5194-2-digetx@gmail.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

At this moment, TXEMPTY is checked before sending data on RS485 and ISO7816
modes. However, TXEMPTY is risen when FIFO (if used) or the Transmit Shift
Register are empty, even though TXRDY might be up and controller is able to
receive data. Since the controller sends data only when TXEMPTY is ready,
on RS485, when DMA is not used, the RTS pin is driven low after each byte.
With this patch, the characters will be transmitted when TXRDY is up and
so, RTS pin will remain high between bytes.
The performance improvement on RS485 is about 8% with a baudrate of 300.
Signed-off-by: NCodrin Ciubotariu <codrin.ciubotariu@microchip.com>
Acked-by: NRichard Genoud <richard.genoud@gmail.com>
Link: https://lore.kernel.org/r/20200107111656.26308-1-codrin.ciubotariu@microchip.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

It's not worth to have them in every serial driver and I'm about to add
another helper function.
Signed-off-by: NDmitry Safonov <dima@arista.com>
Link: https://lore.kernel.org/r/20200109215444.95995-2-dima@arista.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The node pointer in question is not a child node, but the node assigned
to the port device itself, so we should not be using
devm_fwnode_get_gpiod_from_child() [that is going away], but standard
devm_gpiod_get().

To maintain the previous labeling we use gpiod_set_consumer_name() after
we acquire the GPIO.
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>
Link: https://lore.kernel.org/r/20200104202314.GA13591@dtor-wsSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

In order to support having SERIAL_QCOM_GENI as a module while
also still preserving serial console support, tweak the
Kconfig requirements to not require =y

Cc: Todd Kjos <tkjos@google.com>
Cc: Alistair Delva <adelva@google.com>
Cc: Amit Pundir <amit.pundir@linaro.org>
Cc: Jiri Slaby <jslaby@suse.com>
Cc: linux-serial@vger.kernel.org
Signed-off-by: NJohn Stultz <john.stultz@linaro.org>
Reviewed-by: NBjorn Andersson <bjorn.andersson@linaro.org>
Link: https://lore.kernel.org/r/20200107010311.58584-2-john.stultz@linaro.orgSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

In order to support serial console w/ SERIAL_QCOM_GENI=m,
we need to export the uart_console_device() symbol so things
will build

Cc: Todd Kjos <tkjos@google.com>
Cc: Alistair Delva <adelva@google.com>
Cc: Bjorn Andersson <bjorn.andersson@linaro.org>
Cc: Amit Pundir <amit.pundir@linaro.org>
Cc: Jiri Slaby <jslaby@suse.com>
Cc: linux-serial@vger.kernel.org
Signed-off-by: NJohn Stultz <john.stultz@linaro.org>
Link: https://lore.kernel.org/r/20200107010311.58584-1-john.stultz@linaro.orgSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

SGI IOC3 chip has integrated ethernet, keyboard and mouse interface.
It also supports connecting a SuperIO chip for serial and parallel
interfaces. IOC3 is used inside various SGI systemboards and add-on
cards with different equipped external interfaces.

Support for ethernet and serial interfaces were implemented inside
the network driver. This patchset moves out the not network related
parts to a new MFD driver, which takes care of card detection,
setup of platform devices and interrupt distribution for the subdevices.

Serial portion: Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Acked-for-MFD-by: NLee Jones <lee.jones@linaro.org>
Network part: Reviewed-by: Jakub Kicinski <jakub.kicinski@netronome.com>
Network part: Acked-by: Jakub Kicinski <jakub.kicinski@netronome.com>
Signed-off-by: NThomas Bogendoerfer <tbogendoerfer@suse.de>
Signed-off-by: NPaul Burton <paulburton@kernel.org>
Cc: James Hogan <jhogan@kernel.org>
Cc: David S. Miller <davem@davemloft.net>
Cc: Jiri Slaby <jslaby@suse.com>
Cc: linux-mips@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: netdev@vger.kernel.org
Cc: linux-serial@vger.kernel.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>

Remove code from the driver that create and maintain loopback sysfs node.
Instead use the ioctl TIOCMSET with TIOCM_LOOP argument to set HW to
loopback mode.
Signed-off-by: NAkash Asthana <akashast@codeaurora.org>
Reviewed-by: NStephen Boyd <swboyd@chromium.org>
Link: https://lore.kernel.org/r/1578321905-25843-3-git-send-email-akashast@codeaurora.orgSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>