From: William Breathitt Gray <william.gray@linaro.org>
To: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Cc: linus.walleij@linaro.org, brgl@bgdev.pl,
linux-gpio@vger.kernel.org, linux-kernel@vger.kernel.org,
michael@walle.cc, broonie@kernel.org
Subject: Re: [PATCH v2 4/4] gpio: i8255: Migrate to regmap API
Date: Sun, 13 Nov 2022 09:07:42 -0500 [thread overview]
Message-ID: <Y3D6Lji9bKeSbJaI@fedora> (raw)
In-Reply-To: <Y3Dol6rHduFNQT85@smile.fi.intel.com>
[-- Attachment #1: Type: text/plain, Size: 2771 bytes --]
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@linux.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@linaro.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
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
next prev parent reply other threads:[~2022-11-13 14:14 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-11-11 1:55 [PATCH v2 0/4] Migrate i8255 GPIO drivers to regmap API William Breathitt Gray
2022-11-11 1:55 ` [PATCH v2 1/4] gpio: regmap: Always set gpio_chip get_direction William Breathitt Gray
2022-11-13 12:40 ` Andy Shevchenko
2022-11-13 13:21 ` William Breathitt Gray
2022-11-16 11:34 ` Robert Marko
2022-11-16 15:41 ` Michael Walle
2022-11-16 15:54 ` Andy Shevchenko
2022-11-17 14:22 ` William Breathitt Gray
2022-11-17 14:36 ` Michael Walle
2022-11-11 1:55 ` [PATCH v2 2/4] regmap-irq: Add handle_mask_sync() callback William Breathitt Gray
2022-11-13 12:42 ` Andy Shevchenko
2022-11-13 13:08 ` William Breathitt Gray
2022-11-13 13:11 ` Andy Shevchenko
2022-11-15 17:14 ` Mark Brown
2022-11-17 15:00 ` William Breathitt Gray
2022-11-22 1:00 ` William Breathitt Gray
2022-11-11 1:55 ` [PATCH v2 3/4] gpio: 104-idi-48: Migrate to regmap API William Breathitt Gray
2022-11-11 1:55 ` [PATCH v2 4/4] gpio: i8255: " William Breathitt Gray
2022-11-13 12:52 ` Andy Shevchenko
2022-11-13 14:07 ` William Breathitt Gray [this message]
2022-11-13 14:13 ` William Breathitt Gray
2022-11-14 13:14 ` Andy Shevchenko
2022-11-17 16:18 ` Michael Walle
2022-11-17 16:21 ` Mark Brown
2022-11-17 16:30 ` Michael Walle
2022-11-18 11:51 ` Mark Brown
2022-11-20 16:57 ` William Breathitt Gray
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Y3D6Lji9bKeSbJaI@fedora \
--to=william.gray@linaro.org \
--cc=andriy.shevchenko@linux.intel.com \
--cc=brgl@bgdev.pl \
--cc=broonie@kernel.org \
--cc=linus.walleij@linaro.org \
--cc=linux-gpio@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=michael@walle.cc \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).