Loading drivers based on board identification

[Mark Brown <broonie@opensource.wolfsonmicro.com>]

Recently there's been quite a bit of discussion surrounding how to set
up machine specific hardware that can't readily be represented in the
device tree.  I was wondering if one way of solving these problems might
be to provide a mechanism for drivers to load based on board type rather
than by binding to nodes in the device tree, similar to DMI on x86
systems?

The particular case that this has been cropping up for is ASoC machine
drivers - these are drivers which specify how the components of an
embedded audio subsystem (each of which has its own driver) should be
used together to make a functional ALSA device.  Broadly, it will say
something along the lines of "The audio codec at this I2C address is
connected to one or more SSI ports on the SoC and these are clocked in
the following way", though it can get much more complex.  

This isn't a property of any of the component devices - it's all about
the relationships between these devices - and it gets sufficiently
complex in many systems that it's not realistic to try to encode it in
the device tree.  There is normally no specific hardware associated with
this that isn't controlled by one of the component drivers which makes
it difficult to fit into the device tree - in hardware terms this
roughly corresponds to the physical board the system is on.

Since this is difficult to represent in an idiomatic way in the device
tree probing based on the board type seems like reasonable solution.