Sensor with 7 bit address above 0x77

Sensor with 7 bit address above 0x77

[David Oberhollenzer]

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

Re: Sensor with 7 bit address above 0x77

[Wolfram Sang]

[-- Attachment #1: Type: text/plain, Size: 1139 bytes --]


> Both programs mention the limitations in their manpages but give *no explanation* on why they
> exist or where those special values came from.

That could be added to them. But the first thing to look for such
information is still the I2C specification which has a section about
reserved addresses.

> 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?).

Please read the above specification to understand how 10 bit addresses
are transferred over the wire. I think reading it will answer most of
your questions.

> Is there a specific reason I can override i2cdetect but not i2cdump?

Probably not. More likely, nobody needed it until now. Which is
understandable since the device you have has to be considered broken
regarding the I2C standard. But I think patches adding that could be
acceptable. Jean has the last word on this.


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: Sensor with 7 bit address above 0x77

[David Oberhollenzer]

On 06/27/2016 02:13 PM, Wolfram Sang wrote:
> Please read the above specification to understand how 10 bit addresses
> are transferred over the wire. I think reading it will answer most of
> your questions.

Wikipedia brought me to this PDF file here:
http://www.nxp.com/documents/user_manual/UM10204.pdf

Section 3.1.11 "10-bit addressing" along with section 3.1.12 "Reserved
addresses" indeed specify that the 7 bit addresses 0x78-0x7B are reserved
for 10 bit addressing.

The way it is written in the spec (1111 0XX) probably caused people to
confuse it for 0xF0-0xF3 which I found in some messages on the mailing
list.

But that still leaves the question of where the 0xA... in the kernel docs
came from.


>> Is there a specific reason I can override i2cdetect but not i2cdump?
> 
> Probably not. More likely, nobody needed it until now. Which is
> understandable since the device you have has to be considered broken
> regarding the I2C standard. But I think patches adding that could be
> acceptable. Jean has the last word on this.
> 

Section 3.1.12 ends with some musings about the assignment of addresses in
"local systems". More specifically, it ends with the sentence "If it is known
that the reserved address is never going to be used for its intended purpose,
a reserved address can be used for a slave address."

I _do_ know that there are no 10 bit addressed slaves in my application, so
the spec allows me to use at those 4 slave address. Apparently it is not my
device that is broken.

Re: Sensor with 7 bit address above 0x77

[Wolfram Sang]

[-- Attachment #1: Type: text/plain, Size: 1279 bytes --]


> The way it is written in the spec (1111 0XX) probably caused people to
> confuse it for 0xF0-0xF3 which I found in some messages on the mailing
> list.

Yes, it always causes confusion if the R/W bit is part of the address or
not.

> But that still leaves the question of where the 0xA... in the kernel docs
> came from.

less Documentation/i2c/ten-bit-addresses

> Section 3.1.12 ends with some musings about the assignment of addresses in
> "local systems". More specifically, it ends with the sentence "If it is known
> that the reserved address is never going to be used for its intended purpose,
> a reserved address can be used for a slave address."
> 
> I _do_ know that there are no 10 bit addressed slaves in my application, so
> the spec allows me to use at those 4 slave address. Apparently it is not my
> device that is broken.

For your specific case, I agree. For the generic case, I don't. Maybe
the word "broken" is too much, though, how about calling it "risky"?
That being said, as I mentioned before, I think patches adding support
for using "risky" addresses in i2c-tools are acceptable, so no
show-stopper here.

Can you share which device uses the address 0x78? I'd like to add it to
my list of "interesting I2C devices".


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]