From: Robin Murphy <robin.murphy@arm.com>
To: Manivannan Sadhasivam <mani@kernel.org>,
Bjorn Helgaas <helgaas@kernel.org>
Cc: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>,
Bjorn Helgaas <bhelgaas@google.com>,
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>,
Jason Gunthorpe <jgg@ziepe.ca>
Subject: Re: [PATCH v3 1/4] PCI: Enable ACS only after configuring IOMMU for OF platforms
Date: Fri, 6 Feb 2026 15:37:38 +0000 [thread overview]
Message-ID: <3e1da927-d0ed-4f2f-8856-8b9605097cfa@arm.com> (raw)
In-Reply-To: <p6wq2kakzc53fdf47nmezlp2dccimblhc2ssb5hayll3epe7oe@jlgmjqyffkp4>
On 2026-02-06 9:18 am, Manivannan Sadhasivam wrote:
> On Wed, Feb 04, 2026 at 05:33:30PM -0600, Bjorn Helgaas wrote:
>> On Fri, Jan 02, 2026 at 09:04:47PM +0530, Manivannan Sadhasivam wrote:
>>> 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.
>>
>> I don't think cmdline params are relevant, since I don't see any that
>> set pci_acs_enable or call pci_request_acs().
>>
>> I propose a longer but combined call chain in the commit log to show
>> the old sequence vs the new one. I do notice the double call of
>> pci_enable_acs() (along with dev->bus->dma_configure()), which all
>> looks odd, but maybe it will be rationalized someday:
>>
>
> Yeah, there is no issue with calling pci_enable_acs() twice as of now, but I
> don't have a better solution either.
Indeed the second one is due to go away - the current state of running
all of bus->dma_configure twice is the precursor to splitting it up so
the iommu_configure() bits run at device_add() time (or the equivalent
if the IOMMU registers later), while the rest of the dma_configure()
bits (including deferral if we're still waiting for an IOMMU driver)
stay at driver bind. The snag is that there are some dodgy platform
drivers abusing the previous behaviour that I'm not sure what to do with.
However I suppose with some careful refactoring it shouldn't strictly be
necessary to change everything all at once, so if and when I get the
chance to pick that project up again I could potentially finish the new
design for PCI and other buses while kicking platform down the road...
Thanks,
Robin.
>> PCI: Enable ACS after configuring IOMMU for OF platforms
>>
>> Platform, ACPI, or IOMMU drivers call pci_request_acs(), which sets
>> 'pci_acs_enable' to request that ACS be enabled for any devices enumerated
>> in the future.
>>
>> OF platforms called pci_enable_acs() for the first device before
>> of_iommu_configure() called pci_request_acs(), so ACS was never enabled for
>> that device (typically a Root Port).
>>
>> Call pci_enable_acs() later, from pci_dma_configure(), after
>> of_dma_configure() has had a chance to call pci_request_acs().
>>
>> Here's the call path, showing the move of pci_enable_acs() from
>> pci_acs_init() to pci_dma_configure(), where it always happens after
>> pci_request_acs():
>>
>> pci_device_add
>> pci_init_capabilities
>> pci_acs_init
>> - pci_enable_acs
>> - if (pci_acs_enable) <-- previous test
>> - ...
>> device_add
>> bus_notify(BUS_NOTIFY_ADD_DEVICE)
>> iommu_bus_notifier
>> iommu_probe_device
>> iommu_init_device
>> dev->bus->dma_configure
>> pci_dma_configure # pci_bus_type.dma_configure
>> of_dma_configure
>> of_iommu_configure
>> pci_request_acs
>> pci_acs_enable = 1 <-- set
>> + pci_enable_acs
>> + if (pci_acs_enable) <-- new test
>> + ...
>> bus_probe_device
>> device_initial_probe
>> ...
>> really_probe
>> dev->bus->dma_configure
>> pci_dma_configure # pci_bus_type.dma_configure
>> ...
>> pci_enable_acs
>>
>> Note that we will now call pci_enable_acs() twice for every device, first
>> from the iommu_probe_device() path and again from the really_probe() path.
>> Presumably that's not an issue since we also call dev->bus->dma_configure()
>> twice.
>>
>> For the ACPI platforms, pci_request_acs() is called during ACPI
>> initialization time itself, independent of the IOMMU framework.
>>
>
> Thanks! Let me know if I need to respin or you want to ammend it while applying.
> (It is not clear to me what is your plan here).
>
> - Mani
>
next prev parent reply other threads:[~2026-02-06 15:37 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-01-02 15:34 [PATCH v3 0/4] PCI: Fix ACS enablement for Root Ports in " Manivannan Sadhasivam via B4 Relay
2026-01-02 15:34 ` [PATCH v3 1/4] PCI: Enable ACS only after configuring IOMMU for " Manivannan Sadhasivam via B4 Relay
2026-02-04 23:33 ` Bjorn Helgaas
2026-02-06 9:18 ` Manivannan Sadhasivam
2026-02-06 15:37 ` Robin Murphy [this message]
2026-04-03 16:45 ` Regression " Jon Kohler
2026-04-03 16:52 ` Manivannan Sadhasivam
2026-04-03 16:47 ` Jon Kohler
2026-01-02 15:34 ` [PATCH v3 2/4] PCI: Cache ACS capabilities Manivannan Sadhasivam via B4 Relay
2026-01-02 15:34 ` [PATCH v3 3/4] PCI: Disable ACS SV capability for the broken IDT switches Manivannan Sadhasivam via B4 Relay
2026-02-05 23:39 ` Bjorn Helgaas
2026-02-06 9:11 ` Manivannan Sadhasivam
2026-02-06 14:30 ` Jason Gunthorpe
2026-02-06 14:43 ` Robin Murphy
2026-02-06 14:46 ` Bjorn Helgaas
2026-02-06 14:52 ` Jason Gunthorpe
2026-02-06 15:05 ` Bjorn Helgaas
2026-02-06 15:07 ` Jason Gunthorpe
2026-01-02 15:34 ` [PATCH v3 4/4] PCI: Extend the pci_disable_broken_acs_cap() quirk for one more IDT switch Manivannan Sadhasivam via B4 Relay
2026-01-29 17:42 ` [PATCH v3 0/4] PCI: Fix ACS enablement for Root Ports in OF platforms Manivannan Sadhasivam
2026-01-29 18:06 ` Jason Gunthorpe
2026-02-06 18:32 ` Bjorn Helgaas
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=3e1da927-d0ed-4f2f-8856-8b9605097cfa@arm.com \
--to=robin.murphy@arm.com \
--cc=bhelgaas@google.com \
--cc=helgaas@kernel.org \
--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=manivannan.sadhasivam@oss.qualcomm.com \
--cc=naresh.kamboju@linaro.org \
--cc=quic_pkondeti@quicinc.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®