On Fri, 13 Oct 2006, Adam Belay wrote:
> Personally, I don't think exposing a cached version of the PCI config
> space when direct device access is prohibited is the right approach
> here. We really shouldn't be lying about the internal state of PCI
> devices (the cached version could be quite inaccurate). After all, if
> the device is in D3cold, then the spec claims it's perfectly valid for
> it to not respond to PCI configuration access.
>
> I can only assume this hack was done to satisfy some terribly broken
> userspace app. It's not surprising that even reading PCI config can
> easily crash systems. However, it's the responsibility of those apps
> with permission to access the PCI sysfs interface, not the kernel, to be
> aware of these constraints.
According to the comment in the code, access is blocked only during the
time that the device is making the transition between different power
states.
> The PCI configuration space cache was originally introduced to support
> power management. However, it's mostly incorrect, as it unnecessarily
> stores the values of read only registers (and even BIST which is
> potentially dangerous). A while back I posted a series of patches that
> address this issue, and the net result was that the config cache stays
> around wasting memory because of the pci_block_user_cfg_access()
> dependency despite being useless to PCI PM.
>
> I'd like to propose that we have the pci config sysfs interface return
> -EIO when it's blocked (e.g. active BIST or D3cold). This accurately
> reflects the state of the device to userspace, reduces complexity, and
> could potentially save some memory per PCI device instance.
Could you resubmit your old patches and include a corresponding fix for
this access problem?
BTW, is it possible for userspace to try accessing a device in D3cold?
Doesn't the fact that it is D3cold rather than D3hot mean the computer is
turned off? Or have I been missing out on new developments?
Alan Stern
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
