On Sun, Apr 18, 2010 at 03:22:51PM +0200, Wolfram Sang wrote: > > Sorry to bump this old thread, it dropped off my todo-list :( > > On Sun, Feb 28, 2010 at 03:55:02PM +0000, Russell King - ARM Linux wrote: > > On Wed, Feb 24, 2010 at 12:01:45PM +0100, Uwe Kleine-König wrote: > > > From: Wolfram Sang <w.sang@xxxxxxxxxxxxxx> > > > > > > This talkative function is also called on timeouts. As timeouts can > > > happen on regular writes to EEPROMs (no error case), this creates false > > > positives. Giving lots of details is interesting only for developers > > > anyhow, so just use the function if DEBUG is #defined. > > > > Are you sure this is safe? If you time out the write before it completes, > > how do you know if the write was successful? > > > > I don't think this is "no error code" nor "false positive". If the timeout > > is too short for your EEPROMs, then the timeout needs to be increased. > > 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? -- To unsubscribe from this list: send the line "unsubscribe linux-i2c" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
