> > I am sure this is safe because we have retries. The eeprom driver first tries > > to write data without a delay, because EEPROMs often have buffers. Once the > > buffers are full, the chip will not answer to the next write request which will > > result in a timeout for this write request. This is expected, so it will be > > retried after some delay. Something like -EBUSY. Only if another "outer" > > timeout passed after some retries, then we have a problem and this should be > > user visible. But the timeout for the write request is nothing exceptional and > > the user doesn't need to be informed about it, especially not in this detail. > > This is what the patch is addressing. > > And what if it's not an EEPROM that you're talking to? That's up to the corresponding driver. The driver is still notified via the return value how many i2c-messages could be transmitted. If this is not equal to what the driver intended, then it can decide to retry or notify the user. And that is the apropriate level. Doing all this printout at the bus-driver level is only interesting for developers. Users are frightened by the "timeout" in their logs although everything might be as expected. A bus driver can't know. -- Pengutronix e.K. | Wolfram Sang | Industrial Linux Solutions | http://www.pengutronix.de/ |
Attachment:
signature.asc
Description: Digital signature
