[i2c] Documentation/i2c/dev-interface

[David Brownell]

> >Where are those defined?  Such functions don't seem to exist
> >in in a library on any of my Linux distros.
>
> These are inline functions defined in i2c-dev.h. This header file (which
> is different from the one in the kernel tree) is currently distributed
> with the lm-sensors package, for historical reasons. This is explained
> at the beginning of $SUBJECT.

Well, not quite at the beginning.  It's clearly wrong to have that
in a <linux/i2c-dev.h> file that's not provided by Linux!  Not just
counter to expectations, but counter to standard policy ... :(


> Soon we'll have a dedicated i2c-tools package and that header file will
> be part of it:
> http://www.lm-sensors.org/browser/i2c-tools/trunk/include/linux/i2c-dev.h

That shouldn't be a <linux/...> file at all, and it should be
including the relevant linux headers (i2c.h, i2c-dev.h) rather
than replicating any of their contents.

For that matter, the ioctl numbers belong in i2c-dev.h not i2c.h!
(Probably not awkward to fix, since anything using i2c-dev.h must
also include the other.)


> As a side note, these functions would probably be better provided as a
> static library, as some of them are a bit too large to be inlined IMHO.

Right.


> But this is not my priority at the moment.
>
> It can be argued that the rest of the file should be generated or
> extracted from the i2c kernel headers themselves, now that we have a
> clean way to do this.

Nope.  It should be argued that the kernel files and the userspace
files should be entirely separate.  In fact, I'm surprised to hear
you argue anything else ...


> >Also, a clear omission is the SMBus "block write-block read
> >process call" primitive...
>
> Most probably because nobody uses it ;) I2C block read and write
> functions are missing as well. Care to submit a patch?

I had one a while back, let me see if I still have a copy.  For
portability I ended up avoiding the block proc call; it was just
needed for some fixed-size transfers, and the important one could
be handled with the (more widely supported) regular proc call.

I do have block read and write code that could be repurposed, but
it uses a slightly different calling convention.  Taking a struct
pointer caches the I2C_FUNCS result, helpful to support 33+ byte
blocks with I2C_RWR when that's needed.

- Dave