linux-kernel - Re: [PATCH v3] arm64: dts: qcom: sdm845: Expand soc bus address range

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <154767975942.169631.1254649555789319450@swboyd.mtv.corp.google.com>
Date:   Wed, 16 Jan 2019 15:02:39 -0800
From:   Stephen Boyd <swboyd@...omium.org>
To:     Bjorn Andersson <bjorn.andersson@...aro.org>
Cc:     Andy Gross <andy.gross@...aro.org>,
        David Brown <david.brown@...aro.org>,
        Mark Rutland <mark.rutland@....com>,
        Rob Herring <robh+dt@...nel.org>,
        linux-arm-msm@...r.kernel.org, devicetree@...r.kernel.org,
        linux-kernel@...r.kernel.org, Doug Anderson <dianders@...omium.org>
Subject: Re: [PATCH v3] arm64: dts: qcom: sdm845: Expand soc bus address range

Quoting Stephen Boyd (2019-01-16 14:49:58)
> > > 
> > > Do we need #size-cells = <2>? Maybe it could be #size-cells = <1> and we
> > > can avoid having to specify a second size entry that's always going to
> > > be 0 because we don't have devices with huge IO regions in the SoC. Or
> > > does it need to be 2 for the large size of the size element of
> > > dma-ranges and ranges here? Looking at the code I think we can rely on
> > > the size-cells of the parent node so I think it will work with size of 1
> > > here.
> > > 
> > 
> > The "length" part of dma-ranges is described using #size-cells number of
> > cells, so with 1 there's no way we can describe this being 36 bits.
> 
> Yes, but doesn't the #size-cells of the parent node (i.e. root node in
> this case) dictate the number of cells of the "length" part of the
> dma-ranges property here? I hope that we don't need to push down the
> larger size of 2 just for this reason, but I admit I haven't run the
> code to understand this all properly.
> 

Ok, nevermind. I read the code more and looked at the spec and I'm just
talking nonsense on this point.