Re: [PATCH v2 2/2] ARM: dts: gpio-ranges property is now required

[Florian Fainelli <f.fainelli@gmail.com>]

On 12/15/21 1:02 AM, nicolas saenz julienne wrote:
> Florian,
> 
> On Tue, 2021-12-14 at 09:12 -0800, Florian Fainelli wrote:
>> On 12/14/21 6:32 AM, Phil Elwell wrote:
>>> Hi Marek,
>>>
>>> On 14/12/2021 14:21, Marek Szyprowski wrote:
>>>> Hi Phil,
>>>>
>>>> On 06.12.2021 10:22, Phil Elwell wrote:
>>>>> Since [1], added in 5.7, the absence of a gpio-ranges property has
>>>>> prevented GPIOs from being restored to inputs when released.
>>>>> Add those properties for BCM283x and BCM2711 devices.
>>>>>
>>>>> [1] commit 2ab73c6d8323 ("gpio: Support GPIO controllers without
>>>>>       pin-ranges")
>>>>>
>>>>> Fixes: 2ab73c6d8323 ("gpio: Support GPIO controllers without
>>>>> pin-ranges")
>>>>> Signed-off-by: Phil Elwell <phil@raspberrypi.com>
>>>>
>>>> This patch breaks today's linux-next (next-20211214) on RPi3 and RPi4.
>>>> Either there is something missing or wrong here. Booting stops after
>>>> following messages (on RPi4):
>>>>
>>>> [    3.186786] pinctrl-bcm2835 fe200000.gpio: could not add GPIO chip
>>>> [    3.234513] pinctrl-bcm2835 fe200000.gpio: could not add GPIO chip
>>>> [    3.276703] mmc0: SDHCI controller on fe340000.mmc [fe340000.mmc]
>>>> using ADMA
>>>> [    3.287191] pinctrl-bcm2835 fe200000.gpio
>>>
>>> This patch is part of a two-patch set, the cover note for which says:
>>>
>>>     2. Since [1], a "gpio-ranges" property is required in order for pins
>>>     to be returned to inputs when freed. Note that without patch 1, the
>>>     device never gets out of EPROBE_DEFER.
>>>
>>> It looks as though patch 2 has been merged without/before patch 1
>>> ("pinctrl: bcm2835: Change init order for gpio hogs").
>>
>> Yes, the hope was that there would be no such breakage, I suppose we
>> will have to work out a plan to address that and coordinate both changes
>> landing in at the same time.
>>
>> I will work with Arnd to back out the Device Tree changes, sorry about that.
> 
> This is linux-next, so I can back out the DT change myself. Sorry for the
> breakage.
> 
> As for channeling the path, would it make sense for linusw to take it alonside
> GPIO fix?

That would definitively work, Linus, are you comfortable with doing
that? I will reply to the patch with an Acked-by if that helps.
-- 
Florian