Linux-Rockchip Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Michael Riesch <michael.riesch@wolfvision.net>
To: Piotr Oniszczuk <piotr.oniszczuk@gmail.com>,
	Peter Geis <pgwipeout@gmail.com>
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>,
	Heiko Stuebner <heiko@sntech.de>,
	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: Sat, 29 Jan 2022 10:59:32 +0100	[thread overview]
Message-ID: <64f539b5-30b2-c0b7-17bf-c448b507713e@wolfvision.net> (raw)
In-Reply-To: <FBB7C392-C5E0-4E34-AC17-5323414623F5@gmail.com>

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

_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip

  reply	other threads:[~2022-01-29  9:59 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-01-27 19:04 [PATCH 1/2] arm64: dts: rockchip: rename and sort the rk356x usb2 phy handles Michael Riesch
2022-01-27 19:04 ` [PATCH 2/2] arm64: dts: rockchip: add usb2 support to rk3568-evb1-v10 Michael Riesch
2022-01-27 23:32 ` [PATCH 1/2] arm64: dts: rockchip: rename and sort the rk356x usb2 phy handles Peter Geis
2022-01-29  9:23   ` Piotr Oniszczuk
2022-01-29  9:59     ` Michael Riesch [this message]
2022-01-29 15:28       ` Heiko Stübner
2022-01-30  9:56         ` Michael Riesch
2022-01-30 11:02           ` Heiko Stübner
2022-02-08 16:59 ` Heiko Stuebner

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=64f539b5-30b2-c0b7-17bf-c448b507713e@wolfvision.net \
    --to=michael.riesch@wolfvision.net \
    --cc=cl@rock-chips.com \
    --cc=devicetree@vger.kernel.org \
    --cc=frattaroli.nicolas@gmail.com \
    --cc=heiko@sntech.de \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-rockchip@lists.infradead.org \
    --cc=pgwipeout@gmail.com \
    --cc=piotr.oniszczuk@gmail.com \
    --cc=robh+dt@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox