Re: [PATCH 3/4] serial: 8250: map UAPI port type to internal enum

[Andy Shevchenko]

On Thu, Jul 09, 2026 at 11:46:02PM +0200, Christian Marangi wrote:
> On Fri, Jul 10, 2026 at 12:37:48AM +0300, Andy Shevchenko wrote:
> > On Thu, Jul 09, 2026 at 10:56:51PM +0200, Christian Marangi wrote:
> > > There is currently some confusion when a new 8250 UART device needs to be
> > > defined with the related index for uart_config[] to be directly defined in
> > > UAPI header.
> > > 
> > > There isn't any specific reason to define the index directly in UAPI header
> > > unless it's also needed to be defined for userspace usage.
> > > 
> > > To try to address this confusion and making it clear how these specific
> > > index should be defined and where, create a dedicated enum in 8250.h
> > > with all the current defined values in UAPI header and document how these
> > > id should be defined.
> > > 
> > > Rename the define in 8250_port.c with the new UART_ prefix.
> > 
> > This will bring a wide field for the all possible conflicts and doesn't really
> > solve the issue. Why not simply kill the UAPI part of the definitions for good?
> > (Move the all, except the first 13) to be internal to the kernel.
> 
> I mean... With correct review from maintainers, conflict won't happen. I don't
> feel it's that easy to kill UAPI header... userspace stuff and we don't
> kill userspace.
> 
> The previous suggested solution was to stop declaring stuff in UAPI header
> and start declaring in the internal header making the situation even worse
> and error prone with id conflict. This can really be prevent only by
> correct review of the change. (or keep using UAPI)
> 
> Maybe other have better ideas on this. On net we have a similar problem and
> the implementation is mostly similar with duplicated reference and some
> BUILD_BUG magic.

The whole point of UAPI list of the supported types of the ports is busted from
the very first case when we start re-using gaps. Meaning that if there is any
current userspace software that relies on that information, it's already in a mess
state. There is a Debian source code browser, you can check how many programs
use that list for something real (behind the assigning types to the unknown ports).
I believe none. And the assigning unknown port should not be considered valuable
these days as we expect to have kernel drivers for most of the modern HW.
That's why I just recommend to find a great common denominator and leave only
those (and I think this split is exactly between the files in UAPI) in UAPI
and hide the rest completely from the user space. Yes, big change on paper,
but with 99.99% probability no functional change at all at the end of the day.

Submit and RFC patch.


-- 
With Best Regards,
Andy Shevchenko