[PATCH RFC 0/2] gpiolib: of: Introduce hook for missing gpio-ranges

[Florian Fainelli]

On 3/17/22 4:48 AM, Stefan Wahren wrote:
> Hi,
> 
> Am 17.03.22 um 03:02 schrieb Florian Fainelli:
>>
>>
>> On 3/16/2022 6:15 PM, Linus Walleij wrote:
>>> On Wed, Mar 9, 2022 at 8:44 PM Stefan Wahren <stefan.wahren at i2se.com>
>>> wrote:
>>>
>>>> This patch series tries to provide backward compatibility for DTB which
>>>> lacks the gpio-ranges property.
>>>>
>>>> The commit ("pinctrl: msm: fix gpio-hog related boot issues") by
>>>> Christian
>>>> Lamparter already contains a fallback in case the gpio-ranges property
>>>> is missing. But this approach doesn't work on BCM2835 with a gpio-hog
>>>> defined for the SoC GPIOs.
>>>>
>>>> Based Christian's on explanation i conclude that the fallback must
>>>> happen
>>>> during the gpiochip_add() call and not afterwards. So the approach
>>>> is to
>>>> call an optional hook, which can be implemented in the platform driver.
>>>>
>>>> This series has been tested on Raspberry Pi 3 B Plus.
>>>>
>>>> Stefan Wahren (2):
>>>>    gpiolib: of: Introduce hook for missing gpio-ranges
>>>>    pinctrl: bcm2835: implement hook for missing gpio-ranges
>>>
>>> Looks good to me, is this something I should apply to the pinctrl
>>> tree or should I wait for a non-RFC version?
>>
>> I would be inclined to slap a couple of different Fixes tag to each
>> commit because breaking older DTBs should IMHO be considered a
>> regression. So for the first patch I would add:
>>
>> Fixes: 2ab73c6d8323 ("gpio: Support GPIO controllers without pin-ranges")
>>
>> and for the second patch:
>>
>> Fixes: 266423e60ea1 ("pinctrl: bcm2835: Change init order for gpio hogs")
>>
>> WDYT?
> so you consider backporting this "feature"?

Yes, I would consider your changes fixes actually. If I am the only one
deeply concerned about backwards compatibility I suppose I could
backport those into our tree.
-- 
Florian