hwmonX none deterministic

Technical Support
, , , , ,
1

Hello Toradex team,

I hope you are all doing great! And thank you for your support.

Hardware:

uname:

  • Linux 0146230000 5.15.177-6.8.2+git.5a6602cc6c32 #1-TorizonCore SMP PREEMPT Fri Mar 21 16:22:58 UTC 2025 aarch64 aarch64 aarch64 GNU/Linux

Images tested:

  • torizon-core-docker-verdin-imx8mp-Tezi_6.8.2+build.30.tar (STABLE Release)

Guest OS:

  • macOS (M1 Pro ARM64)
  • Linux ubuntu (VM x86_64)

Issue:
I’m facing an issue with the /sys/class/hwmon/hwmonX not being deterministic, at every reboot the hardware is linked to a new number this make it hard to use it in my docker containers as I have to linked the appropriate device to have avoid issue with:

$ docker run -it --rm -v /tmp:/home/torizon -v /sys/class/hwmon:/sys/class/hwmon torizon/debian:$CT_TAG_DEBIAN bash
# echo 1 > /sys/class/hwmon/hwmon1/pwm1_enable
bash: /sys/class/hwmon/hwmon1/pwm1_enable: Read-only file system
# exist
$ docker run -it --rm -v /tmp:/home/torizon -v /sys/class/hwmon/hwmon1:/sys/class/hwmon/hwmon1 torizon/debian:$CT_TAG_DEBIAN bash
# echo 1 > /sys/class/hwmon/hwmon1/pwm1_enable
# SUCCESS

What I can see in the folder /sys/class/hwmon/:

$ cat /sys/class/hwmon/hwmon*/name
tmp75c
gpio_fan
gpio_fan
ncp03wf104
$ sudo reboot
...
$ cat /sys/class/hwmon/hwmon*/name
gpio_fan
gpio_fan
tmp75c
ncp03wf104
$ sudo reboot
...
$ cat /sys/class/hwmon/hwmon*/name
gpio_fan
ncp03wf104
gpio_fan
tmp75c
...

Is there a solution I can use to select the number in my device tree ? Did anyone faced similar issue and has a workaround to avoid issue in my docker containers.

Thanks in advance for your help.

Best,
M

2

Hi, I’m the Toradex AI Assistant.

I might make mistakes. Our support team will step in if needed. If I answered your question, please tick the “Solution” checkbox. For follow-up questions to me, please use @ToradexAI in your post.

Did you like my answer? :+1: :-1:

Hello! Thank you for your detailed description and for providing your software and hardware details.

The non-deterministic numbering of /sys/class/hwmon/hwmonX devices at each boot is a common behavior in Linux due to the variable initialization order of hardware monitoring drivers. This indeed makes it difficult to reference specific devices by their hwmonX index inside Docker containers or scripts.

Solution Overview

While you cannot explicitly assign a particular hwmonX number to a device via the device tree, you can use device tree customization to influence driver probe order and maintain consistency in device initialization—or, more generally, use robust alternatives that allow you to reference the desired hardware monitoring device reliably. Here are two recommended approaches:

1. Reference Devices via the name File

Each /sys/class/hwmon/hwmonX/ folder contains a name file describing the device (e.g., tmp75c, gpio_fan). Instead of hardcoding the number (hwmon1, hwmon2, etc.), dynamically identify the directory by its name in your container at runtime.

Example Script:

for dir in /sys/class/hwmon/hwmon*; do
    if grep -q "gpio_fan" "$dir/name"; then
        echo 1 > "$dir/pwm1_enable"
        break
    fi
done

This approach ensures your script works regardless of the numeric directory order. You can adjust the search string to match the hardware you intend to control.

2. Use Device Tree Customization (Advanced)

The initialization order can sometimes be influenced by how devices are arranged in the device tree (why customize device trees?). You can:

  • Create a custom device tree overlay, defining the order for your hardware monitoring devices.
  • Reference base nodes using the ampersand character and adjust the device nodes as needed (first steps with device trees).

To apply your changes:

  • Use the Device Tree Compiler (dtc) to compile your .dts file.
  • On TorizonCore, the recommended tool is torizoncore-builder:
    torizoncore-builder dt apply custom-device-tree.dts

Keep in mind: This method may help with consistency but cannot guarantee that non-related kernel drivers (or dynamically detected devices) won’t result in shifting numbering. Thus, the script-based approach above is more robust for most use-cases.

Summary

Let me know if you need an example script integrated into your Docker workflow or help with device tree overlays!

Best regards,
Toradex AI Assistant.

3

Can you show me an example for: Reference base nodes using the ampersand character.

Thanks

4

Greetings @unablesalt,

You are correct that the hwmon* entries are not consistent in their numbering. I believe it’s dependent on driver load order, which is not consistent.

One idea you could perhaps try. So entries in /sys/class/hwmon are actually symlinks as seen here:

$ ls -l /sys/class/hwmon/
total 0
lrwxrwxrwx 1 root root 0 Jul 17 21:09 hwmon0 -> ../../devices/virtual/thermal/thermal_zone0/hwmon0
lrwxrwxrwx 1 root root 0 Jul 17 21:09 hwmon1 -> ../../devices/virtual/thermal/thermal_zone1/hwmon1
lrwxrwxrwx 1 root root 0 Jul 17 21:09 hwmon2 -> ../../devices/platform/soc@0/30800000.bus/30a50000.i2c/i2c-3/3-0040/hwmon/hwmon2
lrwxrwxrwx 1 root root 0 Jan  8  2025 hwmon3 -> ../../devices/platform/soc@0/30800000.bus/30a50000.i2c/i2c-3/3-004f/hwmon/hwmon3
lrwxrwxrwx 1 root root 0 Jul 17 21:09 hwmon4 -> ../../devices/platform/soc@0/32f10100.usb/38100000.usb/38100000.usb:connector/power_supply/usb-charger/hwmon4

Perhaps using the absolute paths in /sys/devices/* could work? These absolute paths should be more consistent since they use the actual device bus addresses which shouldn’t change between boots.

Best Regards,
Jeremias

1 Like
5

Hello @jeremias.tx,

Thank you for your reply.

It’s a good idea to use the /sys/devices/. But I checked online for other idea and create a custom rules with udev seems also a good idea and easier to user with low level C code.

Thank for your support.

Good day,
M

6

Glad you were able to resolve this issue. Udev rules are another good way to have some persistence/control over kernel enumeration.

Best Regards,
Jeremias