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

On Thu, Jul 16, 2026 at 01:28:15PM +0100, Mark Brown wrote:
> On Thu, Jul 16, 2026 at 11:22:19AM +0200, Nuno Sá wrote:
> > On Wed, Jul 15, 2026 at 02:37:12PM +0100, Mark Brown wrote:
> 
> > > You still need to work out how the ID appears in the byte stream that
> > > gets sent to/from the device, that's way more information than just a
> > > number and not something the byte stream SPI offers is going to cope
> > > well with.
> 
> > Not sure if I'm following you. Those ID pins just become something you
> > need to set on the spi_xfer. Or in Janani case, she's using regmap
> > reg_base in order to set the right thing depending on the address. I
> > would image this is always something that peripherals need to address in
> > terms of how the message/stream needs to be set. So my understanding is
> > that this should be pretty much transparent for the spi core.
> 
> Oh, isn't that just multi-pin chip selects then:
> 
>    https://patch.msgid.link/[email protected]

No, I think that's something different.

In this case, there is one chip select that all instances of the device
share. Both the ADI and Microchip devices then use the upper bits of the
first/address byte during reads and write to access individual devices.
In the microchip case that I'm familiar with, what upper bits the device
responds to are set by fuses in the factory. They also share the same MOSI
and MISO.

https://ww1.microchip.com/downloads/aemDocuments/documents/MSLD/ProductDocuments/DataSheets/MCP3911-3.3V-Two-Channel-Analog-Front-End-DS20002286D.pdf
(See Figure 6-1 and section 6.2 on page 43)

The SPI core already supports two of these devices from Microchip, since
it just modifies the contents of tx_buf in a spi_transfer.

What Jonathan is working on seems to be a setup where they have multiple
instances of a device with their own chip selects and their own MISO, but
a shared SCLK and MOSI.

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

iHUEABYKAB0WIQRh246EGq/8RLhDjO14tDGHoIJi0gUCalkPgQAKCRB4tDGHoIJi
0vmNAP9AkFNaxjEZSyTfEKFzZq2olZuk05YicHSqI3nmOxgqQwEA3iKLTEWhphUP
dek7aiJwi3r5q+ztZoJbo1JS1yjU2AA=
=s62h
-----END PGP SIGNATURE-----