On Fri, Aug 22, 2025 at 09:11:25AM +0800, Ethan Zhao wrote:
On 8/21/2025 11:28 PM, Brian Norris wrote:
On Thu, Aug 21, 2025 at 08:41:28PM +0800, Ethan Zhao wrote:
Hold a PM reference by pci_config_pm_runtime_get() and then write some data to the PCIe config space, no objection.
To know about the linkspeed etc capabilities/not status, how about creating a cached version of these caps, no need to change their power state.
For static values like the "max" attributes, maybe that's fine.
But Linux is not always the one changing the link speed. I've seen PCI devices that autonomously request link-speed changes, and AFAICT, the only way we'd know in host software is to go reread the config registers. So caching just produces cache invalidation problems.
Maybe you meant the link-speed status, that would be volatile based on link retraining.
Yes.
Here we are talking about some non-volatile capabilities value no invalidation needed to their cached variables.
I missed the "not status" part a few lines up.
So yes, I agree it's possible to make some of these (but not all) use a cache. I could perhaps give that a shot, if it's acknowledged that the non-cacheable attributes are worth fixing.
If there is aggressive power saving requirement, and the polling of these caps will make up wakeup/poweron bugs.
If you're worried about wakeup frequency, I think that's a matter of user space / system administraction to decide -- if it doesn't want to potentially wake up the link, it shouldn't be poking at config-based
IMHO, sysfs interface is part of KABI, you change its behavior , you definitely would break some running binaries. there is alternative way to avoid re-cooking binaries or waking up administrator to modify their configuration/script in the deep night. you already got it.
That's not how KABI works. Just because there's a potentially-observable difference doesn't mean we're "breaking" the ABI. You'd have to demonstrate an actual use case that is breaking. I don't see how it's "broken" to wake up a device when the API is asking for a value that can only be retrieved while awake. Sure, it's potentially a small change in power consumption, but that can apply to almost any kind of change.
My claim is that this is a currently broken area, and that it is impossible to use these interfaces on a system that aggressively enters D3cold. If a system observes any difference from this change, then it was broken before. Bugfixes are not inherently KABI breakages just because they can be observed.
Brian