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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <tigj3afybwwqj5n4etir6xil7njo6q6q36abfqk46oku6fgfyg@36cg54q5sbtn>
Date: Mon, 11 Aug 2025 09:11:44 -0700
From: Dmitry Torokhov <dmitry.torokhov@...il.com>
To: Andy Shevchenko <andriy.shevchenko@...ux.intel.com>
Cc: Hans de Goede <hansg@...nel.org>, 
	Santosh Kumar Yadav <santoshkumar.yadav@...co.com>, Peter Korsgaard <peter.korsgaard@...co.com>, 
	Bartosz Golaszewski <bartosz.golaszewski@...aro.org>, Ilpo Järvinen <ilpo.jarvinen@...ux.intel.com>, 
	Arnd Bergmann <arnd@...db.de>, platform-driver-x86@...r.kernel.org, 
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] platform/x86: barco-p50-gpio: use software nodes for
 gpio-leds/keys

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@...il.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