Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
From:   Heiko =?ISO-8859-1?Q?St=FCbner?= <heiko@sntech.de>
To:     Piotr Oniszczuk <piotr.oniszczuk@gmail.com>,
        Peter Geis <pgwipeout@gmail.com>,
        Michael Riesch <michael.riesch@wolfvision.net>
Cc:     "linux-arm-kernel@lists.infradead.org" 
        <linux-arm-kernel@lists.infradead.org>,
        "open list:ARM/Rockchip SoC..." <linux-rockchip@lists.infradead.org>,
        "devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        Rob Herring <robh+dt@kernel.org>,
        Nicolas Frattaroli <frattaroli.nicolas@gmail.com>,
        Liang Chen <cl@rock-chips.com>
Subject: Re: [PATCH 1/2] arm64: dts: rockchip: rename and sort the rk356x usb2 phy handles
Date:   Sun, 30 Jan 2022 12:02:16 +0100
Message-ID: <14752572.ChuAC8jng2@diego>
In-Reply-To: <d203569c-bae1-c35a-204a-53617170d3b3@wolfvision.net>
References: <20220127190456.2195527-1-michael.riesch@wolfvision.net> <3736463.EBuT6JFcjP@diego> <d203569c-bae1-c35a-204a-53617170d3b3@wolfvision.net>
MIME-Version: 1.0
Content-Transfer-Encoding: 8BIT
Content-Type: text/plain; charset="iso-8859-1"
Precedence: bulk

Am Sonntag, 30. Januar 2022, 10:56:08 CET schrieb Michael Riesch:
> Hello Heiko,
> 
> On 1/29/22 16:28, Heiko St?bner wrote:
> > Am Samstag, 29. Januar 2022, 10:59:32 CET schrieb Michael Riesch:
> >> 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.
> > 
> > correct :-) .
> > 
> > I do see each SoC individually and while I try to have people follow some
> > styling guidelines everywhere (ordering of properties, ordering of nodes)
> > I don't really want people to fear what some other SoC has done before.
> > 
> > But even these rules evolve sometimes, when something seems to work
> > better than before.
> > 
> > We have nowadays 9 years of Rockchip SoC history in the kernel.
> > Thanks to general dt-binding conventions most nodes have specific
> > names anyway (mmc@... etc), but for example trying to rename stuff
> > in older SoCs that has worked for years now is for one error-prone
> > as Michael pointed out, but also introduces unnecessary churn,
> > when these old SoCs (thinking of rk3188, rk3288 and friends but also things
> > like the rk3368) are essentially "finished" and most likely won't see that
> > much additional support for stuff added.
> 
> So... may I take it that you are going to apply the patches in this series?

that was the intention behind that "wall of text" :-D

Heiko


> Or should I switch to option 3 and re-submit?
> 
> Thanks and best regards,
> Michael
> 
> > 
> > 
> > Heiko
> > 
> > 
> >> 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
> >>
> > 
> > 
> > 
> > 
>