linux-kernel - Re: [PATCH 2/2] opp: Don't create an OPP table from dev_pm_opp_get_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]

Message-ID: <20201109045740.y5kpd6tjscoqxhi5@vireshk-i7>
Date:   Mon, 9 Nov 2020 10:27:40 +0530
From:   Viresh Kumar <viresh.kumar@...aro.org>
To:     Dmitry Osipenko <digetx@...il.com>
Cc:     "Rafael J. Wysocki" <rjw@...ysocki.net>,
        Kevin Hilman <khilman@...nel.org>,
        Ulf Hansson <ulf.hansson@...aro.org>,
        Len Brown <len.brown@...el.com>, Pavel Machek <pavel@....cz>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Viresh Kumar <vireshk@...nel.org>, Nishanth Menon <nm@...com>,
        Stephen Boyd <sboyd@...nel.org>, linux-pm@...r.kernel.org,
        Vincent Guittot <vincent.guittot@...aro.org>,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2/2] opp: Don't create an OPP table from
 dev_pm_opp_get_opp_table()

On 09-11-20, 07:41, Dmitry Osipenko wrote:
> 09.11.2020 07:34, Viresh Kumar пишет:
> > On 06-11-20, 16:18, Dmitry Osipenko wrote:
> >> 06.11.2020 09:24, Viresh Kumar пишет:
> >>> It has been found that some users (like cpufreq-dt and others on LKML)
> >>> have abused the helper dev_pm_opp_get_opp_table() to create the OPP
> >>> table instead of just finding it, which is the wrong thing to do. This
> >>> routine was meant for OPP core's internal working and exposed the whole
> >>> functionality by mistake.
> >>>
> >>> Change the scope of dev_pm_opp_get_opp_table() to only finding the
> >>> table. The internal helpers _opp_get_opp_table*() are thus renamed to
> >>> _add_opp_table*(), dev_pm_opp_get_opp_table_indexed() is removed (as we
> >>> don't need the index field for finding the OPP table) and so the only
> >>> user, genpd, is updated.
> >>>
> >>> Note that the prototype of _add_opp_table() was already left in opp.h by
> >>> mistake when it was removed earlier and so we weren't required to add it
> >>> now.
> >>
> >> Hello Viresh,
> >>
> >> It looks like this is not an entirely correct change because previously
> >> it was possible to get an empty opp_table in order to use it for the
> >> dev_pm_opp_set_rate(), which would fall back to clk_set_rate if table is
> >> empty.
> >>
> >> Now it's not possible to get an empty table and
> >> dev_pm_opp_of_add_table() would error out if OPPs are missing in a
> >> device-tree. Hence it's not possible to implement a fall back without
> >> abusing opp_set_regulators() or opp_set_supported_hw() for getting the
> >> empty table. Or am I missing something?
> > 
> > For that case you were always required to call
> > dev_pm_opp_set_clkname(), otherwise how would the OPP core know which
> > clock to set ? And the same shall work now as well.
> 
> Why _allocate_opp_table() grabs the first default clk of a device and
> assigns it to the created table?

Right, it was there so everybody isn't required to call
dev_pm_opp_set_clkname() if they don't need to pass a connection id
while getting the clock. But for the case of supporting empty OPP
tables for cases where we just want dev_pm_opp_set_rate() to act as
clk_set_rate() (in order for the drivers to avoid supporting two
different ways of doing so), we do need that call to be made.

We need to add the OPP table explicitly and what happened with
dev_pm_opp_get_opp_table() was accidental and not what I wanted.

drivers/mmc/host/sdhci-msm.c has an example of how this is done.

-- 
viresh