[i2c] [PATCH] i2c: Fix i2c_smbus_read_i2c_block_data signature

[Mark M. Hoffman]

Hi Jean, et. al.:

* Jean Delvare <khali at linux-fr.org> [2007-05-11 20:31:03 +0200]:
> [Grant, can you please try using this patch and confirm that it's what
> you need for your Dallas DS1682 driver?]
> 
> Let the drivers specify how many bytes they want to read with
> i2c_smbus_read_i2c_block_data(). So far, the block count was
> hard-coded to I2C_SMBUS_BLOCK_MAX (32), which did not make much sense.
> Many driver authors complained about this before, and I believe it's
> about time to fix it. Right now, authors have to do technically stupid
> things, such as individual byte reads or full-fledged I2C messaging,
> to work around the problem. We do not want to encourage that.
> 
> I even found that some bus drivers (e.g. i2c-amd8111) already
> implemented I2C block read the "right" way, that is, they didn't
> follow the old, broken standard. The fact that it was never noticed
> before just shows how little i2c_smbus_read_i2c_block_data() was used,
> which isn't that surprising given how broken its prototype was so far.
> 
> There are some obvious compatiblity considerations:
> * This changes the i2c_smbus_read_i2c_block_data() prototype. Users
>   outside the kernel tree will notice at compilation time, and will
>   have to update their code.
> * User-space has access to i2c_smbus_xfer() directly using i2c-dev, so
>   the change affects tools such as i2cdump. This isn't necessarily a
>   bad thing, as the broken i2c_smbus_read_i2c_block_data() prototype
>   was also hindering user-space applications, so we should update
>   i2c-dev.h in the same way. I've added a size check in i2c-dev to
>   catch and reject I2C block reads with invalid sizes. This seems to
>   be the best way to have people notice the change and update their
>   user-space code. Worst thing that can happen is a short read
>   (i2c_smbus_read_i2c_block_data() returning less bytes than the
>   caller expected), but actually I doubt any other application was
>   using it anyway.

(summary of May 12, 2007 IRC conversation between Jean and myself)

This patch very subtly breaks the existing userspace interface (through the
i2c-dev ioctl), and I objected to that.  Rather than modify the behavior of
ioctl cmd #6, I counter-proposed to add a new ioctl cmd #8, with the desired
behavior (additional len argument).  The in-kernel interface change is OK,
of course.

Jean has asked me to prepare a new patch; so if there's no objection to that
plan, I'll send one shortly.

Regards,

-- 
Mark M. Hoffman
mhoffman at lightlink.com