lkml.org 
[lkml]   [2004]   [Nov]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH 1/2] pci: Block config access during BIST
From
Date

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

\
 
 \ /
  Last update: 2005-03-22 14:08    [W:1.693 / U:0.072 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site