Noone sets tty->driver_data to NULL in the driver, so there is no point
to check that in mxser_close(). Remove the check.
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Link: https://lore.kernel.org/r/20211118073125.12283-8-jslaby@suse.cz
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
xmit_buf is supposed to exist in all these functions. I.e. from
tty_port_operations::activate() to ::shutdown(). So remove these checks.
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Link: https://lore.kernel.org/r/20211118073125.12283-7-jslaby@suse.cz
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The port->icount.tx is handled in a too complicated manner. Instead of
remembering the original count and subtracting the new one from it,
simply increase tx for each character in the loop. No need for cnt
variable then.
Change also the "X = X & Y" assignment to simpler "X &= Y".
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Link: https://lore.kernel.org/r/20211118073125.12283-6-jslaby@suse.cz
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The MSR read is currently performed on both places where
mxser_check_modem_status() is called. So move it there to avoid code
duplication.
Rename the variable to msr while we move it, to actually see what
"status" we are testing.
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Link: https://lore.kernel.org/r/20211118073125.12283-5-jslaby@suse.cz
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The others are superfluous with tty refcounting in place now. And they
are racy in fact:
* tty_port_initialized() reports false for a small moment after
interrupts are enabled.
* closing is 1 while the port is still alive.
The queues are flushed later during close anyway. So there is no need
for this special handling. Actually, the ISR should not flush the
queues. It should behave as every other driver, just queue the chars
into tty buffer and go on. But this will be changed later. There is
still a lot code depending on having tty in ISR (and not only tty_port).
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Link: https://lore.kernel.org/r/20211118073125.12283-4-jslaby@suse.cz
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
As it is the only thing it does now. This is one of the future
serial_core hooks.
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Link: https://lore.kernel.org/r/20211118073125.12283-3-jslaby@suse.cz
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
mxser_close() behaves like this:
-> tty_port_close_start()
-> tty_wait_until_sent()
-> mxser_wait_until_sent()
-> mxser_close_port
-> wait for TEMT
So it is already waited for TEMT through mxser_wait_until_sent() and
there is another round of waiting in mxser_close_port(). The latter one
is superfluous as nothing could be filled into the output FIFO. Remove
the call.
This helps unification among drivers (so that all behave the same) and
future use of tty_port_close().
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Link: https://lore.kernel.org/r/20211118073125.12283-2-jslaby@suse.cz
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
On RZ/G2L SoC we need to explicitly deassert the reset line
for the device to work, use this opportunity to deassert/assert
reset line in sh-sci driver.
This patch adds support to read the "resets" property (if available)
from DT and perform deassert/assert when required.
Also, propagate the error to the caller of sci_parse_dt() instead of
returning NULL in case of failure.
Reviewed-by: Biju Das <biju.das.jz@bp.renesas.com>
Reviewed-by: Philipp Zabel <p.zabel@pengutronix.de>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Link: https://lore.kernel.org/r/20211110232920.19198-4-prabhakar.mahadev-lad.rj@bp.renesas.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
There are two consequent checks of uport != NULL in
uart_port_shutdown(). Join these two under a single block.
De-multiline the comments when shuffling with them anyway.
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Link: https://lore.kernel.org/r/20211118071911.12059-5-jslaby@suse.cz
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Both do_SAK_work() and vc_SAK() provide a valid tty to __do_SAK(), so
remove the check.
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Link: https://lore.kernel.org/r/20211118071911.12059-3-jslaby@suse.cz
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Remove the TTY_SOFT_SAK part. It is never defined, so this is only
confusing.
It was actually never defined since its introduction in
0.99.14g.
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Link: https://lore.kernel.org/r/20211118071911.12059-2-jslaby@suse.cz
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Commit 89d4f98ae9 ("ARM: remove zte zx platform") missed to remove some
definitions for this platform's debug and serial, e.g., code dependent on
the config DEBUG_ZTE_ZX.
Fortunately, ./scripts/checkkconfigsymbols.py detects this and warns:
DEBUG_ZTE_ZX
Referencing files: arch/arm/include/debug/pl01x.S
Further review by Arnd Bergmann identified even more dead code in the
amba serial driver.
Remove all this left-over from the zte zx platform.
Reviewed-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Lukas Bulwahn <lukas.bulwahn@gmail.com>
Link: https://lore.kernel.org/r/20211102063810.932-1-lukas.bulwahn@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
coccicheck complains about the use of snprintf() in sysfs show
functions:
WARNING use scnprintf or sprintf
Use sysfs_emit instead of scnprintf or sprintf makes more sense.
Reported-by: Zeal Robot <zealci@zte.com.cn>
Reviewed-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Jing Yao <yao.jing2@zte.com.cn>
Link: https://lore.kernel.org/r/20211104114754.30983-1-yao.jing2@zte.com.cn
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Revert commit b4b844930f ("tty: serial: fsl_lpuart: drop earlycon entry
for i.MX8QXP"), because this breaks earlycon support on imx8qm/imx8qxp.
While it is true that for earlycon there is no difference between
i.MX8QXP and i.MX7ULP (for now at least), there are differences
regarding clocks and fixups for wakeup support. For that reason it was
deemed unacceptable to add the imx7ulp compatible to device tree in
order to get earlycon working again.
Reviewed-by: Peng Fan <peng.fan@nxp.com>
Signed-off-by: Alexander Stein <alexander.stein@ew.tq-group.com>
Link: https://lore.kernel.org/r/20211124073109.805088-1-alexander.stein@ew.tq-group.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The current implementation uses 0 as lower limit for the baud rate
tolerance for tegra20 and tegra30 chips which causes isses on UART
initialization as soon as baud rate clock is lower than required even
when within the standard UART tolerance of +/- 4%.
This fix aligns the implementation with the initial commit description
of +/- 4% tolerance for tegra chips other than tegra186 and
tegra194.
Fixes: d781ec21ba ("serial: tegra: report clk rate errors")
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Patrik John <patrik.john@u-blox.com>
Link: https://lore.kernel.org/r/sig.19614244f8.20211123132737.88341-1-patrik.john@u-blox.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The LITEX symbol is neither a build or runtime dependency for the
liteuart serial driver.
LITEX is selected by the "LiteX SoC Controller" driver, which does a
probe-time register-access sanity check and panics if the SoC has not
been configured correctly. That driver's Kconfig entry asserts that any
LiteX driver using the LiteX register accessors should depend on LITEX,
but currently only the serial driver complies.
Relax this LITEX "dependency" in order to make it easier to compile test
the driver.
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: Johan Hovold <johan@kernel.org>
Link: https://lore.kernel.org/r/20211117100512.5058-4-johan@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Make sure to release the allocated minor number before returning on
probe errors.
Fixes: 1da81e5562 ("drivers/tty/serial: add LiteUART driver")
Cc: stable@vger.kernel.org # 5.11
Cc: Filip Kokosinski <fkokosinski@antmicro.com>
Cc: Mateusz Holenko <mholenko@antmicro.com>
Reviewed-by: Stafford Horne <shorne@gmail.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: Johan Hovold <johan@kernel.org>
Link: https://lore.kernel.org/r/20211117100512.5058-3-johan@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Deregister the port when unbinding the driver to prevent it from being
used after releasing the driver data and leaking memory allocated by
serial core.
Fixes: 1da81e5562 ("drivers/tty/serial: add LiteUART driver")
Cc: stable@vger.kernel.org # 5.11
Cc: Filip Kokosinski <fkokosinski@antmicro.com>
Cc: Mateusz Holenko <mholenko@antmicro.com>
Reviewed-by: Stafford Horne <shorne@gmail.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: Johan Hovold <johan@kernel.org>
Link: https://lore.kernel.org/r/20211117100512.5058-2-johan@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
drvdata has to be set in _probe() - otherwise platform_get_drvdata()
causes null pointer dereference BUG in _remove().
Fixes: 1da81e5562 ("drivers/tty/serial: add LiteUART driver")
Cc: stable <stable@vger.kernel.org>
Reviewed-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Ilia Sergachev <silia@ethz.ch>
Link: https://lore.kernel.org/r/20211115224944.23f8c12b@dtkw
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The CONSOLE_POLLING mode is used for tools like k(g)db. In this kind of
setup, it is often sharing a serial device with the normal system console.
This is usually no problem because the polling helpers can consume input
values directly (when in kgdb context) and the normal Linux handlers can
only consume new input values after kgdb switched back.
This is not true anymore when RX DMA is enabled for UARTDM controllers.
Single input values can no longer be received correctly. Instead following
seems to happen:
* on 1. input, some old input is read (continuously)
* on 2. input, two old inputs are read (continuously)
* on 3. input, three old input values are read (continuously)
* on 4. input, 4 previous inputs are received
This repeats then for each group of 4 input values.
This behavior changes slightly depending on what state the controller was
when the first input was received. But this makes working with kgdb
basically impossible because control messages are always corrupted when
kgdboc tries to parse them.
RX DMA should therefore be off when CONSOLE_POLLING is enabled to avoid
these kind of problems. No such problem was noticed for TX DMA.
Fixes: 9969394501 ("tty: serial: msm: Add RX DMA support")
Cc: stable@vger.kernel.org
Signed-off-by: Sven Eckelmann <sven@narfation.org>
Link: https://lore.kernel.org/r/20211113121050.7266-1-sven@narfation.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The document 'ACPI for Arm Components 1.0' defines the following
_HID mappings:
-'Prime cell UART (PL011)': ARMH0011
-'SBSA UART': ARMHB000
Use the sbsa-uart driver when a device is described with
the 'ARMHB000' _HID.
Note:
PL011 devices currently use the sbsa-uart driver instead of the
uart-pl011 driver. Indeed, PL011 devices are not bound to a clock
in ACPI. It is not possible to change their baudrate.
Cc: <stable@vger.kernel.org>
Signed-off-by: Pierre Gondois <Pierre.Gondois@arm.com>
Link: https://lore.kernel.org/r/20211109172248.19061-1-Pierre.Gondois@arm.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Commit 761ed4a945 ("tty: serial_core: convert uart_close to use
tty_port_close") converted serial core to use tty_port_close() but
failed to notice that the transmit buffer still needs to be freed on
final close.
Not freeing the transmit buffer means that the buffer is no longer
cleared on next open so that any ioctl() waiting for the buffer to drain
might wait indefinitely (e.g. on termios changes) or that stale data can
end up being transmitted in case tx is restarted.
Furthermore, the buffer of any port that has been opened would leak on
driver unbind.
Note that the port lock is held when clearing the buffer pointer due to
the ldisc race worked around by commit a5ba1d95e4 ("uart: fix race
between uart_put_char() and uart_shutdown()").
Also note that the tty-port shutdown() callback is not called for
console ports so it is not strictly necessary to free the buffer page
after releasing the lock (cf. d72402145a ("tty/serial: do not free
trasnmit buffer page under port lock")).
Link: https://lore.kernel.org/r/319321886d97c456203d5c6a576a5480d07c3478.1635781688.git.baruch@tkos.co.il
Fixes: 761ed4a945 ("tty: serial_core: convert uart_close to use tty_port_close")
Cc: stable@vger.kernel.org # 4.9
Cc: Rob Herring <robh@kernel.org>
Reported-by: Baruch Siach <baruch@tkos.co.il>
Tested-by: Baruch Siach <baruch@tkos.co.il>
Signed-off-by: Johan Hovold <johan@kernel.org>
Link: https://lore.kernel.org/r/20211108085431.12637-1-johan@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The Xen pv console driver is not essential for boot. Set the respective
flag.
Signed-off-by: Juergen Gross <jgross@suse.com>
Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Link: https://lore.kernel.org/r/20211022064800.14978-4-jgross@suse.com
Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Here is the big set of tty and serial driver updates for 5.16-rc1.
Nothing major in here at all, just lots of tiny serial and tty driver
updates for various reported things, and some good cleanups. These
include:
- more good tty api cleanups from Jiri
- stm32 serial driver updates
- softlockup fix for non-preempt systems under high serial load
- rpmsg serial driver update
- 8250 drivers updates and fixes
- n_gsm line discipline fixes and updates as people are finally
starting to use it.
All of these have been in linux-next for a while now with no reported
issues.
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-----BEGIN PGP SIGNATURE-----
iG0EABECAC0WIQT0tgzFv3jCIUoxPcsxR9QN2y37KQUCYYPczQ8cZ3JlZ0Brcm9h
aC5jb20ACgkQMUfUDdst+ykWbwCfaIScbUoCUx+h/uP93nKKD8B3KgYAoMvFuhhD
D/fTLggs12x5NsvLBgtZ
=rq0R
-----END PGP SIGNATURE-----
Merge tag 'tty-5.16-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty
Pull tty / serial driver updates from Greg KH:
"Here is the big set of tty and serial driver updates for 5.16-rc1.
Nothing major in here at all, just lots of tiny serial and tty driver
updates for various reported things, and some good cleanups. These
include:
- more good tty api cleanups from Jiri
- stm32 serial driver updates
- softlockup fix for non-preempt systems under high serial load
- rpmsg serial driver update
- 8250 drivers updates and fixes
- n_gsm line discipline fixes and updates as people are finally
starting to use it.
All of these have been in linux-next for a while now with no reported
issues"
* tag 'tty-5.16-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty: (86 commits)
tty: Fix extra "not" in TTY_DRIVER_REAL_RAW description
serial: cpm_uart: Protect udbg definitions by CONFIG_SERIAL_CPM_CONSOLE
tty: rpmsg: Define tty name via constant string literal
tty: rpmsg: Add pr_fmt() to prefix messages
tty: rpmsg: Use dev_err_probe() in ->probe()
tty: rpmsg: Unify variable used to keep an error code
tty: rpmsg: Assign returned id to a local variable
serial: stm32: push DMA RX data before suspending
serial: stm32: terminate / restart DMA transfer at suspend / resume
serial: stm32: rework RX dma initialization and release
serial: 8250_pci: Remove empty stub pci_quatech_exit()
serial: 8250_pci: Replace custom pci_match_id() implementation
serial: xilinx_uartps: Fix race condition causing stuck TX
serial: sunzilog: Mark sunzilog_putchar() __maybe_unused
Revert "tty: hvc: pass DMA capable memory to put_chars()"
Revert "virtio-console: remove unnecessary kmemdup()"
serial: 8250_pci: Replace dev_*() by pci_*() macros
serial: 8250_pci: Get rid of redundant 'else' keyword
serial: 8250_pci: Refactor the loop in pci_ite887x_init()
tty: add rpmsg driver
...
If CONFIG_CONSOLE_POLL=y, and CONFIG_SERIAL_CPM=m (hence
CONFIG_SERIAL_CPM_CONSOLE=n):
drivers/tty/serial/cpm_uart/cpm_uart_core.c:1109:12: warning: ‘udbg_cpm_getc’ defined but not used [-Wunused-function]
1109 | static int udbg_cpm_getc(void)
| ^~~~~~~~~~~~~
drivers/tty/serial/cpm_uart/cpm_uart_core.c:1095:13: warning: ‘udbg_cpm_putc’ defined but not used [-Wunused-function]
1095 | static void udbg_cpm_putc(char c)
| ^~~~~~~~~~~~~
Fix this by making the udbg definitions depend on
CONFIG_SERIAL_CPM_CONSOLE, in addition to CONFIG_CONSOLE_POLL.
Fixes: a60526097f ("tty: serial: cpm_uart: Add udbg support for enabling xmon")
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Link: https://lore.kernel.org/r/20211027075326.3270785-1-geert@linux-m68k.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Driver uses already twice the same string literal.
Define it in one place, so every user will have this
name consistent.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://lore.kernel.org/r/20211025135148.53944-5-andriy.shevchenko@linux.intel.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Instead of putting garbage in the data structure, assign allocated id
or an error code to a temporary variable. This makes code cleaner.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://lore.kernel.org/r/20211025135148.53944-1-andriy.shevchenko@linux.intel.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Data may be stored in DMA RX buffer, when suspending. The data needs
to be pushed to the upper layer. We can't rely on the timeout IRQ (RTOR)
that can't be triggered into low power state. So safely clear DMA request
(DMAR), force the DMA reception routines to push RX buffer content, before
disabling RX DMA. This way, handover to pio mode is safe.
Only call tty_flip_buffer_push() when there is RX data to handle.
Move the locking outside of stm32_usart_receive_chars() to prevent a race
condition, when disabling DMA request upon suspend / pm_runtime_suspend.
Data may be received under IRQ and pushed before
stm32_usart_receive_chars() has pushed older data from DMA rx_buf upon
suspend.
The sequence in suspend routine needs proper locking to avoid this.
Signed-off-by: Fabrice Gasnier <fabrice.gasnier@foss.st.com>
Signed-off-by: Erwan Le Ray <erwan.leray@foss.st.com>
Link: https://lore.kernel.org/r/20211025134229.8456-4-erwan.leray@foss.st.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
DMA prevents the system to suspend when an UART RX wake-up source is
using DMA. DMA can't suspend while DMA channels are still active.
Terminate DMA transfer at suspend, and restart a new DMA transfer at
resume. Create stm32_usart_start_rx_dma_cyclic function to factorize
dma RX initialization. Move RX DMA code related to wakeup into
stm32_usart_serial_en_wakeup() routine to ease further improvements
on wakeup from low power modes.
Don't enable/disable wakeup on uninitialized port.
There may be data residue in the RX FIFO while suspending. Flush it at
suspend time. Receiver timeout interrupt won't trigger later in low power
mode, so call stm32_usart_receive_chars() in case there's data to handle.
Signed-off-by: Valentin Caron <valentin.caron@foss.st.com>
Signed-off-by: Erwan Le Ray <erwan.leray@foss.st.com>
Link: https://lore.kernel.org/r/20211025134229.8456-3-erwan.leray@foss.st.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The RX DMA channel is kept active forever (from the probe). That prevents
going to low power mode when it is used. This change moves the
DMA configuration and enabling procedures to startup routine to allow
transition to low power mode.
The DMA disabling procedure is implemented in stop_rx routine as this
ops has to stop characters reception, and DMA transation in shutdown.
Clean useless dma_async_tx_descriptor initialization to NULL value.
Signed-off-by: Valentin Caron <valentin.caron@foss.st.com>
Signed-off-by: Erwan Le Ray <erwan.leray@foss.st.com>
Link: https://lore.kernel.org/r/20211025134229.8456-2-erwan.leray@foss.st.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
xilinx_uartps .start_tx() clears TXEMPTY when enabling TXEMPTY to avoid
any previous TXEVENT event asserting the UART interrupt. This clear
operation is done immediately after filling the TX FIFO.
However, if the bytes inserted by cdns_uart_handle_tx() are consumed by
the UART before the TXEMPTY is cleared, the clear operation eats the new
TXEMPTY event as well, causing cdns_uart_isr() to never receive the
TXEMPTY event. If there are bytes still queued in circbuf, TX will get
stuck as they will never get transferred to FIFO (unless new bytes are
queued to circbuf in which case .start_tx() is called again).
While the racy missed TXEMPTY occurs fairly often with short data
sequences (e.g. write 1 byte), in those cases circbuf is usually empty
so no action on TXEMPTY would have been needed anyway. On the other
hand, longer data sequences make the race much more unlikely as UART
takes longer to consume the TX FIFO. Therefore it is rare for this race
to cause visible issues in general.
Fix the race by clearing the TXEMPTY bit in ISR *before* filling the
FIFO.
The TXEMPTY bit in ISR will only get asserted at the exact moment the
TX FIFO *becomes* empty, so clearing the bit before filling FIFO does
not cause an extra immediate assertion even if the FIFO is initially
empty.
This is hard to reproduce directly on a normal system, but inserting
e.g. udelay(200) after cdns_uart_handle_tx(port), setting 4000000 baud,
and then running "dd if=/dev/zero bs=128 of=/dev/ttyPS0 count=50"
reliably reproduces the issue on my ZynqMP test system unless this fix
is applied.
Fixes: 85baf542d5 ("tty: xuartps: support 64 byte FIFO size")
Signed-off-by: Anssi Hannula <anssi.hannula@bitwise.fi>
Link: https://lore.kernel.org/r/20211026102741.2910441-1-anssi.hannula@bitwise.fi
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
If CONSOLE_POLL=n, CONFIG_SERIAL_SUNZILOG_CONSOLE=n, and CONFIG_SERIO=m:
drivers/tty/serial/sunzilog.c:1128:13: error: ‘sunzilog_putchar’ defined but not used [-Werror=unused-function]
1128 | static void sunzilog_putchar(struct uart_port *port, int ch)
| ^~~~~~~~~~~~~~~~
Fix this by marking sunzilog_putchar() __maybe_unused.
Acked-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Link: https://lore.kernel.org/r/20211026080426.2444756-1-geert@linux-m68k.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This reverts commit 0986d7bc55.
It still has some issues and needs to be dropped at this point in time.
Link: https://lore.kernel.org/r/208f7a41-a9fa-630c-cb44-c37c503f3a72@kernel.org
Reported-by: Jiri Slaby <jirislaby@kernel.org>
Cc: Xianting Tian <xianting.tian@linux.alibaba.com>
Cc: Shile Zhang <shile.zhang@linux.alibaba.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The 'else' keyword is not needed when previous conditional branch returns
to the upper layer. Get rid of redundant 'else' keyword in such cases.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: Jiri Slaby <jslaby@kernel.org>
Link: https://lore.kernel.org/r/20211022135147.70965-2-andriy.shevchenko@linux.intel.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The loop can be refactored by using ARRAY_SIZE() instead of NULL terminator.
This reduces code base and makes it easier to read and understand.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: Jiri Slaby <jslaby@kernel.org>
Link: https://lore.kernel.org/r/20211022135147.70965-1-andriy.shevchenko@linux.intel.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This driver exposes a standard TTY interface on top of the rpmsg
framework through a rpmsg service.
This driver supports multi-instances, offering a /dev/ttyRPMSGx entry
per rpmsg endpoint.
Reviewed-by: Mathieu Poirier <mathieu.poirier@linaro.org>
Signed-off-by: Arnaud Pouliquen <arnaud.pouliquen@foss.st.com>
Link: https://lore.kernel.org/r/20211015094701.5732-3-arnaud.pouliquen@foss.st.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The driver was updating the port uartclk before setting the new rate in
an attempt to avoid having the clock notifier redundantly update the
divisors.
The set_termios() callback is however called under the termios semaphore
and tty-port mutex so the worker scheduled by the clock notifier will
block in serial8250_update_uartclk() until the uartclk and divisors have
been updated anyway.
Drop the unnecessary swaps and incorrect comment and simply update the
uartclk field if the clock-rate change was successful.
Tested-by: Serge Semin <fancer.lancer@gmail.com>
Reviewed-by: Serge Semin <fancer.lancer@gmail.com>
Acked-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Johan Hovold <johan@kernel.org>
Link: https://lore.kernel.org/r/20211015111422.1027-4-johan@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Rename a couple of oddly named labels that are used to unlock before
returning after what they do (rather than after the context they are
used in) to improve readability.
Tested-by: Serge Semin <fancer.lancer@gmail.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: Serge Semin <fancer.lancer@gmail.com>
Signed-off-by: Johan Hovold <johan@kernel.org>
Link: https://lore.kernel.org/r/20211015111422.1027-3-johan@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Commit 868f3ee6e4 ("serial: 8250: Add 8250 port clock update method")
added a hack to support SoCs where the UART reference clock can
change behind the back of the driver but failed to add the proper
locking.
First, make sure to take a reference to the tty struct to avoid
dereferencing a NULL pointer if the clock change races with a hangup.
Second, the termios semaphore must be held during the update to prevent
a racing termios change.
Fixes: 868f3ee6e4 ("serial: 8250: Add 8250 port clock update method")
Fixes: c8dff3aa82 ("serial: 8250: Skip uninitialized TTY port baud rate update")
Cc: stable@vger.kernel.org # 5.9
Cc: Serge Semin <Sergey.Semin@baikalelectronics.ru>
Tested-by: Serge Semin <fancer.lancer@gmail.com>
Reviewed-by: Serge Semin <fancer.lancer@gmail.com>
Acked-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Johan Hovold <johan@kernel.org>
Link: https://lore.kernel.org/r/20211015111422.1027-2-johan@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Disable DMA request line (if enabled) to switch in PIO mode in throttle
ops, so the RX data gets queues into the FIFO. The hardware flow control
is triggered when the RX FIFO is full.
Switch back to DMA mode (re-enable DMA request line) in unthrottle ops.
Hardware flow control is stopped when FIFO is not full anymore.
Signed-off-by: Valentin Caron <valentin.caron@foss.st.com>
Signed-off-by: Erwan Le Ray <erwan.leray@foss.st.com>
Link: https://lore.kernel.org/r/20211020150332.10214-4-erwan.leray@foss.st.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This patch reworks RX support over DMA to improve reliability:
- change dma buffer cyclic configuration by using 2 periods. DMA buffer
data are handled by a flip-flop between the 2 periods in order to avoid
risk of data loss/corruption
- change the size of dma buffer to 4096 to limit overruns
- add rx errors management (breaks, parity, framing and overrun).
When an error occurs on the uart line, the dma request line is masked at
HW level. The SW must 1st clear DMAR (dma request line enable), to
handle the error, then re-enable DMAR to recover. So, any correct data
is taken from the DMA buffer, before handling the error itself. Then
errors are handled from RDR/ISR/FIFO (e.g. in PIO mode). Last, DMA
reception is resumed.
- add a condition on DMA request line in DMA RX routines in order to
switch to PIO mode when no DMA request line is disabled, even if the DMA
channel is still enabled.
When the UART is wakeup source and is configured to use DMA for RX, any
incoming data that wakes up the system isn't correctly received.
At data reception, the irq_handler handles the WUF irq, and then the
data reception over DMA.
As the DMA transfer has been terminated at suspend, and will be restored
by resume callback (which has no yet been called by system), the data
can't be received.
The wake-up data has to be handled in PIO mode while suspend callback
has not been called.
Signed-off-by: Valentin Caron <valentin.caron@foss.st.com>
Signed-off-by: Erwan Le Ray <erwan.leray@foss.st.com>
Link: https://lore.kernel.org/r/20211020150332.10214-3-erwan.leray@foss.st.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Re-introduce an irq flag condition in usart_receive_chars.
This condition has been deleted by commit 75f4e830fa ("serial: do not
restore interrupt state in sysrq helper").
This code was present to handle threaded case, and has been removed
because it is no more needed in this case. Nevertheless an irq safe lock
is still needed in some cases, when DMA should be stopped to receive errors
or breaks in PIO mode.
This patch is a precursor to the complete rework or stm32 serial driver
DMA implementation.
Signed-off-by: Erwan Le Ray <erwan.leray@foss.st.com>
Link: https://lore.kernel.org/r/20211020150332.10214-2-erwan.leray@foss.st.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
