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@xxxxxxxxxxxxxxx>
>>
>> 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.
--
Florian
