Re: [PATCH v2 2/3] nvmem: qfprom: sc7280: Handle the additional power-domains vote

[Rajendra Nayak]

On 7/29/2021 9:37 PM, Doug Anderson wrote:
> Hi,
>
> On Thu, Jul 29, 2021 at 5:01 AM Rajendra Nayak <rnayak@xxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxx>
> > ---
> >   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().

Right, I was confused with this too when I saw that the other resources
(regulator/clocks) were also turned off before we write into the
register space. And then looking into the driver I realized its perhaps because
the resources are needed only for the 'raw' writes and the 'conf'
read/writes can happen regardless. I'll just fix that up and put the register
writes before we really turn off any resources to avoid confusion.

> > @@ -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. 

Ah, I didn't know that, thanks, I'll fix the order up and repost.

> 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.

Thanks.

> -Doug

--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation