Re: [RFC PATCH v1 1/2] dt-bindings: gpio: add gpio-split controller

[Jonas Jelonek <jelonek.jonas@gmail.com>]

Hi Linus,

On 14.10.25 10:23, Linus Walleij wrote:
> Hi Jonas,
>
> thanks for your patch!
>
> Including Peter Rosin (the gpio-mux author) and Geert Uytterhoeven
> on this review, as they have worked with similar stuff. Please include
> them on future postings. The result definitely need Peters ack before
> we can merge it.

Thanks, will do.

> So if I understand it correctly this models a 1-to-many input-only
> GPIO multiplexer, we need an illustration such as
>
>         +----- A
> IN     /
> <-----o------- B
>     / |\
>     | | +----- C
>     | |  \
>     | |   +--- D
>     | |
>    M1 M0
>
> MUX CONTROL
>
>  M1 M0   INPUT
>   0  0   A
>   0  1   B
>   1  0   C
>   1  1   D
>
> Is this correct? In that case include something like this
> verbatim in the bindings (feel free to copy/modify this)
> as it makes it much easier to understand what is going on.

You nailed it. I'll include your drawing in the bindings then in the next
revision. Only thing is that I just didn't limit it to being 'input-only'.
I have no real usecase for this but to me there was no really obvious issue
needing this to be input-only.

> That's a very minimal example of a way to turn 3 GPIO
> lines into 4 GPIO lines, which is a bit crazy but I'm not
> the one to tell vendors what to do :D

On my device it's actually that the single GPIO mux controls the signals for
both SFP cages, meaning it makes more sense in the big picture though a GPIO
expander as all other vendors do would've been better IMO ^^.

>> +  mux-controls:
>> +    maxItems: 1
> So this needs a description, it is a phandle to the
> gpio multiplexer (reference /schemas/mux/gpio-mux.yaml
> explicitly!) used by the splitter.
>
> You should also in the same patch add an example to
> /schemas/mux/gpio-mux.yaml showing how this is used
> to muliplex GPIOs so people find this new usecase easily.

Sure, will add it.

>> +  shared-gpio:
>> +    description:
>> +      GPIO that is shared by the virtual GPIOs and controlled via the mux.
> So this one is shared one-to-many, and I think the bindings
> overall makes sense.

I'll also add this hint to the description to make it clearer.

> Maybe "gpio-split" is a bit ambiguous?
> We have io-channel-mux, so what about "gpio-line-mux"
> simply?
>
> The fact that GPIO lines are used to do the muxing is just
> a detail since a mux is an abstract concept, it could have
> just as well been muxed with some I2C device for example.

Sure, this was just my initial idea but I'm not fixed to it. I can adjust
that in the next iteration.

> Yours,
> Linus Walleij

Best,
Jonas