Re: [PATCH v3] PCI: dw-rockchip: Enable async probe by default

From: Niklas Cassel <cassel@kernel.org>
To: Danilo Krummrich <dakr@kernel.org>
Cc: "Manivannan Sadhasivam" <mani@kernel.org>,
	"Robin Murphy" <robin.murphy@arm.com>,
	"Manivannan Sadhasivam" <manivannan.sadhasivam@oss.qualcomm.com>,
	"Lorenzo Pieralisi" <lpieralisi@kernel.org>,
	"Krzysztof Wilczyński" <kwilczynski@kernel.org>,
	"Rob Herring" <robh@kernel.org>,
	"Bjorn Helgaas" <bhelgaas@google.com>,
	"Heiko Stuebner" <heiko@sntech.de>,
	"Shawn Lin" <shawn.lin@rock-chips.com>,
	"Hans Zhang" <18255117159@163.com>,
	"Nicolas Frattaroli" <nicolas.frattaroli@collabora.com>,
	"Wilfred Mallawa" <wilfred.mallawa@wdc.com>,
	linux-pci@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
	linux-rockchip@lists.infradead.org, linux-kernel@vger.kernel.org,
	"Anand Moon" <linux.amoon@gmail.com>,
	Grimmauld <grimmauld@grimmauld.de>,
	"Greg Kroah-Hartman" <gregkh@linuxfoundation.org>,
	"Rafael J. Wysocki" <rafael@kernel.org>,
	driver-core@lists.linux.dev, "Lukas Wunner" <lukas@wunner.de>
Subject: Re: [PATCH v3] PCI: dw-rockchip: Enable async probe by default
Date: Wed, 11 Mar 2026 13:13:34 +0100	[thread overview]
Message-ID: <abFcbmkb9p0hx3NR@fedora> (raw)
In-Reply-To: <DGZXF3LPSRK6.2QYN63QTKUQAX@kernel.org>

On Wed, Mar 11, 2026 at 12:46:03PM +0100, Danilo Krummrich wrote:
> On Wed Mar 11, 2026 at 6:24 AM CET, Manivannan Sadhasivam wrote:
> > I have a contrary view here. If just a single driver or lib doesn't handle async
> > probe, it cannot just force other drivers to not take the advantage of async
> > probe. As I said above, enabling async probe easily saves a few hunderd ms or
> > even more if there are more than one Root Port or Root Complex in an SoC.
> 
> Then the driver or lib has to be fixed / improved first or the driver core has
> to be enabled to deal with a case where PROBE_FORCE_SYNCHRONOUS is requested
> from an async path, etc.
> 
> In any case, applying the patch and breaking things (knowingly?) doesn't seem
> like the correct approach.
> 
> > I strongly agree with you here that the underlying issue should be fixed. But
> > the real impact to end users is not this splat, but not having the boot time
> > optimization that this patch brings in. As an end user, one would want their
> > systems to boot quickly and they wouldn't bother much about a harmless warning
> > splat appearing in the dmesg log.
> 
> You mean quickly booting into a "harmless" potential deadlock condition the
> warning splat tries to make people aware of? :)
> 
> (Or am I missing a subtle detail and we can never actually end up in a deadlock
> for some reason?)

Right now it will print a warning even when trying to load a PHY driver that
is already loaded (e.g. if the PHY driver is built as built-in):
https://github.com/torvalds/linux/blob/v7.0-rc3/drivers/net/phy/phy_device.c#L806-L815

If the PHY driver is built as a module, then I assume that the deadlock
warning is legit.

Kind regards,
Niklas