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