[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAD=FV=Wy6iyrty0tmygY42GJdWSNqby9XePjpg6pKpce-9A7fg@mail.gmail.com>
Date: Thu, 29 Jul 2021 09:07:50 -0700
From: Doug Anderson <dianders@...omium.org>
To: Rajendra Nayak <rnayak@...eaurora.org>
Cc: Andy Gross <agross@...nel.org>,
Bjorn Andersson <bjorn.andersson@...aro.org>,
Srinivas Kandagatla <srinivas.kandagatla@...aro.org>,
Rob Herring <robh+dt@...nel.org>,
linux-arm-msm <linux-arm-msm@...r.kernel.org>,
"open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS"
<devicetree@...r.kernel.org>, LKML <linux-kernel@...r.kernel.org>,
"Ravi Kumar Bokka (Temp)" <rbokka@...eaurora.org>
Subject: Re: [PATCH v2 2/3] nvmem: qfprom: sc7280: Handle the additional
power-domains vote
Hi,
On Thu, Jul 29, 2021 at 5:01 AM Rajendra Nayak <rnayak@...eaurora.org> wrote:
>
> On sc7280, to reliably blow fuses, we need an additional vote
> on max performance state of 'MX' power-domain.
> Add support for power-domain performance state voting in the
> driver.
>
> Signed-off-by: Rajendra Nayak <rnayak@...eaurora.org>
> ---
> drivers/nvmem/qfprom.c | 26 ++++++++++++++++++++++++++
> 1 file changed, 26 insertions(+)
>
> diff --git a/drivers/nvmem/qfprom.c b/drivers/nvmem/qfprom.c
> index 81fbad5..b5f27df 100644
> --- a/drivers/nvmem/qfprom.c
> +++ b/drivers/nvmem/qfprom.c
> @@ -12,6 +12,8 @@
> #include <linux/mod_devicetable.h>
> #include <linux/nvmem-provider.h>
> #include <linux/platform_device.h>
> +#include <linux/pm_domain.h>
> +#include <linux/pm_runtime.h>
> #include <linux/property.h>
> #include <linux/regulator/consumer.h>
>
> @@ -139,6 +141,9 @@ static void qfprom_disable_fuse_blowing(const struct qfprom_priv *priv,
> {
> int ret;
>
> + dev_pm_genpd_set_performance_state(priv->dev, 0);
> + pm_runtime_put(priv->dev);
To me it feels as if this should be at the end of the function rather
than the beginning. I guess it doesn't matter (?), but it feels wrong
that we have writes to the register space after we're don't a
pm_runtime_put().
> @@ -420,6 +440,12 @@ static int qfprom_probe(struct platform_device *pdev)
> econfig.reg_write = qfprom_reg_write;
> }
>
> + ret = devm_add_action_or_reset(dev, qfprom_runtime_disable, dev);
> + if (ret)
> + return ret;
> +
> + pm_runtime_enable(dev);
> +
Swap the order of the two. IOW first pm_runtime_enable(), then
devm_add_action_or_reset(). Specifically the "_or_reset" means that if
you fail to add the action (AKA devm_add_action() fails to allocate
the tiny amount of memory it needs) it will actually _call_ the
action. That means that in your code if the memory allocation fails
you'll call pm_runtime_disable() without the corresponding
pm_runtime_enable().
Other than those two issues this looks good to me. Feel free to add my
Reviewed-by when you fix them.
-Doug
Powered by blists - more mailing lists