linux-kernel - Re: [PATCH v2] arm64: dts: rockchip: split rk3399-rockpro64, for v2 and v2.1 boards

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]

Date:   Thu, 28 Nov 2019 23:59:37 +0100
From:   Soeren Moch <smoch@....de>
To:     Heiko Stuebner <heiko@...ech.de>
Cc:     Katsuhiro Suzuki <katsuhiro@...suster.net>,
        Vasily Khoruzhick <anarsoul@...il.com>,
        linux-rockchip@...ts.infradead.org,
        arm-linux <linux-arm-kernel@...ts.infradead.org>,
        linux-kernel <linux-kernel@...r.kernel.org>,
        Hugh Cole-Baker <sigmaris@...il.com>
Subject: Re: [PATCH v2] arm64: dts: rockchip: split rk3399-rockpro64, for v2
 and v2.1 boards

On 28.11.19 22:53, Heiko Stuebner wrote:
> Am Donnerstag, 28. November 2019, 20:55:54 CET schrieb Soeren Moch:
>>> On Thu, Nov 28, 2019 at 6:02 AM Katsuhiro Suzuki
>>> <katsuhiro@...suster.net> wrote:
>>>> This patch splits rk3399-rockpro64 dts file to 2 files for v2 and
>>>> v2.1 boards.
>>>>
>>>> Both v2 and v2.1 boards can use almost same settings but we find a
>>>> difference in I2C address of audio CODEC ES8136.
>>>>
>>>> Reported-by: Vasily Khoruzhick <anarsoul@...il.com>
>>>> Signed-off-by: Katsuhiro Suzuki <katsuhiro@...suster.net>
>>>>
>>>> ---
> [...]
>
>>>> diff --git a/arch/arm64/boot/dts/rockchip/rk3399-rockpro64.dtsi b/arch/arm64/boot/dts/rockchip/rk3399-rockpro64.dtsi
>>>> new file mode 100644
>>>> index 000000000000..183eda4ffb9c
>>>> --- /dev/null
>> If we add this as new file, should we sort handles and properties
>> alphabetically, where it is not done yet?
> I'm torn here ... on one side, doing missing sorting might be nice
> on the other hand, there is the moving without functional changes
> paradigm, which is generally nice to adhere to.
Agreed. Since we don't move a file, but most of it's content, it was not
clear to me what's more important.
>
> But I guess sorting would generally be ok.
>
>> I'm not sure about all the exceptions that usually apply for rockchip
>> devicetrees, status property at the end, also the pinctrl node?
> In general I don't "enforce" the sorting, so don't reject patches but instead
> just do sorting myself if necessary ;-).
>
> The general rule-of-thumb for nodes we came up with during the rk3288-veyron
> era is something like:
>
> compatible
> reg
> interrupts
> [alphabetical properties]
> status
>
> as this makes it somewhat easier to parse the core properties (compatible,
> reg, ints, status] when scrolling through a devicetree :-) .
Thanks for your explanation, perfectly makes sense.
>
> Pinctrl position is at the discretion of the dt author :-D .
> Position at the end has just the advantage that a long pin-group list does
> not get in the way so much.
>
>> What about unused references, e.g. "fan"?
> Don't change too much when moving stuff around :-)
Yes, good compromise to do some sorting, but no other changes.

Thanks,
Soeren