linux-kernel - Re: [PATCH] PM / OPP: Allow inactive opp

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, 30 Nov 2016 07:06:24 +0530
From:   Viresh Kumar <viresh.kumar@...aro.org>
To:     Stephen Boyd <sboyd@...eaurora.org>
Cc:     Rafael Wysocki <rjw@...ysocki.net>,
        Joonyoung Shim <jy0922.shim@...sung.com>,
        Viresh Kumar <vireshk@...nel.org>, Nishanth Menon <nm@...com>,
        Lists linaro-kernel <linaro-kernel@...ts.linaro.org>,
        "linux-pm@...r.kernel.org" <linux-pm@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        "# 3.13.x" <stable@...r.kernel.org>
Subject: Re: [PATCH] PM / OPP: Allow inactive opp_device to be present in dev list

On 30 November 2016 at 02:26, Stephen Boyd <sboyd@...eaurora.org> wrote:
> On 11/29, Viresh Kumar wrote:
>> On 28-11-16, 18:46, Stephen Boyd wrote:
>> > Anyway, rant over, how about handing out the opp table pointer to
>> > the caller so they can pass it back in when they call the put
>> > side? That should fix the same problem if I understand correctly.
>>
>> Hmm, so the problem is that all below routines (and their callers) need to get
>> updated:
>>
>> int dev_pm_opp_set_supported_hw(struct device *dev, const u32 *versions, unsigned int count);
>> void dev_pm_opp_put_supported_hw(struct device *dev);
>> int dev_pm_opp_set_prop_name(struct device *dev, const char *name);
>> void dev_pm_opp_put_prop_name(struct device *dev);
>> struct opp_table *dev_pm_opp_set_regulator(struct device *dev, const char *name);
>> void dev_pm_opp_put_regulator(struct opp_table *opp_table);
>>
>> And that will make it difficult to get it back to stable kernels, specially
>> because they were all added in different kernel releases after 4.4.
>
> Why do we care? The put variants of the prop and supported_hw
> functions are never called, so we're not going to hit this
> problem there. Sure the code is broken, but nobody is using the
> code in mainline so there isn't anything to backport to stable
> urgently.

Hmm, only the set variants are used by the sti driver.

>>
>> And we also need to fix them properly, with something like a cookie instead of a
>> plain opp_table pointer.
>
> Perhaps this means my approach in using opp_table is undesirable
> for some reason? Care to elaborate why?

You only suggested the cookie method as well, isn't it ? I am fine with your
patch as well, the only problem is that we will have different prototype for
a single set of APIs..

> I'd prefer we used my patch because it
> isn't as easy to break and more directly fixes the problem at
> hand.

Okay, can you please send it formally and I can Ack it then ?

--
viresh