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>
Subject: Re: [PATCH v3] PCI: dw-rockchip: Enable async probe by default
Date: Thu, 12 Mar 2026 13:59:52 +0100 [thread overview]
Message-ID: <DH0TM60TVX5D.20W4O1X696ALA@kernel.org> (raw)
In-Reply-To: <55c28218-1638-4b90-a9cd-a177fb5abcb6@arm.com>
On Thu Mar 12, 2026 at 1:48 PM CET, Robin Murphy wrote:
> On 2026-03-11 9:09 pm, Danilo Krummrich wrote:
>> From a driver-core perspective I think we're rather limited on what we can do;
>> we are already in async context at this point and can't magically go back to
>> initcall context.
>>
>> So, the only thing I can think of is to kick off work on a workqueue, which in
>> the end would be the same as the deferred probe handling.
>
> Hmm, in fact, isn't the deferred probe mechanism itself actually quite
> appropriate?
Yes, I've also mentioned this in [1], including the fact that it technically
even complies with the guarantees given by PROBE_FORCE_SYNCHRONOUS. I.e. the
documentation says:
Use this to annotate drivers that need their probe routines to run
synchronously with driver and device registration (with the exception of
-EPROBE_DEFER handling - re-probing always ends up being done
asynchronously).
However, I'm still not sure how I feel about this, since I consider this to be
more like a workaround that just moves things to a "more approprite" async
context.
On the other hand, eventually we want everything to work with
PROBE_PREFER_ASYNCHRONOUS, so maybe it's also good enough for the time being.
[1] https://lore.kernel.org/driver-core/DGZJBMG2Y738.2MU5LXVGEDD47@kernel.org/
next prev parent reply other threads:[~2026-03-12 12:59 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
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 [this message]
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=DH0TM60TVX5D.20W4O1X696ALA@kernel.org \
--to=dakr@kernel.org \
--cc=18255117159@163.com \
--cc=bhelgaas@google.com \
--cc=cassel@kernel.org \
--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