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

[Florian Fainelli]

On 3/17/22 12:23, Stefan Wahren wrote:
> Hi,
> 
> Am 17.03.22 um 18:17 schrieb 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.
> i'm fine with backporting, but i thought these must be single 
> independent patches.

Linus, how are we proceeding with these changes? Any hope to include 
them for 5.18?
-- 
Florian