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