RE: [PATCH] Input: adp5588-keys: Remove unused driver

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




> -----Original Message-----
> From: Uwe Kleine-König <u.kleine-koenig@xxxxxxxxxxxxxx>
> Sent: Freitag, 27. Mai 2022 09:35
> To: Hennerich, Michael <Michael.Hennerich@xxxxxxxxxx>
> Cc: Arnd Bergmann <arnd@xxxxxxxx>; Bogdan, Dragos
> <Dragos.Bogdan@xxxxxxxxxx>; Dmitry Torokhov
> <dmitry.torokhov@xxxxxxxxx>; Sa, Nuno <Nuno.Sa@xxxxxxxxxx>;
> kernel@xxxxxxxxxxxxxx; linux-input@xxxxxxxxxxxxxxx
> Subject: Re: [PATCH] Input: adp5588-keys: Remove unused driver
> 
> 
> Hello,
> 
> On Fri, May 06, 2022 at 11:57:57AM +0000, Hennerich, Michael wrote:
> > > On Thu, May 05, 2022 at 06:20:22AM +0000, Hennerich, Michael wrote:
> > > > If we start removing drivers which obviously don't have a mainline
> > > > in-tree user, we would upset up many users of these drivers.
> > > > I agree on updating this driver to make platform data optional.
> > > > We could provide a patch in a few days.
> > >
> > > Just to add some background why I stumbled over this driver: On of
> > > my current quests is to make i2c remove callbacks return void. As a
> > > preparation for that I work on updating all i2c drivers to return 0
> > > in
> > > .remove() to make the change to void have no side effects.
> > >
> > > One of the offenders is drivers/gpio/gpio-adp5588.c, which in the
> > > presence of a
> > > pdata->teardown callback might return a non-zero value from
> > > pdata->.remove(). While
> > > looking at the pdata of possible devices I only found
> > > drivers/input/keyboard/adp5588-keys.c.
> > >
> > > So the options for my quest are in increasing impact order:
> > >
> > >  a) just warn if struct adp5588_gpio_platform_data::teardown fails and
> > >     still return 0 from .remove()
> > >  b) make struct adp5588_gpio_platform_data::teardown return void
> > >  c) drop teardown support from adp5588_gpio_platform_data
> > >  d) drop platform support from gpio-adp5588
> > >  e) drop gpio-adp5588
> > >
> > > Currently I'd go for at least d).
> > >
> > > Having said that I think e) has a net benefit. If there is no user
> > > left it reduces maintainance burden. If there is a user left, they
> > > hopefully will tell us, we can restore the driver from git history
> > > and then at least know a tester for future cleanups and changes.
> >
> > Hi Uwe,
> >
> > Thanks for the explanation.
> >
> > I know that there are users of this driver. But I admit, we should
> > have earlier made platform_data support optional and also add proper dt
> bindings.
> > We're in progress doing so. And in the meanwhile, I would prefer a
> > less disruptive intermediate change. For example c) with the promise we're
> working on d).
> 
> FTR: a part of c) hit the mailing list a few days ago. This is good enough for my
> purpose, but to complete platform teardown (and setup) support, it must be
> ripped from adp5588-keys.c, too. I won't do that as it isn't in the way for my
> quest.
> 
> See
> https://lore.kernel.org/linux-gpio/20220523083947.840708-1-u.kleine-
> koenig@xxxxxxxxxxxxxx
> for your opportunity to ack the patch.

Hi Uwe,

Thanks for the reminder!
The driver cleanup is still in the works. We'll likely remove the platform data support completely form the driver.

Best regards,
Michael

> 
> Best regards
> Uwe
> 
> --
> Pengutronix e.K.                           | Uwe Kleine-König            |
> Industrial Linux Solutions                 | https://www.pengutronix.de/ |




[Index of Archives]     [Linux Media Devel]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Linux Wireless Networking]     [Linux Omap]

  Powered by Linux