Received-SPF: pass (google.com: domain of linux-kernel+bounces-194498-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) client-ip=2604:1380:45d1:ec00::1;
Precedence: bulk
MIME-Version: 1.0
References: <cover.1716967982.git.matthias.schiffer@ew.tq-group.com>
 <CAMRc=MeN+QzzSy1BwiD57Y3vTF9Ups=6dtWuFbPmxzOxic=arQ@mail.gmail.com> <ad4dee46c4e0e508c54dd79bab7f45060099ef9b.camel@ew.tq-group.com>
In-Reply-To: <ad4dee46c4e0e508c54dd79bab7f45060099ef9b.camel@ew.tq-group.com>
From: Bartosz Golaszewski <brgl@bgdev.pl>
Date: Wed, 29 May 2024 19:02:38 +0200
Message-ID: <CAMRc=Mfrcx1nPwoN8YJ+Hp_Z33oWDTsSHhOyOSdqjzy3RLcPLQ@mail.gmail.com>
Subject: Re: [PATCH 0/8] gpio-tqmx86 fixes
To: Matthias Schiffer <matthias.schiffer@ew.tq-group.com>
Cc: Linus Walleij <linus.walleij@linaro.org>, Andrew Lunn <andrew@lunn.ch>, linux-gpio@vger.kernel.org, 
	linux-kernel@vger.kernel.org, 
	Gregor Herburger <gregor.herburger@tq-group.com>, linux@ew.tq-group.com
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Wed, May 29, 2024 at 2:55=E2=80=AFPM Matthias Schiffer
<matthias.schiffer@ew.tq-group.com> wrote:
>
> On Wed, 2024-05-29 at 14:08 +0200, Bartosz Golaszewski wrote:
> > On Wed, May 29, 2024 at 9:46=E2=80=AFAM Matthias Schiffer
> > <matthias.schiffer@ew.tq-group.com> wrote:
> > >
> > > This is the first series of improvements to the tqmx86 GPIO driver,
> > > which fixes some long-standing bugs - in particular, IRQ_TYPE_EDGE_BO=
TH
> > > can never have worked correctly.
> > >
> > > Other patches in the series are code cleanup, which is included as it
> > > makes the actual fixes much nicer. I have included the same Fixes tag=
 in
> > > all commits, as they will need to be cherry-picked together.
> > >
> > > A second series with new features (changing GPIO directions, support
> > > more GPIOs on SMARC TQMx86 modules) will be submitted when the fixes
> > > have been reviewed and merged.
> > >
> > > Gregor Herburger (1):
> > >   gpio: tqmx86: fix typo in Kconfig label
> > >
> > > Matthias Schiffer (7):
> > >   gpio: tqmx86: introduce shadow register for GPIO output value
> > >   gpio: tqmx86: change tqmx86_gpio_write() order of arguments to matc=
h
> > >     regmap API
> > >   gpio: tqmx86: introduce _tqmx86_gpio_update_bits() helper
> > >   gpio: tqmx86: add macros for interrupt configuration
> > >   gpio: tqmx86: store IRQ triggers without offsetting index
> > >   gpio: tqmx86: store IRQ trigger type and unmask status separately
> > >   gpio: tqmx86: fix broken IRQ_TYPE_EDGE_BOTH interrupt type
> > >
> > >  drivers/gpio/Kconfig       |   2 +-
> > >  drivers/gpio/gpio-tqmx86.c | 151 ++++++++++++++++++++++++++---------=
--
> > >  2 files changed, 106 insertions(+), 47 deletions(-)
> > >
> > > --
> > > TQ-Systems GmbH | M=C3=BChlstra=C3=9Fe 2, Gut Delling | 82229 Seefeld=
, Germany
> > > Amtsgericht M=C3=BCnchen, HRB 105018
> > > Gesch=C3=A4ftsf=C3=BChrer: Detlef Schneider, R=C3=BCdiger Stahl, Stef=
an Schneider
> > > https://www.tq-group.com/
> > >
> >
> > Hi Matthias!
> >
> > Not all patches in this series are fixes (as in: warrant being sent
> > upstream outside of the merge window). Please split the series into
> > two with the first one containing actual fixes to real bugs and the
> > second for any refactoring and improvements.
> >
> > Bart
>
>
> Hi Bartosz,
>
> as explained in the cover letter, I've found that the fixes become much n=
icer to implement (and to
> review) if they are based on the refactoring. I can leave out _tqmx86_gpi=
o_update_bits for now, but
> removing "add macros for interrupt configuration" and "store IRQ triggers=
 without offsetting index"
> does make the actual fixes "store IRQ trigger type and unmask status sepa=
rately" and "fix broken
> IRQ_TYPE_EDGE_BOTH interrupt type" somewhat uglier.
>
> That being said, you're the maintainer, and I will structure this series =
in any way you prefer. I
> can remove the mentioned refactoring, even though it makes the fixes less=
 pleasant. Another option
> would be that I can submit just the refactoring for -next for now, and le=
ave the fixes for a future
> series. Let me know how you want to proceed.
>
> Thanks,
> Matthias

The question is: do you want these fixes to be backported into stable
branches? Because if not then it's true that the ordering doesn't
matter. But if you do, then it makes more sense to put fixes first,
send them to Torvalds, get them backported and then add refactoring
changes on top.

Bart