Yup, and I was completely on your side. Now any PCI kernel has to
carry that baggage (I know it gets dumped at boot time, but it still
offends me), even if there is no way to actually get at those strings
(i.e., /proc is unavailable).
> Isn't it possible to use the generic PCI code to scan the bus behind
> the CardBus bridge and then just fix the differences? It would require
> a bit of ifdeffing around in pci.c to avoid __initfunc'ing the bus
> scan functions if CardBus support is enabled, but we'll need it for
> hot-pluggable PCI anyway. If you want to go this way, I'll gladly
> make these modifications.
You mean, avoid __initfunc'inc the bus scan functions if CardBus
support is either enabled, or enabled as a module, or might be loaded
as a module compiled separately.
The CardBus code needs to be able to separately:
- pick all IO and memory resources and configure the bridge windows
- initialize a PCI device's configuration space from scratch
- free all IO and memory resources and close the bridge windows
(the resource selection and device initialization have to be separate,
because I pick resources once at device insertion time, but may enable
and disable the device multiple times in response to power management
events)
So yes, this stuff should probably migrate into the PCI code at some
point, but I'd want to think carefully about what functionality needs
to be exposed.
> Yes, but you can add enumeration of other device types (from PNP
> BIOS or ACPI tables) in a simple and straightforward way.
I have PnP BIOS enumeration in the PCMCIA tree, but Linus dropped it
when he did his first pass at integrating PCMCIA into the kernel. I'm
not sure if he thought it was out of place, or a bad implementation,
or a bad idea. For PCMCIA, I keep separate resource maps for PnP,
because putting this stuff in the global resource maps will require
some hairy driver updates.
-- Dave Hinds
-
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.tux.org/lkml/