linux-kernel - Re: [RFC PATCH] arm64: dts: qcom: sc7280: Drop aggre{1,2}

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] [day] [month] [year] [list]

Message-ID: <aKzhiPIDszlMocIQ@google.com>
Date: Mon, 25 Aug 2025 15:19:52 -0700
From: Brian Norris <briannorris@...omium.org>
To: Dmitry Baryshkov <dmitry.baryshkov@....qualcomm.com>
Cc: Bjorn Andersson <andersson@...nel.org>,
	Konrad Dybcio <konradybcio@...nel.org>,
	Georgi Djakov <djakov@...nel.org>,
	Odelu Kukatla <quic_okukatla@...cinc.com>,
	Douglas Anderson <dianders@...omium.org>,
	Krzysztof Kozlowski <krzk+dt@...nel.org>,
	Konrad Dybcio <konrad.dybcio@...aro.org>,
	linux-arm-msm@...r.kernel.org, linux-kernel@...r.kernel.org,
	devicetree@...r.kernel.org, Conor Dooley <conor+dt@...nel.org>,
	Rob Herring <robh@...nel.org>, cros-qcom-dts-watchers@...omium.org
Subject: Re: [RFC PATCH] arm64: dts: qcom: sc7280: Drop aggre{1,2}_noc QOS
 clocks on Herobrine

Hi Dmitry,

Thanks for the response.

On Mon, Aug 25, 2025 at 12:22:03PM +0300, Dmitry Baryshkov wrote:
> On Sat, Aug 23, 2025 at 12:37:18PM -0700, Brian Norris wrote:
> > Specifically, they fail in qcom_icc_set_qos() when trying to write the
> > QoS settings for qhm_qup1. Several of the previous nodes (qhm_qspi,
> > qhm_qup0, ...) seem to configure without crashing.
> > 
> > I don't really know what's unique about Herobrine systems vs other
> > sc7280 systems that presumably work fine. I'd guess there's some
> > conflict with something configured by the boot firmware.
> 
> I think it well might be that Herobrine's TZ doesn't export QoS regions
> to Linux.

That may be. I don't really know what to look for to verify that without
a lot of research, aside from crashes like this though. I'm fine with
assuming this though.

> > I'm submitting as an RFC just to get thoughts from people who hopefully
> > know better than me what might be going wrong here.
> > 
> > Fixes: fbd908bb8bc0 ("interconnect: qcom: sc7280: enable QoS configuration")
> > Fixes: 2b5004956aff ("arm64: dts: qcom: sc7280: Add clocks for QOS configuration")
> > Signed-off-by: Brian Norris <briannorris@...omium.org>
> > ---
> > 
> >  arch/arm64/boot/dts/qcom/sc7280-herobrine.dtsi | 10 ++++++++++
> >  1 file changed, 10 insertions(+)
> > 
> > diff --git a/arch/arm64/boot/dts/qcom/sc7280-herobrine.dtsi b/arch/arm64/boot/dts/qcom/sc7280-herobrine.dtsi
> > index 2ba4ea60cb14..59203ce58c61 100644
> > --- a/arch/arm64/boot/dts/qcom/sc7280-herobrine.dtsi
> > +++ b/arch/arm64/boot/dts/qcom/sc7280-herobrine.dtsi
> > @@ -394,6 +394,16 @@ &vreg_l2c_1p8 {
> >  
> >  /* ADDITIONS TO NODES DEFINED IN PARENT DEVICE TREE FILES */
> >  
> > +/* QoS seems to have conflicts with boot firmware on these devices. */
> > +&aggre1_noc {
> > +	/delete-property/ clocks;
> 
> While it might be enough for Linux to make it skip the QoS, I think a
> more correct fix would be to remove the 'reg' instead / in addition.

That should work too. However, besides simply violating
Documentation/devicetree/bindings/interconnect/qcom,sc7280-rpmh.yaml
(which is easy enough to tweak), that also violates basic simple-bus
rules:

arch/arm64/boot/dts/qcom/sc7280-herobrine-crd.dtb: soc@0 (simple-bus): interconnect@...0000: 'anyOf' conditional failed, one must be fixed:
	'reg' is a required property
	'ranges' is a required property
	from schema $id: http://devicetree.org/schemas/simple-bus.yaml#
[...]

> On the other hand, having those boards used by only a few people it
> might be easier to just pick up the simple fix rather than implementing
> a 'proper' one.
> 
> Nevertheless, this would require changing the schema too, see
> Documentation/devicetree/bindings/interconnect/qcom,sc7280-rpmh.yaml

Sure, I've tested out a change just to tweak the clock requirements.
I'll plan on submitting that if no solution arises for the 'reg' schema.

Brian