i2cdetect -l is broken

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

 



> > i2cdetect -l is broken on drivers which handle more than a single
> > i2c bus (radeonfb in my case). It'll print the same name for all
> > busses, and shouldn't.
> > 
> > I took a look at the sysfs tree and I couldn't find any way to
> > correct it. The fact that i2c-adapters and i2c-devs don't use the
> > same numbering policy doesn't give us much chance.
> 
> But what about the linkages:
> 
> $ tree /sys/class/i2c-dev/
> /sys/class/i2c-dev/
> `-- i2c-0
>     |-- dev
>     |-- device -> ../../../devices/platform/i2c-0
>     `-- driver -> ../../../bus/i2c/drivers/i2c_adapter
> 
> $ tree /sys/class/i2c-adapter/
> /sys/class/i2c-adapter/
> `-- i2c-0
>     |-- device -> ../../../devices/platform/i2c-0
>     `-- driver -> ../../../bus/i2c/drivers/i2c_adapter
> 
> 
> You can match these devices up by looking at the 'device' symlink. 
> This works no matter what numbering scheme there currently is, right?

Yes, it looks like it does. But this requires that we walk both dirs and
compare the entries. Not something easy to do in C, either we introduce
data structures and have to handle memory allocations, or we end up with
a non-linear algorithm.

With our 2.4 system, the same operations was as simple as "cat
/proc/bus/i2c".

> > As far as I can tell, i2c-adapters numbering policy is to use N+1
> > for a new adapter, where N is the biggest number already use at the
> > moment, while i2c-devs numbering policy is to use the lowest
> > available.
> 
> I think this is the same for 2.4, meaning the same problem is there
> too, right?  But for 2.4, you don't have the sysfs linkage to help you
> out. How do you solve the problem there?

I don't know much about the details, and I don't even understand why
there are two series of identifiers, so I can't speeak about that. But
for 2.4, the number given by sensors was also the one you could use in
i2cdump. It never looked like there were two distinct series of
identifiers there. Either they were in sync, or there was only one
series, I can't say. And we have the list in /proc/bus/i2c. No need to
parse a complete tree.

What I see from a user-space developer, user and support-guy point of
view is that this double numbering is a source of problems, and I'd like
to see it solved if possible.

-- 
Jean Delvare
http://www.ensicaen.ismra.fr/~delvare/



[Index of Archives]     [Linux Kernel]     [Linux Hardware Monitoring]     [Linux USB Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Yosemite Backpacking]

  Powered by Linux