linux-kernel - Re: [PATCH] [RFC] gpio: Retry deferred GPIO hogging on pin range change

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]

Date:	Tue, 16 Jun 2015 19:27:36 +0200
From:	Maxime Ripard <maxime.ripard@...e-electrons.com>
To:	Geert Uytterhoeven <geert+renesas@...der.be>
Cc:	Linus Walleij <linus.walleij@...aro.org>,
	Alexandre Courbot <gnurou@...il.com>,
	Benoit Parrot <bparrot@...com>,
	Boris Brezillon <boris.brezillon@...e-electrons.com>,
	linux-gpio@...r.kernel.org, linux-sh@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] [RFC] gpio: Retry deferred GPIO hogging on pin range
 change

Hi Geert,

On Tue, Jun 16, 2015 at 02:36:48PM +0200, Geert Uytterhoeven wrote:
> If a GPIO driver uses gpiochip_add_pin_range() (which is usually the
> case for GPIO/PFC combos), the GPIO hogging mechanism configured from DT
> doesn't work:
> 
>     requesting hog GPIO lcd0 (chip r8a7740_pfc, offset 176) failed
> 
> The actual error code is -517 == -EPROBE_DEFER.
> 
> The problem is that PFC+GPIO registration is handled in multiple steps:
>   1. pinctrl_register(),
>   2. gpiochip_add(),
>   3. gpiochip_add_pin_range().
> 
> Configuration of the hogs is handled in gpiochip_add():
> 
>     gpiochip_add
>         of_gpiochip_add
>             of_gpiochip_scan_hogs
>                 gpiod_hog
>                     gpiochip_request_own_desc
>                         __gpiod_request
>                             chip->request
>                                 pinctrl_request_gpio
>                                     pinctrl_get_device_gpio_range
> 
> However, at this point the GPIO controller hasn't been added to
> pinctrldev_list yet, so the range can't be found, and the operation fails
> with -EPROBE_DEFER.
> 
>   - Exchanging the order of the calls to gpiochip_add() and
>     gpiochip_add_pin_range() is not an option, as the latter depends on
>     initialization done by the former.
>   - Just moving the call of of_gpiochip_scan_hogs() from gpiochip_add()
>     to gpiochip_add_pin_range() is also not an option, as the latter is
>     optional, and thus not used by all drivers.
> 
> Hence if of_gpiochip_scan_hogs() fails with -EPROBE_DEFER, call it
> again every time the pin range is changed, until it succeeded.
> 
> Signed-off-by: Geert Uytterhoeven <geert+renesas@...der.be>
> ---
> Questions:
>   - Is there a better solution to handle this?
> 
>   - Should the pin ranges be configured by passing an array of data to
>     gpiochip_add() instead of having calls to gpiochip_add_pin_range()?
>     That would require changing all drivers.
> 
>   - What happens if you have multiple hogs in multiple ranges?
>     The first hog(s) may be configured multiple times.  Is that a problem?
> 
>   - In one of the threads that discussed the GPIO hogging mechanism, Maxime
>     Ripard said: "Our pinctrl driver is also our GPIO driver, so they both
>     share the same node."
>     Maxime: Did you try GPIO hogging? Did it work?
>     If yes, which driver are you using? What's different compared to sh-pfc?
>     If no, did you get it to work?

I'm using pinctrl-sunxi, and no, I haven't tried it yet, so it
probably have the issue you reported :)

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

Download attachment "signature.asc" of type "application/pgp-signature" (820 bytes)