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  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
47hwmon_device_register_with_info registers a hardware monitoring device.
48It creates the standard sysfs attributes in the hardware monitoring core,
49letting the driver focus on reading from and writing to the chip instead
50of having to bother with sysfs attributes. The parent device parameter
51as well as the chip parameter must not be NULL. Its parameters are described
52in more detail below.
53
54devm_hwmon_device_register_with_info is similar to
55hwmon_device_register_with_info. However, it is device managed, meaning the
56hwmon device does not have to be removed explicitly by the removal function.
57
58All other hardware monitoring device registration functions are deprecated
59and must not be used in new drivers.
60
61hwmon_device_unregister deregisters a registered hardware monitoring device.
62The parameter of this function is the pointer to the registered hardware
63monitoring device structure. This function must be called from the driver
64remove function if the hardware monitoring device was registered with
65hwmon_device_register_with_info.
66
67devm_hwmon_device_unregister does not normally have to be called. It is only
68needed for error handling, and only needed if the driver probe fails after
69the call to hwmon_device_register_with_info and if the automatic (device
70managed) removal would be too late.
71
72All supported hwmon device registration functions only accept valid device
73names. Device names including invalid characters (whitespace, '*', or '-')
74will be rejected. The 'name' parameter is mandatory.
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
88Using devm_hwmon_device_register_with_info()
89--------------------------------------------
90
91hwmon_device_register_with_info() registers a hardware monitoring device.
92The 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
103This function returns a pointer to the created hardware monitoring device
104on success and a negative error code for failure.
105
106The 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
113It contains the following fields:
114
115* ops:
116	Pointer to device operations.
117* info:
118	NULL-terminated list of device channel descriptors.
119
120The 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
131It 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
145Each sensor channel is described with struct hwmon_channel_info, which is
146defined as follows::
147
148	struct hwmon_channel_info {
149		enum hwmon_sensor_types type;
150		u32 *config;
151	};
152
153It 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
178As an example, here is the complete description file for a LM75 compatible
179sensor chip. The chip has a single temperature sensor. The driver wants to
180register with the thermal subsystem (HWMON_C_REGISTER_TZ), and it supports
181the update_interval attribute (HWMON_C_UPDATE_INTERVAL). The chip supports
182reading the temperature (HWMON_T_INPUT), it has a maximum temperature
183register (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
236A complete list of bit values indicating individual attribute support
237is defined in include/linux/hwmon.h. Definition prefixes are as follows.
238
239=============== =================================================
240HWMON_C_xxxx	Chip attributes, for use with hwmon_chip.
241HWMON_T_xxxx	Temperature attributes, for use with hwmon_temp.
242HWMON_I_xxxx	Voltage attributes, for use with hwmon_in.
243HWMON_C_xxxx	Current attributes, for use with hwmon_curr.
244		Notice the prefix overlap with chip attributes.
245HWMON_P_xxxx	Power attributes, for use with hwmon_power.
246HWMON_E_xxxx	Energy attributes, for use with hwmon_energy.
247HWMON_H_xxxx	Humidity attributes, for use with hwmon_humidity.
248HWMON_F_xxxx	Fan speed attributes, for use with hwmon_fan.
249HWMON_PWM_xxxx	PWM control attributes, for use with hwmon_pwm.
250=============== =================================================
251
252Driver callback functions
253-------------------------
254
255Each driver provides is_visible, read, and write functions. Parameters
256and 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
261Parameters:
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
274Return 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
283Parameters:
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
298Return 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
306Parameters:
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
321Return value:
322	0 on success, a negative error number otherwise.
323
324
325Driver-provided sysfs attributes
326--------------------------------
327
328In most situations it should not be necessary for a driver to provide sysfs
329attributes since the hardware monitoring core creates those internally.
330Only additional non-standard sysfs attributes need to be provided.
331
332The header file linux/hwmon-sysfs.h provides a number of useful macros to
333declare and use hardware monitoring sysfs attributes.
334
335In many cases, you can use the existing define DEVICE_ATTR or its variants
336DEVICE_ATTR_{RW,RO,WO} to declare such attributes. This is feasible if an
337attribute has no additional context. However, in many cases there will be
338additional information such as a sensor index which will need to be passed
339to the sysfs attribute handling function.
340
341SENSOR_DEVICE_ATTR and SENSOR_DEVICE_ATTR_2 can be used to define attributes
342which need such additional context information. SENSOR_DEVICE_ATTR requires
343one additional argument, SENSOR_DEVICE_ATTR_2 requires two.
344
345Simplified variants of SENSOR_DEVICE_ATTR and SENSOR_DEVICE_ATTR_2 are available
346and should be used if standard attribute permissions and function names are
347feasible. Standard permissions are 0644 for SENSOR_DEVICE_ATTR[_2]_RW,
3480444 for SENSOR_DEVICE_ATTR[_2]_RO, and 0200 for SENSOR_DEVICE_ATTR[_2]_WO.
349Standard functions, similar to DEVICE_ATTR_{RW,RO,WO}, have _show and _store
350appended to the provided function name.
351
352SENSOR_DEVICE_ATTR and its variants define a struct sensor_device_attribute
353variable. This structure has the following fields::
354
355	struct sensor_device_attribute {
356		struct device_attribute dev_attr;
357		int index;
358	};
359
360You can use to_sensor_dev_attr to get the pointer to this structure from the
361attribute read or write function. Its parameter is the device to which the
362attribute is attached.
363
364SENSOR_DEVICE_ATTR_2 and its variants define a struct sensor_device_attribute_2
365variable, 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
373Use to_sensor_dev_attr_2 to get the pointer to this structure. Its parameter
374is the device to which the attribute is attached.
375