Re: [RFC PATCH] slimbus: Linux driver framework for SLIMbus.

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

On Wed, 2011-08-17 at 16:00 +0200, Arnd Bergmann wrote:

> How about a mixed model then?

> I can see three relevant cases to consider:

> 1. A simple potentially hotplugged device that registers itself to the bus
>    can be automatically matched to the driver.
> 2. A device tree representation for hardwired devices that require
>    something to happen in order to register to the bus (clock, regulator,
>    ...).
> 3. A hardcoded list of devices on a slimbus host for stuff that is known
>    to be there, e.g. on a PCI card that has its own driver and that
>    also need some special setup as in case 2.

> I think in all three cases, we should identify the device by its EA and
> match that to the device driver. We create the slim_device and register
> it to the bus as soon as one of the three above is found, but in case 2
> and 3, the driver is responsible for the device to actually become active
> on the bus before it's allowed to send any commands to it.

Yes, I think that makes sense and it matches what we're doing with the
other subsystems well. We should be able to make the drivers work with
all cases. Probably the probe function should have a flag and/or query
function to let the driver know if the device has actually appeared yet.

> For the device tree binding, I would suggest defining a slimbus bus to
> have #address-cells=1, #size-cells=0 and just put the EA into the reg
> property. This is enough for the host driver to add create a
> slim_device and match a driver to it. The driver can access all the
> properties from the device_node (or platform_data in case of statically
> defined devices). When the physical device shows up on the bus, it is
> automatically associated with the existing slim_device.

Sounds reasonable I'd need to actually look at the specs again for the
details.