[PATCH 0/2] pinctrl: mcp23s08: Enable gpio-line-names for multi-chip configurations

[PATCH 0/2] pinctrl: mcp23s08: Enable gpio-line-names for multi-chip configurations

[Jean-Michel Hautbois via B4 Relay]

The MCP23S08/17/18 SPI driver supports multiple GPIO expander chips
sharing the same SPI chip select via hardware address pins (A0-A2).
However, the gpio-line-names device tree property could not be used in
these configurations because all gpio_chip instances tried to use names
starting at index 0.

This series enables gpio-line-names support by setting gpio_chip.offset
for each chip based on cumulative GPIO count.

Example device tree usage:
    gpio@0 {
        compatible = "microchip,mcp23s17";
        microchip,spi-present-mask = /bits/ 8 <0x03>;  /* chips 0 and 1 */
        gpio-line-names =
            /* Chip 0: 16 names */
            "EXP0_A0", "EXP0_A1", ..., "EXP0_B7",
            /* Chip 1: 16 names */
            "EXP1_A0", "EXP1_A1", ..., "EXP1_B7";
    };

Patch 1 implements the driver change (9 lines added).
Patch 2 adds documentation with a complete example.

Testing:
- Verified on AM64x hardware with 2 MCP23S17 chips at addresses 1 and 2
- Confirmed gpio-line-names appear correctly in gpioinfo output
- Each chip's 16 GPIOs receive the correct sequential names

Signed-off-by: Jean-Michel Hautbois <jeanmichel.hautbois@yoseli.org>
---
Jean-Michel Hautbois (2):
      pinctrl: mcp23s08: support gpio-line-names
      dt-bindings: pinctrl: mcp23s08: Add multi-chip example

 .../bindings/pinctrl/microchip,mcp23s08.yaml       | 33 ++++++++++++++++++++++
 drivers/pinctrl/pinctrl-mcp23s08_spi.c             |  4 +++
 2 files changed, 37 insertions(+)
---
base-commit: 0f61b1860cc3f52aef9036d7235ed1f017632193
change-id: 20260112-mcp23s17-multiple-addr-names-42314cda32b9

Best regards,
--  
Jean-Michel Hautbois <jeanmichel.hautbois@yoseli.org>

[PATCH 1/2] pinctrl: mcp23s08: support gpio-line-names

[Jean-Michel Hautbois via B4 Relay]

From: Jean-Michel Hautbois <jeanmichel.hautbois@yoseli.org>

The MCP23S08/17/18 SPI driver supports multiple chips sharing the same
SPI chip select by using the hardware address pins (A0-A2). Each chip
gets its own gpio_chip instance, but they all share the parent device
tree node.

Without setting gpio_chip.offset, the gpio-line-names property cannot
be used because gpiolib assigns all chips names starting at index 0.
Set offset based on cumulative GPIO count to enable sequential
gpio-line-names in device tree:

    microchip,spi-present-mask = /bits/ 8 <0x03>;  /* chips 0 and 1 */
    gpio-line-names =
        /* Chip 0: 16 names */
        "EXP0_A0", "EXP0_A1", ..., "EXP0_B7",
        /* Chip 1: 16 names */
        "EXP1_A0", "EXP1_A1", ..., "EXP1_B7";

Signed-off-by: Jean-Michel Hautbois <jeanmichel.hautbois@yoseli.org>
---
 drivers/pinctrl/pinctrl-mcp23s08_spi.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/drivers/pinctrl/pinctrl-mcp23s08_spi.c b/drivers/pinctrl/pinctrl-mcp23s08_spi.c
index 54f61c8cb1c0..105efc85c3e7 100644
--- a/drivers/pinctrl/pinctrl-mcp23s08_spi.c
+++ b/drivers/pinctrl/pinctrl-mcp23s08_spi.c
@@ -141,6 +141,7 @@ static int mcp23s08_probe(struct spi_device *spi)
 	unsigned long spi_present_mask;
 	unsigned int ngpio = 0;
 	unsigned int addr;
+	unsigned int line_offset = 0;
 	int chips;
 	int ret;
 	u32 v;
@@ -178,6 +179,9 @@ static int mcp23s08_probe(struct spi_device *spi)
 		if (ret)
 			return ret;
 
+		data->mcp[addr]->chip.offset = line_offset;
+		line_offset += data->mcp[addr]->chip.ngpio;
+
 		data->mcp[addr]->pinctrl_desc.name = devm_kasprintf(dev, GFP_KERNEL,
 								    "mcp23xxx-pinctrl.%d",
 								    addr);

-- 
2.39.5

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

[Jean-Michel Hautbois via B4 Relay]

From: Jean-Michel Hautbois <jeanmichel.hautbois@yoseli.org>

Enable gpio-line-names property in the schema and add example showing
how to use it with multiple MCP23S08/17/18 chips sharing the same SPI
chip select. Names are assigned sequentially in hardware address order.

Signed-off-by: Jean-Michel Hautbois <jeanmichel.hautbois@yoseli.org>
---
 .../bindings/pinctrl/microchip,mcp23s08.yaml       | 33 ++++++++++++++++++++++
 1 file changed, 33 insertions(+)

diff --git a/Documentation/devicetree/bindings/pinctrl/microchip,mcp23s08.yaml b/Documentation/devicetree/bindings/pinctrl/microchip,mcp23s08.yaml
index e07f4723de17..667be31b6da3 100644
--- a/Documentation/devicetree/bindings/pinctrl/microchip,mcp23s08.yaml
+++ b/Documentation/devicetree/bindings/pinctrl/microchip,mcp23s08.yaml
@@ -42,6 +42,8 @@ properties:
   interrupts:
     maxItems: 1
 
+  gpio-line-names: true
+
   reset-gpios:
     description: GPIO specifier for active-low reset pin.
     maxItems: 1
@@ -159,3 +161,34 @@ examples:
             microchip,spi-present-mask = /bits/ 8 <0x01>;
         };
     };
+
+  - |
+    /* Multiple chips sharing same SPI CS with gpio-line-names */
+    spi {
+        #address-cells = <1>;
+        #size-cells = <0>;
+
+        gpio@0 {
+            compatible = "microchip,mcp23s17";
+            reg = <0>;
+            gpio-controller;
+            #gpio-cells = <2>;
+            spi-max-frequency = <10000000>;
+            /* Two chips at hardware addresses 0 and 1 */
+            microchip,spi-present-mask = /bits/ 8 <0x03>;
+            /*
+             * 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";
+        };
+    };

-- 
2.39.5

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

[Krzysztof Kozlowski]

On Tue, Jan 13, 2026 at 03:29:48PM +0100, Jean-Michel Hautbois wrote:
> Enable gpio-line-names property in the schema and add example showing
> how to use it with multiple MCP23S08/17/18 chips sharing the same SPI
> chip select. Names are assigned sequentially in hardware address order.
> 
> Signed-off-by: Jean-Michel Hautbois <jeanmichel.hautbois@yoseli.org>
> ---
>  .../bindings/pinctrl/microchip,mcp23s08.yaml       | 33 ++++++++++++++++++++++
>  1 file changed, 33 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/pinctrl/microchip,mcp23s08.yaml b/Documentation/devicetree/bindings/pinctrl/microchip,mcp23s08.yaml
> index e07f4723de17..667be31b6da3 100644
> --- a/Documentation/devicetree/bindings/pinctrl/microchip,mcp23s08.yaml
> +++ b/Documentation/devicetree/bindings/pinctrl/microchip,mcp23s08.yaml
> @@ -42,6 +42,8 @@ properties:
>    interrupts:
>      maxItems: 1
>  
> +  gpio-line-names: true

Variable number of GPIOs? No constraints possible at all? 

> +
>    reset-gpios:
>      description: GPIO specifier for active-low reset pin.
>      maxItems: 1
> @@ -159,3 +161,34 @@ examples:
>              microchip,spi-present-mask = /bits/ 8 <0x01>;
>          };
>      };
> +
> +  - |
> +    /* Multiple chips sharing same SPI CS with gpio-line-names */
> +    spi {
> +        #address-cells = <1>;
> +        #size-cells = <0>;
> +
> +        gpio@0 {
> +            compatible = "microchip,mcp23s17";
> +            reg = <0>;
> +            gpio-controller;
> +            #gpio-cells = <2>;
> +            spi-max-frequency = <10000000>;
> +            /* Two chips at hardware addresses 0 and 1 */
> +            microchip,spi-present-mask = /bits/ 8 <0x03>;
> +            /*
> +             * 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 =

Just extend existing example. There is little point in adding one new
example per one new different property.

Best regards,
Krzysztof

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

[Linus Walleij]

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@kernel.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

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

[Jean-Michel Hautbois]

Hi Linus, Krzysztof,

Le mercredi 14 janvier 2026, 14:52:00 heure normale d’Europe centrale Linus 
Walleij a écrit :
> Hi Jean-Michel,
> 
> thanks for your patch!

Thanks for reviewing !

> 
> On Tue, Jan 13, 2026 at 3:29 PM Jean-Michel Hautbois via B4 Relay
> 
> <devnull+jeanmichel.hautbois.yoseli.org@kernel.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.
> 

Indeed, I was probably a bit optimistic :-).
What about this:
 allOf:
   - $ref: /schemas/spi/spi-peripheral-props.yaml#
+  - if:
+      properties:
+        compatible:
+          contains:
+            enum:
+              - microchip,mcp23s08
+              - microchip,mcp23008
+    then:
+      properties:
+        gpio-line-names:
+          maxItems: 32
+        pinmux:
+          properties:
+            pins:
+              maxItems: 32
+  - if:
+      properties:
+        compatible:
+          contains:
+            enum:
+              - microchip,mcp23s17
+              - microchip,mcp23s18
+              - microchip,mcp23017
+              - microchip,mcp23018
+    then:
+      properties:
+        gpio-line-names:
+          maxItems: 128
+        pinmux:
+          properties:
+            pins:
+              maxItems: 128
+

This would allow up to 4 chips to be on the same CS. But in the 
microchip,mcp23s17 datasheet, it says:
"Three Hardware Address Pins to Allow Up to Eight Devices On the Bus"

So, the maxItems could even be 256 for microchip,mcp23x17/18 family !

What do you think (sorry for the headache !) ?
Thanks,
JM

>  +            /*
> 
> > +             * 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

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

[Linus Walleij]

On Wed, Jan 14, 2026 at 6:29 PM Jean-Michel Hautbois
<jeanmichel.hautbois@yoseli.org> wrote:

> > 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.
>
> Indeed, I was probably a bit optimistic :-).
> What about this:
>  allOf:
>    - $ref: /schemas/spi/spi-peripheral-props.yaml#
> +  - if:
> +      properties:
> +        compatible:
> +          contains:
> +            enum:
> +              - microchip,mcp23s08
> +              - microchip,mcp23008
> +    then:
> +      properties:
> +        gpio-line-names:
> +          maxItems: 32
> +        pinmux:
> +          properties:
> +            pins:
> +              maxItems: 32
> +  - if:
> +      properties:
> +        compatible:
> +          contains:
> +            enum:
> +              - microchip,mcp23s17
> +              - microchip,mcp23s18
> +              - microchip,mcp23017
> +              - microchip,mcp23018
> +    then:
> +      properties:
> +        gpio-line-names:
> +          maxItems: 128
> +        pinmux:
> +          properties:
> +            pins:
> +              maxItems: 128
> +
>
> This would allow up to 4 chips to be on the same CS.

Hm I don't get it why everything is multiplied by 4 here?

Doesn't each chip have its own instance? And the instance is
limited to 8 or 16 lines/pins?

> But in the
> microchip,mcp23s17 datasheet, it says:
> "Three Hardware Address Pins to Allow Up to Eight Devices On the Bus"

Doesn't each device have its own entry?

Yours,
Linus Walleij

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

[Jean-Michel Hautbois]

Hi Linus,

Le lundi 19 janvier 2026, 00:12:05 heure normale d’Europe centrale Linus 
Walleij a écrit :
> On Wed, Jan 14, 2026 at 6:29 PM Jean-Michel Hautbois
> 
> <jeanmichel.hautbois@yoseli.org> wrote:
> > > 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.
> > 
> > Indeed, I was probably a bit optimistic :-).
> > 
> > What about this:
> >  allOf:
> >    - $ref: /schemas/spi/spi-peripheral-props.yaml#
> > 
> > +  - if:
> > +      properties:
> > +        compatible:
> > +          contains:
> > +            enum:
> > +              - microchip,mcp23s08
> > +              - microchip,mcp23008
> > +    then:
> > +      properties:
> > +        gpio-line-names:
> > +          maxItems: 32
> > +        pinmux:
> > +          properties:
> > +            pins:
> > +              maxItems: 32
> > +  - if:
> > +      properties:
> > +        compatible:
> > +          contains:
> > +            enum:
> > +              - microchip,mcp23s17
> > +              - microchip,mcp23s18
> > +              - microchip,mcp23017
> > +              - microchip,mcp23018
> > +    then:
> > +      properties:
> > +        gpio-line-names:
> > +          maxItems: 128
> > +        pinmux:
> > +          properties:
> > +            pins:
> > +              maxItems: 128
> > +
> > 
> > This would allow up to 4 chips to be on the same CS.
> 
> Hm I don't get it why everything is multiplied by 4 here?
> 
> Doesn't each chip have its own instance? And the instance is
> limited to 8 or 16 lines/pins?
> 
> > But in the
> > microchip,mcp23s17 datasheet, it says:
> > "Three Hardware Address Pins to Allow Up to Eight Devices On the Bus"
> 
> Doesn't each device have its own entry?

As far as I get it, for I2C variants, each chip has its own device node,
so gpio-line-names would be limited to 8/16 per node.

However, for SPI variants (mcp23s08/s17/s18), multiple chips can share
the same SPI chipselect via the 'microchip,spi-present-mask' property.

In this case, a single DT node represents multiple physical chips,
and gpio-line-names needs to cover all of them:
- mcp23s08: up to 4 chips × 8 GPIOs = 32 lines
- mcp23s17: up to 8 chips × 16 GPIOs = 128 lines

Should I split the conditionals to apply different limits for I2C vs SPI?

Or did I miss something which is totally possible too -_-' ?

Thanks,
JM

> Yours,
> Linus Walleij

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

[Linus Walleij]

Hi Jean-Michel,

paging in Lars Poeschel who might be able to shed some light on this!

On Mon, Jan 19, 2026 at 7:17 AM Jean-Michel Hautbois
<jeanmichel.hautbois@yoseli.org> wrote:
> Le lundi 19 janvier 2026, 00:12:05 heure normale d’Europe centrale Linus
> Walleij a écrit :
> > On Wed, Jan 14, 2026 at 6:29 PM Jean-Michel Hautbois

> > <jeanmichel.hautbois@yoseli.org> wrote:
> > > > 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.
> > >
> > > Indeed, I was probably a bit optimistic :-).
> > >
> > > What about this:
> > >  allOf:
> > >    - $ref: /schemas/spi/spi-peripheral-props.yaml#
> > >
> > > +  - if:
> > > +      properties:
> > > +        compatible:
> > > +          contains:
> > > +            enum:
> > > +              - microchip,mcp23s08
> > > +              - microchip,mcp23008
> > > +    then:
> > > +      properties:
> > > +        gpio-line-names:
> > > +          maxItems: 32
> > > +        pinmux:
> > > +          properties:
> > > +            pins:
> > > +              maxItems: 32
> > > +  - if:
> > > +      properties:
> > > +        compatible:
> > > +          contains:
> > > +            enum:
> > > +              - microchip,mcp23s17
> > > +              - microchip,mcp23s18
> > > +              - microchip,mcp23017
> > > +              - microchip,mcp23018
> > > +    then:
> > > +      properties:
> > > +        gpio-line-names:
> > > +          maxItems: 128
> > > +        pinmux:
> > > +          properties:
> > > +            pins:
> > > +              maxItems: 128
> > > +
> > >
> > > This would allow up to 4 chips to be on the same CS.
> >
> > Hm I don't get it why everything is multiplied by 4 here?
> >
> > Doesn't each chip have its own instance? And the instance is
> > limited to 8 or 16 lines/pins?
> >
> > > But in the
> > > microchip,mcp23s17 datasheet, it says:
> > > "Three Hardware Address Pins to Allow Up to Eight Devices On the Bus"
> >
> > Doesn't each device have its own entry?
>
> As far as I get it, for I2C variants, each chip has its own device node,
> so gpio-line-names would be limited to 8/16 per node.
>
> However, for SPI variants (mcp23s08/s17/s18), multiple chips can share
> the same SPI chipselect via the 'microchip,spi-present-mask' property.
>
> In this case, a single DT node represents multiple physical chips,
> and gpio-line-names needs to cover all of them:
> - mcp23s08: up to 4 chips × 8 GPIOs = 32 lines
> - mcp23s17: up to 8 chips × 16 GPIOs = 128 lines
>
> Should I split the conditionals to apply different limits for I2C vs SPI?
>
> Or did I miss something which is totally possible too -_-' ?

Just that several chips share the same chip select does not
mean they should have the same device instance.

You can also confirm that Linux instantiates one regmap
and one gpio_chip per device node. The ngpio accumulated
in pinctrl-mcp23s08_spi.c  mcp23s08_probe() is not used for
anything, in fact it is garbage AFAICT and should be deleted.

Further, we apparently have no in-kernel device tree actually
using this property. Just grep for microchip,spi-present-mask
and mcp,spi-present-mask: no-one is using this property.
No-one on the entire internet either. So I seriously wonder
about this thing.

Given that the code bails out for the SPI device if this property
isn't present and we still have a bunch of SPI-based
MCP23S08 in the tree I wonder what is going on. Are all of
these broken?? They clearly never use more than 8/16
lines/GPIOs anyway.

I think you can safely assume 8/16 lines for any device
here.

I'd like to hear from someone using the MCP23S* devices
over SPI if their device is actually working :/

Yours,
Linus Walleij