Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
MIME-Version: 1.0
References: <20210707135226.191988-1-aardelean@deviqon.com> <YOW1dKIpXa1GXyXh@smile.fi.intel.com>
In-Reply-To: <YOW1dKIpXa1GXyXh@smile.fi.intel.com>
From:   Alexandru Ardelean <aardelean@deviqon.com>
Date:   Thu, 8 Jul 2021 10:03:12 +0300
Message-ID: <CAASAkoY2Yw7E1ftN+410twQ3HHkF=b85YbzuyCXonKf3LwDehQ@mail.gmail.com>
Subject: Re: [PATCH] gpio: wcove: remove platform_set_drvdata() + cleanup probe
To:     Andy Shevchenko <andriy.shevchenko@intel.com>
Cc:     linux-gpio <linux-gpio@vger.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
        Bartosz Golaszewski <bgolaszewski@baylibre.com>,
        Linus Walleij <linus.walleij@linaro.org>,
        sathyanarayanan.kuppuswamy@linux.intel.com, andy@kernel.org
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

On Wed, 7 Jul 2021 at 17:09, Andy Shevchenko
<andriy.shevchenko@intel.com> wrote:
>
> On Wed, Jul 07, 2021 at 04:52:26PM +0300, Alexandru Ardelean wrote:
> > The platform_set_drvdata() call is only useful if we need to retrieve back
> > the private information.
> > Since the driver doesn't do that, it's not useful to have it.
>
> This is fine.
>
> > This change also changes the probe order a bit, moving the
> > devm_gpiochip_add_data() as the last call. This means that when the
> > gpiochip is registered [and available to consumers], it should be
> > initialized.
> >
> > It's still possible that the devm_gpiochip_add_data() call could fail,
> > leaving the chip in a partially initialized state, but that was possible
> > even before this change; it was just some other partially initialized
> > state.
>
> ...
>
> >       /* Enable GPIO0 interrupts */
>
> ^^^^^
>
> > +     return devm_gpiochip_add_data(dev, &wg->chip, wg);
>
> This is dangerous change. How did you test it?
>
> The handler now can be called before chip and actual handling code is
> registered. It means at least two possible (bad) scenarios:
>  1) the handler may dereference dangling or NULL pointer;
>  2) the IRQ may be level interrupt and we may got 100000 IRQs and
>     IRQ core will disable it leaving device completely unfunctional.


Makes sense.
Let's drop this :)


>
> --
> With Best Regards,
> Andy Shevchenko
>
>