[PATCH] PCI/proc: Avoid spurious runtime PM wakeup on config space accesses

Krzysztof Wilczyński <[email protected]>
Newsgroups org.kernel.vger.linux-pci
Message-ID <[email protected]>
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 <[email protected]>
---
 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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.