[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <64f539b5-30b2-c0b7-17bf-c448b507713e@wolfvision.net>
Date: Sat, 29 Jan 2022 10:59:32 +0100
From: Michael Riesch <michael.riesch@...fvision.net>
To: Piotr Oniszczuk <piotr.oniszczuk@...il.com>,
Peter Geis <pgwipeout@...il.com>
Cc: "linux-arm-kernel@...ts.infradead.org"
<linux-arm-kernel@...ts.infradead.org>,
"open list:ARM/Rockchip SoC..." <linux-rockchip@...ts.infradead.org>,
"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
Rob Herring <robh+dt@...nel.org>,
Heiko Stuebner <heiko@...ech.de>,
Nicolas Frattaroli <frattaroli.nicolas@...il.com>,
Liang Chen <cl@...k-chips.com>
Subject: Re: [PATCH 1/2] arm64: dts: rockchip: rename and sort the rk356x usb2
phy handles
Hello Peter and Piotr,
On 1/29/22 10:23, Piotr Oniszczuk wrote:
>
>
>>
>> Good Evening,
>>
>> While I'm not against this idea, my main concern still stands.
>> I spent a great deal of thought on this, and decided to go the route I
>> did to maintain consistency with previous generations.
>> As such, I see one of three paths here:
>> - Pull this patch only and depart rk356x from previous SoCs.
>> - Do the same for previous SoCs to maintain consistency.
>> - Drop this patch to maintain consistency with previous SoCs.
>>
>> I ask that others weigh in here, as offline discussion has produced
>> mixed results already.
>
> just pure user perspective
>
> (who spent last weeks considerable time to develop DT for rk3566 tvbox. 99% of my work was by reading/learning from other boards existing DT's. Any inconsistencies in DTs makes work for such ppl like me much more harder):
>
> For option 1 - i don't see value
> For option 2 - what is reward for extra work needs to be done on all other SoCs?
>
> so option 3 seems to be natural choice...
>
> in other words:
>
> for me:
> option 1 brings practically zero value + increased inconsistency.
> option 2: extra work - but consistency is like in option 3 (so where is value?)
>
> so option 3 offers the same consistency - but without extra work...
>
> just my 0.02$
Of course this change is purely cosmetic and it is reasonable to ask for
the practical value. It is just that technically the quartz64 dts is not
sorted alphabetically at the moment. The u2phy* nodes should be but
before the uart* nodes to follow the convention. On the other hand, it
may be nice to have the usb2 phys and controllers grouped in the dts.
The proposed renaming would allow all the mentioned nodes sorted
alphabetically and grouped logically.
Therefore I had option 1 in mind. I don't see any dependencies between
the different SoCs and think we can make a fresh start here.
Option 2 is not really feasible, we would almost definitely break
something existent.
Option 3 is feasible, of course. However, I would sort the nodes
alphabetically (u2phy*, then uart*, then usb*). Works for me as well,
although it is not that nice IMHO.
Since many boards with the RK3566 and RK3568 will pop up in near future
we should do the change right now (if we want to do it), as of course
all the board files need to be changed. Therefore I wanted to bring this
matter up now. Let's agree on something and move on.
Best regards,
Michael
Powered by blists - more mailing lists