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

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

Wolfram Sang said the following:
...
>> 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.
> 
Especially it is ugly that devices which are mentioned in DTS but are
not present (because the component isn't plugged in or powered) get an
directory entry in /sys/bus/i2c/devices with bind, unbind, ...
This is my 'problem': I search for a clean way to instantiate on demand
with no zombies in case of missing H/W. I know there are problems in
identification of devices, but to remove all possibilities to try it
seems not a good way for me.

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

I am new in the sense that I jumped in at 2.4 making some non
i2c-drivers, rejoind at 2.6.24 for i2c-drivers and a non i2c-driver.
Currently I try to catch up to current state to prepare management of
all i2c-devices on our next project.

Even i2c_board_info needs to be filled in and passed to subsystem via a
function call. Which part of kernel is supposed to do that without
changing code beside board specific configuration files?
(I do really mean this as a question.)

-- 
Kind regards,
Michael