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@xxxxxx/ which goes back to improving the bus probe.
