From: sashiko-bot@kernel.org
To: "Jacky Chou" <jacky_chou@aspeedtech.com>
Cc: linux-pci@vger.kernel.org
Subject: Re: [PATCH] PCI: aspeed: Drop PROBE_PREFER_ASYNCHRONOUS to fix enumeration race
Date: Mon, 09 Nov 2026 12:13:27 +0000 [thread overview]
Message-ID: <sashiko-outbox-204918@kernel.org> (raw)
In-Reply-To: <20261109-aspeed-pcie-sync-probe-v1-1-71cc9e718623@aspeedtech.com>
Thank you for your contribution! Sashiko AI review found 1 potential
issue to consider:
- [Medium] PCI: aspeed: dropping PROBE_PREFER_ASYNCHRONOUS does not fix
EP probe order
--
commit 0a5273357bc4c6f662270192044fe2acfee34187
Author: Jacky Chou <jacky_chou@aspeedtech.com>
PCI: aspeed: Drop PROBE_PREFER_ASYNCHRONOUS to fix enumeration race
This commit removes PROBE_PREFER_ASYNCHRONOUS from aspeed_pcie_driver so
that the ASPEED PCIe Root Complex driver probes synchronously.
> diff --git a/drivers/pci/controller/pcie-aspeed.c b/drivers/pci/controller/pcie-aspeed.c
> index ecb7562f84c01..def5591010cac 100644
> --- a/drivers/pci/controller/pcie-aspeed.c
> +++ b/drivers/pci/controller/pcie-aspeed.c
> @@ -1104,7 +1104,6 @@ static struct platform_driver aspeed_pcie_driver = {
> .name = "aspeed-pcie",
> .of_match_table = aspeed_pcie_of_match,
> .suppress_bind_attrs = true,
> - .probe_type = PROBE_PREFER_ASYNCHRONOUS,
> },
> .probe = aspeed_pcie_probe,
> };
[Severity: Medium]
Does dropping PROBE_PREFER_ASYNCHRONOUS from aspeed_pcie_driver actually
solve the endpoint probe ordering problem described in the commit message?
Registering a struct pci_driver before the bus is enumerated succeeds and
adds the driver to pci_bus_type; its probe() callback does not run until
aspeed_pcie_probe() finishes enumeration and pci_bus_add_device() calls
device_initial_probe(&dev->dev), which binds any already-registered
pci_driver even when aspeed_pcie_probe() runs on an async worker.
If a consumer instead looks up a pci_dev directly from an initcall or an
on-board endpoint requires another driver to run before bus enumeration,
removing PROBE_PREFER_ASYNCHRONOUS still does not guarantee that
aspeed_pcie_probe() runs before late_initcall: aspeed_pcie_driver is
registered at device_initcall via builtin_platform_driver(), and
aspeed_pcie_probe() acquires resets, clocks, and PHYs (h2xrst, port->clk,
port->phy, port->perst) that can defer probing via -EPROBE_DEFER or
fw_devlink until deferred_probe_initcall() at late_initcall.
Meanwhile, forcing synchronous probing serializes the 10 ms mdelay() in
aspeed_host_reset() and the 100 ms msleep() per port in
aspeed_pcie_port_init() on the main boot thread across all RC instances.
--
Sashiko AI review · https://sashiko.dev/#/patchset/20261109-aspeed-pcie-sync-probe-v1-1-71cc9e718623@aspeedtech.com?part=1
prev parent reply other threads:[~2026-11-09 12:13 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-09 11:57 [PATCH] PCI: aspeed: Drop PROBE_PREFER_ASYNCHRONOUS to fix enumeration race Jacky Chou
2026-11-09 12:13 ` sashiko-bot [this message]
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=sashiko-outbox-204918@kernel.org \
--to=sashiko-bot@kernel.org \
--cc=jacky_chou@aspeedtech.com \
--cc=linux-pci@vger.kernel.org \
--cc=sashiko-reviews@lists.linux.dev \
/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