All of lore.kernel.org
 help / color / mirror / Atom feed
From: Nicolin Chen <nicolinc@nvidia.com>
To: Jonathan Cameron <jonathan.cameron@oss.qualcomm.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 10:44:29 -0800	[thread overview]
Message-ID: <auorjXgbVPXZNHZL@nvidia.com> (raw)
In-Reply-To: <6c09d2f78d4bb9db7f49fa14a6550f5176721121.1793729707.git.nicolinc@nvidia.com>

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.

Nicolin

  parent reply	other threads:[~2026-11-03 18:45 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 [this message]
2026-11-03 21:02     ` Jonathan Cameron
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=auorjXgbVPXZNHZL@nvidia.com \
    --to=nicolinc@nvidia.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=jonathan.cameron@oss.qualcomm.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=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.