On Tue, Jun 11, 2024 at 12:56:54PM +0300, Tony Lindgren wrote: > On Tue, Jun 11, 2024 at 10:17:11AM +0200, Petr Mladek wrote: > > On Thu 2024-06-06 14:41:46, Tony Lindgren wrote: ... > > So, the DEVNAME:X.Y to ttySZ mapping is: > > > > 00:00:0.0 -> ttyS0 > > serial8250:0.1 -> ttyS1 > > serial8250:0.2 -> ttyS2 > > serial8250:0.3 -> ttyS3 > > [...] > > serial8250:0.30 -> ttyS30 > > serial8250:0.31 -> ttyS31 > > > > Why is ttyS0 associated with "so ugly" DEVNAME "00:00" > > while the rest uses "nice" DEVNAME "serial8250"? > > Because ACPI serial driver takes over the serial8250 port. Yes we are > recycling the preallocated serial8250 ports for the hardware specific > drivers.. That always adds some extra confusion on the top :) FWIW, 00:00 type of DEVNAME is originating from PNP subsystem (drivers/pnp). > > I would expect: > > > > serial8250:0.0 -> ttyS0 > > serial8250:0.1 -> ttyS1 > > serial8250:0.2 -> ttyS2 > > [...] > > I believe this would be the situation if you make CONFIG_ACPI is not set > in the .config. This is interesting. So, we still have the DEVNAME differences depending on the kernel configuration? OTOH, I can't imagine either how we can get the device names more stable as long as some drivers instantiate the platform device instead of using 8250 core parts (port, base, core) directly. ... > > If the users defines a non-existing console=SBASE_DEVNAME:X.Y then > > c->name and c->index will never be set. But it is OK. It will be > > the same as when user defines a non-existing console=blabla > > on the command line. > > OK. I think we should keep it as DEVNAME though as it should not be > limited to serial consoles. I agree, users know about DEVNAME, like developers know about strcpy(), there's no specific need for new name. -- With Best Regards, Andy Shevchenko
