Re: [PATCH 00/10] Regulator ena_gpiod fixups

From: Bartosz Golaszewski
Date: Fri Nov 30 2018 - 03:35:23 EST


czw., 29 lis 2018 o 20:01 Mark Brown <broonie@xxxxxxxxxx> napisaÅ(a):
>
> On Thu, Nov 29, 2018 at 07:38:20PM +0100, Bartosz Golaszewski wrote:
>
> > I'm wondering if instead of using the non-devm variants of
> > gpiod_get_*() routines, we shouldn't provide helpers in the regulator
> > framework that would be named accordingly, for example:
> > regulator_gpiod_get_optional() etc. even if all they do is call the
> > relevant gpiolib function. Those helpers could then be documented as
> > passing the control over GPIO lines over to the regulator subsystem.
>
> > The reason for that is that most driver developers will automatically
> > use devm functions whenever available and having a single non-devm
> > function without any comment used in a driver normally using devres
> > looks like a bug. Expect people sending "fixes" in a couple months.
>
> I predict that people would then immediately start demanding devm_
> variants of that function...

At least we could document it in the code.

If I wouldn't know about the reason for not using devm and saw a stray
gpiod_get() without a corresponding put() I'd probably send a patch to
fix it, but if I saw something like regulator_gpiod_get(), I'd look at
what this routine does.

Matter of taste I guess, but I'd prefer the latter. At the very least
we could add a comment to each call saying that the regulator
framework will take care of that resource.

Bart