Message-Id: <200907221403.07985.david-b@pacbell.net>
Date:	Wed, 22 Jul 2009 14:03:07 -0700
From:	David Brownell <david-b@...bell.net>
To:	Mark Brown <broonie@...nsource.wolfsonmicro.com>
Cc:	Eric Miao <eric.y.miao@...il.com>,
	Daniel Ribeiro <drwyrm@...il.com>,
	Pierre Ossman <pierre@...man.eu>,
	"linux-kernel" <linux-kernel@...r.kernel.org>,
	"openezx-devel" <openezx-devel@...ts.openezx.org>,
	Liam Girdwood <lrg@...mlogic.co.uk>,
	"linux-arm-kernel" <linux-arm-kernel@...ts.arm.linux.org.uk>
Subject: Re: [PATCH 1/2] MMC/pxamci: workaround regulator framework bugs

On Wednesday 01 July 2009, Mark Brown wrote:
> On Tue, Jun 30, 2009 at 07:36:20PM -0700, David Brownell wrote:
> > On Monday 29 June 2009, Mark Brown wrote:
> 
> > > At the minute the regulator API actually copes pretty well with this -
> > > the only problem I'm aware of is with drivers like the MMC driver which
> > > require exclusive control of the regulator.
> 
> > Which is a fairly typical situation for power-aware drivers.
> 
> As has been mentioned a number of times in previous discussions of this
> there is a very large class of devices which do not *require* any power
> control at all but which can usefully switch their supplies on and off.

Which I never argued with.  My comment was about their drivers.

Power-aware drivers may *require* that they can actually reduce
system power consumption ... else what's the point?  Likewise,
switching voltages needs care, and sometimes ability to switch
power on and off.


> > Which belies your claim that the regulator API "copes pretty well".
> > It'd be more accurate to say "broken-as-designed", since you have
> > rejected numerous attempts to fix this, yet not fixed it yourself.
> 
> You've suggested variations of essentially one approach, forcing the
> regulator to be off while the use count is zero.

For the record, that's simply not true.  The patches I sent tried
a variety of approaches, and I don't recall that ever being one of
them ... since that is in fact a fair description of what needed to
be FIXED.  The property my patches shared was:

	/* that this simple idiom would finally work */
	if (regulator_is_enabled(r))
		regulator_disable(r);

It's *your* proposals which preserved the property that the above
lines of code could fail (often rudely at boot time).  Until just
yesterday... when you posted

  http://marc.info/?l=linux-kernel&m=124818844611060&w=2

which is intended to provide a new mechanism, the only way to
ensure the above idiom can always work.  It looks like that will
work for $SUBJECT (MMC/SD drivers) and some similar cases.


> I have previously had to ask you to try to approach discussions on the
> regulator API in a more constructive fashion, please let me renew that
> request.  Doing so would be much less time consuming and for that reason
> if nothing else would be very helpful in progressing things.

I've previously had to ask you to respond to **what I said** not
to something you merely imagined I had said.  Don't pretend that
you were blameless.  Your approach was highly confrontational,
and rejected many constructive suggestions.  At one point you
flamed me for disagreeing ... with the point *I* was making, as
eventually became clear.

If you felt my responses were sufficiently non-constructive as to
deserve a lecture on courtesy ... you ought to have considered your
own participation.  What you saw was a rising tide of frustration
caused by (a) your refusal to address what I was actually saying,
(b) your falsely attributing statements and viewpoints to me, and
(c) rejecting around half a dozen patches to solve a problem, all
of which were within (d) an ever-increasing number of constraints
you grew with each new iteration.  I had to try so many different
approaches since nothing seemed to be getting through.  The lack
of constructive behavior was mostly on *your* part ... but when I
finally called you on that, I got a lecture back!!  Feh.  I don't
need to let such crap stand; but decided to wait until the anger
went away.

So it's no surprise I would conclude the only solution was to wait
for you to write a patch, which you would then accept.  And you
have now done that; thanks.

- Dave


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists