svn commit: r323465 - head/usr.sbin/i2c

[Ian Lepore]

On Tue, 2017-10-10 at 19:23 +0300, Andriy Gapon wrote:
> On 10/10/2017 19:12, Ian Lepore wrote:
> > 
> > On Tue, 2017-10-10 at 17:45 +0300, Andriy Gapon wrote:
> > > 
> > > On 12/09/2017 00:49, Ian Lepore wrote:
> > > > 
> > > > 
> > > > Author: ian
> > > > Date: Mon Sep 11 21:49:38 2017
> > > > New Revision: 323465
> > > > URL: https://svnweb.freebsd.org/changeset/base/323465
> > > > 
> > > > Log:
> > > >   Make i2c -s (device scan) work on hardware that supports only full xfers.
> > > >   
> > > >   The existing scan code is based on sending an i2c START condition and if
> > > >   there is no error it assumes there is a device at that i2c address.  Some
> > > >   i2c controllers don't support sending individual start/stop signals on the
> > > >   bus, they can only perform complete data transfers with start/stop handled
> > > >   in the silicon.
> > > >   
> > > >   This adds a fallback mechanism that attempts to read a single byte from each
> > > >   i2c address.  It's less reliable than looking for an an ACK repsonse to a
> > > >   start, because some devices will NAK an attempt to read that isn't preceeded
> > > >   by a write of a register address.  Writing to devices to probe them is too
> > > >   dangerous to even consider.  The user is told that a less-reliable scan is
> > > >   being done, so even if the read-scan comes up empty too, it's still a vast
> > > >   improvement over the old situation where it would just claim there were no
> > > >   devices on the bus even though the devices were there and working fine.
> > > >   
> > > >   If the i2c controller responds with a proper ENODEV (device doesn't support
> > > >   operation) or an almost-proper EOPNOTSUPP, the START/STOP scan is switched
> > > >   to a read-scan right away.  Most controllers respond with ENXIO or EIO if
> > > >   they don't support START/STOP, so no quick-out is available.  For those,
> > > >   if a scan of all 127 addresses and come up empty, the scan is re-done using
> > > >   the read method.
> > > Perhaps the new scan method should have been added as a separate option that has
> > > to be explicitly activated...  My concern is that there are some extremely
> > > simple I2C devices out there that do no sanity checking and may get confused
> > > 
> > i2c -s is not a thing that's done routinely in a production system or
> > normal system operations... it's something a person does manually when
> > trying to configure or debug a system.
> Right.  And another point, it's not extremely hard to type another option on the
> command line.  I haven't suggested that the functionality should not have been
> added at all, I have just suggested adding a new option to unlock it.
> 

This conversation is making me think harder about what's happening on
the bus during the two different kinds of scans, and I'm realizing the
answer is "almost exactly the same thing in both cases".

A "normal" scan is a START, followed by 9 clocks during which the slave
address is put on the bus and either an ACK or NAK happens, followed by
a STOP.

A new-style "read" scan is a START, followed by 9 clocks during which
the slave address is put on the bus and either an ACK or NAK happens,
followed by 9 more clocks for transferring a byte+NAK, followed by a
STOP.

So the entire difference is 9 extra clocks, in terms of bus behavior.
 Operationally, the slave device already indicated a willingness to
service a read operation when it ACK'd its address following the start.

Actually doing the read shouldn't put the device into a bad state, but
I guess we could theorize it might... maybe it likes to work in 16-bit
chunks and a STOP after 8 bits confuses it.  But before the stop comes
a NAK from the master which says "I don't want to read anymore" and if
that confuses the device, it's violating the protocol.

All in all, I'm now wondering if what should change is removing the
wording about the read-based scan being somehow "less reliable", I
don't think it really is.

-- Ian