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-18-dima@arista.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.

Cc: "Uwe Kleine-König" <u.kleine-koenig@pengutronix.de>
Cc: Pengutronix Kernel Team <kernel@pengutronix.de>
Cc: linux-arm-kernel@lists.infradead.org
Signed-off-by: NDmitry Safonov <dima@arista.com>
Link: https://lore.kernel.org/r/20191213000657.931618-17-dima@arista.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.

Cc: "Maciej W. Rozycki" <macro@linux-mips.org>
Signed-off-by: NDmitry Safonov <dima@arista.com>
Link: https://lore.kernel.org/r/20191213000657.931618-16-dima@arista.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-15-dima@arista.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.

Cc: Alexander Shiyan <shc_work@mail.ru>
Cc: linux-arm-kernel@lists.infradead.org
Signed-off-by: NDmitry Safonov <dima@arista.com>
Link: https://lore.kernel.org/r/20191213000657.931618-14-dima@arista.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.

While at it, remove forward-declaration of atmel_console - it wasn't
needed even at the moment the driver was first time introduced:
commit 1e6c9c28 ("[ARM] 3242/2: AT91RM9200 support for 2.6 (Serial)")

Cc: Alexandre Belloni <alexandre.belloni@bootlin.com>
Cc: Ludovic Desroches <ludovic.desroches@microchip.com>
Cc: Richard Genoud <richard.genoud@gmail.com>
Cc: linux-arm-kernel@lists.infradead.org
Signed-off-by: NDmitry Safonov <dima@arista.com>
Link: https://lore.kernel.org/r/20191213000657.931618-13-dima@arista.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.

Cc: Vineet Gupta <vgupta@synopsys.com>
Signed-off-by: NDmitry Safonov <dima@arista.com>
Link: https://lore.kernel.org/r/20191213000657.931618-12-dima@arista.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-11-dima@arista.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.

Cc: Russell King <linux@armlinux.org.uk>
Signed-off-by: NDmitry Safonov <dima@arista.com>
Link: https://lore.kernel.org/r/20191213000657.931618-10-dima@arista.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-9-dima@arista.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-8-dima@arista.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.

Cc: Florian Fainelli <f.fainelli@gmail.com>
Cc: bcm-kernel-feedback-list@broadcom.com
Cc: linux-arm-kernel@lists.infradead.org
Signed-off-by: NDmitry Safonov <dima@arista.com>
Link: https://lore.kernel.org/r/20191213000657.931618-7-dima@arista.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.

In contrast to 8250/8250_of, legacy_serial on powerpc does fill
(struct plat_serial8250_port). The reason is likely that it's done on
device_initcall(), not on probe. So, 8250_core is not yet probed.

Propagate value from platform_device on 8250 probe - in case powepc
legacy driver it's initialized on initcall, in case 8250_of it will be
initialized later on of_platform_serial_setup().

Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: linuxppc-dev@lists.ozlabs.org
Signed-off-by: NDmitry Safonov <dima@arista.com>
Link: https://lore.kernel.org/r/20191213000657.931618-6-dima@arista.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

This reverts commit 54edb425.

The offending commit caused serdev core to always be built-in, something
which breaks the build of dependent modules when serdev is being built
as a module:

ERROR: "__serdev_device_driver_register" [drivers/gnss/gnss-ubx.ko] undefined!
...
make[2]: *** [/home/johan/work/omicron/src/linux/scripts/Makefile.modpost:94: __modpost] Error 1
Reported-by: Nkbuild test robot <lkp@intel.com>
Signed-off-by: NJohan Hovold <johan@kernel.org>
Cc: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Link: https://lore.kernel.org/r/20191218131154.13702-1-johan@kernel.orgSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

This reverts commit 751d0017.

The wrong commit got added to the tty-next tree, the correct one is in
the tty-linus branch.
Reported-by: NStephen Rothwell <sfr@canb.auug.org.au>
Cc: David Engraf <david.engraf@sysgo.com>
Signed-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.

Cc: Joel Stanley <joel@jms.id.au>
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-aspeed@lists.ozlabs.org
Signed-off-by: NDmitry Safonov <dima@arista.com>
Acked-by: NAndrew Jeffery <andrew@aj.id.au>
Link: https://lore.kernel.org/r/20191213000657.931618-5-dima@arista.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The samsung_tty driver was trying to abuse the struct uart_port by using
two "empty" bytes for its own use.  That's not ok, and was found by
removing those fields from the structure.

Move the variables into the port-specific structure, which is where
everything else for this port already is.  There is no space wasted here
as there was an empty "hole" in the structure already for these bytes.

Cc: Kukjin Kim <kgene@kernel.org>
Cc: Hyunki Koo <kkoos00@naver.com>
Cc: HYUN-KI KOO <hyunki00.koo@samsung.com>
Cc: Shinbeom Choi <sbeom.choi@samsung.com>
Cc: Krzysztof Kozlowski <krzk@kernel.org>
Cc: Dmitry Safonov <dima@arista.com>
Cc: Jiri Slaby <jslaby@suse.com>
Cc: linux-serial@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Link: https://lore.kernel.org/r/20191217140232.GA3489190@kroah.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

sysrq_toggle_support() can be called in parallel, in return calling
input_(un)register_handler(), which fortunately is safe to call
in parallel and regardless of registered/unregistered status of
sysrq_handler.
Remove sysrq_handler_registered as it doesn't have any function there
and may confuse reader about possible race.
Signed-off-by: NDmitry Safonov <dima@arista.com>
Link: https://lore.kernel.org/r/20191213000657.931618-2-dima@arista.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

scripts/conmakehash is only used for generating
drivers/tty/vt/consolemap_deftbl.c

Move it to the related directory.
Signed-off-by: NMasahiro Yamada <masahiroy@kernel.org>
Link: https://lore.kernel.org/r/20191217110633.8796-1-masahiroy@kernel.orgSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The driver variable is assigned to unconditionally and not used before.
So there is no need to explicitly initialize it at the start of
tty_kopen().
Signed-off-by: NUwe Kleine-König <u.kleine-koenig@pengutronix.de>
Link: https://lore.kernel.org/r/20191217075040.8020-1-u.kleine-koenig@pengutronix.deSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

With %pe the symbolic name is printed, so you get

	failure adding device. status -EIO

which is more expressive than the current state

	failure adding device. status -5

.
Signed-off-by: NUwe Kleine-König <u.kleine-koenig@pengutronix.de>
Link: https://lore.kernel.org/r/20191212101649.18126-2-u.kleine-koenig@pengutronix.deSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

drivers/tty/Makefile has:
	obj-$(CONFIG_SERIAL_DEV_BUS)    += serdev/

so in drivers/tty/serdev/Makefile CONFIG_SERIAL_DEV_BUS is always =y.
Signed-off-by: NUwe Kleine-König <u.kleine-koenig@pengutronix.de>
Link: https://lore.kernel.org/r/20191212101649.18126-1-u.kleine-koenig@pengutronix.deSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

checkpatch is giving a bunch of:
	WARNING: Missing a blank line after declarations
messages on this file, so fix up all instances of that issue.

Cc: Kukjin Kim <kgene@kernel.org>
Cc: Krzysztof Kozlowski <krzk@kernel.org>
Cc: Hyunki Koo <kkoos00@naver.com>
Cc: HYUN-KI KOO <hyunki00.koo@samsung.com>
Cc: Shinbeom Choi <sbeom.choi@samsung.com>
Cc: Jiri Slaby <jslaby@suse.com>
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-samsung-soc@vger.kernel.org
Cc: linux-serial@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Link: https://lore.kernel.org/r/20191210143706.3928480-10-gregkh@linuxfoundation.orgSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Fix up some minor formatting of comment blocks to make checkpatch
happier and to make things look more uniform.

Cc: Kukjin Kim <kgene@kernel.org>
Cc: Hyunki Koo <kkoos00@naver.com>
Cc: HYUN-KI KOO <hyunki00.koo@samsung.com>
Cc: Shinbeom Choi <sbeom.choi@samsung.com>
Cc: Jiri Slaby <jslaby@suse.com>
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-samsung-soc@vger.kernel.org
Cc: linux-serial@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Reviewed-by: NKrzysztof Kozlowski <krzk@kernel.org>
Link: https://lore.kernel.org/r/20191210143706.3928480-9-gregkh@linuxfoundation.orgSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The function uart_console_write() expects an unsigned int, so use that
variable type, not 'unsigned', which is generally frowned apon in the
kernel now.

Cc: Kukjin Kim <kgene@kernel.org>
Cc: Hyunki Koo <kkoos00@naver.com>
Cc: HYUN-KI KOO <hyunki00.koo@samsung.com>
Cc: Shinbeom Choi <sbeom.choi@samsung.com>
Cc: Jiri Slaby <jslaby@suse.com>
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-samsung-soc@vger.kernel.org
Cc: linux-serial@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Reviewed-by: NKrzysztof Kozlowski <krzk@kernel.org>
Link: https://lore.kernel.org/r/20191210143706.3928480-8-gregkh@linuxfoundation.orgSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The dbg() macro for the driver is not needed at all, all drivers should
use the common dynamic debugging infrastructure, not roll their own.  So
delete the custom macro and convert the driver to use dev_dbg() instead,
providing a lot more information than the previous macro provided.

Cc: Kukjin Kim <kgene@kernel.org>
Cc: Hyunki Koo <kkoos00@naver.com>
Cc: HYUN-KI KOO <hyunki00.koo@samsung.com>
Cc: Shinbeom Choi <sbeom.choi@samsung.com>
Cc: Jiri Slaby <jslaby@suse.com>
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-samsung-soc@vger.kernel.org
Cc: linux-serial@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Reviewed-by: NKrzysztof Kozlowski <krzk@kernel.org>
Link: https://lore.kernel.org/r/20191210143706.3928480-7-gregkh@linuxfoundation.orgSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Now that the kernel has ftrace, any debugging calls that just do "made
it to this function!" and "leaving this function!" can be removed.

On the quest to move the samsung_tty driver over to use the standard
kernel debugging functions, drop these unneeded calls.

Cc: Kukjin Kim <kgene@kernel.org>
Cc: Hyunki Koo <kkoos00@naver.com>
Cc: HYUN-KI KOO <hyunki00.koo@samsung.com>
Cc: Shinbeom Choi <sbeom.choi@samsung.com>
Cc: Jiri Slaby <jslaby@suse.com>
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-samsung-soc@vger.kernel.org
Cc: linux-serial@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Reviewed-by: NKrzysztof Kozlowski <krzk@kernel.org>
Link: https://lore.kernel.org/r/20191210143706.3928480-6-gregkh@linuxfoundation.orgSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

There is no need for a .h file for a single .c file, so just move all of
the content of samsung.h into samsung_tty.c

Cc: Kukjin Kim <kgene@kernel.org>
Cc: Hyunki Koo <kkoos00@naver.com>
Cc: HYUN-KI KOO <hyunki00.koo@samsung.com>
Cc: Shinbeom Choi <sbeom.choi@samsung.com>
Cc: Jiri Slaby <jslaby@suse.com>
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-samsung-soc@vger.kernel.org
Cc: linux-serial@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Reviewed-by: NKrzysztof Kozlowski <krzk@kernel.org>
Link: https://lore.kernel.org/r/20191210143706.3928480-5-gregkh@linuxfoundation.orgSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The callback was never set, nor called, so remove the pointer entirely
from struct s3c24xx_uart_info.

Cc: Kukjin Kim <kgene@kernel.org>
Cc: Hyunki Koo <kkoos00@naver.com>
Cc: HYUN-KI KOO <hyunki00.koo@samsung.com>
Cc: Shinbeom Choi <sbeom.choi@samsung.com>
Cc: Jiri Slaby <jslaby@suse.com>
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-samsung-soc@vger.kernel.org
Cc: linux-serial@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Reviewed-by: NKrzysztof Kozlowski <krzk@kernel.org>
Link: https://lore.kernel.org/r/20191210143706.3928480-4-gregkh@linuxfoundation.orgSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

checkpatch found some minor issues with comments in samsung.h, so fix
that up.

Cc: Kukjin Kim <kgene@kernel.org>
Cc: Krzysztof Kozlowski <krzk@kernel.org>
Cc: Hyunki Koo <kkoos00@naver.com>
Cc: HYUN-KI KOO <hyunki00.koo@samsung.com>
Cc: Shinbeom Choi <sbeom.choi@samsung.com>
Cc: Jiri Slaby <jslaby@suse.com>
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-samsung-soc@vger.kernel.org
Cc: linux-serial@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Link: https://lore.kernel.org/r/20191210143706.3928480-3-gregkh@linuxfoundation.orgSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Fix a build warning on systems that do not have CONFIG_OF enabled.

Cc: Kukjin Kim <kgene@kernel.org>
Cc: Hyunki Koo <kkoos00@naver.com>
Cc: HYUN-KI KOO <hyunki00.koo@samsung.com>
Cc: Shinbeom Choi <sbeom.choi@samsung.com>
Cc: Jiri Slaby <jslaby@suse.com>
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-samsung-soc@vger.kernel.org
Cc: linux-serial@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Reviewed-by: NKrzysztof Kozlowski <krzk@kernel.org>
Link: https://lore.kernel.org/r/20191210143706.3928480-2-gregkh@linuxfoundation.orgSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

There is no need to tie this driver to only the Exynos platform,
especially for build testing.  So add COMPILE_TEST as an option allowing
it to be built on any platform.

Cc: Kukjin Kim <kgene@kernel.org>
Cc: Hyunki Koo <kkoos00@naver.com>
Cc: HYUN-KI KOO <hyunki00.koo@samsung.com>
Cc: Shinbeom Choi <sbeom.choi@samsung.com>
Cc: Jiri Slaby <jslaby@suse.com>
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-samsung-soc@vger.kernel.org
Cc: linux-serial@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Reviewed-by: NKrzysztof Kozlowski <krzk@kernel.org>
Link: https://lore.kernel.org/r/20191210143706.3928480-1-gregkh@linuxfoundation.orgSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Use MCK_DIV8 when the clock divider is > 65535. Unfortunately the mode
register was already written thus the clock selection is ignored.

Fix by writing the mode register after calculating the baudrate.
Signed-off-by: NDavid Engraf <david.engraf@sysgo.com>
Link: https://lore.kernel.org/r/20191211162954.8393-1-david.engraf@sysgo.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Add the suspend and resume handlers for the versal uart platform driver.
Adds the suspend for sbsa driver.
Sbsa is a subset of the pl011 driver.
Signed-off-by: NShubhrajyoti Datta <shubhrajyoti.datta@xilinx.com>
Link: https://lore.kernel.org/r/1575873048-14313-1-git-send-email-shubhrajyoti.datta@gmail.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Fix the following warning:
drivers/tty/serial/amba-pl011.c: In function check_apply_cts_event_workaround:
drivers/tty/serial/amba-pl011.c:1461:15: warning: variable dummy_read set but not used [-Wunused-but-set-variable]

The data read is useless and can be dropped.
Reported-by: NHulk Robot <hulkci@huawei.com>
Signed-off-by: NXiongfeng Wang <wangxiongfeng2@huawei.com>
Link: https://lore.kernel.org/r/1575619526-34482-1-git-send-email-wangxiongfeng2@huawei.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Fixes gcc '-Wunused-but-set-variable' warning:

drivers/tty/serial/samsung_tty.c: In function s3c24xx_serial_rx_chars_dma:
drivers/tty/serial/samsung_tty.c:549:24: warning: variable ufstat set but not used [-Wunused-but-set-variable]
Signed-off-by: NChen Wandun <chenwandun@huawei.com>
Link: https://lore.kernel.org/r/1574424258-138975-1-git-send-email-chenwandun@huawei.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Fix the following warning:
drivers/tty/serial/omap-serial.c: In function serial_omap_rlsi:
drivers/tty/serial/omap-serial.c:496:16: warning: variable ch set but not used [-Wunused-but-set-variable]

The character read is useless according to the table 23-246 of the omap4
TRM. So we can drop it.
Reported-by: NHulk Robot <hulkci@huawei.com>
Signed-off-by: NXiongfeng Wang <wangxiongfeng2@huawei.com>
Link: https://lore.kernel.org/r/1575617863-32484-1-git-send-email-wangxiongfeng2@huawei.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

This reverts commit fdc2de87 ("serial/8250:
Add support for NI-Serial PXI/PXIe+485 devices").

The commit fdc2de87 ("serial/8250: Add support for NI-Serial
PXI/PXIe+485 devices") introduced a breakage on NI-Serial PXI(e)-RS485
devices, RS-232 variants have no issue. The Linux system can enumerate the
NI-Serial PXI(e)-RS485 devices, but it broke the R/W operation on the
ports.

However, the implementation is working on the NI internal Linux RT kernel
but it does not work in the Linux main tree kernel. This is only affecting
NI products, specifically the RS-485 variants. Reverting the upstream
until a proper implementation that can apply to both NI internal Linux
kernel and Linux mainline kernel is figured out.
Signed-off-by: NJe Yen Tam <je.yen.tam@ni.com>
Fixes: fdc2de87 ("serial/8250: Add support for NI-Serial PXI/PXIe+485 devices")
Cc: stable <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20191127075301.9866-1-je.yen.tam@ni.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Commit d21b0be2 ("vt: introduce unicode mode for /dev/vcs") guarded
against using devices containing attributes as this is not yet
implemented. It however failed to guard against writes to any devices
as this is also unimplemented.
Reported-by: NOr Cohen <orcohen@paloaltonetworks.com>
Signed-off-by: NNicolas Pitre <npitre@baylibre.com>
Cc: <stable@vger.kernel.org> # v4.19+
Cc: Jiri Slaby <jslaby@suse.com>
Fixes: d21b0be2 ("vt: introduce unicode mode for /dev/vcs")
Link: https://lore.kernel.org/r/nycvar.YSQ.7.76.1911051030580.30289@knanqh.ubzrSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Do not try to handle keycodes that are too big, otherwise we risk doing
out-of-bounds writes:

BUG: KASAN: global-out-of-bounds in clear_bit include/asm-generic/bitops-instrumented.h:56 [inline]
BUG: KASAN: global-out-of-bounds in kbd_keycode drivers/tty/vt/keyboard.c:1411 [inline]
BUG: KASAN: global-out-of-bounds in kbd_event+0xe6b/0x3790 drivers/tty/vt/keyboard.c:1495
Write of size 8 at addr ffffffff89a1b2d8 by task syz-executor108/1722
...
 kbd_keycode drivers/tty/vt/keyboard.c:1411 [inline]
 kbd_event+0xe6b/0x3790 drivers/tty/vt/keyboard.c:1495
 input_to_handler+0x3b6/0x4c0 drivers/input/input.c:118
 input_pass_values.part.0+0x2e3/0x720 drivers/input/input.c:145
 input_pass_values drivers/input/input.c:949 [inline]
 input_set_keycode+0x290/0x320 drivers/input/input.c:954
 evdev_handle_set_keycode_v2+0xc4/0x120 drivers/input/evdev.c:882
 evdev_do_ioctl drivers/input/evdev.c:1150 [inline]

In this case we were dealing with a fuzzed HID device that declared over
12K buttons, and while HID layer should not be reporting to us such big
keycodes, we should also be defensive and reject invalid data ourselves as
well.

Reported-by: syzbot+19340dff067c2d3835c0@syzkaller.appspotmail.com
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>
Cc: stable <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20191122204220.GA129459@dtor-wsSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>