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] [day] [month] [year] [list]

Message-ID: <72a7312a-5529-92df-63e9-c3e6905103c2@codeaurora.org>
Date:   Thu, 13 Dec 2018 13:18:39 +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

Hello Viresh,

On 12/12/2018 10:17 AM, Viresh Kumar wrote:
> On 11-12-18, 19:05, Taniya Das wrote:
>> 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.
> 
> Firstly, even in such cases we can go ahead with the design we proposed. And I
> am not at all concerned about some hardware which we don't have right now. We
> will see what to do when such hardware comes, maybe reintroduce the structures,
> but that doesn't matter right now.
> 
>> 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.
> 
> I don't see how debugging would be hard without those structures in place.
> 
>> Hope these above helps us to go ahead with the current SW design.
> 
> Sorry, but I don't see any satisfactory reason on why you shouldn't make the
> suggested changes. We are trying to make your (and any other developer who will
> work on that driver) life simple by simplifying the code. Nothing beyond that :)
> 

Sure, Thanks, will submit the next patch series for your ACK :).

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

--