[PATCH 0/2] serial: 8250_dw: Fix RX trigger levels for 64-byte FIFOs

[PATCH 0/2] serial: 8250_dw: Fix RX trigger levels for 64-byte FIFOs

[Kryštof Černý via B4 Relay]

DesignWare UARTs that report their FIFO through the CPR register are
always registered as PORT_16550A. For a 64-byte FIFO, as found on the
Rockchip RK3328, the rx_trig_bytes sysfs attribute therefore uses the
16-byte table: it reports 8 bytes while the hardware triggers at 32,
and writing it programs a different level than requested.

Generic autoconfig already classifies a 16550A with a 64-byte FIFO as
PORT_U6_16550A. DesignWare ports without a usable CPR are probed this
way, so the same 64-byte core is registered as U6_16550A or as 16550A
depending on whether its CPR can be read. This series makes the CPR
path pick U6_16550A as well, after first giving PORT_U6_16550A an
rxtrig_bytes table that matches the DesignWare FCR RT encoding.

Patch 1 adds the table to the core. It has to come first: without it,
patch 2 would make the rx_trig_bytes attribute disappear on the
affected ports.

Patch 2 switches 8250_dw to the new type for 64-byte FIFOs.

Things worth reviewing:

- The register programming does not change. FIFO size, TX load size and
  capabilities still come from CPR, and both types use the same default
  FCR value.

- The port type visible to userspace changes from 16550A (4) to
  U6_16550A (19) for these ports, in TIOCGSERIAL, /proc/tty/driver/serial
  and the boot log.

- dw8250_setup_port() is also used by 8250_lpss, so Intel LPSS UARTs with
  a 64-byte FIFO are affected the same way. I could not test on LPSS
  hardware.

- Ports detected as U6_16550A by autoconfig gain the rx_trig_bytes
  attribute. Its highest level, FIFO size - 2, follows the DesignWare
  encoding and may not match non-DesignWare hardware detected this way.

- Only 64-byte FIFOs are handled. DesignWare FIFOs of other depths keep
  using the 16-byte table. Deriving the levels from the FIFO size would
  cover them as well, but needs a new hook in the core. I am happy to go
  that way instead if it is preferred.

Testing:

Tested on a Unipi G110 controller with a Rockchip RK3328, on ttyS1 and
ttyS2, with next-20261029 and with 6.12.114-cip34, each without and
with this series. Both ports have a 64-byte FIFO, and both kernels and
both ports gave identical results.

With the UART in internal loopback at 9600 baud, each value was written
to rx_trig_bytes and 640 bytes were sent. The largest chunk delivered
to userspace shows the trigger level the hardware actually used:

                 without series         with series
  written        reads   hw level       reads   hw level
  1              1       1              1       1
  4              4       16             1       1
  8              8       32             1       1
  16             14      62             16      16
  32             14      62             32      32
  62             14      62             62      62

Without the series the ports register as 16550A and rx_trig_bytes
reports 8 by default, while the default FCR value is the one written
for 8 above, i.e. 32 bytes. With the series they register as
U6_16550A and report 32. Values in between round down to the nearest
level, for example 31 reads back as 16, 40 as 32 and 255 as 62. At
level 62 the TX-empty interrupt also drains the RX FIFO, so 2-byte
chunks appear between the 62-byte ones.

The series was also build-tested with W=1 for arm64 defconfig and for
an x86_64 config with 8250_lpss, at each patch. It was not tested on
Intel LPSS hardware.

The commit messages and this cover letter were drafted with help
from an AI assistant. The changes are used in downstream Unipi kernel.

Signed-off-by: Kryštof Černý <cleverline1mc@gmail.com>
---
Kryštof Černý (2):
      serial: 8250: Add RX trigger levels for U6_16550A
      serial: 8250_dw: Select U6_16550A for 64-byte FIFO

 drivers/tty/serial/8250/8250_dwlib.c | 2 +-
 drivers/tty/serial/8250/8250_port.c  | 1 +
 2 files changed, 2 insertions(+), 1 deletion(-)
---
base-commit: a39c950806213f6861d00f90729acaaa21f2d95a
change-id: 20261030-8250-select-u6-64bit-7717e1a99023

Best regards,
--  
Kryštof Černý <cleverline1mc@gmail.com>

[PATCH 1/2] serial: 8250: Add RX trigger levels for U6_16550A

[Kryštof Černý via B4 Relay]

From: Kryštof Černý <cleverline1mc@gmail.com>

PORT_U6_16550A has a 64-byte FIFO but no rxtrig_bytes table, so the
rx_trig_bytes sysfs attribute is not registered for ports of this type
and the RX trigger level cannot be read or changed from userspace.

Add a table with 1, 16, 32 and 62 bytes, i.e. 1 character, FIFO 1/4
full, FIFO 1/2 full and FIFO 2 less than full. These are the levels the
Synopsys DesignWare UART uses for a 64-byte FIFO, and they match the
existing PORT_ALTR_16550_F64 table.

The default FCR value of the type is unchanged, so the trigger level a
port starts with stays at 1/2 full. The only visible change for ports
already detected as U6_16550A by autoconfig is the new sysfs attribute.

This prepares for 8250_dw selecting PORT_U6_16550A for DesignWare UARTs
with a 64-byte FIFO.

Co-developed-by: Miroslav Ondra <ondra@faster.cz>
Signed-off-by: Miroslav Ondra <ondra@faster.cz>
Signed-off-by: Kryštof Černý <cleverline1mc@gmail.com>
---
 drivers/tty/serial/8250/8250_port.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/tty/serial/8250/8250_port.c b/drivers/tty/serial/8250/8250_port.c
index 36b2b0a2c05c..a7acede62f40 100644
--- a/drivers/tty/serial/8250/8250_port.c
+++ b/drivers/tty/serial/8250/8250_port.c
@@ -163,6 +163,7 @@ static const struct serial8250_config uart_config[] = {
 		.fifo_size	= 64,
 		.tx_loadsz	= 64,
 		.fcr		= UART_FCR_ENABLE_FIFO | UART_FCR_R_TRIG_10,
+		.rxtrig_bytes	= {1, 16, 32, 62},
 		.flags		= UART_CAP_FIFO | UART_CAP_AFE,
 	},
 	[PORT_TEGRA] = {

-- 
2.47.3

[PATCH 2/2] serial: 8250_dw: Select U6_16550A for 64-byte FIFO

[Kryštof Černý via B4 Relay]

From: Kryštof Černý <cleverline1mc@gmail.com>

DesignWare 8250 ports that describe their FIFO in the CPR register are
always configured as PORT_16550A, regardless of the FIFO depth. On
UARTs with a 64-byte FIFO, such as those on the Rockchip RK3328, this
selects the 16-byte rxtrig_bytes table {1, 4, 8, 14}. The rx_trig_bytes
sysfs attribute then reports 8 bytes while the hardware triggers at 32,
and writes to it program the wrong trigger level.

Select PORT_U6_16550A when the CPR reports a 64-byte FIFO. Generic
autoconfig already assigns this type to a 16550A with a 64-byte FIFO,
and its rxtrig_bytes table matches the DesignWare FCR RT encoding.

The FIFO size, TX load size and capabilities are still taken from the
CPR, and the default FCR value is the same for both types, so the
hardware is programmed exactly as before. The port type reported to
userspace changes from 16550A to U6_16550A.

Co-developed-by: Miroslav Ondra <ondra@faster.cz>
Signed-off-by: Miroslav Ondra <ondra@faster.cz>
Signed-off-by: Kryštof Černý <cleverline1mc@gmail.com>
---
 drivers/tty/serial/8250/8250_dwlib.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/tty/serial/8250/8250_dwlib.c b/drivers/tty/serial/8250/8250_dwlib.c
index 9bb02a4ab11f..ae556b06b03a 100644
--- a/drivers/tty/serial/8250/8250_dwlib.c
+++ b/drivers/tty/serial/8250/8250_dwlib.c
@@ -236,9 +236,9 @@ void dw8250_setup_port(struct uart_port *p)
 
 	/* Select the type based on FIFO */
 	if (reg & DW_UART_CPR_FIFO_MODE) {
-		p->type = PORT_16550A;
 		p->flags |= UPF_FIXED_TYPE;
 		p->fifosize = DW_UART_CPR_FIFO_SIZE(reg);
+		p->type = (p->fifosize == 64) ? PORT_U6_16550A : PORT_16550A;
 		up->capabilities = UART_CAP_FIFO | UART_CAP_NOTEMT;
 	}
 

-- 
2.47.3

Re: [PATCH 1/2] serial: 8250: Add RX trigger levels for U6_16550A

[Ilpo Järvinen]

[-- Attachment #1: Type: text/plain, Size: 1934 bytes --]

On Mon, 9 Nov 2026, Kryštof Černý via B4 Relay wrote:

> From: Kryštof Černý <cleverline1mc@gmail.com>
> 
> PORT_U6_16550A has a 64-byte FIFO but no rxtrig_bytes table, so the
> rx_trig_bytes sysfs attribute is not registered for ports of this type
> and the RX trigger level cannot be read or changed from userspace.
> 
> Add a table with 1, 16, 32 and 62 bytes, i.e. 1 character, FIFO 1/4
> full, FIFO 1/2 full and FIFO 2 less than full. These are the levels the
> Synopsys DesignWare UART uses for a 64-byte FIFO, and they match the
> existing PORT_ALTR_16550_F64 table.
> 
> The default FCR value of the type is unchanged, so the trigger level a
> port starts with stays at 1/2 full. The only visible change for ports
> already detected as U6_16550A by autoconfig is the new sysfs attribute.
> 
> This prepares for 8250_dw selecting PORT_U6_16550A for DesignWare UARTs
> with a 64-byte FIFO.
> 
> Co-developed-by: Miroslav Ondra <ondra@faster.cz>
> Signed-off-by: Miroslav Ondra <ondra@faster.cz>
> Signed-off-by: Kryštof Černý <cleverline1mc@gmail.com>
> ---
>  drivers/tty/serial/8250/8250_port.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/tty/serial/8250/8250_port.c b/drivers/tty/serial/8250/8250_port.c
> index 36b2b0a2c05c..a7acede62f40 100644
> --- a/drivers/tty/serial/8250/8250_port.c
> +++ b/drivers/tty/serial/8250/8250_port.c
> @@ -163,6 +163,7 @@ static const struct serial8250_config uart_config[] = {
>  		.fifo_size	= 64,
>  		.tx_loadsz	= 64,
>  		.fcr		= UART_FCR_ENABLE_FIFO | UART_FCR_R_TRIG_10,
> +		.rxtrig_bytes	= {1, 16, 32, 62},

Reusing U6 entry for DW UARTs seems misleading.

We've better mechanism coming up for defining rxtrig in a one pending 
series so this constant friction with the uart config types can be put 
into rest.

Please build on top of that other series and help in testing and reviewing 
it.


-- 
 i.

Re: [PATCH 1/2] serial: 8250: Add RX trigger levels for U6_16550A

[Kryštof Černý]

> On Mon, 9 Nov 2026, Kryštof Černý via B4 Relay wrote:
> 
>> From: Kryštof Černý <cleverline1mc@gmail.com>
>>
>> PORT_U6_16550A has a 64-byte FIFO but no rxtrig_bytes table, so the
>> rx_trig_bytes sysfs attribute is not registered for ports of this type
>> and the RX trigger level cannot be read or changed from userspace.
>>
>> Add a table with 1, 16, 32 and 62 bytes, i.e. 1 character, FIFO 1/4
>> full, FIFO 1/2 full and FIFO 2 less than full. These are the levels the
>> Synopsys DesignWare UART uses for a 64-byte FIFO, and they match the
>> existing PORT_ALTR_16550_F64 table.
>>
>> The default FCR value of the type is unchanged, so the trigger level a
>> port starts with stays at 1/2 full. The only visible change for ports
>> already detected as U6_16550A by autoconfig is the new sysfs attribute.
>>
>> This prepares for 8250_dw selecting PORT_U6_16550A for DesignWare UARTs
>> with a 64-byte FIFO.
>>
>> Co-developed-by: Miroslav Ondra <ondra@faster.cz>
>> Signed-off-by: Miroslav Ondra <ondra@faster.cz>
>> Signed-off-by: Kryštof Černý <cleverline1mc@gmail.com>
>> ---
>>   drivers/tty/serial/8250/8250_port.c | 1 +
>>   1 file changed, 1 insertion(+)
>>
>> diff --git a/drivers/tty/serial/8250/8250_port.c b/drivers/tty/serial/8250/8250_port.c
>> index 36b2b0a2c05c..a7acede62f40 100644
>> --- a/drivers/tty/serial/8250/8250_port.c
>> +++ b/drivers/tty/serial/8250/8250_port.c
>> @@ -163,6 +163,7 @@ static const struct serial8250_config uart_config[] = {
>>   		.fifo_size	= 64,
>>   		.tx_loadsz	= 64,
>>   		.fcr		= UART_FCR_ENABLE_FIFO | UART_FCR_R_TRIG_10,
>> +		.rxtrig_bytes	= {1, 16, 32, 62},
> 
> Reusing U6 entry for DW UARTs seems misleading.
> 
> We've better mechanism coming up for defining rxtrig in a one pending
> series so this constant friction with the uart config types can be put
> into rest.
> 
> Please build on top of that other series and help in testing and reviewing
> it.

Thanks for the information, I started the work about a month ago
and not sure if the patch existed before. I will test the other series 
on my hardware. I like that approach more.

Re: [PATCH 1/2] serial: 8250: Add RX trigger levels for U6_16550A

[Andy Shevchenko]

On Mon, Nov 09, 2026 at 04:37:43PM +0100, Kryštof Černý wrote:
> > On Mon, 9 Nov 2026, Kryštof Černý via B4 Relay wrote:

...

> > Reusing U6 entry for DW UARTs seems misleading.
> > 
> > We've better mechanism coming up for defining rxtrig in a one pending
> > series so this constant friction with the uart config types can be put
> > into rest.
> > 
> > Please build on top of that other series and help in testing and reviewing
> > it.
> 
> Thanks for the information, I started the work about a month ago
> and not sure if the patch existed before. I will test the other series on my
> hardware. I like that approach more.

+1 to what Ilpo said. Please, make a joint effort with that patch series (test,
review, et cetera) to get it better.

-- 
With Best Regards,
Andy Shevchenko