linux-kernel - Re: [PATCH v9 09/12] iio: adc: ad7768-1: add support for Synchronization over SPI

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 for Android: free password hash cracker in your pocket

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

Message-ID: <20250531184242.468e9e27@jic23-huawei>
Date: Sat, 31 May 2025 18:42:42 +0100
From: Jonathan Cameron <jic23@...nel.org>
To: Andy Shevchenko <andy@...nel.org>
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, linux-acpi@...r.kernel.org, nuno.sa@...log.com,
 Michael.Hennerich@...log.com, marcelo.schmitt@...log.com, 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, jonath4nns@...il.com, dlechner@...libre.com,
 rafael@...nel.org, djrscally@...il.com
Subject: Re: [PATCH v9 09/12] iio: adc: ad7768-1: add support for
 Synchronization over SPI

On Fri, 30 May 2025 20:45:32 +0300
Andy Shevchenko <andy@...nel.org> wrote:

> On Thu, May 29, 2025 at 07:50:29PM -0300, Jonathan Santos wrote:
> > The synchronization method using GPIO requires the generated pulse to be
> > truly synchronous with the base MCLK signal. When it is not possible to
> > do that in hardware, the datasheet recommends using synchronization over
> > SPI, where the generated pulse is already synchronous with MCLK. This
> > requires the SYNC_OUT pin to be connected to the SYNC_IN pin.
> > 
> > Use trigger-sources property to enable device synchronization over SPI
> > and multi-device synchronization while replacing sync-in-gpios property.  
> 
> ...
> 
> > struct ad7768_state {  
> 
> >  	struct iio_trigger *trig;
> >  	struct gpio_desc *gpio_sync_in;
> >  	struct gpio_desc *gpio_reset;  
> 
> > +	bool en_spi_sync;  
> 
> I'm wondering if moving this...
> 
> >  	const char *labels[ARRAY_SIZE(ad7768_channels)];
> >  	struct gpio_chip gpiochip;  
> 
> ...to here saves a few bytes in accordance to `pahole`.
> 
> >  };  
> 
> ...
> 
> > +static int ad7768_trigger_sources_sync_setup(struct device *dev,
> > +					     struct fwnode_handle *dev_fwnode,
> > +					     struct ad7768_state *st)
> > +{
> > +	struct fwnode_reference_args args;
> > +
> > +	struct fwnode_handle *fwnode __free(fwnode_handle) =
> > +		fwnode_find_reference_args(dev_fwnode, "trigger-sources",
> > +					   "#trigger-source-cells", 0,
> > +					   AD7768_TRIGGER_SOURCE_SYNC_IDX, &args);  
> 
> I don't see how args are being used. This puts in doubt the need of the first
> patch.

That did get discussed (more context needed in the commit message for patch 1).
I wasn't happy with ignoring #trigger-source-cells which is required in the
binding but here is known to be 0.

If it was larger than 0 but we didn't care about the arguments I believe
we'd still need to use this call to take the right stride through the
data array that this is coming from.
Ultimately I think that is this bit of code establishing the end of the phandle.
https://elixir.bootlin.com/linux/v6.15/source/drivers/of/base.c#L1300

I might have gotten it wrong how this all works though!

J