Incorrect mapping from hwmon sensor type into iio sensor type

[damijans]

iio library defines two bunch of sensor type, one for hwmon and the other for iio sensors.

hwmon sensor type are defined with
enum hwmon_chan_type {
HWMON_VOLTAGE,
HWMON_FAN,
HWMON_PWM,
HWMON_TEMP,
HWMON_CURRENT,
HWMON_POWER,
HWMON_ENERGY,
HWMON_HUMIDITY,
HWMON_INTRUSION,
HWMON_CHAN_TYPE_UNKNOWN = IIO_CHAN_TYPE_UNKNOWN,
};
while iio sensor types are define with
enum iio_chan_type {
IIO_VOLTAGE,
IIO_CURRENT,
IIO_POWER,
IIO_ACCEL,
IIO_ANGL_VEL,
IIO_MAGN,
IIO_LIGHT,
IIO_INTENSITY,
IIO_PROXIMITY,
IIO_TEMP,
IIO_INCLI,
IIO_ROT,
IIO_ANGL,
IIO_TIMESTAMP,
IIO_CAPACITANCE,
IIO_ALTVOLTAGE,
IIO_CCT,
IIO_PRESSURE,
IIO_HUMIDITYRELATIVE,
IIO_ACTIVITY,
IIO_STEPS,
IIO_ENERGY,
IIO_DISTANCE,
IIO_VELOCITY,
IIO_CONCENTRATION,
IIO_RESISTANCE,
IIO_PH,
IIO_UVINDEX,
IIO_ELECTRICALCONDUCTIVITY,
IIO_COUNT,
IIO_INDEX,
IIO_GRAVITY,
IIO_POSITIONRELATIVE,
IIO_PHASE,
IIO_MASSCONCENTRATION,
IIO_DELTA_ANGL,
IIO_DELTA_VELOCITY,
IIO_COLORTEMP,
IIO_CHROMATICITY,
IIO_ATTENTION,
IIO_ALTCURRENT,
IIO_CHAN_TYPE_UNKNOWN = INT_MAX
};

when library enumerates hwmon sensors from the system fs, it converts type description into hwmon_chan_type in iio_channel_init_finalize() function based on hwmon_chan_type_name_spec table. Here "temp1" sensor description is correctly converted into HWMON_TEMP type. However, later on, this type is typecasted directly into iio_chan_type, i.e. HWMON_TEMP(value 3) is converted into IIO_ACCEL(value 3), what is wrong. Rather it should be converted into IIO_TEMP (value 7).

The same mistake happens also in the opposite direction, i.e. conversion from iio_chan_type into hwmon_chan_type (see hwmon_channel_get_type() function)

[RubenNatanael]

Hi @damijans, thank you for the report and the analysis. Indeed, following our own review, the implementation can be—and is—confusing for developers. As it stands, it requires a prior check using the pattern:

if (iio_device_is_hwmon(iio_channel_get_device(chn))) {  
    enum hwmon_chan_type hw_type = hwmon_channel_get_type(chn);  
} else {  
    enum iio_chan_type iio_type = iio_channel_get_type(chn);  
}

In search of a solution, we’ve decided to try making the type member an int (to keep it general) and to issue a warning for incorrect usage when retrieving the type. This means errors will still occur if the previously mentioned pattern isn't followed.

I will add a link to the PR once it’s ready.
All the best!

[nunojsa]

when library enumerates hwmon sensors from the system fs, it converts type description into hwmon_chan_type in iio_channel_init_finalize() function based on hwmon_chan_type_name_spec table. Here "temp1" sensor description is correctly converted into HWMON_TEMP type. However, later on, this type is typecasted directly into iio_chan_type, i.e. HWMON_TEMP(value 3) is converted into IIO_ACCEL(value 3), what is wrong. Rather it should be converted into IIO_TEMP (value 7).

Have you actually seen any issue in the libiio core code/API regarding this? FWIW, I commented on #1404

[rgetz]

This is an intentional design decision, not a bug or mistake.

libiio defines two sets of sensor types, one for hwmon and the other for IIO sensors.”

Let’s clarify the distinction.

For IIO devices, the Linux kernel defines the channel types in its UAPI, see: include/uapi/linux/iio/types.h in the Linux kernel source tree.

These enum iio_chan_type values are part of the kernel ABI. libiio must match these exactly, because they are defined and exported by the kernel. We cannot reorder or redefine them without breaking ABI compatibility.

The Linux hwmon subsystem does not define a corresponding enum in the kernel ABI. Instead, hwmon devices expose sensor types through sysfs file naming conventions (e.g., temp1_input, in0_input, etc.), as documented here: https://www.kernel.org/doc/Documentation/hwmon/sysfs-interface

When hwmon support was added to libiio, there was no kernel-defined enum to mirror. So libiio introduced enum hwmon_chan_type internally to:

• Provide structured semantics similar to IIO
• Avoid string comparisons throughout the code
• Maintain consistency with how IIO channel types are handled

The numeric values of:

• enum hwmon_chan_type
• enum iio_chan_type

are not meant to align.

Casting between them does not imply semantic equivalence of the numeric value. The enums represent different namespaces that happen to share some overlapping concepts (e.g., TEMP, VOLTAGE), but they originate from:

• IIO → kernel-defined ABI
• hwmon → sysfs naming conventions (no kernel enum)

The fact that HWMON_TEMP == 3 and IIO_ACCEL == 3 is incidental. The values are not designed to be interchangeable.

In short

• iio_chan_type mirrors the kernel ABI and must remain fixed.
• hwmon_chan_type was added internally to give structure to sysfs-based hwmon data.

The enums are intentionally separate.

Numeric alignment between them is neither required nor expected.

If a semantic mapping is required (e.g., mapping HWMON_TEMP → IIO_TEMP), that should be done explicitly — not by assuming matching enum values.

This behavior is by design, not an oversight.