[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <74655775-a8e2-45f4-8a1b-8046dffa5520@gmail.com>
Date: Fri, 3 May 2024 07:54:21 +0300
From: Matti Vaittinen <mazziesaccount@...il.com>
To: Conor Dooley <conor@...nel.org>
Cc: Matti Vaittinen <matti.vaittinen@...rohmeurope.com>,
Lee Jones <lee@...nel.org>, Rob Herring <robh@...nel.org>,
Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
Conor Dooley <conor+dt@...nel.org>, Liam Girdwood <lgirdwood@...il.com>,
Mark Brown <broonie@...nel.org>, Wim Van Sebroeck <wim@...ux-watchdog.org>,
Guenter Roeck <linux@...ck-us.net>, devicetree@...r.kernel.org,
linux-kernel@...r.kernel.org, linux-watchdog@...r.kernel.org
Subject: Re: [PATCH v1 1/6] dt-bindings: ROHM BD96801 PMIC regulators
Hi Conor,
On 5/2/24 19:20, Conor Dooley wrote:
> On Tue, Apr 30, 2024 at 02:59:50PM +0300, Matti Vaittinen wrote:
>> ROHM BD96801 is a highly configurable automotive grade PMIC. Introduce
>> DT bindings for the BD96801 regulators.
>>
>> Signed-off-by: Matti Vaittinen <mazziesaccount@...il.com>
>>
>> ---
>> RFCv2 => v1
>
> RFC is a status, not a version - ideally this would have been v3 and the
> next version v4.
Thanks for the clarification. I've always wondered if an RFC should be
seen as a separate series. Previously I've ended up just dropping the
RFC and pumping up the version. This time the switch from RFC => non RFC
was somewhat radical as a lot of the features were dropped. Furthermore,
I've developed the 'simple' version (this non RFC one) and
'experimental' version (the RFC one) in separate branches - which made
the separation even stronger in my mind - I probably started thinking
these as two different patch series.
But, as I said, thanks for the clarification! I guess it's still better
to make next version v2 (and not v4) to not add even more confusion...
>> - Drop regulator-name pattern requirement
>> - do not require regulator-name
>
>
> Krzysztof had some comments on the buck/ldo node names
I think Krzysztof pointed out that the regulator-name property should
not match the data-sheet but the board. If he had something to say about
the node names, then I've missed his comment!
> and on the
> initial value properties that I'm not sure if have been addressed, so
> gonna leave this series to him.
Thanks for pointing out I may have missed addressing some of his
concerns. I though I fixed all issues he pointed to me but it may be I
missed some - or accidentally dropped some change(s) when merging fixes
from the 'experimental' branch to the 'simple'. I'll revise Krzysztof's
feedback to the RFC before sending the next version!
Thanks!
Yours,
-- Matti
--
Matti Vaittinen
Linux kernel developer at ROHM Semiconductors
Oulu Finland
~~ When things go utterly wrong vim users can always type :help! ~~
Powered by blists - more mailing lists