[alsa-devel] [PATCH v2 1/3] ALSA SoC: Add OpenFirmware helper for matching bus and codec drivers

[Mark Brown]

On Tue, Jul 15, 2008 at 09:08:28AM -0400, Jon Smirl wrote:
> On 7/15/08, Mark Brown <broonie at 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. :/