Hi Jonathan,
On 10/9/22 15:24, Jonathan Cameron wrote:
On Thu, 6 Oct 2022 19:17:39 +0300
Andy Shevchenko <andriy.shevchenko@xxxxxxxxxxxxxxx> wrote:
On Thu, Oct 06, 2022 at 05:36:52PM +0300, Matti Vaittinen wrote:
A few regulator consumer drivers seem to be just getting a regulator,
enabling it and registering a devm-action to disable the regulator at
the driver detach and then forget about it.
We can simplify this a bit by adding a devm-helper for this pattern.
Add devm_regulator_get_enable() and devm_regulator_get_enable_optional()
...
(cherry picked from commit b6058e052b842a19c8bb639798d8692cd0e7589f)
Not sure:
- why this is in the commit message
- what it points to, since
$ git show b6058e052b842a19c8bb639798d8692cd0e7589f
fatal: bad object b6058e052b842a19c8bb639798d8692cd0e7589f
These are now upstream in Linus' tree and in my testing branch.
I'd not normally advocate working on top of that (because I rebase it), but
if it is useful for this series go ahead.
Thanks for the explanation :)
This series will conflict with my fixup series for triggered-buffer
attributes. Hence I though I might combine these two series into one if
I need to respin the fixup series. I thought of using the v6.1-rc1 when
it is out. (I think the 6.1-rc1 should not be that far away)
OTOH, I just read your another mail which told that there will be one
more driver which will conflict with the fixup coming in during this
cycle. If that driver lands in your tree before the fix - then I guess I
need to rebase the fixup series (and maybe this too) on top of your tree
+ add conversion of this new driver. I don't think that would be the
testing branch though(?)
Yours
-- Matti
--
Matti Vaittinen
Linux kernel developer at ROHM Semiconductors
Oulu Finland
~~ When things go utterly wrong vim users can always type :help! ~~
