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>

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>

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>

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>

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>

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>

Since a05025d0 ("tty: serial: samsung_tty: use standard debugging
macros") this configuration option is not used at all, so remove it from
the Kconfig file.

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

There is no need to tie this driver to only a specific SoC, or compile
test, so remove that dependancy from the Kconfig rules.

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

Convert pr_*() calls to dev_*() ones. We have a port, we should use it.
Suggested-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://lore.kernel.org/r/20200217114016.49856-5-andriy.shevchenko@linux.intel.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Move device attributes to DEVICE_ATTR_RW() as that would make things
a lot more "obvious" what is happening here.
Suggested-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://lore.kernel.org/r/20200217114016.49856-4-andriy.shevchenko@linux.intel.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Fix a spelling mistake in a comment.
Signed-off-by: NAlexandre Belloni <alexandre.belloni@bootlin.com>
Acked-by: NUwe Kleine-König <u.kleine-koenig@pengutronix.de>
Link: https://lore.kernel.org/r/20200214141406.20792-1-alexandre.belloni@bootlin.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

'exsisting' has an extra 's'
Signed-off-by: NChristophe JAILLET <christophe.jaillet@wanadoo.fr>
Link: https://lore.kernel.org/r/20200216102742.19298-1-christophe.jaillet@wanadoo.frSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

If we're unlucky enough that this drivers binds to a mrvl,mmp-uart device
on a MMP3, the port type gets detected as 16550A instead of XScale, and it
won't work. Other drivers that may bind to the same hardware are 8250_of
and, god forbid, serial_pxa.

Force the port type, we know it's a PORT_XSCALE.
Signed-off-by: NLubomir Rintel <lkundrak@v3.sk>
Link: https://lore.kernel.org/r/20200219080130.4334-1-lkundrak@v3.skSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Move device attributes to DEVICE_ATTR_RO() as that would make things
a lot more "obvious" what is happening here.
Suggested-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://lore.kernel.org/r/20200217114016.49856-2-andriy.shevchenko@linux.intel.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Symbolic permissions 'S_IRUSR | S_IRGRP' are not preferred.
Use octal permissions '0440'. This also makes code shorter.
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://lore.kernel.org/r/20200214114339.53897-4-andriy.shevchenko@linux.intel.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

We have two times duplicated excerpt where we initialize spin lock
for UART port. Consolidate it under uart_port_spin_lock_init() helper.
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://lore.kernel.org/r/20200214114339.53897-3-andriy.shevchenko@linux.intel.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Introduce uart_console_enabled() helper which checks port to be console
and console is registered in the list.

Note, this helper will be used in the future as well.
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://lore.kernel.org/r/20200214114339.53897-2-andriy.shevchenko@linux.intel.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>