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: <CAF78GY0jB_oeKgfZc4SHWBVusGnNfxKk5jTC4UBDsteSEVEzTw@mail.gmail.com>
In-Reply-To: <CAF78GY0jB_oeKgfZc4SHWBVusGnNfxKk5jTC4UBDsteSEVEzTw@mail.gmail.com>
From:   Andy Shevchenko <andy.shevchenko@gmail.com>
Date:   Mon, 28 Jun 2021 16:40:51 +0300
Message-ID: <CAHp75VeZwUiK2v8HZ=MLGSkK8wLudDEJFhBSm--Wu9gzABhmSg@mail.gmail.com>
Subject: Re: gpiochip_lock_as_irq on pins without FLAG_REQUESTED: bug or
 feature ?
To:     Vincent Pelletier <plr.vincent@gmail.com>
Cc:     Linus Walleij <linus.walleij@linaro.org>,
        Bartosz Golaszewski <bgolaszewski@baylibre.com>,
        "open list:GPIO SUBSYSTEM" <linux-gpio@vger.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

On Mon, Jun 28, 2021 at 6:37 AM Vincent Pelletier <plr.vincent@gmail.com> wrote:
>
> Hello,
>
> While trying to debug an IRQ handling issue on a sifive-unmatched board
> (which is a very recent board on a recent architecture, so I would not
> be overly surprised if there were bugs in hiding), I realised that I was able
> to claim via sysfs GPIO pins which are being actively used as IRQ sources.
>
> Checking drivers/gpio/gpiolib.c and kernel/irq/chip.c, I believe this is because
> gpiolib (gpiochip_irq_reqres, gpiochip_reqres_irq, gpiochip_lock_as_irq)
> does not call gpiod_request_{,commit}, resulting in a pin which is available
> for use. I could confirm this by adding (just as a debugging aid):
>   WARN_ON(!test_bit(FLAG_REQUESTED, &desc->flags));
> early in gpiochip_lock_as_irq, and this statement gets triggered.
>
> Is this intentional ?

IIRC the GPIO can be locked as IRQ without being requested (perhaps
for legacy/historical reasons). But I forgot all code paths anyway, so
I'm expecting that Linus and  or Bart can elaborate this better.

> Does this requesting belong to something else in the codepath from
> request_threaded_irq (and similar) ?
> Could it be something missing in the devicetree for this board ?
>
> Also, I notice that both gpiochip_hierarchy_add_domain and
> gpiochip_reqres_irq call gpiochip_lock_as_irq, and I am surprised I do not
> get any error about this: in my understanding only the first call on a given pin
> should succeed, but with my WARN_ON I am seeing both stack traces and
> no other warning.


-- 
With Best Regards,
Andy Shevchenko