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

On Tue, Jul 28, 2026 at 06:06:32PM +0100, Nuno Sá wrote:
> On Tue, Jul 28, 2026 at 05:10:55PM +0100, 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?
> > 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.
> 
> IIUC, I think for the current ADI device it could actually be useful to have
> the above representation given that, in theory, any of the logical
> devices can have their own supplies, pins, etc (so it would help to have
> each of them as adc@address,spi-device-address)... But we choose not to go
> down that path (in previous versions) for simplicity. So yeah, not sure

You can have either representation, I don't really care, they're much of
a muchness to me. Just you can't have both!

> :).
> 
> - Nuno Sá
> 
> > 
> > > 
> > > 
> > > Also feels like this series should update the one use of the microchip binding
> > > in tree.
> > > 
> > > arch/riscv/boot/dts/microchip/mpfs-beaglev-fire.dts
> > 
> > I never asked for this cos I maintain the platform and was gonna fix it
> > up myself, but sure!
> 
>

-----BEGIN PGP SIGNATURE-----

iHUEABYKAB0WIQRh246EGq/8RLhDjO14tDGHoIJi0gUCamjkNgAKCRB4tDGHoIJi
0tDzAQD1eLvcNgHKFZmG02MdYRWuzwVyRhI6ahm9VKUXPI8ykgD/amgLx6jgTYB5
8wgMq4RkZLn56LxshmnCbdAkMESb7AU=
=J+ZH
-----END PGP SIGNATURE-----