[RFC PATCH linux dev-4.10 0/7] Add fast rotor reads to MAX31785

[Andrew Jeffery]

On Mon, 2017-06-05 at 15:31 +0930, Joel Stanley wrote:
> > On Fri, Jun 2, 2017 at 3:52 PM, Andrew Jeffery <andrew at aj.id.au> wrote:
> > Hello,
> > 
> > I've dodgied up this series with a patch to the i2c core to make the fast rotor
> > read documented in [1] work. Thus, it's an RFC series. Further, the fast rotor
> > values are zero on the machine I was testing against. Maybe I need to broaden
> > my horizons and test against more machines, but I figured I'd send the patches
> > to get some "internal" feedback.
> > 
> > Timothy's original patch is reworked against the new hwmon kernel APIs. The
> > rework made it easier to support both the 0x3030 and 0x3040 firmwares for the
> > approach I took, though maybe there is a better way with using the hwmon
> > attribute visibility modes. Further, it's still not a pmbus driver, so it's
> > probably not yet acceptible upstream despite the fact that upstream still
> > doesn't support fan control in the pmbus core.
> 
> Looks good.
> 
> I suggest we send it upstream with patches 1, 3, 4, 6 squashed into
> one. Make sure we retain Timothy's copyright in the header.

Yep, it doesn't make sense to upstream the exploded series. I'll squash
things down and rework as below.

> 
> Instead of using your i2c DWORD hack, use i2c_master_recv to do your
> four byte transfer.

Yes, I'll give this a go. Quirky (I2C, not SMBus) code for quirky
behaviour seems reasonable, and less hacky than inventing non-standard
transfer types.

>  Call out in a comment or your commit message that
> the smbus spec doesn't define a 4 byte transfer, but the device needs
> it.

Will do.

Cheers,

Andrew
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: This is a digitally signed message part
URL: <http://lists.ozlabs.org/pipermail/openbmc/attachments/20170605/b0d260f8/attachment.sig>