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

["Jon Smirl" <jonsmirl@gmail.com>]

On 7/14/08, Timur Tabi <timur@freescale.com> wrote:
> Mark Brown wrote:
>
>  > Desktop Management Interface, a standard BIOS interface for getting
>  > system data on x86 class hardware.  Of particular interest here is the
>  > fact that it contains various ID strings for things like motherboard and
>  > chassis - on Linux drivers can be automatically loaded based on these
>  > strings.  See drivers/misc/thinkpad_acpi.c for an example of a driver
>  > that does this.
>
>
> The only problem with this is that the OF probing code in the kernel binds
>  drivers to device tree nodes.  So when a driver claims a node, no other driver
>  will be probed with it.
>
>  So we can't have generic nodes that classify the motherboard and just let
>  everyone get probed on it.

Allowing multiple binds at the root causes the problem of something
like compatible="lite5200b,mpc5200-simple". Both platforms would bind
and that's not what you want.

I'm not a fan of each platform creating a platform device in
arch/powerpc/platforms/*. That implies that each platform would cause
another source file to be added each containing pretty much identical
code. It also makes the mpc5200-simple platform pointless. Of course
this scheme works and I'm doing it right now, but it's clearly not an
optimal solution.

Another scheme would be to add kernel code to always create virtual OF
devices like "lite5200b-fabric" that are derived off from the machine
name that achieved a bind.

A third scheme would be to convert the powerpc machine drivers
themselves to device drivers and move them out of
arch/powerpc/platforms/* into drivers/whatever. Then add the ASoC
fabric code to them. I don't know if you can load device drivers early
enough to load a powerpc machine driver from initrd.

A fourth scheme is to do it at compile time. But that means no
universal firmware images that support multiple hardware revisions. We
have this one today too.

-- 
Jon Smirl
jonsmirl@gmail.com