[smartmontools-support] [PATCH v5] scsi: Add hwmon support for SMART temperature sensors

[Hannes Reinecke]

On 10/7/18 10:49 PM, Linus Walleij wrote:
> S.M.A.R.T. temperature sensors have been supported for
> years by userspace tools such as smarttools. This adds
> support to read it from the kernel and adds a temperature
> zone for the drive.
> 
> The temperature readout is however also a good fit for
> Linux' hwmon subsystem. By adding a hwmon interface to dig
> out SMART parameters, we can expose the drive temperature
> as a standard hwmon sensor.
> 
> The idea came about when experimenting with NAS enclosures
> that lack their own on-board sensors but instead piggy-back
> the sensor found in the harddrive, if any, to decide on a
> policy for driving the on-board fan.
> 
> The kernel thermal subsystem supports defining a thermal
> policy for the enclosure using the device tree, see e.g.:
> arch/arm/boot/dts/gemini-dlink-dns-313.dts
> but this requires a proper hwmon sensor integrated with
> the kernel.
> 
> With this driver, the hard disk temperatur can be read from
> sysfs:
> 
>   > cd /sys/class/hwmon/hwmon0/
>   > cat temp1_input
>   38
> 
> If the harddrive supports one of the detected vendor
> extensions for providing min/max temperatures we also
> provide attributes for displaying that.
> 
> This means that they can also be handled by userspace
> tools such as lm_sensors in a uniform way without need
> for any special tools such as "hddtemp" (which seems
> dormant).
> 
> This driver does not block any simultaneous use of
> other SMART userspace tools, it's a both/and approach,
> not either/or.
> 
> Reviewed-by: Guenter Roeck <linux at roeck-us.net> # HWMON
> Signed-off-by: Linus Walleij <linus.walleij at linaro.org>
> ---
Hmm. I might be getting something wrong here, but the main problem with 
SMART values is that they are _not_ really standardized; plus any drive 
is free to implement whatever they want.
Plus there are tons of SMART attribute values, and decoding just one 
seems to be a bit poor. At the same time having them in the kernel will 
just require us to implement lots of decoding, which I really would 
leave to userland.
So overall I'm not sure if that the right approach.

Cheers,

Hannes
-- 
Dr. Hannes Reinecke		   Teamlead Storage & Networking
hare at suse.de			               +49 911 74053 688
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton
HRB 21284 (AG Nürnberg)