Re: [PATCH 2/3] i2c/pxa: only define 'blue_murder'-function if DEBUG is #defined

[Wolfram Sang <w.sang-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>]

[-- Attachment #1: Type: text/plain, Size: 1398 bytes --]

> > 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 #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]