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;
Date:   Tue, 25 Apr 2023 22:36:37 +0300
From:   Aaro Koskinen <aaro.koskinen@iki.fi>
To:     Andreas Kemnade <andreas@kemnade.info>
Cc:     linux-omap@vger.kernel.org, linux-gpio@vger.kernel.org,
        Bartosz Golaszewski <bartosz.golaszewski@linaro.org>,
        Tony Lindgren <tony@atomide.com>, linux-kernel@vger.kernel.org
Subject: Re: [BISECTED REGRESSION] OMAP1 GPIO breakage
Message-ID: <20230425193637.GH444508@darkstar.musicnaut.iki.fi>
References: <20230425173241.GF444508@darkstar.musicnaut.iki.fi>
 <20230425201117.457f224c@aktux>
 <20230425183857.GG444508@darkstar.musicnaut.iki.fi>
 <20230425212040.5a4d5b09@aktux>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20230425212040.5a4d5b09@aktux>
Precedence: bulk

On Tue, Apr 25, 2023 at 09:20:40PM +0200, Andreas Kemnade wrote:
> Aaro Koskinen <aaro.koskinen@iki.fi> wrote:
> > Which commit introduced that regression? Also, the changelog mentions
> > it happens only with "unusual" probe order. Now, all the ordinary cases
> > for OMAP1 are broken.
> > 
> did not bisect that to an exact commit.
> Unusual probe order: on the device where I tested it,
> I did not see a completely successful probe.

If you cannot point out a working past commit, there was no regression. If
you fix something that hasn't worked before or has been long time broken,
it must not cause breakage to other current users.

> > And it's not just that tps65010 thing. E.g. 770 fails to boot as well
> > and it doesn't use it; and reverting 92bf78b33b0b fixes that one as
> > well. AFAIK it's because all the gpio_request()s in OMAP1 board files
> > stopped now working.
> > 
> so we break every non-devicetree user of omap-gpio? 

It seems so.

A.