Re: [PATCH 01/11] MFD: DA9052 MFD core module v2

[Mark Brown <broonie@opensource.wolfsonmicro.com>]

On Thu, Jul 21, 2011 at 10:40:23PM +0200, Arnd Bergmann wrote:
> On Thursday 21 July 2011 16:47:48 Mark Brown wrote:

> > Although the bigger problem is why are these interruptible?  That's
> > very unusual.

> Well, the default should really be to use _interruptible or at least
> _killable with the appropriate error handling, and only use noninterruptible
> locks  in cases where that's not possible.

> In the funtions that Shawn pointed out, there is an error return, so it would
> be possible to do that, but the callers would need to be audited carefully.

We went round this analysis already with the underlying I2C drivers
(which also end up needing to take mutexes and so on) - it really does
work out better to just make the I/O noninterruptible, the I/O is fast
enough to not really be worth interrupting and the handling for actual
I/O errors should normally be sufficiently different to that for user
initiated aborts that it just adds complication.

For example, if the user interrupts while we're in the middle of some
lengthy series of operations or wait what we really want to do is to
tear down the high level thing we're doing in an orderly fashion.  If
we allow the interrupt to be noticed as part of an I/O operation then
what we often end up doing is failing that and we then have to work out
why the I/O failed, if actually happened on a physical level and how we
deal with that.  Usually none of these paths will be well tested.

The overall result is that the system generally becomes more complicated
and less robust.