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>
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/

  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