Re: [PATCH] regulator core: fix double-free inregulator_register() error path

[Mark Brown]

On Tue, Apr 28, 2009 at 04:47:52AM -0700, David Brownell wrote:
> On Tuesday 28 April 2009, Mark Brown wrote:
> > On Tue, Apr 28, 2009 at 02:32:56AM -0700, David Brownell wrote:

> > > > > What it lacks is something entirely different: ?driver support
> > > > > for the LCD which uses the regulator framework,

> > > > It's not VAUX3 that it's saying has incomplete constraints, it's the
> > > > board as a whole - if the constraints for the board were fully specified

> > > No; driver support != constraint.  Only one of the
> > > issues is packaged as a "constraint".

> > Driver support isn't particularly relevant here.

> It's the *entire* point.  The driver is talking directly
> to the regulator, bypassing this framework.  The constraints
> on that regulator are fully defined ... and then bypassed.

Ah, I see - I didn't realise that there was driver support that doesn't
use the regulator API, that had been dropped out of context by that
point in the discussion.  I guess the LCD driver will be converted to
use the API in due course, hopefully there aren't too many other such
drivers.

This is the sort of use case that made me not want to have the API
disable unused regulators by default - there's stuff going on that the
regulator API and the code using it doesn't know about (since it's going
through some other interface to do the job in this case) so the API
can't safely do anything to that regulator.

> > > How about:  "VAUX3 board support is incomplete".
> > > That's accurate.

> > No.  The constraints being complete is a property of the board as a
> > whole and not the particular regulator.

> Except ... that "constraint" isn't the issue, it's
> unexpected driver behavior.  And "board" is exactly

This is sufficiently unexpected that it's the first time I've seen
anything bypassing the regulator API; in any case, it's just a question
of where you see the problem coming from.

My terminology comes from the fact that as far as the core is concerned
the issue is that the board didn't say it had given the core complete
constraints allowing it to fully control the regulators that are visible
to it.  The reason the board didn't do that is that is that the LCD
driver is bypassing the regulator API and the regulator API doesn't have
any way to express that possibility.

> what I said, so I don't know why you're arguing.
> (For the "fun" of it?)

David, that is really not necessary or constructive.  This sort of
disparaging remark has been a constant feature of your interactions on
regulator API issues and it is not achieving anything useful.

> Board support includes full driver support, as well
> as board setup (constraints).  That's the common way
> to factor it, at any rate -- a "board support package"
> addresses both, and they need to work together.

s/board/machine driver/; in an ideal world for Linux there is no BSP,
it's all mainline.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/