From: Nicolin Chen <nicolinc@nvidia.com>
To: Bjorn Helgaas <helgaas@kernel.org>
Cc: Danny Gonzalez <digonzal@google.com>,
Bjorn Helgaas <bhelgaas@google.com>,
David Decotigny <decot@google.com>,
Sheena Mohan <sheenamo@google.com>, <linux-pci@vger.kernel.org>,
<linux-kernel@vger.kernel.org>, Jason Gunthorpe <jgg@nvidia.com>,
Pranjal Shrivastava <praan@google.com>,
Joerg Roedel <joerg.roedel@amd.com>,
Lu Baolu <baolu.lu@linux.intel.com>,
Kevin Tian <kevin.tian@intel.com>
Subject: Re: [PATCH] PCI/ATS: Disable ATS when ACS TB is set upstream
Date: Thu, 5 Nov 2026 15:15:30 -0800 [thread overview]
Message-ID: <au0OEn8xLzsIhQIQ@nvidia.com> (raw)
In-Reply-To: <20261105230412.GA1450377@bhelgaas>
On Thu, Nov 05, 2026 at 05:04:12PM -0600, Bjorn Helgaas wrote:
> * pci_dev_reset_iommu_prepare() vs pci_dev_reset_iommu_done()
>
> Different values will make gdev->reset_depth, group->recovery_cnt,
> group->domain, and gdev->blocked get out of sync.
>
> I think it would be better if _iommu_prepare() and _iommu_done()
> themselves tracked what _iommu_done() needs to do, for example
> they could do something like this:
>
> int pci_dev_reset_iommu_prepare(struct pci_dev *pdev, bool *restore)
> {
> if (!pci_ats_supported(pdev) || !dev_has_iommu(&pdev->dev)) {
> *restore = false;
> return 0;
> }
>
> *restore = true;
> ...
> }
>
> Then pci_dev_reset_iommu_done() wouldn't need to call
> pci_ats_supported() or dev_has_iommu(), and users would look like
> this:
>
> int pcie_flr(...)
> {
> bool restore;
>
> ret = pci_dev_reset_iommu_prepare(dev, &restore);
> ...
> if (restore)
> pci_dev_reset_iommu_done(dev);
> }
>
> Or I guess we could call pci_dev_reset_iommu_done()
> unconditionally and pass it 'restore' and it could test it
If the condition here is "an upstream bridge becomes inaccessible
during a reset", then the reset/flr itself fails?
The patch that you acked yesterday handles such a case:
https://lore.kernel.org/linux-iommu/20261105001312.GA1479227@bhelgaas/
Nicolin
next prev parent reply other threads:[~2026-11-05 23:16 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-20 18:10 [PATCH] PCI/ATS: Disable ATS when ACS TB is set upstream Danny Gonzalez
2026-10-20 18:36 ` sashiko-bot
2026-11-05 23:04 ` Bjorn Helgaas
2026-11-05 23:15 ` Nicolin Chen [this message]
2026-11-06 17:49 ` Jason Gunthorpe
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=au0OEn8xLzsIhQIQ@nvidia.com \
--to=nicolinc@nvidia.com \
--cc=baolu.lu@linux.intel.com \
--cc=bhelgaas@google.com \
--cc=decot@google.com \
--cc=digonzal@google.com \
--cc=helgaas@kernel.org \
--cc=jgg@nvidia.com \
--cc=joerg.roedel@amd.com \
--cc=kevin.tian@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=praan@google.com \
--cc=sheenamo@google.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.