| 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
| ||
|
Date: Wed, 25 Oct 2023 15:51:44 +0200
From: Ulf Hansson <ulf.hansson@...aro.org>
To: Viresh Kumar <viresh.kumar@...aro.org>
Cc: Viresh Kumar <vireshk@...nel.org>, Nishanth Menon <nm@...com>,
Stephen Boyd <sboyd@...nel.org>,
"Rafael J. Wysocki" <rafael@...nel.org>, linux-pm@...r.kernel.org,
Vincent Guittot <vincent.guittot@...aro.org>,
Stephan Gerhold <stephan.gerhold@...nkonzept.com>,
Konrad Dybcio <konrad.dybcio@...aro.org>,
Manivannan Sadhasivam <manivannan.sadhasivam@...aro.org>,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2/2] OPP: Call dev_pm_opp_set_opp() for required OPPs
On Thu, 19 Oct 2023 at 12:22, Viresh Kumar <viresh.kumar@...aro.org> wrote:
>
> Configuring the required OPP was never properly implemented, we just
> took an exception for genpds and configured them directly, while leaving
> out all other required OPP types.
>
> Now that a standard call to dev_pm_opp_set_opp() takes care of
> configuring the opp->level too, the special handling for genpds can be
> avoided by simply calling dev_pm_opp_set_opp() for the required OPPs,
> which shall eventually configure the corresponding level for genpds.
>
> This also makes it possible for us to configure other type of required
> OPPs (no concrete users yet though), via the same path. This is how
> other frameworks take care of parent nodes, like clock, regulators, etc,
> where we recursively call the same helper.
>
> In order to call dev_pm_opp_set_opp() for the virtual genpd devices,
> they must share the OPP table of the genpd. Call _add_opp_dev() for them
> to get that done.
>
> This commit also extends the struct dev_pm_opp_config to pass required
> devices, for non-genpd cases, which can be used to call
> dev_pm_opp_set_opp() for the non-genpd required devices.
>
> Signed-off-by: Viresh Kumar <viresh.kumar@...aro.org>
> ---
> drivers/opp/core.c | 144 ++++++++++++++++++-----------------------
> drivers/opp/of.c | 12 ++--
> drivers/opp/opp.h | 8 +--
> include/linux/pm_opp.h | 7 +-
> 4 files changed, 76 insertions(+), 95 deletions(-)
>
> diff --git a/drivers/opp/core.c b/drivers/opp/core.c
> index aab8c8e79146..056b51abc501 100644
> --- a/drivers/opp/core.c
> +++ b/drivers/opp/core.c
[...]
> -static int _opp_set_required_opps_genpd(struct device *dev,
> - struct opp_table *opp_table, struct dev_pm_opp *opp, bool scaling_down)
> +/* This is only called for PM domain for now */
> +static int _set_required_opps(struct device *dev, struct opp_table *opp_table,
> + struct dev_pm_opp *opp, bool up)
> {
> - struct device **genpd_virt_devs = opp_table->genpd_virt_devs;
> + struct device **devs = opp_table->required_devs;
> int index, target, delta, ret;
>
> - if (!genpd_virt_devs)
> - return 0;
Rather than continue the path below, wouldn't it be better to return 0
"if (!devs)" here?
If I understand correctly, the code below does manage this condition,
so it's not strictly needed though.
> + /* required-opps not fully initialized yet */
> + if (lazy_linking_pending(opp_table))
> + return -EBUSY;
>
> /* Scaling up? Set required OPPs in normal order, else reverse */
> - if (!scaling_down) {
> + if (up) {
> index = 0;
> target = opp_table->required_opp_count;
> delta = 1;
> @@ -1092,9 +1069,11 @@ static int _opp_set_required_opps_genpd(struct device *dev,
> }
>
> while (index != target) {
> - ret = _set_performance_state(dev, genpd_virt_devs[index], opp, index);
> - if (ret)
> - return ret;
> + if (devs[index]) {
> + ret = dev_pm_opp_set_opp(devs[index], opp);
> + if (ret)
> + return ret;
> + }
>
> index += delta;
> }
[...]
>
> /*
> @@ -2429,15 +2374,10 @@ static int _opp_attach_genpd(struct opp_table *opp_table, struct device *dev,
> int index = 0, ret = -EINVAL;
> const char * const *name = names;
>
> - if (opp_table->genpd_virt_devs)
> + /* Checking only the first one is enough ? */
> + if (opp_table->required_devs[0])
The allocation of opp_table->required_devs is being done from
_opp_table_alloc_required_tables(), which doesn't necessarily
allocate/assign the data for it.
Maybe check "opp_table->required_devs" instead, to make that clear?
> return 0;
>
> - opp_table->genpd_virt_devs = kcalloc(opp_table->required_opp_count,
> - sizeof(*opp_table->genpd_virt_devs),
> - GFP_KERNEL);
> - if (!opp_table->genpd_virt_devs)
> - return -ENOMEM;
> -
> while (*name) {
> if (index >= opp_table->required_opp_count) {
> dev_err(dev, "Index can't be greater than required-opp-count - 1, %s (%d : %d)\n",
> @@ -2452,13 +2392,25 @@ static int _opp_attach_genpd(struct opp_table *opp_table, struct device *dev,
> goto err;
> }
>
> - opp_table->genpd_virt_devs[index] = virt_dev;
> + /*
> + * Add the virtual genpd device as a user of the OPP table, so
> + * we can call dev_pm_opp_set_opp() on it directly.
> + *
> + * This will be automatically removed when the OPP table is
> + * removed, don't need to handle that here.
> + */
> + if (!_add_opp_dev(virt_dev, opp_table->required_opp_tables[index])) {
> + ret = -ENOMEM;
> + goto err;
> + }
> +
> + opp_table->required_devs[index] = virt_dev;
> index++;
> name++;
> }
>
> if (virt_devs)
> - *virt_devs = opp_table->genpd_virt_devs;
> + *virt_devs = opp_table->required_devs;
>
> return 0;
>
> @@ -2468,10 +2420,34 @@ static int _opp_attach_genpd(struct opp_table *opp_table, struct device *dev,
>
> }
>
> +static void _opp_set_required_devs(struct opp_table *opp_table,
> + struct device **required_devs)
> +{
> + int i;
> +
> + /* Another CPU that shares the OPP table has set the required devs ? */
Not sure I fully understand the above comment. Is this the only
relevant use-case or could there be others too?
> + if (opp_table->required_devs[0])
Maybe check opp_table->required_devs instead?
> + return;
> +
> + for (i = 0; i < opp_table->required_opp_count; i++)
> + opp_table->required_devs[i] = required_devs[i];
To be safe, don't we need to check the in-parameter required_devs?
Or we should simply rely on the callers of dev_pm_opp_set_config() to
do the right thing?
[...]
Besides the minor things above, this looks really great to me! Feel free to add:
Reviewed-by: Ulf Hansson <ulf.hansson@...aro.org>
Kind regards
Uffe
Powered by blists - more mailing lists