1The Linux Hardware Monitoring kernel API 2======================================== 3 4Guenter Roeck 5 6Introduction 7------------ 8 9This document describes the API that can be used by hardware monitoring 10drivers that want to use the hardware monitoring framework. 11 12This document does not describe what a hardware monitoring (hwmon) Driver or 13Device is. It also does not describe the API which can be used by user space 14to communicate with a hardware monitoring device. If you want to know this 15then please read the following file: Documentation/hwmon/sysfs-interface.rst. 16 17For additional guidelines on how to write and improve hwmon drivers, please 18also read Documentation/hwmon/submitting-patches.rst. 19 20The API 21------- 22Each hardware monitoring driver must #include <linux/hwmon.h> and, in some 23cases, <linux/hwmon-sysfs.h>. linux/hwmon.h declares the following 24register/unregister functions:: 25 26 struct device * 27 hwmon_device_register_with_info(struct device *dev, 28 const char *name, void *drvdata, 29 const struct hwmon_chip_info *info, 30 const struct attribute_group **extra_groups); 31 32 struct device * 33 devm_hwmon_device_register_with_info(struct device *dev, 34 const char *name, 35 void *drvdata, 36 const struct hwmon_chip_info *info, 37 const struct attribute_group **extra_groups); 38 39 void hwmon_device_unregister(struct device *dev); 40 41 char *hwmon_sanitize_name(const char *name); 42 43 char *devm_hwmon_sanitize_name(struct device *dev, const char *name); 44 45 void hwmon_lock(struct device *dev); 46 void hwmon_unlock(struct device *dev); 47 48hwmon_device_register_with_info registers a hardware monitoring device. 49It creates the standard sysfs attributes in the hardware monitoring core, 50letting the driver focus on reading from and writing to the chip instead 51of having to bother with sysfs attributes. The parent device parameter 52as well as the chip parameter must not be NULL. Its parameters are described 53in more detail below. 54 55devm_hwmon_device_register_with_info is similar to 56hwmon_device_register_with_info. However, it is device managed, meaning the 57hwmon device does not have to be removed explicitly by the removal function. 58 59All other hardware monitoring device registration functions are deprecated 60and must not be used in new drivers. 61 62hwmon_device_unregister deregisters a registered hardware monitoring device. 63The parameter of this function is the pointer to the registered hardware 64monitoring device structure. This function must be called from the driver 65remove function if the hardware monitoring device was registered with 66hwmon_device_register_with_info. 67 68All supported hwmon device registration functions only accept valid device 69names. Device names including invalid characters (whitespace, '*', or '-') 70will be rejected. If NULL is passed as name parameter, the hardware monitoring 71device name will be derived from the parent device name. 72 73If the driver doesn't use a static device name (for example it uses 74dev_name()), and therefore cannot make sure the name only contains valid 75characters, hwmon_sanitize_name can be used. This convenience function 76will duplicate the string and replace any invalid characters with an 77underscore. It will allocate memory for the new string and it is the 78responsibility of the caller to release the memory when the device is 79removed. 80 81devm_hwmon_sanitize_name is the resource managed version of 82hwmon_sanitize_name; the memory will be freed automatically on device 83removal. 84 85When using ``[devm_]hwmon_device_register_with_info()`` to register the 86hardware monitoring device, accesses using the associated access functions 87are serialised by the hardware monitoring core. If a driver needs locking 88for other functions such as interrupt handlers or for attributes which are 89fully implemented in the driver, hwmon_lock() and hwmon_unlock() can be used 90to ensure that calls to those functions are serialized. 91 92Using devm_hwmon_device_register_with_info() 93-------------------------------------------- 94 95hwmon_device_register_with_info() registers a hardware monitoring device. 96The parameters to this function are 97 98=============================================== =============================================== 99`struct device *dev` Pointer to parent device 100`const char *name` Device name 101`void *drvdata` Driver private data 102`const struct hwmon_chip_info *info` Pointer to chip description. 103`const struct attribute_group **extra_groups` Null-terminated list of additional non-standard 104 sysfs attribute groups. 105=============================================== =============================================== 106 107This function returns a pointer to the created hardware monitoring device 108on success and a negative error code for failure. 109 110The hwmon_chip_info structure looks as follows:: 111 112 struct hwmon_chip_info { 113 const struct hwmon_ops *ops; 114 const struct hwmon_channel_info * const *info; 115 }; 116 117It contains the following fields: 118 119* ops: 120 Pointer to device operations. 121* info: 122 NULL-terminated list of device channel descriptors. 123 124The list of hwmon operations is defined as:: 125 126 struct hwmon_ops { 127 umode_t (*is_visible)(const void *, enum hwmon_sensor_types type, 128 u32 attr, int); 129 int (*read)(struct device *, enum hwmon_sensor_types type, 130 u32 attr, int, long *); 131 int (*write)(struct device *, enum hwmon_sensor_types type, 132 u32 attr, int, long); 133 }; 134 135It defines the following operations. 136 137* is_visible: 138 Pointer to a function to return the file mode for each supported 139 attribute. This function is mandatory. 140 141* read: 142 Pointer to a function for reading a value from the chip. This function 143 is optional, but must be provided if any readable attributes exist. 144 145* write: 146 Pointer to a function for writing a value to the chip. This function is 147 optional, but must be provided if any writeable attributes exist. 148 149Each sensor channel is described with struct hwmon_channel_info, which is 150defined as follows:: 151 152 struct hwmon_channel_info { 153 enum hwmon_sensor_types type; 154 u32 *config; 155 }; 156 157It contains following fields: 158 159* type: 160 The hardware monitoring sensor type. 161 162 Supported sensor types are 163 164 ================== ================================================== 165 hwmon_chip A virtual sensor type, used to describe attributes 166 which are not bound to a specific input or output 167 hwmon_temp Temperature sensor 168 hwmon_in Voltage sensor 169 hwmon_curr Current sensor 170 hwmon_power Power sensor 171 hwmon_energy Energy sensor 172 hwmon_energy64 Energy sensor, reported as 64-bit signed value 173 hwmon_humidity Humidity sensor 174 hwmon_fan Fan speed sensor 175 hwmon_pwm PWM control 176 ================== ================================================== 177 178* config: 179 Pointer to a 0-terminated list of configuration values for each 180 sensor of the given type. Each value is a combination of bit values 181 describing the attributes supposed by a single sensor. 182 183As an example, here is the complete description file for a LM75 compatible 184sensor chip. The chip has a single temperature sensor. The driver wants to 185register with the thermal subsystem (HWMON_C_REGISTER_TZ), and it supports 186the update_interval attribute (HWMON_C_UPDATE_INTERVAL). The chip supports 187reading the temperature (HWMON_T_INPUT), it has a maximum temperature 188register (HWMON_T_MAX) as well as a maximum temperature hysteresis register 189(HWMON_T_MAX_HYST):: 190 191 static const u32 lm75_chip_config[] = { 192 HWMON_C_REGISTER_TZ | HWMON_C_UPDATE_INTERVAL, 193 0 194 }; 195 196 static const struct hwmon_channel_info lm75_chip = { 197 .type = hwmon_chip, 198 .config = lm75_chip_config, 199 }; 200 201 static const u32 lm75_temp_config[] = { 202 HWMON_T_INPUT | HWMON_T_MAX | HWMON_T_MAX_HYST, 203 0 204 }; 205 206 static const struct hwmon_channel_info lm75_temp = { 207 .type = hwmon_temp, 208 .config = lm75_temp_config, 209 }; 210 211 static const struct hwmon_channel_info * const lm75_info[] = { 212 &lm75_chip, 213 &lm75_temp, 214 NULL 215 }; 216 217 The HWMON_CHANNEL_INFO() macro can and should be used when possible. 218 With this macro, the above example can be simplified to 219 220 static const struct hwmon_channel_info * const lm75_info[] = { 221 HWMON_CHANNEL_INFO(chip, 222 HWMON_C_REGISTER_TZ | HWMON_C_UPDATE_INTERVAL), 223 HWMON_CHANNEL_INFO(temp, 224 HWMON_T_INPUT | HWMON_T_MAX | HWMON_T_MAX_HYST), 225 NULL 226 }; 227 228 The remaining declarations are as follows. 229 230 static const struct hwmon_ops lm75_hwmon_ops = { 231 .is_visible = lm75_is_visible, 232 .read = lm75_read, 233 .write = lm75_write, 234 }; 235 236 static const struct hwmon_chip_info lm75_chip_info = { 237 .ops = &lm75_hwmon_ops, 238 .info = lm75_info, 239 }; 240 241A complete list of bit values indicating individual attribute support 242is defined in include/linux/hwmon.h. Definition prefixes are as follows. 243 244=============== ================================================= 245HWMON_C_xxxx Chip attributes, for use with hwmon_chip. 246HWMON_T_xxxx Temperature attributes, for use with hwmon_temp. 247HWMON_I_xxxx Voltage attributes, for use with hwmon_in. 248HWMON_C_xxxx Current attributes, for use with hwmon_curr. 249 Notice the prefix overlap with chip attributes. 250HWMON_P_xxxx Power attributes, for use with hwmon_power. 251HWMON_E_xxxx Energy attributes, for use with hwmon_energy. 252HWMON_H_xxxx Humidity attributes, for use with hwmon_humidity. 253HWMON_F_xxxx Fan speed attributes, for use with hwmon_fan. 254HWMON_PWM_xxxx PWM control attributes, for use with hwmon_pwm. 255=============== ================================================= 256 257Driver callback functions 258------------------------- 259 260Each driver provides is_visible, read, and write functions. Parameters 261and return values for those functions are as follows:: 262 263 umode_t is_visible_func(const void *data, enum hwmon_sensor_types type, 264 u32 attr, int channel) 265 266Parameters: 267 data: 268 Pointer to device private data structure. 269 type: 270 The sensor type. 271 attr: 272 Attribute identifier associated with a specific attribute. 273 For example, the attribute value for HWMON_T_INPUT would be 274 hwmon_temp_input. For complete mappings of bit fields to 275 attribute values please see include/linux/hwmon.h. 276 channel: 277 The sensor channel number. 278 279Return value: 280 The file mode for this attribute. Typically, this will be 0 (the 281 attribute will not be created), 0444, or 0644. 282 283:: 284 285 int read_func(struct device *dev, enum hwmon_sensor_types type, 286 u32 attr, int channel, long *val) 287 288Parameters: 289 dev: 290 Pointer to the hardware monitoring device. 291 type: 292 The sensor type. 293 attr: 294 Attribute identifier associated with a specific attribute. 295 For example, the attribute value for HWMON_T_INPUT would be 296 hwmon_temp_input. For complete mappings please see 297 include/linux/hwmon.h. 298 channel: 299 The sensor channel number. 300 val: 301 Pointer to attribute value. 302 For hwmon_energy64, `'val`' is passed as `long *` but needs 303 a typecast to `s64 *`. 304 305Return value: 306 0 on success, a negative error number otherwise. 307 308:: 309 310 int write_func(struct device *dev, enum hwmon_sensor_types type, 311 u32 attr, int channel, long val) 312 313Parameters: 314 dev: 315 Pointer to the hardware monitoring device. 316 type: 317 The sensor type. 318 attr: 319 Attribute identifier associated with a specific attribute. 320 For example, the attribute value for HWMON_T_INPUT would be 321 hwmon_temp_input. For complete mappings please see 322 include/linux/hwmon.h. 323 channel: 324 The sensor channel number. 325 val: 326 The value to write to the chip. 327 328Return value: 329 0 on success, a negative error number otherwise. 330 331 332Driver-provided sysfs attributes 333-------------------------------- 334 335In most situations it should not be necessary for a driver to provide sysfs 336attributes since the hardware monitoring core creates those internally. 337Only additional non-standard sysfs attributes need to be provided. 338 339The header file linux/hwmon-sysfs.h provides a number of useful macros to 340declare and use hardware monitoring sysfs attributes. 341 342In many cases, you can use the existing define DEVICE_ATTR or its variants 343DEVICE_ATTR_{RW,RO,WO} to declare such attributes. This is feasible if an 344attribute has no additional context. However, in many cases there will be 345additional information such as a sensor index which will need to be passed 346to the sysfs attribute handling function. 347 348SENSOR_DEVICE_ATTR and SENSOR_DEVICE_ATTR_2 can be used to define attributes 349which need such additional context information. SENSOR_DEVICE_ATTR requires 350one additional argument, SENSOR_DEVICE_ATTR_2 requires two. 351 352Simplified variants of SENSOR_DEVICE_ATTR and SENSOR_DEVICE_ATTR_2 are available 353and should be used if standard attribute permissions and function names are 354feasible. Standard permissions are 0644 for SENSOR_DEVICE_ATTR[_2]_RW, 3550444 for SENSOR_DEVICE_ATTR[_2]_RO, and 0200 for SENSOR_DEVICE_ATTR[_2]_WO. 356Standard functions, similar to DEVICE_ATTR_{RW,RO,WO}, have _show and _store 357appended to the provided function name. 358 359SENSOR_DEVICE_ATTR and its variants define a struct sensor_device_attribute 360variable. This structure has the following fields:: 361 362 struct sensor_device_attribute { 363 struct device_attribute dev_attr; 364 int index; 365 }; 366 367You can use to_sensor_dev_attr to get the pointer to this structure from the 368attribute read or write function. Its parameter is the device to which the 369attribute is attached. 370 371SENSOR_DEVICE_ATTR_2 and its variants define a struct sensor_device_attribute_2 372variable, which is defined as follows:: 373 374 struct sensor_device_attribute_2 { 375 struct device_attribute dev_attr; 376 u8 index; 377 u8 nr; 378 }; 379 380Use to_sensor_dev_attr_2 to get the pointer to this structure. Its parameter 381is the device to which the attribute is attached. 382