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

[Dragan Simic]

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