Messages in this thread | | | Subject | Re: [PATCH 1/2] pci: Block config access during BIST | From | Benjamin Herrenschmidt <> | Date | Sat, 20 Nov 2004 18:09:27 +1100 |
| |
> 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.
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |