On 2019-04-16 22:47, Jean Delvare wrote: > Hi Peter, > > On Tue, 16 Apr 2019 19:45:10 +0000, Peter Rosin wrote: >> If there is some other device responding to 0x36/0x37, then it didn't >> respond in the first (elided) dump with no ee1004 driver bound. So, that >> seems unlikely. No? >> >> For reference the elided dump I referred to was: >> >>> [root:/sys/bus/i2c/devices] # i2cdetect 2 >>> WARNING! This program can confuse your I2C bus, cause data loss and worse! >>> I will probe file /dev/i2c-2. >>> I will probe address range 0x03-0x77. >>> Continue? [Y/n] y >>> 0 1 2 3 4 5 6 7 8 9 a b c d e f >>> 00: -- -- -- -- -- 08 -- -- -- -- -- -- -- >>> 10: -- -- -- -- -- -- -- -- 18 -- 1a -- -- -- -- -- >>> 20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- >>> 30: 30 31 -- -- 34 35 -- -- -- -- -- -- -- -- -- -- >>> 40: -- -- -- -- 44 -- -- -- -- -- -- -- -- -- -- -- >>> 50: 50 -- 52 -- -- -- -- -- -- -- -- -- -- -- -- -- >>> 60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- >>> 70: -- -- -- -- -- -- -- -- >> >> But why is there no response for those addresses when there is no >> driver bound? Will they only ack writes or something? I don't know >> anything about these DDR4 SPDs... > > For range 0x30-0x37, i2cdetect uses read commands for probing. > 0x37 is a write-only address for the EE1004 standard, so it doesn't > have to ack reads. 0x36 is special, as a read command it returns the > currently selected page, but uses the ack to answer (page 0 or page 1) > instead of acking and answering in an actual payload. If you ask me it > is VERY BAD design, and it is very sad that whoever came up with that > part of the EE1004 standard had too little experience to realize that > saving a few bytes for this command was really not worth the clumsy > design. The ack bit has a meaning and should never be abused like that. Sigh, designers who think they are "creative" are a nuisance. Or worse. Anyway, thanks for the background! Cheers, Peter
