Manikanta Guntupalli [Tue, 23 Jan 2024 06:16:54 +0000 (11:46 +0530)]
tty: serial: uartps: Relocate cdns_uart_tx_empty to facilitate rs485
Relocate cdns_uart_tx_empty function to avoid prototype statement in
rs485 changes.
Update return check with uart_tx_stopped() in cdns_uart_handle_tx().
Rengarajan S [Thu, 25 Jan 2024 10:06:19 +0000 (15:36 +0530)]
8250: microchip: Add 4 Mbps support in PCI1XXXX UART
The current clock input is set to 62.5 MHz for supporting fractional
divider, which enables generation of an acceptable baud rate from any
frequency. With the current clock input the baud rate range is limited
to 3.9 Mbps. Hence, the current range is extended to support 4 Mbps
with Burst mode operation. Divisor calculation for a given baud rate is
updated as the sampling rate is reduced from 16 to 8 for 4 Mbps.
Rengarajan S [Thu, 25 Jan 2024 10:00:06 +0000 (15:30 +0530)]
8250: microchip: pci1xxxx: Add Burst mode transmission support in uart driver for reading from FIFO
pci1xxxx_handle_irq reads the burst status and checks if the FIFO
is empty and is ready to accept the incoming data. The handling is
done in pci1xxxx_tx_burst where each transaction processes data in
block of DWORDs, while any remaining bytes are processed individually,
one byte at a time.
This SoC family was destined for server use, featuring Qualcomm's very
interesting Kryo cores (before "Kryo" became a marketing term for Arm
cores with small modifications). It did however not leave the labs of
Qualcomm and presumably some partners, nor was it ever productized.
Remove the workarounds, as they are long obsolete.
Tudor Ambarus [Fri, 19 Jan 2024 10:45:26 +0000 (10:45 +0000)]
tty: serial: samsung: shrink memory footprint of ``struct s3c24xx_uart_info``
Use u32 for the members of ``struct s3c24xx_uart_info`` that are used
for register interactions. The purpose of these members becomes clearer.
The greater benefit of this change is that it also reduces the memory
footprint of the struct, allowing 64-bit architectures to use a
single cacheline for the entire struct.
Tudor Ambarus [Fri, 19 Jan 2024 10:45:25 +0000 (10:45 +0000)]
tty: serial: samsung: change has_divslot type to bool
Since the driver was introduced the port features flags never extended.
As we don't expect more flags soon that would bypass the first
cacheline of ``struct s3c24xx_uart_info``, change the type of
``has_divslot`` to bool. Bitfields operations incur performance penalty
when set or read as compared to direct types.
Tudor Ambarus [Fri, 19 Jan 2024 10:45:24 +0000 (10:45 +0000)]
tty: serial: samsung: shrink the clock selection to 8 clocks
<linux/serial_s3c.h> provides a clock selection pool of maximum 4 clocks.
Update the driver to consider a pool selection of maximum 8 clocks.
u8 is large enough to allow more clocks than are supported by the driver
now, and not too big to cause spanning of ``struct s3c24xx_uart_info``
through 2 cachelines when compiled for arm64. The goal is to reduce the
memory footprint of ``struct s3c24xx_uart_info``.
Tudor Ambarus [Fri, 19 Jan 2024 10:45:23 +0000 (10:45 +0000)]
tty: serial: samsung: change return type for s3c24xx_serial_rx_fifocnt()
Change the return type of the s3c24xx_serial_rx_fifocnt() method to
``unsigned int`` as the method only returns the fifo size and does not
handle error codes.
Tudor Ambarus [Fri, 19 Jan 2024 10:45:21 +0000 (10:45 +0000)]
tty: serial: samsung: return bool for s3c24xx_serial_txempty_nofifo()
s3c24xx_serial_txempty_nofifo() returned either 0 or BIT(2), which is
counterintuitive. Make the method return bool, and return true when TX
is empty and false otherwise.
Tudor Ambarus [Fri, 19 Jan 2024 10:45:20 +0000 (10:45 +0000)]
tty: serial: samsung: don't compare with zero an if (bitwise expression)
The bitwise AND with the fifo mask is used to check if the fifo is empty
or not, it doesn't care about the length, thus the comparison with zero
is implicit. Rely on the implicit comparison instead.
Tudor Ambarus [Fri, 19 Jan 2024 10:45:18 +0000 (10:45 +0000)]
tty: serial: samsung: drop superfluous comment
The comment brings no benefit as we can already see from the method's
name, ``s3c24xx_serial_pm``, that it deals with power management.
Drop the superfluous comment.
Tudor Ambarus [Fri, 19 Jan 2024 10:45:14 +0000 (10:45 +0000)]
tty: serial: samsung: explicitly include <linux/types.h>
samsung_tty.c uses u32 and relies on <linux/console.h> to include
<linux/types.h>. Explicitly include <linux/types.h>. We shall aim to
have the driver self contained.
Tudor Ambarus [Fri, 19 Jan 2024 10:45:12 +0000 (10:45 +0000)]
tty: serial: samsung: add gs101 earlycon support
The entire bus (PERIC) on which the GS101 serial resides only allows
32-bit register accesses. The reg-io-width dt property is disallowed
for the "google,gs101-uart" compatible and instead the iotype is
inferred from the compatible. Always set UPIO_MEM32 iotype for the
gs101 earlycon.
Reviewed-by: Peter Griffin <peter.griffin@linaro.org> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Reviewed-by: Sam Protsenko <semen.protsenko@linaro.org> Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org> Link: https://lore.kernel.org/r/20240119104526.1221243-6-tudor.ambarus@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Tudor Ambarus [Fri, 19 Jan 2024 10:45:11 +0000 (10:45 +0000)]
tty: serial: samsung: set UPIO_MEM32 iotype for gs101
GS101's Connectivity Peripheral blocks (peric0/1 blocks) which
include the I3C and USI (I2C, SPI, UART) only allow 32-bit
register accesses.
Instead of specifying the reg-io-width = 4 everywhere, for each node,
the requirement should be deduced from the compatible.
Infer UPIO_MEM32 iotype from the "google,gs101-uart" compatible.
Update the uart info name to be GS101 specific in order to
differentiate from the other exynos platforms. All the other settings
are not changed.
exynos_fifoszdt_serial_drv_data was replaced by gs101_serial_drv_data
because the iotype restriction is gs101 specific and there was no other
user of exynos_fifoszdt_serial_drv_data.
Reviewed-by: Peter Griffin <peter.griffin@linaro.org> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Reviewed-by: Sam Protsenko <semen.protsenko@linaro.org> Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org> Link: https://lore.kernel.org/r/20240119104526.1221243-5-tudor.ambarus@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Tudor Ambarus [Fri, 19 Jan 2024 10:45:10 +0000 (10:45 +0000)]
tty: serial: samsung: prepare for different IO types
GS101's Connectivity Peripheral blocks (peric0/1 blocks) which
include the I3C and USI (I2C, SPI, UART) only allow 32-bit
register accesses. If using 8-bit register accesses, a SError
Interrupt is raised causing the system unusable.
Instead of specifying the reg-io-width = 4 everywhere, for each node,
the requirement should be deduced from the compatible.
Prepare the samsung tty driver to allow IO types different than
UPIO_MEM. ``struct uart_port::iotype`` is an unsigned char where all
its 8 bits are exposed to uapi. We can't make NULL checks on it to
verify if it's set, thus always set it from the driver's data.
Use u8 for the ``iotype`` member of ``struct s3c24xx_uart_info`` to
emphasize that the iotype is an 8 bit mask.
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Reviewed-by: Sam Protsenko <semen.protsenko@linaro.org> Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org> Link: https://lore.kernel.org/r/20240119104526.1221243-4-tudor.ambarus@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Tudor Ambarus [Fri, 19 Jan 2024 10:45:09 +0000 (10:45 +0000)]
dt-bindings: serial: samsung: do not allow reg-io-width for gs101
All gs101 serial ports are restricted to 32-bit register accesses.
This requirement will be inferred from the compatible. Do not allow
the reg-io-width property for the google,gs101-uart compatible.
Suggested-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Reviewed-by: Peter Griffin <peter.griffin@linaro.org> Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org> Reviewed-by: Sam Protsenko <semen.protsenko@linaro.org> Link: https://lore.kernel.org/r/20240119104526.1221243-3-tudor.ambarus@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Tudor Ambarus [Fri, 19 Jan 2024 10:45:08 +0000 (10:45 +0000)]
tty: serial: samsung: fix tx_empty() to return TIOCSER_TEMT
The core expects for tx_empty() either TIOCSER_TEMT when the tx is
empty or 0 otherwise. s3c24xx_serial_txempty_nofifo() might return
0x4, and at least uart_get_lsr_info() tries to clear exactly
TIOCSER_TEMT (BIT(1)). Fix tx_empty() to return TIOCSER_TEMT.
Valentin Caron [Fri, 12 Jan 2024 09:53:00 +0000 (10:53 +0100)]
serial: stm32: get FIFO size from hwcfg register
Since STM32MP25, FIFO size could vary regarding the STM32MPxx version.
So we get this size from "hwcfgr1" register and compute threshold values
corresponding to the ratio given by reference manual.
As STM32MP1x, STM32MP25 and STM32H7 share the same compatible and STM32H7
doesn't have a register to get FIFO size, we force FIFO size to 16 in case
of zero read from hwcfgr1 register.
Valentin Caron [Fri, 12 Jan 2024 09:52:57 +0000 (10:52 +0100)]
serial: stm32: implement prescaler tuning to compute low baudrate
In the case of high USART input clock and low baud rate, BRR value
is not enough to get correct baud rate. So here we use USART prescaler to
divide USART input clock to get the correct baud rate.
Douglas Anderson [Fri, 12 Jan 2024 23:03:08 +0000 (15:03 -0800)]
serial: qcom-geni: Don't cancel/abort if we can't get the port lock
As of commit d7402513c935 ("arm64: smp: IPI_CPU_STOP and
IPI_CPU_CRASH_STOP should try for NMI"), if we've got pseudo-NMI
enabled then we'll use it to stop CPUs at panic time. This is nice,
but it does mean that there's a pretty good chance that we'll end up
stopping a CPU while it holds the port lock for the console
UART. Specifically, I see a CPU get stopped while holding the port
lock nearly 100% of the time on my sc7180-trogdor based Chromebook by
enabling the "buddy" hardlockup detector and then doing:
UART drivers are _supposed_ to handle this case OK and this is why
UART drivers check "oops_in_progress" and only do a "trylock" in that
case. However, before we enabled pseudo-NMI to stop CPUs it wasn't a
very well-tested situation.
Now that we're testing the situation a lot, it can be seen that the
Qualcomm GENI UART driver is pretty broken. Specifically, when I run
my test case and look at the console output I just see a bunch of
garbled output like:
That's obviously not so great. This happens because each call to the
console driver exits after the data has been written to the FIFO but
before it's actually been flushed out of the serial port. When we have
multiple calls into the console one after the other then (if we can't
get the lock) each call tells the UART to throw away any data in the
FIFO that hadn't been transferred yet.
I've posted up a patch to change the arm64 core to avoid this
situation most of the time [1] much like x86 seems to do, but even if
that patch lands the GENI driver should still be fixed.
>From testing, it appears that we can just delete the cancel/abort in
the case where we weren't able to get the UART lock and the output
looks good. It makes sense that we'd be able to do this since that
means we'll just call into __qcom_geni_serial_console_write() and
__qcom_geni_serial_console_write() looks much like
qcom_geni_serial_poll_put_char() but with a loop. However, it seems
safest to poll the FIFO and make sure it's empty before our
transfer. This should reliably make sure that we're not
interrupting/clobbering any existing transfers.
As part of this change, we'll also avoid re-setting up a TX at the end
of the console write function if we weren't able to get the lock,
since accessing "port->tx_remaining" without the lock is not
safe. This is only needed to re-start userspace initiated transfers.
Geert Uytterhoeven [Wed, 10 Jan 2024 13:21:46 +0000 (14:21 +0100)]
serial: 8250: Move hp300_setup_serial_console() to <linux/serial_8250.h>
If CONFIG_SERIAL_8250_HP300=y and CONFIG_SERIAL_8250_CONSOLE=y (e.g.
m68k/allyesconfig):
drivers/tty/serial/8250/8250_hp300.c:91:12: error: no previous prototype for ‘hp300_setup_serial_console’ [-Werror=missing-prototypes]
91 | int __init hp300_setup_serial_console(void)
| ^~~~~~~~~~~~~~~~~~~~~~~~~~
Fix this by moving the existing prototype in arch/m68k/hp300/config.c to
<linux/serial_8250.h>, so it is visible to both caller and implementor.
While at it, provide a dummy in case CONFIG_SERIAL_8250_CONSOLE is not
enabled, to reduce #ifdef clutter in the caller.
Exposed by commit 0fcb70851fbfea17 ("Makefile.extrawarn: turn on
missing-prototypes globally").
Roman Žilka [Tue, 9 Jan 2024 10:43:46 +0000 (11:43 +0100)]
tty/vt: UTF-8 parsing update according to RFC 3629, modern Unicode
vc_translate_unicode() and vc_sanitize_unicode() parse input to the
UTF-8-enabled console, marking invalid byte sequences and producing Unicode
codepoints. The current algorithm follows ancient Unicode and may accept
invalid byte sequences, pass on non-existent codepoints and reject valid
sequences.
The patch restores the functions' compliance with modern Unicode (v15.1 [1]
+ many previous versions) as well as RFC 3629 [2].
1. Codepoint space is limited to 0x10FFFF.
2. "Noncharacters", such as U+FFFE, U+FFFF, are no longer invalid in
Unicode and will be accepted. Another option was to complete the set of
noncharacters (used to be just those two, now there's more) and preserve
the rejection step. This is indeed what Unicode suggests ([1] chap.
23.7) (not requires), but most codepoints are !iswprint(), so selecting
just the noncharacters seemed arbitrary and futile (and unnecessary).
This is not a security patch. I'm not aware of any present security
implications of the old code.
Francesco Dolcini [Mon, 22 Jan 2024 18:05:51 +0000 (19:05 +0100)]
treewide, serdev: change receive_buf() return type to size_t
receive_buf() is called from ttyport_receive_buf() that expects values
">= 0" from serdev_controller_receive_buf(), change its return type from
ssize_t to size_t.
The need for this clean-up was noticed while fixing a warning, see
commit 94d053942544 ("Bluetooth: btnxpuart: fix recv_buf() return value").
Changing the callback prototype to return an unsigned seems the best way
to document the API and ensure that is properly used.
GNSS drivers implementation of serdev receive_buf() callback return
directly the return value of gnss_insert_raw(). gnss_insert_raw()
returns a signed int, however this is not an issue since the value
returned is always positive, because of the kfifo_in() implementation.
gnss_insert_raw() could be changed to return also an unsigned, however
this is not implemented here as request by the GNSS maintainer Johan
Hovold.
Suggested-by: Jiri Slaby <jirislaby@kernel.org> Link: https://lore.kernel.org/all/087be419-ec6b-47ad-851a-5e1e3ea5cfcc@kernel.org/ Signed-off-by: Francesco Dolcini <francesco.dolcini@toradex.com> Acked-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> #for-iio Reviewed-by: Johan Hovold <johan@kernel.org> Reviewed-by: Rob Herring <robh@kernel.org> Reviewed-by: Alex Elder <elder@linaro.org> Acked-by: Maximilian Luz <luzmaximilian@gmail.com> # for platform/surface Acked-by: Lee Jones <lee@kernel.org> Acked-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Link: https://lore.kernel.org/r/20240122180551.34429-1-francesco@dolcini.it Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
selection.c and vt.c still uses tabs in the kernel-doc. This misrenders the
functions in the output -- sphinx misinterprets the description. So
remove these tabs, incl. those around dashes.
'enum' keyword is needed before enum names. Fix that.
Superfluous \n after the comments are also removed. They are not
completely faulty, but this unifies all the kernel-doc in the files.
Again, fbcon_getxy() is the same as the default implementation since the
softscroll removal in commit 50145474f6ef (fbcon: remove soft scrollback
code). Drop that.
tty: vt: make types of screenpos() more consistent
* parameter offset: it is expected to be non-negative, so switch to
unsigned
* return type: switch from ushort to explicit u16. This is expected on
most places. And fix the remaining two places too.
fbcon_screen_pos() performs the same as the default implementation. The
only difference in the default implementation is that is considers both
vc->vc_origin and vc->vc_visible_origin. But given fbcon's softscroll
code was already removed in commit 50145474f6ef (fbcon: remove soft
scrollback code), both are always the same.
tty: vt: make types around consw::con_blank() bool
Both the mode_switch parameter and the return value (a redraw needed)
are true/false. So switch them to bool, so that users won't return
-Eerrors or anything else.
tty: vt: define a common enum for VESA blanking constants
There are currently two places with VESA blanking constants definitions:
fb.h and console.h. Extract/unify the two to a separate header (vesa.h).
Given the fb's is in an uapi header, create the common header in uapi
too.
Note that instead of macros, an enum (vesa_blank_mode) is created. But
the macros are kept too (they now expand to the enum constants), just in
case someone in userspace performs some #ifdeffery.
tty: vt: stop using -1 for blank mode in consw::con_blank()
-1 is the same as VESA_VSYNC_SUSPEND in all con_blank() implementations.
So we can remove this special case from vgacon now too.
Despite con_blank() of fbcon looks complicated, the "if
(!fbcon_is_inactive(vc, info))" branch is not taken as we set
"ops->graphics = 1;" few lines above. So what matters there (as in all
other blank implementations except vgacon) is if 'blank' is zero or not.
The non-zero (true) return value from consw::con_switch() means a redraw
is needed. So make this return type a bool explicitly instead of int.
The latter might imply that -Eerrors are expected. They are not.
fbdev/core: simplify cursor_state setting in fbcon_ops::cursor()
There is a switch decicing if cursor should be drawn or not. The whole
switch can be simplified to one line. Do this cleanup as a preparatory
work for the next patch. There, all the CM_* constants are removed.
consoles: use if instead of switch-case in consw::con_cursor()
This is only a preparation for the following cleanup patch to make it
easier. Provided CM_ERASE is the only different, use 'if' instead of
'switch+case' in all those.
Similar to con_putc() in the previous patch:
* make the pointer to charattr a pointer to u16, and
* make x, y, and count unsigned as they are strictly non-negative.
Make parameters of consw::con_putc() saner:
* x and y are unsigned now, as they cannot be negative, and
* ca is made u16, as it is composed of two 8bit values (character and
attribute). See the con_putcs() hook, u16/ushort is worked on there.
All these consw::con_putc() implementations do the same as
consw::con_putcs() (only for one charattr) or even call
consw::con_putcs() on their own.
Drop them, as thanks to the new con_putc() helper in the previous patch,
the console code performs this already -- exactly if consw::con_putc()
is missing (NULL).
tty: vt: remove checks for count in consw::con_clear() implementations
'count' in consw::con_clear() is guaranteed to be positive. csi_X() (the
only caller) takes the minimum of the vc parameter (which is at least 1)
and count of characters till the end of the line. The latter is computed
as a subtraction of vc->vc_cols (count) and vc->state.x (offset). So for
the worst case, full line, it is 1.
Therefore, there is no point in checking zero or negative values (width
is now unsigned anyway).
The return value of con_debug_enter() and con_debug_leave() is ignored
on many fronts. So just don't propagate errors (the current
implementations return 0 anyway) and make the return type a void.
The count to process is supposed to be between 1 and vc->vc_cols -
vc->state.x (or rows and .y). clamp() can be used exactly for this,
instead of ifs and min().
It's always confusing to read all those case 0:, case 1: etc. in csi_*
handlers. Define enum entries for all those constants in CSI+m and use
them in csi_m().
It is pretty unfortunate to set vc_data::vc_resize_user in two callers
of vc_do_resize(). vc_resize_user is immediately reset there (while
remembering it). So instead of this back and forth, pass 'from_user' as
a parameter.
Notes on 'int user':
* The name changes from 'user' to 'from_user' on some places to be
consistent.
* The type is bool now as 'int user' might evoke user's uid or whatever.
Provided vc_resize() is called on many places and they need not to care
about this parameter, its prototype is kept unchanged. Instead, it is
now an inline calling a new __vc_resize() which implements the above.
Pass proper types and proper pointers (the data with an offset) to the
TIOCL_* handlers. So that they need not to cast or add anything to the
passed pointer.
At least since commits feebed6515a1 ("tty: shutdown method") and bc1e99d93f09 ("TTY: vt, add ->install"), tty->driver_data in vc is
expected to be set since tty_operations::install() till ::cleanup().
So the checks of !tty->driver_data (aka !vc) in:
* vc_do_resize() by tty -> ioctl(TIOCSWINSZ) -> vt_resize()
* do_con_write() by tty -> tty_operations::write()/::put_char()
* con_flush_chars() by tty -> ::flush_chars()
are all superfluous. And also, holding a console lock is not needed to
fetch tty->driver_data.
Note there is even a stale comment in con_flush_chars() about a race
between that and con_close(). But con_close() does not set
tty->driver_data to NULL for years already.
Drop all these in a hope I am not terribly mistaken.
projects / users / jedix / linux-maple.git / log