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] [day] [month] [year] [list]
Message-ID: <40aed1a2c3d4015881694e847beca683@manjaro.org>
Date: Wed, 05 Mar 2025 05:06:41 +0100
From: Dragan Simic <dsimic@...jaro.org>
To: Heiko Stübner <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-04 22:52, Heiko Stübner wrote:
> Am Dienstag, 4. März 2025, 07:44:59 MEZ schrieb Dragan Simic:
>> 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

Thanks!

>> 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.

Oh, I know very well first-hand how alphanumerical ordering may
look and feel strange at first... :)

I used ls(1) without the "-v" option for many, many years, and the
things looked a bit strange after I decided to add "-v" to its set
of options at some point, but after a short period of getting used
to it, alphanumerical sorting became so logical and useful to me that
alphabetical ordering is actually now harder to read and is looking
a bit strange to me. :)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ