linux-kernel - Re: [PATCH 3/8] gpio: tqmx86: change tqmx86_gpio_write() order of arguments to match regmap API

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]

Date: Wed, 29 May 2024 14:23:46 +0200
From: Matthias Schiffer <matthias.schiffer@...tq-group.com>
To: Andrew Lunn <andrew@...n.ch>, Bartosz Golaszewski <brgl@...ev.pl>
Cc: Linus Walleij <linus.walleij@...aro.org>, linux-gpio@...r.kernel.org, 
 linux-kernel@...r.kernel.org, Gregor Herburger
 <gregor.herburger@...group.com>,  linux@...tq-group.com
Subject: Re: [PATCH 3/8] gpio: tqmx86: change tqmx86_gpio_write() order of
 arguments to match regmap API

On Wed, 2024-05-29 at 14:11 +0200, Andrew Lunn wrote:
> 
> On Wed, May 29, 2024 at 02:03:35PM +0200, Bartosz Golaszewski wrote:
> > On Wed, May 29, 2024 at 9:46 AM Matthias Schiffer
> > <matthias.schiffer@...tq-group.com> wrote:
> > > 
> > > Conversion to actually use regmap does not seem useful for this driver,
> > > as regmap can't properly represent separate read-only and write-only
> > > registers at the same address, but we can at least match the API to make
> > > the code clearer.
> > > 
> > > No functional change intended.
> > > 
> > > Fixes: b868db94a6a7 ("gpio: tqmx86: Add GPIO from for this IO controller")
> > 
> > This is not a fix.
> 
> Agreed.
> 
> I'm somewhat conflicted by this patch. It is a step towards using
> regmap, but then says regmap does not make sense. So why make that
> step?
> 
> Changing the order of parameters like this seems like it is will make
> back porting bug fixes harder, unless all supported versions are
> changed, which is why fixes make sense. Does the compiler at least
> issue a warning if the parameters are used the wrong way around?
> 
> Overall, i'm leaning towards just dropping it.
> 
> 	 Andrew



Okay, will drop this patch.

Matthias