> 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
