Re: [PATCH v3 1/3] HID: i2c-hid: Rely on HID descriptor fetch to probe

Kenny Levinsen
2024-05-01T05:24:16Z

On 4/30/24 11:41 PM, Dmitry Torokhov wrote:
> I actually believe there is. On Chromebooks we may source components
> from several vendors and use them in our devices. The components
> are electrically compatible with each other, have exactly the same
> connector, and therefore interchangeable. Because of that at probe time
> we do not quite know if the device is there at given address, or not
> (i.e. the touchpad could be from a different vendor and listening on
> another address) and we need to make a quick determination whether we
> should continue with probe or not.

Maybe I should clarify what I meant: All I2C operations start with the
master writing the slave address to the bus. When a slave reads its own
address off the bus, it pulls the data line low to ACK. If no device is
present on the bus with the specified address, the line stays high which
is a NACK. This means that on the bus level, we have a clear error
condition specifically for no device with the specified address being
present on the bus.

Whether the operation used is a dummy read or our first actual write
should not matter - if the address is not acknowledged, the device is
not present (or able to talk I2C). The problem lies in whether this "no
device present on bus" error is reported clearly to us: Some drivers use
-ENXIO specifically for this, some use it also for NACKs on written
data, some report it but use other return codes for it, etc.

Even if we stick to the smbus probe in the long run, if we get to the
point where we can rely on the error codes from I2C drivers we would be
able to correctly log and propagate other error classes like bus errors
or I2C driver issues which are all currently silenced as "nothing at
address" by the smbus probe.

> I am not sure we can fully unify what Windows does and what Linux does,
> mainly because our firmwares are different (I think Windows devices do a
> lot more device discovery in firmware, Chrome OS historically tried to
> limit amount of code in its firmware). We also need to make sure it
> works on non-ACPI systems/ARM.

Good point. My main focus is also quirky behaviors we have added to
replicate Windows behavior, the smbus probe just stood out in my bus traces.

I already sent
https://lore.kernel.org/all/20240429233924.6453-1-kl@kl.wtf/ which goes
back to improving the bus probe.