Hi Wolfram, On Fri, 11 Nov 2011 11:43:35 +0100, Wolfram Sang wrote: > > I can think of 2 different ways of addressing the problem. > > > > First way is to use a different device name format for 10-bit address > > devices, for example %d-10bit-%04x. This has the drawback that some > > user-space applications and libraries may not recognize these as valid > > i2c device names. libsensors and sensors-detect would be amongst these. > > Wouldn't the cleanest solution be > > "%d-%02x" for 7 bit > "%d-%04x" for 10 bit? I'd rather use %03x for 10-bit then, for consistency. > Yeah, I know that would really break userspace. Yes indeed. While it wouldn't break libsensors (which uses sscanf "%hd-%x" to parse the fields), it would break at least sensors-detect, which really expects 4 hex digits in the sysfs name. This would definitely be a change in the user-space interface anyway, who knows which other tools would be affected. Your solution was elegant (although it has its own drawbacks, such as leaving it to every library and application to come up with a creative way to handle and store 10-bit addresses separately from 7-bit addresses internally), but unfortunately it would have had to be implemented in the early days, not 8 years later. > > I'd rather go with a larger offset such as 0x1000. This translates 0x2d > > to 0x102d which is more obviously "10-bit address 0x2d". We have 16 > > bits to store the address so it shouldn't be an issue. Another possible > > offset would be 0xa000 (as 0xa is 10.) > > I like 0xa000 a tad better than 0x1000, but well... Then again, those > devices are probably rare enough to take a non-intrusive approach. Yes I agree, we really want to leave 7-bit addresses unaffected by the change. 0xa000 is not more intrusive than 0x1000, so if the majority - i.e. you ;) - is in favor of this, that's fine with me. I'll send a patch later today. Thanks, -- Jean Delvare -- To unsubscribe from this list: send the line "unsubscribe linux-i2c" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
