[lm-sensors] [patch 2.6.23-rc6] lm75: new-style i2c binding, cleanup

[David Brownell]

> This is crying for at least two separate patches, and ideally more like
> 3 or 4.

This will be followed by three patches:

 - Cleanups, minor reorg, Kconfig update ... no functional changes

 - Support for new-style driver binding.

 - Use 12-bit resolution where it's available.


> Additionally, I can't apply your patch to my tree. Presumably you are
> missing recent patches that went into Mark's hwmon-testing tree and
> which affect the lm75 driver:
>
> hwmon: Allow writing of negative trigger temperatures
> http://lm-sensors.org/kernel?p=kernel/mhoffman/hwmon-2.6.git;a=commit;h=a1efde3fd7b3d94c942b1a675da992c8a2f1f04b
>
> hwmon: Convert from class_device to device
> http://lm-sensors.org/kernel?p=kernel/mhoffman/hwmon-2.6.git;a=commit;h=f89523a27def89ddc74d094a0910970f6a1c6f43
>
> If you split your patch and make sure that the result applies on top of
> the above patches, I'll be happy to review and test your work.

They're on top of those, as modified to apply against rc8 (various
changes in non-lm75 code prevent those from applying).


> > The way to kick in higher sample resolution on a given board is to
> > use the new style binding to pass in the chip type.
> > 
> > One temporary omission:  IRQ support, or for the TI chips SMBALERT#
> > notifications.

Turns out that it's not just the TMP75/175/275 chips that understand
SMBALERT# and respond to the alert response address ... TMP101 too,
but not the TMP100.

Of course, from what I see so far, hwmon doesn't have any way to get
async notifications to userspace.  A "temp1_max_alarm" attribute
would need constant polling, and it's not clear quite when it'd clear.
Likewise with "temp1_min_alarm".

- Dave