ps: "without knowing if the device is, or is not on the bus ..." On Mon, Apr 15, 2024 at 2:10 PM Radoslaw Biernacki <biernacki@xxxxxxxxxx> wrote: > > Hi Kenny, > > > If the device can enter deep-sleep arbitrarily, then we presumably also > > have problems in i2c_hid_output_raw_report() and > > i2c_hid_get_raw_report() which could happen after the device has gone to > > sleep from inactivity. These places would also need EREMOTEIO retry logic. > > It does not enter deep-sleep arbitrarily and therefore it is not a problem with > other communication patterns. > The design which was chosen back in the day, to save the battery power > is event based > instead of level based (some HW line). Therefore to avoid power leak > we need to request > low power state (to prevent power leak in case the kernel will not > boot up soon). > > Basically we need to take out the device from deep state logic by message, > without knowing if the device is on the bus or it is on the bus but > not responding. > > > > > All these places should have the same sleeping behavior as they are > > working around the same device glitch. I imagine the client ACK timeout > > is longer than your required 400µs, in which case you don't need any > > sleep on retry at all, as is the case in the current i2c_hid_set_power() > > implementation. > > > > However, as we litter retry-code all over the place, Johan's suggestion > > about doing this in the I2C driver does become a bit more relevant... > > > > Best regards, > > Kenny Levinsen > >
