Messages in this thread |  | | Date | Sat, 14 Jan 2023 12:23:49 +0100 | Subject | Re: [PATCH v2 1/2] pinctrl: bcm: bcm2835: Switch to use ->add_pin_ranges() | From | Stefan Wahren <> |
| |
Hi Andy,
Am 13.01.23 um 22:31 schrieb Andy Shevchenko: > On Fri, Jan 13, 2023 at 09:13:23PM +0100, Stefan Wahren wrote: >> Am 13.01.23 um 18:10 schrieb Andy Shevchenko: > ... > >>> v2: fixed compilation issues (LKP), Cc'ed to the author of original code >>> >>> Btw, the commit d2b67744fd99 ("pinctrl: bcm2835: implement hook for >>> missing gpio-ranges") seems problematic in the fist place due to >>> odd of_node_put() call. I dunno how that part had been tested, or >>> how it's supposed to work, i.e. where is the counterpart of_node_get(). >>> Anyway this change drops it for good. >> The countpart is in of_pinctrl_get(). I was just following the pattern like >> in other drivers like gpio-rockchip. The original commit has been tested by >> Florian Fainelli and me. I'm not sure if it's safe to drop it completely. > Please, elaborate how of_pinctrl_get() increases refcount of the parameter. > Maybe I'm looking into a wrong place? > >> Btw this is not the only platform affected by the gpio-ranges compatibility >> issue [1]. > This is the only one that uses unnecessary added callback.
i didn't have access to any of the other platforms which were also affected. So i thought providing a general solution would be good idea. I wasn't aware of add_pin_ranges().
Since i was annoyed that nobody cared about DTB backward compatibility, i send out a RFC series to fix the GPIO hog regression which breaks the LEDs on the Raspberry Pi. Nobody complained about it.
> >>> Perhaps we can check gpio-ranges property presence inside the GPIO >>> library, so this ->add_pin_ranges() won't be called at all. >> I thought this could be very platform specific, so i implemented a hook. But >> yes my initial hack modified gpiolib-of [2]. > The point is that possibly documentation of ->add_pin_ranges() should be > amended to take care of the cases like this. We don't need two or more > hooks to do the same, esp. taking into account that OF specific doesn't > cover other cases. > >> [1] - https://patchwork.kernel.org/project/linux-arm-msm/patch/20180412190138.12372-1-chunkeey@gmail.com/ >> >> [2] - https://lore.kernel.org/linux-arm-kernel/75266ed1-666a-138b-80f1-ae9a06b7bdf3@i2se.com/ >> >>> Also I would like to understand the dance around checking for pin >>> control device. The original commit lacks of comments in the non-trivial >>> code. > Any comment on this? Do you mean the NULL check? of_pinctrl_get() could return NULL, but pinctrl_dev_get_devname() directly access the dev member.
|  |