On 02.01.22 07:54, Linus Walleij wrote:
> On Wed, Dec 29, 2021 at 8:07 PM Stefan Wahren <stefan.wahren@xxxxxxxx> wrote:
>> Am 10.12.21 um 00:24 schrieb Linus Walleij:
>>> On Mon, Dec 6, 2021 at 10:22 AM Phil Elwell <phil@xxxxxxxxxxxxxxx> wrote:
>>>
>>>> ...and gpio-ranges
>>>>
>>>> pinctrl-bcm2835 is a combined pinctrl/gpio driver. Currently the gpio
>>>> side is registered first, but this breaks gpio hogs (which are
>>>> configured during gpiochip_add_data). Part of the hog initialisation
>>>> is a call to pinctrl_gpio_request, and since the pinctrl driver hasn't
>>>> yet been registered this results in an -EPROBE_DEFER from which it can
>>>> never recover.
>>>>
>>>> Change the initialisation sequence to register the pinctrl driver
>>>> first.
>>>>
>>>> This also solves a similar problem with the gpio-ranges property, which
>>>> is required in order for released pins to be returned to inputs.
>>>>
>>>> Fixes: 73345a18d464b ("pinctrl: bcm2835: Pass irqchip when adding gpiochip")
>>>> Signed-off-by: Phil Elwell <phil@xxxxxxxxxxxxxxx>
>>> This patch (1/2) applied for fixes.
>>
>> Unfortunately this change breaks all GPIO LEDs at least on the Raspberry
>> Pi 3 Plus (Linux 5.16-rc7, multi_v7_defconfig). The ACT LED for instance
>> stays in the last state instead of the configured heartbeat behavior.
>> Also there are no GPIO LEDs in /sys/class/leds/ directory.
>>
>> After reverting this change everything is back to normal.
>
> Oh what a mess. OK I reverted the fix.
>
I happened to debug this regression as well: The issue of the patch
seems to be that it initializes gpio_range.base with -1, because
gpio_chip.base is not yet set at this point. Maybe that can be achieved
differently, to please all cases.
Jan
