On Wed, 2002-07-24 at 23:58, William Lee Irwin III wrote:
> I don't have one of these, and I'm not even sure what it is. But here's
> a wild guess at a fix.
These must be locked against any other PCI access so it needs to share
the lock with arch/i386/kernel/pci*.c. The code is also wrong for other
reasons and there are some fixes in the 2.4.19-ac tree to those
functions that affect the locking and maybe should be merged too.
What is going on here is that we have to probe the CMD640 PCI either via
PCI conf1 or PCI conf2. We cannot use the kernel default functions
because they may trigger a bug in the CMD640 hardware.
get_cmd640_reg_pci[12] are basically reimplementations of the
pci_read_config bits for type 1/type 2 PCI configurations. The register
and lock are thus the same as the core. This lock also needs to match
the same lock on non x86 platforms so the pci config lock name should be
unified now before the brown and sticky impacts on the rotating
propellor blades
-
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/
This archive was generated by hypermail 2b29 : Tue Jul 30 2002 - 14:00:17 EST