Re: [PATCH v8 10/17] iio: frequency: ad9910: initial driver implementation

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
- [Medium] State check in `ad9910_sw_powerdown_set` masks partial hardware failures.
- [Medium] Software state `st->data.output_current_uA` is updated before hardware write and not reverted on error.
- [Medium] The `adi,refclk-out-drive-strength` property is ignored if the PLL is disabled, preventing valid hardware configurations.
--

--- Patch [10]: [PATCH v8 10/17] iio: frequency: ad9910: initial driver implementation ---
commit fa8ede19ae75d86e6b54bd272809bde5cbcf3f66
Author: Rodrigo Alencar <rodrigo.alencar@analog.com>
Subject: iio: frequency: ad9910: initial driver implementation

Add the core AD9910 DDS driver infrastructure with single tone mode support.
This includes SPI register access, profile management via GPIO pins, PLL/DAC
configuration from firmware properties, and single tone frequency/phase/amplitude
control through IIO attributes.

> diff --git a/drivers/iio/frequency/ad9910.c b/drivers/iio/frequency/ad9910.c
> new file mode 100644
> index 0000000000000..b41b011af2812
> --- /dev/null
> +++ b/drivers/iio/frequency/ad9910.c

[ ... ]

> +static int ad9910_set_dac_current(struct ad9910_state *st, u32 val_uA,
> +				  bool update)
> +{
> +	u32 code;
> +
> +	/* FSC = (86.4 / Rset) * (1 + CODE/96) where Rset = 10k ohms */
> +	val_uA = clamp(val_uA, AD9910_DAC_IOUT_MIN_uA, AD9910_DAC_IOUT_MAX_uA);
> +	code = DIV_ROUND_CLOSEST(val_uA - AD9910_DAC_IOUT_MIN_uA, 90);
> +	st->data.output_current_uA = AD9910_DAC_IOUT_MIN_uA + code * 90;

[Severity: Medium]
If ad9910_reg32_write() fails due to an SPI error, the hardware state isn't
updated. However, since st->data.output_current_uA was already modified, won't
subsequent reads (e.g., IIO_CHAN_INFO_SCALE) return this cached value instead
of the actual hardware configuration?

> +
> +	return ad9910_reg32_write(st, AD9910_REG_AUX_DAC, code, update);
> +}

[ ... ]

> +static inline bool ad9910_sw_powerdown_get(struct ad9910_state *st)
> +{
> +	return FIELD_GET(AD9910_CFR1_SW_POWER_DOWN_MSK,
> +			 st->reg[AD9910_REG_CFR1].val32) ? true : false;
> +}
> +
> +static int ad9910_sw_powerdown_set(struct ad9910_state *st, bool enable)
> +{
> +	int ret;
> +
> +	if (ad9910_sw_powerdown_get(st) == enable)
> +		return 0;

[Severity: Medium]
If the previous powerdown sequence failed after writing SW1 but before writing
SW0 due to an SPI error, ad9910_sw_powerdown_get() will still return true
because one of the masked bits is set.

Will this early return prevent subsequent calls from attempting to recover and
complete the powerdown sequence?

> +
> +	/*
> +	 * When powering down, the DAC and AUX_DAC (SW1) must be powered down
> +	 * first, as they require an I/O update to take effect. The opposite is

[ ... ]

> +static int ad9910_parse_fw(struct ad9910_state *st)
> +{
> +	static const char * const refclk_out_drv0[] = {
> +		"disabled", "low", "medium", "high",
> +	};
> +	struct device *dev = &st->spi->dev;
> +	const char *prop;
> +	u32 tmp;
> +	int ret;
> +
> +	st->data.pll_enabled = device_property_read_bool(dev, "adi,pll-enable");
> +	if (st->data.pll_enabled) {
> +		prop = "adi,charge-pump-current-microamp";
> +		if (device_property_present(dev, prop)) {
> +			ret = device_property_read_u32(dev, prop, &tmp);
> +			if (ret)
> +				return dev_err_probe(dev, ret, "property read: %s\n", prop);
> +
> +			if (tmp < AD9910_ICP_MIN_uA || tmp > AD9910_ICP_MAX_uA)
> +				return dev_err_probe(dev, -ERANGE,
> +						     "invalid charge pump current %u\n", tmp);
> +		} else {
> +			tmp = AD9910_ICP_MIN_uA;
> +		}
> +		st->data.pll_charge_pump_current = tmp;
> +
> +		prop = "adi,refclk-out-drive-strength";
> +		if (device_property_present(dev, prop)) {

[Severity: Medium]
Is it intentional that adi,refclk-out-drive-strength is only parsed when the
PLL is enabled? 

The hardware appears to support routing and buffering the reference clock
output regardless of whether the internal PLL is enabled. If a device tree
omits adi,pll-enable but provides adi,refclk-out-drive-strength, won't this
property be ignored entirely?

> +			ret = device_property_match_property_string(dev, prop,
> +								    refclk_out_drv0,
> +								    ARRAY_SIZE(refclk_out_drv0));

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260714-ad9910-iio-driver-v8-0-36939c3c07d2@analog.com?part=10