lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
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

Powered by Openwall GNU/*/Linux Powered by OpenVZ