Re: [PATCH 3/6] iio: adc: adi-axi-adc: Add support for CRC

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:

New issues:
- [Medium] Incomplete implementation: missing `crc_enable` and `crc_disable` callbacks in AD485X and AD408X specific operations structures.

Pre-existing issues:
- [High] The mutex `st->lock` is never initialized in the driver's probe function.
--

--- Patch [3]: [PATCH 3/6] iio: adc: adi-axi-adc: Add support for CRC ---
commit c99754ea278319045472336d04b62842c05a3731
Author: Janani Sunil <janani.sunil@analog.com>

iio: adc: adi-axi-adc: Add support for CRC

Add support for enabling and disabling Cyclic Redundancy Check (CRC)
processing in the AXI ADC backend. CRC provides data integrity verification
for high-speed ADC data streams, ensuring reliable data transfer between
the ADC frontend and backend processing systems.

> diff --git a/drivers/iio/adc/adi-axi-adc.c b/drivers/iio/adc/adi-axi-adc.c
> index 26b9c75bd4d8e..8af42d26aac08 100644
> --- a/drivers/iio/adc/adi-axi-adc.c
> +++ b/drivers/iio/adc/adi-axi-adc.c

[ ... ]

> @@ -615,6 +633,8 @@ static const struct iio_backend_ops adi_axi_adc_ops = {
>  	.num_lanes_set = axi_adc_num_lanes_set,
>  	.debugfs_reg_access = iio_backend_debugfs_ptr(axi_adc_reg_access),
>  	.debugfs_print_chan_status = iio_backend_debugfs_ptr(axi_adc_debugfs_print_chan_status),
> +	.crc_enable = axi_adc_crc_enable,
> +	.crc_disable = axi_adc_crc_disable,
>  };

[Severity: Medium]
Did this patch introduce a regression where AD485X and AD408X backend
operations are missing the new CRC callbacks?

If a frontend driver for AD485X or AD408X tries to enable CRC via
iio_backend_crc_enable(), it will return -EOPNOTSUPP because the
callbacks are missing in their respective structures:

drivers/iio/adc/adi-axi-adc.c:
static const struct iio_backend_ops adi_ad485x_ops = {
	.enable = axi_adc_enable,
	...
	.debugfs_print_chan_status =
		iio_backend_debugfs_ptr(axi_adc_debugfs_print_chan_status),
	/* crc_enable and crc_disable are NULL */
};

Should adi_ad485x_ops and adi_ad408x_ops also be updated?

[Severity: High]
This isn't a bug introduced by this patch, but I noticed the mutex
st->lock is never initialized during probe:

drivers/iio/adc/adi-axi-adc.c:adi_axi_adc_probe() {
	...
	st = devm_kzalloc(dev, sizeof(*st), GFP_KERNEL);
	if (!st)
		return -ENOMEM;
	...
}

Because devm_kzalloc only zero-initializes the memory, the internal
wait_list for st->lock is left uninitialized.

When concurrent access occurs and hits the mutex slow path, won't this
cause a kernel panic due to a NULL pointer dereference? Should a call to
devm_mutex_init() be added here?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260709-ad7768-driver-v1-0-44e1194fd96a@analog.com?part=3