Re: [PATCH] gpio: shared: call gpio_chip::of_xlate() if set

[Bartosz Golaszewski]

On Tue, 17 Mar 2026 23:46:55 +0100, Jon Hunter <jonathanh@xxxxxxxxxx> said:
>
> On 17/03/2026 15:19, Bartosz Golaszewski wrote:
>> On Tue, Mar 17, 2026 at 3:05 PM Bartosz Golaszewski <brgl@xxxxxxxxxx> wrote:
>>>
>>> On Tue, Mar 17, 2026 at 2:47 PM Jon Hunter <jonathanh@xxxxxxxxxx> wrote:
>>>>
>>>>
>>>>>> I am not sure if this is because these are child nodes of gpio-keys?
>>>>>> Obviously this is not a proper example, but something quick and dirty
>>>>>> for local testing :-)
>>>>>>
>>>>>
>>>>> Let me create a setup with GPIO keys then.
>>>>
>>>> Thanks!
>>>> Jon
>>>>
>>>
>>> I can reproduce this with a gpio-keys setup. I think you hit an
>>> interesting corner-case where the consumer device is the same for two
>>> shared pins assigned to its child fwnodes. The setup doesn't make
>>> sense really but I guess this shouldn't just fail like that.
>>>
>>
>> So the problem goes like this: we're using lookup tables for shared
>> GPIOs but they are not capable of dealing with two fwnodes that are
>> children of the same device that share the same pin but are themselves
>> not attached to a device bound to a driver. While we could extend
>> lookup tables to take that into account, I think that the setup here
>> is so hypothetical, it doesn't really make sense to spend time on it.
>
> Makes sense.
>

Just to be clear, this:

	gpio-keys {
		compatible = "gpio-keys";

		key-one {
			label = "foo";
			gpios = <&gpio_sim0 10 0>;
			linux,input-type = <EV_KEY>;
			linux,code = <KEY_POWER>;
		};

		key-two {
			label = "bar";
			gpios = <&gpio_sim0 10 0>;
			linux,input-type = <EV_KEY>;
			linux,code = <KEY_POWER>;
		};
	};

doesn't work, but this:

	gpio-keys-1 {
		compatible = "gpio-keys";

		key-one {
			label = "foo";
			gpios = <&gpio_sim0 10 0>;
			linux,input-type = <EV_KEY>;
			linux,code = <KEY_POWER>;
		};
	};

	gpio-keys-2 {
		compatible = "gpio-keys";

		key-two {
			label = "bar";
			gpios = <&gpio_sim0 10 0>;
			linux,input-type = <EV_KEY>;
			linux,code = <KEY_POWER>;
		};
	};

does. I don't think making the former work is worth the effort.

>> Does this patch fix the real problem on the tegra board that you
>> reported initially? I doubt two separate GPIO keys, share the same pin
>> in real life.
>
> Yes it fixes the initial issue. However, now I am seeing a different
> error on the actual platform that is having the issue to begin with ...
>

This is *with* the fix?

>   ------------[ cut here ]------------
>   WARNING: kernel/rcu/srcutree.c:757 at cleanup_srcu_struct+0xc0/0x1e0, CPU#2: kworker/u49:1/114
>   Modules linked in:
>   CPU: 2 UID: 0 PID: 114 Comm: kworker/u49:1 Not tainted 6.19.0-tegra #1 PREEMPT
>   Hardware name: NVIDIA NVIDIA Jetson AGX Orin Developer Kit/Jetson, BIOS buildbrain-gcid-44496888 03/15/2026
>   Workqueue: events_unbound deferred_probe_work_func
>   pstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
>   pc : cleanup_srcu_struct+0xc0/0x1e0
>   lr : cleanup_srcu_struct+0xb4/0x1e0
>   sp : ffff800081cbb930
>   x29: ffff800081cbb930 x28: ffffd79ff96d0c40 x27: ffff000086059000
>   x26: 00000000fffffff0 x25: ffff000086571200 x24: ffffd79ff94adb10
>   x23: ffffd79ff86400c0 x22: ffff000086059390 x21: ffffd79ff94aa040
>   x20: 0000000000000000 x19: fffffdffbf669d40 x18: 00000000ffffffff
>   x17: 0000000000000000 x16: ffffd79ff62dc8a0 x15: 0081cf5fe0409838
>   x14: 0000000000000000 x13: 0000000000000272 x12: 0000000000000000
>   x11: 00000000000000c0 x10: f7c5d06d757a4b3a x9 : 15ccf89dfeffb5e1
>   x8 : ffff800081cbb8c8 x7 : 0000000000000000 x6 : 000000000151e960
>   x5 : 0800000000000000 x4 : 0000000000000000 x3 : 0000000000000000
>   x2 : 0000000000000001 x1 : 0000000000000000 x0 : 0000000000000004
>   Call trace:
>    cleanup_srcu_struct+0xc0/0x1e0 (P)
>    gpiochip_add_data_with_key+0x3dc/0xf68
>    devm_gpiochip_add_data_with_key+0x30/0x84
>    tegra186_gpio_probe+0x5e4/0x808
>    platform_probe+0x5c/0xb0
>    really_probe+0xbc/0x2b4
>    __driver_probe_device+0x78/0x134
>    driver_probe_device+0x3c/0x164
>    __device_attach_driver+0xc8/0x15c
>    bus_for_each_drv+0x88/0x100
>    __device_attach+0xa0/0x198
>    device_initial_probe+0x58/0x5c
>    bus_probe_device+0x38/0xbc
>    deferred_probe_work_func+0x88/0xc8
>    process_one_work+0x16c/0x3fc
>    worker_thread+0x2d8/0x3ec
>    kthread+0x144/0x22c
>    ret_from_fork+0x10/0x20
>   ---[ end trace 0000000000000000 ]---
>   gpiochip_add_data_with_key: GPIOs 512..675 (tegra234-gpio) failed to register, -16
>   tegra186-gpio 2200000.gpio: probe with driver tegra186-gpio failed with error -16
>
> Note this is on top of a Linux v6.19 kernel I was using to track down the
> original problem.
>

There's a change to how gpiochip_add_data_with_key() error path works in
linux-next at the moment but it's not in any stable branch yet.

> Looking at the above there appears to be two other issues; one the warning from
> SRCU and the other an -EBUSY failure when registering the GPIO controller. I am
> guessing the warning is triggered when gpiochip_add_data_with_key fails. I need
> to look at this closer.
>

-EBUSY can typically only happen if gpiod_request_commit() is called twice on
the same descriptor. Is that the case here?

Bart