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/
WARNING: multiple messages have this Message-ID (diff)
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/
_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip
next prev parent reply other threads:[~2026-03-12 12:59 UTC|newest]
Thread overview: 73+ 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 10:10 ` Anand Moon
2026-02-26 12:06 ` Niklas Cassel
2026-02-26 12:06 ` Niklas Cassel
2026-03-02 15:59 ` Hans Zhang
2026-03-02 15:59 ` Hans Zhang
2026-03-03 1:01 ` Shawn Lin
2026-03-03 1:01 ` Shawn Lin
2026-03-04 6:48 ` Manivannan Sadhasivam
2026-03-04 6:48 ` Manivannan Sadhasivam
2026-03-10 13:41 ` Robin Murphy
2026-03-10 13:41 ` Robin Murphy
2026-03-10 15:30 ` Manivannan Sadhasivam
2026-03-10 15:30 ` Manivannan Sadhasivam
2026-03-10 21:03 ` Robin Murphy
2026-03-10 21:03 ` Robin Murphy
2026-03-11 0:43 ` Danilo Krummrich
2026-03-11 0:43 ` Danilo Krummrich
2026-03-25 3:44 ` Dmitry Torokhov
2026-03-25 3:44 ` Dmitry Torokhov
2026-03-25 6:36 ` Lukas Wunner
2026-03-25 6:36 ` Lukas Wunner
2026-03-11 5:24 ` Manivannan Sadhasivam
2026-03-11 5:24 ` Manivannan Sadhasivam
2026-03-11 7:56 ` Lukas Wunner
2026-03-11 11:46 ` Danilo Krummrich
2026-03-11 11:46 ` Danilo Krummrich
2026-03-11 12:13 ` Niklas Cassel
2026-03-11 12:13 ` Niklas Cassel
2026-03-11 12:28 ` Manivannan Sadhasivam
2026-03-11 12:28 ` Manivannan Sadhasivam
2026-03-11 21:09 ` Danilo Krummrich
2026-03-11 21:09 ` Danilo Krummrich
2026-03-12 1:33 ` Shawn Lin
2026-03-12 1:33 ` Shawn Lin
2026-03-12 11:40 ` Anand Moon
2026-03-12 11:40 ` Anand Moon
2026-03-12 11:54 ` Danilo Krummrich
2026-03-12 11:54 ` Danilo Krummrich
2026-03-13 9:26 ` Anand Moon
2026-03-13 9:26 ` Anand Moon
2026-03-12 12:48 ` Robin Murphy
2026-03-12 12:48 ` Robin Murphy
2026-03-12 12:59 ` Danilo Krummrich [this message]
2026-03-12 12:59 ` Danilo Krummrich
2026-03-13 13:15 ` Robin Murphy
2026-03-13 13:15 ` Robin Murphy
2026-03-13 14:39 ` Danilo Krummrich
2026-03-13 14:39 ` Danilo Krummrich
2026-03-13 17:36 ` Robin Murphy
2026-03-13 17:36 ` Robin Murphy
2026-03-14 5:12 ` Anand Moon
2026-03-14 5:12 ` Anand Moon
2026-03-17 6:24 ` Anand Moon
2026-03-17 6:24 ` Anand Moon
2026-03-13 14:05 ` Manivannan Sadhasivam
2026-03-13 14:05 ` Manivannan Sadhasivam
2026-03-13 9:25 ` Anand Moon
2026-03-13 9:25 ` Anand Moon
2026-03-25 4:13 ` Dmitry Torokhov
2026-03-25 4:13 ` Dmitry Torokhov
2026-03-25 15:01 ` Robin Murphy
2026-03-25 15:01 ` Robin Murphy
2026-03-25 15:23 ` Dmitry Torokhov
2026-03-25 15:23 ` Dmitry Torokhov
2026-03-25 15:13 ` Danilo Krummrich
2026-03-25 15:13 ` Danilo Krummrich
2026-03-25 15:26 ` Dmitry Torokhov
2026-03-25 15:26 ` Dmitry Torokhov
2026-03-25 18:24 ` Anand Moon
2026-03-25 18:24 ` Anand Moon
2026-03-11 12:32 ` Manivannan Sadhasivam
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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.