linux-kernel - Re: [PATCH 3/4] arm64: dts: qcom: sc7280: Factor out Chrome common fragment

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: <YeGHsTLT/CD8D9rH@google.com>
Date:   Fri, 14 Jan 2022 06:24:49 -0800
From:   Matthias Kaehlcke <mka@...omium.org>
To:     Douglas Anderson <dianders@...omium.org>
Cc:     Bjorn Andersson <bjorn.andersson@...aro.org>,
        quic_rjendra@...cinc.com, sibis@...eaurora.org,
        kgodara1@...eaurora.org, swboyd@...omium.org,
        pmaliset@...eaurora.org, Andy Gross <agross@...nel.org>,
        Rob Herring <robh+dt@...nel.org>, devicetree@...r.kernel.org,
        linux-arm-msm@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 3/4] arm64: dts: qcom: sc7280: Factor out Chrome common
 fragment

On Thu, Jan 13, 2022 at 04:43:02PM -0800, Douglas Anderson wrote:
> This factors out a device tree fragment from some sc7280 device
> trees. It represents the device tree bits that should be included for
> "Chrome" based sc7280 boards. On these boards the bootloader (Coreboot
> + Depthcharge) configures things slightly different than the
> bootloader that Qualcomm provides. The modem firmware on these boards
> also works differently than on other Qulacomm products and thus the
> reserved memory map needs to be adjusted.
> 
> NOTES:
> - This is _not_ quite a no-op change. The "herobrine" and "idp"
>   fragments here were different and it looks like someone simply
>   forgot to update the herobrine version. This updates a few numbers
>   to match IDP. This will also cause the `pmk8350_pon` to be disabled
>   on idp/crd, which I belive is a correct change.
> - At the moment this assumes LTE skus. Once it's clearer how WiFi SKUs
>   will work (how much of the memory map they can reclaim) we may add
>   an extra fragment that will rejigger one way or the other.
> 
> Signed-off-by: Douglas Anderson <dianders@...omium.org>

Reviewed-by: Matthias Kaehlcke <mka@...omium.org>