linux-kernel - Re: [PATCH v5 02/14] dt-bindings: iio: adc: ad7768-1: add trigger-sources 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: <aABGfv+9KxEt5sAq@JSANTO12-L01.ad.analog.com>
Date: Wed, 16 Apr 2025 21:08:30 -0300
From: Jonathan Santos <jonath4nns@...il.com>
To: David Lechner <dlechner@...libre.com>
Cc: Jonathan Santos <Jonathan.Santos@...log.com>, linux-iio@...r.kernel.org,
	devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
	linux-gpio@...r.kernel.org, lars@...afoo.de,
	Michael.Hennerich@...log.com, marcelo.schmitt@...log.com,
	jic23@...nel.org, robh@...nel.org, krzk+dt@...nel.org,
	conor+dt@...nel.org, marcelo.schmitt1@...il.com,
	linus.walleij@...aro.org, brgl@...ev.pl, lgirdwood@...il.com,
	broonie@...nel.org
Subject: Re: [PATCH v5 02/14] dt-bindings: iio: adc: ad7768-1: add
 trigger-sources property

On 04/11, David Lechner wrote:
> On 4/11/25 10:56 AM, Jonathan Santos wrote:
> > In addition to GPIO synchronization, The AD7768-1 also supports
> > synchronization over SPI, which use is recommended when the GPIO
> > cannot provide a pulse synchronous with the base MCLK signal. It
> > consists of looping back the SYNC_OUT to the SYNC_IN pin and send
> > a command via SPI to trigger the synchronization.
> > 
> > Introduce the 'trigger-sources' property to support SPI-based
> > synchronization, along with additional optional entries for the SPI
> > offload trigger and the START signal via GPIO3.
> > 
> > While at it, add description to the interrupts property.
> > 
> > Signed-off-by: Jonathan Santos <Jonathan.Santos@...log.com>
> > ---
> > v5 Changes:
> > * Include START pin and DRDY in the trigger-sources description.
> > * Fixed "#trigger-source-cells" value and description.
> > * sync-in-gpios is represented in the trigger-sources property.
> > 
> > v4 Changes:
> > * none
> > 
> > v3 Changes:
> > * Fixed dt-bindings errors.
> > * Trigger-source is set as an alternative to sync-in-gpios, so we
> >   don't break the previous ABI.
> > * increased maxItems from trigger-sources to 2.
> > 
> > v2 Changes:
> > * Patch added as replacement for adi,sync-in-spi patch.
> > * addressed the request for a description to interrupts property.
> > ---
> >  .../bindings/iio/adc/adi,ad7768-1.yaml        | 38 +++++++++++++++++--
> >  1 file changed, 35 insertions(+), 3 deletions(-)
> > 
> > diff --git a/Documentation/devicetree/bindings/iio/adc/adi,ad7768-1.yaml b/Documentation/devicetree/bindings/iio/adc/adi,ad7768-1.yaml
> > index 3ce59d4d065f..4c58dbe8f749 100644
> > --- a/Documentation/devicetree/bindings/iio/adc/adi,ad7768-1.yaml
> > +++ b/Documentation/devicetree/bindings/iio/adc/adi,ad7768-1.yaml
> > @@ -26,7 +26,30 @@ properties:
> >    clock-names:
> >      const: mclk
> >  
> > +  trigger-sources:
> > +    $ref: /schemas/types.yaml#/definitions/phandle-array
> > +    minItems: 1
> > +    maxItems: 3
> > +    description: |
> > +      A list of phandles referencing trigger source devices or GPIOs.
> 
> I don't think a gpio phandle should be directly allowed. Only a trigger
> source provider (something with #trigger-source-cells).
> 

Sorry, I meant gpio-trigger, but I phrased it incorrectly.

> > +      Supports up to three entries, each representing a different type of
> > +      trigger:
> > +
> > +        - First entry specifies the device responsible for driving the
> > +          synchronization (SYNC_IN) pin, as an alternative to adi,sync-in-gpios.
> > +          This can be a `gpio-trigger` or another `ad7768-1` device. If the
> > +          device's own SYNC_OUT pin is internally connected to its SYNC_IN pin,
> > +          reference the device itself or omit this property.
> > +        - Second entry optionally defines a GPIO3 pin used as a START signal trigger.
> > +        - Third entry specifies a GPIO line to act as a trigger for SPI offload.
> 
> SPI offload is part of the SPI controller, not the ADC chip, so doesn't
> make sense to have that binding here. In that case, the ADC is the
> trigger-source provider, not consumer.

Right! Maybe a silly question, but this means we would have then two trigger-sources 
defined, one in the spi controller node and other in the adc node, right? like
this:

spi_controller: spi@...00000 {
	...
	trigger-sources = <&offload_trigger_source>;
	...
	adc0@ {
	...
		trigger-sources = <&sync_trigger_source>;
		#trigger-source-cells = <1>;
	...
	}
}

> 
> 
>