linux-kernel - Re: [PATCH 0/8] gpio-tqmx86 fixes

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAMRc=Mfrcx1nPwoN8YJ+Hp_Z33oWDTsSHhOyOSdqjzy3RLcPLQ@mail.gmail.com>
Date: Wed, 29 May 2024 19:02:38 +0200
From: Bartosz Golaszewski <brgl@...ev.pl>
To: Matthias Schiffer <matthias.schiffer@...tq-group.com>
Cc: Linus Walleij <linus.walleij@...aro.org>, Andrew Lunn <andrew@...n.ch>, linux-gpio@...r.kernel.org, 
	linux-kernel@...r.kernel.org, 
	Gregor Herburger <gregor.herburger@...group.com>, linux@...tq-group.com
Subject: Re: [PATCH 0/8] gpio-tqmx86 fixes

On Wed, May 29, 2024 at 2:55 PM Matthias Schiffer
<matthias.schiffer@...tq-group.com> wrote:
>
> On Wed, 2024-05-29 at 14:08 +0200, Bartosz Golaszewski wrote:
> > On Wed, May 29, 2024 at 9:46 AM Matthias Schiffer
> > <matthias.schiffer@...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_BOTH
> > > 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 match
> > >     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ühlstraße 2, Gut Delling | 82229 Seefeld, Germany
> > > Amtsgericht München, HRB 105018
> > > Geschäftsführer: Detlef Schneider, Rüdiger Stahl, Stefan 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 nicer to implement (and to
> review) if they are based on the refactoring. I can leave out _tqmx86_gpio_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 separately" 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 leave 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