Hi! I have an issue with a recently purchased I2C sensor that (according to the manufacturer) responds to bus address 0x78. The i2c-tools program i2cdetect only displays addresses in the range 0x03 to 0x77 and i2cdump complains that the address is out of range. Since 0x77 seems pretty arbitrary and strange for a hardware limit (0 bit right in the center), I assumed that the remaining 8 addresses above 0x77 might be reserved for some special use and started digging around in the documentation. Both programs mention the limitations in their manpages but give *no explanation* on why they exist or where those special values came from. i2cdetect seems to have a switch to override this behaviour, but i2cdump doesn't. I found no mentioning of the magic limits in the uapi headers. In fact, a quick git grep revealed that the i2c-tools are sprinkled with *hard-coded* address range checks. I found no mentioning in the kernel documentation either. A quick git grep in the kernel source lead me to i2c-core.c:897 (i2c_check_7bit_addr_validity_strict) where yet another hard-coded address check is performed. The comment above the line states that addresses 0x78-0x7b are used for 10-bit slave addressing. The documentation on 10-bit slave addressing (Documentation/i2c/ten-bit-addresses) says "...The leading 0xa (= 10) represents the 10 bit mode...". Wouldn't such an address on the bus be quite problematic as 0xA has a leading 1 bit (read/write select?). After a quick search on the mailing list, I found a number of messages regarding 10 bit addresses, mentioning _completely_ different address ranges for mapping 10 bit addresses. Since I don't have 10 bit addressed devices on the bus anyway (or anywhere else in the entire building), is there some magic ioctl that I can use to access them? According to the docs, I2C_TENBIT is already off by default? Is there a specific reason I can override i2cdetect but not i2cdump? Thanks, David -- 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
