On 7/15/08, Mark Brown broonie@opensource.wolfsonmicro.com wrote:
On Mon, Jul 14, 2008 at 07:45:46PM -0400, Jon Smirl wrote:
On 7/14/08, Timur Tabi timur@freescale.com wrote:
Mark Brown wrote:
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.
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.
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.
If we allow multiple bindings both lite5200b and mpc5200-simple would bind. The compatible list is a priority list from most specific to most general. First you check for the specific driver lite5200b, if it's not found then load the generic one mpc5200-simple.
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.
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.
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.
run into similar situations with other hardware at some point - either for undocumented extras that you happen to know exist on the system (like much of the DMI usage on x86) or for other things where you've got on-board hardware structured like sound hardware tends to be.
This makes sense, it is possible that other areas we aren't familiar with will need fabric drivers too. The problem is easily exposed in audio hardware since we use external clock and amp chips.