linux-kernel - Re: [PATCH v1 14/15] 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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <Z4W9j9/UNOMnHtFK@JSANTO12-L01.ad.analog.com>
Date: Mon, 13 Jan 2025 22:27:43 -0300
From: Jonathan Santos <jonath4nns@...il.com>
To: Jonathan Cameron <jic23@...nel.org>
Cc: David Lechner <dlechner@...libre.com>,
	Jonathan Santos <Jonathan.Santos@...log.com>,
	linux-iio@...r.kernel.org, devicetree@...r.kernel.org,
	linux-kernel@...r.kernel.org, lars@...afoo.de,
	Michael.Hennerich@...log.com, robh@...nel.org, krzk+dt@...nel.org,
	conor+dt@...nel.org, marcelo.schmitt1@...il.com
Subject: Re: [PATCH v1 14/15] iio: adc: ad7768-1: add support for
 Synchronization over SPI

On 01/12, Jonathan Cameron wrote:
> On Tue, 7 Jan 2025 17:50:29 -0600
> David Lechner <dlechner@...libre.com> wrote:
> 
> > On 1/7/25 9:27 AM, 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 SYNC_IN pin.
> > > 
> > > Add the option to handle device synchronization over SPI.
> > > 
> > > Signed-off-by: Jonathan Santos <Jonathan.Santos@...log.com>
> > > ---  
> > 
> > ...
> > 
> > >  static int ad7768_gpio_direction_input(struct gpio_chip *chip, unsigned int offset)
> > > @@ -697,11 +708,21 @@ static int ad7768_setup(struct ad7768_state *st)
> > >  	if (ret)
> > >  		return ret;
> > >  
> > > -	st->gpio_sync_in = devm_gpiod_get(&st->spi->dev, "adi,sync-in",
> > > -					  GPIOD_OUT_LOW);
> > > +	st->gpio_sync_in = devm_gpiod_get_optional(&st->spi->dev, "adi,sync-in",
> > > +						   GPIOD_OUT_LOW);
> > >  	if (IS_ERR(st->gpio_sync_in))
> > >  		return PTR_ERR(st->gpio_sync_in);
> > >  
> > > +	if (device_property_present(&st->spi->dev, "adi,sync-in-spi"))
> > > +		st->en_spi_sync = true;
> > > +
> > > +	/*
> > > +	 * GPIO and SPI Synchronization are mutually exclusive.
> > > +	 * Return error if both are enabled  
> > 
> > Should it also be an error if we have neither? Otherwise it sounds like
> > decimation won't work correctly since there is a comment that says we have
> > to toggle this after updating the decimation rate register.
> 
> I'm not quite sure how this interacts with potential future support
> for daisy chaining but for now, if we have no GPIO specified why can't
> we assume spi sync is the way to go?
> 
> If no GPIO is provided and for a single device SYNC_OUT is not wired
> to SYNC_IN I think the board is broken anyway and we don't have to care.
> 
> Jonathan
> 

I also think it is safe to assume the spi sync if we don't have the GPIO
defined. For Daisy chaining it would be as problem if we decided for
multiple instances in case of multiple devices. With the single device
approach it still works.

> > 
> > > +	 */
> > > +	if (st->gpio_sync_in && st->en_spi_sync)
> > > +		return -EINVAL;  
> > 
> > A dev_err_probe() message would be helpful here when creating a new DT and
> > bringing up a new system since it is easy to forget a property or make a typo
> > that could lead to this error.
> > 
> > > +
> > >  	ret = ad7768_gpio_init(st);
> > >  	if (ret < 0)
> > >  		return ret;  
> > 
> > 
>