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