Messages in this thread | | | Subject | Re: [PATCH 1/2] pci: Block config access during BIST | From | Benjamin Herrenschmidt <> | Date | Sun, 21 Nov 2004 09:32:01 +1100 |
| |
On Sat, 2004-11-20 at 12:42 +0000, Alan Cox wrote: > On Sad, 2004-11-20 at 07:09, Benjamin Herrenschmidt wrote: > > 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: > > That doesn't mean it is the right implementation. Most devices don't > need > this check so might as well have a fast path. You can at least reduce > the cost by setting a flag on devices that potentially have this problem > (or a PCI_ANY PCI_ANY quirk for platforms with it globally)
Oh, that's I agree (about the implentation beeing maybe sub-optimal), especially the possibility to avoid the lock...
> > - 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. > > That will be fun given some laptop SMM touches config space.
None of the affected setups has something as broken-by-design as SMM BIOSes :)
> > 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. > > Some of the Intel CPU's are very bad at lock handling so it is an issue.
Yah, we alraedy have a lock in the config space code, so I think the solution here is to avoid the double locks by doing things a bit differently.
> Also most PCI config accesses nowdays go to onboard devices whose > behaviour may well be quite different to PCI anyway. PCI has become a > device management API. > > I dislike the "Hey it sucks, lets make it suck more" approach when it > seems easy to do the job well.
I don't understand your statements above.
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/
| |