Some ACPI systems list 2 I2C resources for the CM3218 sensor. On these
systems the first I2cSerialBus ACPI-resource points to the SMBus Alert
Response Address (ARA, 0x0c) and the second I2cSerialBus ACPI-resource
points to the actual CM3218 sensor address:
Method (_CRS, 0, NotSerialized) // _CRS: Current Resource Settings
{
Name (SBUF, ResourceTemplate ()
{
I2cSerialBusV2 (0x000C, ControllerInitiated, 0x00061A80,
AddressingMode7Bit, "\\_SB.I2C3",
0x00, ResourceConsumer, , Exclusive,
)
I2cSerialBusV2 (0x0048, ControllerInitiated, 0x00061A80,
AddressingMode7Bit, "\\_SB.I2C3",
0x00, ResourceConsumer, , Exclusive,
)
Interrupt (ResourceConsumer, Level, ActiveHigh, Exclusive, ,, )
{
0x00000033,
}
})
Return (SBUF) /* \_SB_.I2C3.ALSD._CRS.SBUF */
}
Detect this and take the following step to deal with it:
1. When a SMBus Alert capable sensor has an Alert asserted, it will
not respond on its actual I2C address. Read a byte from the ARA
to clear any pending Alerts.
2. Create a "dummy" client for the actual I2C address and
use that client to communicate with the sensor.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
c1e62062ff