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