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: <26lttxx7obu2oqvf4xnooqi3o7qwodhjzyjh4trjq5tlj2gzxs@uwihybmwbdid>
Date: Sat, 30 Nov 2024 12:26:30 +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: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?

-- 
With best wishes
Dmitry