Messages in this thread | | | From | Bartosz Golaszewski <> | Date | Fri, 30 Nov 2018 09:35:09 +0100 | Subject | Re: [PATCH 00/10] Regulator ena_gpiod fixups |
| |
czw., 29 lis 2018 o 20:01 Mark Brown <broonie@kernel.org> 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
| |