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

[Jonathan Cameron]

On Sat, 31 Oct 2026 03:20:26 -0300
Jonathan Santos <jonath4nns@xxxxxxxxx> wrote:

> On 10/27, Conor Dooley wrote:
> > 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?
> >  
> 
> Hi Conor, Jonathan,
> 
> Thanks for the feedback.
> 
> The problem we are addressing now: today the SPI core gives a driver very 
> little control over chip selects. The main spi_device only drives the first
> 'reg' entry and the only way a driver can use the other CS lines is through
> ancillary devices, but for individual access only. For aggregated chips 
> (AD7768-1 in this case) we need all CS lines asserted at the same time, and 
> nothing in the core lets the driver ask for that AFAIK.
> 
> In v1 I added a CS mask to struct spi_transfer, but that also needed a
> lane mask to work, and after the feedback we agreed it was too flexible
> and too easy to get wrong. In v2 and v3 I switched to ancillary devices
> (each with a lane attached) for single-CS access. That covered
> individual access, but there was still no way to assert all the CS lines
> at once. The spi-cs-composite property in v4 was my way around that, 
> letting the main device be the aggregator and using the ancillaries for
> single access.
> 
> David also suggested two alternatives before that don't need any DT changes:
> 
>  a) Add a CS description to struct spi_transfer or spi_message, e.g.
>     passing the ancillary devices whose CS should be asserted. This also
>     allows dynamic CS selection within the main device. And since the
>     ancillary devices are already bound to a lane, this is less prone to
>     errors than the approach on v1.
> 
>  b) Add a new "composite" spi device, so a driver would have the main
>     device, ancillaries for individual access, and a composite device
>     for simultaneous access. The issue I saw is that the ancillary and
>     composite devices are siblings and their CS lines would conflict in
>     the core's CS check, so only one kind could exist for a given
>     device, not both (without some more complex logic in the spi cs check).
> 
> I like the (b) approach, but we would have to bypass that sibling problem.
> The (a) looks less harmful to existing projects, if everyone agrees I can
> implement it on v5. Also with (a) I think we can drop the spi device
> name for now (or not?).

I don't have a strong opinion on the way forward here.
Mark, any thoughts on what is going to work best long term for SPI?

I'm nervous that we might wall ourselves into a corner if not
careful about bindings. That is less of a concern for in kernel
interfaces which probably won't be that widely used.

Jonathan

> 
> Best regards,
> Jonathan Santos
> 
> > > 
> > > 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.
> >   
> 
> Yes, this is a bit out of the scope and kind of complex.
> 
> > 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.  
> > >   
> 
>