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

[Alan Cox]

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)

>  - 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.

> 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.
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.

Alan

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/