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

[Michael Lawnick <ml.lawnick-Mmb7MZpHnFY@public.gmane.org>]

Wolfram Sang said the following:
>> mailing list. Nevertheless loading modules at runtime is legal and
>> generally supported by LINUX.
> 
> Ack. And it does so...
> 
>> 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.
>> As every DTS entry will force a sysFs subdirectory there would be a
>> bunch of functionless directories - rather ugly.
> 
> Well, you should have a DTS for every flavour; that is what DTS are
> about. You do know that, do you?

You like it more complicated? Ok, here it is:
As Jean indicated in his reply, we will have to support hotplug. Most of
the above sensors won't exist a life time on some systems, on others all
could exist. I tried to keep out this issue to avoid a drift to the
discussion that hotplug is not _yet_ supported. I will^Wmust support
hotplug, either by using tree's code or by doing my own modifications.
> 
> Even if not, there would be a slighty messed directory on one specific
> device with how many units? Let's take the latest example of extending
> the DTS file with OS-specific information - this one is ugly, too, but
> has impact _for everyone using dts_ files. Think about the number of
> affected systems and you will hopefully understand why such patches are
> handled with extreme caution.

You talk about my reading of the class entry from DTS?
No, I don't understand how other systems are affected by this.
They don't read this entry of _my_ .dts file.
Seems there is a general misunderstanding...
> 
>> Because of the situation above I try to keep the ability of dynamic
>> instantiation. Jean hesitates, I feel because he sees I2C solely in
>> static manner.
> 
> He is taking care for every I2C communication on every Linux machine out
> there. He can't please everyone. On the other hand, you are free to
> modify the kernel as you please. It doesn't really have to be in
> mainline, does it?
If this would be a private problem, yes.
But I see this as a more general flaw:
Many adapters do initialization of .class in adapter code. A few do not.
I haven't checked, but assume the PPC ones, as they have DTS. Thats Ok,
as long DTS is really used. In at least one other adapter it is: Exactly
Wolfgang Grandegger, who is responsible for removal of the original
default initialization, showed me, that it is done in i2c-cpm!
> 
> BTW, I hope you saw that the "linux,i2c-class" property is considered
> deprecated. Thus, expect a patch from me removing it entirely as soon
> as the old binding model went away (there aren't even any users).
> 
And how do you want to implement setting the class attribute?
Allowing only clients that are mentioned in DTS? How should it work on
systems without DTS?