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

[Jonathan Santos <jonath4nns@gmail.com>]

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@analog.com> 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?).

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@analog.com>
> > > ---
> > > 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.
> >