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, attributes which are fully 89implemented in the driver, or debugfs functions, hwmon_lock() and hwmon_unlock() 90can be used to ensure that calls to those functions are serialized. Those 91functions also support guard() and scoped_guard() variants. 92 93Using devm_hwmon_device_register_with_info() 94-------------------------------------------- 95 96hwmon_device_register_with_info() registers a hardware monitoring device. 97The parameters to this function are 98 99=============================================== =============================================== 100`struct device *dev` Pointer to parent device 101`const char *name` Device name 102`void *drvdata` Driver private data 103`const struct hwmon_chip_info *info` Pointer to chip description. 104`const struct attribute_group **extra_groups` Null-terminated list of additional non-standard 105 sysfs attribute groups. 106=============================================== =============================================== 107 108This function returns a pointer to the created hardware monitoring device 109on success and a negative error code for failure. 110 111The hwmon_chip_info structure looks as follows:: 112 113 struct hwmon_chip_info { 114 const struct hwmon_ops *ops; 115 const struct hwmon_channel_info * const *info; 116 }; 117 118It contains the following fields: 119 120* ops: 121 Pointer to device operations. 122* info: 123 NULL-terminated list of device channel descriptors. 124 125The list of hwmon operations is defined as:: 126 127 struct hwmon_ops { 128 umode_t (*is_visible)(const void *, enum hwmon_sensor_types type, 129 u32 attr, int); 130 int (*read)(struct device *, enum hwmon_sensor_types type, 131 u32 attr, int, long *); 132 int (*write)(struct device *, enum hwmon_sensor_types type, 133 u32 attr, int, long); 134 }; 135 136It defines the following operations. 137 138* is_visible: 139 Pointer to a function to return the file mode for each supported 140 attribute. This function is mandatory. 141 142* read: 143 Pointer to a function for reading a value from the chip. This function 144 is optional, but must be provided if any readable attributes exist. 145 146* write: 147 Pointer to a function for writing a value to the chip. This function is 148 optional, but must be provided if any writeable attributes exist. 149 150Each sensor channel is described with struct hwmon_channel_info, which is 151defined as follows:: 152 153 struct hwmon_channel_info { 154 enum hwmon_sensor_types type; 155 u32 *config; 156 }; 157 158It contains following fields: 159 160* type: 161 The hardware monitoring sensor type. 162 163 Supported sensor types are 164 165 ================== ================================================== 166 hwmon_chip A virtual sensor type, used to describe attributes 167 which are not bound to a specific input or output 168 hwmon_temp Temperature sensor 169 hwmon_in Voltage sensor 170 hwmon_curr Current sensor 171 hwmon_power Power sensor 172 hwmon_energy Energy sensor 173 hwmon_energy64 Energy sensor, reported as 64-bit signed value 174 hwmon_humidity Humidity sensor 175 hwmon_fan Fan speed sensor 176 hwmon_pwm PWM control 177 ================== ================================================== 178 179* config: 180 Pointer to a 0-terminated list of configuration values for each 181 sensor of the given type. Each value is a combination of bit values 182 describing the attributes supposed by a single sensor. 183 184As an example, here is the complete description file for a LM75 compatible 185sensor chip. The chip has a single temperature sensor. The driver wants to 186register with the thermal subsystem (HWMON_C_REGISTER_TZ), and it supports 187the update_interval attribute (HWMON_C_UPDATE_INTERVAL). The chip supports 188reading the temperature (HWMON_T_INPUT), it has a maximum temperature 189register (HWMON_T_MAX) as well as a maximum temperature hysteresis register 190(HWMON_T_MAX_HYST):: 191 192 static const u32 lm75_chip_config[] = { 193 HWMON_C_REGISTER_TZ | HWMON_C_UPDATE_INTERVAL, 194 0 195 }; 196 197 static const struct hwmon_channel_info lm75_chip = { 198 .type = hwmon_chip, 199 .config = lm75_chip_config, 200 }; 201 202 static const u32 lm75_temp_config[] = { 203 HWMON_T_INPUT | HWMON_T_MAX | HWMON_T_MAX_HYST, 204 0 205 }; 206 207 static const struct hwmon_channel_info lm75_temp = { 208 .type = hwmon_temp, 209 .config = lm75_temp_config, 210 }; 211 212 static const struct hwmon_channel_info * const lm75_info[] = { 213 &lm75_chip, 214 &lm75_temp, 215 NULL 216 }; 217 218 The HWMON_CHANNEL_INFO() macro can and should be used when possible. 219 With this macro, the above example can be simplified to 220 221 static const struct hwmon_channel_info * const lm75_info[] = { 222 HWMON_CHANNEL_INFO(chip, 223 HWMON_C_REGISTER_TZ | HWMON_C_UPDATE_INTERVAL), 224 HWMON_CHANNEL_INFO(temp, 225 HWMON_T_INPUT | HWMON_T_MAX | HWMON_T_MAX_HYST), 226 NULL 227 }; 228 229 The remaining declarations are as follows. 230 231 static const struct hwmon_ops lm75_hwmon_ops = { 232 .is_visible = lm75_is_visible, 233 .read = lm75_read, 234 .write = lm75_write, 235 }; 236 237 static const struct hwmon_chip_info lm75_chip_info = { 238 .ops = &lm75_hwmon_ops, 239 .info = lm75_info, 240 }; 241 242A complete list of bit values indicating individual attribute support 243is defined in include/linux/hwmon.h. Definition prefixes are as follows. 244 245=============== ================================================= 246HWMON_C_xxxx Chip attributes, for use with hwmon_chip. 247HWMON_T_xxxx Temperature attributes, for use with hwmon_temp. 248HWMON_I_xxxx Voltage attributes, for use with hwmon_in. 249HWMON_C_xxxx Current attributes, for use with hwmon_curr. 250 Notice the prefix overlap with chip attributes. 251HWMON_P_xxxx Power attributes, for use with hwmon_power. 252HWMON_E_xxxx Energy attributes, for use with hwmon_energy. 253HWMON_H_xxxx Humidity attributes, for use with hwmon_humidity. 254HWMON_F_xxxx Fan speed attributes, for use with hwmon_fan. 255HWMON_PWM_xxxx PWM control attributes, for use with hwmon_pwm. 256=============== ================================================= 257 258Driver callback functions 259------------------------- 260 261Each driver provides is_visible, read, and write functions. Parameters 262and return values for those functions are as follows:: 263 264 umode_t is_visible_func(const void *data, enum hwmon_sensor_types type, 265 u32 attr, int channel) 266 267Parameters: 268 data: 269 Pointer to device private data structure. 270 type: 271 The sensor type. 272 attr: 273 Attribute identifier associated with a specific attribute. 274 For example, the attribute value for HWMON_T_INPUT would be 275 hwmon_temp_input. For complete mappings of bit fields to 276 attribute values please see include/linux/hwmon.h. 277 channel: 278 The sensor channel number. 279 280Return value: 281 The file mode for this attribute. Typically, this will be 0 (the 282 attribute will not be created), 0444, or 0644. 283 284:: 285 286 int read_func(struct device *dev, enum hwmon_sensor_types type, 287 u32 attr, int channel, long *val) 288 289Parameters: 290 dev: 291 Pointer to the hardware monitoring device. 292 type: 293 The sensor type. 294 attr: 295 Attribute identifier associated with a specific attribute. 296 For example, the attribute value for HWMON_T_INPUT would be 297 hwmon_temp_input. For complete mappings please see 298 include/linux/hwmon.h. 299 channel: 300 The sensor channel number. 301 val: 302 Pointer to attribute value. 303 For hwmon_energy64, `'val`' is passed as `long *` but needs 304 a typecast to `s64 *`. 305 306Return value: 307 0 on success, a negative error number otherwise. 308 309:: 310 311 int write_func(struct device *dev, enum hwmon_sensor_types type, 312 u32 attr, int channel, long val) 313 314Parameters: 315 dev: 316 Pointer to the hardware monitoring device. 317 type: 318 The sensor type. 319 attr: 320 Attribute identifier associated with a specific attribute. 321 For example, the attribute value for HWMON_T_INPUT would be 322 hwmon_temp_input. For complete mappings please see 323 include/linux/hwmon.h. 324 channel: 325 The sensor channel number. 326 val: 327 The value to write to the chip. 328 329Return value: 330 0 on success, a negative error number otherwise. 331 332 333Driver-provided sysfs attributes 334-------------------------------- 335 336In most situations it should not be necessary for a driver to provide sysfs 337attributes since the hardware monitoring core creates those internally. 338Only additional non-standard sysfs attributes need to be provided. 339 340The header file linux/hwmon-sysfs.h provides a number of useful macros to 341declare and use hardware monitoring sysfs attributes. 342 343In many cases, you can use the existing define DEVICE_ATTR or its variants 344DEVICE_ATTR_{RW,RO,WO} to declare such attributes. This is feasible if an 345attribute has no additional context. However, in many cases there will be 346additional information such as a sensor index which will need to be passed 347to the sysfs attribute handling function. 348 349SENSOR_DEVICE_ATTR and SENSOR_DEVICE_ATTR_2 can be used to define attributes 350which need such additional context information. SENSOR_DEVICE_ATTR requires 351one additional argument, SENSOR_DEVICE_ATTR_2 requires two. 352 353Simplified variants of SENSOR_DEVICE_ATTR and SENSOR_DEVICE_ATTR_2 are available 354and should be used if standard attribute permissions and function names are 355feasible. Standard permissions are 0644 for SENSOR_DEVICE_ATTR[_2]_RW, 3560444 for SENSOR_DEVICE_ATTR[_2]_RO, and 0200 for SENSOR_DEVICE_ATTR[_2]_WO. 357Standard functions, similar to DEVICE_ATTR_{RW,RO,WO}, have _show and _store 358appended to the provided function name. 359 360SENSOR_DEVICE_ATTR and its variants define a struct sensor_device_attribute 361variable. This structure has the following fields:: 362 363 struct sensor_device_attribute { 364 struct device_attribute dev_attr; 365 int index; 366 }; 367 368You can use to_sensor_dev_attr to get the pointer to this structure from the 369attribute read or write function. Its parameter is the device to which the 370attribute is attached. 371 372SENSOR_DEVICE_ATTR_2 and its variants define a struct sensor_device_attribute_2 373variable, which is defined as follows:: 374 375 struct sensor_device_attribute_2 { 376 struct device_attribute dev_attr; 377 u8 index; 378 u8 nr; 379 }; 380 381Use to_sensor_dev_attr_2 to get the pointer to this structure. Its parameter 382is the device to which the attribute is attached. 383