mbox series

[00/10] adp5588-keys refactor and fw properties support

Message ID 20220708093448.42617-1-nuno.sa@analog.com (mailing list archive)
Headers show
Series adp5588-keys refactor and fw properties support | expand

Message

Nuno Sa July 8, 2022, 9:34 a.m. UTC 
The main goal of this patchset is to remove platform data and replace it by
firmware properties. Original discussion in [1].

While in here, some refactor was done to the driver. The most noticeable one
is to replace the GPIs events handling by irqchip support so that this gpi
keys can be "consumed" by the gpio-keys driver (also as suggested in [1]).
With this, the gpio-adp5588 can be removed. This change comes first so that
we can already remove some platform data variables making it easier to
completly replace it by firmware properties further down in the series.

As there's no users of the platform data, I just replace it in a single
patch as there's no point in having support for both (even though it might
be harder to review the patch as-is).

Special note to the gpio-adp5588 driver removal. I'm aware of some changes
to the driver in [2]. These changes are in the gpio tree and this patchset
is naturally based on the input tree which means that patch 2 will
not apply. So, I'm not really sure how to handle this. I guess in this
case the conflict is easy to handle :) but just let me know on how to
proceed in here if there's anything for me to do.

[1]: https://lore.kernel.org/linux-input/20220504084617.36844-1-u.kleine-koenig@pengutronix.de/
[2]: https://lore.kernel.org/linux-gpio/20220628193906.36350-3-andriy.shevchenko@linux.intel.com/

Nuno Sá (10):
  input: keyboard: adp5588-keys: support gpi key events as 'gpio keys'
  gpio: gpio-adp5588: drop the driver
  input: keyboard: adp5588-keys: bail out on returned error
  input: keyboard: adp5588-keys: add support for fw properties
  dt-bindings: input: adp5588-keys: add bindings
  input: keyboard: adp5588-keys: do not check for irq presence
  input: keyboard: adp5588-keys: fix coding style warnings
  input: keyboard: adp5588-keys: add optional reset gpio
  input: keyboard: adp5588-keys: add regulator support
  input: keyboard: adp5588-keys: Use new PM macros

 .../bindings/input/adi,adp5588-keys.yaml      | 110 +++
 MAINTAINERS                                   |   2 +-
 drivers/gpio/Kconfig                          |  14 -
 drivers/gpio/Makefile                         |   1 -
 drivers/gpio/gpio-adp5588.c                   | 471 ------------
 drivers/input/keyboard/Kconfig                |   3 +
 drivers/input/keyboard/adp5588-keys.c         | 710 ++++++++++++------
 include/linux/platform_data/adp5588.h         | 171 -----
 8 files changed, 580 insertions(+), 902 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/input/adi,adp5588-keys.yaml
 delete mode 100644 drivers/gpio/gpio-adp5588.c
 delete mode 100644 include/linux/platform_data/adp5588.h

Comments

Andy Shevchenko July 8, 2022, 1:59 p.m. UTC | #1 
On Fri, Jul 8, 2022 at 11:36 AM Nuno Sá <nuno.sa@analog.com> wrote:
>
> The main goal of this patchset is to remove platform data and replace it by
>
> firmware properties. Original discussion in [1].
>
>
>
> While in here, some refactor was done to the driver. The most noticeable one
>
> is to replace the GPIs events handling by irqchip support so that this gpi
>
> keys can be "consumed" by the gpio-keys driver (also as suggested in [1]).
>
> With this, the gpio-adp5588 can be removed. This change comes first so that
>
> we can already remove some platform data variables making it easier to
>
> completly replace it by firmware properties further down in the series.
>
>
>
> As there's no users of the platform data, I just replace it in a single
>
> patch as there's no point in having support for both (even though it might
>
> be harder to review the patch as-is).
>
>
>
> Special note to the gpio-adp5588 driver removal. I'm aware of some changes
>
> to the driver in [2]. These changes are in the gpio tree and this patchset
>
> is naturally based on the input tree which means that patch 2 will
>
> not apply. So, I'm not really sure how to handle this. I guess in this
>
> case the conflict is easy to handle :) but just let me know on how to
>
> proceed in here if there's anything for me to do.

Resolving conflict like this is easy, just input subsys maintainer
needs to tell Linus about it to Linus in PR.