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