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