Re: [PATCH v4 07/10] arm64: select HAVE_SHARED_GPIOS for ARCH_QCOM

Re: [PATCH v4 07/10] arm64: select HAVE_SHARED_GPIOS for ARCH_QCOM

[Jon Hunter]

Hi Bartosz,

On 12/11/2025 13:55, Bartosz Golaszewski wrote:
> From: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
> 
> Some qualcomm platforms use shared GPIOs. Enable support for them by
> selecting the Kconfig switch provided by GPIOLIB.
> 
> Acked-by: Linus Walleij <linus.walleij@linaro.org>
> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
> ---
>   arch/arm64/Kconfig.platforms | 1 +
>   1 file changed, 1 insertion(+)
> 
> diff --git a/arch/arm64/Kconfig.platforms b/arch/arm64/Kconfig.platforms
> index 13173795c43d4f28e2d47acc700f80a165d44671..3dbff0261f0add0516d8cb3fd0f29e277af94f20 100644
> --- a/arch/arm64/Kconfig.platforms
> +++ b/arch/arm64/Kconfig.platforms
> @@ -316,6 +316,7 @@ config ARCH_QCOM
>   	select GPIOLIB
>   	select PINCTRL
>   	select HAVE_PWRCTRL if PCI
> +	select HAVE_SHARED_GPIOS
>   	help
>   	  This enables support for the ARMv8 based Qualcomm chipsets.
>   

I have noticed the following kernel warning on our Tegra platforms ...

  ERR KERN OF: /__symbols__: could not find phandle 794981747

Bisect is pointing to this commit and reverting this does prevent it. I 
am not sure if anyone else has seen this?

Jon
-- 
nvpublic

Re: [PATCH v4 07/10] arm64: select HAVE_SHARED_GPIOS for ARCH_QCOM

[Bartosz Golaszewski]

On Wed, Nov 26, 2025 at 3:24 PM Jon Hunter <jonathanh@nvidia.com> wrote:
>
> Hi Bartosz,
>
> On 12/11/2025 13:55, Bartosz Golaszewski wrote:
> > From: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
> >
> > Some qualcomm platforms use shared GPIOs. Enable support for them by
> > selecting the Kconfig switch provided by GPIOLIB.
> >
> > Acked-by: Linus Walleij <linus.walleij@linaro.org>
> > Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
> > ---
> >   arch/arm64/Kconfig.platforms | 1 +
> >   1 file changed, 1 insertion(+)
> >
> > diff --git a/arch/arm64/Kconfig.platforms b/arch/arm64/Kconfig.platforms
> > index 13173795c43d4f28e2d47acc700f80a165d44671..3dbff0261f0add0516d8cb3fd0f29e277af94f20 100644
> > --- a/arch/arm64/Kconfig.platforms
> > +++ b/arch/arm64/Kconfig.platforms
> > @@ -316,6 +316,7 @@ config ARCH_QCOM
> >       select GPIOLIB
> >       select PINCTRL
> >       select HAVE_PWRCTRL if PCI
> > +     select HAVE_SHARED_GPIOS
> >       help
> >         This enables support for the ARMv8 based Qualcomm chipsets.
> >
>
> I have noticed the following kernel warning on our Tegra platforms ...
>
>   ERR KERN OF: /__symbols__: could not find phandle 794981747
>
> Bisect is pointing to this commit and reverting this does prevent it. I
> am not sure if anyone else has seen this?
>

I assume it comes from drivers/of/base.c:1295 - could you please post
a stack trace of how you're getting there?

Bart

Re: [PATCH v4 07/10] arm64: select HAVE_SHARED_GPIOS for ARCH_QCOM

[Jon Hunter]

On 26/11/2025 14:28, Bartosz Golaszewski wrote:
> On Wed, Nov 26, 2025 at 3:24 PM Jon Hunter <jonathanh@nvidia.com> wrote:
>>
>> Hi Bartosz,
>>
>> On 12/11/2025 13:55, Bartosz Golaszewski wrote:
>>> From: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
>>>
>>> Some qualcomm platforms use shared GPIOs. Enable support for them by
>>> selecting the Kconfig switch provided by GPIOLIB.
>>>
>>> Acked-by: Linus Walleij <linus.walleij@linaro.org>
>>> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
>>> ---
>>>    arch/arm64/Kconfig.platforms | 1 +
>>>    1 file changed, 1 insertion(+)
>>>
>>> diff --git a/arch/arm64/Kconfig.platforms b/arch/arm64/Kconfig.platforms
>>> index 13173795c43d4f28e2d47acc700f80a165d44671..3dbff0261f0add0516d8cb3fd0f29e277af94f20 100644
>>> --- a/arch/arm64/Kconfig.platforms
>>> +++ b/arch/arm64/Kconfig.platforms
>>> @@ -316,6 +316,7 @@ config ARCH_QCOM
>>>        select GPIOLIB
>>>        select PINCTRL
>>>        select HAVE_PWRCTRL if PCI
>>> +     select HAVE_SHARED_GPIOS
>>>        help
>>>          This enables support for the ARMv8 based Qualcomm chipsets.
>>>
>>
>> I have noticed the following kernel warning on our Tegra platforms ...
>>
>>    ERR KERN OF: /__symbols__: could not find phandle 794981747
>>
>> Bisect is pointing to this commit and reverting this does prevent it. I
>> am not sure if anyone else has seen this?
>>
> 
> I assume it comes from drivers/of/base.c:1295 - could you please post
> a stack trace of how you're getting there?

Yes looks like it does and I see ...

[    0.123356] OF: /__symbols__: could not find phandle 794981747
[    0.123401] CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.18.0-rc7-next-20251126-00002-g1cd98992c487-dirty #19 PREEMPT
[    0.123418] Hardware name: NVIDIA Jetson AGX Xavier Developer Kit (DT)
[    0.123447] Call trace:
[    0.123453]  show_stack+0x18/0x24 (C)
[    0.123472]  dump_stack_lvl+0x74/0x8c
[    0.123487]  dump_stack+0x18/0x24
[    0.123518]  of_phandle_iterator_next+0x18c/0x1c4
[    0.123536]  of_count_phandle_with_args+0xa0/0xc8
[    0.123551]  gpio_shared_of_traverse+0xb8/0x47c
[    0.123566]  gpio_shared_of_traverse+0x158/0x47c
[    0.123578]  gpio_shared_init+0x110/0x1f0
[    0.123595]  do_one_initcall+0x7c/0x1c0
[    0.123607]  kernel_init_freeable+0x204/0x2e0
[    0.123622]  kernel_init+0x20/0x1d8
[    0.123637]  ret_from_fork+0x10/0x20

Thanks
Jon

-- 
nvpublic

Re: [PATCH v4 07/10] arm64: select HAVE_SHARED_GPIOS for ARCH_QCOM

[Bartosz Golaszewski]

On Wed, Nov 26, 2025 at 3:51 PM Jon Hunter <jonathanh@nvidia.com> wrote:
>
>
> On 26/11/2025 14:28, Bartosz Golaszewski wrote:
> > On Wed, Nov 26, 2025 at 3:24 PM Jon Hunter <jonathanh@nvidia.com> wrote:
> >>
> >> Hi Bartosz,
> >>
> >> On 12/11/2025 13:55, Bartosz Golaszewski wrote:
> >>> From: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
> >>>
> >>> Some qualcomm platforms use shared GPIOs. Enable support for them by
> >>> selecting the Kconfig switch provided by GPIOLIB.
> >>>
> >>> Acked-by: Linus Walleij <linus.walleij@linaro.org>
> >>> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
> >>> ---
> >>>    arch/arm64/Kconfig.platforms | 1 +
> >>>    1 file changed, 1 insertion(+)
> >>>
> >>> diff --git a/arch/arm64/Kconfig.platforms b/arch/arm64/Kconfig.platforms
> >>> index 13173795c43d4f28e2d47acc700f80a165d44671..3dbff0261f0add0516d8cb3fd0f29e277af94f20 100644
> >>> --- a/arch/arm64/Kconfig.platforms
> >>> +++ b/arch/arm64/Kconfig.platforms
> >>> @@ -316,6 +316,7 @@ config ARCH_QCOM
> >>>        select GPIOLIB
> >>>        select PINCTRL
> >>>        select HAVE_PWRCTRL if PCI
> >>> +     select HAVE_SHARED_GPIOS
> >>>        help
> >>>          This enables support for the ARMv8 based Qualcomm chipsets.
> >>>
> >>
> >> I have noticed the following kernel warning on our Tegra platforms ...
> >>
> >>    ERR KERN OF: /__symbols__: could not find phandle 794981747
> >>
> >> Bisect is pointing to this commit and reverting this does prevent it. I
> >> am not sure if anyone else has seen this?
> >>
> >
> > I assume it comes from drivers/of/base.c:1295 - could you please post
> > a stack trace of how you're getting there?
>
> Yes looks like it does and I see ...
>
> [    0.123356] OF: /__symbols__: could not find phandle 794981747
> [    0.123401] CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.18.0-rc7-next-20251126-00002-g1cd98992c487-dirty #19 PREEMPT
> [    0.123418] Hardware name: NVIDIA Jetson AGX Xavier Developer Kit (DT)
> [    0.123447] Call trace:
> [    0.123453]  show_stack+0x18/0x24 (C)
> [    0.123472]  dump_stack_lvl+0x74/0x8c
> [    0.123487]  dump_stack+0x18/0x24
> [    0.123518]  of_phandle_iterator_next+0x18c/0x1c4
> [    0.123536]  of_count_phandle_with_args+0xa0/0xc8
> [    0.123551]  gpio_shared_of_traverse+0xb8/0x47c
> [    0.123566]  gpio_shared_of_traverse+0x158/0x47c
> [    0.123578]  gpio_shared_init+0x110/0x1f0
> [    0.123595]  do_one_initcall+0x7c/0x1c0
> [    0.123607]  kernel_init_freeable+0x204/0x2e0
> [    0.123622]  kernel_init+0x20/0x1d8
> [    0.123637]  ret_from_fork+0x10/0x20
>

Is the device-tree used here upstream? Can you enable DEBUG_GPIO in
Kconfig and post the entire kernel log on pastebin?

Bartosz

Re: [PATCH v4 07/10] arm64: select HAVE_SHARED_GPIOS for ARCH_QCOM

[Jon Hunter]

On 26/11/2025 14:54, Bartosz Golaszewski wrote:
> On Wed, Nov 26, 2025 at 3:51 PM Jon Hunter <jonathanh@nvidia.com> wrote:
>>
>>
>> On 26/11/2025 14:28, Bartosz Golaszewski wrote:
>>> On Wed, Nov 26, 2025 at 3:24 PM Jon Hunter <jonathanh@nvidia.com> wrote:
>>>>
>>>> Hi Bartosz,
>>>>
>>>> On 12/11/2025 13:55, Bartosz Golaszewski wrote:
>>>>> From: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
>>>>>
>>>>> Some qualcomm platforms use shared GPIOs. Enable support for them by
>>>>> selecting the Kconfig switch provided by GPIOLIB.
>>>>>
>>>>> Acked-by: Linus Walleij <linus.walleij@linaro.org>
>>>>> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
>>>>> ---
>>>>>     arch/arm64/Kconfig.platforms | 1 +
>>>>>     1 file changed, 1 insertion(+)
>>>>>
>>>>> diff --git a/arch/arm64/Kconfig.platforms b/arch/arm64/Kconfig.platforms
>>>>> index 13173795c43d4f28e2d47acc700f80a165d44671..3dbff0261f0add0516d8cb3fd0f29e277af94f20 100644
>>>>> --- a/arch/arm64/Kconfig.platforms
>>>>> +++ b/arch/arm64/Kconfig.platforms
>>>>> @@ -316,6 +316,7 @@ config ARCH_QCOM
>>>>>         select GPIOLIB
>>>>>         select PINCTRL
>>>>>         select HAVE_PWRCTRL if PCI
>>>>> +     select HAVE_SHARED_GPIOS
>>>>>         help
>>>>>           This enables support for the ARMv8 based Qualcomm chipsets.
>>>>>
>>>>
>>>> I have noticed the following kernel warning on our Tegra platforms ...
>>>>
>>>>     ERR KERN OF: /__symbols__: could not find phandle 794981747
>>>>
>>>> Bisect is pointing to this commit and reverting this does prevent it. I
>>>> am not sure if anyone else has seen this?
>>>>
>>>
>>> I assume it comes from drivers/of/base.c:1295 - could you please post
>>> a stack trace of how you're getting there?
>>
>> Yes looks like it does and I see ...
>>
>> [    0.123356] OF: /__symbols__: could not find phandle 794981747
>> [    0.123401] CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.18.0-rc7-next-20251126-00002-g1cd98992c487-dirty #19 PREEMPT
>> [    0.123418] Hardware name: NVIDIA Jetson AGX Xavier Developer Kit (DT)
>> [    0.123447] Call trace:
>> [    0.123453]  show_stack+0x18/0x24 (C)
>> [    0.123472]  dump_stack_lvl+0x74/0x8c
>> [    0.123487]  dump_stack+0x18/0x24
>> [    0.123518]  of_phandle_iterator_next+0x18c/0x1c4
>> [    0.123536]  of_count_phandle_with_args+0xa0/0xc8
>> [    0.123551]  gpio_shared_of_traverse+0xb8/0x47c
>> [    0.123566]  gpio_shared_of_traverse+0x158/0x47c
>> [    0.123578]  gpio_shared_init+0x110/0x1f0
>> [    0.123595]  do_one_initcall+0x7c/0x1c0
>> [    0.123607]  kernel_init_freeable+0x204/0x2e0
>> [    0.123622]  kernel_init+0x20/0x1d8
>> [    0.123637]  ret_from_fork+0x10/0x20
>>
> 
> Is the device-tree used here upstream? Can you enable DEBUG_GPIO in
> Kconfig and post the entire kernel log on pastebin?

Yes this is the upstream device-tree in 
arch/arm64/boot/dts/nvidia/tegra194-p2972-0000.dts. OK I will get the 
entire log for review.

Jon

-- 
nvpublic

Re: [PATCH v4 07/10] arm64: select HAVE_SHARED_GPIOS for ARCH_QCOM

[Bartosz Golaszewski]

On Wed, 26 Nov 2025 15:55:54 +0100, Jon Hunter <jonathanh@nvidia.com> said:
>
>> Is the device-tree used here upstream? Can you enable DEBUG_GPIO in
>> Kconfig and post the entire kernel log on pastebin?
>
> Yes this is the upstream device-tree in
> arch/arm64/boot/dts/nvidia/tegra194-p2972-0000.dts. OK I will get the
> entire log for review.
>

If you could also add the following:

diff --git a/drivers/gpio/gpiolib-shared.c b/drivers/gpio/gpiolib-shared.c
index 3803b5c938f99..51af7886d9f2d 100644
--- a/drivers/gpio/gpiolib-shared.c
+++ b/drivers/gpio/gpiolib-shared.c
@@ -101,6 +101,8 @@ static int gpio_shared_of_traverse(struct device_node *curr)
 		    strcmp(prop->name, "gpio") != 0)
 			continue;

+		printk("%s: %pOF %s\n", __func__, curr, prop->name);
+
 		count = of_count_phandle_with_args(curr, prop->name,
 						   "#gpio-cells");
 		if (count <= 0)

That would help me.

Bart

Re: [PATCH v4 07/10] arm64: select HAVE_SHARED_GPIOS for ARCH_QCOM

[Jon Hunter]

On 26/11/2025 14:54, Bartosz Golaszewski wrote:
> On Wed, Nov 26, 2025 at 3:51 PM Jon Hunter <jonathanh@nvidia.com> wrote:
>>
>>
>> On 26/11/2025 14:28, Bartosz Golaszewski wrote:
>>> On Wed, Nov 26, 2025 at 3:24 PM Jon Hunter <jonathanh@nvidia.com> wrote:
>>>>
>>>> Hi Bartosz,
>>>>
>>>> On 12/11/2025 13:55, Bartosz Golaszewski wrote:
>>>>> From: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
>>>>>
>>>>> Some qualcomm platforms use shared GPIOs. Enable support for them by
>>>>> selecting the Kconfig switch provided by GPIOLIB.
>>>>>
>>>>> Acked-by: Linus Walleij <linus.walleij@linaro.org>
>>>>> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
>>>>> ---
>>>>>     arch/arm64/Kconfig.platforms | 1 +
>>>>>     1 file changed, 1 insertion(+)
>>>>>
>>>>> diff --git a/arch/arm64/Kconfig.platforms b/arch/arm64/Kconfig.platforms
>>>>> index 13173795c43d4f28e2d47acc700f80a165d44671..3dbff0261f0add0516d8cb3fd0f29e277af94f20 100644
>>>>> --- a/arch/arm64/Kconfig.platforms
>>>>> +++ b/arch/arm64/Kconfig.platforms
>>>>> @@ -316,6 +316,7 @@ config ARCH_QCOM
>>>>>         select GPIOLIB
>>>>>         select PINCTRL
>>>>>         select HAVE_PWRCTRL if PCI
>>>>> +     select HAVE_SHARED_GPIOS
>>>>>         help
>>>>>           This enables support for the ARMv8 based Qualcomm chipsets.
>>>>>
>>>>
>>>> I have noticed the following kernel warning on our Tegra platforms ...
>>>>
>>>>     ERR KERN OF: /__symbols__: could not find phandle 794981747
>>>>
>>>> Bisect is pointing to this commit and reverting this does prevent it. I
>>>> am not sure if anyone else has seen this?
>>>>
>>>
>>> I assume it comes from drivers/of/base.c:1295 - could you please post
>>> a stack trace of how you're getting there?
>>
>> Yes looks like it does and I see ...
>>
>> [    0.123356] OF: /__symbols__: could not find phandle 794981747
>> [    0.123401] CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.18.0-rc7-next-20251126-00002-g1cd98992c487-dirty #19 PREEMPT
>> [    0.123418] Hardware name: NVIDIA Jetson AGX Xavier Developer Kit (DT)
>> [    0.123447] Call trace:
>> [    0.123453]  show_stack+0x18/0x24 (C)
>> [    0.123472]  dump_stack_lvl+0x74/0x8c
>> [    0.123487]  dump_stack+0x18/0x24
>> [    0.123518]  of_phandle_iterator_next+0x18c/0x1c4
>> [    0.123536]  of_count_phandle_with_args+0xa0/0xc8
>> [    0.123551]  gpio_shared_of_traverse+0xb8/0x47c
>> [    0.123566]  gpio_shared_of_traverse+0x158/0x47c
>> [    0.123578]  gpio_shared_init+0x110/0x1f0
>> [    0.123595]  do_one_initcall+0x7c/0x1c0
>> [    0.123607]  kernel_init_freeable+0x204/0x2e0
>> [    0.123622]  kernel_init+0x20/0x1d8
>> [    0.123637]  ret_from_fork+0x10/0x20
>>
> 
> Is the device-tree used here upstream? Can you enable DEBUG_GPIO in
> Kconfig and post the entire kernel log on pastebin?

The kernel log is here: https://pastebin.com/7rBh3T3T

Thanks
Jon

-- 
nvpublic

Re: [PATCH v4 07/10] arm64: select HAVE_SHARED_GPIOS for ARCH_QCOM

[Bartosz Golaszewski]

On Wed, Nov 26, 2025 at 4:29 PM Jon Hunter <jonathanh@nvidia.com> wrote:
>
> >>
> >
> > Is the device-tree used here upstream? Can you enable DEBUG_GPIO in
> > Kconfig and post the entire kernel log on pastebin?
>
> The kernel log is here: https://pastebin.com/7rBh3T3T

This is not telling me much, can you try again with the printk() I
posted earlier, please?

Bart

Re: [PATCH v4 07/10] arm64: select HAVE_SHARED_GPIOS for ARCH_QCOM

[Jon Hunter]

On 26/11/2025 15:33, Bartosz Golaszewski wrote:
> On Wed, Nov 26, 2025 at 4:29 PM Jon Hunter <jonathanh@nvidia.com> wrote:
>>
>>>>
>>>
>>> Is the device-tree used here upstream? Can you enable DEBUG_GPIO in
>>> Kconfig and post the entire kernel log on pastebin?
>>
>> The kernel log is here: https://pastebin.com/7rBh3T3T
> 
> This is not telling me much, can you try again with the printk() I
> posted earlier, please?

Yes, sorry I missed that before kicking off the last test. With
this print I see ...

[    0.120432] gpio_shared_of_traverse: /bus@0/ethernet@2490000 phy-reset-gpios
[    0.121407] gpio_shared_of_traverse: /bus@0/mmc@3400000 cd-gpios
[    0.121891] gpio_shared_of_traverse: /bus@0/host1x@13e00000/sor@15b80000 nvidia,hpd-gpio
[    0.122035] gpio_shared_of_traverse: /bus@0/pcie-ep@141a0000 reset-gpios
[    0.122075] gpio_shared_of_traverse: /bus@0/pcie-ep@141a0000 nvidia,refclk-select-gpios
[    0.122342] gpio_shared_of_traverse: /regulator-vdd-hdmi gpio
[    0.122381] gpio_shared_of_traverse: /regulator-vdd-3v3-pcie gpio
[    0.122420] gpio_shared_of_traverse: /regulator-vdd-12v-pcie gpio
[    0.122453] gpio_shared_of_traverse: /regulator-vdd-5v0-sata gpio
[    0.122486] gpio_shared_of_traverse: /gpio-keys/key-force-recovery gpios
[    0.122551] gpio_shared_of_traverse: /gpio-keys/key-power gpios
[    0.122615] gpio_shared_of_traverse: /__symbols__ gpio
[    0.122672] OF: /__symbols__: could not find phandle 794981747
[    0.122701] CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.18.0-rc7-next-20251126-00002-g1cd98992c487-dirty #21 PREEMPT
[    0.122739] Hardware name: NVIDIA Jetson AGX Xavier Developer Kit (DT)
[    0.122747] Call trace:
[    0.122753]  show_stack+0x18/0x24 (C)
[    0.122772]  dump_stack_lvl+0x74/0x8c
[    0.122788]  dump_stack+0x18/0x24
[    0.122801]  of_phandle_iterator_next+0x18c/0x1c4
[    0.122819]  of_count_phandle_with_args+0xa0/0xc8
[    0.122832]  gpio_shared_of_traverse+0xd4/0x4c8
[    0.122848]  gpio_shared_of_traverse+0x178/0x4c8
[    0.122860]  gpio_shared_init+0x11c/0x1f8
[    0.122878]  do_one_initcall+0x7c/0x1c0
[    0.122892]  kernel_init_freeable+0x204/0x2e0
[    0.122908]  kernel_init+0x20/0x1d8
[    0.122923]  ret_from_fork+0x10/0x20
[    0.123055] gpiolib_shared: Finished scanning firmware nodes for shared GPIOs

Jon
-- 
nvpublic

Re: [PATCH v4 07/10] arm64: select HAVE_SHARED_GPIOS for ARCH_QCOM

[Bartosz Golaszewski]

On Wed, Nov 26, 2025 at 4:47 PM Jon Hunter <jonathanh@nvidia.com> wrote:
>
>
>
> On 26/11/2025 15:33, Bartosz Golaszewski wrote:
> > On Wed, Nov 26, 2025 at 4:29 PM Jon Hunter <jonathanh@nvidia.com> wrote:
> >>
> >>>>
> >>>
> >>> Is the device-tree used here upstream? Can you enable DEBUG_GPIO in
> >>> Kconfig and post the entire kernel log on pastebin?
> >>
> >> The kernel log is here: https://pastebin.com/7rBh3T3T
> >
> > This is not telling me much, can you try again with the printk() I
> > posted earlier, please?
>
> Yes, sorry I missed that before kicking off the last test. With
> this print I see ...
>
> [    0.120432] gpio_shared_of_traverse: /bus@0/ethernet@2490000 phy-reset-gpios
> [    0.121407] gpio_shared_of_traverse: /bus@0/mmc@3400000 cd-gpios
> [    0.121891] gpio_shared_of_traverse: /bus@0/host1x@13e00000/sor@15b80000 nvidia,hpd-gpio
> [    0.122035] gpio_shared_of_traverse: /bus@0/pcie-ep@141a0000 reset-gpios
> [    0.122075] gpio_shared_of_traverse: /bus@0/pcie-ep@141a0000 nvidia,refclk-select-gpios
> [    0.122342] gpio_shared_of_traverse: /regulator-vdd-hdmi gpio
> [    0.122381] gpio_shared_of_traverse: /regulator-vdd-3v3-pcie gpio
> [    0.122420] gpio_shared_of_traverse: /regulator-vdd-12v-pcie gpio
> [    0.122453] gpio_shared_of_traverse: /regulator-vdd-5v0-sata gpio
> [    0.122486] gpio_shared_of_traverse: /gpio-keys/key-force-recovery gpios
> [    0.122551] gpio_shared_of_traverse: /gpio-keys/key-power gpios
> [    0.122615] gpio_shared_of_traverse: /__symbols__ gpio

So I have no idea why the special __symbols__ node has a "gpio"
property but as this is a special case, I think we should just
explicitly ignore it.

Let me send a patch.

Bart

> [    0.122672] OF: /__symbols__: could not find phandle 794981747
> [    0.122701] CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.18.0-rc7-next-20251126-00002-g1cd98992c487-dirty #21 PREEMPT
> [    0.122739] Hardware name: NVIDIA Jetson AGX Xavier Developer Kit (DT)
> [    0.122747] Call trace:
> [    0.122753]  show_stack+0x18/0x24 (C)
> [    0.122772]  dump_stack_lvl+0x74/0x8c
> [    0.122788]  dump_stack+0x18/0x24
> [    0.122801]  of_phandle_iterator_next+0x18c/0x1c4
> [    0.122819]  of_count_phandle_with_args+0xa0/0xc8
> [    0.122832]  gpio_shared_of_traverse+0xd4/0x4c8
> [    0.122848]  gpio_shared_of_traverse+0x178/0x4c8
> [    0.122860]  gpio_shared_init+0x11c/0x1f8
> [    0.122878]  do_one_initcall+0x7c/0x1c0
> [    0.122892]  kernel_init_freeable+0x204/0x2e0
> [    0.122908]  kernel_init+0x20/0x1d8
> [    0.122923]  ret_from_fork+0x10/0x20
> [    0.123055] gpiolib_shared: Finished scanning firmware nodes for shared GPIOs
>

Re: [PATCH v4 03/10] gpiolib: implement low-level, shared GPIO support

[Jon Hunter]

Hi Bartosz,

On 12/11/2025 13:55, Bartosz Golaszewski wrote:
> From: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
> 
> This module scans the device tree (for now only OF nodes are supported
> but care is taken to make other fwnode implementations easy to
> integrate) and determines which GPIO lines are shared by multiple users.
> It stores that information in memory. When the GPIO chip exposing shared
> lines is registered, the shared GPIO descriptors it exposes are marked
> as shared and virtual "proxy" devices that mediate access to the shared
> lines are created. When a consumer of a shared GPIO looks it up, its
> fwnode lookup is redirected to a just-in-time machine lookup that points
> to this proxy device.
> 
> This code can be compiled out on platforms which don't use shared GPIOs.
> 
> Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
> Acked-by: Linus Walleij <linus.walleij@linaro.org>
> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>


I have observed a crash on one of our boards with Linux v6.19 and I was
able to reproduce the same crash on a recent -next. The crash log I see
is ...

  Unable to handle kernel paging request at virtual address f0f21322a6ad56c5
  Mem abort info:
    ESR = 0x0000000096000004
    EC = 0x25: DABT (current EL), IL = 32 bits
    SET = 0, FnV = 0
    EA = 0, S1PTW = 0
    FSC = 0x04: level 0 translation fault
  Data abort info:
    ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000
    CM = 0, WnR = 0, TnD = 0, TagAccess = 0
    GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0
  [f0f21322a6ad56c5] address between user and kernel address ranges
  Internal error: Oops: 0000000096000004 [#1]  SMP
  Modules linked in:
  CPU: 9 UID: 0 PID: 95 Comm: kworker/u51:4 Not tainted 7.0.0-rc3-next-20260309-00004-g34a79c0d58ea-dirty #13 PREEMPT
  Hardware name: NVIDIA NVIDIA Jetson AGX Orin Developer Kit/Jetson, BIOS buildbrain-gcid-42974706 11/20/2025
  Workqueue: events_unbound deferred_probe_work_func
  pstate: 20400009 (nzCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
  pc : __srcu_read_lock+0x18/0x84
  lr : gpiod_request_commit+0x30/0x174
  sp : ffff8000843fb8d0
  x29: ffff8000843fb8d0 x28: ffff800081e12000 x27: 0000000000000200
  x26: 00000000000000b9 x25: ffff000080ad92d8 x24: ffff000085cdd940
  x23: ffff800081e12cc0 x22: f0f21322a6ad56c5 x21: ffff800082df0528
  x20: f0f21322a6ad5295 x19: f0f21322a6ad56c5 x18: 00000000ffffffff
  x17: ffff000080c04d80 x16: 1fffe000101809a1 x15: ffff8000843fb530
  x14: ffff000080b17192 x13: ffff000080b1718e x12: ffff0007a1e468b8
  x11: ffff80008199ccf0 x10: 0000000000000000 x9 : 0000000000000000
  x8 : 1fffe0001014ec41 x7 : 0000000000000fff x6 : 0000000000000fff
  x5 : ffff800082df0538 x4 : ffff000081011410 x3 : ffff0000825b82b0
  x2 : ffff0000816daf40 x1 : ffff800081e12cc0 x0 : f0f21322a6ad56c5
  Call trace:
   __srcu_read_lock+0x18/0x84 (P)
   gpiod_request_commit+0x30/0x174
   gpio_device_setup_shared+0x144/0x254
   gpiochip_add_data_with_key+0xc38/0xeec
   devm_gpiochip_add_data_with_key+0x30/0x7c
   tegra186_gpio_probe+0x5cc/0x844
   platform_probe+0x5c/0x98
   really_probe+0xbc/0x2a8
   __driver_probe_device+0x78/0x12c
   driver_probe_device+0x3c/0x15c
   __device_attach_driver+0xb8/0x134
   bus_for_each_drv+0x84/0xe0
   __device_attach+0x9c/0x188
   device_initial_probe+0x50/0x54
   bus_probe_device+0x38/0xa4
   deferred_probe_work_func+0x88/0xc0
   process_one_work+0x154/0x294
   worker_thread+0x184/0x304
   kthread+0x118/0x124
   ret_from_fork+0x10/0x20
  Code: d5384102 910003fd a90153f3 aa0003f3 (f9400014)
  ---[ end trace 0000000000000000 ]---


On Tegra234, the main gpio controller has a total of 164 GPIOs (see
the tegra234_main_ports in drivers/gpio/gpio-tegra186.c). The GPIOs
are assigned a index by the kernel from 0-163, but these GPIOs are
not contiguous with respect to the device-tree specifier.

For example, in device-tree, if I have a shared-gpio with the
following specifier ...

  gpios = <&gpio TEGRA234_MAIN_GPIO(AF, 1) GPIO_ACTIVE_LOW>;

The macro TEGRA234_MAIN_GPIO(AF, 1) evaluates to (23 * 8) + 1 = 185.
This is greater than 164 and this is causing the above crash because
'entry->offset' in gpio_device_setup_shared() is greater than
'gdev->ngpio' and this causes us to access invalid memory.

This is what I have been able to determine so far and wanted to get
your inputs.

Thanks
Jon

-- 
nvpublic

Re: [PATCH v4 03/10] gpiolib: implement low-level, shared GPIO support

[Andy Shevchenko]

On Wed, Mar 11, 2026 at 8:38 PM Jon Hunter <jonathanh@nvidia.com> wrote:
> On 12/11/2025 13:55, Bartosz Golaszewski wrote:

...

> On Tegra234, the main gpio controller has a total of 164 GPIOs (see
> the tegra234_main_ports in drivers/gpio/gpio-tegra186.c). The GPIOs
> are assigned a index by the kernel from 0-163, but these GPIOs are
> not contiguous with respect to the device-tree specifier.

If I may ask...

Why? Is it sparse because there are pads that can't be used as GPIOs?

> For example, in device-tree, if I have a shared-gpio with the
> following specifier ...
>
>   gpios = <&gpio TEGRA234_MAIN_GPIO(AF, 1) GPIO_ACTIVE_LOW>;
>
> The macro TEGRA234_MAIN_GPIO(AF, 1) evaluates to (23 * 8) + 1 = 185.

To me it sounds like a bad design of the driver for this SoC/platform.

> This is greater than 164 and this is causing the above crash because
> 'entry->offset' in gpio_device_setup_shared() is greater than
> 'gdev->ngpio' and this causes us to access invalid memory.
>
> This is what I have been able to determine so far and wanted to get
> your inputs.


-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH v4 03/10] gpiolib: implement low-level, shared GPIO support

[Jon Hunter]

On 11/03/2026 20:14, Andy Shevchenko wrote:
> On Wed, Mar 11, 2026 at 8:38 PM Jon Hunter <jonathanh@nvidia.com> wrote:
>> On 12/11/2025 13:55, Bartosz Golaszewski wrote:
> 
> ...
> 
>> On Tegra234, the main gpio controller has a total of 164 GPIOs (see
>> the tegra234_main_ports in drivers/gpio/gpio-tegra186.c). The GPIOs
>> are assigned a index by the kernel from 0-163, but these GPIOs are
>> not contiguous with respect to the device-tree specifier.
> 
> If I may ask...
> 
> Why? Is it sparse because there are pads that can't be used as GPIOs?

It is purely how the different port for the GPIO controller are 
configured in h/w ...

static const struct tegra_gpio_port tegra234_main_ports[] = {
         TEGRA234_MAIN_GPIO_PORT( A, 0, 0, 8),
         TEGRA234_MAIN_GPIO_PORT( B, 0, 3, 1),
         TEGRA234_MAIN_GPIO_PORT( C, 5, 1, 8),
         TEGRA234_MAIN_GPIO_PORT( D, 5, 2, 4),
         TEGRA234_MAIN_GPIO_PORT( E, 5, 3, 8),
         TEGRA234_MAIN_GPIO_PORT( F, 5, 4, 6),
         TEGRA234_MAIN_GPIO_PORT( G, 4, 0, 8),
         TEGRA234_MAIN_GPIO_PORT( H, 4, 1, 8),
         TEGRA234_MAIN_GPIO_PORT( I, 4, 2, 7),
         TEGRA234_MAIN_GPIO_PORT( J, 5, 0, 6),
         TEGRA234_MAIN_GPIO_PORT( K, 3, 0, 8),
         TEGRA234_MAIN_GPIO_PORT( L, 3, 1, 4),
         TEGRA234_MAIN_GPIO_PORT( M, 2, 0, 8),
         TEGRA234_MAIN_GPIO_PORT( N, 2, 1, 8),
         TEGRA234_MAIN_GPIO_PORT( P, 2, 2, 8),
         TEGRA234_MAIN_GPIO_PORT( Q, 2, 3, 8),
         TEGRA234_MAIN_GPIO_PORT( R, 2, 4, 6),
         TEGRA234_MAIN_GPIO_PORT( X, 1, 0, 8),
         TEGRA234_MAIN_GPIO_PORT( Y, 1, 1, 8),
         TEGRA234_MAIN_GPIO_PORT( Z, 1, 2, 8),
         TEGRA234_MAIN_GPIO_PORT(AC, 0, 1, 8),
         TEGRA234_MAIN_GPIO_PORT(AD, 0, 2, 4),
         TEGRA234_MAIN_GPIO_PORT(AE, 3, 3, 2),
         TEGRA234_MAIN_GPIO_PORT(AF, 3, 4, 4),
         TEGRA234_MAIN_GPIO_PORT(AG, 3, 2, 8),
};

Each port can have upto 8 pins, but some don't. Note the last number in 
the column indicates the number of pins for a port.

>> For example, in device-tree, if I have a shared-gpio with the
>> following specifier ...
>>
>>    gpios = <&gpio TEGRA234_MAIN_GPIO(AF, 1) GPIO_ACTIVE_LOW>;
>>
>> The macro TEGRA234_MAIN_GPIO(AF, 1) evaluates to (23 * 8) + 1 = 185.
> 
> To me it sounds like a bad design of the driver for this SoC/platform.

I am not sure why you think that. Assuming a 1:1 mapping of the kernel's 
GPIO index to the GPIO controller + h/w port + 1 GPIO number seems fragile.

Jon

-- 
nvpublic

Re: [PATCH v4 03/10] gpiolib: implement low-level, shared GPIO support

[Chen-Yu Tsai]

On Thu, Mar 12, 2026 at 3:29 PM Jon Hunter <jonathanh@nvidia.com> wrote:
>
>
> On 11/03/2026 20:14, Andy Shevchenko wrote:
> > On Wed, Mar 11, 2026 at 8:38 PM Jon Hunter <jonathanh@nvidia.com> wrote:
> >> On 12/11/2025 13:55, Bartosz Golaszewski wrote:
> >
> > ...
> >
> >> On Tegra234, the main gpio controller has a total of 164 GPIOs (see
> >> the tegra234_main_ports in drivers/gpio/gpio-tegra186.c). The GPIOs
> >> are assigned a index by the kernel from 0-163, but these GPIOs are
> >> not contiguous with respect to the device-tree specifier.
> >
> > If I may ask...
> >
> > Why? Is it sparse because there are pads that can't be used as GPIOs?
>
> It is purely how the different port for the GPIO controller are
> configured in h/w ...
>
> static const struct tegra_gpio_port tegra234_main_ports[] = {
>          TEGRA234_MAIN_GPIO_PORT( A, 0, 0, 8),
>          TEGRA234_MAIN_GPIO_PORT( B, 0, 3, 1),
>          TEGRA234_MAIN_GPIO_PORT( C, 5, 1, 8),
>          TEGRA234_MAIN_GPIO_PORT( D, 5, 2, 4),
>          TEGRA234_MAIN_GPIO_PORT( E, 5, 3, 8),
>          TEGRA234_MAIN_GPIO_PORT( F, 5, 4, 6),
>          TEGRA234_MAIN_GPIO_PORT( G, 4, 0, 8),
>          TEGRA234_MAIN_GPIO_PORT( H, 4, 1, 8),
>          TEGRA234_MAIN_GPIO_PORT( I, 4, 2, 7),
>          TEGRA234_MAIN_GPIO_PORT( J, 5, 0, 6),
>          TEGRA234_MAIN_GPIO_PORT( K, 3, 0, 8),
>          TEGRA234_MAIN_GPIO_PORT( L, 3, 1, 4),
>          TEGRA234_MAIN_GPIO_PORT( M, 2, 0, 8),
>          TEGRA234_MAIN_GPIO_PORT( N, 2, 1, 8),
>          TEGRA234_MAIN_GPIO_PORT( P, 2, 2, 8),
>          TEGRA234_MAIN_GPIO_PORT( Q, 2, 3, 8),
>          TEGRA234_MAIN_GPIO_PORT( R, 2, 4, 6),
>          TEGRA234_MAIN_GPIO_PORT( X, 1, 0, 8),
>          TEGRA234_MAIN_GPIO_PORT( Y, 1, 1, 8),
>          TEGRA234_MAIN_GPIO_PORT( Z, 1, 2, 8),
>          TEGRA234_MAIN_GPIO_PORT(AC, 0, 1, 8),
>          TEGRA234_MAIN_GPIO_PORT(AD, 0, 2, 4),
>          TEGRA234_MAIN_GPIO_PORT(AE, 3, 3, 2),
>          TEGRA234_MAIN_GPIO_PORT(AF, 3, 4, 4),
>          TEGRA234_MAIN_GPIO_PORT(AG, 3, 2, 8),
> };
>
> Each port can have upto 8 pins, but some don't. Note the last number in
> the column indicates the number of pins for a port.
>
> >> For example, in device-tree, if I have a shared-gpio with the
> >> following specifier ...
> >>
> >>    gpios = <&gpio TEGRA234_MAIN_GPIO(AF, 1) GPIO_ACTIVE_LOW>;
> >>
> >> The macro TEGRA234_MAIN_GPIO(AF, 1) evaluates to (23 * 8) + 1 = 185.
> >
> > To me it sounds like a bad design of the driver for this SoC/platform.
>
> I am not sure why you think that. Assuming a 1:1 mapping of the kernel's
> GPIO index to the GPIO controller + h/w port + 1 GPIO number seems fragile.

If the hardware has uneven number of actual pins for each bank, either
you end up using the deprecated static GPIO number allocation and
have holes in the GPIO range (sunxi currently does this), or you use
dynamic allocation, which gives you no holes in the GPIO range, but
not directly calculable mapping between DT and GPIO numbers.

The driver handles the mapping by providing an .xlate callback. A
consumer shouldn't assume anything. The shared GPIO library probably
shouldn't be try parsing the property itself and use the result to
grab the GPIO descriptor, but just rely on the gpiochip's .xlate
callback in some way.


ChenYu

Re: [PATCH v4 03/10] gpiolib: implement low-level, shared GPIO support

[Jon Hunter]

On 12/03/2026 07:49, Chen-Yu Tsai wrote:

...

>>> To me it sounds like a bad design of the driver for this SoC/platform.
>>
>> I am not sure why you think that. Assuming a 1:1 mapping of the kernel's
>> GPIO index to the GPIO controller + h/w port + 1 GPIO number seems fragile.
> 
> If the hardware has uneven number of actual pins for each bank, either
> you end up using the deprecated static GPIO number allocation and
> have holes in the GPIO range (sunxi currently does this), or you use
> dynamic allocation, which gives you no holes in the GPIO range, but
> not directly calculable mapping between DT and GPIO numbers.
> 
> The driver handles the mapping by providing an .xlate callback. A
> consumer shouldn't assume anything. The shared GPIO library probably
> shouldn't be try parsing the property itself and use the result to
> grab the GPIO descriptor, but just rely on the gpiochip's .xlate
> callback in some way.

Right. I was thinking that isn't this why we have the xlate callbacks in 
the first place to handle such things and not make these assumptions?

I am curious if other platforms could have the same issue? I did not see 
this immediately with v6.19 because it is only one specific platform  we 
have that showed this. So very much a corner case that will only be seen 
if a platform uses shared GPIOs and the shared GPIO happens to be high 
enough to overflow the descriptor array. Even if we don't crash, at 
least for Tegra, we could be using the wrong descriptor too for shared 
GPIOs.

Jon

-- 
nvpublic

Re: [PATCH v4 03/10] gpiolib: implement low-level, shared GPIO support

[Andy Shevchenko]

On Thu, Mar 12, 2026 at 08:41:03AM +0000, Jon Hunter wrote:
> On 12/03/2026 07:49, Chen-Yu Tsai wrote:

...

> > > > To me it sounds like a bad design of the driver for this SoC/platform.
> > > 
> > > I am not sure why you think that. Assuming a 1:1 mapping of the kernel's
> > > GPIO index to the GPIO controller + h/w port + 1 GPIO number seems fragile.

You may use valid mask (which is also available via GPIO device properties) or
as said below. In any case this thread just convinces me even more that driver
has a design flaw.

> > If the hardware has uneven number of actual pins for each bank, either
> > you end up using the deprecated static GPIO number allocation and
> > have holes in the GPIO range (sunxi currently does this), or you use
> > dynamic allocation, which gives you no holes in the GPIO range, but
> > not directly calculable mapping between DT and GPIO numbers.
> > 
> > The driver handles the mapping by providing an .xlate callback. A
> > consumer shouldn't assume anything. The shared GPIO library probably
> > shouldn't be try parsing the property itself and use the result to
> > grab the GPIO descriptor, but just rely on the gpiochip's .xlate
> > callback in some way.
> 
> Right. I was thinking that isn't this why we have the xlate callbacks in the
> first place to handle such things and not make these assumptions?
> 
> I am curious if other platforms could have the same issue? I did not see
> this immediately with v6.19 because it is only one specific platform  we
> have that showed this. So very much a corner case that will only be seen if
> a platform uses shared GPIOs and the shared GPIO happens to be high enough
> to overflow the descriptor array. Even if we don't crash, at least for
> Tegra, we could be using the wrong descriptor too for shared GPIOs.

None of Intel platforms has this issue, for the rest I have no clue.

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH v4 03/10] gpiolib: implement low-level, shared GPIO support

[Bartosz Golaszewski]

On Thu, Mar 12, 2026 at 8:49 AM Chen-Yu Tsai <wens@kernel.org> wrote:
>
> On Thu, Mar 12, 2026 at 3:29 PM Jon Hunter <jonathanh@nvidia.com> wrote:
> >
> >
> > On 11/03/2026 20:14, Andy Shevchenko wrote:
> > > On Wed, Mar 11, 2026 at 8:38 PM Jon Hunter <jonathanh@nvidia.com> wrote:
> > >> On 12/11/2025 13:55, Bartosz Golaszewski wrote:
> > >
> > > ...
> > >
> > >> On Tegra234, the main gpio controller has a total of 164 GPIOs (see
> > >> the tegra234_main_ports in drivers/gpio/gpio-tegra186.c). The GPIOs
> > >> are assigned a index by the kernel from 0-163, but these GPIOs are
> > >> not contiguous with respect to the device-tree specifier.
> > >
> > > If I may ask...
> > >
> > > Why? Is it sparse because there are pads that can't be used as GPIOs?
> >
> > It is purely how the different port for the GPIO controller are
> > configured in h/w ...
> >
> > static const struct tegra_gpio_port tegra234_main_ports[] = {
> >          TEGRA234_MAIN_GPIO_PORT( A, 0, 0, 8),
> >          TEGRA234_MAIN_GPIO_PORT( B, 0, 3, 1),
> >          TEGRA234_MAIN_GPIO_PORT( C, 5, 1, 8),
> >          TEGRA234_MAIN_GPIO_PORT( D, 5, 2, 4),
> >          TEGRA234_MAIN_GPIO_PORT( E, 5, 3, 8),
> >          TEGRA234_MAIN_GPIO_PORT( F, 5, 4, 6),
> >          TEGRA234_MAIN_GPIO_PORT( G, 4, 0, 8),
> >          TEGRA234_MAIN_GPIO_PORT( H, 4, 1, 8),
> >          TEGRA234_MAIN_GPIO_PORT( I, 4, 2, 7),
> >          TEGRA234_MAIN_GPIO_PORT( J, 5, 0, 6),
> >          TEGRA234_MAIN_GPIO_PORT( K, 3, 0, 8),
> >          TEGRA234_MAIN_GPIO_PORT( L, 3, 1, 4),
> >          TEGRA234_MAIN_GPIO_PORT( M, 2, 0, 8),
> >          TEGRA234_MAIN_GPIO_PORT( N, 2, 1, 8),
> >          TEGRA234_MAIN_GPIO_PORT( P, 2, 2, 8),
> >          TEGRA234_MAIN_GPIO_PORT( Q, 2, 3, 8),
> >          TEGRA234_MAIN_GPIO_PORT( R, 2, 4, 6),
> >          TEGRA234_MAIN_GPIO_PORT( X, 1, 0, 8),
> >          TEGRA234_MAIN_GPIO_PORT( Y, 1, 1, 8),
> >          TEGRA234_MAIN_GPIO_PORT( Z, 1, 2, 8),
> >          TEGRA234_MAIN_GPIO_PORT(AC, 0, 1, 8),
> >          TEGRA234_MAIN_GPIO_PORT(AD, 0, 2, 4),
> >          TEGRA234_MAIN_GPIO_PORT(AE, 3, 3, 2),
> >          TEGRA234_MAIN_GPIO_PORT(AF, 3, 4, 4),
> >          TEGRA234_MAIN_GPIO_PORT(AG, 3, 2, 8),
> > };
> >
> > Each port can have upto 8 pins, but some don't. Note the last number in
> > the column indicates the number of pins for a port.
> >
> > >> For example, in device-tree, if I have a shared-gpio with the
> > >> following specifier ...
> > >>
> > >>    gpios = <&gpio TEGRA234_MAIN_GPIO(AF, 1) GPIO_ACTIVE_LOW>;
> > >>
> > >> The macro TEGRA234_MAIN_GPIO(AF, 1) evaluates to (23 * 8) + 1 = 185.
> > >
> > > To me it sounds like a bad design of the driver for this SoC/platform.
> >
> > I am not sure why you think that. Assuming a 1:1 mapping of the kernel's
> > GPIO index to the GPIO controller + h/w port + 1 GPIO number seems fragile.
>
> If the hardware has uneven number of actual pins for each bank, either
> you end up using the deprecated static GPIO number allocation and
> have holes in the GPIO range (sunxi currently does this), or you use
> dynamic allocation, which gives you no holes in the GPIO range, but
> not directly calculable mapping between DT and GPIO numbers.
>
> The driver handles the mapping by providing an .xlate callback. A
> consumer shouldn't assume anything. The shared GPIO library probably
> shouldn't be try parsing the property itself and use the result to
> grab the GPIO descriptor, but just rely on the gpiochip's .xlate
> callback in some way.
>

Yes, it's a bug. I will fix it. Thanks for the report Jon.

Bart