Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
MIME-Version: 1.0
References: <CAHk-=wiHa0vsZseZES=1T0rJ4Z_bC5cwHMUJfqFL9hVpvB283g@mail.gmail.com>
 <20220314192522.GA3031157@roeck-us.net> <CAHk-=wiEhs+4P1TNh2sNnk04D1FFdNThk6XLOMxzkRL72PEXFw@mail.gmail.com>
 <CACjc_5paC=X4znTty8LBtobqBW2nq4mbQYnw_TMgVEFb1A7mhA@mail.gmail.com>
In-Reply-To: <CACjc_5paC=X4znTty8LBtobqBW2nq4mbQYnw_TMgVEFb1A7mhA@mail.gmail.com>
From:   Linus Torvalds <torvalds@linux-foundation.org>
Date:   Mon, 14 Mar 2022 18:47:11 -0700
Message-ID: <CAHk-=wh0QBksyaTEn4gk=mn6hgAhp3e8i9mRsr657Dd-kQ3MKg@mail.gmail.com>
Subject: Re: Linux 5.17-rc8
To:     Marcelo Roberto Jimenez <marcelo.jimenez@gmail.com>
Cc:     Guenter Roeck <linux@roeck-us.net>,
        Thierry Reding <treding@nvidia.com>,
        Linus Walleij <linus.walleij@linaro.org>,
        Vidya Sagar <vidyas@nvidia.com>,
        Edmond Chung <edmondchung@google.com>,
        Andrew Chant <achant@google.com>,
        Will McVicker <willmcvicker@google.com>,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
        Bartosz Golaszewski <brgl@bgdev.pl>
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

On Mon, Mar 14, 2022 at 5:45 PM Marcelo Roberto Jimenez
<marcelo.jimenez@gmail.com> wrote:
>
> At a certain point, I tried Thorsten's suggestion to add a gpio-ranges
> property in a way similar to another patch, but the kernel went into
> an EPROBE_DEFER deadlock. Thierry Reding made some comments about this
> in the sequence.

Hmm. The problem does sound like that particular driver doesn't use
the pin_ranges thing, so then the tests for an empty pin_ranges will
always be true.

The EPROBE_DEFER deadlock then sounds like something went wrong in the
gpio-ranges patch when you tried to fix it - but I don't actually find
that patch or that attempt, so I can't even guess at it.

This whole code pin_ranges code looks very odd:
gpiochip_add_pin{group}_range() seems to add the pin ranges properly,
but that actual gpiochip_add_pin_ranges() function does *not*.

It just expects that that the 'add_pin_ranges()' callback exists, and
if it doesn't, does nothing at all.

Which then makes those

        if (list_empty(&gc->gpiodev->pin_ranges))
                return 0;

tests very suspicious - because if some doesn't implement that
add_pin_ranges() callback, it looks like nothing at all ever gets
done, because nothing calls the function to actually add the pinrange.
And then that "list_empty()" test very much will trigger.

IOW, it looks like either a gpio controller has to implement that
'add_pin_ranges()' function (only tegra), or it needs to always add
the pin ranges at probe time.

Am I guessing right that the driver that you use does neither?

LinusW/Bartoz - this all really sounds strange to me. Maybe I'm
misreading the situation entirely. Should there be some sanity-test
that any gpio/pinctrl driver that uses gpiochip_generic_request()
would either have to have that add_pin_ranges() callback, or a
successful probe needs to always populate that 'gpiodev->pin_ranges'
list?

Or maybe I'm misreading the situation entirely. I don't know the code
- I'm just grepping for things and trying to make sense of how that
'->pin_ranges' list is supposed to work.

But for now, I think that patch has to be reverted.

               Linus