linux-kernel - Re: [PATCH 01/21] opp: Manage empty OPP tables with clk handle

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: <20200413104203.gyb7icsxbhnvjbvx@vireshk-i7>
Date:   Mon, 13 Apr 2020 16:12:03 +0530
From:   Viresh Kumar <viresh.kumar@...aro.org>
To:     Rajendra Nayak <rnayak@...eaurora.org>
Cc:     sboyd@...nel.org, bjorn.andersson@...aro.org, agross@...nel.org,
        linux-arm-msm@...r.kernel.org, devicetree@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH 01/21] opp: Manage empty OPP tables with clk handle

On 13-04-20, 16:04, Rajendra Nayak wrote:
> FWIK, no one should call a _of_add_opp_table_v2 in cases where there is no OPP in DT?
> The 'empty' OPP table from what I understand will be created by dev_pm_opp_set_clkname.
> A good case to look at is the PATCH 13/21 in this series. The driver I am modifying
> is used on sdm845/sc7180 and a host of other older qualcomm SoCs. Since i am adding
> support for perf state voting using OPP only on sdm845/sc7180 I want the existing
> platforms to just do what they were doing. Now thats not possible unless I start
> adding a bunch of if/else around every opp call in the driver to distinguish between
> the two.
> 
> I am a little surprised since I though the idea of doing something like this came from
> you :) (or perhaps Stephen, I somehow can't recollect)

Me only as I start remembering it now :)

> to avoid all the if/else conditions
> I had when I initially posted some of these changes.
> Btw, you had this patch reviewed when this was posted a long while back too [1]
> 
> [1] https://patchwork.kernel.org/patch/11027217/

That's an year back, in my defence :)

But anyway, I wasn't opposed to the idea now as well. I was just making sure all
things are handled well :)

-- 
viresh