Re: [Patch] MPC Adapter: read class attribute from device tree

[Wolfgang Grandegger <wg-5Yr1BZd7O62+XT7JhA+gdA@public.gmane.org>]

Michael Lawnick wrote:
> Wolfgang Grandegger said the following:
>> Hello,
>>
>> sorry for jumping in late. I just recently subscribed to this list.
>>
>> Michael Lawnick wrote:
>>> For MPC adapter there is no class assigned as it is done in other
>>> adapters. This way no new-style client will ever be instantiated. With
>>> this patch class assignment is read from device tree.
>>> Necessary entry:
>>> class = <1>; /* I2C_CLASS_HWMON (iic.h) */
>> Do we really need that? Probing is dangerous and not necessary. Does it
>> not work with a proper DTS entry? But maybe I have missed something?
> 
> Our current and our next system consists of two flavors of the same
> board with different devices. To minimize maintenance and testing we use
> a reduced kernel and load the needed modules at runtime. Furthermore we
> will have to handle hot-plugged I2C-devices. Whether this strategy is
> best could be discussed in another thread but is rather OT in this
> mailing list. Nevertheless loading modules at runtime is legal and
> generally supported by LINUX.
> 
> Defining all possible (I2C-)devices in DTS would give a mess. E.g. on
> one board there will be ~30 temperature sensors, on the other none.

The legacy device probing has it's limitations and I doubt that it will
be able to find 30 DTT devices properly. E.g. the legacy probing
algorithm is not able to distinguish between a LM75 and DS75. Let's
first try to find out why it does not work as expected with the DTS entry.

> As every DTS entry will force a sysFs subdirectory there would be a
> bunch of functionless directories - rather ugly.

Hopefully not. They will be created when the probing was successful, I
assume. I think it is OK to define multiple I2C nodes also for
non-existing devices in the DTS file if the I2C address is unique.

Wolfgang.