linux-kernel - Re: [PATCH v2 20/31] arm64: dts: qcom: ipq5018: move board clocks to ipq5018.dtsi file

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]

Message-ID: <wvrelorcsajlux73jfqysgsox5dge7udfvhktt2sto2yg2xb3a@t7cpherrt6z7>
Date: Sat, 30 Nov 2024 13:08:21 +0200
From: Dmitry Baryshkov <dmitry.baryshkov@...aro.org>
To: Krzysztof Kozlowski <krzk@...nel.org>
Cc: Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>, 
	Bjorn Andersson <andersson@...nel.org>, Konrad Dybcio <konradybcio@...nel.org>, 
	Rob Herring <robh@...nel.org>, Krzysztof Kozlowski <krzk+dt@...nel.org>, 
	Conor Dooley <conor+dt@...nel.org>, Leo Yan <leo.yan@...ux.dev>, Joseph Gates <jgates@...areup.com>, 
	Georgi Djakov <djakov@...nel.org>, Shawn Guo <shawn.guo@...aro.org>, 
	Stephan Gerhold <stephan@...hold.net>, Zac Crosby <zac@...areup.com>, 
	Bastian Köcher <git@...r.de>, Andy Gross <andy.gross@...aro.org>, 
	Jeremy McNicoll <jeremymc@...hat.com>, Rohit Agarwal <quic_rohiagar@...cinc.com>, 
	Melody Olvera <quic_molvera@...cinc.com>, Bhupesh Sharma <bhupesh.sharma@...aro.org>, 
	cros-qcom-dts-watchers@...omium.org, Stephen Boyd <swboyd@...omium.org>, 
	Rajendra Nayak <quic_rjendra@...cinc.com>, Martin Botka <martin.botka@...ainline.org>, 
	Jonathan Marek <jonathan@...ek.ca>, Vinod Koul <vkoul@...nel.org>, 
	Tengfei Fan <quic_tengfan@...cinc.com>, Fenglin Wu <quic_fenglinw@...cinc.com>, 
	Neil Armstrong <neil.armstrong@...aro.org>, Abel Vesa <abel.vesa@...aro.org>, 
	Alexandru Marc Serdeliuc <serdeliuk@...oo.com>, Vladimir Zapolskiy <vladimir.zapolskiy@...aro.org>, 
	Sibi Sankar <quic_sibis@...cinc.com>, Bryan O'Donoghue <bryan.odonoghue@...aro.org>, 
	Jun Nie <jun.nie@...aro.org>, James Willcox <jwillcox@...areup.com>, 
	Max Chen <mchen@...areup.com>, Vincent Knecht <vincent.knecht@...loo.org>, 
	Benjamin Li <benl@...areup.com>, linux-arm-msm@...r.kernel.org, devicetree@...r.kernel.org, 
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 20/31] arm64: dts: qcom: ipq5018: move board clocks to
 ipq5018.dtsi file

On Sat, Nov 30, 2024 at 11:43:34AM +0100, Krzysztof Kozlowski wrote:
> On 30/11/2024 11:26, Dmitry Baryshkov wrote:
> > On Sat, Nov 30, 2024 at 11:00:32AM +0100, Krzysztof Kozlowski wrote:
> >> On 30/11/2024 10:57, Dmitry Baryshkov wrote:
> >>> On Sat, Nov 30, 2024 at 10:29:38AM +0100, Krzysztof Kozlowski wrote:
> >>>> On 30/11/2024 02:44, Dmitry Baryshkov wrote:
> >>>>> IPQ5018 is one of the platforms where board-level clocks (XO, sleep)
> >>>>> definitions are split between the SoC dtsi file and the board file.
> >>>>> This is not optimal, as the clocks are a part of the SoC + PMICs design.
> >>>>> Frequencies are common for the whole set of devices using the same SoC.
> >>>>> Remove the split and move frequencies to the SoC DTSI file.
> >>>>>
> >>>>> Suggested-by: Bjorn Andersson <andersson@...nel.org>
> >>>>> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@...aro.org>
> >>>>
> >>>> This contradicts DTS coding style and all my existing review. Obviously
> >>>> that's a NAK from me. If you want to merge this patch, please kindly
> >>>> carry my formal objection for this and all following "move board clocks"
> >>>> patches:
> >>>>
> >>>> Nacked-by: Krzysztof Kozlowski <krzk@...nel.org>
> >>>
> >>> I'd kindly ask Bjorn to chime in as a platform maintainer.
> >>
> >>
> >> To change my NAK? NAK is still a NAK. We discussed it many, many times
> >> already. We have coding style for this explicitly mentioning this case.
> >> Could not be more specific... plus all my reviews for Qualcomm, NXP, TI,
> >> ST and other platforms. I would be quite unpredictable or unfair if I
> >> gave here some sort of exception while expecting different code from
> >> other platforms.
> >>
> >> Please carry my NAK.
> > 
> > Of course. I didn't mean to drop your tag or your objection.
> > 
> > BTW, would it be possible for you to clarify the policy on external
> > references? I mean, is it fine for DTSI to reference a label which is
> > not defined within that file or within one of the files that it includes?
> 
> 
> It is fine, you have plenty of such examples of shared components like
> some audio blocks or PMICs.
> 
> All Qualcomm PMICs DTSI (e.g. arch/arm64/boot/dts/qcom/pmi632.dtsi )
> reference them. Chromebooks are even "worse" here:
> arch/arm64/boot/dts/qcom/sc7280-chrome-common.dtsi
> Nothing gets included there but hundred of phandles!
> 
> Are you planning to "fix" these as well?

No.

> 
> These are just Qualcomm, but same cases are everywhere else.
> 
> But *that's not even important* because I do not suggest to move clocks
> to DTSI. I suggest - and was almost always suggesting as best compromise
> - to follow DTS coding style by doing opposite of what this patch is
> doing. That's why I NAKed this and following patches, except last two
> which are different.

If you remmember my first attempt was implemented other way around. But
I think it still better to have both frequencies in the SoC dtsi, it
points out that it is tightly coupled with the RPM CC (and can not be
easily changed), it saves us from 32 kHz / 32.768 kHz / 32.764 kHz
typos, etc.

-- 
With best wishes
Dmitry