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

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

Jon Smirl said the following:
> On Fri, Apr 24, 2009 at 6:53 AM, Michael Lawnick <ml.lawnick-Mmb7MZpHnFY@public.gmane.org> wrote:
>> 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.
> 
> You might want to ask about this on the linux-ppc mailing list.

I can't see how they should be able to help me more than this list.
> 
> You're stuck because i2c hardware does not support hotplug. Since the
> hardware doesn't support hotplug there's no software support for it in
> the kernel. So you want to fall back to polled probing.

That's what I do. But being able to detect a new device via /dev/i2c is
only halve of the job. The device needs to be identified and a client
instantiated. Doing this job in the user space polling program would
double the code, as detection is already done in the drivers.
> 
> But probing is bad because it isn't standardized and coordinated, one
> device's probe can cause another device to destroy things (like set a
> voltage too high on a motherboard). Because of this probing can't be
> turned on in general.

That's not the problem. The problem is, that in current code state it is
not possible at all to do proper probing on MPC85xx architecture, even
if the possible I2C devices / bus layout would allow it. You must force
instantiation, so if the driver detects an error on .probe and stops,
you have dead entries in sysFs. This would not be the case if there
would be a way to go via .detect
> 
> It's possible to get to the i2c bus from user space. You could write a
> user space app that polls in your controlled environment.

As said above, this is already done in this way.

> When you
> detect the new devices you can load the appropriate modules. Now you
> need to instantiate these new devices.

The modules are already loaded, there is missing a proper way to start
instantiation of *new* clients.
> 
> Jean, is it still possible to instantiate i2c devices from the module
> command line?

This question is missing the point. The module is already up and
running. The situation to handle is that there is powered-on a device
after module load. Now a client for this device needs instantiation. As
code for detection of client-type should IMHO not be part of user space
(as it *is* already part of drivers) I am currently fighting for a way
to trigger a driver's detect function.

--
Kind regards,
Michael