linux-kernel - Re: [PATCH 5.10 081/290] gpiolib: Read "gpio-line-names" from a firmware node

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 for Android: free password hash cracker in your pocket

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

Date:   Mon, 15 Mar 2021 15:18:14 +0100
From:   Marek Vasut <marex@...x.de>
To:     gregkh@...uxfoundation.org, linux-kernel@...r.kernel.org
Cc:     stable@...r.kernel.org, Roman Guskov <rguskov@...electronics.com>,
        Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
        Bartosz Golaszewski <bgolaszewski@...libre.com>
Subject: Re: [PATCH 5.10 081/290] gpiolib: Read "gpio-line-names" from a
 firmware node

On 3/15/21 2:52 PM, gregkh@...uxfoundation.org wrote:
> From: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
> 
> From: Andy Shevchenko <andriy.shevchenko@...ux.intel.com>
> 
> commit b41ba2ec54a70908067034f139aa23d0dd2985ce upstream.
> 
> On STM32MP1, the GPIO banks are subnodes of pin-controller@...02000,
> see arch/arm/boot/dts/stm32mp151.dtsi. The driver for
> pin-controller@...02000 is in drivers/pinctrl/stm32/pinctrl-stm32.c
> and iterates over all of its DT subnodes when registering each GPIO
> bank gpiochip. Each gpiochip has:
> 
>    - gpio_chip.parent = dev,
>      where dev is the device node of the pin controller
>    - gpio_chip.of_node = np,
>      which is the OF node of the GPIO bank
> 
> Therefore, dev_fwnode(chip->parent) != of_fwnode_handle(chip.of_node),
> i.e. pin-controller@...02000 != pin-controller@...02000/gpio@...0*000.
> 
> The original code behaved correctly, as it extracted the "gpio-line-names"
> from of_fwnode_handle(chip.of_node) = pin-controller@...02000/gpio@...0*000.
> 
> To achieve the same behaviour, read property from the firmware node.

There seem to be some discussion going on around this patch, so please 
postpone backporting until that is settled. Same for v5.11 backport. I 
hope Andy/Bartosz agrees ?