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>

Use uart_console() helper in instead of open coded variant.

Note, SERIAL_CORE_CONSOLE is selected by SERIAL_ATMEL_CONSOLE,
thus no functional changes expected.
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Acked-by: NRichard Genoud <richard.genoud@gmail.com>
Link: https://lore.kernel.org/r/20200310133057.86840-1-andriy.shevchenko@linux.intel.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Use uart_console() helper in instead of open coded variant.

Note, SERIAL_CORE_CONSOLE is selected by SERIAL_PIC32_CONSOLE,
thus no functional changes expected.
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://lore.kernel.org/r/20200311090027.64441-1-andriy.shevchenko@linux.intel.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

SiFive's UART has a software controller clock divider that produces the
final baud rate clock.  Whenever the clock that drives the UART is
changed this divider must be updated accordingly, and given that these
two events are controlled by software they cannot be done atomically.
During the period between updating the UART's driving clock and internal
divider the UART will transmit a different baud rate than what the user
has configured, which will probably result in a corrupted transmission
stream.

The SiFive UART has a FIFO, but due to an issue with the programming
interface there is no way to directly determine when the UART has
finished transmitting.  We're essentially restricted to dead reckoning
in order to figure that out: we can use the FIFO's TX busy register to
figure out when the last frame has begun transmission and just delay for
a long enough that the last frame is guaranteed to get out.

As far as the actual implementation goes: I've modified the existing
existing clock notifier function to drain both the FIFO and the shift
register in on PRE_RATE_CHANGE.  As far as I know there is no hardware
flow control in this UART, so there's no good way to ask the other end
to stop transmission while we can't receive (inserting software flow
control messages seems like a bad idea here).
Signed-off-by: NPalmer Dabbelt <palmerdabbelt@google.com>
Tested-by: NYash Shah <yash.shah@sifive.com>
Link: https://lore.kernel.org/r/20200307042637.83728-1-palmer@dabbelt.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Mark mips_ejtag_fdc_encode() methods switch-case-4 as expecting to
fall through.

This patch fixes the following warning:

drivers/tty/mips_ejtag_fdc.c: In function ‘mips_ejtag_fdc_encode’:
drivers/tty/mips_ejtag_fdc.c:245:13: warning: this statement may fall through [-Wimplicit-fallthrough=]
   word.word &= 0x00ffffff;
   ~~~~~~~~~~^~~~~~~~~~~~~
drivers/tty/mips_ejtag_fdc.c:246:2: note: here
  case 3:
  ^~~~
Signed-off-by: NSerge Semin <Sergey.Semin@baikalelectronics.ru>
Signed-off-by: NAlexey Malahov <Alexey.Malahov@baikalelectronics.ru>
Cc: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
Cc: Paul Burton <paulburton@kernel.org>
Cc: Ralf Baechle <ralf@linux-mips.org>
Link: https://lore.kernel.org/r/20200306124913.151A68030792@mail.baikalelectronics.ruSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Many embedded boards have a disconnected TTL level serial which can
generate some garbage that can lead to spurious false sysrq detects.

Currently, sysrq can be either completely disabled for serial console
or always disabled (with CONFIG_MAGIC_SYSRQ_SERIAL), since
commit 732dbf3a ("serial: do not accept sysrq characters via serial port")

At Arista, we have such boards that can generate BREAK and random
garbage. While disabling sysrq for serial console would solve
the problem with spurious false sysrq triggers, it's also desirable
to have a way to enable sysrq back.

As a measure of balance between on and off options, add
MAGIC_SYSRQ_SERIAL_SEQUENCE which is a string sequence that can enable
sysrq if it follows BREAK on a serial line. The longer the string - the
less likely it may be in the garbage.

Having the way to enable sysrq was beneficial to debug lockups with
a manual investigation in field and on the other side preventing false
sysrq detections.
Based-on-patch-by: NVasiliy Khoruzhick <vasilykh@arista.com>
Signed-off-by: NDmitry Safonov <dima@arista.com>
Link: https://lore.kernel.org/r/20200302175135.269397-3-dima@arista.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Many embedded boards have a disconnected TTL level serial which can
generate some garbage that can lead to spurious false sysrq detects.

Currently, sysrq can be either completely disabled for serial console
or always disabled (with CONFIG_MAGIC_SYSRQ_SERIAL), since
commit 732dbf3a ("serial: do not accept sysrq characters via serial port")

At Arista, we have such boards that can generate BREAK and random
garbage. While disabling sysrq for serial console would solve
the problem with spurious false sysrq triggers, it's also desirable
to have a way to enable sysrq back.

Having the way to enable sysrq was beneficial to debug lockups with
a manual investigation in field and on the other side preventing false
sysrq detections.

As a preparation to add sysrq_toggle_support() call into uart,
remove a private copy of sysrq_enabled from sysctl - it should reflect
the actual status of sysrq.

Furthermore, the private copy isn't correct already in case
sysrq_always_enabled is true. So, remove __sysrq_enabled and use a
getter-helper sysrq_mask() to check sysrq_key_op enabled status.

Cc: Iurii Zaikin <yzaikin@google.com>
Cc: Jiri Slaby <jslaby@suse.com>
Cc: Luis Chamberlain <mcgrof@kernel.org>
Cc: Kees Cook <keescook@chromium.org>
Cc: linux-fsdevel@vger.kernel.org
Signed-off-by: NDmitry Safonov <dima@arista.com>
Link: https://lore.kernel.org/r/20200302175135.269397-2-dima@arista.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Commit e490c914 ("tty: Add software emulated RS485 support for 8250")
introduced support to use RTS as an rs485 Transmit Enable signal if data
is transmitted through the tty layer.

Console messages bypass the tty layer and instead are emitted via
serial8250_console_write().  Amend that function to drive RTS as well,
allowing for a console on rs485 ports.

Note that serial8250_console_write() may be called concurrently to the
tty layer accessing the port.  The two protect their accesses with the
port lock, but serial8250_console_write() may find RTS still being
asserted by the tty layer, in which case it shouldn't be deasserted
after the console message has been printed.  Recognize such situations
by checking the em485->tx_stopped flag.

If a delay_rts_before_send or delay_rts_after_send has been specified,
serial8250_console_write() busy-waits for its duration.  Optimizations
for those wait times are conceivable:  E.g. if RTS is already asserted,
we could check whether em485->start_tx_timer is active and wait only
for the remaining expire time.  But this would require calling into
the hrtimer infrastructure, which involves acquiring locks and
potentially reprogramming timer hardware.  Such operations seem too
risky in the context of console printout, which needs to work even when
the kernel has crashed and emits a BUG splat.  So I've gone with a
simplistic solution which just always waits for the full delay.
Signed-off-by: NLukas Wunner <lukas@wunner.de>
Cc: Matwey V. Kornilov <matwey@sai.msu.ru>
Link: https://lore.kernel.org/r/65edffce4670a19e598015c03cbe46f1ffd93e43.1582895077.git.lukas@wunner.deSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Amend 8250_bcm2835aux.c to support rs485 as introduced for 8250_omap.c
by commit e490c914 ("tty: Add software emulated RS485 support for
8250").

The bcm2835aux differs from omap chips by inverting the meaning of RTS
in the MCR register:  If the bit is clear, RTS is high.  With omap, it's
apparently the other way round.

Moreover, omap achieves half-duplex mode by disabling the UART_IER_RDI
interrupt and clearing the RX FIFO when TX stops.  This approach doesn't
work on bcm2835aux because the UART_LSR_DR bit is set even when
UART_IER_RDI is disabled.  Consequently, serial8250_handle_irq() invokes
serial8250_rx_chars() to empty the FIFO and characters are received even
though the user requested half-duplex.  Solve by disabling the receiver
using the non-standard CNTL register.

Cache that register in the driver's private data for performance.  Set
the private data pointer before calling serial8250_register_8250_port()
to prevent a null pointer deref in case one of the rs485 callbacks is
invoked immediately after port registration.
Signed-off-by: NLukas Wunner <lukas@wunner.de>
Cc: Matwey V. Kornilov <matwey@sai.msu.ru>
Link: https://lore.kernel.org/r/dd86460e20a8f979b7272a0bde73640312b902b1.1582895077.git.lukas@wunner.deSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Commit e490c914 ("tty: Add software emulated RS485 support for 8250")
introduced support to use RTS as an rs485 Transmit Enable signal.
So far the only drivers taking advantage of it are 8250_omap.c and
8250_of.c.

We're about to make use of the feature in 8250_bcm2835aux.c as well.
The bcm2835aux differs from omap chips by inverting the meaning of RTS
in the MCR register.  Moreover, omap achieves half-duplex mode by
disabling the RX interrupt and clearing the RX FIFO when TX stops.
The bcm2835aux requires disabling the receiver instead.

Support these behavioral differences by generalizing the rs485 emulation:
Introduce ->rs485_start_tx() and ->rs485_stop_tx() callbacks in struct
uart_8250_port, provide generic implementations containing the existing
code and use them as callbacks in 8250_omap.c and 8250_of.c.

start_tx_rs485() is idempotent in that it recognizes whether RTS is
already asserted.  Achieve the same by introducing a tx_stopped flag in
struct uart_8250_em485.  This may even perform a little better on arches
where memory access is faster than mmio access.
Signed-off-by: NLukas Wunner <lukas@wunner.de>
Cc: Matwey V. Kornilov <matwey@sai.msu.ru>
Link: https://lore.kernel.org/r/5ac0464ae4414708e723a1e0d52b0c1b2bd41b9b.1582895077.git.lukas@wunner.deSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

When rs485 transmission over an 8250 port stops, __stop_tx() assigns
active_timer = NULL before calling __stop_tx_rs485().

That function in turn either assigns active_timer = stop_tx_timer and
rearms the timer (in case a delay_rts_after_send needs to be observed)
or directly calls __do_stop_tx_rs485().

Move the assignment active_timer = NULL to __stop_tx_rs485() into the
branch which directly calls __do_stop_tx_rs485(), thereby avoiding a
duplicate assignment and simplifying the code.
Signed-off-by: NLukas Wunner <lukas@wunner.de>
Cc: Matwey V. Kornilov <matwey@sai.msu.ru>
Link: https://lore.kernel.org/r/bca638405550eaf92f0c6060b553b687f35885e0.1582895077.git.lukas@wunner.deSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Amend the generic ->rs485_config() callback to sanitize RTS polarity and
zero-fill the padding (in addition to the existing sanitization of the
RTS delays).
Signed-off-by: NLukas Wunner <lukas@wunner.de>
Cc: Matwey V. Kornilov <matwey@sai.msu.ru>
Link: https://lore.kernel.org/r/ff833721bc372d38678f289eb2a44dbf016d5203.1582895077.git.lukas@wunner.deSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Commit e490c914 ("tty: Add software emulated RS485 support for 8250")
introduced support to use RTS as an rs485 Transmit Enable signal.
Drivers opt in to the feature by calling serial8250_em485_init() from
their ->rs485_config() callback.

So far there are two drivers doing that, 8250_omap.c and 8250_of.c.
Both use an identical callback.  We're about to add a third user of that
callback, therefore deduplicate it and move it to 8250_port.c.

Drivers now opt in to rs485 software emulation by assigning the generic
serial8250_rs485_config() callback introduced herein to their
.rs485_config struct member.  This change allows unexporting
serial8250_em485_init() and declaring it static.
Signed-off-by: NLukas Wunner <lukas@wunner.de>
Cc: Matwey V. Kornilov <matwey@sai.msu.ru>
Cc: Heiko Schocher <hs@denx.de>
Link: https://lore.kernel.org/r/fcef63642dc4eae41ae7842d23747b2bf5d40285.1582895077.git.lukas@wunner.deSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Retrieve rs485 devicetree properties on registration of 8250 ports in
case they are attached to an rs485 transceiver.

If the property "linux,rs485-enabled-at-boot-time" is present, invoke
the ->rs485_config() callback to immediately deassert RTS, thereby
ceasing control of the bus.
Signed-off-by: NLukas Wunner <lukas@wunner.de>
Cc: Giulio Benetti <giulio.benetti@micronovasrl.com>
Cc: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Link: https://lore.kernel.org/r/5908ea89b7f9da54872d6634b606d83db032297a.1582895077.git.lukas@wunner.deSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

serial8250_do_set_mctrl() currently allows modifying the RTS modem
control line even when RTS is used as an rs485 Transmit Enable signal.
It is thus possible for user space to interfere with rs485 communication
by invoking a TIOCMSET ioctl().

Ignore such change requests and retain the current RTS polarity when in
rs485 mode.  Note that serial8250_set_mctrl() is always called with
port->lock held, so there's no risk that RTS is changed concurrently.
Signed-off-by: NLukas Wunner <lukas@wunner.de>
Cc: Matwey V. Kornilov <matwey@sai.msu.ru>
Link: https://lore.kernel.org/r/b1ce34ca9bc4d7bdc6e9852fcf30b1f4e37c8a80.1582895077.git.lukas@wunner.deSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

If a driver exposes early consoles with EARLYCON_DECLARE() and
OF_EARLYCON_DECLARE(), pefer the non-OF variant if the user specifies it
by
  earlycon=<driver>,<options>

The rationale behind this is that some drivers register multiple setup
functions under the same driver name. Eg.

OF_EARLYCON_DECLARE(lpuart, "fsl,vf610-lpuart", lpuart_early_console_setup);
OF_EARLYCON_DECLARE(lpuart32, "fsl,ls1021a-lpuart", lpuart32_early_console_setup);
OF_EARLYCON_DECLARE(lpuart32, "fsl,imx7ulp-lpuart", lpuart32_imx_early_console_setup);
EARLYCON_DECLARE(lpuart, lpuart_early_console_setup);
EARLYCON_DECLARE(lpuart32, lpuart32_early_console_setup);

It depends on the order of the entries which console_setup() actually
gets called. To make things worse, I guess it also depends on the
compiler how these are ordered. Thus always prefer the EARLYCON_DECLARE()
ones.
Signed-off-by: NMichael Walle <michael@walle.cc>
Link: https://lore.kernel.org/r/20200220174607.24285-1-michael@walle.ccSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

This patch corrects the SPDX License Identifier style in
header files related to tty serial drivers.
For C header files Documentation/process/license-rules.rst
mandates C-like comments (opposed to C source files where
C++ style should be used).

Changes made by using a script provided by Joe Perches here:
https://lkml.org/lkml/2019/2/7/46.
Suggested-by: NJoe Perches <joe@perches.com>
Signed-off-by: NNishad Kamdar <nishadkamdar@gmail.com>
Link: https://lore.kernel.org/r/20200301204517.GA10368@nishadSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

When syzkaller tests, there is a UAF:
  BUG: KASan: use after free in vgacon_invert_region+0x9d/0x110 at addr
    ffff880000100000
  Read of size 2 by task syz-executor.1/16489
  page:ffffea0000004000 count:0 mapcount:-127 mapping:          (null)
  index:0x0
  page flags: 0xfffff00000000()
  page dumped because: kasan: bad access detected
  CPU: 1 PID: 16489 Comm: syz-executor.1 Not tainted
  Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
  rel-1.9.3-0-ge2fc41e-prebuilt.qemu-project.org 04/01/2014
  Call Trace:
    [<ffffffffb119f309>] dump_stack+0x1e/0x20
    [<ffffffffb04af957>] kasan_report+0x577/0x950
    [<ffffffffb04ae652>] __asan_load2+0x62/0x80
    [<ffffffffb090f26d>] vgacon_invert_region+0x9d/0x110
    [<ffffffffb0a39d95>] invert_screen+0xe5/0x470
    [<ffffffffb0a21dcb>] set_selection+0x44b/0x12f0
    [<ffffffffb0a3bfae>] tioclinux+0xee/0x490
    [<ffffffffb0a1d114>] vt_ioctl+0xff4/0x2670
    [<ffffffffb0a0089a>] tty_ioctl+0x46a/0x1a10
    [<ffffffffb052db3d>] do_vfs_ioctl+0x5bd/0xc40
    [<ffffffffb052e2f2>] SyS_ioctl+0x132/0x170
    [<ffffffffb11c9b1b>] system_call_fastpath+0x22/0x27
    Memory state around the buggy address:
     ffff8800000fff00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00
     00 00
     ffff8800000fff80: 00 00 00 00 00 00 00 00 00 00 00 00 00
     00 00 00
    >ffff880000100000: ff ff ff ff ff ff ff ff ff ff ff ff ff
     ff ff ff

It can be reproduce in the linux mainline by the program:
  #include <stdio.h>
  #include <stdlib.h>
  #include <unistd.h>
  #include <fcntl.h>
  #include <sys/types.h>
  #include <sys/stat.h>
  #include <sys/ioctl.h>
  #include <linux/vt.h>

  struct tiocl_selection {
    unsigned short xs;      /* X start */
    unsigned short ys;      /* Y start */
    unsigned short xe;      /* X end */
    unsigned short ye;      /* Y end */
    unsigned short sel_mode; /* selection mode */
  };

  #define TIOCL_SETSEL    2
  struct tiocl {
    unsigned char type;
    unsigned char pad;
    struct tiocl_selection sel;
  };

  int main()
  {
    int fd = 0;
    const char *dev = "/dev/char/4:1";

    struct vt_consize v = {0};
    struct tiocl tioc = {0};

    fd = open(dev, O_RDWR, 0);

    v.v_rows = 3346;
    ioctl(fd, VT_RESIZEX, &v);

    tioc.type = TIOCL_SETSEL;
    ioctl(fd, TIOCLINUX, &tioc);

    return 0;
  }

When resize the screen, update the 'vc->vc_size_row' to the new_row_size,
but when 'set_origin' in 'vgacon_set_origin', vgacon use 'vga_vram_base'
for 'vc_origin' and 'vc_visible_origin', not 'vc_screenbuf'. It maybe
smaller than 'vc_screenbuf'. When TIOCLINUX, use the new_row_size to calc
the offset, it maybe larger than the vga_vram_size in vgacon driver, then
bad access.
Also, if set an larger screenbuf firstly, then set an more larger
screenbuf, when copy old_origin to new_origin, a bad access may happen.

So, If the screen size larger than vga_vram, resize screen should be
failed. This alse fix CVE-2020-8649 and CVE-2020-8647.

Linus pointed out that overflow checking seems absent. We're saved by
the existing bounds checks in vc_do_resize() with rather strict
limits:

	if (cols > VC_RESIZE_MAXCOL || lines > VC_RESIZE_MAXROW)
		return -EINVAL;

Fixes: 0aec4867 ("[PATCH] SVGATextMode fix")
Reference: CVE-2020-8647 and CVE-2020-8649
Reported-by: NHulk Robot <hulkci@huawei.com>
Signed-off-by: NZhang Xiaoxu <zhangxiaoxu5@huawei.com>
[danvet: augment commit message to point out overflow safety]
Cc: stable@vger.kernel.org
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20200304022429.37738-1-zhangxiaoxu5@huawei.com

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>

On Apple devices the _CRS method returns an empty resource template, and
the resource settings are instead provided by the _DSM method. But
commit 33364d63 (serdev: Add ACPI
devices by ResourceSource field) changed the search for serdev devices
to require valid, non-empty resource template, thereby breaking Apple
devices and causing bluetooth devices to not be found.

This expands the check so that if we don't find a valid template, and
we're on an Apple machine, then just check for the device being an
immediate child of the controller and having a "baud" property.

Cc: <stable@vger.kernel.org> # 5.5
Fixes: 33364d63 ("serdev: Add ACPI devices by ResourceSource field")
Signed-off-by: NRonald Tschalär <ronald@innovation.ch>
Link: https://lore.kernel.org/r/20200211194723.486217-1-ronald@innovation.chSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Remove the dependency with ARCH_SPRD from sprd serial/console Kconfig-s,
since we want them can be built-in when ARCH_SPRD is set as 'm'.
Signed-off-by: NChunyan Zhang <chunyan.zhang@unisoc.com>
Link: https://lore.kernel.org/r/20200305103228.9686-2-zhang.lyra@gmail.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The ->setup() callback is mandatory for the devices.
Provide it for Elkhart Lake UART ports.

Note, for time being it's empty, but in the future it might require
an additional configuration such as DMA.
Reported-by: NRaymond Tan <raymond.tan@intel.com>
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://lore.kernel.org/r/20200305130822.36850-1-andriy.shevchenko@linux.intel.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

MTK uart design no need to control uart clock,
so we just control bus clock in runtime function.
Add uart clock used count to avoid repeatedly switching the clock.
Signed-off-by: NChangqi Hu <changqi.hu@mediatek.com>
Link: https://lore.kernel.org/r/1582707225-26815-1-git-send-email-changqi.hu@mediatek.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The peripheral has support for inverting its input and/or output
signals.  This is useful if the hardware flips polarity of the
peripheral's signal, such as swapped +/- pins on an RS-422 transceiver,
or an inverting level shifter.  Add support for these control registers
via the device tree binding.

As part of this change, make the writes of the various registers more
uniform by moving the UCR3 block up near the other registers' blocks,
since the INVT bit must be set before enabling the peripheral.
Signed-off-by: NGeorge Hilliard <ghilliard@kopismobile.com>
Acked-by: NUwe Kleine-König <u.kleine-koenig@pengutronix.de>
Link: https://lore.kernel.org/r/20200226222319.18383-3-ghilliard@kopismobile.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Emulate half-duplex operation and use mctrl_gpio to add support for
RS485 tranceiver with transmit/receive switch hooked to RTS GPIO line.
This is needed to make use of the RS485 port found on Teltonika RUT955.
Signed-off-by: NDaniel Golle <daniel@makrotopia.org>
Link: https://lore.kernel.org/r/20200221212331.GA21467@makrotopia.orgSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Add capability to support RX-TX, CTS-RTS pins swap in HW.

Configure UART_IO_MACRO_CTRL register accordingly if RX-TX pair
or CTS-RTS pair or both pairs swapped.
Signed-off-by: NRoja Rani Yarubandi <rojay@codeaurora.org>
Reviewed-by: NStephen Boyd <swboyd@chromium.org>
Tested-by: NMatthias Kaehlcke <mka@chromium.org>
Reviewed-by: NMatthias Kaehlcke <mka@chromium.org>
Link: https://lore.kernel.org/r/20200304112203.408-1-rojay@codeaurora.orgSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The CPM UART (PowerPC) has an open coded GPIO modem control
handling. Since I can't test this I can't just migrate it to
the serial mctrl GPIO helper library though I wish I could.
I do second best and convert it to GPIO descriptors at least.

Cc: Rasmus Villemoes <linux@rasmusvillemoes.dk>
Cc: Christophe Leroy <christophe.leroy@c-s.fr>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
Link: https://lore.kernel.org/r/20200229231842.247563-1-linus.walleij@linaro.orgSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Nothing in this driver uses the symbols from <linux/gpio.h>
so drop this include.

Cc: Rahul Tanwar <rahul.tanwar@linux.intel.com>
Cc: Songjun Wu <songjun.wu@linux.intel.com>
Cc: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Cc: John Crispin <john@phrozen.org>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
Link: https://lore.kernel.org/r/20200229212331.174946-1-linus.walleij@linaro.orgSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Nothing in this driver uses the symbols from these GPIO
includes so drop them. These are probably just historical
artifacts from befor mctrl_gpio was used.

Cc: Ludovic Desroches <ludovic.desroches@microchip.com>
Cc: Razvan Stefanescu <razvan.stefanescu@microchip.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
Reviewed-by: NLudovic Desroches <ludovic.desroches@microchip.com>
Link: https://lore.kernel.org/r/20200229220941.205599-1-linus.walleij@linaro.orgSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Shift the cases one level left as this is how we are supposed to write
the switch-case code according to the CodingStyle.
Signed-off-by: NJiri Slaby <jslaby@suse.cz>
Link: https://lore.kernel.org/r/20200219073951.16151-9-jslaby@suse.czSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

It is declared in vt_kern.h, so no need to declare it in selection.c
which includes the header.
Signed-off-by: NJiri Slaby <jslaby@suse.cz>
Link: https://lore.kernel.org/r/20200219073951.16151-8-jslaby@suse.czSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

vt_dont_switch is pure boolean, no need for whole char.
Signed-off-by: NJiri Slaby <jslaby@suse.cz>
Link: https://lore.kernel.org/r/20200219073951.16151-6-jslaby@suse.czSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Move all the selection global variables to a structure vc_selection,
instantiated as vc_sel. This helps to group all the variables together
and see what should be protected by the embedded lock too.

It might be used later also for per-console selection support.
Signed-off-by: NJiri Slaby <jslaby@suse.cz>
Link: https://lore.kernel.org/r/20200219073951.16151-5-jslaby@suse.czSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

use_unicode needs not be global. It is used only in set_selection_kernel
and sel_pos (a callee). It is also always set there prior calling
sel_pos. So make use_unicode local and rename it to plain shorter
"unicode". Finally, propagate it to sel_pos via parameter.
Signed-off-by: NJiri Slaby <jslaby@suse.cz>
Link: https://lore.kernel.org/r/20200219073951.16151-4-jslaby@suse.czSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

multiplier and mode are not actually needed:
* multiplier is used only in kmalloc_array, so use "use_unicode ? 4 : 1"
  directly
* mode is used only to assign a bool in this manner:
  if (cond)
    x = true;
  else
    x = false;
  So do "x = cond" directly.
Signed-off-by: NJiri Slaby <jslaby@suse.cz>
Link: https://lore.kernel.org/r/20200219073951.16151-3-jslaby@suse.czSigned-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>

Commit 0265d6e8 ("xen/blkfront: limit allocated memory size to
actual use case") made struct blkfront_ring_info size dynamic. This is
fine when running with only one queue, but with multiple queues the
addressing of the single queues has to be adapted as the structs are
allocated in an array.

Fixes: 0265d6e8 ("xen/blkfront: limit allocated memory size to actual use case")
Reported-by: NSander Eikelenboom <linux@eikelenboom.it>
Tested-by: NSander Eikelenboom <linux@eikelenboom.it>
Signed-off-by: NJuergen Gross <jgross@suse.com>
Acked-by: NRoger Pau Monné <roger.pau@citrix.com>
Link: https://lore.kernel.org/r/20200305155129.28326-1-jgross@suse.comSigned-off-by: NBoris Ostrovsky <boris.ostrovsky@oracle.com>