[U-Boot] [RFC] Make i2c probe opt-outable?

[Mike Frysinger]

On Friday 18 May 2012 12:11:57 Tom Rini wrote:
> On 05/17/2012 07:48 PM, Mike Frysinger wrote:
> > On Thursday 17 May 2012 14:43:45 Tom Rini wrote:
> >> I'd like to propose making 'i2c probe' be a command that is
> >> opt-out'able.  In the Linux Kernel the notion of probing for devices was
> >> abandoned a while ago due to, in short, devices misbehaving when
> >> randomly poked at.  Over in omap24xx_i2c land we changed our probe
> >> method a while ago from an attempted read to an attempted write as some
> >> i2c devices would NAK the read.  But now with the am33xx SoM family we
> >> have a new issue which is that attempting to write to an address doesn't
> >> immediately issue a NAK so probe sees all addresses as valid and in turn
> >> leaves the bus upset.  I've worked around this for now by making
> >> i2c_probe use the read method instead, only on am33xx (so most devices
> >> would be spotted, but the ones that caused the initial change would not
> >> show up).  But a possibly better solution is to just make the i2c probe
> >> command not implemented for am33xx (as you don't have to run i2c probe
> >> to try and use your device).
> > 
> > i've always seen the "i2c probe" command as a debugging tool, not
> > something that you need to do to make things work.  so along those
> > lines, isn't it already optional ?  if you don't like it, don't run it
> > :).
> 
> Including a command that doesn't work and saying "ah, just don't use
> that" is asking for trouble.  I'm going down the "what changed in the IP
> block, really" rat-hole now (since I've got the original test working).

there's plenty of commands in u-boot which are dangerous and should not be run 
lightly.  i'm not sure we should special case this.

>   But still, the kernel decided i2c probing is dangerous/unreliable,
> maybe we should follow, or at least allow boards to follow?

i don't think "dangerous" is quite right, but certainly it's unreliable 
because i2c clients are dirt cheap and they aren't required by the protocol to 
be terribly sane.  plenty of device drivers do probing once they've been told 
to connect to a specific address, but that's been gated somewhat.

also, the counter point is that the kernel still *allows* you to probe the 
entire i2c bus regardless of it being dangerous.  the i2c-tools package is 
awesome for doing this sort of thing: probing an entire bus, attempting to 
dump register addresses of slaves en mass, etc...
	http://www.lm-sensors.org/wiki/I2CTools
personally, i've used the "i2c probe" command before and found it very useful.
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20120518/960c7121/attachment.pgp>