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] [day] [month] [year] [list]
Message-ID: <a5729091-af6f-4549-8cda-ca2778346437@baylibre.com>
Date: Thu, 17 Apr 2025 10:11:40 -0500
From: David Lechner <dlechner@...libre.com>
To: 938b950b-4215-4358-a888-6f6c9aab48e8@...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 4/16/25 7:08 PM, Jonathan Santos wrote:
> 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>
>>> ---

...

>>> +      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>;
> 	...
> 	}
> }

Yes, this looks correct. And for the case of SYNC_OUT connected to SYNC_IN on
the ADC itself, we could omit trigger-sources = <&sync_trigger_source>;.


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ