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

[Jean Delvare]

David,

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. In fact we sure hope
that chips do _not_ follow the SMBus semantics for zero-length
messages, and fortunately I yet have to see any chip which does.

> That doesn't mean that there aren't a fair number of I2C systems that
> can be viewed as fully supporting SMBus.  It just means that it's not
> safe to assume that I2C support always implies SMBus support.  That's
> true at the electrical level (voltage, rise/fall, clocking, etc), so
> pointing that out doesn't change much -- except unwise assumptions.

We do not assume that I2C support implies full SMBus support. This is
why each bus exports a functionality bitfield, and we have a
functionality flag for I2C (I2C_FUNC_I2C) and a functionality flag for
_each_ SMBus transaction type and feature. Bus drivers must set these
flags appropriately. Chip drivers must check for availability before
using any functionality.

> > I pretty much doubt that systems branded "I2C" need to support any
> > semantics at all, given that the I2C specification doesn't have such
> > semantics in the first place.
> 
> While that's probably true, it doesn't relate to the point I made:
> that unless a system says it conforms to SMBus, using SMBUS_QUICK
> isn't guaranteed to work.  (And thus, I2C-only systems shouldn't be
> assuming those transactions will always work ...)

Using the SMBus quick command isn't guaranteed to work even for non-I2C
SMBus masters. For example I have an evaluation module from TAOS on my
desk at the moment, which only supports the following SMBus transaction
types:
* Receive Byte
* Send Byte
* Read Byte
* Write Byte
No Quick Command, as you can see, despite the fact that this is an SMBus
master and not an I2C master.

> > So again I fail to see how the 
> > zero-length transaction, aka SMBus quick command, is special in that
> > respect, other than in your personal experience that some bus master
> > chips happen to not support it (which can be explained by the simple
> > fact that a zero-length command seems useless at first sight.)
> 
> It's special in one key respect:  the current "I2C" core is relying
> on SMBUS_QUICK, which I2C systems aren't guaranteed to support.  That
> is another reason these driver model patches matter:  they help the
> I2C stack work with systems that don't support SMBUS_QUICK.

The i2c core is relying on the SMBus Quick command for chip detection
only. You do not have to use chip detection if you don't want to,
therefore we do not impose that I2C busses support the Quick command.
And again this has little to do with I2C vs. SMBus. Most but not all
SMBus masters implement the SMBus quick command. Most but not all I2C
masters support zero-length messages.

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."

And that's about it. It has nothing to do with SMBus vs. I2C, neither
with semantics. Whether is was a good idea to use zero-length messages
to probe for chip presence is an different issue. I already changed
user-space tools to use one-byte reads (SMBus Receive Byte) instead for
some addresses, and plan to do the same in i2c-core someday. Also, we
could fallback to Receive Byte for all addresses on busses which do not
support zero-length messages. This was on my to-do list for a long
time, but hopefully your patches will make that change unnecessary.

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.

> There are probably other SMBus things that an I2C-only system will
> not handle all that well, but I've not looked at it in detail.  (The
> broadcast and interrupt mechanisms come to mind.)

Broadcast is part of the I2C specification (it's called a "general
call"). The SMBus alert line is not, but there's nothing preventing an
I2C system from using a GPIO pin for that purpose.

-- 
Jean Delvare