linux-kernel - Re: [PATCH] arm64: dts: qcom: sc8280xp: Add lost ranges for timer

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: <Ys4lnuVncPiWkjbH@builder.lan>
Date:   Tue, 12 Jul 2022 20:53:34 -0500
From:   Bjorn Andersson <bjorn.andersson@...aro.org>
To:     Johan Hovold <johan@...nel.org>
Cc:     Andy Gross <agross@...nel.org>,
        Konrad Dybcio <konrad.dybcio@...ainline.org>,
        Johan Hovold <johan+linaro@...nel.org>,
        Rob Herring <robh+dt@...nel.org>,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
        manivannan.sadhasivam@...aro.org, linux-arm-msm@...r.kernel.org,
        devicetree@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] arm64: dts: qcom: sc8280xp: Add lost ranges for timer

On Tue 12 Jul 09:53 CDT 2022, Johan Hovold wrote:

> On Mon, Jul 11, 2022 at 07:28:26PM -0700, Bjorn Andersson wrote:
> > On Mon 11 Jul 01:56 PDT 2022, Johan Hovold wrote:
> > 
> > > On Thu, Jul 07, 2022 at 09:08:58AM -0700, Bjorn Andersson wrote:
> > > > The timer node needs ranges specified to map the 1-cell children to the
> > > > 2-cell address range used in /soc. This addition never made it into the
> > > > patch that was posted and merged, so add it now.
> > > > 
> > > > Fixes: 152d1faf1e2f ("arm64: dts: qcom: add SC8280XP platform")
> > > > Signed-off-by: Bjorn Andersson <bjorn.andersson@...aro.org>
> > > > ---
> > > >  arch/arm64/boot/dts/qcom/sc8280xp.dtsi | 1 +
> > > >  1 file changed, 1 insertion(+)
> > > > 
> > > > diff --git a/arch/arm64/boot/dts/qcom/sc8280xp.dtsi b/arch/arm64/boot/dts/qcom/sc8280xp.dtsi
> > > > index 2bdb42c88311..37a4cd6f85b6 100644
> > > > --- a/arch/arm64/boot/dts/qcom/sc8280xp.dtsi
> > > > +++ b/arch/arm64/boot/dts/qcom/sc8280xp.dtsi
> > > > @@ -1667,6 +1667,7 @@ timer@...20000 {
> > > >  			reg = <0x0 0x17c20000 0x0 0x1000>;
> > > >  			#address-cells = <1>;
> > > >  			#size-cells = <1>;
> > > > +			ranges = <0 0 0 0x20000000>;
> > > 
> > > While addressing the current issue, this looks odd to me. Why not use a
> > > non-zero parent bus address here instead?
> > > 
> > 
> > I guess we could express the frames relative the timer range, but that
> > would imply that anyone porting downstream dts snippets would have to
> > translate these addresses - or more likely would end up just copying the
> > existing cases.
> > 
> > > And please use hex notation consistently for the addresses.
> > 
> > That seems like a reasonable ask, I can fix that up. But on both
> > accounts this matches what I merged for all the other platforms in:
> > 
> > 458ebdbb8e5d ("arm64: dts: qcom: timer should use only 32-bit size")
> > 
> > 
> > So I guess we'll also need to go back and fix up the style of all the
> > other platforms - just because we're not allowed to express the frames
> > in 64-bits according to the binding...
> 
> Would have been easier to just amend the binding. I don't think that
> #size-cells = 1 constraint is set in stone as it was added when
> converting to DT schema.
> 

Rob disagrees with this idea:
https://lore.kernel.org/all/CAL_JsqJMMCBnukFZLJ8X14s1PwqT=VEwKjDVj8mm4h55pZpcuw@mail.gmail.com/

> I also don't think you need to fixup the hex notation elsewhere, it's
> quite inconsistent currently, but no need to make it worse.
> 

I'll prefix the 0s with some 0x in this case and we can care for the
other platforms some other day...

> But you probably should amend the commit message and mention that this
> fixes time keeping. I had recently noticed that something was off
> (journals rotating, and erratic cursor blinking) but didn't realise that
> timers were broken until you posted this.
> 

That sounds like a good idea, thanks for the suggestion.

Regards,
Bjorn