On Tue, Jul 15, 2008 at 09:08:28AM -0400, Jon Smirl wrote:
On 7/15/08, Mark Brown broonie@opensource.wolfsonmicro.com wrote:
Binding isn't the issue here - it's loading the driver in the first place. Once the drivers are loaded they can (hopefully) figure out if they are running on appropriate hardware.
In this case we would end up with two core PowerPC machine drivers bound, not ALSA ones. We have machine drivers in the PowerPC core, that's one reason why it is confusing to call the ALSA drivers machine drivers too.
Again, I'm not talking about binding anything.
This is what I'm suggesting, modulo the fact that I'm suggesting *not* creating virtual devices but rather providing a mechanism for drivers to load without binding to anything. It strikes me that you're going to
If you have drivers for four different hardware releases compiled into your kernel, the only kernel mechanism I know of to trigger only one of these to initialize is to create a device and then let the probe mechanism sort it out. This is even more true when the drivers are on initrd and need to be dynamically loaded. The module load code will search through the alias lists in the module .ko files.
This can be handled in the module initialisation (rather than driver probe) - providing something can arrange for the driver to get loaded then the drivers can check the system they're running on when that happens and fail if it's inappropriate. The ARM ASoC drivers and x86 DMI based stuff do things this way, for example (ARM doesn't have the automatic module load stuff implemented, though).
The infrastructure for automatically loading modules is usable separately from device registration, though normally the two do go hand in hand.
It has been pointed out that a lite5200b-fabric device isn't really a virtual devices. It's a device that represents the traces on the PCB wiring the generic chip drivers together.
This was brought up very early on when you guys first started working on it. :/