Hi Wolfram,

On Mon, 11 Mar 2019 23:33:35 +0100, Wolfram Sang wrote:
> The I2C standard reserves addresses 0x03-0x07. Adapt our tools to that.

I have a different interpretation of the specification. Addresses
0x04-0x07 are marked as "Hs-mode master code". They are not explicitly
marked as "reserved" (although admittedly the table is named "Reserved
addresses"). My understanding is that HS-mode will "use" these
addresses, which means that you can't use HS-mode _and_ slaves at
addresses 0x04-0x07 on the same I²C bus segment. I do not read this as
"non-HS-mode slaves can't use these addresses". But maybe this is just
me, and also I don't know that much about HS-mode really.

Address 0x03 is indeed reserved, so obviously that this really makes me
wonder how the original range of 0x03-0x77 was decided. Unfortunately
the git history doesn't go that far (this range was already used in
i2cget and i2cdetect at the time i2c-tools was split to its own
repository). But I was able to dig out an old lm-sensors commit:

commit e1c8fe76763bfa7e9261a5a024755d2274a8b14b
Author: Mark D. Studebaker
Date:   Sat Mar 20 17:23:31 2004 +0000

    scan address 0x03 again
    
    
    git-svn-id: http://lm-sensors.org/svn/lm-sensors/trunk@2377 
7894878c-1315-0410-8ee3-d5d059ff63e0

diff --git a/prog/detect/i2cdetect.c b/prog/detect/i2cdetect.c
index 43bb704265ac..8d96591493aa 100644
--- a/prog/detect/i2cdetect.c
+++ b/prog/detect/i2cdetect.c
@@ -159,7 +159,7 @@ int main(int argc, char *argv[])
   for (i = 0; i < 128; i+=16) {
     printf("%02x: ",i);
     for(j = 0; j < 16; j++) {
-      if (!force && (i+j<0x04 || i+j>0x77)) {
+      if (!force && (i+j<0x03 || i+j>0x77)) {
         printf("   ");
         continue;
       }
diff --git a/prog/detect/sensors-detect b/prog/detect/sensors-detect
index adc6ef2f2fb9..2aa0575ce7b3 100755
--- a/prog/detect/sensors-detect
+++ b/prog/detect/sensors-detect
@@ -2418,7 +2418,7 @@ sub scan_adapter
   binmode FILE;
 
   # Now scan each address in turn
-  foreach $addr (0x04..0x77) {
+  foreach $addr (0x03..0x77) {
     # As the not_to_scan list is sorted, we can check it fast
     if (@not_to_scan and $not_to_scan[0] == $addr) {
       shift @not_to_scan;

Unfortunately no rationale in the log message, so this does not tell us
why address 0x03 was rehabilitated. I can only speculate that someone
had an actual device responding to address 0x03 back then.

That being said... In the end it doesn't really matter if addresses
0x03-0x07 are considered reserved but "should not", as long as the user
has an option to override that limitation. Now that such an option is
consistently available for all i2c tools, I have no objection to being
more conservative by default.

Thanks,
-- 
Jean Delvare
SUSE L3 Support

Reply via email to