Re: [PATCH tty v3 1/6] serial: core: Add dedicated uart_port field for console flow

[John Ogness]

On 2026-04-17, Sashiko wrote:
>> diff --git a/include/linux/serial_core.h b/include/linux/serial_core.h
>> index 666430b478997..2327a364ded16 100644
>> --- a/include/linux/serial_core.h
>> +++ b/include/linux/serial_core.h
>> @@ -567,6 +568,7 @@ struct uart_port {
>>  #define UPSTAT_SYNC_FIFO	((__force upstat_t) (1 << 5))
>>  
>>  	bool			hw_stopped;		/* sw-assisted CTS flow state */
>> +	bool			cons_flow;		/* user specified console flow control */
>>  	unsigned int		mctrl;			/* current modem ctrl settings */
>>  	unsigned int		frame_time;		/* frame timing in ns */
>>  	unsigned int		type;			/* port type */
>
> Since cons_flow is now separate from the flags field, do manual
> assignments of struct uart_port need to be updated to copy this new
> field?

My goal was to catch everywhere where uart_port.flags is set explicitly
or from some "external" source. I did not want to filter anytime one
uart_port.flags is to another uart_port.flags. If UPF_CONS_FLOW is set
in the source uart_port.flags, then _that_ is the problem.

> While subsequent patches in this series update
> serial8250_register_8250_port() to explicitly copy this new field,
> early_serial_setup() does not appear to receive a similar update.
>
> For example, looking at early_serial_setup() in
> drivers/tty/serial/8250/8250_core.c:
>
> int __init early_serial_setup(struct uart_port *port)
> {
> 	...
> 	p = &serial8250_ports[port->line].port;
> 	p->iobase       = port->iobase;
> 	...
> 	p->iotype       = port->iotype;
> 	p->flags        = port->flags;
> 	p->mapbase      = port->mapbase;
> 	...
> }
>
> Because UPF_CONS_FLOW was previously copied as part of port->flags,
> will omitting cons_flow here cause a regression where the
> configuration is silently lost if any platform sets console flow
> control prior to early registration?

In this particular case, I checked all callers of
early_serial_setup(). They are passing explicit flags and UPF_CONS_FLOW
is not one of them.

Likewise, I could not find any examples, where UPF_CONS_FLOW could slip
into uart_port.flags, aside from the 2 examples I found and deal with in
my series.

I have no control over out-of-tree drivers that call
early_serial_setup() with UPF_CONS_FLOW. I could sprinkle bitmasks and
WARN_ON's to try to catch such out-of-tree misfits. But honestly, I
think that would introduce unnecesary code churn and complexity.

Considering the current questionable kernel state of console flow
control today, I doubt any out-of-tree drivers are really using the
appropriate policies anyway... meaning that the out-of-tree driver is
probably just unsafely using (uart_port.flags & UPF_CONS_FLOW) now,
which would likely continue to work as good/bad as it does now.

John

P.S. It looks like Sashiko ran out of gas [0] trying to review the 2nd
patch. So hopefully another reviewer (human or !human) will find some
time to take a look at the series.

At this point my only real concern is the community opinions on
deprecating UPF_CONS_FLOW.

[0] https://sashiko.dev/#/patchset/20260417102423.40984-1-john.ogness%40linutronix.de