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: <20230425173241.GF444508@darkstar.musicnaut.iki.fi>
 <20230425201117.457f224c@aktux> <20230425183857.GG444508@darkstar.musicnaut.iki.fi>
 <20230425212040.5a4d5b09@aktux> <20230425193637.GH444508@darkstar.musicnaut.iki.fi>
 <20230425215848.247a936a@aktux> <20230426071910.GE14287@atomide.com> <20230504055156.GO14287@atomide.com>
In-Reply-To: <20230504055156.GO14287@atomide.com>
From:   Linus Walleij <linus.walleij@linaro.org>
Date:   Thu, 4 May 2023 14:13:32 +0200
Message-ID: <CACRpkdY9ShRATHa776KyzeArmQdKxdwGxJC11YnmhWiCdSGzEA@mail.gmail.com>
Subject: Re: [BISECTED REGRESSION] OMAP1 GPIO breakage
To:     Tony Lindgren <tony@atomide.com>
Cc:     Andreas Kemnade <andreas@kemnade.info>,
        Aaro Koskinen <aaro.koskinen@iki.fi>,
        linux-omap@vger.kernel.org, linux-gpio@vger.kernel.org,
        Bartosz Golaszewski <bartosz.golaszewski@linaro.org>,
        linux-kernel@vger.kernel.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

On Thu, May 4, 2023 at 7:52=E2=80=AFAM Tony Lindgren <tony@atomide.com> wro=
te:
> * Tony Lindgren <tony@atomide.com> [230426 07:20]:
> > Seems that we should just revert this patch for now and try again after
> > the issues have been fixed.
>
> Looking at the proposed fixes being posted seems like they are quite
> intrusive.. How about we partially revert this patch so omap1 still
> uses static assigment of gpios?

I think Andreas patch (commit 92bf78b33b0b463b00c6b0203b49aea845daecc8)
kind of describes the problem with that: the probe order is now unpredictab=
le,
so if we revert the patch then that problem returns, but I don't know how
serious that problem is.

It's one of the reasons why we can't have static GPIO bases anymore FWIW.
The only fix that would actually fix the problem would be to undo deferred
probe and the ongoing work to determine probe order from the device
tree resource tree, and it is way too late for that, it's just not possible=
.

Yours,
Linus Walleij