Message-ID: <97a2aebb-f707-4f88-be5f-d86bd795c65a@baylibre.com>
Date: Fri, 11 Apr 2025 17:48:57 -0500
From: David Lechner <dlechner@...libre.com>
To: 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
Cc: 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, jonath4nns@...il.com
Subject: Re: [PATCH v5 11/14] iio: adc: ad7768-1: add support for
 Synchronization over SPI

On 4/11/25 10:58 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.
> 
> Use trigger-sources property to enable device synchronization over SPI
> and to replace sync-in-gpios property for a gpio-trigger node.
> 
> Signed-off-by: Jonathan Santos <Jonathan.Santos@...log.com>
> ---
> v5 Changes:
> * Allow omitting trigger-sources property.

I didn't see this possibility mentioned in the dt-bindings patch. Maybe I missed
something?

> * include gpio-trigger to trigger-sources to replace adi,sync-in-gpios
>   property.
> * Read trigger-sources cell value to differentiate the trigger type.
> 

...

>  drivers/iio/adc/ad7768-1.c | 100 ++++++++++++++++++++++++++++++++++---
>  1 file changed, 92 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/iio/adc/ad7768-1.c b/drivers/iio/adc/ad7768-1.c
> index 179806f821be..aa60c55afd24 100644
> --- a/drivers/iio/adc/ad7768-1.c
> +++ b/drivers/iio/adc/ad7768-1.c
> @@ -100,6 +100,11 @@
>  
>  #define AD7768_VCM_OFF			0x07
>  
> +enum ad7768_trigger_type {
> +	AD7768_TRIGGER_TYPE_GPIO,
> +	AD7768_TRIGGER_TYPE_DEV
> +};

I assume this is supposed to correspond to the #trigger-source-cells argument?
It would make sense to put this in a dt-bindings/iio/adc/adi,ad7768-1.h file
in the dt-bindings patch so that it can also be used in .dts files.

> +static int ad7768_set_sync_source(struct device *dev, struct ad7768_state *st)
> +{
> +	struct fwnode_reference_args args;
> +	struct fwnode_handle *fwnode = NULL;
> +	const char *value;
> +	int trigger_type, ret;
> +
> +	/*
> +	 * The AD7768-1 allows two primary methods for driving the SYNC_IN pin
> +	 * to synchronize one or more devices:
> +	 * 1. Using a GPIO to directly drive the SYNC_IN pin.
> +	 * 2. Using a SPI command, where the SYNC_OUT pin generates a
> +	 *    synchronization pulse that loops back to the SYNC_IN pin.
> +	 */
> +	ret = fwnode_property_get_reference_args(dev_fwnode(dev),
> +						 "trigger-sources",
> +						 "#trigger-source-cells",
> +						 0, 0, &args);

Since we have more than one possible trigger-source index, it could be helpful
to create macros or an enum instead of hard-coding 0 here for the index arg.

> +	if (ret) {

This ignores errors other than the property just being missing. Probably better
would be to use device_property_present() first for this check then call
fwnode_property_get_reference_args() later and return any error.

> +		/*
> +		 * In the absence of trigger-sources property, enable self
> +		 * synchronziation via SPI command.

s/synchronziation/synchronization/

> +		 */
> +		st->en_spi_sync = true;
> +		return 0;
> +	}
> +
> +	trigger_type = args.args[0];

This is accessing args.args without checking args.nargs, so could be reading
out of bounds.

Also, we need to inspect args.fwnode first to see what type of trigger it is
since the meaning of the args will depend on the compatible string of
args.fwnode. The "gpio-trigger" has #trigger-source-cells = <0>; so this really
would be reading uninitialized memory.

> +	fwnode = args.fwnode;
> +	if (!fwnode)
> +		return dev_err_probe(dev, -ENOENT,
> +				     "Invalid or missing fwnode in 'trigger-sources'\n");

Is it really possible for this to happen without an error being returned by
fwnode_property_get_reference_args()?

> +
> +	switch (trigger_type) {
> +	case AD7768_TRIGGER_TYPE_GPIO:

As mentioned in the dt-bindings review, this isn't a valid value. We should
just check the compatible string directly.

> +		ret = fwnode_property_read_string(fwnode, "compatible", &value);
> +		if (ret)
> +			goto out_put_node;
> +
> +		if (strcmp("gpio-trigger", value))
> +			goto err_not_supp;

Ideally we would have a trigger subsystem where we could just call a
devm_trigger_source_get_gpio() function instead of this. But that is a bit
beyond the scope of this patch series. :-)

> +
> +		st->gpio_sync_in = fwnode_gpiod_get_index(fwnode, NULL, 0,

Should be devm_fwnode_gpiod_get_index() so that the gpiod is released on driver
removal.

> +							  GPIOD_OUT_LOW,
> +							  "sync-in");
> +		if (IS_ERR(st->gpio_sync_in))
> +			ret = PTR_ERR(st->gpio_sync_in);
> +
> +		goto out_put_node;
> +	case AD7768_TRIGGER_TYPE_DEV:

As mentioned in the dt-bindings review, this isn't a valid value. We can just
check fwnode->dev directly earlier in this function. Then it is only safe
to do trigger_type = args.args[0]; after that. And we should be checking that
trigger_type is SYNC_OUT since that is the only supported self trigger for now.

> +		/* Only self synchronization is supported for now */
> +		if (fwnode->dev == dev) {
> +			st->en_spi_sync = true;
> +			goto out_put_node;
> +		}
> +
> +		goto err_not_supp;
> +	default:
> +		goto err_not_supp;
> +	}
> +
> +err_not_supp:
> +	ret = -EOPNOTSUPP;
> +	dev_err(dev, "Trigger-sources type not supported\n");
> +out_put_node:
> +	fwnode_handle_put(args.fwnode);
> +	return ret;
> +}
> +
>  static int ad7768_setup(struct iio_dev *indio_dev)
>  {
>  	struct ad7768_state *st = iio_priv(indio_dev);
> @@ -699,10 +784,9 @@ static int ad7768_setup(struct iio_dev *indio_dev)
>  			return ret;
>  	}
>  
> -	st->gpio_sync_in = devm_gpiod_get(&st->spi->dev, "adi,sync-in",

I don't see where this function is moved to. If we remove it, wouldn't that
break existing users depending on it? We can't expect everyone to update their
devicetree to the new bindings.

We could change it to devm_gpiod_get_optional() instead and only call
ad7768_set_sync_source() if (!st->gpio_sync_in).

> -					  GPIOD_OUT_LOW);
> -	if (IS_ERR(st->gpio_sync_in))
> -		return PTR_ERR(st->gpio_sync_in);
> +	ret = ad7768_set_sync_source(&st->spi->dev, st);
> +	if (ret)
> +		return ret;
>  
>  	/* Only create a Chip GPIO if flagged for it */
>  	if (device_property_read_bool(&st->spi->dev, "gpio-controller")) {

Powered by blists - more mailing lists