xref: /linux/Documentation/hwmon/hwmon-kernel-api.rst (revision dec1c62e91ba268ab2a6e339d4d7a59287d5eba1)
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