Greg KH wrote:
Except that the individual drivers are a lot of the time written by
different people, live in different portions of the tree, and are
combined into different combinations depending on the chipset.
Yes -- the worst case is that people have to work together, and it
tweaks people who like to organize source files nicely into directories :)
For i2c devices, I see the scx200_acb, i2c-elektor, i2c-sis5595, and
i2c-sis630 drivers needing this. The last one happens to share the pci
device with a video driver, that doesn't always need to be / want to be
loaded by users just so they can read the temperature of their
processors.
Sure. Reasonable request, and doable within today's APIs.
Oh, the EDAC code also needs this, and I know that no one wants to merge
that stuff into their individual drivers :)
So people have to work together... darn :) most drivers these days are
organized nicely into nicely modular units anyway, making it easy to
write a "shell" driver that simply registers each sub-driver, and helps
arbitrate/provide resources to sub-units.
Consider, for example, a PCI driver that loads, and then fills in
platform_data to provide a specific set of resources to a platform
driver (a common idiom). You would need to create parented struct
devices (parent: pci_dev's device), but everything else should work within
I could even forsee a future where most drivers are written in a generic
platform-driver style, and PCI|sbus|embedded-bus|blah are simply
bus-specific shells that fill in platform data.
All of this should be nicely possible within the existing usage of
struct device, platform drivers, generic DMA API, iomap, etc.
Jeff
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
