RE: [PATCH v6 1/4] dt-bindings: media: ti,ds90ub953: Add support for remote GPIO data source

G.N. Zhou (OSS)
2026-04-27T09:13:02Z

Hi Linus,

Thanks for your review.

> -----Original Message-----
> From: Linus Walleij <linusw@kernel.org>
> Sent: Sunday, April 26, 2026 4:36 PM
> To: G.N. Zhou (OSS) <guoniu.zhou@oss.nxp.com>
> Cc: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>; Mauro Carvalho
> Chehab <mchehab@kernel.org>; Rob Herring <robh@kernel.org>; Krzysztof
> Kozlowski <krzk+dt@kernel.org>; Conor Dooley <conor+dt@kernel.org>; Frank
> Li <frank.li@nxp.com>; Vladimir Zapolskiy <vz@mleia.com>; Bartosz
> Golaszewski <brgl@kernel.org>; linux-media@vger.kernel.org;
> devicetree@vger.kernel.org; linux-kernel@vger.kernel.org; imx@lists.linux.dev;
> linux-gpio@vger.kernel.org; G.N. Zhou <guoniu.zhou@nxp.com>
> Subject: Re: [PATCH v6 1/4] dt-bindings: media: ti,ds90ub953: Add support for
> remote GPIO data source
>
> Hi Guoniu,
>
> thanks for your patch!
>
> n Fri, Apr 24, 2026 at 3:40 AM Guoniu Zhou <guoniu.zhou@oss.nxp.com>
> wrote:
>
> > The DS90UB953 supports four pins, GPIO0 through GPIO3. When enabled as
> > an output, it can be programed to output local data or remote data
> > coming from the remote compatible deserializer.
> >
> > Add GPIO flag in second cell to select remote GPIO data source.
> >
> > Signed-off-by: Guoniu Zhou <guoniu.zhou@nxp.com>
> (...)
> > ---
> > Changes in v6:
> > - Added GPIO_DATA_SOURCE_REMOTE flag to dt-bindings/gpio/gpio.h
>
> (...)
> > +/*
> > + * Bit 24 indicates the GPIO data source is from a remote device.
> > + * This is used in serializer/deserializer setups where the GPIO pin
> > + * on the local device (e.g., TI DS90UB953 serializer) reflects the
> > + * state of a GPIO on the remote device (e.g., TI DS90UB960 deserializer).
> > + */
> > +#define GPIO_DATA_SOURCE_REMOTE 0x01000000
>
> So this is added to all GPIO controllers ever in existance as something
> fundamental about GPIO that may need its own flag.

You're absolutely right that adding this to the global GPIO flags is too
broad for what is essentially a device-specific requirement.

>
> I doubt this.
>
> I understand that the driver needs to deal with this in a per-gpio-line basis
> though, have you considered:
>
> 1. Just hard-coding this into the driver based on the .compatible
> string, if the remote GPIOs are always the same for this TI thing?
>
> 2. If it is just for one particular system, you *could* actually have
> a table/mask inside the driver for this:
> if (of_machine_is_compatible("my-funky-system")) which will
> kick in only on that very machine,
>
> 3. If you really want to store the information in the media i2c
> device node, add some custom property like this:
> ti,remote-sources = <0x0000001f>;
> where a bit is set to 1 for each GPIO which is remote.
>
> Putting flags on the GPIO lines themselves seems too complex and system-
> specific.

Thank you for the detailed feedback.

After considering your suggestions, I think option 3 (custom device property)
is the most appropriate approach for this case.

However, I initially implemented this using a custom device property
(ti,gpio-data) in v1 [1], and Vladimir rejected that approach.

In v2, I extended the GPIO cell to use a third cell to mark remote data,
but unfortunately, this broke the ABI. Rob suggested using a flag in the
second cell or extending the GPIO range to represent remote data [2].

I adopted the extended GPIO range approach in v3, but in v5, Tomi
suggested using a custom GPIO flag instead [3].

I attempted to implement this, but couldn't find guidance on how to add
custom GPIO flags, so I added it to include/dt-bindings/gpio/gpio.h and
choose bit 24, see the reasons in [4].

Given this history, what would be the acceptable solution? Could the
maintainers align on the preferred approach. I'm happy to implement
whichever solution is acceptable, but I need clear direction to avoid going
in circles.

[1]: https://lore.kernel.org/all/e526e93e-1373-4f1e-82ab-6b22d68211cd@mleia.com/
[2]: https://lore.kernel.org/all/20250915015309.GA2329507-robh@kernel.org/
[3]: https://lore.kernel.org/all/d63bff5a-1a37-4162-8b75-bf62787a0782@ideasonboard.com/
[4]: https://lore.kernel.org/all/AS8PR04MB9080CEB000F4F1C9043E8C21FA362@AS8PR04MB9080.eurprd04.prod.outlook.com/#t
>
> Yours,
> Linus Walleij