Whenever the atmel_rs485_config() driver method would be called,
the USART mode is reset to normal mode before even checking if
RS485 flag is set, thus resulting in losing the previous USART
mode in the case where the checking fails.

Some tools, such as `linux-serial-test`, lead to the driver calling
this method when doing the setup of the serial port: after setting the
port mode (Hardware Flow Control, Normal Mode, RS485 Mode, etc.),
`linux-serial-test` tries to enable/disable RS485 depending on
the commandline arguments that were passed.

Example of how this issue could reveal itself:
When doing a serial communication with Hardware Flow Control through
`linux-serial-test`, the tool would lead to the driver roughly doing
the following:
- set the corresponding bit to 1 (ATMEL_US_USMODE_HWHS bit in the
ATMEL_US_MR register) through the atmel_set_termios() to enable
Hardware Flow Control
- disable RS485 through the atmel_config_rs485() method
Thus, when the latter is called, the mode will be reset and the
previously set bit is unset, leaving USART in normal mode instead of
the expected Hardware Flow Control mode.

This fix ensures that this reset is only done if the checking for
RS485 succeeds and that the previous mode is preserved otherwise.

Fixes: e8faff73 ("ARM: 6092/1: atmel_serial: support for RS485 communications")
Cc: stable <stable@kernel.org>
Reviewed-by: NIlpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: NSergiu Moga <sergiu.moga@microchip.com>
Link: https://lore.kernel.org/r/20220824142902.502596-1-sergiu.moga@microchip.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

When the user initializes the uart port, and waits for the transmit
engine to complete in lpuart32_set_termios(), if the UART TX fifo has
dirty data and the UARTMODIR enable the flow control, the TX fifo may
never be empty. So here we should disable the flow control first to make
sure the transmit engin can complete.

Fixes: 380c966c ("tty: serial: fsl_lpuart: add 32-bit register interface support")
Cc: stable <stable@kernel.org>
Signed-off-by: NSherry Sun <sherry.sun@nxp.com>
Link: https://lore.kernel.org/r/20220821101527.10066-1-sherry.sun@nxp.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The setting of RS485 RTS polarity is inverse in the current driver.

When the property of 'rs485-rts-active-low' is enabled in the dts node,
the RTS signal should be LOW during sending. Otherwise, if there is no
such a property, the RTS should be HIGH during sending.

Fixes: 03895cf4 ("tty: serial: fsl_lpuart: Add support for RS-485")
Cc: stable <stable@kernel.org>
Signed-off-by: NNicolas Diaz <nicolas.diaz@nxp.com>
Signed-off-by: NShenwei Wang <shenwei.wang@nxp.com>
Link: https://lore.kernel.org/r/20220805144529.604856-1-shenwei.wang@nxp.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

When we multiply an unsigned int by a u32 we still end up with an
unsigned int. That means we should specify "%u" not "%lu" in the
format code.

NOTE: this fix was chosen instead of somehow promoting the value to
"unsigned long" since the max baud rate from the earlier call to
uart_get_baud_rate() is 4000000 and the max sampling rate is 32.
4000000 * 32 = 0x07a12000, not even close to overflowing 32-bits.

Fixes: c474c775 ("tty: serial: qcom-geni-serial: Fix get_clk_div_rate() which otherwise could return a sub-optimal clock rate.")
Reported-by: NMark Brown <broonie@kernel.org>
Signed-off-by: NDouglas Anderson <dianders@chromium.org>
Link: https://lore.kernel.org/r/20220802132250.1.Iea061e14157a17e114dbe2eca764568a02d6b889@changeidSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

This was the only function mentioned in the text, but was neither linked
nor documented. So document and link it, so that hyperlinking works in
the text.
Signed-off-by: NJiri Slaby <jslaby@suse.cz>
Link: https://lore.kernel.org/r/20220728061056.20799-6-jslaby@suse.czSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

There are many annotated functions in serial_core.c, but they do not
completely conform to the kernel-doc style. So reformat them and link
them from the Documentation.
Signed-off-by: NJiri Slaby <jslaby@suse.cz>
Link: https://lore.kernel.org/r/20220728061056.20799-5-jslaby@suse.czSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The GPIO uart functions are documented in Documentation. Move and
transform this documentation into kernel-doc directly in the code and
reference it in Documentation using kernel-doc:.

This makes it easier to update, maintain and check by the build.
Signed-off-by: NJiri Slaby <jslaby@suse.cz>
Link: https://lore.kernel.org/r/20220728061056.20799-3-jslaby@suse.czSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Some of the serial (uart_*) functions are documented twice. Once as
kernel-doc along their sources and once in Documentation. So deduplicate
these texts, merge them into kernel-doc in the sources, and link them
using kernel-doc: from the Documentation.

To be properly linked and rendered, tabulators had to be removed from
the comments.
Signed-off-by: NJiri Slaby <jslaby@suse.cz>
Link: https://lore.kernel.org/r/20220728061056.20799-2-jslaby@suse.czSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

For mvebu uart2, error bits are not cleared on buffer read.
This causes interrupt loop and system hang.

Cc: stable@vger.kernel.org
Reviewed-by: NYi Guo <yi.guo@cavium.com>
Reviewed-by: NNadav Haklai <nadavh@marvell.com>
Signed-off-by: NNarendra Hadke <nhadke@marvell.com>
Signed-off-by: NPali Rohár <pali@kernel.org>
Link: https://lore.kernel.org/r/20220726091221.12358-1-pali@kernel.orgSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The LPUART can't distinguish between a break signal and a framing error,
so need to count the break characters if there is a framing error and
received data is zero instead of the parity error.

Fixes: 5541a9ba ("serial: fsl_lpuart: handle break and make sysrq work")
Reviewed-by: NMichael Walle <michael@walle.cc>
Signed-off-by: NSherry Sun <sherry.sun@nxp.com>
Link: https://lore.kernel.org/r/20220725050115.12396-1-sherry.sun@nxp.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The info structs are local only to the stm32-usart.c driver and are
triggering sparse warnings about being undecalred. Move these into
the main driver code and make them static to avoid the following
warnings:

drivers/tty/serial/stm32-usart.h:42:25: warning: symbol 'stm32f4_info' was not declared. Should it be static?
drivers/tty/serial/stm32-usart.h:63:25: warning: symbol 'stm32f7_info' was not declared. Should it be static?
drivers/tty/serial/stm32-usart.h:85:25: warning: symbol 'stm32h7_info' was not declared. Should it be static?
Signed-off-by: NBen Dooks <ben-linux@fluff.org>
Link: https://lore.kernel.org/r/20220721212430.453192-1-ben-linux@fluff.orgSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The LPUART hardware doesn't zero out the parity bit on the received
characters. This behavior won't impact the use cases of CS8 because
the parity bit is the 9th bit which is not currently used by software.
But the parity bit for CS7 must be zeroed out by software in order to
get the correct raw data.
Signed-off-by: NShenwei Wang <shenwei.wang@nxp.com>
Link: https://lore.kernel.org/r/20220714185858.615373-1-shenwei.wang@nxp.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

tty: serial: qcom-geni-serial: Fix get_clk_div_rate() which otherwise could return a sub-optimal clock rate.

In the logic around call to clk_round_rate(), for some corner conditions,
get_clk_div_rate() could return an sub-optimal clock rate. Also, if an
exact clock rate was not found lowest clock was being returned.

Search for suitable clock rate in 2 steps
a) exact match or within 2% tolerance
b) within 5% tolerance
This also takes care of corner conditions.

Fixes: c2194bc9 ("tty: serial: qcom-geni-serial: Remove uart frequency table. Instead, find suitable frequency with call to clk_round_rate")
Reviewed-by: NDouglas Anderson <dianders@chromium.org>
Signed-off-by: NVijaya Krishna Nivarthi <quic_vnivarth@quicinc.com>
Link: https://lore.kernel.org/r/1657911343-1909-1-git-send-email-quic_vnivarth@quicinc.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The error path when get clock frequency fails in bcm2835aux_serial
driver does not correctly disable the clock.

This flaw was found using a static analysis tool "Hulk Robot", which
reported the following warning when analyzing linux-next/master:

    drivers/tty/serial/8250/8250_bcm2835aux.c:
    warning: clk_disable_unprepare_missing.cocci

The cocci script checks for the existence of clk_disable_unprepare()
paired with clk_prepare_enable().

Add the missing clk_disable_unprepare() to the error path.

Fixes: fcc446c8 ("serial: 8250_bcm2835aux: Add ACPI support")
Reported-by: NHulk Robot <hulkci@huawei.com>
Reviewed-by: NFlorian Fainelli <f.fainelli@gmail.com>
Signed-off-by: NGuo Mengqi <guomengqi3@huawei.com>
Link: https://lore.kernel.org/r/20220715023312.37808-1-guomengqi3@huawei.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Commit d3164e2f ("MIPS: Remove VR41xx support") removed support
for MIPS VR41xx platform, so remove exclusive drivers for this
platform, too.
Signed-off-by: NThomas Bogendoerfer <tsbogend@alpha.franken.de>
Link: https://lore.kernel.org/r/20220715140322.135825-1-tsbogend@alpha.franken.deSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Before the drivers rs485_config() function is called the serial core
already ensures that only one of both options RTS on send or RTS after send
is set. So remove the concerning sanity check in the driver function to
avoid redundancy.
Reviewed-by: NIlpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: NLino Sanfilippo <l.sanfilippo@kunbus.com>
Link: https://lore.kernel.org/r/20220710164442.2958979-9-LinoSanfilippo@gmx.deSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Before the drivers rs485_config() function is called the serial core
already ensures that only one of both options RTS on send or RTS after send
is set. So remove the concerning sanity check in the driver function to
avoid redundancy.
Reviewed-by: NIlpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: NLino Sanfilippo <l.sanfilippo@kunbus.com>
Link: https://lore.kernel.org/r/20220710164442.2958979-8-LinoSanfilippo@gmx.deSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Currently the RTS delays set via device tree are not clamped to a maximum
value although the device tree bindings documentation for RS485 claims that
only a maximum of 1000 msecs is allowed.

So clamp the values to avoid arbitrary high delay settings. However clamp
the values to 100 instead of 1000 msecs to be consistent which the maximum
that is allowed when setting the delays from userspace via the UART ioctl
TIOCSRS485.
Signed-off-by: NLino Sanfilippo <l.sanfilippo@kunbus.com>
Link: https://lore.kernel.org/r/20220710164442.2958979-6-LinoSanfilippo@gmx.deSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Move the sanitizing of RS485 delays out of uart_sanitize_serial_rs485()
into the new function uart_sanitize_serial_rs485_delays().
Reviewed-by: NIlpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: NLino Sanfilippo <l.sanfilippo@kunbus.com>
Link: https://lore.kernel.org/r/20220710164442.2958979-5-LinoSanfilippo@gmx.deSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

In serial8250_em485_config() the termination GPIO is set with the uart_port
spinlock held. This is an issue if setting the GPIO line can sleep (e.g.
since the concerning GPIO expander is connected via SPI or I2C).

Fix this by setting the termination line outside of the uart_port spinlock
in the serial core and using gpiod_set_value_cansleep() which instead of
gpiod_set_value() allows it to sleep.

Beside fixing the termination GPIO line setting for the 8250 driver this
change also makes setting the termination GPIO generic for all UART
drivers.
Signed-off-by: NLino Sanfilippo <l.sanfilippo@kunbus.com>
Link: https://lore.kernel.org/r/20220710164442.2958979-4-LinoSanfilippo@gmx.deSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

In ar933x_config_rs485() the check for the RTS GPIO is not needed since in
case the GPIO is not available at driver init ar933x_no_rs485 is assigned
to port->rs485_supported and this function is never called. So remove the
check.

Also in uart_set_rs485_config() the serial core already assigns the passed
serial_rs485 struct to the uart port. So remove the assignment in the
drivers rs485_config() function to avoid redundancy.
Signed-off-by: NLino Sanfilippo <l.sanfilippo@kunbus.com>
Link: https://lore.kernel.org/r/20220710164442.2958979-3-LinoSanfilippo@gmx.deSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

RS485 is not possible without an RTS GPIO regardless of whether RS485 is
enabled at boot time or not. So correct the concerning check in the probe()
function.

Fixes: e849145e ("serial: ar933x: Fill in rs485_supported")
Signed-off-by: NLino Sanfilippo <l.sanfilippo@kunbus.com>
Link: https://lore.kernel.org/r/20220710164442.2958979-2-LinoSanfilippo@gmx.deSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Commit 9cabe26e ("serial: 8250_bcm7271: UART errors after resuming
from S2") prevented an early enabling of RTS during resume, but it did
not actively restore the RTS state after resume.

Fixes: 9cabe26e ("serial: 8250_bcm7271: UART errors after resuming from S2")
Signed-off-by: NDoug Berger <opendmb@gmail.com>
Signed-off-by: NFlorian Fainelli <f.fainelli@gmail.com>
Link: https://lore.kernel.org/r/20220714031316.404918-1-f.fainelli@gmail.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

With PSLVERR_RESP_EN parameter set to 1, the device generates an error
response when an attempt to read an empty RBR with FIFO enabled.

This happens when LCR writes are ignored when UART is busy.
dw8250_check_lcr() in retries to update LCR, invokes dw8250_force_idle()
to clear and reset FIFO and eventually reads UART_RX causing the error.

Avoid this by not reading RBR/UART_RX when no data is available.
Reviewed-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: NVAMSHI GAJJELA <vamshigajjela@google.com>
Link: https://lore.kernel.org/r/20220713131722.2316829-1-vamshigajjela@google.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

S3C2410_UCON is a 32bit register, so it must be read with rd_regl()
instead of rd_reg(), otherwise the upper bits will be zeroed. Fix this.

Fixes: 72a43046 ("tty: serial: samsung_tty: loopback mode support")
Tested-by: NChanho Park <chanho61.park@samsung.com>
Reviewed-by: NKrzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Reviewed-by: NChanho Park <chanho61.park@samsung.com>
Signed-off-by: NMarek Szyprowski <m.szyprowski@samsung.com>
Link: https://lore.kernel.org/r/20220712140745.30362-1-m.szyprowski@samsung.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The Aspeed Virtual UART is only present on Aspeed BMC platforms.  Hence
add a dependency on ARCH_ASPEED, to prevent asking the user about this
driver when configuring a kernel without Aspeed BMC support.
Reviewed-by: NJeremy Kerr <jk@ozlabs.org>
Signed-off-by: NGeert Uytterhoeven <geert+renesas@glider.be>
Link: https://lore.kernel.org/r/259138c372d433005b4871789ef9ee8d15320307.1657528861.git.geert+renesas@glider.beSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Add support for some of the Brainboxes PCIe (PX) range of
serial cards, including the PX-101, PX-235/PX-246,
PX-203/PX-257, PX-260/PX-701, PX-310, PX-313,
PX-320/PX-324/PX-376/PX-387, PX-335/PX-346, PX-368, PX-420,
PX-803 and PX-846.
Signed-off-by: NCameron Williams <cang1@live.co.uk>
Cc: stable <stable@kernel.org>
Link: https://lore.kernel.org/r/AM5PR0202MB2564669252BDC59BF55A6E87C4879@AM5PR0202MB2564.eurprd02.prod.outlook.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Prepare for the BCM63138 ARCH_BCM_63XX migration to ARCH_BCMBCA. Make
SERIAL_BCM63XX depending on ARCH_BCMBCA.
Signed-off-by: NWilliam Zhang <william.zhang@broadcom.com>
Acked-by: NFlorian Fainelli <f.fainelli@gmail.com>
Signed-off-by: NFlorian Fainelli <f.fainelli@gmail.com>

When DT provides rs485-term, set termination flag as supported.
Reviewed-by: NLino Sanfilippo <l.sanfilippo@kunbus.com>
Signed-off-by: NIlpo Järvinen <ilpo.jarvinen@linux.intel.com>
Link: https://lore.kernel.org/r/20220704094515.6831-3-ilpo.jarvinen@linux.intel.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Embed rs485_supported to uart_port to allow serial core to tweak it as
needed.
Reviewed-by: NLino Sanfilippo <l.sanfilippo@kunbus.com>
Signed-off-by: NIlpo Järvinen <ilpo.jarvinen@linux.intel.com>
Link: https://lore.kernel.org/r/20220704094515.6831-2-ilpo.jarvinen@linux.intel.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Some Freescale 8250 implementations have the problem that a single long
break results in one irq per character frame time. The code in
fsl8250_handle_irq() that is supposed to handle that uses the BI bit in
lsr_saved_flags to detect such a situation and then skip the second
received character. However it also stores other error bits and so after
a single frame error the character received in the next irq handling is
passed to the upper layer with a frame error, too.

So after a spike on the data line (which is correctly recognized as a
frame error) the following valid character is thrown away, because the
driver reports a frame error for that one, too.

To weaken this problem restrict saving LSR to only the BI bit.

Note however that the handling is still broken:

 - lsr_saved_flags is updated using orig_lsr which is the LSR content
   for the first received char, but there might be more in the FIFO, so
   a character is thrown away that is received later and not necessarily
   the one following the break.
 - The doubled break might be the 2nd and 3rd char in the FIFO, so the
   workaround doesn't catch these, because serial8250_rx_chars() doesn't
   handle the workaround.
 - lsr_saved_flags might have set UART_LSR_BI at the entry of
   fsl8250_handle_irq() which doesn't originate from
   fsl8250_handle_irq()'s "up->lsr_saved_flags |= orig_lsr &
   UART_LSR_BI;" but from e.g. from serial8250_tx_empty().
 - For a long or a short break this isn't about two characters, but more
   or only a single one.

Fixes: 9deaa53a ("serial: add irq handler for Freescale 16550 errata.")
Acked-by: NIlpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: NUwe Kleine-König <u.kleine-koenig@pengutronix.de>
Link: https://lore.kernel.org/r/20220704085119.55900-1-u.kleine-koenig@pengutronix.deSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

As per RZ/N1 peripheral user manual(r01uh0752ej0100-rzn1-peripheral.pdf)
rev 1.0.0 Mar,2019, the value for 8_WORD_BURST is 4(b2,b1=2’b10).

This patch fixes the macro as per the user manual.

Fixes: aa63d786 ("serial: 8250: dw: Add support for DMA flow controlling devices")
Reviewed-by: NPhil Edworthy <phil.edworthy@renesas.com>
Signed-off-by: NBiju Das <biju.das.jz@bp.renesas.com>
Link: https://lore.kernel.org/r/20220630083909.4294-1-biju.das.jz@bp.renesas.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Functions tty_termios_encode_baud_rate() and uart_update_timeout() should
be called with the baudrate value which was set to hardware. Linux then
report exact values via ioctl(TCGETS2) to userspace.

Change mvebu_uart_baud_rate_set() function to return baudrate value which
was set to hardware and propagate this value to above mentioned functions.

With this change userspace would see precise value in termios c_ospeed
field.

Fixes: 68a0db1d ("serial: mvebu-uart: add function to change baudrate")
Cc: stable <stable@kernel.org>
Reviewed-by: NIlpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: NPali Rohár <pali@kernel.org>
Link: https://lore.kernel.org/r/20220628100922.10717-1-pali@kernel.orgSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

When console is enabled, univ8250_console_setup() calls
serial8250_console_setup() before .dev is set to uart_port. Therefore,
it will not call pm_runtime_get_sync(). Later, when the actual driver
is going to take over univ8250_console_exit() is called. As .dev is
already set, serial8250_console_exit() makes pm_runtime_put_sync() call
with usage count being zero triggering PM usage count warning
(extra debug for univ8250_console_setup(), univ8250_console_exit(), and
serial8250_register_ports()):

[    0.068987] univ8250_console_setup ttyS0 nodev
[    0.499670] printk: console [ttyS0] enabled
[    0.717955] printk: console [ttyS0] printing thread started
[    1.960163] serial8250_register_ports assigned dev for ttyS0
[    1.976830] printk: console [ttyS0] disabled
[    1.976888] printk: console [ttyS0] printing thread stopped
[    1.977073] univ8250_console_exit ttyS0 usage:0
[    1.977075] serial8250 serial8250: Runtime PM usage count underflow!
[    1.977429] dw-apb-uart.6: ttyS0 at MMIO 0x4010006000 (irq = 33, base_baud = 115200) is a 16550A
[    1.977812] univ8250_console_setup ttyS0 usage:2
[    1.978167] printk: console [ttyS0] printing thread started
[    1.978203] printk: console [ttyS0] enabled

To fix the issue, call pm_runtime_get_sync() in
serial8250_register_ports() as soon as .dev is set for an uart_port
if it has console enabled.

This problem became apparent only recently because 82586a72 ("PM:
runtime: Avoid device usage count underflows") added the warning
printout. I confirmed this problem also occurs with v5.18 (w/o the
warning printout, obviously).

Fixes: bedb404e ("serial: 8250_port: Don't use power management for kernel console")
Cc: stable <stable@kernel.org>
Tested-by: NTony Lindgren <tony@atomide.com>
Reviewed-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: NTony Lindgren <tony@atomide.com>
Signed-off-by: NIlpo Järvinen <ilpo.jarvinen@linux.intel.com>
Link: https://lore.kernel.org/r/b4f428e9-491f-daf2-2232-819928dc276e@linux.intel.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

If port->mapbase = NULL in serial8250_request_std_resource() , it need
return a error code instead of 0. If uart_set_info() fail to request new
regions by serial8250_request_std_resource() but the return value of
serial8250_request_std_resource() is 0, The system incorrectly considers
that the resource application is successful and does not attempt to
restore the old setting. A null pointer reference is triggered when the
port resource is later invoked.
Signed-off-by: NYi Yang <yiyang13@huawei.com>
Cc: stable <stable@kernel.org>
Link: https://lore.kernel.org/r/20220628083515.64138-1-yiyang13@huawei.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The code lacks clearing of previous DEAT/DEDT values. Thus, changing
values on the fly results in garbage delays tending towards the maximum
value as more and more bits are ORed together. (Leaving RS485 mode
would have cleared the old values though).

Fixes: 1bcda09d ("serial: stm32: add support for RS485 hardware control mode")
Cc: stable <stable@kernel.org>
Signed-off-by: NIlpo Järvinen <ilpo.jarvinen@linux.intel.com>
Link: https://lore.kernel.org/r/20220627150753.34510-1-ilpo.jarvinen@linux.intel.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Place dw8250_serial_out() before dw8250_serial_out38x() so that it can
be called from dw8250_serial_out38x() to do the actual write.
Signed-off-by: NIlpo Järvinen <ilpo.jarvinen@linux.intel.com>
Link: https://lore.kernel.org/r/20220628134234.53771-2-ilpo.jarvinen@linux.intel.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Instead of open-coding, use BIT(), GENMASK(), and FIELD_GET() helpers.
Reviewed-by: NAndy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: NIlpo Järvinen <ilpo.jarvinen@linux.intel.com>
Link: https://lore.kernel.org/r/20220630100536.41329-1-ilpo.jarvinen@linux.intel.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Drop CONFIG_PM and CONFIG_PM_SLEEP ifdeffery while converting dw8250_pm_ops
to use new PM macros. Since we are using runtime PM, wrap dw8250_pm_ops into
pm_ptr().
Reviewed-by: NIlpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://lore.kernel.org/r/20220630100507.31113-1-andriy.shevchenko@linux.intel.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

For the sake of better maintenance, sort included headers alphabetically.
While at it, split the serial group of headers which makes clear the
subsystem the driver belongs to.
Reviewed-by: NIlpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://lore.kernel.org/r/20220630093816.28271-1-andriy.shevchenko@linux.intel.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>