All of lore.kernel.org
 help / color / mirror / Atom feed
From: Brian Norris <briannorris@chromium.org>
To: gregkh@linuxfoundation.org
Cc: bhelgaas@google.com, stable-commits@vger.kernel.org,
	stable@vger.kernel.org
Subject: Re: Patch "PCI/sysfs: Ensure devices are powered for config reads" has been added to the 6.6-stable tree
Date: Thu, 16 Oct 2025 08:15:46 -0700	[thread overview]
Message-ID: <aPEMIreBYZ7yk3cm@google.com> (raw)
In-Reply-To: <2025101627-purifier-crewless-0d52@gregkh>

Hi,

On Thu, Oct 16, 2025 at 03:09:27PM +0200, Greg Kroah-Hartman wrote:
> 
> This is a note to let you know that I've just added the patch titled
> 
>     PCI/sysfs: Ensure devices are powered for config reads
> 
> to the 6.6-stable tree which can be found at:
>     http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
> 
> The filename of the patch is:
>      pci-sysfs-ensure-devices-are-powered-for-config-reads.patch
> and it can be found in the queue-6.6 subdirectory.
> 
> If you, or anyone else, feels it should not be added to the stable tree,
> please let <stable@vger.kernel.org> know about it.

Adding to the stable tree is good IMO, but one note about exactly how to
do so below:

> Wrap these access in pci_config_pm_runtime_{get,put}() like most of the
> rest of the similar sysfs attributes.
> 
> Notably, "max_link_speed" does not access config registers; it returns a
> cached value since d2bd39c0456b ("PCI: Store all PCIe Supported Link
> Speeds").

^^ This note about commit d2bd39c0456b was specifically to provide hints
about backporting. Without commit d2bd39c0456b, the solution is somewhat
incomplete. We should either backport commit d2bd39c0456b as well, or we
should adapt the change to add pci_config_pm_runtime_{get,put}() in
max_link_speed_show() too.

Commit d2bd39c0456b was already ported to 6.12.y, but seemingly no
further.

If adapting this change to pre-commit-d2bd39c0456b is better, I can
submit an updated version here.

Without commit d2bd39c0456b, it just means that the 'max_link_speed'
sysfs attribute is still susceptible to accessing a powered-down
device/link. We're in no worse state than we were without this patch.
And frankly, people are not likely to notice if they haven't already,
since I'd guess most systems don't suspend devices this aggressively.

Brian

> Fixes: 56c1af4606f0 ("PCI: Add sysfs max_link_speed/width, current_link_speed/width, etc")
> Signed-off-by: Brian Norris <briannorris@google.com>
> Signed-off-by: Brian Norris <briannorris@chromium.org>
> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
> Cc: stable@vger.kernel.org
> Link: https://patch.msgid.link/20250924095711.v2.1.Ibb5b6ca1e2c059e04ec53140cd98a44f2684c668@changeid
> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> ---
>  drivers/pci/pci-sysfs.c |   20 +++++++++++++++++++-
>  1 file changed, 19 insertions(+), 1 deletion(-)
> 
> --- a/drivers/pci/pci-sysfs.c
> +++ b/drivers/pci/pci-sysfs.c
> @@ -196,8 +196,14 @@ static ssize_t max_link_width_show(struc
>  				   struct device_attribute *attr, char *buf)
>  {
>  	struct pci_dev *pdev = to_pci_dev(dev);
> +	ssize_t ret;
>  
> -	return sysfs_emit(buf, "%u\n", pcie_get_width_cap(pdev));
> +	/* We read PCI_EXP_LNKCAP, so we need the device to be accessible. */
> +	pci_config_pm_runtime_get(pdev);
> +	ret = sysfs_emit(buf, "%u\n", pcie_get_width_cap(pdev));
> +	pci_config_pm_runtime_put(pdev);
> +
> +	return ret;
>  }
>  static DEVICE_ATTR_RO(max_link_width);
>  
> @@ -209,7 +215,10 @@ static ssize_t current_link_speed_show(s
>  	int err;
>  	enum pci_bus_speed speed;
>  
> +	pci_config_pm_runtime_get(pci_dev);
>  	err = pcie_capability_read_word(pci_dev, PCI_EXP_LNKSTA, &linkstat);
> +	pci_config_pm_runtime_put(pci_dev);
> +
>  	if (err)
>  		return -EINVAL;
>  
> @@ -226,7 +235,10 @@ static ssize_t current_link_width_show(s
>  	u16 linkstat;
>  	int err;
>  
> +	pci_config_pm_runtime_get(pci_dev);
>  	err = pcie_capability_read_word(pci_dev, PCI_EXP_LNKSTA, &linkstat);
> +	pci_config_pm_runtime_put(pci_dev);
> +
>  	if (err)
>  		return -EINVAL;
>  
> @@ -242,7 +254,10 @@ static ssize_t secondary_bus_number_show
>  	u8 sec_bus;
>  	int err;
>  
> +	pci_config_pm_runtime_get(pci_dev);
>  	err = pci_read_config_byte(pci_dev, PCI_SECONDARY_BUS, &sec_bus);
> +	pci_config_pm_runtime_put(pci_dev);
> +
>  	if (err)
>  		return -EINVAL;
>  
> @@ -258,7 +273,10 @@ static ssize_t subordinate_bus_number_sh
>  	u8 sub_bus;
>  	int err;
>  
> +	pci_config_pm_runtime_get(pci_dev);
>  	err = pci_read_config_byte(pci_dev, PCI_SUBORDINATE_BUS, &sub_bus);
> +	pci_config_pm_runtime_put(pci_dev);
> +
>  	if (err)
>  		return -EINVAL;
>  
> 
> 
> Patches currently in stable-queue which might be from briannorris@google.com are
> 
> queue-6.6/pci-sysfs-ensure-devices-are-powered-for-config-reads.patch

       reply	other threads:[~2025-10-16 15:15 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <2025101627-purifier-crewless-0d52@gregkh>
2025-10-16 15:15 ` Brian Norris [this message]
2025-10-17  6:58   ` Patch "PCI/sysfs: Ensure devices are powered for config reads" has been added to the 6.6-stable tree Greg KH
2025-10-17 17:50     ` Brian Norris
2025-10-20 20:44       ` Brian Norris

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=aPEMIreBYZ7yk3cm@google.com \
    --to=briannorris@chromium.org \
    --cc=bhelgaas@google.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=stable-commits@vger.kernel.org \
    --cc=stable@vger.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.