Date: Tue, 10 Oct 2017 10:12:43 -0600 From: Ian Lepore <ian@freebsd.org> To: Andriy Gapon <avg@FreeBSD.org>, src-committers@FreeBSD.org, svn-src-all@FreeBSD.org, svn-src-head@FreeBSD.org Subject: Re: svn commit: r323465 - head/usr.sbin/i2c Message-ID: <1507651963.84167.37.camel@freebsd.org> In-Reply-To: <4c4a916f-9960-6d7f-3389-37b998ba980b@FreeBSD.org> References: <201709112149.v8BLncAs049328@repo.freebsd.org> <4c4a916f-9960-6d7f-3389-37b998ba980b@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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. In that situation, there is more harm in being told there are no working devices on the bus when in fact everything is fine, than there is some some hypothetical device doing some hypothetical "bad thing" in response to a read command. In all my years of working with i2c stuff I've never seen a device doing anything more harmful than hanging the bus, requiring a reset (and even causing that requires worse behavior than an unexpected read). On the other hand, I've seen a lot of people frustrated that i2c -s on freebsd says there are no devices, while the equivelent command on linux shows that everything is fine. -- Ian
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1507651963.84167.37.camel>