Re: [PATCH v1] gpio: Extend TODO to cover code duplication avoidance

[Andy Shevchenko <andriy.shevchenko@xxxxxxxxxxxxxxx>]

On Fri, Apr 03, 2020 at 01:05:51AM +0530, Vaibhav Gupta wrote:
> On Fri, Apr 3, 2020 at 12:51 AM Andy Shevchenko
> <andriy.shevchenko@xxxxxxxxxxxxxxx> wrote:
> >
> > It appears at least two drivers has a lot of duplication code in
> > GPIO subsystem.
> Yes, I was surprised too. I studied the gpio-pch to understand how
> conversions are going to take place. But when I started working
> on gpio-ml-ioh, It was exactly same and I could do it in no other
> way, except like that of gpio-pch.

I guess this answers the question in the previous thread.
To be clear, scrap your patch and don't touch just gpio-ml-ioh alone.
Basically it should be one patch to get rid the driver.

JFYI, I will send couple of clean ups against gpio-pch.

> 
> -- Vaibhav Gupta
> To avoid adding more and get rid of existing duplication
> > extend TODO.
> >
> > Signed-off-by: Andy Shevchenko <andriy.shevchenko@xxxxxxxxxxxxxxx>
> > ---
> >  drivers/gpio/TODO | 4 ++++
> >  1 file changed, 4 insertions(+)
> >
> > diff --git a/drivers/gpio/TODO b/drivers/gpio/TODO
> > index 3a44e6ae52bd..b989c9352da2 100644
> > --- a/drivers/gpio/TODO
> > +++ b/drivers/gpio/TODO
> > @@ -99,6 +99,10 @@ similar and probe a proper driver in the gpiolib subsystem.
> >  In some cases it makes sense to create a GPIO chip from the local driver
> >  for a few GPIOs. Those should stay where they are.
> >
> > +At the same time it makes sense to get rid of code duplication in existing or
> > +new coming drivers. For example, gpio-ml-ioh should be incorporated into
> > +gpio-pch. In similar way gpio-intel-mid into gpio-pxa.
> > +
> >
> >  Generic MMIO GPIO
> >
> > --
> > 2.25.1
> >

-- 
With Best Regards,
Andy Shevchenko