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] [day] [month] [year] [list]

Message-ID: <CAD++jLkmOHF8sPa2OMW9QF3+MHaFWtmpsZje0UU2q0EaN4OExA@mail.gmail.com>
Date: Mon, 19 Jan 2026 09:46:16 +0100
From: Linus Walleij <linusw@...nel.org>
To: Jean-Michel Hautbois <jeanmichel.hautbois@...eli.org>, Lars Poeschel <poeschel@...onage.de>
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,

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