From: Chen Pei <cp0613@linux.alibaba.com>
To: dave.jiang@intel.com
Cc: alison.schofield@intel.com, cp0613@linux.alibaba.com,
dave@stgolabs.net, djbw@kernel.org, guoren@kernel.org,
ira.weiny@intel.com, jic23@kernel.org, linux-cxl@vger.kernel.org,
linux-kernel@vger.kernel.org, vishal.l.verma@intel.com
Subject: Re: [PATCH] cxl/acpi: Defer probe when ACPI0016 PCI root bridge is not ready
Date: Tue, 19 May 2026 09:50:09 +0800 [thread overview]
Message-ID: <20260519015009.3430-1-cp0613@linux.alibaba.com> (raw)
In-Reply-To: <4ad8feae-6fc7-4e9d-8509-c9cc365d1c53@intel.com>
On Fri, 15 May 2026 08:38:01 -0700, Dave Jiang wrote:
> I would leave the assignment of 'hb' as is above and just what's below
> after looking at to_cxl_host_bridge() function.
>
> if (!hb) {
> if (!acpi_pci_find_root(adev->handle)) {
> ...
> return -EPROBE_DEFER;
> }
> return 0;
> }
Hi Dave,
Thanks for the review and the code structure suggestion. I agree that
nesting the check under `if (!hb)` is cleaner.
> I am concerned of other failure cases that causes acpi_pci_find_root()
> to fail beyond the driver not being attached. Will cxl_acpi probe() be
> stuck permanently in the defer probe queue when that happens? This is
> also something that Sashiko raised. Is there no way to adjust the
> RISCV ACPI setup to go around subsys_initcall()? That would be
> preferred solution.
You raise a valid concern. The EPROBE_DEFER approach indeed risks
infinite deferral if acpi_pci_find_root() fails for reasons other
than the driver not being attached yet. This is a fundamental
limitation of this approach.
After considering the feedback from you, Sashiko, and Dan Williams,
I plan to abandon the EPROBE_DEFER approach and instead use the
ACPI _DEP mechanism as Dan suggested. This is the proper ACPI
standard way to declare device dependencies:
1. Firmware side (DSDT): Add a _DEP package to the ACPI0017 device
pointing to all ACPI0016 host bridges it depends on.
2. Kernel side: Add acpi_dev_clear_dependencies() in acpi_pci_root_add()
so that ACPI0017 will naturally wait for all ACPI0016 devices to
be ready before probing.
This eliminates the permanent defer risk since the dependency is
explicitly declared by firmware and resolved by the ACPI core,
rather than relying on runtime probing heuristics.
I'll send a new patch series for this approach.
Thanks,
Pei
prev parent reply other threads:[~2026-05-19 1:50 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-14 2:32 [PATCH] cxl/acpi: Defer probe when ACPI0016 PCI root bridge is not ready Chen Pei
2026-05-14 7:31 ` Richard Cheng
2026-05-15 13:46 ` Chen Pei
2026-05-15 19:24 ` Dan Williams (nvidia)
2026-05-19 1:55 ` Chen Pei
2026-05-21 17:13 ` Dave Jiang
2026-05-14 17:10 ` Dave Jiang
2026-05-15 13:53 ` Chen Pei
2026-05-14 17:19 ` Alison Schofield
2026-05-15 13:56 ` Chen Pei
2026-05-15 15:38 ` Dave Jiang
2026-05-19 1:50 ` Chen Pei [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=20260519015009.3430-1-cp0613@linux.alibaba.com \
--to=cp0613@linux.alibaba.com \
--cc=alison.schofield@intel.com \
--cc=dave.jiang@intel.com \
--cc=dave@stgolabs.net \
--cc=djbw@kernel.org \
--cc=guoren@kernel.org \
--cc=ira.weiny@intel.com \
--cc=jic23@kernel.org \
--cc=linux-cxl@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=vishal.l.verma@intel.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