Re: [PATCH] regulator: core: Fix enable GPIO reference counting

[Doug Anderson]

Mark,

On Mon, Mar 2, 2015 at 10:47 AM, Mark Brown <broonie@xxxxxxxxxx> wrote:
> On Fri, Feb 27, 2015 at 11:41:03AM -0800, Doug Anderson wrote:
>> It is possible for _regulator_do_enable() to be called for an
>> already-enabled rdev, like in regulator_suspend_finish().  If we were
>> using an enable pin (rdev->ena_pin is set) then we'd end up
>> incrementing the reference count in regulator_ena_gpio_ctrl() over and
>> over again without a decrement.  That prevented the GPIO from going to
>> the "off" state even after all users were disabled.
>
>> Fix this by avoiding the call to regulator_ena_gpio_ctrl() when it's
>> not needed.
>
> There's a big jump in this changelog where you assert that we're
> avoiding the call "when it's not needed" without explaining the
> situations in which this is the case or why.
>
> Looking at the code it seems that you're adding checks to skip calls in
> the standard enable and disable paths but not touching other paths,
> based on this patch by itself I can't tell if this is a good idea or
> not.  It certainly doesn't feel robust - if we're missing reference
> counting skipping operations seems likely to lead to other bugs popping
> up elsewhere when the other user that isn't doing a disable currently
> decides to start doing so.

I guess it depends on whether _regulator_do_enable() on an
already-enabled rdev is supposed to be a noop or not.  My assumption
was that it was supposed to be a noop with reference counting handled
by _regulator_enable().

My assumption is that regulator drivers themselves shouldn't do
reference counting.  That is: if you call
rdev->desc->ops->enable(rdev) twice you should not have to call
rdev->desc->ops->disable(rdev) twice to disable.  Right?  That means
my fix is making the "ena_pin" symmetric to how normal regulator
drivers work.

The refcounting being skipped by my patch is refcounting that's used
only when the same GPIO is shared by more than one regulator.  That
is, if "vcc_a" uses GPIO1 and "vcc_b" also uses "GPIO1" we need
refcounting.  GPIO1 will be in the "on" state if either vcc_a or vcc_b
is on.  The problem came in because _regulator_do_enable() was
incrementing the shared refcount every time it was called even if the
specific regulator was already on.


Anyway, I looked at Javier's patch and it's also fine / reasonable.
...and in fact I would argue that possibly we could take both patches.
Javier's patch eliminates the one known place where
_regulator_do_enable() is called for an already-enabled regulator and
my patch means that if someone else adds a new call we won't end up
back in this same subtle bug.  I'm happy to update the CL desc to make
it more obvious if you'd like.

-Doug
--
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/