Re: Deterministic device paths for ACPI instantiated hwmon devices

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 12/11/23 18:52, Chris Packham wrote:
Hi,

We're looking at our first in-house modular product using an x86_64 CPU.
Previously we've done other products using other various embedded CPU
architectures which make use of a device tree for describing the hardware.

We've got some userspace code which tries to present end-user consumable
names for various hardware monitors on removable modules (e.g.
"temperature sensor 1 on the card in bay 3").

We do this based on knowing the deterministic path of the device in
sysfs (e.g. /sys/devices/platform/soc/i2c0/lm75@2e) that works fine for
devices instantiated on a device tree aware system (using device-tree
overlays). However we've yet to find any way of getting a deterministic
path out of devices instantiated via ACPI overlays. For now we've been
using the `/sys/class/hwmon/hwmonN/device` paths but the N depends on
the order the hardware was discovered which may not be the order the
end-user expects.

Is there a way of inferring/influencing the numbering that gets used in
the `/sys/devices/LNXSYSTM:00/LNXSYBUS:00/AMDI0010:00/` paths that
appear when the devices get instantiated?


Did you try sensors_get_detected_chips() from libsensors ?

Guenter





[Index of Archives]     [LM Sensors]     [Linux Sound]     [ALSA Users]     [ALSA Devel]     [Linux Audio Users]     [Linux Media]     [Kernel]     [Gimp]     [Yosemite News]     [Linux Media]

  Powered by Linux