[i2c] [patch 2.6.23-rc5 2/2] i2c-algo-bit read block data bugfix

[David Brownell]

> > This fixes a bug in the way i2c-algo-bit handles I2C_M_RECV_LEN,
> > used to implement i2c_smbus_read_block_data().  Previously, in the
> > absence of PEC (rarely used!) it would NAK the "length" byte:
> > 
> > 	S addr Rd [A] [length] NA
> > 
> > That prevents the subsequent data bytes from being read:
> > 
> > 	S addr Rd [A] [length] { A [data] }* NA
> > 
> > The primary fix just reorders two code blocks, so the length used
> > in the "should I NAK now?" check incorporates the data which it
> > just read from the slave device.
> > 
> > However, that move also highlighted other fault handling glitches.
> > This fixes those by abstracting the RX path ack/nak logic, so it
> > can be used in more than one location.  Also, a few CodingStyle
> > issues were also resolved.
>
> Most of which I'll have to back out as I want this patch to be as small
> as possible: I intend to get it in 2.6.22-stable.

OK, though you'd asked for at least one of them.   You're right
that this would be a good candidate for the stable series.  For
some reason I don't find those very often, so I'm out of practice
for that level of patch minimization.  :)


> > +static int acknak(struct i2c_adapter *i2c_adap, u8 byte, int is_ack)
>
> The "byte" parameter is not used.

Yeah, debris from an earlier patch iteration where a diagnostic
moved along with that logic; good riddance.


> I've cleanups up both problems myself, and here is for reference the
> patch I'll be pushing to Linus:

Looked fine, and not so different from what I sent.

FYI I tried the version I sent against that broken PMBus firmware
and it actually behaved sanely in a few cases.  I suspect there are
(at least) two bugs in that firmware, and one of them was making
the bug addressed by this patch cause a lot more breakage.  Reading
the desired block twice seems to give sane results.

- Dave