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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



> You like it more complicated? Ok, here it is:

Thanks, that gave me a bigger picture.

> 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...

DTS is convention. One convention is to keep it OS-neutral. If you use
something out of this convention like "linux,i2c-class", you motivate
others to follow you. In fact, this is exactly what happened because
i2c-cpm defined such a thing (and people who are watching the DTS not
drifting away seemed to have missed it). If other people use it, other
OS could be forced to evaluate a property which is named  "linux" and
may be, in addition, inadequate for their purpose.

DTS (or better the OF devicetree) faces the danger of so many private
extensions that there is no common thing (= convention) at the end of
the day rendering it unusable. This is why adding new properties is
handled with care (and should always be CCed to devicetree-discuss).

> 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,

(Would be nice if you did. Knowledge is better than assumption in this
case)

I think most drivers are old enough to have a .class as it was useful
back then and nobody cared to remove it. Newer drivers, especially
embedded ones, usually don't have it right from the beginning, also on
ARM..., as probing is not wanted.

> 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!

You mean setting the class variable through DTS? Yeah, this was a good
outcome of this thread. I will submit a patch to remove it soonish. It
just slipped through, should have never been there IMHO.

> And how do you want to implement setting the class attribute?

Not at all. I see ".class" as a reminiscent to overcome some flaws of
the old binding model. If we finally got rid of that we can surely think
of a more elegant way to enforce instanciation of clients run-time. And
with that, probably get rid of .class altogether. D'accord, Jean?

> Allowing only clients that are mentioned in DTS?

For now, yes. This is still the common case (=avoid probing). Until a
mainline solution comes up (which is needed, I agree on that), not so
common cases could simply patch the driver to add a .class field.

> How should it work on systems without DTS?

i2c_board_info? (no offence, sometimes it is hard to tell if you know
all details and still see a valid problem or if you are just missing
details. If the first one is the case, please be a bit more elaborative
on the problem.)

Regards,

   Wolfram

-- 
Pengutronix e.K.                           | Wolfram Sang                |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |

Attachment: signature.asc
Description: Digital signature


[Index of Archives]     [Linux GPIO]     [Linux SPI]     [Linux Hardward Monitoring]     [LM Sensors]     [Linux USB Devel]     [Linux Media]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux