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

[David Lechner <dlechner@baylibre.com>]

On 7/28/26 4:05 PM, Jonathan Cameron wrote:
> On Tue, 28 Jul 2026 13:39:20 -0500
> David Lechner <dlechner@baylibre.com> 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 <dlechner@baylibre.com> 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 <janani.sunil@analog.com>
>>>>>> ---
>>>>>>  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.)

> 
> 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
> 
>>
>>
>