From: "Danilo Krummrich" <dakr@kernel.org>
To: "Manivannan Sadhasivam" <mani@kernel.org>
Cc: "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>,
"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: Wed, 11 Mar 2026 12:46:03 +0100 [thread overview]
Message-ID: <DGZXF3LPSRK6.2QYN63QTKUQAX@kernel.org> (raw)
In-Reply-To: <qwanhqrpztzkudik5fmberhabnzaly7v53677dohqzj5nq4wi2@6ndpiubyxcbi>
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?)
next prev parent reply other threads:[~2026-03-11 11:46 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 [this message]
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=DGZXF3LPSRK6.2QYN63QTKUQAX@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