[i2c] [patch 3/5] i2c probe() and remove(), documented at last

[David Brownell]

On Saturday 03 March 2007 10:47 am, Jean Delvare wrote:
> On Fri, 2 Mar 2007 13:30:52 -0800, David Brownell wrote:
> > Right.  So unless you have a system that explicitly claims to support
> > those added SMBus semantics (e.g. all its chips support them), it's not
> > safe to depend on them.
> 
> We do not depend on SMBus semantics in i2c-core.

That's half-true.  Drivers that don't use the SMBus probe mechanism
by default are pretty scarce, and the manual configuration scheme
(by kernel command line or module options) is error prone.  But yes,
one can put together systems that bypass it.  Not many folk do that,
because i2c-core makes it so awkward not to use SMBus probing.


> Summary:
> 
> "The i2c core currently relies on zero-length messages, also known as
> SMBus quick command, to probe for chip presence at a given address. Not
> all busses support such messages, therefore chip presence detection is
> not possible on all busses."

Fair enough.


> I do agree with you that your patches will make dealing with
> non-detectable devices easier. But it will not only be useful for the
> few busses which do not support zero-length messages. It will also be
> useful for all chips which we cannot identify and/or configure by
> probing, regardless of the bus they are connected to.

Absolutely.  I never said it mattered _only_ for systems where the
SMBUS_QUICK command is unavailable.  It also helps get rid of lots
of board-specific logic in I2C device drivers, because it provides
robust ways to deliver platform-specific configuration; and shrinks
drivers, by letting all those large module parameter arrays vanish.

Plus it helps remove the cognitive dissonance of a driver binding
model unlike anything else in Linux.  :)

- Dave