lkml.org 
[lkml]   [2019]   [Nov]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH v2] arm64: dts: rockchip: split rk3399-rockpro64, for v2 and v2.1 boards
From
Date
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@katsuster.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@gmail.com>
>>>> Signed-off-by: Katsuhiro Suzuki <katsuhiro@katsuster.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

\
 
 \ /
  Last update: 2019-11-29 00:00    [W:0.044 / U:0.072 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site