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

[David Brownell]

> > The reason I wrote "overlaps" is that while, as you observe, the bits
> > exchanged for SMBUS_QUICK do fit within the I2C space, the semantics
> > assigned to them (by SMBus) are an extension ... not mandatory.  So
> > while there are I2C transactions SMBUS doesn't include, likewise there
> > are SMBUS semantics that I2C doesn't include.
> 
> This is correct, but not specific to the SMBus quick command. I2C
> doesn't have any semantics at all, SMBus adds them at the same time it
> restricts the set of allowed transactions.

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.

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.


> > Another way to put this is to observe that systems branded "I2C" (it's
> > a trademark/brand, not all vendors are licensed to say they conform!)
> > are not required to support SMBUS_QUICK semantics.
> 
> 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 ...)


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

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

- Dave