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: <757afa87255212dfa5abf4c0e31deb08@manjaro.org>
Date: Tue, 04 Mar 2025 07:44:59 +0100
From: Dragan Simic <dsimic@...jaro.org>
To: Heiko Stuebner <heiko@...ech.de>
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

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.

Admittedly, the patch itself indeed looks nicer [1] with the
alphabetical ordering, :) (which is quasi-alphabetical, actually,
please see below) but it might be better to have the DT guidelines
adjusted to specify alphanumerical ordering as well.  Even ls(1)
can sort filenames alphanumerically, with its "-v" option that
performs "natural sort of (version) numbers within text". [2]

The real trouble is that, if we were to apply the alphabetical
ordering strictly, we'd end up with the following order of node
properties in which 12 is before 1.8 and 3.3, which IMHO doesn't
make much sense:

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

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.

[1] 
https://web.git.kernel.org/pub/scm/linux/kernel/git/mmind/linux-rockchip.git/commit/?id=64ef4a4320e7aa3f0f267e01f170f52b90bf0b1b
[2] https://man.archlinux.org/man/ls.1.en#v