On 10/25/24 03:55, Mikael Lund Jepsen wrote:
On 11/11/24 06:24, Guenter Roeck wrote:
On 10/11/24 06:24, Mikael Lund Jepsen wrote:
I'm trying to add ACPI definitions for two i2c-based ads7830 sensors. Problem is that lm-sensor reports both devices as "ads7830-virtual-0", which makes it impossible to define separate configs for multiple sensors of the same type. If I register the sensors via sysfs, lm-sensors reports them as I would expect, with <bus#>-<address> in the chip name (e.g. ads7830-i2c-0-4a).
The adapter on an ACPI defined sensor is being reported as "Virtual device", not "Synopsys DesignWare I2C adapter" as when registered via sysfs, so it seems that the i2c bus is not identified properly in the ACPI case.
I've followed the documentation for ACPI Based Device Enumeration, using PRP0001 as _HID to match the driver via the compatible property:
Device (ADS0)
{
Name (_HID, "PRP0001")
Name (_DSD, Package ()
{
ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
Package ()
{
Package () { "compatible", "ti,ads7830" },
}
})
Method (_CRS, 0, Serialized)
{
Name (SBUF, ResourceTemplate ()
{
I2cSerialBusV2 (0x4a, ControllerInitiated,
100000, AddressingMode7Bit,
"\\_SB.PC00.I2C0", 0x00,
ResourceConsumer, , Exclusive,)
})
Return (SBUF)
}
}
The difference between declaring in ACPI (addr 0x4a) vs. registering via sysfs (addr 0x4b) is clear in /sys/bus/i2c/devices/:
0-004b ->
../../../devices/pci0000:00/0000:00:15.0/i2c_designware.0/i2c-0/0-004b
i2c-0 ->
../../../devices/pci0000:00/0000:00:15.0/i2c_designware.0/i2c-0
...
i2c-PRP0001:00 ->
../../../devices/pci0000:00/0000:00:15.0/i2c_designware.0/i2c-0/i2c-PR
P0001:00
I'm not sure if this is correct behaviour, or if this is a symptom of the Adapter being identified as Virtual rather than an i2c bus adapter.
Does anyone have an idea what I'm doing wrong in my ACPI definition, or is this an issue in the driver/hwmon?
The driver doesn't know anything about ACPI. The identification as virtual device is done by libsensors. That code is supposed to find ACPI devices, but maybe something has changed and that doesn't work anymore. One would have to debug the libsensors code to find a solution.
Note that the driver does not currently support device properties, meaning that reading individual properties from ACPI is not currently supported. There is only a single property, "ti,differential-input", which you don't seem to use, so that probably does not matter. If you do need that property, the driver would have to be updated.
Guenter
Thanks for the suggestion.
I did some debugging of libsensors as suggested, and what I find is that classify_device() gets called with dev_name=i2c-PRP0001:00, not 0-004b, which it tries to parse to find chip.bus.nr and chip.addr. This obviously fails for the ACPI declared sensor.
The dev_name comes from listing nodes under /sys/bus/i2c/devices as far as I can see, so I wonder if this is a sysfs/acpi problem, rather than libsensors?
Theoretically, libsensors could find the bus number from parsing the realpath of the i2c-PRP0001:00 node, but I cannot see how it could find the chip.addr via sysfs the way it is represented now.
When i2c devices are defined in DTS on arm systems, they also get added as <bus.nr>-<chip.addr> nodes (same as when registering via sysfs), so it is only ACPI defined sensors which are represented differently in sysfs.
Should I post this to linux-acpi using a more precise subject, or is there another more suitable list I should try?
I really don't know anything about ACPI, sorry.
Guenter
Thanks,
Mikael
