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]
Message-ID: <6abd9dd3-e14b-f690-f967-15fb58dffae8@denx.de>
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 ?

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ