linux-kernel - Re: [PATCH] arm64: dts: qcom: sc7180: Fix the LLCC base register size

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: <CAD=FV=VVeoqOsVzJiCxjYTpJc8JX4Qx3vB+0evzp8oMdYsRZvQ@mail.gmail.com>
Date:   Mon, 17 Aug 2020 14:12:05 -0700
From:   Doug Anderson <dianders@...omium.org>
To:     Sai Prakash Ranjan <saiprakash.ranjan@...eaurora.org>
Cc:     Andy Gross <agross@...nel.org>,
        Bjorn Andersson <bjorn.andersson@...aro.org>,
        Stephen Boyd <swboyd@...omium.org>,
        linux-arm-msm <linux-arm-msm@...r.kernel.org>,
        "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" 
        <devicetree@...r.kernel.org>, LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] arm64: dts: qcom: sc7180: Fix the LLCC base register size

Hi,

On Sun, Aug 16, 2020 at 9:04 PM Sai Prakash Ranjan
<saiprakash.ranjan@...eaurora.org> wrote:
>
> There is only one LLCC logical bank on SC7180 SoC of size
> 0x50000(320KB) not 2MB, so correct the size and fix copy
> paste mistake from SDM845 which had 4 logical banks.

I guess SDM845 not only has 4 banks but each bank is bigger?  At first
I thought "yeah, 4 banks and 4 * 0x5 = 0x20" except that's not true in
hex.  ;-)

> Fixes: 7cee5c742899 ("arm64: dts: qcom: sc7180: Fix node order")
> Fixes: c831fa299996 ("arm64: dts: qcom: sc7180: Add Last level cache controller node")
> Signed-off-by: Sai Prakash Ranjan <saiprakash.ranjan@...eaurora.org>
> ---
>  arch/arm64/boot/dts/qcom/sc7180.dtsi | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

Without having any documentation ,this seems sane to me.  I guess it
doesn't do a whole lot because the driver just reads one register from
this whole space (at 0x0003000c bytes off).  So it's just a cleanup,
or is it needed to actually fix something?

...the fact that there's a status register in the middle of this seems
strange, though.  Your commit message makes it sound as if this range
is describing the size of the cache itself and then I would think that
this was the address range where you could read from the cache memory
directly, but that doesn't seem to mesh in my mind with there being a
status register.  Hrm.  Am I just confused as usual?

-Doug