From: Jonathan Cameron <jonathan.cameron@oss.qualcomm.com>
To: Nicolin Chen <nicolinc@nvidia.com>
Cc: Jason Gunthorpe <jgg@nvidia.com>, <joro@8bytes.org>,
Bjorn Helgaas <bhelgaas@google.com>,
Will Deacon <will@kernel.org>,
Robin Murphy <robin.murphy@arm.com>, <rafael@kernel.org>,
Len Brown <lenb@kernel.org>, Joerg Roedel <joerg.roedel@amd.com>,
Kevin Tian <kevin.tian@intel.com>,
Jonathan Cameron <Jonathan.Cameron@huawei.com>,
Dave Jiang <dave.jiang@intel.com>, Dan Williams <djbw@kernel.org>,
<iommu@lists.linux.dev>, <linux-kernel@vger.kernel.org>,
<linux-acpi@vger.kernel.org>, <linux-pci@vger.kernel.org>
Subject: Re: [PATCH v1 2/5] PCI/CXL: Probe the underlying bus reset in cxl_reset_bus_function()
Date: Tue, 3 Nov 2026 13:02:14 -0800 [thread overview]
Message-ID: <20261103130214.00000b82@oss.qualcomm.com> (raw)
In-Reply-To: <auorjXgbVPXZNHZL@nvidia.com>
On Tue, 3 Nov 2026 10:44:29 -0800
Nicolin Chen <nicolinc@nvidia.com> wrote:
> On Tue, Nov 03, 2026 at 10:33:43AM -0800, Nicolin Chen wrote:
> > cxl_reset_bus_function() reports "supported" to a probe after checking only
> > that the upstream bridge carries a CXL port DVSEC. The underlying bus reset
> > can still be unavailable, e.g. on a bus shared with other devices, so both
> > the reset_methods[] array and the reset_method sysfs node end up listing a
> > "cxl_bus" that is guaranteed to fail with -ENOTTY when it is attempted.
> >
> > Probe the underlying pci_dev_reset_slot_function() and then, if it is not
> > applicable, pci_parent_bus_reset(). These are the same two checks that the
> > actual reset runs, so a shared-bus CXL device no longer advertises a method
> > that can never succeed.
> >
> > Probing via pci_reset_bus_function() would not work: its cxl_sbr_masked()
> > check rejects every CXL port with a masked SBR, while the do-reset path in
> > this function unmasks the SBR before resetting. Such a port would wrongly
> > probe as unsupported.
> >
> > Move the port control register read above the probe branch as well, so that
> > probe runs the same checks. That read asserts no reset, and a failure means
> > the device cannot be reset this way, which is a probe-time answer.
> >
> > Also pass an explicit PCI_RESET_DO_RESET at the do-reset call site, since
> > probe is always false at that point.
> >
> > Fixes: 53c49b6e6dd2e ("PCI/CXL: Add 'cxl_bus' reset method for devices below CXL Ports")
> > Signed-off-by: Nicolin Chen <nicolinc@nvidia.com>
>
> Ah, I missed Jonathan's review tag during the split:
> https://lore.kernel.org/linux-iommu/20260926001311.7c4be583@jic23-hlaptop/
>
> Jonathan, would you mind giving another review tag here? It's the
> exact same patch that you reviewed. Sorry for the inconvenience.
>
Reviewed-by: Jonathan Cameron <jonathan.cameron@oss.qualcomm.com>
> Nicolin
next prev parent reply other threads:[~2026-11-03 21:02 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-03 18:33 [PATCH v1 0/5] iommu: Keep a device blocked after a failed PCI reset Nicolin Chen
2026-11-03 18:33 ` [PATCH v1 1/5] PCI: Don't suspend IOMMU when probing reset capability Nicolin Chen
2026-11-03 18:40 ` sashiko-bot
2026-11-03 18:33 ` [PATCH v1 2/5] PCI/CXL: Probe the underlying bus reset in cxl_reset_bus_function() Nicolin Chen
2026-11-03 18:44 ` sashiko-bot
2026-11-03 18:44 ` Nicolin Chen
2026-11-03 21:02 ` Jonathan Cameron [this message]
2026-11-03 18:33 ` [PATCH v1 3/5] iommu: Convert gdev->blocked from bool to enum blocked_reason Nicolin Chen
2026-11-03 18:39 ` sashiko-bot
2026-11-03 18:33 ` [PATCH v1 4/5] iommu: Pass in gdev's blocked state to iommu_deinit_device() Nicolin Chen
2026-11-03 18:44 ` sashiko-bot
2026-11-03 18:33 ` [PATCH v1 5/5] iommu: Pass in reset result to pci_dev_reset_iommu_done() Nicolin Chen
2026-11-03 18:52 ` sashiko-bot
2026-11-03 19:59 ` Nicolin Chen
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=20261103130214.00000b82@oss.qualcomm.com \
--to=jonathan.cameron@oss.qualcomm.com \
--cc=Jonathan.Cameron@huawei.com \
--cc=bhelgaas@google.com \
--cc=dave.jiang@intel.com \
--cc=djbw@kernel.org \
--cc=iommu@lists.linux.dev \
--cc=jgg@nvidia.com \
--cc=joerg.roedel@amd.com \
--cc=joro@8bytes.org \
--cc=kevin.tian@intel.com \
--cc=lenb@kernel.org \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=nicolinc@nvidia.com \
--cc=rafael@kernel.org \
--cc=robin.murphy@arm.com \
--cc=will@kernel.org \
/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.