Re: [PATCH 1/2] pci: Block config access during BIST

[Benjamin Herrenschmidt <benh@kernel.crashing.org>]

> Even better, put that code in your private debug tree. Replace the
> locked cases with BUG() and fix the driver to get its internal locking
> right in this situation.
> 
> It seems wrong to put expensive checks in core code paths when you could
> just as easily provide
> 
> 	my_device_is_stupid_pci_read_config_byte()
> 
> and equivalent lock taking functions that wrap the existing ones and are
> locked against the reset path without hurting sane computing devices
> (and PC's).

Unfortunately, Alan, the cases where it matters aren't a driver with bad
locking or some something that can be fixed at the driver level. There
are already 2 uses of the above:

 - The device he's working on, which sometimes need to trigger a BIST
(built-in self test). During this operation, the device stops responding
on the PCI bus, which can be sort-of fatal if anything (userland playing
with /sys/bus/pci/* for example) touches the config space.

 - On Macs, I can turn the clock of some PCI devices on/off for power
management (and I do). However, when such a device is powered off, it
will not respond to config cycles neither, resulting in all-1's reads on
some HW setups or even in deadlock iirc on the G5. We need to "cloack"
them properly while the kernel still has the pci_dev entry for them
since they are just locally power managed by their driver , while
retaining userland visibility in /proc/pci or /sysfs or things like
kudzu stops finding them.

Also, the "Mac" case here (power management) is something I've seen
doable in a variety of embedded setups.

I would add: Config space accesses are slow anyways. They are even
horribly slow. They are worse than IO accesses. I _VERY_MUCH_ doubt that
a test of a variable member of pci_dev like the above would have any
noticeable impact here.

Ben.