On Fri, Nov 21, 2014 at 6:24 PM, Robert Jarzmik <robert.jarz...@free.fr> wrote:
> Felipe Balbi <ba...@ti.com> writes:
>
>> On Sun, Nov 09, 2014 at 03:58:14PM +0100, Robert Jarzmik wrote:
>>> + if (!enabled) {
>>> + ret = regulator_enable(vbus_draw);
>>> + if (ret < 0)
>>> + return;
>>> + nop->vbus_draw_enabled = 1;
>>
>> do you really need this flag here ? How about:
>>
>> if (regulator_is_enabled(vbus_draw))
>> foo();
> Good question, I copy-pasted that code from gpio-vbus...
> Philipp, do you have an insight here ?
Regulator refcounting is per regulator_dev, not per struct regulator,
so for multiple consumer scenarios it is necessary to either balance
enable/disable calls, or, if that can't be guaranteed, the consumer
has to keep its own enable flag. The latter is the case for the vbus_draw
callback.
Also regulator_is_enabled does not just return (refcount > 0),
but might try to read the actual regulator hardware state (and fail),
depending on the regulator driver.
While I can't see a reason to ever share the vbus_draw regulator with
another consumer, and for gpio regulators regulator_is_enabled never
fails, so for the current users relying on regulator_is_enabled should
work here, I think keeping the flag is the safe thing to do.
regards
Philipp
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
