Linux Input/HID development
 help / color / mirror / Atom feed
From: Dmitry Torokhov <dmitry.torokhov@gmail.com>
To: Arnd Bergmann <arnd@kernel.org>, Bartosz Golaszewski <brgl@kernel.org>
Cc: sashiko-reviews@lists.linux.dev, linux-input@vger.kernel.org,
	 Hans de Goede <hansg@kernel.org>,
	Jin Yao <yao.jin@linux.intel.com>
Subject: Re: [PATCH 02/10] [v3] input: gpio-keys: make legacy gpiolib optional
Date: Mon, 6 Jul 2026 21:54:32 -0700	[thread overview]
Message-ID: <akyF3Log1X8_FGIB@google.com> (raw)
In-Reply-To: <ah-1z9LhVG0wtfBw@google.com>

On Tue, Jun 02, 2026 at 10:10:28PM -0700, Dmitry Torokhov wrote:
> On Mon, Jun 01, 2026 at 08:32:31PM +0200, Arnd Bergmann wrote:
> > 
> > Hans, Dmitry, do you already have plans to deal with the
> > soc_button_array driver to move it away from legacy GPIOs?
> > 
> > So far I can see four possible ways we can deal with it,
> > but none that I actually like:
> > 
> > a) delay the problem, apply my original oneline change
> >    to 'select GPIOLIB_LEGACY' and fix it later, so we
> >    can make GPIOLIB_LEGACY default-disabled in 7.3.
> > 
> > b) add a gpiod member to struct gpio_keys_button and skip
> >    the intermediate gpio number here. Clean it up later.
> > 
> > c) always pass the gpio as an interrupt, as the driver
> >    already does for some machines
> > 
> > d) add dynamic device properties that duplicate the
> >    information from ACPI/DMI, so the driver can
> >    stop using platform data
> > 
> > e) disconnect gpio_keys_button from gpio-keys.c and
> >    register the buttons to the input subsystem
> >    directly from soc_button_device_create().
> 
> I tried doing e) and while it is possible I ended up re-implementing
> most of gpio_keys.c which is not great. We still need both GPIO and
> IRQ-only modes, and handling debouncing, both software and hardware, and
> so on. So I would like to see if d) is possible. The problem is that we
> need to reconstruct GPIO reference from existing gpio_desc. If Bart will
> be OK with something like below then I think the conversion should be
> achievable.

It turns out Bart was not on the CC list so I was waiting for response
in vain...

Bart, will you be OK with something like below?

> 
> gpiolib: Introduce gpiod_get_software_node_reference()
> 
> From: Dmitry Torokhov <dmitry.torokhov@gmail.com>
> 
> To support converting drivers (such as soc_button_array) to use static
> device properties/software nodes, we need a way to reconstruct a GPIO
> reference from an existing gpio_desc.
> 
> Introduce gpiod_get_software_node_reference() which populates a
> struct software_node_ref_args with the GPIO device's fwnode, the pin
> offset, and the appropriate active-low flag.
> 
> Assisted-by: Gemini:gemini-3.1-pro
> Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
> ---
>  drivers/gpio/gpiolib.c        |   35 +++++++++++++++++++++++++++++++++++
>  include/linux/gpio/consumer.h |   12 ++++++++++++
>  2 files changed, 47 insertions(+)
> 
> diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c
> index 1e6dce430dca..63cef0fb02b5 100644
> --- a/drivers/gpio/gpiolib.c
> +++ b/drivers/gpio/gpiolib.c
> @@ -247,6 +247,41 @@ int gpiod_hwgpio(const struct gpio_desc *desc)
>  }
>  EXPORT_SYMBOL_GPL(gpiod_hwgpio);
>  
> +/**
> + * gpiod_get_software_node_reference() - Reconstruct a software node reference
> + *                                       from a GPIO descriptor
> + * @desc: GPIO descriptor
> + * @args: Pointer to software node reference arguments structure to populate
> + *
> + * This function can be used to construct a software node reference from
> + * an existing GPIO descriptor. This is useful when a driver wants to pass
> + * a software node to a secondary device, but needs to reconstruct a GPIO
> + * reference dynamically.
> + *
> + * Returns:
> + * 0 on success, or a negative error code on failure.
> + */
> +int gpiod_get_software_node_reference(const struct gpio_desc *desc,
> +				      struct software_node_ref_args *args)
> +{
> +	struct gpio_device *gdev;
> +
> +	if (IS_ERR_OR_NULL(desc) || !args)
> +		return -EINVAL;
> +
> +	gdev = desc->gdev;
> +
> +	memset(args, 0, sizeof(*args));
> +	args->fwnode = dev_fwnode(&gdev->dev);
> +	args->nargs = 2;
> +	args->args[0] = gpiod_hwgpio(desc);
> +	if (test_bit(GPIOD_FLAG_ACTIVE_LOW, &desc->flags))
> +		args->args[1] = GPIO_ACTIVE_LOW;
> +
> +	return 0;
> +}
> +EXPORT_SYMBOL_GPL(gpiod_get_software_node_reference);
> +
>  /**
>   * gpiod_to_chip - Return the GPIO chip to which a GPIO descriptor belongs
>   * @desc:	descriptor to return the chip of
> diff --git a/include/linux/gpio/consumer.h b/include/linux/gpio/consumer.h
> index 3efb5cb1e1d1..c95b715a1d15 100644
> --- a/include/linux/gpio/consumer.h
> +++ b/include/linux/gpio/consumer.h
> @@ -11,6 +11,7 @@
>  struct acpi_device;
>  struct device;
>  struct fwnode_handle;
> +struct software_node_ref_args;
>  
>  struct gpio_array;
>  struct gpio_desc;
> @@ -177,6 +178,9 @@ int desc_to_gpio(const struct gpio_desc *desc);
>  
>  int gpiod_hwgpio(const struct gpio_desc *desc);
>  
> +int gpiod_get_software_node_reference(const struct gpio_desc *desc,
> +				      struct software_node_ref_args *args);
> +
>  struct gpio_desc *fwnode_gpiod_get_index(struct fwnode_handle *fwnode,
>  					 const char *con_id, int index,
>  					 enum gpiod_flags flags,
> @@ -545,6 +549,14 @@ static inline int desc_to_gpio(const struct gpio_desc *desc)
>  	return -EINVAL;
>  }
>  
> +static inline
> +int gpiod_get_software_node_reference(const struct gpio_desc *desc,
> +				      struct software_node_ref_args *args)
> +{
> +	WARN_ON(desc);
> +	return -EINVAL;
> +}
> +
>  static inline
>  struct gpio_desc *fwnode_gpiod_get_index(struct fwnode_handle *fwnode,
>  					 const char *con_id, int index,
> 
> Thanks.
> 

-- 
Dmitry

  reply	other threads:[~2026-07-07  4:54 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-05-20 18:38 [PATCH v2 00/10] gpiolib: fence off legacy interfaces Arnd Bergmann
2026-05-20 18:38 ` [PATCH 01/10] [v2] [net-next] net: dsa: b53: hide legacy gpiolib usage on non-mips Arnd Bergmann
2026-05-30  0:45   ` sashiko-bot
2026-06-01 16:50     ` Arnd Bergmann
2026-05-20 18:38 ` [PATCH 02/10] [v3] input: gpio-keys: make legacy gpiolib optional Arnd Bergmann
2026-05-21  9:03   ` Bartosz Golaszewski
2026-05-22  4:55   ` Matti Vaittinen
2026-05-22  8:28     ` Arnd Bergmann
2026-05-22 12:45       ` Matti Vaittinen
2026-05-25  8:57   ` Linus Walleij
2026-05-29  5:37     ` Dmitry Torokhov
2026-05-30  0:45   ` sashiko-bot
2026-06-01 18:32     ` Arnd Bergmann
2026-06-03  5:10       ` Dmitry Torokhov
2026-07-07  4:54         ` Dmitry Torokhov [this message]
2026-05-20 18:38 ` [PATCH 03/10] [v2] x86/olpc: select GPIOLIB_LEGACY Arnd Bergmann
2026-05-20 18:38 ` [PATCH 04/10] [v2] sh: select legacy gpiolib interface Arnd Bergmann
2026-05-21  6:49   ` John Paul Adrian Glaubitz
2026-05-20 18:38 ` [PATCH 05/10] [v2] mips: select legacy gpiolib interfaces where used Arnd Bergmann
2026-05-30  0:45   ` sashiko-bot
2026-06-15 10:33   ` Thomas Bogendoerfer
2026-05-20 18:38 ` [PATCH 06/10] [v4] leds: gpio: make legacy gpiolib interface optional Arnd Bergmann
2026-05-20 18:38 ` [PATCH 07/10] [v6 net-next] dt-bindings: net: add st,stlc4560/p54spi binding Arnd Bergmann
2026-05-21  9:04   ` Bartosz Golaszewski
2026-05-20 18:38 ` [PATCH 08/10] [v6 net-next] p54spi: convert to devicetree Arnd Bergmann
2026-05-30  0:45   ` sashiko-bot
2026-05-20 18:38 ` [PATCH 09/10] [v6 omap] ARM: dts: omap2: add stlc4560 spi-wireless node Arnd Bergmann
2026-05-20 21:39   ` Johannes Berg
2026-05-20 21:46   ` Andreas Kemnade
2026-05-20 18:38 ` [PATCH 10/10] gpiolib: turn off legacy interface by default Arnd Bergmann
2026-05-30  0:45   ` sashiko-bot
2026-06-09 22:25 ` (subset) [PATCH v2 00/10] gpiolib: fence off legacy interfaces Kevin Hilman

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=akyF3Log1X8_FGIB@google.com \
    --to=dmitry.torokhov@gmail.com \
    --cc=arnd@kernel.org \
    --cc=brgl@kernel.org \
    --cc=hansg@kernel.org \
    --cc=linux-input@vger.kernel.org \
    --cc=sashiko-reviews@lists.linux.dev \
    --cc=yao.jin@linux.intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox