[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <b17dccb5-79f1-a70b-37f6-129e20f27cfc@gmail.com>
Date: Thu, 11 Aug 2022 07:50:49 +0300
From: Matti Vaittinen <mazziesaccount@...il.com>
To: Mark Brown <broonie@...nel.org>
Cc: matti.vaittinen@...rohmeurope.com,
Liam Girdwood <lgirdwood@...il.com>,
linux-kernel@...r.kernel.org
Subject: Re: [RFC PATCH 2/7] regulator: Add devm helpers for get and enable
On 8/10/22 18:16, Mark Brown wrote:
> On Wed, Aug 10, 2022 at 03:19:05PM +0300, Matti Vaittinen wrote:
>
>> In order to tackle the issue the suggested API does not return handle to the
>> regulators - it really just provides the "get'n enable, then forget"
>> solution. The consumers who use the suggested API to "devm get'n enable"
>> will have had time manually controlling the regulator afterwards as they
>> will not get the handle. I would almost claim that the pattern we nowadays
>> see (devm_get, enable, add_action_or_reset(disable())) is more error prone
>> as users seem to in many case be storing the regulator handle w/o any
>> comment about the automated disable at detach.
>
> Hrm, right - that does help with that case. However we do need a bulk
> version since that's an obvious problem case.
I'll take a look at the bulk APIs and add them if they're not too
complex. I'm a bit short on time as I was told I should be doing
something we can show to a customer ;)
As a result of this discussion - not returning the handle to struct
regulator * sounds like a safest option here. I'll drop the RFC when I
respin this (hopefully with the bulk-APIs and a few more converted drivers)
Thanks for the input!
Best Regards
Matti Vaittinen
--
Matti Vaittinen
Linux kernel developer at ROHM Semiconductors
Oulu Finland
~~ When things go utterly wrong vim users can always type :help! ~~
Discuss - Estimate - Plan - Report and finally accomplish this:
void do_work(int time) __attribute__ ((const));
Powered by blists - more mailing lists