Re: [PATCH v2 1/1] serial: core: Fix serial_base_match() after fixing controller port name

[Guenter Roeck <linux@roeck-us.net>]

On 8/5/23 08:50, Guenter Roeck wrote:
> On 8/5/23 04:48, Tony Lindgren wrote:
>> * Guenter Roeck <linux@roeck-us.net> [230805 10:50]:
>>> On 8/4/23 21:49, Tony Lindgren wrote:
>>>> * Guenter Roeck <linux@roeck-us.net> [230804 21:42]:
>>>>> kobject: kobject_add_internal failed for serial8250.0:0.0 with -EEXIST, don't try to register things with the same name in the same directory.
>>>>> serial8250 serial8250.0: unable to register port at index 1 (IO2f8 MEM0 IRQ3): -17
>>>>> sysfs: cannot create duplicate filename '/devices/platform/serial8250.0/serial8250.0:0/serial8250.0:0.0'
>>>>
>>>> The issue above should be fixed with commit:
>>>>
>>>> bbb4abb1bcfb ("serial: 8250: Reinit port_id when adding back serial8250_isa_devs")
>>>>
>>>
>>> No. I tested the tip of tty-linus (v6.5-rc4-9-gdfe2aeb226fd) which includes
>>> above commit, but still see the problem. sparc images also still stall after
>>> the "cannot create duplicate filename" message.
>>> I bisected the sparc problem - it also bisects to commit d962de6ae51f.
>>>
>>> The problem affects all mips boot tests, all sparc boot tests, as well as
>>> arm sx1, ppc bamboo and sam460ex emulations. As far as I can see, those
>>> call serial8250_register_8250_port() without calling  serial8250_setup_port()
>>> and thus don't set port_id. I am only testing a few of those, so I strongly
>>> suspect that all similar callers of serial8250_register_8250_port() are
>>> affected (i.e., almost all of them) if they register more than one serial port.
>>
>> OK thanks for explaining. So we need to initialize port->port_id for the
>> multi-port instances to avoid being stuck with the port->line index. I'll
>> take a look.
>>
>> I wonder if we should just revert d962de6ae51f for now. It needs to be
>> tested to see if something else also needs reverting though.
>>
> 
> It is actually more complicated like that. Adding some debug into, I get the following
> from a mips boot. Turns out that serial8250_setup_port() is actually called.
> 
> ...
> ####### serial8250_setup_port: index 0
> ####### serial8250_setup_port: index 0 returning 819a5ab8
> ####### serial8250_setup_port: index 1
> ####### serial8250_setup_port: index 1 returning 819a5d20
> ####### serial8250_setup_port: index 2
> ####### serial8250_setup_port: index 2 returning 819a5f88
> ####### serial8250_setup_port: index 3
> ####### serial8250_setup_port: index 3 returning 819a61f0
> ...
> #### serial8250_register_8250_port: uart=819a5ab8
> #### serial8250_register_8250_port: uart=819a5ab8 port_id=0 line=0
> ...
> #### serial8250_register_8250_port: uart=819a5d20
> #### serial8250_register_8250_port: uart=819a5d20 port_id=1 line=1
> sysfs: cannot create duplicate filename '/devices/platform/serial8250.0/serial8250.0:0/serial8250.0:0.0'
> 
> So line and port_id are both set, but the created sysfs attribute
> is still duplicate. I'll do some more debugging.
> 

Ok, it is actually quite simple. In serial8250_register_8250_port(),
uart->port.port_id has the correct and expected value. However, that is
overwritten with
	uart->port.port_id      = up->port.port_id;
where 'up' is the port pointer passed by the caller of serial8250_register_8250_port().
And 'port_id' is always 0 in _that_ port pointer (while 'line' is set correctly).

Guenter