linux-kernel - Re: [PATCH v11 2/2] cpufreq: qcom-hw: Add support for QCOM cpufreq HW driver

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: <82b168d1-79bc-f454-8e19-4f7630a34069@codeaurora.org>
Date:   Tue, 11 Dec 2018 19:05:43 +0530
From:   Taniya Das <tdas@...eaurora.org>
To:     Viresh Kumar <viresh.kumar@...aro.org>
Cc:     Stephen Boyd <sboyd@...nel.org>,
        "Rafael J. Wysocki" <rjw@...ysocki.net>,
        linux-kernel@...r.kernel.org, linux-pm@...r.kernel.org,
        Rajendra Nayak <rnayak@...eaurora.org>,
        devicetree@...r.kernel.org, robh@...nel.org,
        skannan@...eaurora.org, linux-arm-msm@...r.kernel.org,
        evgreen@...gle.com
Subject: Re: [PATCH v11 2/2] cpufreq: qcom-hw: Add support for QCOM cpufreq HW
 driver

Hi Viresh,

Sorry for the delayed response. Thanks for the patch.

On 12/5/2018 11:46 AM, Viresh Kumar wrote:
> On 05-12-18, 09:07, Taniya Das wrote:
>> Hello Stephen, Viresh
>>
>> Thanks for the code and suggestions.
>>
>> Having a NR_DOMAINS '2' makes the driver not scalable for re-use.
> 
> Sure, I didn't like it either and that wasn't really what I was suggesting in
> the first place. I didn't wanted to write the code myself and pass it on, but I
> have it now anyway :)
> 
> It may have a bug or two in there, but compiles just fine and is rebased over
> your patch Taniya.
> 

The design here assumes that there would not be any per-cpu/per-cluster 
based SW requirement for the HW during frequency transitions, which 
again makes me think that we would require to re-introduce these 
structures again in case we have such requirements in near future.

Also I think leaving the structures also helps us debug any boot up 
issues looking at the ram contents of the per-(cpu/cluster) structures 
with the contents from the firmware.

Hope these above helps us to go ahead with the current SW design.

-- 
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation.

--