linux-kernel - RE: [PATCH V4 4/5] gpio: gpio-xilinx: Add support for suspend and resume

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: <DM6PR02MB538673699067F89F6F167121AFAE0@DM6PR02MB5386.namprd02.prod.outlook.com>
Date:   Fri, 8 Jan 2021 11:41:15 +0000
From:   Srinivas Neeli <sneeli@...inx.com>
To:     Linus Walleij <linus.walleij@...aro.org>
CC:     Bartosz Golaszewski <bgolaszewski@...libre.com>,
        Michal Simek <michals@...inx.com>,
        Shubhrajyoti Datta <shubhraj@...inx.com>,
        Srinivas Goud <sgoud@...inx.com>,
        Robert Hancock <hancock@...systems.ca>,
        William Breathitt Gray <vilhelm.gray@...il.com>,
        Syed Nayyar Waris <syednwaris@...il.com>,
        "open list:GPIO SUBSYSTEM" <linux-gpio@...r.kernel.org>,
        Linux ARM <linux-arm-kernel@...ts.infradead.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        git <git@...inx.com>
Subject: RE: [PATCH V4 4/5] gpio: gpio-xilinx: Add support for suspend and
 resume

Hi Linus,

> -----Original Message-----
> From: Linus Walleij <linus.walleij@...aro.org>
> Sent: Thursday, January 7, 2021 3:17 PM
> To: Srinivas Neeli <sneeli@...inx.com>
> Cc: Bartosz Golaszewski <bgolaszewski@...libre.com>; Michal Simek
> <michals@...inx.com>; Shubhrajyoti Datta <shubhraj@...inx.com>; Srinivas
> Goud <sgoud@...inx.com>; Robert Hancock <hancock@...systems.ca>;
> William Breathitt Gray <vilhelm.gray@...il.com>; Syed Nayyar Waris
> <syednwaris@...il.com>; open list:GPIO SUBSYSTEM <linux-
> gpio@...r.kernel.org>; Linux ARM <linux-arm-kernel@...ts.infradead.org>;
> linux-kernel@...r.kernel.org; git <git@...inx.com>
> Subject: Re: [PATCH V4 4/5] gpio: gpio-xilinx: Add support for suspend and
> resume
> 
> On Wed, Jan 6, 2021 at 1:27 PM Srinivas Neeli <srinivas.neeli@...inx.com>
> wrote:
> 
> > Add support for suspend and resume, pm runtime suspend and resume.
> > Added free and request calls.
> >
> > Signed-off-by: Srinivas Neeli <srinivas.neeli@...inx.com>
> (...)
> 
> > +static int xgpio_request(struct gpio_chip *chip, unsigned int offset)
> > +{
> > +       int ret;
> > +
> > +       ret = pm_runtime_get_sync(chip->parent);
> > +       /*
> > +        * If the device is already active pm_runtime_get() will return 1 on
> > +        * success, but gpio_request still needs to return 0.
> > +        */
> > +       return ret < 0 ? ret : 0;
> > +}
> 
> That's clever. I think more GPIO drivers should be doing it like this, today I
> think most just ignore the return code.
> 
> > +static int __maybe_unused xgpio_suspend(struct device *dev) static
> > +int __maybe_unused xgpio_resume(struct device *dev)
> 
> Those look good.
> 
> 
> >  /**
> >   * xgpio_remove - Remove method for the GPIO device.
> >   * @pdev: pointer to the platform device @@ -289,7 +323,10 @@ static
> > int xgpio_remove(struct platform_device *pdev)  {
> >         struct xgpio_instance *gpio = platform_get_drvdata(pdev);
> >
> > -       clk_disable_unprepare(gpio->clk);
> > +       if (!pm_runtime_suspended(&pdev->dev))
> > +               clk_disable_unprepare(gpio->clk);
> > +
> > +       pm_runtime_disable(&pdev->dev);
> 
> This looks complex and racy. What if the device is resumed after you
> executed the first part of the statement.

Could you please explain more on this.
What is the need to call pm_runtime_get_sync(); in remove API ?

> 
> The normal sequence is:
> 
> pm_runtime_get_sync(dev);
> pm_runtime_put_noidle(dev);
> pm_runtime_disable(dev);
> 
> This will make sure the clock is enabled and pm runtime is disabled.
> After this you can unconditionally call clk_disable_unprepare(gpio->clk);
> 
> It is what you are doing on the errorpath of probe().
> 
> Yours,
> Linus Walleij