From: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
To: Bjorn Helgaas <bhelgaas@google.com>
Cc: linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org,
iommu@lists.linux.dev, Naresh Kamboju <naresh.kamboju@linaro.org>,
Pavankumar Kondeti <quic_pkondeti@quicinc.com>,
Xingang Wang <wangxingang5@huawei.com>,
Marek Szyprowski <m.szyprowski@samsung.com>,
Robin Murphy <robin.murphy@arm.com>,
Jason Gunthorpe <jgg@ziepe.ca>,
Manivannan Sadhasivam <mani@kernel.org>,
Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
Subject: [PATCH v2 1/4] PCI: Enable ACS only after configuring IOMMU for OF platforms
Date: Tue, 02 Dec 2025 19:52:48 +0530 [thread overview]
Message-ID: <20251202-pci_acs-v2-1-5d2759a71489@oss.qualcomm.com> (raw)
In-Reply-To: <20251202-pci_acs-v2-0-5d2759a71489@oss.qualcomm.com>
For enabling ACS without the cmdline params, the platform drivers are
expected to call pci_request_acs() API which sets a static flag,
'pci_acs_enable' in drivers/pci/pci.c. And this flag is used to enable ACS
in pci_enable_acs() helper, which gets called during pci_acs_init(), as per
this call stack:
-> pci_device_add()
-> pci_init_capabilities()
-> pci_acs_init()
/* check for pci_acs_enable */
-> pci_enable_acs()
For the OF platforms, pci_request_acs() is called during
of_iommu_configure() during device_add(), as per this call stack:
-> device_add()
-> iommu_bus_notifier()
-> iommu_probe_device()
-> pci_dma_configure()
-> of_dma_configure()
-> of_iommu_configure()
/* set pci_acs_enable */
-> pci_request_acs()
As seen from both call stacks, pci_enable_acs() is called way before the
invocation of pci_request_acs() for the OF platforms. This means,
pci_enable_acs() will not enable ACS for the first device that gets
enumerated, which is usally the Root Port device. But since the static
flag, 'pci_acs_enable' is set *afterwards*, ACS will be enabled for the
ACS capable devices enumerated later.
To fix this issue, do not call pci_enable_acs() from pci_acs_init(), but
only from pci_dma_configure() after calling of_dma_configure(). This makes
sure that pci_enable_acs() only gets called after the IOMMU framework has
called pci_request_acs(). The ACS enablement flow now looks like:
-> pci_device_add()
-> pci_init_capabilities()
/* Just store the ACS cap */
-> pci_acs_init()
-> device_add()
...
-> pci_dma_configure()
-> of_dma_configure()
-> pci_request_acs()
-> pci_enable_acs()
For the ACPI platforms, pci_request_acs() is called during ACPI
initialization time itself, independent of the IOMMU framework.
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
---
drivers/pci/pci-driver.c | 8 ++++++++
drivers/pci/pci.c | 8 --------
drivers/pci/pci.h | 1 +
3 files changed, 9 insertions(+), 8 deletions(-)
diff --git a/drivers/pci/pci-driver.c b/drivers/pci/pci-driver.c
index 302d61783f6c..a4ee93497a06 100644
--- a/drivers/pci/pci-driver.c
+++ b/drivers/pci/pci-driver.c
@@ -1648,6 +1648,14 @@ static int pci_dma_configure(struct device *dev)
ret = acpi_dma_configure(dev, acpi_get_dma_attr(adev));
}
+ /*
+ * Attempt to enable ACS regardless of capability because some Root
+ * Ports (e.g. those quirked with *_intel_pch_acs_*) do not have
+ * the standard ACS capability but still support ACS via those
+ * quirks.
+ */
+ pci_enable_acs(to_pci_dev(dev));
+
pci_put_host_bridge_device(bridge);
/* @drv may not be valid when we're called from the IOMMU layer */
diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index b14dd064006c..9f594fc6dade 100644
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -3677,14 +3677,6 @@ bool pci_acs_path_enabled(struct pci_dev *start,
void pci_acs_init(struct pci_dev *dev)
{
dev->acs_cap = pci_find_ext_capability(dev, PCI_EXT_CAP_ID_ACS);
-
- /*
- * Attempt to enable ACS regardless of capability because some Root
- * Ports (e.g. those quirked with *_intel_pch_acs_*) do not have
- * the standard ACS capability but still support ACS via those
- * quirks.
- */
- pci_enable_acs(dev);
}
void pci_rebar_init(struct pci_dev *pdev)
diff --git a/drivers/pci/pci.h b/drivers/pci/pci.h
index 36f8c0985430..972b28fc5455 100644
--- a/drivers/pci/pci.h
+++ b/drivers/pci/pci.h
@@ -917,6 +917,7 @@ static inline resource_size_t pci_resource_alignment(struct pci_dev *dev,
}
void pci_acs_init(struct pci_dev *dev);
+void pci_enable_acs(struct pci_dev *dev);
#ifdef CONFIG_PCI_QUIRKS
int pci_dev_specific_acs_enabled(struct pci_dev *dev, u16 acs_flags);
int pci_dev_specific_enable_acs(struct pci_dev *dev);
--
2.48.1
next prev parent reply other threads:[~2025-12-02 14:23 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CGME20251202142307eucas1p12a15e5656bb53f48f445c3056d4e3166@eucas1p1.samsung.com>
2025-12-02 14:22 ` [PATCH v2 0/4] PCI: Fix ACS enablement for Root Ports in " Manivannan Sadhasivam
2025-12-02 14:22 ` Manivannan Sadhasivam [this message]
2025-12-02 14:22 ` [PATCH v2 2/4] PCI: Cache ACS capabilities Manivannan Sadhasivam
2025-12-02 14:22 ` [PATCH v2 3/4] PCI: Disable ACS SV capability for the broken IDT switches Manivannan Sadhasivam
2025-12-02 19:15 ` Jason Gunthorpe
2025-12-09 11:20 ` Manivannan Sadhasivam
2025-12-17 15:19 ` Jason Gunthorpe
2025-12-02 14:22 ` [PATCH v2 4/4] PCI: Extend the pci_disable_acs_sv quirk for one more IDT switch Manivannan Sadhasivam
2025-12-03 8:46 ` [PATCH v2 0/4] PCI: Fix ACS enablement for Root Ports in OF platforms Naresh Kamboju
2025-12-03 12:04 ` Marek Szyprowski
2025-12-04 13:13 ` Marek Szyprowski
2025-12-09 7:31 ` Marek Szyprowski
2025-12-09 8:28 ` Marek Szyprowski
2025-12-09 11:15 ` Manivannan Sadhasivam
2025-12-09 12:00 ` Marek Szyprowski
2025-12-09 15:04 ` Manivannan Sadhasivam
2025-12-10 17:26 ` Marek Szyprowski
2025-12-12 4:02 ` Manivannan Sadhasivam
2025-12-12 7:25 ` Marek Szyprowski
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=20251202-pci_acs-v2-1-5d2759a71489@oss.qualcomm.com \
--to=manivannan.sadhasivam@oss.qualcomm.com \
--cc=bhelgaas@google.com \
--cc=iommu@lists.linux.dev \
--cc=jgg@ziepe.ca \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=m.szyprowski@samsung.com \
--cc=mani@kernel.org \
--cc=naresh.kamboju@linaro.org \
--cc=quic_pkondeti@quicinc.com \
--cc=robin.murphy@arm.com \
--cc=wangxingang5@huawei.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
all inboxes | Powered by JetHome®