On Sun, Nov 13, 2022 at 09:13:34AM -0500, William Breathitt Gray wrote: > 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/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. Yes, that's what I meant. Thank you! -- With Best Regards, Andy Shevchenko