Linux PCI subsystem development
 help / color / mirror / Atom feed
From: "Krzysztof Wilczyński" <kwilczynski@kernel.org>
To: Bjorn Helgaas <bhelgaas@google.com>
Cc: Bjorn Helgaas <helgaas@kernel.org>,
	Manivannan Sadhasivam <mani@kernel.org>,
	Lorenzo Pieralisi <lpieralisi@kernel.org>,
	linux-pci@vger.kernel.org
Subject: [PATCH] PCI/proc: Avoid spurious runtime PM wakeup on config space accesses
Date: Wed, 29 Jul 2026 07:59:09 +0000	[thread overview]
Message-ID: <20260729075909.1219906-1-kwilczynski@kernel.org> (raw)

Currently, proc_bus_pci_read() and proc_bus_pci_write() do not return
early for zero-length configuration space accesses at valid offsets.

Thus, such an access invokes pci_config_pm_runtime_get() and
pci_config_pm_runtime_put() around transfer blocks that do nothing.

This is a problem because pci_config_pm_runtime_get() synchronously
resumes the upstream bridge through pm_runtime_get_sync(), and resumes
the device itself through pm_runtime_resume() when it is in D3cold,
only for the handler to return zero immediately afterwards.  Such a
spurious wakeup wastes power and adds needless resume latency.

The sysfs core already returns early for in-range zero-length binary
attribute accesses before pci_read_config() or pci_write_config() is
invoked.  In contrast, the VFS forwards zero-length requests to the
procfs callbacks, where they continue into runtime PM handling.

Therefore, return early from proc_bus_pci_read() and proc_bus_pci_write()
when nbytes is zero, before any runtime PM involvement.

The value returned to userspace at these offsets remains zero,
so the change is not visible to userspace.

Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org>
---
 drivers/pci/proc.c | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/drivers/pci/proc.c b/drivers/pci/proc.c
index 71ad289fcb8e..fcbd75d53ac5 100644
--- a/drivers/pci/proc.c
+++ b/drivers/pci/proc.c
@@ -46,6 +46,9 @@ static ssize_t proc_bus_pci_read(struct file *file, char __user *buf,
 	else
 		size = 64;
 
+	if (!nbytes)
+		return 0;
+
 	if (pos >= size)
 		return 0;
 	if (nbytes >= size)
@@ -122,6 +125,9 @@ static ssize_t proc_bus_pci_write(struct file *file, const char __user *buf,
 	if (ret)
 		return ret;
 
+	if (!nbytes)
+		return 0;
+
 	if (pos >= size)
 		return 0;
 	if (nbytes >= size)
-- 
2.55.0


             reply	other threads:[~2026-07-29  7:59 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-29  7:59 Krzysztof Wilczyński [this message]
2026-07-29  8:05 ` [PATCH] PCI/proc: Avoid spurious runtime PM wakeup on config space accesses sashiko-bot

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=20260729075909.1219906-1-kwilczynski@kernel.org \
    --to=kwilczynski@kernel.org \
    --cc=bhelgaas@google.com \
    --cc=helgaas@kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=lpieralisi@kernel.org \
    --cc=mani@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox