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? 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 >> > > > >
