linux-kernel - Re: [PATCH v2 0/2] Slightly improve hardware description of Pine64 RockPro64

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]

Message-ID: <2630232.Icojqenx9y@diego>
Date: Tue, 04 Mar 2025 22:52:22 +0100
From: Heiko Stübner <heiko@...ech.de>
To: Dragan Simic <dsimic@...jaro.org>
Cc: linux-rockchip@...ts.infradead.org, linux-arm-kernel@...ts.infradead.org,
 linux-kernel@...r.kernel.org, devicetree@...r.kernel.org, robh@...nel.org,
 krzk+dt@...nel.org, conor+dt@...nel.org, didi.debian@...ow.org, chris@...de
Subject:
 Re: [PATCH v2 0/2] Slightly improve hardware description of Pine64 RockPro64

Am Dienstag, 4. März 2025, 07:44:59 MEZ schrieb Dragan Simic:
> Hello Heiko,
> 
> On 2025-03-03 23:36, Heiko Stuebner wrote:
> > On Sun, 02 Mar 2025 19:48:02 +0100, Dragan Simic wrote:
> >> This is a small series that introduces small improvements to the way
> >> Pine64 RockPro64 [1] single-board-computer is described in the DT 
> >> files.
> >> This applies to both production-run revisions of the RockPro64.
> >> 
> >> The introduced improvements boil down to eliminating some warnings 
> >> from
> >> the kernel log, by adding a previously undefined regulator and by 
> >> adding
> >> some previously missing references to the regulators.
> >> 
> >> [...]
> > 
> > Applied, thanks!
> > 
> > [1/2] arm64: dts: rockchip: Add avdd HDMI supplies to RockPro64 board 
> > dtsi
> >       commit: bd1c959f37f384b477f51572331b0dc828bd009a
> > [2/2] arm64: dts: rockchip: Add missing PCIe supplies to RockPro64 
> > board dtsi
> >       commit: 64ef4a4320e7aa3f0f267e01f170f52b90bf0b1b
> > 
> > I've moved the pcie12v supply up one line.
> > While in a mathematical sense it's true 12 > 3.3, we're sorting
> > alphabetical, so it's 1?? < 3?? .
> > 
> > And yes I sympathize with 3.3 < 12, but also have come to appreciate 
> > not
> > having overly many special cases :-)
> 
> Great, thanks! :)
> 
> I'm fine with the alphabetical ordering, albeit with some caveats
> described below, but the following part of the patch description
> should also be removed, if possible, so the patch description fully
> matches the introduced changes:
> 
>    Shuffle and reorder the "vpcie*-supply" properties a bit, so they're 
> sorted
>    alphanumerically, which is a bit more logical and more useful than 
> having
>    these properties listed in their strict alphabetical order.

I've amended the commit, dropping this block

> I'm hoping you'll agree that specifying alphanumerical ordering
> for the properties in the DTS coding style is the way to go, just
> like it's already specified for the ordering of the nodes.  I'll
> go ahead and submit an appropriate patch for the DT guidelines.

vpcie0v9-supply = <&vcca_0v9>;
vpcie1v8-supply = <&vcca_1v8>;
vpcie3v3-supply = <&vcc3v3_pcie>;
vpcie12v-supply = <&vcc12v_dcin>;

In the end I don't care _that_ much, but personally I find that
alphanumerical ordering harder to read ;-) .

Because in the example above, my mind now constantly shouts
"why is vpcie1... after vpcie3... ..... ooooh right, it's alpha-numerical"

But I can live with it I guess ;-) .
As 3.3 is smaller than 12 afterall.


Heiko