linux-kernel - Re: [PATCH v3 7/7] dt-bindings: iio: adc: adi,ad4030: add data-lanes property

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <0cf78f84-01e7-4507-abf9-2f82f98206b2@baylibre.com>
Date: Fri, 5 Dec 2025 15:33:49 -0600
From: David Lechner <dlechner@...libre.com>
To: Marcelo Schmitt <marcelo.schmitt1@...il.com>,
 Rob Herring <robh@...nel.org>
Cc: Mark Brown <broonie@...nel.org>, Krzysztof Kozlowski
 <krzk+dt@...nel.org>, Conor Dooley <conor+dt@...nel.org>,
 Marcelo Schmitt <marcelo.schmitt@...log.com>,
 Michael Hennerich <michael.hennerich@...log.com>,
 Nuno Sá <nuno.sa@...log.com>,
 Jonathan Cameron <jic23@...nel.org>, Andy Shevchenko <andy@...nel.org>,
 Sean Anderson <sean.anderson@...ux.dev>, linux-spi@...r.kernel.org,
 devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
 linux-iio@...r.kernel.org
Subject: Re: [PATCH v3 7/7] dt-bindings: iio: adc: adi,ad4030: add data-lanes
 property

On 12/5/25 3:12 PM, Marcelo Schmitt wrote:
> On 12/04, Rob Herring wrote:
>> On Mon, Dec 01, 2025 at 08:20:45PM -0600, David Lechner wrote:
>>> Add data-lanes property to specify the number of data lanes used on the
>>> ad463x chips that support reading two samples at the same time using
>>> two data lanes with a capable SPI controller.
>>>
>>> Signed-off-by: David Lechner <dlechner@...libre.com>
>>> ---
>>> v3 changes: new patch
>>>
>>> I added this one to give a real-world use case where spi-rx-bus-width
>>> was not sufficient to fully describe the hardware configuration.
>>>
>>> spi-rx-bus-width = <4>; alone could be be interpreted as either:
>>>
>>> +--------------+    +----------+
>>> | SPI          |    | AD4630   |
>>> | Controller   |    | ADC      |
>>> |              |    |          |
>>> |        SDIA0 |<---| SDOA0    |
>>> |        SDIA1 |<---| SDOA1    |
>>> |        SDIA2 |<---| SDOA2    |
>>> |        SDIA3 |<---| SDOA3    |
>>> |              |    |          |
>>> |        SDIB0 |x   | SDOB0    |
>>> |        SDIB1 |x   | SDOB1    |
>>> |        SDIB2 |x   | SDOB2    |
>>> |        SDIB3 |x   | SDOB3    |
>>> |              |    |          |
>>> +--------------+     +---------+
>>>
>>> or
>>>
>>> +--------------+    +----------+
>>> | SPI          |    | AD4630   |
>>> | Controller   |    | ADC      |
>>> |              |    |          |
>>> |        SDIA0 |<---| SDOA0    |
>>> |        SDIA1 |<---| SDOA1    |
>>> |        SDIA2 |x   | SDOA2    |
>>> |        SDIA3 |x   | SDOA3    |
>>> |              |    |          |
>>> |        SDIB0 |<---| SDOB0    |
>>> |        SDIB1 |<---| SDOB1    |
>>> |        SDIB2 |x   | SDOB2    |
>>> |        SDIB3 |x   | SDOB3    |
>>> |              |    |          |
>>> +--------------+     +---------+
>>>
>>> Now, with data-lanes having a default value of [0] (inherited from
>>> spi-peripheral-props.yaml), specifying:
>>>
>>>     spi-rx-bus-width = <4>;
>>>
>>> is unambiguously the first case and the example given in the binding
>>> documentation is the second case:
>>>
>>>     spi-rx-bus-width = <2>;
>>>     data-lanes = <0>, <1>;
>>
>> I just reviewed this and all, but what if you just did:
>>
>> spi-rx-bus-width = <2>, <2>;
>>
>> So *-bus-width becomes equal to the number of serializers/channels.
> 
> Unless I'm missing something, I think that would also describe the currently
> possible use cases as well. To me, it actually seems even more accurate than
> data-lanes. The data-lanes property only describes the SPI controller input
> lines/lanes, no info is given about the output lanes.

It describes both directions.

> Well yeah, that would only> be a problem for a device with multiple input serializers and multiple output
> serializers. Still, the *-bus-width = <N>, <N>, ... <N>; notation looks clearer,
> IMHO.
> 
>>
>> Rob
>>

It think it complicates Sean's use case though where such
a controller is being used as basically two separate SPI
buses.

For that case, we want to be able to do:

spi {
	...

	thing@0 {
		compatible = ...;
		reg = <0>;
		/* (implicit) data-lanes = <0>; */
	};

	thing@1 {
		compatible = ...;
		reg = <1>;
		data-lanes = <1>;
	};
};

Meaning:

+--------------+    +----------+
| SPI          |    | Thing 1  |
| Controller   |    |          |
|              |    |          |
|          CS0 |--->| CS       |
|         SDI0 |<---| SDO      |
|         SDO0 |--->| SDI      |
|        SCLK0 |--->| SCLK     |
|              |    |          |
|              |    +----------+
|              |                
|              |    +----------+
|              |    | Thing 2  |
|              |    |          |
|          CS1 |--->| CS       |
|         SDI1 |<---| SDO      |
|         SDO1 |--->| SDI      |
|        SCLK1 |--->| SCLK     |
|              |    |          |
+--------------+    +----------+

(I don't remember if SCLKs are shared or separate, but I don't
think that is relevant anyway).


I guess we could write it like this?

spi {
	...

	thing@0 {
		compatible = ...;
		reg = <0>;
	};

	thing@1 {
		compatible = ...;
		reg = <1>;
		spi-tx-bus-width = <0>, <1>;
		spi-rx-bus-width = <0>, <1>;
	};
};