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@xxxxxxxx>
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
