mbox series

[00/14] Remove support for platform data from samsung keypad

Message ID 20240819045813.2154642-1-dmitry.torokhov@gmail.com (mailing list archive)
Headers show
Series Remove support for platform data from samsung keypad | expand

Message

Dmitry Torokhov Aug. 19, 2024, 4:57 a.m. UTC
Hi,

This series attempts to rework samsumg=keypad driver to stop using
platform data and instead rely on generic device properties only.

The first 8 patches are general cleanup/facelift patches.

The 9th patch introduces alternative binding that is more compact that
the original one, which makes it more suitable for use in legacy (non
DT) boards with static device properties. Note that the "new" binding is
the standard binding for matrix keypads.

Patch #10 implements the new binding in the driver, #11 converts the
only user of platform data in the mainline tree to the static device
properties, and #12 drops support for platform data from the driver.

Patches #13 and #14 are "bonus" converting the rest of crag6410 to use
software nodes/properties to describe GPIO keys, LEDs and other
peripherals. Note that I believe they fix and issue with recent
conversion to GPIO lookup tables - the names of gpiochip structures I
think are "GP<N>" ("GPK", "GPL", etc) and not "GPIO<N>".

Mark, you said you are using this board, it would be great if you could
give this a spin.

Thanks!

Dmitry Torokhov (14):
  Input: samsung-keypad - switch to using devm_clk_get_prepared()
  Input: samsung-keypad - do not set input device's parent explicitly
  Input: samsung-keypad - do not combine memory allocation checks
  Input: samsung-keypad - use struct_size() helper
  Input: samsung-keypad - use devm to disable runtime PM
  Input: samsung-keypad - use guard notation to acquire mutex
  Input: samsung-keypad - use per-chip parameters
  Input: samsung-keypad - use BIT() and GENMASK() where appropriate
  dt-bindings: input: samsung,s3c6410-keypad: introduce compact binding
  Input: samsung-keypad - handle compact binding
  ARM: s3c: crag6410: switch keypad device to software properties
  Input: samsung-keypad - remove support for platform data
  ARM: s3c: crag6410: use software nodes/properties to set up GPIO keys
  ARM: s3c: crag6410 - convert GPIO lookup tables to property entries

 .../input/samsung,s3c6410-keypad.yaml         |  57 +++-
 arch/arm/mach-s3c/Kconfig                     |   5 -
 arch/arm/mach-s3c/Kconfig.s3c64xx             |   1 -
 arch/arm/mach-s3c/Makefile.s3c64xx            |   1 -
 arch/arm/mach-s3c/devs.c                      |  62 ----
 arch/arm/mach-s3c/devs.h                      |   2 -
 arch/arm/mach-s3c/gpio-samsung-s3c64xx.h      |   5 +
 arch/arm/mach-s3c/gpio-samsung.c              |  35 ++
 arch/arm/mach-s3c/keypad.h                    |  27 --
 arch/arm/mach-s3c/mach-crag6410.c             | 242 ++++++++-----
 arch/arm/mach-s3c/setup-keypad-s3c64xx.c      |  20 --
 drivers/input/keyboard/samsung-keypad.c       | 318 ++++++++----------
 include/linux/input/samsung-keypad.h          |  39 ---
 13 files changed, 398 insertions(+), 416 deletions(-)
 delete mode 100644 arch/arm/mach-s3c/keypad.h
 delete mode 100644 arch/arm/mach-s3c/setup-keypad-s3c64xx.c
 delete mode 100644 include/linux/input/samsung-keypad.h

Comments

Arnd Bergmann Aug. 19, 2024, 9:40 a.m. UTC | #1
On Mon, Aug 19, 2024, at 06:57, Dmitry Torokhov wrote:
>
> This series attempts to rework samsumg=keypad driver to stop using
> platform data and instead rely on generic device properties only.
>
> The first 8 patches are general cleanup/facelift patches.
>
> The 9th patch introduces alternative binding that is more compact that
> the original one, which makes it more suitable for use in legacy (non
> DT) boards with static device properties. Note that the "new" binding is
> the standard binding for matrix keypads.
>
> Patch #10 implements the new binding in the driver, #11 converts the
> only user of platform data in the mainline tree to the static device
> properties, and #12 drops support for platform data from the driver.
>
> Patches #13 and #14 are "bonus" converting the rest of crag6410 to use
> software nodes/properties to describe GPIO keys, LEDs and other
> peripherals. Note that I believe they fix and issue with recent
> conversion to GPIO lookup tables - the names of gpiochip structures I
> think are "GP<N>" ("GPK", "GPL", etc) and not "GPIO<N>".

I had a (brief) look at the patches, everything looks fine to
me, thanks for working on this! Let's see what Mark and 
Krzysztof think.

      Arnd
Dmitry Torokhov Oct. 4, 2024, 1:38 p.m. UTC | #2
On Mon, Aug 19, 2024 at 11:40:56AM +0200, Arnd Bergmann wrote:
> On Mon, Aug 19, 2024, at 06:57, Dmitry Torokhov wrote:
> >
> > This series attempts to rework samsumg=keypad driver to stop using
> > platform data and instead rely on generic device properties only.
> >
> > The first 8 patches are general cleanup/facelift patches.
> >
> > The 9th patch introduces alternative binding that is more compact that
> > the original one, which makes it more suitable for use in legacy (non
> > DT) boards with static device properties. Note that the "new" binding is
> > the standard binding for matrix keypads.
> >
> > Patch #10 implements the new binding in the driver, #11 converts the
> > only user of platform data in the mainline tree to the static device
> > properties, and #12 drops support for platform data from the driver.
> >
> > Patches #13 and #14 are "bonus" converting the rest of crag6410 to use
> > software nodes/properties to describe GPIO keys, LEDs and other
> > peripherals. Note that I believe they fix and issue with recent
> > conversion to GPIO lookup tables - the names of gpiochip structures I
> > think are "GP<N>" ("GPK", "GPL", etc) and not "GPIO<N>".
> 
> I had a (brief) look at the patches, everything looks fine to
> me, thanks for working on this! Let's see what Mark and 
> Krzysztof think.

Mark, were you able to give this a spin? Or should I address the DT
binding comments from Krzysztof and Connor and resent for merge?

Thanks.
Mark Brown Oct. 4, 2024, 2:58 p.m. UTC | #3
On Fri, Oct 04, 2024 at 06:38:01AM -0700, Dmitry Torokhov wrote:
> On Mon, Aug 19, 2024 at 11:40:56AM +0200, Arnd Bergmann wrote:

> > I had a (brief) look at the patches, everything looks fine to
> > me, thanks for working on this! Let's see what Mark and 
> > Krzysztof think.

> Mark, were you able to give this a spin? Or should I address the DT
> binding comments from Krzysztof and Connor and resent for merge?

Sorry, no - I've been some combination of ill, travelling and super busy
since you posted it (sadly the bootloader for the board only supports
booting from SD card so until I port u-boot it's not in my board farm
and I need to specifically set it up on my desk whenver I want to do
anything with it, especially for this where I need to poke at the
keypad).  I've got one more week of travel next week and one of the
major sources of super busy just got better so I'm reasonably hopeful
I'll get to it week of the 14th but probably worth respinning.