linux-kernel - Re: [PATCH 0/8] Flush RSC votes properly on more RPMh platforms

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]

Date:   Wed, 31 May 2023 14:45:08 -0700
From:   Doug Anderson <dianders@...omium.org>
To:     Konrad Dybcio <konrad.dybcio@...aro.org>
Cc:     Andy Gross <agross@...nel.org>,
        Bjorn Andersson <andersson@...nel.org>,
        Rob Herring <robh+dt@...nel.org>,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
        Conor Dooley <conor+dt@...nel.org>,
        Melody Olvera <quic_molvera@...cinc.com>,
        Vinod Koul <vkoul@...nel.org>,
        Richard Acayan <mailingradian@...il.com>,
        Lina Iyer <ilina@...eaurora.org>,
        Neil Armstrong <neil.armstrong@...aro.org>,
        Abel Vesa <abel.vesa@...aro.org>,
        Sai Prakash Ranjan <quic_saipraka@...cinc.com>,
        Marijn Suijten <marijn.suijten@...ainline.org>,
        Bartosz Golaszewski <bartosz.golaszewski@...aro.org>,
        Luca Weiss <luca.weiss@...rphone.com>,
        linux-arm-msm@...r.kernel.org, devicetree@...r.kernel.org,
        linux-kernel@...r.kernel.org, Andy Gross <andy.gross@...aro.org>,
        Konrad Dybcio <konrad.dybcio@...ainline.org>,
        Maulik Shah <quic_mkshah@...cinc.com>,
        Stephen Boyd <swboyd@...omium.org>
Subject: Re: [PATCH 0/8] Flush RSC votes properly on more RPMh platforms

Hi,

On Wed, May 31, 2023 at 7:26 AM Konrad Dybcio <konrad.dybcio@...aro.org> wrote:
>
> On 31.05.2023 15:22, Konrad Dybcio wrote:
> > As pointed out in [1], the Linux implementation of RSC basically requires
> > (even if not explicitly) that we point it to a power domain which
> > represents the power state of the CPUs. In an effort to fulfill that
> > requirement, make it required in bindings and hook it up on all platforms
> > where I was able to do. This means all RPMh platforms, except
> >
> > - SC7180
> > - SC7280
> > - SA8775
> >
> > As there wasn't an idle-states setup (which may be on purpose for CrOS
> > devices, certainly not for Windows SC7[12]80s) that I could validate.
> > (Doug, Bartosz, could you guys look into your respective platforms of
> > interest here?)
> >
> > This series also adds support for idle states on SM6350, as I was able
> > to add and test that.
> I noticed that 7280 is WIP:
>
> https://lore.kernel.org/lkml/20230424110933.3908-4-quic_mkshah@quicinc.com/

Right. For sc7180 Chromebooks we don't use OSI (OS Initiated) mode but
instead use PC (Platform Coordinated) mode. As I understand it, that
means we take a different path through all this stuff.

That being said, in the sc7280 thread you pointed at, Bjorn and Ulf
said that we could use the new device tree snippets for sc7280 even
before the ATF update. If I'm reading the thread correctly and the
same applies to sc7180:

1. New DT plus firmware that doesn't support OSI - OK
2. New DT plus firmware that supports OSI - OK after code changes
3. Old DT plus firmware that doesn't support OSI - OK
4. Old DT plus firmware that supports OSI - Not OK

For sc7180 Chromebooks we'll never have firmware that supports OSI.
That means that, assuming I'm understanding correctly, we actually
could move the DT to represent things the new way. Presumably this
would be important for sc7180 devices that originally shipped with
Windows (I think support for one of these is underway).

-Doug