linux-kernel - Re: [PATCH 2/2] cpufreq: arm_scmi: Set fast_switch

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: <20200618080833.GA20559@bogus>
Date:   Thu, 18 Jun 2020 09:08:33 +0100
From:   Sudeep Holla <sudeep.holla@....com>
To:     Viresh Kumar <viresh.kumar@...aro.org>
Cc:     Nicola Mazzucato <nicola.mazzucato@....com>,
        linux-kernel@...r.kernel.org, rjw@...ysocki.net,
        linux-arm-kernel@...ts.infradead.org, linux-pm@...r.kernel.org,
        lukasz.luba@....com, Sudeep Holla <sudeep.holla@....com>
Subject: Re: [PATCH 2/2] cpufreq: arm_scmi: Set fast_switch_possible
 conditionally

On Thu, Jun 18, 2020 at 11:44:20AM +0530, Viresh Kumar wrote:
> On 17-06-20, 13:47, Sudeep Holla wrote:
> > This is first step towards avoiding polling based cpufreq set if firmware
> > has fast access registers that bypass normal mailbox based messaging.
> >
> > If you happy with this and provide ack, I will take this along with scmi
> > changes via ARM SoC. Hope that is fine by you.
>
> Sudeep,
>
> I am not sure how it concerns me frankly :)
>

Sorry I wasn't clear.

> AFAICT, this is enabling fast switch based on some mechanism (internal
> to scmi) and so either the cpufreq driver will have fast-switch
> enabled or not, and both are fine by the cpufreq core.
>

Indeed.

> And so I am confused on why my Ack is important here :)
>

Generally ARM SoC team expects a stamp from other subsystem maintainers
if they are pulling it. I understand there is more firmware aspect than
cpufreq aspect here, but still we may need your stamp to this 😉 for
logistic reasons.

--
Regards,
Sudeep