Re: [PATCH v7 1/7] spi: dt-bindings: Add spi-device-addr peripheral property

On Tue, 28 Jul 2026 16:46:26 -0500
David Lechner <[email protected]> wrote:

> On 7/28/26 4:05 PM, Jonathan Cameron wrote:
> > On Tue, 28 Jul 2026 13:39:20 -0500
> > David Lechner <[email protected]> wrote:
> >   
> >> On 7/28/26 11:10 AM, Conor Dooley wrote:  
> >>> On Sat, Jul 25, 2026 at 11:04:45PM +0100, Jonathan Cameron wrote:    
> >>>> On Sat, 25 Jul 2026 15:55:01 -0500
> >>>> David Lechner <[email protected]> wrote:
> >>>>    
> >>>>> On 7/22/26 2:54 AM, Janani Sunil wrote:    
> >>>>>> Some SPI devices support sharing a single chip select across multiple
> >>>>>> physical chips by encoding a device address in the SPI frame itself.
> >>>>>> Add the generic spi-device-addr property for describing these hardware
> >>>>>> addresses. The property is placed on the SPI peripheral node and may
> >>>>>> contain multiple addresses.
> >>>>>>
> >>>>>> Signed-off-by: Janani Sunil <[email protected]>
> >>>>>> ---
> >>>>>>  Documentation/devicetree/bindings/spi/spi-peripheral-props.yaml | 7 +++++++
> >>>>>>  1 file changed, 7 insertions(+)
> >>>>>>
> >>>>>> diff --git a/Documentation/devicetree/bindings/spi/spi-peripheral-props.yaml b/Documentation/devicetree/bindings/spi/spi-peripheral-props.yaml
> >>>>>> index 880a9f624566..b59d047cf117 100644
> >>>>>> --- a/Documentation/devicetree/bindings/spi/spi-peripheral-props.yaml
> >>>>>> +++ b/Documentation/devicetree/bindings/spi/spi-peripheral-props.yaml
> >>>>>> @@ -142,6 +142,13 @@ properties:
> >>>>>>      minItems: 2
> >>>>>>      maxItems: 4
> >>>>>>  
> >>>>>> +  spi-device-addr:
> >>>>>> +    $ref: /schemas/types.yaml#/definitions/uint32-array
> >>>>>> +    description:
> >>>>>> +      Device addresses used when multiple peripherals share a single chip
> >>>>>> +      select. The array allows one logical peripheral to comprise multiple
> >>>>>> +      physical devices, with one address per device.      
> >>>>>
> >>>>> "per physical device" for clarity.
> >>>>>    
> >>>>
> >>>> We may end up relaxing that again if multichip packages start doing this.
> >>>> Fine to add that clarification for now. We can revisit when / if it ever
> >>>> needs that relaxing.
> >>>>    
> >>>>>> +
> >>>>>>    st,spi-midi-ns:
> >>>>>>      deprecated: true
> >>>>>>      description: |
> >>>>>>       
> >>>>>
> >>>>> If there is nothing useful the SPI core code can do with this information,
> >>>>> I'm not entirely convinced that this needs to be a common property.    
> >>>>
> >>>> I think being common does make some sense from a standarization point of
> >>>> view and it isn't obvious where to put it other than under spi.
> >>>>    
> >>>>>
> >>>>> And this only allows for one logical device. If we wanted to treat each
> >>>>> address as a logical device (all with same CS), we would need #address-cells = <2>;
> >>>>> instead where the DT "address" is two values, the CS and the device address.    
> >>>>
> >>>> Ah.  Good point for the adc@address or similar needing to match a combination
> >>>> of CS and spi-device-addr.  Conor any thoughts on how this would be done?    
> >>>
> >>> I'm sorry, I don't quite understand. Why do you want to support both of
> >>> these representations? Hardware wise both of these things would be
> >>> describing the same setup, so allowing this alternate "multiple logical
> >>> device" typically is not permitted. What even is the use case of it?  
> > 
> > The microchip parts.  They are entirely independent. The device address is
> > just a way to save pins.  That is contrasting those with the one in this
> > series where the design assumes you want to treat them as a large logical
> > device in a similar way to spi device chaining.
> > 
> >   
> >>> Does it matter at all if you have one or more logical devices from a
> >>> consumer perspective?
> >>>
> >>> I do have an idea of how to solve the adc@address problem (you can do
> >>> adc@address,spi-device-address like some other devices) but as I said I
> >>> don't get why it would be needed.    
> > 
> > I think we should often do this because there are some confusing cases
> > otherwise. See below.
> >   
> >>
> >> I would expect that if such a device was intended to be used as individual
> >> logical devices that they would just be wired up each with their own chip
> >> select rather than sharing one.
> >>
> >> The only reason I can think of actually needing adc@address,spi-device-address
> >> would be on a system that was really short on pins on the MCU.
> >>
> >> So not saying that we need it right now. Just wanted to make sure we were
> >> intentional about saying we don't need it if we don't.  
> > 
> > To enumerate the cases:
> > 
> > 1. One CS has multiple spi-device-address and needs to be a combined device.
> > 	Given this ADC does some fun stuff to include messages with no
> >         spi-device-address that are meant to be received by all such
> > 	devices we pretty much have to map any that share a CS to one
> > 	logical device - we have to bind one driver.  This is kind of
> > 	similar to SPI device chaining.
> > 	address == cs.  spi-device-address property not used for that.
> > 	- This one can be normal SPI style.
> > 
> > 2. One CS has multiple spi-device-address but logically separate otherwise.
> > 	This is the microchip devices I think.  For those the device-address
> > 	is just a pin saving exercise.
> > 	address == spi-device-address. CS not needed as there is only one.  
> 
> We would still need CS to tell the SPI controller which one is wired. So
> we should never have adc@spi-device-address, only adc@cs,spi-device-address.
> 
> (There currently isn't any binding for SPI_NO_CS, so the controller would
> still need a CS line even if it isn't wired/muxed and CS on the peripheral
> is hardwired.)

Sure - it needs to provided today because the reg entry must match the adc@reg
bit.  That 'could' be relaxed.  I don't think it's a good idea but
I thought this was what Conor was proposing.

> 
> > 
> > 2b.  Same as 2, but there is another normal ADC with a chip select.
> > 	How do we know adc@spi-device-address vs adc@cs given they could
> > 	easily take same address value by coincidence?  
> 
> As above.
> 
> > 
> > 2c. Basically Case as 2 but * N CS all on same SPI bus.
> > 	As David calls out this is the pin count minimization case.
> > 	E.g. I want 8 devices each of which has 2 pin straps to set the
> > 	device address.  So I have to use at least 2 CS.
> > 	For this I need both cs and device-address and Conor's suggestion works.
> > 
> > There is a case of 1 + 2 with different device types but result is same
> > as 2c.
> > 
> > Now, to me the question is whether we say that if spi-device-address is
> > present you always do adc@cs,spi-device-address or do we allow for not
> > doing so for the composite devices where nothing else is sharing the CS
> > (like this driver).
> > 
> > My inclination is standardize on always doing it for these devices.
> > 
> > Jonathan
> >   
> >>
> >>  
> >   
>