On Sun, Nov 13, 2022 at 09:07:42AM -0500, William Breathitt Gray wrote: > 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: > > > 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. Sorry, I realize now that you meant to split the i8255 gpio_regmap additions to their own patch, perform the driver migrations in the own respective patches, and then finally remove the dangling unused i8255 functions and structures. Yes I think that would make for a cleaner patch series so I'll split it up that way. William Breathitt Gray
Attachment:
signature.asc
Description: PGP signature
