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