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-arch" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
