[i2c] Adaptive adapter name?

[Jean Delvare]

Hi Till,

On Sat, 4 Nov 2006 00:37:27 +0100 (MET), Till Harbaum wrote:
> On Friday 03 November 2006 11:22, Jean Delvare wrote:
> > A simple test would be to not load any hardware monitoring driver, only
> > your i2c bus driver, and use i2cdetect (and the i2c-dev driver) to
> > probe the bus before and after unplugging/replugging it. If probing
> > fails the second time, it means your bus driver doesn't properly
> > support hotplug. I can't say more without seeing the actual code,
> > though.
>
> Hm, actually something changes. Before it reads:
> 
> ...
> 40: XX XX XX XX XX XX XX XX UU XX XX XX XX XX XX XX
> ...
> 
> and after being unplugged and replugged:
> 
> ...
> 40: XX XX XX XX XX XX XX XX 48 XX XX XX XX XX XX XX
> ...
> 
> But the man page unfortunately doesn't tell me about the difference. Maybe
> the UU means "un use" or so.

The manual page was updated recently to describe the output convention:

--- 8< ---
INTERPRETING THE OUTPUT
       Each  cell  in  the output table will contain one of the following sym-
       bols:

       - "XX". The address was probed but no chip answered.

       - "UU". Probing was skipped, because this address is currently  in  use
         by  a  driver.  This  strongly  suggests that there is a chip at this
         address.

       - An address number in hexadecimal, e.g. "2d" or "4e". A chip was found
         at this address.
--- 8< ---


> I have investigated this further and i found out, that after replugging the 
> interface i have to unload and reaload the ds1621 module to make
> it visible to sensors again.
> 
> Hmm, shouldn't this work automatically?

It should. The i2c chip drivers should detach when the bus disappears,
and attach again then it comes back. And it is supposed to work, but
from the output above, it's clear that at least the second doesn't
happen for you.

Try cycling the bus driver instead of physically unplugging the USB
adapter. It should be the same from the chip driver's point of view, so
it'll be interesting to see what happens.

Then you can add some printks in the i2c chip driver in the client
attach and detach functions, to see exactly what's called. You can also
enable i2c core debugging, so that we get the core's view of what's
happening.

Once again, without seeing your code, I can only speculate.

-- 
Jean Delvare