linux-kernel - Re: [BUG] pinctrl: reg-fixed-voltage usb0-vbus: error -EINVAL: can't get GPIO

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: <2f82dbe8-50d6-d905-9065-d3869948aa06@xs4all.nl>
Date:   Tue, 18 Jan 2022 15:13:20 +0100
From:   Hans Verkuil <hverkuil-cisco@...all.nl>
To:     Corentin Labbe <clabbe.montjoie@...il.com>,
        linus.walleij@...aro.org, mripard@...nel.org, wens@...e.org,
        jernej.skrabec@...il.com
Cc:     linux-gpio@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
        linux-sunxi@...ts.linux.dev, linux-kernel@...r.kernel.org,
        zhangn1985@...il.com
Subject: Re: [BUG] pinctrl: reg-fixed-voltage usb0-vbus: error -EINVAL: can't
 get GPIO

On 1/18/22 13:50, Corentin Labbe wrote:
> Hello
> 
> As reported on old googlegroup sunxi mainling list, on linux-next-20220118, USB storage fail to bring up on orangepiPC.
> We can see some error logs in dmesg:
> reg-fixed-voltage usb0-vbus: error -EINVAL: can't get GPIO
> reg-fixed-voltage: probe of usb0-vbus failed with error -22
> 
> This is bisected to: 8df89a7cbc63c7598c00611ad17b67e8d5b4fad3 pinctrl-sunxi: don't call pinctrl_gpio_direction()
> 
> Reverting this commit lead to a working USB storage being setuped.

Hmm, I'll bet it's EPROBE_DEFER related.

The original call (pre that commit) of pinctrl_gpio_direction_output() checks
if the pin controller could find the pin (pinctrl_get_device_gpio_range()).

That doesn't happen in the new code.

The sunxi appears to have two pincontrollers in the device tree (&pio and &r_pio),
that might be part of the reason this is an issue here.

Linus, should there be a check somewhere for a missing pincontroller in
gpiod_get_index()? I suspect that before my commit it was the gpiod_configure_flags
call in that function that returned -EPROBE_DEFER, but I'm not completely certain.

If someone can give me a hint about what should be done, then I can make a patch.

The alternative is to revert this sunxi patch, but perhaps this is a deeper
problem with these pincontroller drivers that set the direction directly
instead of going through pinctrl_gpio_direction_output().

Corentin, it would help me if you can figure out where the EPROBE_DEFER is
returned (pre-commit) in drivers/pinctrl/core.c. Probably pinctrl_get_device_gpio_range().

And I'd love to have the WARN_ON(1) output from just before the 'return -EPROBE_DEFER'.

Regards,

	Hans

> 
> Regards