public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: "Danilo Krummrich" <dakr@kernel.org>
To: "Robin Murphy" <robin.murphy@arm.com>
Cc: "Manivannan Sadhasivam" <mani@kernel.org>,
	"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>,
	"Niklas Cassel" <cassel@kernel.org>,
	"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>,
	"Dmitry Torokhov" <dmitry.torokhov@gmail.com>
Subject: Re: [PATCH v3] PCI: dw-rockchip: Enable async probe by default
Date: Wed, 11 Mar 2026 01:43:15 +0100	[thread overview]
Message-ID: <DGZJBMG2Y738.2MU5LXVGEDD47@kernel.org> (raw)
In-Reply-To: <5d88fb5b-e771-4ea6-8d2c-c5cfd21e5860@arm.com>

(Cc: Dmitry)

On Tue Mar 10, 2026 at 10:03 PM CET, Robin Murphy wrote:
> [ +driver-core maintainers - async probe question below ]

<snip>

> I'm guessing it maybe wasn't anticipated to have bus drivers calling
> device_initial_probe() from within async in the first place?

I think this is not limited to device_initial_probe(), device_attach() or even
device_add() would have the same problem. I.e. the driver core simply does not
consider whether it is already running in an async handler when it is requested
to run probe() synchronously.

A simple workaround to this would be to check whether current_is_async() and in
case it returns true just defer probing in an PROBE_FORCE_SYNCHRONOUS case. This
would at least be compatible with the guarantees given by
PROBE_FORCE_SYNCHRONOUS, but it doesn't sound quite right to me -- guess I have
to think about it a bit more.

In any case, given that this is not a supported case, this commit seems to be
wrong and should probably be reverted.

I think a quick workaround in the driver core as mentioned above is not a good
idea, instead this should be properly thought through.

> It may not strictly be the fault of this patch - clearly 91703041697c 
> ("PCI: Allow built-in drivers to use async initial probing") is 
> implicated in this too - but the fact is that it *has* exposed a bug 
> that needs fixing one way or another, it can't just be left hanging and 
> impacting end users.

At a side note, I think device_initial_probe() was not meant to be exposed
outside of the driver core in the first place. As the name suggests it is only
meant to be called on the initial probe() path (i.e. the initial probe() path of
the driver core). It seems to me that it ended up in include/linux/device.h
instead of drivers/base/base.h by accident.

The original commit - commit 765230b5f084 ("driver-core: add asynchronous
probing support for drivers") - introducing the feature even mentions "manual
binding is still synchronous" in its commit message and I think this has never
been changed.

So, it seems commit 91703041697c ("PCI: Allow built-in drivers to use async
initial probing") relies on something that might work by accident. :)

So, I wouldn't rule out any unexpected side effects entirely.

  reply	other threads:[~2026-03-11  0:43 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-02-26 10:10 [PATCH v3] PCI: dw-rockchip: Enable async probe by default Anand Moon
2026-02-26 12:06 ` Niklas Cassel
2026-03-02 15:59 ` Hans Zhang
2026-03-03  1:01 ` Shawn Lin
2026-03-04  6:48 ` Manivannan Sadhasivam
2026-03-10 13:41   ` Robin Murphy
2026-03-10 15:30     ` Manivannan Sadhasivam
2026-03-10 21:03       ` Robin Murphy
2026-03-11  0:43         ` Danilo Krummrich [this message]
2026-03-25  3:44           ` Dmitry Torokhov
2026-03-25  6:36             ` Lukas Wunner
2026-03-11  5:24         ` Manivannan Sadhasivam
2026-03-11  7:56           ` Lukas Wunner
2026-03-11 11:46           ` Danilo Krummrich
2026-03-11 12:13             ` Niklas Cassel
2026-03-11 12:28             ` Manivannan Sadhasivam
2026-03-11 21:09               ` Danilo Krummrich
2026-03-12  1:33                 ` Shawn Lin
2026-03-12 11:40                   ` Anand Moon
2026-03-12 11:54                     ` Danilo Krummrich
2026-03-13  9:26                       ` Anand Moon
2026-03-12 12:48                 ` Robin Murphy
2026-03-12 12:59                   ` Danilo Krummrich
2026-03-13 13:15                     ` Robin Murphy
2026-03-13 14:39                       ` Danilo Krummrich
2026-03-13 17:36                         ` Robin Murphy
2026-03-14  5:12                           ` Anand Moon
2026-03-17  6:24                             ` Anand Moon
2026-03-13 14:05                     ` Manivannan Sadhasivam
2026-03-13  9:25                   ` Anand Moon
2026-03-25  4:13                   ` Dmitry Torokhov
2026-03-25 15:01                     ` Robin Murphy
2026-03-25 15:23                       ` Dmitry Torokhov
2026-03-25 15:13                     ` Danilo Krummrich
2026-03-25 15:26                       ` Dmitry Torokhov
2026-03-25 18:24                         ` Anand Moon
2026-03-11 12:32   ` Manivannan Sadhasivam

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=DGZJBMG2Y738.2MU5LXVGEDD47@kernel.org \
    --to=dakr@kernel.org \
    --cc=18255117159@163.com \
    --cc=bhelgaas@google.com \
    --cc=cassel@kernel.org \
    --cc=dmitry.torokhov@gmail.com \
    --cc=driver-core@lists.linux.dev \
    --cc=gregkh@linuxfoundation.org \
    --cc=grimmauld@grimmauld.de \
    --cc=heiko@sntech.de \
    --cc=kwilczynski@kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=linux-rockchip@lists.infradead.org \
    --cc=linux.amoon@gmail.com \
    --cc=lpieralisi@kernel.org \
    --cc=lukas@wunner.de \
    --cc=mani@kernel.org \
    --cc=manivannan.sadhasivam@oss.qualcomm.com \
    --cc=nicolas.frattaroli@collabora.com \
    --cc=rafael@kernel.org \
    --cc=robh@kernel.org \
    --cc=robin.murphy@arm.com \
    --cc=shawn.lin@rock-chips.com \
    --cc=wilfred.mallawa@wdc.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox