24rf08 update

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Good work guys!  Nice to have narrowed it down to a broken I2C 
implementation on a particular chip.  Detection has always been 
difficult task to make absolutely safe.

It also seems to match what Joe from Australia described, and what we 
were suspecting.

So to recap (from my understanding of where we stand), is this true?

- The only corruption that happens with this chip is in 
  sensors-detect?

- If sensors-detect is run to avoid 0x54-0x58, the problem is avoided?

- We have a working patch for sensors-detect which works identically 
  as before, but avoids the corruption (and detects the chip 
  as eeproms)?

- The regular eeprom.o driver does not corrupt the chip, and works 
  as expected?

- There are no complications with the 'protection' address of the chip 
  and probing?


Phil

On Sun, Sep 01, 2002 at 10:12:26PM -0400, Mark D. Studebaker wrote:
> yes. I get it, makes sense now.
> 
> Ky?sti M?lkki wrote:
> > 
> > On Sun, 1 Sep 2002, Mark D. Studebaker wrote:
> > 
> > > Ky?sti M?lkki wrote:
> > >
> > > > Two successive Write Quick "0" become Write Byte, only changing the
> > > > reference for Read Byte transactions. This is i2cdetect operation and
> > > > causes no corruption.
> > > >
> > > > S 0x54 Wr [A] <P><S> 0x55 Wr [A] P
> > > >
> > > > If this is the case, latter of the two Write Quick commands is always
> > > > acknowledged by 24rf08, and does not reflect a client at that address.
> > > >
> > > If this were the case I would not get a detection at 0x54 and I would
> > > get a detection at 0x58. But I correctly get a detection at 0x54-0x57.
> > > This is true whether I use Write Quick "0" or Write Quick "1".
> > 
> > You would get a detection at 0x54, since at that point 24rf08
> > acknowledges its address. You would not get a detection at 0x58, since
> > there was an even number of Write Quicks.
> > 
> > Scan range 0x57 to 0x58.
> > 
> > --
> >   Ky?sti M?lkki
> >   kmalkki at cc.hut.fi

-- 
Philip Edelbrock -- IS Manager -- Edge Design, Corvallis, OR
   phil at netroedge.com -- http://www.netroedge.com/~phil
 PGP F16: 01 D2 FD 01 B5 46 F4 F0  3A 8B 9D 7E 14 7F FB 7A



[Index of Archives]     [Linux Kernel]     [Linux Hardware Monitoring]     [Linux USB Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Yosemite Backpacking]

  Powered by Linux