Re: [PATCH] serial: core: Add sysfs links for serial core port instances for ttys

[Andy Shevchenko <andriy.shevchenko@intel.com>]

On Wed, Jul 19, 2023 at 08:43:21AM +0300, Tony Lindgren wrote:
> * Andy Shevchenko <andriy.shevchenko@intel.com> [230719 05:34]:
> > On Wed, Jul 19, 2023 at 08:16:11AM +0300, Tony Lindgren wrote:
> > > Let's allow the userspace to find out the tty name for a serial core
> > > controller id if a tty exists. This can be done with:
> > > 
> > > $ grep DEVNAME /sys/bus/serial-base/devices/port*/tty/uevent
> > > /sys/bus/serial-base/devices/port.00:04.0/tty/uevent:DEVNAME=ttyS0
> > > /sys/bus/serial-base/devices/port.serial8250.1/tty/uevent:DEVNAME=ttyS1
> > > /sys/bus/serial-base/devices/port.serial8250.2/tty/uevent:DEVNAME=ttyS2
> > > /sys/bus/serial-base/devices/port.serial8250.3/tty/uevent:DEVNAME=ttyS3
> > 
> > What part is the controller ID here?
> 
> Oh looks like controller id it's missing in the name, I'll send a fix
> for that.
> 
> > We also have something in procfs (I don't remember what info exactly is there).
> 
> Do you mean /proc/devices?

Something tty specific, /proc/tty/, but I had a look and it seems for another
stuff.

> > > And with this, we can add /dev/serial/by-id symlinks to the serial port
> > > device instances so we can start using serial core port addressing in
> > > addition to the legacy ttyS naming.
> > > 
> > > The naming we can use is dev_name:0.0 where 0.0 are the serial core
> > > controller id and port id, so for the ttyS0 example above the naming
> > > would be 00:04.0:0.0.
> > 
> > This is interesting idea. But any hint why it can be useful?
> 
> If you have lots of serial ports and we are stuck with adding aliases
> for the ports in the dts files where the ttyS naming and ordering does
> not really help or may not necessarily make sense if the ports are on
> different buses or domains. With CONFIG_SERIAL_8250_RUNTIME_UARTS=4,
> the ttyS naming is only needed for the legacy ports really.

I see. Does it fix the long standing issue with ttyS enumeration (on x86
at least) when depending on the presence of the legacy ports the HSUART
(high speed) can preempt the legacy placeholders (ttyS0..ttyS3)?

To me sounds like it may very well do fix it and I would be glad to see that
in the commit message (as selling point) and in documentation.

-- 
With Best Regards,
Andy Shevchenko