Re: [PATCH v4 1/9] spi: dt-bindings: Add spi-cs-composite property

[Conor Dooley]

On Mon, Oct 26, 2026 at 02:00:03AM +0000, Jonathan Cameron wrote:
> On Tue, 20 Oct 2026 22:56:41 -0300
> Jonathan Santos <Jonathan.Santos@xxxxxxxxxx> wrote:
> 
> > Some setups combine several SPI devices into one logical device, with
> > each chip on its own CS line. All of those CS lines must be asserted at
> > the same time, so that one transfer reaches every chip.
> > 
> > Add the 'spi-cs-composite' boolean property. When it is set, every chip
> > select listed in 'reg' is asserted together on each transfer.
> 
> To me it feels inevitable that we will see a device / combination of
> devices that want groups of CS lines together and others independent.
> 
> Seems less likely we'll see more than one set of composite entrees.
> Maybe this should be an array of values that match with specific
> entrees in reg?
> 
> I'm not sure though.  Conor, Kryzsztof or Rob, any thoughts on this
> or similar things that have arisen elsewhere?

Why does the property actually exist in the first place? Does the device
driver not know how each CS should be treated?

> 
> The most general case would (subject to it not working) smell like
> 
> reg = < <0x1 0x4 0x5> <0x2> >
> 
> Where intent is that 1 4 and 5 are meant to switch together and
> 2 is separate.

I would expect that for this kind of device, the driver should know that
the first 3 CS are switched together and the 4th is not. I'm not really
sure what the internal representation should be, because if someone can
make a device like this, they could surely also make a device where (to
borrow your format) it behaves like

| reg = < <0x1 0x4> <0x5 0x2> >

and so on. But if those devices don't actually exist at the moment, and
everything is either all together or all seperate, the API for this
stuff in the SPI core doesn't have to solve that until a device actually
shows up.

Worst case is something where there's a variable grouping of chip
selects, e.g.

| reg = < <0x1 0x4 0x5> <0x2> >

or

| reg = < <0x1 0x4> <0x2> >

but maybe if that happens the thing to do is permit reg-names for that
device, and again store the relationships in the driver rather than
try to convey it via DT.

Cheers,
Conor.

> 
> How to do lookup on something like this is another question.
> 
> Jonathan
> 
> 
> > 
> > Signed-off-by: Jonathan Santos <Jonathan.Santos@xxxxxxxxxx>
> > ---
> > Changes in v4:
> > * New patch. This has been included because without an explicit property,
> >   every device with more than one 'reg' entry would have all its chip
> >   selects asserted together. That breaks devices that use ancillary
> >   devices for the extra CS lines, so the composite behavior is now opt-in.
> > ---
> >  .../devicetree/bindings/spi/spi-peripheral-props.yaml     | 8 ++++++++
> >  1 file changed, 8 insertions(+)
> > 
> > diff --git a/Documentation/devicetree/bindings/spi/spi-peripheral-props.yaml b/Documentation/devicetree/bindings/spi/spi-peripheral-props.yaml
> > index 4894196c8f9c..456cb9095632 100644
> > --- a/Documentation/devicetree/bindings/spi/spi-peripheral-props.yaml
> > +++ b/Documentation/devicetree/bindings/spi/spi-peripheral-props.yaml
> > @@ -60,6 +60,14 @@ properties:
> >        Delay in nanoseconds to be introduced by the controller after CS is
> >        de-asserted.
> >  
> > +  spi-cs-composite:
> > +    description: Some SPI devices can be aggregated into a single logical
> > +      device by asserting all their chip selects simultaneously. When this
> > +      property is present, all chip selects listed in the 'reg' property are
> > +      asserted together on every transfer, treating the group as one composite
> > +      device.
> > +    type: boolean
> > +
> >    spi-rx-bus-width:
> >      description:
> >        Bus width to the SPI bus used for read transfers.
>

Attachment: signature.asc
Description: PGP signature