u-boot.git/drivers/serial, branch v2026.01

serial: s5p: add compatible for exynos8895

2025-11-12T04:58:36+00:00

Add the compatible for Exynos8895 UART as described in upstream
devicetree bindings. This enables support for Exynos8895 and other
similar UART devices, such as Exynos7870. Other than that, the driver
works as-is.

Signed-off-by: Kaustabh Chakraborty 
Reviewed-by: Henrik Grimler 
Signed-off-by: Minkyu Kang

serial: make VPL_DM_SERIAL depend on VPL_DM

2025-11-06T23:33:31+00:00

I have a hunch VPL_DM_SERIAL should not be selectable if VPL isn't set
as implied by the prefix. Additionally, still based on the prefix, I'm
assuming VPL_DM should be a dependency. Since VPL_DM can only be
selectable when VPL is enabled, only depend on VPL_DM.

This mirrors SPL_DM_SERIAL and TPL_DM_SERIAL so seems right to me.

Signed-off-by: Quentin Schulz 
Reviewed-by: Tom Rini 
Reviewed-by: Simon Glass

serial: msm-geni: implement firmware loading

2025-10-30T17:04:51+00:00

Teach the GENI UART driver to load firmware, similar to i2c.

This is primarily intended for non-debug UARTs, but since we don't
support using these as the console we abort probe for now.

Remove duplicated register macros that are in the common geni-se header.

Signed-off-by: Casey Connolly 
Link: https://patch.msgid.link/20250714-geni-load-fw-v5-7-5abbc0d29838@linaro.org
Signed-off-by: Casey Connolly

serial: msm-geni: Enable SE clk in probe

2025-10-30T17:04:51+00:00

Enable the serial engine clk in probe so that this driver can work on
platforms that don't already initialize the clk for this device before
this driver runs. This fixes a problem I see on Coreboot platforms like
Trogdor where the UART hardware isn't enabled by coreboot unless the
serial console build is used.

Signed-off-by: Stephen Boyd 
Link: https://patch.msgid.link/20250714-geni-load-fw-v5-6-5abbc0d29838@linaro.org
Signed-off-by: Casey Connolly

misc: introduce Qcom GENI wrapper

2025-10-30T17:04:51+00:00

Qualcomm peripherals like UART, SPI, I2C, etc are all exposed under a
common GENI Serial Engine wrapper device. Replace the stub driver we use
for this currently with a full-on misc device and implement support for
loading peripheral firmware.

Each of the peripherals has it's own protocol-specific firmware, this is
stored on the internal storage of the device with a well-known partition
type GUID.

To support this, GENI will bind peripherals in two stages. First the
ones that already have firmware loaded (such as the serial port) are
bound in the typical way. But devices that require firmware loading are
deferred until EVT_LAST_STAGE_INIT. At this point we can be sure that
the storage device is available, so we load the firmware and then bind
and probe the remaining children.

Child devices are expected to determine if firmware loading is necessary
and call qcom_geni_load_firmware().

Since Linux currently doesn't support loading firmware (and firmware may
not be available), we probe all GENI peripherals to ensure that they
always load firmware if necessary.

Signed-off-by: Casey Connolly 
Link: https://patch.msgid.link/20250714-geni-load-fw-v5-3-5abbc0d29838@linaro.org
Signed-off-by: Casey Connolly

serial: msm: Use single character mode

2025-10-29T11:27:33+00:00

The UART DM controller supports different channel data packing modes,
either the 4-character packing mode (where 32-bit are read/written at once)
or the single-character mode (where only a single character is read/written
at a time). The 4-character mode can be more efficient, but the
single-character mode is much easier to implement.

At the moment, serial_msm uses the 4-character mode. Since the
dm_serial_ops operate on one character at the time, the code goes through
quite some hoops in order to break this down to single characters. This
code is prone to race conditions (e.g. priv->chars_cnt is read from the
registers, then a command is issued, what if another char came in
inbetween?). It also seems to cause another subtle issue with autoboot:

Unlike the previous autoboot failures that happened when UART was
disconnected, this problem occurs when UART is connected and open in a
terminal: For EFI boot, the console size is queried in efi_console.c
query_console_serial() by sending an ANSI escape code via UART. For some
reason, with the current driver we get yet another 0x00 byte (UART break
event?) when reading the reply from serial input. Because of that, reading
the console size fails in efi_console.c, the actual reply remains in the
UART buffer, and later the boot flow aborts because it detects input after
printing a prompt.

Rather than trying to fix the issue in the current complicated approach,
switch the driver to use the single-character mode. This is simple and
straightforward to implement without race conditions:

- We write one character at a time to UARTDM_TF, as long as the TX FIFO
has space available (TX_READY). To flush the console before starting
Linux, we wait for TX_EMPTY.

- We read one character at a time from UARTDM_RF and strip off the
additional error information (assuming there is something in the
RX FIFO, as indicated by RX_READY).

In this mode, querying the serial console size works and autoboot is no
longer interrupted. The overall code is also much shorter.

Reviewed-by: Neil Armstrong
Signed-off-by: Stephan Gerhold
Tested-by: Alexey Minnekhanov
Acked-by: Sumit Garg
Link: https://lore.kernel.org/r/20250908-db410c-autoboot-fixes-v2-6-316ed98e0143@linaro.org
Signed-off-by: Casey Connolly

serial: msm: Re-enable after resetting

2025-10-29T11:27:33+00:00

The documentation for the UART controller in the APQ8016E specifies that
both RESET and ENABLE commands must be issued to set up the receiver and
transmitter, but at the moment we only issue RESET. This doesn't seem to
cause issues in practice (looks like the reset already re-enables the
receiver/transmitter), but let's add the two writes to RX_ENABLE/TX_ENABLE
to better match the recommendations in the documentation.

Reviewed-by: Neil Armstrong 
Signed-off-by: Stephan Gerhold 
Tested-by: Alexey Minnekhanov 
Acked-by: Sumit Garg 
Link: https://lore.kernel.org/r/20250908-db410c-autoboot-fixes-v2-5-316ed98e0143@linaro.org
Signed-off-by: Casey Connolly

serial: msm: Reset after writing to DMEN

2025-10-29T11:27:33+00:00

According to the documentation of the UART controller in the APQ8016E TRM,
clearing bits inside UARTDM_DMEN requires resetting the transmitter and/or
receiver. We do reset inside uart_dm_init(), but before writing to
UARTDM_DMEN. This doesn't seem to cause problems in practice, but let's
move the reset to the end of uart_dm_init() to better match the
recommendations in the documentation.

Reviewed-by: Neil Armstrong 
Signed-off-by: Stephan Gerhold 
Tested-by: Alexey Minnekhanov 
Acked-by: Sumit Garg 
Link: https://lore.kernel.org/r/20250908-db410c-autoboot-fixes-v2-4-316ed98e0143@linaro.org
Signed-off-by: Casey Connolly

serial: msm: Cleanup register naming

2025-10-29T11:27:33+00:00

Some of the register definitions are inconsistently named (likely copied
as-is from Qualcomm's Little Kernel/LK bootloader, which uses the
MSM_BOOT_UART naming scheme). Rename them to be in line with the other
register definitions and move them up to be next to the related register.

No functional change.

Signed-off-by: Stephan Gerhold 
Tested-by: Alexey Minnekhanov 
Acked-by: Sumit Garg 
Link: https://lore.kernel.org/r/20250908-db410c-autoboot-fixes-v2-3-316ed98e0143@linaro.org
Signed-off-by: Casey Connolly

Revert "serial: serial_msm: Delay initialization to let pins stabilize"

2025-10-29T11:27:33+00:00

There have been issues with autoboot on DB410c for years, where autoboot
gets interrupted by spurious input on the UART console. Back in 2021, I've
tried to fix this by inserting a delay before UART initialization, but it
has turned out this is not working reliably either.

It looks like the root cause has always been the lack of bias-pull-up,
which was causing the RX line to be floating when UART is disconnected.
The delay does not seem to be needed anymore when applying bias-pull-up,
so drop it again in favor of the proper fix.

This reverts commit ad7e967738a9c639e07cf50b83ffccdf9a8537b0.

Signed-off-by: Stephan Gerhold 
Tested-by: Alexey Minnekhanov 
Acked-by: Sumit Garg 
Link: https://lore.kernel.org/r/20250908-db410c-autoboot-fixes-v2-2-316ed98e0143@linaro.org
Signed-off-by: Casey Connolly