Johan Hovold [Thu, 22 Apr 2021 08:02:11 +0000 (10:02 +0200)]
serial: extend compile-test coverage
Allow more drivers to be compile tested more easily, for example, when
doing subsystem-wide changes.
Verified on X86_64 as well as arm, powerpc and m68k with minimal configs
in order to catch missing implicit build dependencies (e.g. MAILBOX for
SERIAL_TEGRA_TCU).
Add the support for two optional DT properties, to configure RX and TX
FIFO thresholds:
- rx-threshold
- tx-threshold
This replaces hard-coded 8 bytes threshold. Keep 8 as the default value if
not specified, for backward compatibility.
Signed-off-by: Fabrice Gasnier <fabrice.gasnier@foss.st.com> Signed-off-by: Erwan Le Ray <erwan.leray@foss.st.com>
Changes in v2:
Change added properties naming as proposed by Rob Herring. Link: https://lore.kernel.org/r/20210413174015.23011-5-erwan.leray@foss.st.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Override rx-threshold and tx-threshold properties:
- extend description
- provide default and expected values
Signed-off-by: Fabrice Gasnier <fabrice.gasnier@foss.st.com> Signed-off-by: Erwan Le Ray <erwan.leray@foss.st.com>
Changes in v2:
Change added properties naming and factorize it in serial.yaml as proposed
by Rob Herring.
Johan Hovold [Wed, 21 Apr 2021 09:55:09 +0000 (11:55 +0200)]
serial: xilinx_uartps: drop low-latency workaround
Commit d43f9c379e53 ("serial: xuartps: Rewrite the interrupt handling
logic") reworked the driver interrupt processing but also, without
comment, added an unnecessary workaround for the infamous low_latency
behaviour of tty_flip_buffer_push() which had been removed years
before.
Specifically, since commit 671ac8a2b918 ("tty: Fix low_latency BUG"),
tty_flip_buffer_push() always schedules a work item to push data to the
line discipline and there's no need to keep any low_latency hacks around.
Johan Hovold [Wed, 21 Apr 2021 09:55:08 +0000 (11:55 +0200)]
serial: vt8500: drop low-latency workaround
Commit 01546f4e53a7 ("tty: serial: vt8500: drop uart_port->lock before
calling tty_flip_buffer_push()") claimed to address a locking
issue but only provided a dubious lockdep splat from an unrelated
driver, which in the end turned out to be due a broken local change
carried by the author.
Unfortunately these patches were merged before the issue had been
analysed properly so the commit messages makes no sense whatsoever.
The real issue was first seen on RT which at the time effectively always
set the low_latency flag for all serial drivers by patching
tty_flip_buffer_push(). This in turn revealed that many drivers did not
handle the infamous low_latency behaviour which meant that data was
pushed immediately to the line discipline instead of being deferred to a
work queue.
Since commit 671ac8a2b918 ("tty: Fix low_latency BUG"),
tty_flip_buffer_push() always schedules a work item to push data to the
line discipline and there's no need to keep any low_latency hacks
around.
Johan Hovold [Wed, 21 Apr 2021 09:55:07 +0000 (11:55 +0200)]
serial: timbuart: drop low-latency workaround
The timbuart driver has always carried a workaround for the infamous
low_latency behaviour of tty_flip_buffer_push() which required not
holding the port lock when the low_latency flag was set.
Since commit 671ac8a2b918 ("tty: Fix low_latency BUG"),
tty_flip_buffer_push() always schedules a work item to push data to the
line discipline and there's no need to keep any low_latency hacks
around.
Johan Hovold [Wed, 21 Apr 2021 09:55:06 +0000 (11:55 +0200)]
serial: sunsu: drop low-latency workaround
The sunsu driver has been carrying a workaround for the infamous
low_latency behaviour of tty_flip_buffer_push() by dropping and
reacquiring the port lock in the interrupt handler since 2004.
Since commit 671ac8a2b918 ("tty: Fix low_latency BUG"),
tty_flip_buffer_push() always schedules a work item to push data to the
line discipline and there's no need to keep any low_latency hacks around.
Cc: "David S. Miller" <davem@davemloft.net> Acked-by: David S. Miller <davem@davemloft.net> Signed-off-by: Johan Hovold <johan@kernel.org> Link: https://lore.kernel.org/r/20210421095509.3024-24-johan@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Johan Hovold [Wed, 21 Apr 2021 09:55:05 +0000 (11:55 +0200)]
serial: sifive: drop low-latency workaround
The sifive driver has always carried an unnecessary workaround for the
infamous low_latency behaviour of tty_flip_buffer_push() which had been
removed years before the driver was added by commit 4f96f5102939 ("tty:
serial: add driver for the SiFive UART").
Specifically, since commit 671ac8a2b918 ("tty: Fix low_latency BUG"),
tty_flip_buffer_push() always schedules a work item to push data to the
line discipline and there's no need to keep any low_latency hacks around.
Cc: Palmer Dabbelt <palmer@dabbelt.com> Cc: Paul Walmsley <paul.walmsley@sifive.com> Signed-off-by: Johan Hovold <johan@kernel.org> Link: https://lore.kernel.org/r/20210421095509.3024-23-johan@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Johan Hovold [Wed, 21 Apr 2021 09:55:04 +0000 (11:55 +0200)]
serial: txx9: drop low-latency workaround
Commit 18800ef542b9 ("[PATCH] txx9 serial update") worked around the
infamous low_latency behaviour of tty_flip_buffer_push() by simply
dropping and reacquiring the port lock in the interrupt handler.
Since commit 671ac8a2b918 ("tty: Fix low_latency BUG"),
tty_flip_buffer_push() always schedules a work item to push data to the
line discipline and there's no need to keep any low_latency hacks around.
Johan Hovold [Wed, 21 Apr 2021 09:55:03 +0000 (11:55 +0200)]
serial: sa1100: drop low-latency workaround
Commit f708978817ff ("tty: serial: sa1100: drop uart_port->lock before
calling tty_flip_buffer_push()") claimed to address a locking
issue but only provided a dubious lockdep splat from an unrelated
driver, which in the end turned out to be due a broken local change
carried by the author.
Unfortunately these patches were merged before the issue had been
analysed properly so the commit messages makes no sense whatsoever.
The real issue was first seen on RT which at the time effectively always
set the low_latency flag for all serial drivers by patching
tty_flip_buffer_push(). This in turn revealed that many drivers did not
handle the infamous low_latency behaviour which meant that data was
pushed immediately to the line discipline instead of being deferred to a
work queue.
Since commit 671ac8a2b918 ("tty: Fix low_latency BUG"),
tty_flip_buffer_push() always schedules a work item to push data to the
line discipline and there's no need to keep any low_latency hacks
around.
Johan Hovold [Wed, 21 Apr 2021 09:55:02 +0000 (11:55 +0200)]
serial: rp2: drop low-latency workaround
Commit fb53c037a7f1 ("tty: serial: rp2: drop uart_port->lock before
calling tty_flip_buffer_push()") claimed to address a locking
issue but only provided a dubious lockdep splat from an unrelated
driver, which in the end turned out to be due a broken local change
carried by the author.
Unfortunately these patches were merged before the issue had been
analysed properly so the commit messages makes no sense whatsoever.
The real issue was first seen on RT which at the time effectively always
set the low_latency flag for all serial drivers by patching
tty_flip_buffer_push(). This in turn revealed that many drivers did not
handle the infamous low_latency behaviour which meant that data was
pushed immediately to the line discipline instead of being deferred to a
work queue.
Since commit 671ac8a2b918 ("tty: Fix low_latency BUG"),
tty_flip_buffer_push() always schedules a work item to push data to the
line discipline and there's no need to keep any low_latency hacks
around.
Johan Hovold [Wed, 21 Apr 2021 09:55:01 +0000 (11:55 +0200)]
serial: rda: drop low-latency workaround
The rda driver has always carried an unnecessary workaround for the
infamous low_latency behaviour of tty_flip_buffer_push(), which had
been removed years before the driver was added by commit 35fc5144a637
("tty: serial: Add RDA8810PL UART driver").
Specifically, since commit 671ac8a2b918 ("tty: Fix low_latency BUG"),
tty_flip_buffer_push() always schedules a work item to push data to the
line discipline and there's no need to keep any low_latency hacks around.
Johan Hovold [Wed, 21 Apr 2021 09:55:00 +0000 (11:55 +0200)]
serial: owl: drop low-latency workaround
The owl driver has always carried an unnecessary workaround for the
infamous low_latency behaviour of tty_flip_buffer_push(), which had
been removed years before the driver was added by commit d4bd602dedaf
("tty: serial: owl: Implement console driver").
Specifically, since commit 671ac8a2b918 ("tty: Fix low_latency BUG"),
tty_flip_buffer_push() always schedules a work item to push data to the
line discipline and there's no need to keep any low_latency hacks around.
Johan Hovold [Wed, 21 Apr 2021 09:54:59 +0000 (11:54 +0200)]
serial: msm_serial: drop low-latency workaround
Commit afeca1e11580 ("tty: serial: msm: drop uart_port->lock before
calling tty_flip_buffer_push()") claimed to address a locking
issue but only provided a dubious lockdep splat from an unrelated
driver, which in the end turned out to be due a broken local change
carried by the author.
Unfortunately these patches were merged before the issue had been
analysed properly so the commit messages makes no sense whatsoever.
The real issue was first seen on RT which at the time effectively always
set the low_latency flag for all serial drivers by patching
tty_flip_buffer_push(). This in turn revealed that many drivers did not
handle the infamous low_latency behaviour which meant that data was
pushed immediately to the line discipline instead of being deferred to a
work queue.
Since commit 671ac8a2b918 ("tty: Fix low_latency BUG"),
tty_flip_buffer_push() always schedules a work item to push data to the
line discipline and there's no need to keep any low_latency hacks
around.
Johan Hovold [Wed, 21 Apr 2021 09:54:58 +0000 (11:54 +0200)]
serial: mpc52xx_uart: drop low-latency workaround
Commit e0880f43f747 ("Fix a potential issue in mpc52xx uart driver")
worked around the infamous low_latency behaviour of
tty_flip_buffer_push() by simply dropping and reacquiring the port lock
in the interrupt handler.
Since commit 671ac8a2b918 ("tty: Fix low_latency BUG"),
tty_flip_buffer_push() always schedules a work item to push data to the
line discipline and there's no need to keep any low_latency hacks around.
Johan Hovold [Wed, 21 Apr 2021 09:54:57 +0000 (11:54 +0200)]
serial: meson: drop low-latency workaround
The meson driver has always carried an unnecessary workaround for the
infamous low_latency behaviour of tty_flip_buffer_push(), which had
already been removed by the time the driver was added by commit 2da7ed3fecbe ("ARM: meson: serial: add MesonX SoC on-chip uart driver").
Specifically, since commit 671ac8a2b918 ("tty: Fix low_latency BUG"),
tty_flip_buffer_push() always schedules a work item to push data to the
line discipline and there's no need to keep any low_latency hacks around.
Johan Hovold [Wed, 21 Apr 2021 09:54:56 +0000 (11:54 +0200)]
serial: mcf: drop low-latency workaround
Commit 0e09ac5ebcdf ("tty: serial: mcf: drop uart_port->lock before
calling tty_flip_buffer_push()") claimed to address a locking
issue but only provided a dubious lockdep splat from an unrelated
driver, which in the end turned out to be due a broken local change
carried by the author.
Unfortunately these patches were merged before the issue had been
analysed properly so the commit messages makes no sense whatsoever.
The real issue was first seen on RT which at the time effectively always
set the low_latency flag for all serial drivers by patching
tty_flip_buffer_push(). This in turn revealed that many drivers did not
handle the infamous low_latency behaviour which meant that data was
pushed immediately to the line discipline instead of being deferred to a
work queue.
Since commit 671ac8a2b918 ("tty: Fix low_latency BUG"),
tty_flip_buffer_push() always schedules a work item to push data to the
line discipline and there's no need to keep any low_latency hacks
around.
Johan Hovold [Wed, 21 Apr 2021 09:54:55 +0000 (11:54 +0200)]
serial: lpc32xx_hs: drop low-latency workaround
Commit 88ce9357e77d ("tty: serial: lpc32xx_hs: drop uart_port->lock
before calling tty_flip_buffer_push()") claimed to address a locking
issue but only provided a dubious lockdep splat from an unrelated
driver, which in the end turned out to be due a broken local change
carried by the author.
Unfortunately these patches were merged before the issue had been
analysed properly so the commit messages makes no sense whatsoever.
The real issue was first seen on RT which at the time effectively always
set the low_latency flag for all serial drivers by patching
tty_flip_buffer_push(). This in turn revealed that many drivers did not
handle the infamous low_latency behaviour which meant that data was
pushed immediately to the line discipline instead of being deferred to a
work queue.
Since commit 671ac8a2b918 ("tty: Fix low_latency BUG"),
tty_flip_buffer_push() always schedules a work item to push data to the
line discipline and there's no need to keep any low_latency hacks
around.
Johan Hovold [Wed, 21 Apr 2021 09:54:54 +0000 (11:54 +0200)]
serial: icom: drop low-latency workaround
Commit a352cdc7741b ("tty: serial: icom: drop uart_port->lock before
calling tty_flip_buffer_push()") claimed to address a locking
issue but only provided a dubious lockdep splat from an unrelated
driver, which in the end turned out to be due a broken local change
carried by the author.
Unfortunately these patches were merged before the issue had been
analysed properly so the commit messages makes no sense whatsoever.
The real issue was first seen on RT which at the time effectively always
set the low_latency flag for all serial drivers by patching
tty_flip_buffer_push(). This in turn revealed that many drivers did not
handle the infamous low_latency behaviour which meant that data was
pushed immediately to the line discipline instead of being deferred to a
work queue.
Since commit 671ac8a2b918 ("tty: Fix low_latency BUG"),
tty_flip_buffer_push() always schedules a work item to push data to the
line discipline and there's no need to keep any low_latency hacks
around.
Johan Hovold [Wed, 21 Apr 2021 09:54:53 +0000 (11:54 +0200)]
serial: bcm63xx: drop low-latency workaround
Commit eeb657c81f11 ("tty: serial: bcm63xx: drop uart_port->lock before
calling tty_flip_buffer_push()") claimed to address a locking
issue but only provided a dubious lockdep splat from an unrelated
driver, which in the end turned out to be due a broken local change
carried by the author.
Unfortunately these patches were merged before the issue had been
analysed properly so the commit messages makes no sense whatsoever.
The real issue was first seen on RT which at the time effectively always
set the low_latency flag for all serial drivers by patching
tty_flip_buffer_push(). This in turn revealed that many drivers did not
handle the infamous low_latency behaviour which meant that data was
pushed immediately to the line discipline instead of being deferred to a
work queue.
Since commit 671ac8a2b918 ("tty: Fix low_latency BUG"),
tty_flip_buffer_push() always schedules a work item to push data to the
line discipline and there's no need to keep any low_latency hacks
around.
Johan Hovold [Wed, 21 Apr 2021 09:54:52 +0000 (11:54 +0200)]
serial: atmel_serial: drop low-latency workaround
Commit 092b3b5a9a77 ("atmel_serial: split the interrupt handler") worked
around the infamous low_latency behaviour of tty_flip_buffer_push() by
dropping and reacquiring the port lock in the tasklet callback.
Since commit 671ac8a2b918 ("tty: Fix low_latency BUG"),
tty_flip_buffer_push() always schedules a work item to push data to the
line discipline and there's no need to keep any low_latency hacks around.
Johan Hovold [Wed, 21 Apr 2021 09:54:51 +0000 (11:54 +0200)]
serial: arc_uart: drop low-latency workaround
Commit 6317361f32f8 ("tty: serial: arc: drop uart_port->lock before
calling tty_flip_buffer_push()") claimed to address a locking
issue but only provided a dubious lockdep splat from an unrelated
driver, which in the end turned out to be due a broken local change
carried by the author.
Unfortunately these patches were merged before the issue had been
analysed properly so the commit messages makes no sense whatsoever.
The real issue was first seen on RT which at the time effectively always
set the low_latency flag for all serial drivers by patching
tty_flip_buffer_push(). This in turn revealed that many drivers did not
handle the infamous low_latency behaviour which meant that data was
pushed immediately to the line discipline instead of being deferred to a
work queue.
Since commit 671ac8a2b918 ("tty: Fix low_latency BUG"),
tty_flip_buffer_push() always schedules a work item to push data to the
line discipline and there's no need to keep any low_latency hacks
around.
Johan Hovold [Wed, 21 Apr 2021 09:54:50 +0000 (11:54 +0200)]
serial: ar933x: drop low-latency workaround
Commit 4b44738dc53e ("tty: serial: ar933x: drop uart_port->lock before
calling tty_flip_buffer_push()") claimed to address a locking
issue but only provided a dubious lockdep splat from an unrelated
driver, which in the end turned out to be due a broken local change
carried by the author.
Unfortunately these patches were merged before the issue had been
analysed properly so the commit messages makes no sense whatsoever.
The real issue was first seen on RT which at the time effectively always
set the low_latency flag for all serial drivers by patching
tty_flip_buffer_push(). This in turn revealed that many drivers did not
handle the infamous low_latency behaviour which meant that data was
pushed immediately to the line discipline instead of being deferred to a
work queue.
Since commit 671ac8a2b918 ("tty: Fix low_latency BUG"),
tty_flip_buffer_push() always schedules a work item to push data to the
line discipline and there's no need to keep any low_latency hacks
around.
Johan Hovold [Wed, 21 Apr 2021 09:54:49 +0000 (11:54 +0200)]
serial: apbuart: drop low-latency workaround
Commit 9ff30d705667 ("tty: serial: apbuart: drop uart_port->lock before
calling tty_flip_buffer_push()") claimed to address a locking
issue but only provided a dubious lockdep splat from an unrelated
driver, which in the end turned out to be due a broken local change
carried by the author.
Unfortunately these patches were merged before the issue had been
analysed properly so the commit messages makes no sense whatsoever.
The real issue was first seen on RT which at the time effectively always
set the low_latency flag for all serial drivers by patching
tty_flip_buffer_push(). This in turn revealed that many drivers did not
handle the infamous low_latency behaviour which meant that data was
pushed immediately to the line discipline instead of being deferred to a
work queue.
Since commit 671ac8a2b918 ("tty: Fix low_latency BUG"),
tty_flip_buffer_push() always schedules a work item to push data to the
line discipline and there's no need to keep any low_latency hacks
around.
Johan Hovold [Wed, 21 Apr 2021 09:54:48 +0000 (11:54 +0200)]
serial: amba-pl011: drop low-latency workaround
Commit 30522b3bfbc5 ("ARM: 6763/1: pl011: add optional RX DMA to PL011
v2") added RX DMA support and also reproduced the workaround for the
infamous low_latency behaviour of tty_flip_buffer_push() by dropping and
reacquiring the port lock during receive processing.
Since commit 671ac8a2b918 ("tty: Fix low_latency BUG"),
tty_flip_buffer_push() always schedules a work item to push data to the
line discipline and there's no need to keep any low_latency hacks around.
Note that the port lock is also dropped in the PIO path
(see pl011_rx_chars), but it is not clear whether this is still needed
by the DMA code added by the aforementioned commit.
Cc: Linus Walleij <linus.walleij@linaro.org> Cc: Russell King <linux@armlinux.org.uk> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Johan Hovold <johan@kernel.org> Link: https://lore.kernel.org/r/20210421095509.3024-6-johan@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Johan Hovold [Wed, 21 Apr 2021 09:54:47 +0000 (11:54 +0200)]
serial: amba-pl010: drop low-latency workaround
Commit 43d16510230e ("[ARM] 4417/1: Serial: Fix AMBA drivers locking")
worked around the infamous low_latency behaviour of
tty_flip_buffer_push() by simply dropping and reacquiring the port lock
in the interrupt handler.
Since commit 671ac8a2b918 ("tty: Fix low_latency BUG"),
tty_flip_buffer_push() always schedules a work item to push data to the
line discipline and there's no need to keep any low_latency hacks around.
Johan Hovold [Wed, 21 Apr 2021 09:54:46 +0000 (11:54 +0200)]
serial: altera_uart: drop low-latency workaround
Commit 3218295d8a36 ("tty: serial: altera: drop uart_port->lock before
calling tty_flip_buffer_push()") claimed to address a locking
issue but only provided a dubious lockdep splat from an unrelated
driver, which in the end turned out to be due a broken local change
carried by the author.
Unfortunately these patches were merged before the issue had been
analysed properly so the commit messages makes no sense whatsoever.
The real issue was first seen on RT which at the time effectively always
set the low_latency flag for all serial drivers by patching
tty_flip_buffer_push(). This in turn revealed that many drivers did not
handle the infamous low_latency behaviour which meant that data was
pushed immediately to the line discipline instead of being deferred to a
work queue.
Since commit 671ac8a2b918 ("tty: Fix low_latency BUG"),
tty_flip_buffer_push() always schedules a work item to push data to the
line discipline and there's no need to keep any low_latency hacks
around.
Johan Hovold [Wed, 21 Apr 2021 09:54:45 +0000 (11:54 +0200)]
serial: altera_jtaguart: drop low-latency workaround
Commit 7b32f935ea4f ("tty: serial: altera_jtag: drop uart_port->lock
before calling tty_flip_buffer_push()") claimed to address a locking
issue but only provided a dubious lockdep splat from an unrelated
driver, which in the end turned out to be due a broken local change
carried by the author.
Unfortunately these patches were merged before the issue had been
analysed properly so the commit messages makes no sense whatsoever.
The real issue was first seen on RT which at the time effectively always
set the low_latency flag for all serial drivers by patching
tty_flip_buffer_push(). This in turn revealed that many drivers did not
handle the infamous low_latency behaviour which meant that data was
pushed immediately to the line discipline instead of being deferred to a
work queue.
Since commit 671ac8a2b918 ("tty: Fix low_latency BUG"),
tty_flip_buffer_push() always schedules a work item to push data to the
line discipline and there's no need to keep any low_latency hacks
around.
Johan Hovold [Wed, 21 Apr 2021 09:54:44 +0000 (11:54 +0200)]
tty: mxser: drop low-latency workaround
Commit b4803a11e98f ("Char: mxser_new, fix recursive locking") worked
around the infamous low_latency behaviour of tty_flip_buffer_push() by
simply dropping and reacquiring the port lock in the interrupt handler.
Since commit 671ac8a2b918 ("tty: Fix low_latency BUG"),
tty_flip_buffer_push() always schedules a work item to push data to the
line discipline and there's no need to keep any low_latency hacks around.
Data received during half-duplex transmission must be filtered.
If the target device responds quickly, emptying the FIFO at the end of
the transmission can erase not only the echo characters but also part of
the response message.
By keeping the receive interrupt enabled even during transmission, it
allows you to filter each echo character and only in a number equal to
those transmitted.
The issue was generated by a target device that started responding
240us later having received a request in communication at 115200bps.
Sometimes, some messages received by the target were missing some of the
first bytes.
Fixes: 2f5834e66b8f ("tty/serial: omap: empty the RX FIFO at the end of half-duplex TX") Signed-off-by: Dario Binacchi <dariobin@libero.it> Link: https://lore.kernel.org/r/20210418094705.27014-1-dariobin@libero.it Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
serial: omap: don't disable rs485 if rts gpio is missing
There are rs485 transceivers (e.g. MAX13487E/MAX13488E) which
automatically disable or enable the driver and receiver to keep the bus
in the correct state.
In these cases we don't need a GPIO for flow control.
Johan Hovold [Fri, 16 Apr 2021 14:05:57 +0000 (16:05 +0200)]
serial: stm32: defer sysrq processing
Use the uart_unlock_and_check_sysrq() helper to defer sysrq processing
until receive processing is done and the port lock has been released.
This allows cleaning up the console_write() implementation by not having
to work around the recursive sysrq case (by dropping locking completely)
and also makes the console code work with PREEMPT_RT by no longer
relying on local_irq_save().
Johan Hovold [Fri, 16 Apr 2021 14:05:56 +0000 (16:05 +0200)]
serial: stm32: fix threaded interrupt handling
When DMA is enabled the receive handler runs in a threaded handler, but
the primary handler up until very recently neither disabled interrupts
in the device or used IRQF_ONESHOT. This would lead to a deadlock if an
interrupt comes in while the threaded receive handler is running under
the port lock.
Commit d4b0b7b3348b ("serial: stm32: fix a deadlock condition with
wakeup event") claimed to fix an unrelated deadlock, but unfortunately
also disabled interrupts in the threaded handler. While this prevents
the deadlock mentioned in the previous paragraph it also defeats the
purpose of using a threaded handler in the first place.
Fix this by making the interrupt one-shot and not disabling interrupts
in the threaded handler.
Note that (receive) DMA must not be used for a console port as the
threaded handler could be interrupted while holding the port lock,
something which could lead to a deadlock in case an interrupt handler
ends up calling printk.
Johan Hovold [Fri, 16 Apr 2021 14:05:55 +0000 (16:05 +0200)]
serial: do not restore interrupt state in sysrq helper
The uart_unlock_and_check_sysrq() helper can be used to defer processing
of sysrq until the interrupt handler has released the port lock and is
about to return.
Since commit b24aaf9d9d8d ("genirq: Disable interrupts for force
threaded handlers") interrupt handlers that are not explicitly requested
as threaded are always called with interrupts disabled and there is no
need to save the interrupt state when taking the port lock.
Instead of adding another sysrq helper for when the interrupt state has
not needlessly been saved, drop the state parameter from
uart_unlock_and_check_sysrq() and update its callers to no longer
explicitly disable interrupts in their interrupt handlers.
Cc: Joel Stanley <joel@jms.id.au> Cc: Andrew Jeffery <andrew@aj.id.au> Cc: Andy Gross <agross@kernel.org> Cc: Bjorn Andersson <bjorn.andersson@linaro.org> Signed-off-by: Johan Hovold <johan@kernel.org> Link: https://lore.kernel.org/r/20210416140557.25177-2-johan@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Colin Ian King [Tue, 20 Apr 2021 10:57:18 +0000 (11:57 +0100)]
tty: synclink_gt: remove redundant initialization of variable count
The variable count is being initialized with a value that is
never read and it is being updated later with a new value. The
initialization is redundant and can be removed.
int main(int argc, char *argv[])
{
int i;
int fd[10];
for (i = 0; i < 10; i++)
fd[i] = open("/dev/ttyprintk", O_WRONLY);
ioctl(fd[0], TIOCVHANGUP);
for (i = 0; i < 10; i++)
close(fd[i]);
close(open("/dev/ttyprintk", O_WRONLY));
return 0;
}
----------
When TTY hangup happens, port->count needs to be reset via
"struct tty_operations"->hangup callback.
There are a lot of tty-core-only functions that are listed in
include/linux/tty.h. Move them to drivers/tty/tty.h so that no one else
can accidentally call them or think that they are public functions.
tty: audit: move some local functions out of tty.h
The functions tty_audit_add_data() and tty_audit_tiocsti() are local to
the tty core code, and do not need to be in a "kernel-wide" header file
so move them to drivers/tty/tty.h
There are a number of functions and #defines in include/linux/tty.h that
do not belong there as they are private to the tty core code.
Create an initial drivers/tty/tty.h file and copy the odd "tty logging"
macros into it to seed the file with some initial things that we know
nothing outside of the tty core should be calling.
dt-bindings: serial: 8250: add aspeed, lpc-io-reg and aspeed, lpc-interrupts
These correspond to the existing lpc_address, sirq, and sirq_polarity
sysfs attributes; the second element of aspeed,lpc-interrupts provides
a replacement for the deprecated aspeed,sirq-polarity-sense property.
serial: 8250_aspeed_vuart: add aspeed, lpc-io-reg and aspeed, lpc-interrupts DT properties
These allow describing all the Aspeed VUART attributes currently
available via sysfs. aspeed,lpc-interrupts provides a replacement for
the deprecated aspeed,sirq-polarity-sense property.
serial: 8250_aspeed_vuart: refactor sirq and lpc address setting code
This splits dedicated aspeed_vuart_set_{sirq,lpc_address}() functions
out of the sysfs store functions in preparation for adding DT
properties that will be poking the same registers. While we're at it,
these functions now provide some basic bounds-checking on their
arguments.
This property ties SIRQ polarity to SCU register bits that don't
necessarily have any direct relationship to it; the only use of it was
removed in commit 449e48249b2d ("ARM: aspeed: g5: Do not set sirq
polarity").
Johan Hovold [Fri, 9 Apr 2021 07:35:12 +0000 (09:35 +0200)]
tty: clarify that not all ttys have a class device
Commit cb419364fd17 ("tty: add tty_struct->dev pointer to corresponding
device instance") added a struct device pointer field to struct
tty_struct which was populated with the corresponding tty class device
during initialisation.
Unfortunately, not all ttys have a class device (e.g. pseudoterminals
and serdev) in which case the device pointer will be set to NULL,
something which have bit driver authors over the years.
In retrospect perhaps this field should never have been added, but let's
at least document the current behaviour.
Bixuan Cui [Sat, 10 Apr 2021 03:50:48 +0000 (11:50 +0800)]
serial: Add missing MODULE_DEVICE_TABLE
This patch adds missing MODULE_DEVICE_TABLE definition which generates
correct modalias for automatic loading of this driver when it is built
as an external module.
Johan Hovold [Wed, 7 Apr 2021 09:52:08 +0000 (11:52 +0200)]
serial: core: return early on unsupported ioctls
Drivers can return -ENOIOCTLCMD when an ioctl is not recognised to tell
the upper layers to continue looking for a handler.
This is not the case for the RS485 and ISO7816 ioctls whose handlers
should return -ENOTTY directly in case a serial driver does not
implement the corresponding methods.
Johan Hovold [Wed, 7 Apr 2021 09:52:07 +0000 (11:52 +0200)]
serial: core: drop redundant TIOCGSERIAL memset
Since commit c6639bf1e580 ("serial_core: switch to ->[sg]et_serial()")
the serial structure passed to uart_get_info() has already have been
cleared by the tty layer so drop the redundant memset.
Johan Hovold [Wed, 7 Apr 2021 09:52:03 +0000 (11:52 +0200)]
tty: fix return value for unsupported termiox ioctls
Drivers should return -ENOTTY ("Inappropriate I/O control operation")
when an ioctl isn't supported, while -EINVAL is used for invalid
arguments.
Support for termiox was added by commit fbacee6fafde ("tty: Add
termiox") in 2008 but no driver support ever followed and it was
recently ripped out by commit 0c70029ff6bd ("tty: Remove dead termiox
code").
Fix the return value for the unsupported termiox ioctls, which have
always returned -EINVAL, by explicitly returning -ENOTTY rather than
removing them completely and falling back to the default unrecognised-
ioctl handling.
Andy Shevchenko [Tue, 6 Apr 2021 13:16:15 +0000 (16:16 +0300)]
tty: pti: Remove Kconfig leftovers
The commit 289dd3bfbafc ("misc: pti: Remove driver for deprecated platform")
got rid of deprecated drivers under TTY subsystem, but cleaned only one Kconfig
entry. Remove Kconfig leftovers.
Johan Hovold [Wed, 7 Apr 2021 10:23:34 +0000 (12:23 +0200)]
tty: synclink_gt: drop redundant tty-port initialisation
The port close_delay and closing_wait parameters have already been by
tty_port_init() so drop the redundant driver initialisation to the
default values.
Johan Hovold [Wed, 7 Apr 2021 10:23:33 +0000 (12:23 +0200)]
pcmcia: synclink_cs: drop redundant tty-port initialisation
The port close_delay and closing_wait parameters have already been by
tty_port_init() so drop the redundant driver initialisation to the
default values.
Johan Hovold [Wed, 7 Apr 2021 10:23:31 +0000 (12:23 +0200)]
tty: mxser: fix TIOCSSERIAL jiffies conversions
The port close_delay and closing wait parameters set by TIOCSSERIAL are
specified in jiffies, while the values returned by TIOCGSERIAL are
specified in centiseconds.
Add the missing conversions so that TIOCSSERIAL works as expected also
when HZ is not 100.
Johan Hovold [Wed, 7 Apr 2021 10:23:30 +0000 (12:23 +0200)]
tty: moxa: fix TIOCSSERIAL implementation
TIOCSSERIAL is a horrid, underspecified, legacy interface which for most
serial devices is only useful for setting the close_delay and
closing_wait parameters.
A non-privileged user has only ever been able to set the since long
deprecated ASYNC_SPD flags and trying to change any other *supported*
feature should result in -EPERM being returned. Setting the current
values for any supported features should return success.
Fix the moxa implementation which was returning -EPERM also for a
privileged user when trying to change certain unsupported parameters and
instead return success consistently.
The tty-port close_delay and closing_wait parameters set by TIOCSSERIAL
are specified in jiffies, while the values returned by TIOCGSERIAL are
specified in centiseconds.
Add the missing conversions so that TIOCSSERIAL works as expected also
if this code is ever reused on a system where HZ is not 100.
Johan Hovold [Wed, 7 Apr 2021 10:23:25 +0000 (12:23 +0200)]
staging: greybus: uart: clean up TIOCGSERIAL
TIOCSSERIAL is a horrid, underspecified, legacy interface which for most
serial devices is only useful for setting the close_delay and
closing_wait parameters.
The xmit_fifo_size parameter could be used to set the hardware transmit
fifo size of a legacy UART when it could not be detected, but the
interface is limited to eight bits and should be left unset when not
used.
Similarly, baud_base could be used to set the UART base clock when it
could not be detected but might as well be left unset when it is not
known.
The type parameter could be used to set the UART type, but is
better left unspecified (type unknown) when it isn't used.
Note that some applications have historically expected TIOCGSERIAL to be
implemented, but judging from the Debian sources, the port type not
being PORT_UNKNOWN is only used to check for the existence of legacy
serial ports (ttySn). Notably USB serial drivers like ftdi_sio have been
using PORT_UNKNOWN for twenty years without any problems.
Drop the bogus values provided by the greybus implementation.
TIOCSSERIAL is a horrid, underspecified, legacy interface which for most
serial devices is only useful for setting the close_delay and
closing_wait parameters.
A non-privileged user has only ever been able to set the since long
deprecated ASYNC_SPD flags and trying to change any other *supported*
feature should result in -EPERM being returned. Setting the current
values for any supported features should return success.
Fix the greybus implementation which instead indicated that the
TIOCSSERIAL ioctl was not even implemented when a non-privileged user
set the current values.
Johan Hovold [Wed, 7 Apr 2021 10:23:22 +0000 (12:23 +0200)]
staging: fwserial: fix TIOCGSERIAL implementation
TIOCSSERIAL is a horrid, underspecified, legacy interface which for most
serial devices is only useful for setting the close_delay and
closing_wait parameters.
The xmit_fifo_size parameter could be used to set the hardware transmit
fifo size of a legacy UART when it could not be detected, but the
interface is limited to eight bits and should be left unset when not
used.
Fix the fwserial implementation by dropping its custom interpretation of
the unused xmit_fifo_size field, which was overflowed with the driver
FIFO size. Also leave the type and flags fields unset as these cannot be
changed.
The close_delay and closing_wait parameters returned by TIOCGSERIAL are
specified in centiseconds. The driver does not yet support changing
closing_wait, but let's report back the default value actually used (30
seconds).
Fixes: 8f2f22c56fbc ("staging: fwserial: Add TTY-over-Firewire serial driver") Signed-off-by: Johan Hovold <johan@kernel.org> Link: https://lore.kernel.org/r/20210407102334.32361-5-johan@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Johan Hovold [Wed, 7 Apr 2021 10:23:21 +0000 (12:23 +0200)]
staging: fwserial: fix TIOCSSERIAL implementation
TIOCSSERIAL is a horrid, underspecified, legacy interface which for most
serial devices is only useful for setting the close_delay and
closing_wait parameters.
A non-privileged user has only ever been able to set the since long
deprecated ASYNC_SPD flags and trying to change any other *supported*
feature should result in -EPERM being returned. Setting the current
values for any supported features should return success.
Fix the fwserial implementation which was returning -EPERM also for a
privileged user when trying to change certain unsupported parameters,
and instead return success consistently.
Fixes: 8f2f22c56fbc ("staging: fwserial: Add TTY-over-Firewire serial driver") Signed-off-by: Johan Hovold <johan@kernel.org> Link: https://lore.kernel.org/r/20210407102334.32361-4-johan@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
A test was added to the probe function to ensure the device was
actually connected and working before successfully completing a
probe. If the device was actually there, but the I2C bus was not
ready yet for whatever reason, the probe fails permanently.
Change the probe so that we defer the probe on a regmap read
failure so that we try the probe again when the dependent drivers
are potentially loaded. This should not affect the case where the
device truly isn't present because the probe will never successfully
complete.
Zheyu Ma [Sat, 3 Apr 2021 06:58:36 +0000 (06:58 +0000)]
firewire: nosy: Fix a use-after-free bug in nosy_ioctl()
For each device, the nosy driver allocates a pcilynx structure.
A use-after-free might happen in the following scenario:
1. Open nosy device for the first time and call ioctl with command
NOSY_IOC_START, then a new client A will be malloced and added to
doubly linked list.
2. Open nosy device for the second time and call ioctl with command
NOSY_IOC_START, then a new client B will be malloced and added to
doubly linked list.
3. Call ioctl with command NOSY_IOC_START for client A, then client A
will be readded to the doubly linked list. Now the doubly linked
list is messed up.
4. Close the first nosy device and nosy_release will be called. In
nosy_release, client A will be unlinked and freed.
5. Close the second nosy device, and client A will be referenced,
resulting in UAF.
The root cause of this bug is that the element in the doubly linked list
is reentered into the list.
Fix this bug by adding a check before inserting a client. If a client
is already in the linked list, don't insert it.
The following KASAN report reveals it:
BUG: KASAN: use-after-free in nosy_release+0x1ea/0x210
Write of size 8 at addr ffff888102ad7360 by task poc
CPU: 3 PID: 337 Comm: poc Not tainted 5.12.0-rc5+ #6
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.12.0-59-gc9ba5276e321-prebuilt.qemu.org 04/01/2014
Call Trace:
nosy_release+0x1ea/0x210
__fput+0x1e2/0x840
task_work_run+0xe8/0x180
exit_to_user_mode_prepare+0x114/0x120
syscall_exit_to_user_mode+0x1d/0x40
entry_SYSCALL_64_after_hwframe+0x44/0xae
The buggy address belongs to the object at ffff888102ad7300 which belongs to the cache kmalloc-128 of size 128
The buggy address is located 96 bytes inside of 128-byte region [ffff888102ad7300, ffff888102ad7380)
[ Modified to use 'list_empty()' inside proper lock - Linus ]
Merge tag 'io_uring-5.12-2021-04-03' of git://git.kernel.dk/linux-block
POull io_uring fix from Jens Axboe:
"Just fixing a silly braino in a previous patch, where we'd end up
failing to compile if CONFIG_BLOCK isn't enabled.
Not that a lot of people do that, but kernel bot spotted it and it's
probably prudent to just flush this out now before -rc6.
Sorry about that, none of my test compile configs have !CONFIG_BLOCK"
* tag 'io_uring-5.12-2021-04-03' of git://git.kernel.dk/linux-block:
io_uring: fix !CONFIG_BLOCK compilation failure
projects / kernel.git / log