On Wed, May 01, 2024 at 07:24:08AM +0200, Kenny Levinsen wrote: > 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). Is it possible for a device to be wedged so hard that it refuses to acknowledge the address? > 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 think this depends on the answer to the question above. If there is potential that the chip may stop responding, I still see benefit in differentiating initial "soft touch" poke vs. hard errors once we established that there is/was a device and it started misbehaving. Thanks. -- Dmitry
