Commits
Hans de Goede committed 7781edaed63
i2c: core: ACPI: Log device not acking errors at dbg loglevel Unfortunately some DSDTs issue bogus i2c reads to non existing devices resulting in -EREMOTEIO errors because the non existing device of course does not ack. This happens e.g. from the The Asus T100TA's _BIX method, the DSDT on the T100TA defines 2 resources on the I2C1 bus: Name (EHID, ResourceTemplate () { I2cSerialBusV2 (0x005B, ControllerInitiated, 0x00061A80, AddressingMode7Bit, "\\_SB.I2C1", 0x00, ResourceConsumer, , Exclusive, ) }) OperationRegion (EHOR, GenericSerialBus, Zero, 0x0100) Field (EHOR, BufferAcc, NoLock, Preserve) { Connection (EHID), Offset (0x01), AccessAs (BufferAcc, AttribBytes (0x10)), ABCD, 8 } Name (UMPC, ResourceTemplate () { I2cSerialBusV2 (0x0066, ControllerInitiated, 0x00061A80, AddressingMode7Bit, "\\_SB.I2C1", 0x00, ResourceConsumer, , Exclusive, ) }) The _BIX method does a single read (on each BIX() call) from the EHID device through the ABCD Field, only to completely ignore the result. This read always fails as there is no i2c client at address 0x5b. The _BIX method also does several reads from the UMPC device and actually uses the results of those to provide battery information. IIRC I've also seen some DSTDs which do an i2c read to detect if a device is present, also leading to false positive errors being logged. Esp. the _BIX use is problematic as the _BIX method gets called periodically to monitor battery status. This commit stops the logs from filling up with errors like these: [ 57.327858] i2c i2c-0: i2c read 16 bytes from client@0x5b starting at reg 0x1 failed, error: -121 Signed-off-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Wolfram Sang <wsa@the-dreams.de>