Re: [PATCH] platform/x86: barco-p50-gpio: use software nodes for gpio-leds/keys

Dmitry Torokhov
2025-08-11T16:11:48Z

On Mon, Aug 11, 2025 at 07:01:00PM +0300, Andy Shevchenko wrote:
> On Mon, Aug 11, 2025 at 08:49:21AM -0700, Dmitry Torokhov wrote:
> > On Mon, Aug 11, 2025 at 06:45:23PM +0300, Andy Shevchenko wrote:
> > > On Mon, Aug 11, 2025 at 04:20:33PM +0200, Hans de Goede wrote:
> > > > On 11-Aug-25 2:44 PM, Andy Shevchenko wrote:
> > > > > On Sun, Aug 10, 2025 at 09:31:37PM -0700, Dmitry Torokhov wrote:
>
> ...
>
> > > > > Otherwise LGTM as here it looks like we establish platform device ourselves and
> > > > > hence no need some additional magic Hans mentioned in the other series.
> > > >
> > > > Not entirely like with the x86-android-tablets patches this
> > > > declares a software-node for the gpiochip:
> > > >
> > > > static const struct software_node gpiochip_node = {
> > > > .name = DRIVER_NAME,
> > > > };
> > > >
> > > > and registers that node, but nowhere does it actually
> > > > get assigned to the gpiochip.
> > > >
> > > > This is going to need a line like this added to probe():
> > > >
> > > > p50->gc.fwnode = software_node_fwnode(&gpiochip_node);
> > > >
> > > > note the software_node_fwnode() call MUST be made after
> > > > registering the software-nodes (group).
> > > >
> > > > Other then needing this single line things are indeed
> > > > much easier when the code containing the software
> > > > properties / nodes is the same code as which is
> > > > registering the gpiochip.
> > >
> > > Ah, good point!
> >
> > This is wrong though, the software node need not be attached to the
> > gpiochip (and I wonder if it is even safe to do so). It simply provides
> > a name by which gpiochip is looked up in swnode_get_gpio_device().
>
> Do we have all this being documented somewhere? Perhaps start with that?1

This is original commit introducing the functionality:

commit e7f9ff5dc90c3826231343439c35c6b7e9e57378
Author: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Date: Fri Nov 11 14:19:08 2022 -0800

gpiolib: add support for software nodes

Now that static device properties understand notion of child nodes and
references, let's teach gpiolib to handle them:

- GPIOs are represented as a references to software nodes representing
gpiochip
- references must have 2 arguments - GPIO number within the chip and
GPIO flags (GPIO_ACTIVE_LOW/GPIO_ACTIVE_HIGH, etc)
- a new PROPERTY_ENTRY_GPIO() macro is supplied to ensure the above
- name of the software node representing gpiochip must match label of
the gpiochip, as we use it to locate gpiochip structure at runtime
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

The following illustrates use of software nodes to describe a "System"
button that is currently specified via use of gpio_keys_platform_data
in arch/mips/alchemy/board-mtx1.c. It follows bindings specified in
Documentation/devicetree/bindings/input/gpio-keys.yaml.

static const struct software_node mxt1_gpiochip2_node = {
.name = "alchemy-gpio2",
};

static const struct property_entry mtx1_gpio_button_props[] = {
PROPERTY_ENTRY_U32("linux,code", BTN_0),
PROPERTY_ENTRY_STRING("label", "System button"),
PROPERTY_ENTRY_GPIO("gpios", &mxt1_gpiochip2_node, 7, GPIO_ACTIVE_LOW),
{ }
};

Similarly, arch/arm/mach-tegra/board-paz00.c can be converted to:

static const struct software_node tegra_gpiochip_node = {
.name = "tegra-gpio",
};

static struct property_entry wifi_rfkill_prop[] __initdata = {
PROPERTY_ENTRY_STRING("name", "wifi_rfkill"),
PROPERTY_ENTRY_STRING("type", "wlan"),
PROPERTY_ENTRY_GPIO("reset-gpios",
&tegra_gpiochip_node, 25, GPIO_ACTIVE_HIGH);
PROPERTY_ENTRY_GPIO("shutdown-gpios",
&tegra_gpiochip_node, 85, GPIO_ACTIVE_HIGH);
{ },
};

static struct platform_device wifi_rfkill_device = {
.name = "rfkill_gpio",
.id = -1,
};

...

software_node_register(&tegra_gpiochip_node);
device_create_managed_software_node(&wifi_rfkill_device.dev,
wifi_rfkill_prop, NULL);

I guess we could extract this into somewhere like
Documentation/driver-api/gpio/legacy-boards.rst, but given that after
initial set of conversions we should not be seeing any more users I
wonder if it is worth it.

Thanks.

--
Dmitry