public inbox for linux-cxl@vger.kernel.org
 help / color / mirror / Atom feed
From: Dave Jiang <dave.jiang@intel.com>
To: Vidya Sagar <vidyas@nvidia.com>,
	bhelgaas@google.com, Jonathan.Cameron@huawei.com,
	alex.williamson@redhat.com, raphael.norwitz@nutanix.com,
	Dan Williams <dan.j.williams@intel.com>
Cc: vsethi@nvidia.com, sdonthineni@nvidia.com, smadhavan@nvidia.com,
	skancherla@nvidia.com, vaslot@nvidia.com,
	linux-pci@vger.kernel.org, linux-cxl@vger.kernel.org,
	linux-kernel@vger.kernel.org, kthota@nvidia.com,
	mmaddireddy@nvidia.com, sagar.tv@gmail.com
Subject: Re: [PATCH V1] PCI: Hide SBR from reset_methods if masked by CXL
Date: Fri, 20 Feb 2026 14:21:27 -0700	[thread overview]
Message-ID: <835de7c9-a64f-4aaa-95e0-b91c2ae5885e@intel.com> (raw)
In-Reply-To: <20260220195259.2397847-1-vidyas@nvidia.com>



On 2/20/26 12:52 PM, Vidya Sagar wrote:
> The CXL specification (e.g., CXL r3.1 v1.0, sec 8.1.5.2) defines
> the "Unmask SBR" bit in the Port Control Extensions Register.
> When this bit is 0 (default), asserting the Secondary Bus Reset (SBR) bit
> in the Bridge Control register has no effect on the downstream bus.
> 
> Currently, the Linux PCI core checks this condition in
> pci_reset_bus_function(). If SBR is masked, it returns -ENOTTY during the
> execution of the reset. However, during the probe phase (when probe=true),
> the function currently returns 0. This 0 return value incorrectly signals
> to the PCI subsystem that SBR is a viable reset method for the device.


The "Unmask SBR" bit is a toggle bit. It does not give indicator whether the device is capable of SBR or not. The original thought was that if the user is issuing CXL SBR, you know what you are doing and the kernel will set that bit and issue the SBR.

DJ

> 
> As a result, 'bus' is listed in the device's
> /sys/bus/pci/devices/.../reset_methods attribute, even though the hardware
> is incapable of performing it. If a user attempts to write bus to reset
> method or triggers a reset that falls back to SBR, the operation fails
> with: "bash: echo: write error: Inappropriate ioctl for device" error.
> 
> This patch modifies pci_reset_bus_function() to return -ENOTTY immediately
> if cxl_sbr_masked() is true, regardless of the probe argument. This
> ensures that 'bus' is not advertised in reset_methods when the hardware
> prevents it, improving clarity for users and aligning the sysfs capability
> report with actual hardware behavior.
> 
> Signed-off-by: Vidya Sagar <vidyas@nvidia.com>
> ---
>  drivers/pci/pci.c | 6 +-----
>  1 file changed, 1 insertion(+), 5 deletions(-)
> 
> diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
> index f3244630bfd0..57e24300d1c7 100644
> --- a/drivers/pci/pci.c
> +++ b/drivers/pci/pci.c
> @@ -4915,12 +4915,8 @@ static int pci_reset_bus_function(struct pci_dev *dev, bool probe)
>  	 * If "dev" is below a CXL port that has SBR control masked, SBR
>  	 * won't do anything, so return error.
>  	 */
> -	if (bridge && cxl_sbr_masked(bridge)) {
> -		if (probe)
> -			return 0;
> -
> +	if (bridge && cxl_sbr_masked(bridge))
>  		return -ENOTTY;
> -	}
>  
>  	rc = pci_dev_reset_iommu_prepare(dev);
>  	if (rc) {


  reply	other threads:[~2026-02-20 21:21 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-02-20 19:52 [PATCH V1] PCI: Hide SBR from reset_methods if masked by CXL Vidya Sagar
2026-02-20 21:21 ` Dave Jiang [this message]
2026-02-23 13:11   ` Vidya Sagar
2026-02-23 15:52     ` Dave Jiang
2026-02-25 13:13       ` Vidya Sagar
2026-02-25 16:09         ` Dave Jiang
2026-02-25 13:38 ` [PATCH V2] " Vidya Sagar
2026-02-25 16:34   ` Dave Jiang
2026-02-27 13:34     ` Jonathan Cameron
2026-03-17 17:34     ` Vidya Sagar
2026-03-17 19:57   ` 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=835de7c9-a64f-4aaa-95e0-b91c2ae5885e@intel.com \
    --to=dave.jiang@intel.com \
    --cc=Jonathan.Cameron@huawei.com \
    --cc=alex.williamson@redhat.com \
    --cc=bhelgaas@google.com \
    --cc=dan.j.williams@intel.com \
    --cc=kthota@nvidia.com \
    --cc=linux-cxl@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=mmaddireddy@nvidia.com \
    --cc=raphael.norwitz@nutanix.com \
    --cc=sagar.tv@gmail.com \
    --cc=sdonthineni@nvidia.com \
    --cc=skancherla@nvidia.com \
    --cc=smadhavan@nvidia.com \
    --cc=vaslot@nvidia.com \
    --cc=vidyas@nvidia.com \
    --cc=vsethi@nvidia.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