Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Sender: Guenter Roeck <groeck7@gmail.com>
Message-ID: <a6973497-f45f-6456-ac2b-d3c0262d892b@roeck-us.net>
Date:   Sat, 5 Aug 2023 03:50:28 -0700
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.13.0
Content-Language: en-US
To:     Tony Lindgren <tony@atomide.com>
Cc:     Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
        Jiri Slaby <jirislaby@kernel.org>,
        Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
        Andy Shevchenko <andriy.shevchenko@intel.com>,
        Dhruva Gole <d-gole@ti.com>,
        =?UTF-8?Q?Ilpo_J=c3=a4rvinen?= <ilpo.jarvinen@linux.intel.com>,
        John Ogness <john.ogness@linutronix.de>,
        Johan Hovold <johan@kernel.org>,
        Sebastian Andrzej Siewior <bigeasy@linutronix.de>,
        Vignesh Raghavendra <vigneshr@ti.com>,
        linux-kernel@vger.kernel.org, linux-serial@vger.kernel.org,
        kernel test robot <oliver.sang@intel.com>
References: <20230803071034.25571-1-tony@atomide.com>
 <0e1bc27d-dc84-473d-bfdf-db0743c5d64a@roeck-us.net>
 <20230805044910.GJ14799@atomide.com>
From:   Guenter Roeck <linux@roeck-us.net>
Subject: Re: [PATCH v2 1/1] serial: core: Fix serial_base_match() after fixing
 controller port name
In-Reply-To: <20230805044910.GJ14799@atomide.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk

On 8/4/23 21:49, Tony Lindgren wrote:
> * Guenter Roeck <linux@roeck-us.net> [230804 21:42]:
>> On Thu, Aug 03, 2023 at 10:10:32AM +0300, Tony Lindgren wrote:
>>> While fixing DEVNAME to be more usable, I broke serial_base_match() as the
>>> ctrl and port prefix for device names seemed unnecessary.
>>>
>>> The prefixes are still needed by serial_base_match() to probe the serial
>>> base controller port, and serial tx is now broken.
>>>
>>> Let's fix the issue by checking against dev->type and drv->name instead
>>> of the prefixes that are no longer in the DEVNAME.
>>>
>>> Fixes: 1ef2c2df1199 ("serial: core: Fix serial core controller port name to show controller id")
>>> Reported-by: kernel test robot <oliver.sang@intel.com>
>>> Closes: https://lore.kernel.org/oe-lkp/202308021529.35b3ad6c-oliver.sang@intel.com
>>> Signed-off-by: Tony Lindgren <tony@atomide.com>
>>
>> With this patch applied, I see the following traceback in the pending-fixes
>> branch.
>>
>> Bisect log attached as well. It actually points to commit d962de6ae51f
>> ("serial: core: Fix serial core port id to not use port->line").
>> Bisect was on mips, but I also see problems on arm, ppc, and sparc.
>> sparc boot tests show the warning message and then stall until aborted
>> (which of course may be a different problem).
> 
> Sorry about all the hassles and thanks for testing again.
> 
> I too noticed several issues remaining after testing reloading the hardware
> specific serial driver, the issues I saw should be fixed in tty-linus.
> 
>> 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.

Guenter