lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
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

Powered by Openwall GNU/*/Linux Powered by OpenVZ