linux-kernel - Re: [PATCH v2 4/4] gpio: i8255: Migrate to 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]

Message-ID: <Y3D6Lji9bKeSbJaI@fedora>
Date:   Sun, 13 Nov 2022 09:07:42 -0500
From:   William Breathitt Gray <william.gray@...aro.org>
To:     Andy Shevchenko <andriy.shevchenko@...ux.intel.com>
Cc:     linus.walleij@...aro.org, brgl@...ev.pl,
        linux-gpio@...r.kernel.org, linux-kernel@...r.kernel.org,
        michael@...le.cc, broonie@...nel.org
Subject: Re: [PATCH v2 4/4] gpio: i8255: Migrate to regmap API

On Sun, Nov 13, 2022 at 02:52:39PM +0200, Andy Shevchenko wrote:
> On Thu, Nov 10, 2022 at 08:55:53PM -0500, William Breathitt Gray wrote:
> > The regmap API supports IO port accessors so we can take advantage of
> > regmap abstractions rather than handling access to the device registers
> > directly in the driver. The 104-dio-48e and gpio-mm modules depend on
> > the i8255 library and are thus updated accordingly.
> > 
> > By leveraging the gpio_regmap API, the i8255 library is reduced to
> > simply a devm_i8255_regmap_register() function, a configuration
> > structure struct i8255_regmap_config, and a helper macro
> > i8255_volatile_regmap_range() provided to simplify volatile PPI register
> > hinting for the regmap.
> 
> > Cc: Andy Shevchenko <andriy.shevchenko@...ux.intel.com>
> 
> Suggested-by?
> (I'm not insisting, just consider if it's appropriate to use here or in the
>  other patches)

No problem, I'll make sure your Suggested-by lines are properly added
for the patches. ;-)

> > Signed-off-by: William Breathitt Gray <william.gray@...aro.org>
> > ---
> >  drivers/gpio/Kconfig            |   2 +
> >  drivers/gpio/gpio-104-dio-48e.c | 397 ++++++++++-------------------
> >  drivers/gpio/gpio-gpio-mm.c     | 151 +++--------
> >  drivers/gpio/gpio-i8255.c       | 429 +++++++++++---------------------
> >  drivers/gpio/gpio-i8255.h       |  80 +++---
> 
> Can we actually split this to a few steps:
>  - providing gpio-i8255-regmap
>  - providing gpio-mm-regmap
>  - converting the driver
>  - removing not used modules (one by one)
> ?
> 
> In this case if any regression somewhere appears, we can always perform a
> (semi-)revert for a certain driver.

Sure, I can split the regmap_irq migration for 104-dio-48e into a
separate precursor patch to reduce the amount of changes we see here and
provide a revert path for these IRQ changes. I can do a similar change
for 104-idi-48 as well.

The rest of the changes for 104-dio-48 and gpio-mm are essentially just
the regmap configurations, so the patch will be largely identical even
if we migrate gpio-i8255 to regmap API first before migrating again to
the gpio_regmap in a second patch.

I believe the reason the changes look ugly in this patch is because the
large number of lines deleted is confusing the match heuristic for diff
so the changes aren't lining up nicely into distinct deletion/creation
blocks. I can play around with the git diff "--break-rewrites" option to
get it to produce a nicer diff; I think gpio-mm looks much easier to
review as a rewrite rather than inline diffs [0].

[0] https://gitlab.com/vilhelmgray/gpio/-/raw/61327a67cc308af413471a69a4810b2785e53e8e/drivers/gpio/gpio-gpio-mm.c

William Breathitt Gray

Download attachment "signature.asc" of type "application/pgp-signature" (229 bytes)