Introduction¶

This document describes the API that can be used by hardware monitoringdrivers that want to use the hardware monitoring framework.

This document does not describe what a hardware monitoring (hwmon) Driver orDevice is. It also does not describe the API which can be used by user spaceto communicate with a hardware monitoring device. If you want to know thisthen please read the following file:Naming and data format standards for sysfs files.

For additional guidelines on how to write and improve hwmon drivers, pleasealso readHow to Get Your Patch Accepted Into the Hwmon Subsystem.

The API¶

Each hardware monitoring driver must #include <linux/hwmon.h> and, in somecases, <linux/hwmon-sysfs.h>. linux/hwmon.h declares the followingregister/unregister functions:

struct device *hwmon_device_register_with_info(struct device *dev,                                const char *name, void *drvdata,                                const struct hwmon_chip_info *info,                                const struct attribute_group **extra_groups);struct device *devm_hwmon_device_register_with_info(struct device *dev,                                     const char *name,                                     void *drvdata,                                     const struct hwmon_chip_info *info,                                     const struct attribute_group **extra_groups);void hwmon_device_unregister(struct device *dev);char *hwmon_sanitize_name(const char *name);char *devm_hwmon_sanitize_name(struct device *dev, const char *name);void hwmon_lock(struct device *dev);void hwmon_unlock(struct device *dev);

hwmon_device_register_with_info registers a hardware monitoring device.It creates the standard sysfs attributes in the hardware monitoring core,letting the driver focus on reading from and writing to the chip insteadof having to bother with sysfs attributes. The parent device parameteras well as the chip parameter must not be NULL. Its parameters are describedin more detail below.

devm_hwmon_device_register_with_info is similar tohwmon_device_register_with_info. However, it is device managed, meaning thehwmon device does not have to be removed explicitly by the removal function.

All other hardware monitoring device registration functions are deprecatedand must not be used in new drivers.

hwmon_device_unregister deregisters a registered hardware monitoring device.The parameter of this function is the pointer to the registered hardwaremonitoring device structure. This function must be called from the driverremove function if the hardware monitoring device was registered withhwmon_device_register_with_info.

All supported hwmon device registration functions only accept valid devicenames. Device names including invalid characters (whitespace, ‘*’, or ‘-‘)will be rejected. If NULL is passed as name parameter, the hardware monitoringdevice name will be derived from the parent device name.

If the driver doesn’t use a static device name (for example it usesdev_name()), and therefore cannot make sure the name only contains validcharacters, hwmon_sanitize_name can be used. This convenience functionwill duplicate the string and replace any invalid characters with anunderscore. It will allocate memory for the new string and it is theresponsibility of the caller to release the memory when the device isremoved.

devm_hwmon_sanitize_name is the resource managed version ofhwmon_sanitize_name; the memory will be freed automatically on deviceremoval.

When using[devm_]hwmon_device_register_with_info() to register thehardware monitoring device, accesses using the associated access functionsare serialised by the hardware monitoring core. If a driver needs lockingfor other functions such as interrupt handlers or for attributes which arefully implemented in the driver,hwmon_lock() andhwmon_unlock() can be usedto ensure that calls to those functions are serialized.

Using devm_hwmon_device_register_with_info()¶

hwmon_device_register_with_info() registers a hardware monitoring device.The parameters to this function are

This function returns a pointer to the created hardware monitoring deviceon success and a negative error code for failure.

The hwmon_chip_info structure looks as follows:

struct hwmon_chip_info {        const struct hwmon_ops *ops;        const struct hwmon_channel_info * const *info;};

It contains the following fields:

• ops:

  Pointer to device operations.

• info:

  NULL-terminated list of device channel descriptors.

The list of hwmon operations is defined as:

struct hwmon_ops {      umode_t (*is_visible)(const void *, enum hwmon_sensor_types type,                            u32 attr, int);      int (*read)(struct device *, enum hwmon_sensor_types type,                  u32 attr, int, long *);      int (*write)(struct device *, enum hwmon_sensor_types type,                   u32 attr, int, long);};

It defines the following operations.

• is_visible:

  Pointer to a function to return the file mode for each supportedattribute. This function is mandatory.

• read:

  Pointer to a function for reading a value from the chip. This functionis optional, but must be provided if any readable attributes exist.

• write:

  Pointer to a function for writing a value to the chip. This function isoptional, but must be provided if any writeable attributes exist.

Each sensor channel is described withstructhwmon_channel_info, which isdefined as follows:

struct hwmon_channel_info {        enum hwmon_sensor_types type;        u32 *config;};

It contains following fields:

• type:

  The hardware monitoring sensor type.

  Supported sensor types are

  hwmon_chip	A virtual sensor type, used to describe attributeswhich are not bound to a specific input or output
  hwmon_temp	Temperature sensor
  hwmon_in	Voltage sensor
  hwmon_curr	Current sensor
  hwmon_power	Power sensor
  hwmon_energy	Energy sensor
  hwmon_energy64	Energy sensor, reported as 64-bit signed value
  hwmon_humidity	Humidity sensor
  hwmon_fan	Fan speed sensor
  hwmon_pwm	PWM control

• config:

  Pointer to a 0-terminated list of configuration values for eachsensor of the given type. Each value is a combination of bit valuesdescribing the attributes supposed by a single sensor.

As an example, here is the complete description file for a LM75 compatiblesensor chip. The chip has a single temperature sensor. The driver wants toregister with the thermal subsystem (HWMON_C_REGISTER_TZ), and it supportsthe update_interval attribute (HWMON_C_UPDATE_INTERVAL). The chip supportsreading the temperature (HWMON_T_INPUT), it has a maximum temperatureregister (HWMON_T_MAX) as well as a maximum temperature hysteresis register(HWMON_T_MAX_HYST):

static const u32 lm75_chip_config[] = {        HWMON_C_REGISTER_TZ | HWMON_C_UPDATE_INTERVAL,        0};static const struct hwmon_channel_info lm75_chip = {        .type = hwmon_chip,        .config = lm75_chip_config,};static const u32 lm75_temp_config[] = {        HWMON_T_INPUT | HWMON_T_MAX | HWMON_T_MAX_HYST,        0};static const struct hwmon_channel_info lm75_temp = {        .type = hwmon_temp,        .config = lm75_temp_config,};static const struct hwmon_channel_info * const lm75_info[] = {        &lm75_chip,        &lm75_temp,        NULL};The HWMON_CHANNEL_INFO() macro can and should be used when possible.With this macro, the above example can be simplified tostatic const struct hwmon_channel_info * const lm75_info[] = {        HWMON_CHANNEL_INFO(chip,                        HWMON_C_REGISTER_TZ | HWMON_C_UPDATE_INTERVAL),        HWMON_CHANNEL_INFO(temp,                        HWMON_T_INPUT | HWMON_T_MAX | HWMON_T_MAX_HYST),        NULL};The remaining declarations are as follows.static const struct hwmon_ops lm75_hwmon_ops = {        .is_visible = lm75_is_visible,        .read = lm75_read,        .write = lm75_write,};static const struct hwmon_chip_info lm75_chip_info = {        .ops = &lm75_hwmon_ops,        .info = lm75_info,};

A complete list of bit values indicating individual attribute supportis defined in include/linux/hwmon.h. Definition prefixes are as follows.

Driver callback functions¶

Each driver provides is_visible, read, and write functions. Parametersand return values for those functions are as follows:

umode_t is_visible_func(const void *data, enum hwmon_sensor_types type,                        u32 attr, int channel)

Parameters:

data:

Pointer to device private data structure.

type:

The sensor type.

attr:

Attribute identifier associated with a specific attribute.For example, the attribute value for HWMON_T_INPUT would behwmon_temp_input. For complete mappings of bit fields toattribute values please see include/linux/hwmon.h.

channel:

The sensor channel number.

Return value:

The file mode for this attribute. Typically, this will be 0 (theattribute will not be created), 0444, or 0644.

int read_func(struct device *dev, enum hwmon_sensor_types type,              u32 attr, int channel, long *val)

Parameters:

dev:

Pointer to the hardware monitoring device.

type:

The sensor type.

attr:

Attribute identifier associated with a specific attribute.For example, the attribute value for HWMON_T_INPUT would behwmon_temp_input. For complete mappings please seeinclude/linux/hwmon.h.

channel:

The sensor channel number.

val:

Pointer to attribute value.For hwmon_energy64,‘val’ is passed aslong * but needsa typecast tos64 *.

Return value:

0 on success, a negative error number otherwise.

int write_func(struct device *dev, enum hwmon_sensor_types type,               u32 attr, int channel, long val)

Parameters:

dev:

Pointer to the hardware monitoring device.

type:

The sensor type.

attr:

Attribute identifier associated with a specific attribute.For example, the attribute value for HWMON_T_INPUT would behwmon_temp_input. For complete mappings please seeinclude/linux/hwmon.h.

channel:

The sensor channel number.

val:

The value to write to the chip.

Return value:

0 on success, a negative error number otherwise.

Driver-provided sysfs attributes¶

In most situations it should not be necessary for a driver to provide sysfsattributes since the hardware monitoring core creates those internally.Only additional non-standard sysfs attributes need to be provided.

The header file linux/hwmon-sysfs.h provides a number of useful macros todeclare and use hardware monitoring sysfs attributes.

In many cases, you can use the existing define DEVICE_ATTR or its variantsDEVICE_ATTR_{RW,RO,WO} to declare such attributes. This is feasible if anattribute has no additional context. However, in many cases there will beadditional information such as a sensor index which will need to be passedto the sysfs attribute handling function.

SENSOR_DEVICE_ATTR and SENSOR_DEVICE_ATTR_2 can be used to define attributeswhich need such additional context information. SENSOR_DEVICE_ATTR requiresone additional argument, SENSOR_DEVICE_ATTR_2 requires two.

Simplified variants of SENSOR_DEVICE_ATTR and SENSOR_DEVICE_ATTR_2 are availableand should be used if standard attribute permissions and function names arefeasible. Standard permissions are 0644 for SENSOR_DEVICE_ATTR[_2]_RW,0444 for SENSOR_DEVICE_ATTR[_2]_RO, and 0200 for SENSOR_DEVICE_ATTR[_2]_WO.Standard functions, similar to DEVICE_ATTR_{RW,RO,WO}, have _show and _storeappended to the provided function name.

SENSOR_DEVICE_ATTR and its variants define astructsensor_device_attributevariable. This structure has the following fields:

struct sensor_device_attribute {        struct device_attribute dev_attr;        int index;};

You can use to_sensor_dev_attr to get the pointer to this structure from theattribute read or write function. Its parameter is the device to which theattribute is attached.

SENSOR_DEVICE_ATTR_2 and its variants define astructsensor_device_attribute_2variable, which is defined as follows:

struct sensor_device_attribute_2 {        struct device_attribute dev_attr;        u8 index;        u8 nr;};

Use to_sensor_dev_attr_2 to get the pointer to this structure. Its parameteris the device to which the attribute is attached.