As I read the code it doesn't have to do with preemption so much as
machine-check control. So, no, I don't think I'll be changing it.
> - I also don't see any need for calling lock_kernel() in PCI config
> space access syscalls as they just call the low-level functions and
> they do their own locking.
Good point. Probably just left over from the big lock_kernel move of '.21.
(Or whenever. But that does have a nice ring to it.)
> - Register reading functions do check for alignment correctly, but their
> write counterparts don't.
Oops. Those checks had been missing entirely before and I'd been
putting them in. Seems I missed some.
> These functions for different chipsets seem
> todiffer only in mk_conf_addr() and conf_{read,write}() ...
No they don't. Look at core_tsunami.c for the oddball.
> - You can do all the bridge reconfiguration in pcibios_fixup_bus() without
> needing to traverse the bus tree yourselves in hose_scan_bridges() and
> friends. If the only thing you need is to force pci_scan_bus() to assign
> the bus numbers even if they have been already assigned...
That has little or nothing to do with why hose_scan_bridges exists.
The problem is that multiple busses have entirely separate I/O regions,
and we need to be able to determine which bus the device in question is
on, so that we can read or write from the appropriate region.
The problem is that the kernel always uses pcibios_*_config_*, which
throws away all of the information I need to know how to perform the
operation. So what I have to do is set up a mapping from bus number
to pci controler so that I can figure out what's going on. And I have
to do this _before_ pci_scan_bus runs, since it needs that info to
even consider doing its job.
The cleanest thing would be for the kernel itself to never ever use
pcibios_*_config_*, but instead always use pci_*_config_*. With the
later, I still have the full device structure, and I can walk back up
to dev->bus->sysdata and find out what I need to know. But I figured
it was way too close to 2.2 for such a change to be considered.
I have several ideas now for 2.3 how to rearrange things to make
multi-bus machines happier.
r~
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.altern.org/andrebalsa/doc/lkml-faq.html