From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 1830A37E5CE; Wed, 29 Jul 2026 22:47:38 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785365260; cv=none; b=AdZXlk7CYcNJO/MJ3nwfpAj20YMfGBuFDLSAxS8KIAVOa6LQ+kY6YYYU5xpGMBskotxVXSFANfmo7O2XG8un1Tjs1f1ZJVcNeAV13LpSLWLhM+sqRw9FgW7IONfi3L1A2g8IVYHLfX138imGhoBJVmrgrUGT74Ra7P31CcCeIuo= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785365260; c=relaxed/simple; bh=W4Ui70n5xFnTa802mEnZLkbAQG4UwWdi84S/0eTZq+s=; h=Date:From:To:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=ncDv6VxBwyslBaIg+qs+zPnJVTFXcl2W4UXYoYfVZE32c6ECq93X6O32d9mp6xE8F+2q/zEBdxSjGcd6w3zO2cYcaaABONFaodJVvhd1NAKMsNVQAGMuh6Lt8Hrpe+OGLXb8Nlgxa3HiiAZsSkNO6ws8pg06pAyB2u5ME1oxpIs= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=AxSKw8HL; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="AxSKw8HL" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 16F7D1F000E9; Wed, 29 Jul 2026 22:47:37 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1785365258; bh=vMXRsnL3EafGsZdVSmTWqi92Pdp6B251xlDnGExp0iw=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=AxSKw8HLkRHHqjcc1/u1RT1Q2jwU5+NEYqAinUt5CcD4xvrymZnPeH6RuWUhntiny VtdgFAK77/dfdwxf03MXlsZaq+9aT/g1lnVklNhdw5NGg2cKjlCfOLX6plVnZ1sbtA CIfFv1P8N8hZHTa6Qc4vdthyoIs85mpp5NJFgou0vXIQyY3ZRha3yzi7pPWzJTcZPY yAWBT4XAvW0hGyjsFgbACFOG1YSJP7K6ZI5AjVeVUonj110HpUERBBgCk1wRJTDTa3 prdJYAkSPlHB05FaBIUoQE0xYBj3tS/L11W7eZX6lNOiRgxQdBp+g2gqbuqLzc3udj l83AhvsGTpHDA== Date: Wed, 29 Jul 2026 23:47:33 +0100 From: Jonathan Cameron To: David Lechner Cc: Conor Dooley , Janani Sunil , Lars-Peter Clausen , Michael Hennerich , Nuno =?UTF-8?B?U8Oh?= , Andy Shevchenko , Rob Herring , Krzysztof Kozlowski , Conor Dooley , Philipp Zabel , Jonathan Corbet , Shuah Khan , Mark Brown , Marius Cristea , Marcus Folkesson , Kent Gustavsson , linux-iio@vger.kernel.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org, Janani Sunil , linux-spi@vger.kernel.org, Kent Gustavsson Subject: Re: [PATCH v7 1/7] spi: dt-bindings: Add spi-device-addr peripheral property Message-ID: <20260729234733.6b092a00@jic23-huawei> In-Reply-To: <163c9872-17ef-4b01-9392-96e896c284b8@baylibre.com> References: <20260722-ad5529r-driver-v7-0-7781cd74ad75@analog.com> <20260722-ad5529r-driver-v7-1-7781cd74ad75@analog.com> <20260725230445.60a445a0@jic23-huawei> <20260728-barrette-rickety-788b47da503c@spud> <20260728220544.5c65bc50@jic23-huawei> <163c9872-17ef-4b01-9392-96e896c284b8@baylibre.com> X-Mailer: Claws Mail 4.4.0 (GTK 3.24.52; x86_64-pc-linux-gnu) Precedence: bulk X-Mailing-List: devicetree@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit On Tue, 28 Jul 2026 16:46:26 -0500 David Lechner wrote: > On 7/28/26 4:05 PM, Jonathan Cameron wrote: > > On Tue, 28 Jul 2026 13:39:20 -0500 > > David Lechner 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 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 > >>>>>> --- > >>>>>> 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 > > > >> > >> > > >