linux-kernel - Re: [PATCH 2/2] dt-bindings: pinctrl: mcp23s08: Add multi-chip example

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAD++jLmP13oeiZJx9_Y4oOCvFbJ=TaU_exHu9qqZjnCR9DGAbA@mail.gmail.com>
Date: Wed, 14 Jan 2026 14:52:00 +0100
From: Linus Walleij <linusw@...nel.org>
To: jeanmichel.hautbois@...eli.org
Cc: Rob Herring <robh@...nel.org>, Krzysztof Kozlowski <krzk+dt@...nel.org>, 
	Conor Dooley <conor+dt@...nel.org>, Himanshu Bhavani <himanshu.bhavani@...iconsignals.io>, 
	linux-gpio@...r.kernel.org, linux-kernel@...r.kernel.org, 
	devicetree@...r.kernel.org
Subject: Re: [PATCH 2/2] dt-bindings: pinctrl: mcp23s08: Add multi-chip example

Hi Jean-Michel,

thanks for your patch!

On Tue, Jan 13, 2026 at 3:29 PM Jean-Michel Hautbois via B4 Relay
<devnull+jeanmichel.hautbois.yoseli.org@...nel.org> wrote:

> +  gpio-line-names: true

I have a bit of similar concerns as Krzysztof, this is unlimited.

This is actually:
- 8 for microchip,mcp23008 and microchip,mcp23s08
- 16 for microchip,mcp23017, microchip,mcp23018, microchip,mcp23s17
and microchip,mcp23s18

(The "s" variants are just the SPI variants of the same chip...)

Make some fancy - if: clauses to decide the maxItems from the compatible.
Don't hesitate to ask for help if this gets complicated, I get a panic
every time I have to deal with it because of the whitespacing business.

 +            /*
> +             * Names assigned sequentially in address order.
> +             * First 16 names for chip at address 0 (GPA0-7, GPB0-7).
> +             * Next 16 names for chip at address 1 (GPA0-7, GPB0-7).
> +             */
> +            gpio-line-names =
> +                "EXP0_GPA0", "EXP0_GPA1", "EXP0_GPA2", "EXP0_GPA3",
> +                "EXP0_GPA4", "EXP0_GPA5", "EXP0_GPA6", "EXP0_GPA7",
> +                "EXP0_GPB0", "EXP0_GPB1", "EXP0_GPB2", "EXP0_GPB3",
> +                "EXP0_GPB4", "EXP0_GPB5", "EXP0_GPB6", "EXP0_GPB7",
> +                "EXP1_GPA0", "EXP1_GPA1", "EXP1_GPA2", "EXP1_GPA3",
> +                "EXP1_GPA4", "EXP1_GPA5", "EXP1_GPA6", "EXP1_GPA7",
> +                "EXP1_GPB0", "EXP1_GPB1", "EXP1_GPB2", "EXP1_GPB3",
> +                "EXP1_GPB4", "EXP1_GPB5", "EXP1_GPB6", "EXP1_GPB7";

So we get this, and we already have this (from the example):

            gpiopullups: pinmux {
                pins = "gpio0", "gpio1", "gpio2", "gpio3",
                       "gpio4", "gpio5", "gpio6", "gpio7",
                       "gpio8", "gpio9", "gpio10", "gpio11",
                       "gpio12", "gpio13", "gpio14", "gpio15";
                bias-pull-up;
            };

This is wild, we need some constraints I think.

Whatever we come up with to limit the number of items in gpio-line-names
should also be applied to the "pins" list in the pinmux node.

Yours,
Linus Walleij