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-PRP0001: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
