linux-kernel - Re: [PATCH v2 2/2] iio: dac: Add MAX22007 DAC driver support

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] [day] [month] [year] [list]
Message-ID: <20260112202610.350223da@jic23-huawei>
Date: Mon, 12 Jan 2026 20:26:10 +0000
From: Jonathan Cameron <jic23@...nel.org>
To: Janani Sunil <janani.sunil@...log.com>
Cc: Lars-Peter Clausen <lars@...afoo.de>, Michael Hennerich
 <Michael.Hennerich@...log.com>, Alexandru Ardelean
 <alexandru.ardelean@...log.com>, "Rob Herring" <robh@...nel.org>, Krzysztof
 Kozlowski <krzk+dt@...nel.org>, "Conor Dooley" <conor+dt@...nel.org>,
 Jonathan Corbet <corbet@....net>, <linux-iio@...r.kernel.org>,
 <devicetree@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
 <linux-doc@...r.kernel.org>, <jan.sun97@...il.com>
Subject: Re: [PATCH v2 2/2] iio: dac: Add MAX22007 DAC driver support

On Thu, 8 Jan 2026 13:58:24 +0100
Janani Sunil <janani.sunil@...log.com> wrote:

> Add support for the MAX22007, a 4-channel 12-bit DAC that drives
> voltage or current output on each channel.
> 
> Signed-off-by: Janani Sunil <janani.sunil@...log.com>
> diff --git a/drivers/iio/dac/max22007.c b/drivers/iio/dac/max22007.c
> new file mode 100644
> index 000000000000..19557c008554
> --- /dev/null
> +++ b/drivers/iio/dac/max22007.c
> @@ -0,0 +1,507 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * max22007.c - MAX22007 DAC driver
> + *
> + * Driver for Analog Devices MAX22007 Digital to Analog Converter.
> + *
> + * Copyright (c) 2026 Analog Devices Inc.
> + */
> +
> +#include <linux/bitfield.h>
> +#include <linux/bits.h>
> +#include <linux/crc8.h>
> +#include <linux/dev_printk.h>
> +#include <linux/device.h>
> +#include <linux/err.h>
> +#include <linux/errno.h>
> +#include <linux/gpio/consumer.h>
> +#include <linux/iio/iio.h>
> +#include <linux/mod_devicetable.h>
> +#include <linux/module.h>
> +#include <linux/property.h>
> +#include <linux/regmap.h>
> +#include <linux/regulator/consumer.h>
> +#include <linux/slab.h>
> +#include <linux/spi/spi.h>
> +#include <linux/string.h>
> +#include <linux/types.h>
> +#include <linux/unaligned.h>

Hi.

I decided to use your driver (well v1 actually but comments still apply)
to mess around with https://github.com/masoncl/review-prompts (I'm trying to see
if it is worth the effort!) and I queried if the includes were correct.
(rather than running IWYU directly). 

It correctly noted:

The driver has 2 missing includes and 1 unnecessary include:

  // Should ADD:
  #include <linux/kstrtox.h>    // for kstrtobool()
  #include <linux/sysfs.h>      // for sysfs_emit()

  // Should REMOVE:
  #include <linux/unaligned.h>  // not used

Now I keep mean to start running IWYU against commits at time
of merge but it's enough of a pain that I don't do it when just
reviewing.

Interestingly, claude argued itself out of reporting a bug around the reset
in v1 (which is now fixed)

For fun I asked it what smatch would have reported... See below.


> +static int max22007_spi_read(void *context, const void *reg, size_t reg_size,
> +			     void *val, size_t val_size)
> +{
> +	struct max22007_state *st = context;
> +	u8 reg_byte = *(u8 *)reg;
> +	u8 calculated_crc, received_crc;
> +	u8 crc_data[3];
> +	u8 rx_buf[4];
> +	int ret;
> +
> +	if (reg_size != 1)
One from claude that I think is sensible, if not a bug.
Should sanity check val_size as well.

> +		return -EINVAL;
> +
> +	ret = spi_write_then_read(st->spi, &reg_byte, 1, rx_buf,
> +				  val_size + MAX22007_CRC_OVERHEAD);
> +	if (ret) {
> +		dev_err(&st->spi->dev, "SPI transfer failed: %d\n", ret);
> +		return ret;
> +	}
> +
> +	crc_data[0] = reg_byte;
> +	crc_data[1] = rx_buf[0];
> +	crc_data[2] = rx_buf[1];
> +
> +	calculated_crc = crc8(max22007_crc8_table, crc_data, 3, 0x00);
> +	received_crc = rx_buf[val_size];
> +
> +	if (calculated_crc != received_crc) {
> +		dev_err(&st->spi->dev, "CRC mismatch on read register %02x\n", reg_byte);
> +		return -EIO;
> +	}
> +
> +	memcpy(val, rx_buf, val_size);
> +
> +	return 0;
> +}
> +
> +static int max22007_spi_write(void *context, const void *data, size_t count)
> +{
> +	struct max22007_state *st = context;
> +	struct spi_transfer xfer = {
> +		.tx_buf = st->tx_buf,
> +		.rx_buf = st->rx_buf,
> +	};
Similarly claude reported a false positive here but it seems sensible to
cover it:  Check the size of count is <= ARRAY_SIZE(st->tx_buf) - 1;

> +
> +	memset(st->tx_buf, 0, sizeof(st->tx_buf));
> +
> +	xfer.len = count + MAX22007_CRC_OVERHEAD;
> +
> +	memcpy(st->tx_buf, data, count);
> +	st->tx_buf[count] = crc8(max22007_crc8_table, st->tx_buf,
> +				 sizeof(st->tx_buf) - 1, 0x00);
> +
> +	return spi_sync_transfer(st->spi, &xfer, 1);
> +}

...

> +
> +static int max22007_write_channel_data(struct max22007_state *state,
> +				       unsigned int channel, unsigned int data)
Another one Claude raised that I think is worth cleaning up though not technically
a bug.  This is passed int val at the caller as the data parameter here.
I'd keep that as an int and then add a check on it being positive below.

Wrap around means any negative would end up as a big positive and fail the test
below (I think anyway) but we can make the check more obvious!

> +{
> +	unsigned int reg_val;
> +
> +	if (data > MAX22007_DAC_MAX_RAW)
> +		return -EINVAL;
> +
> +	reg_val = FIELD_PREP(MAX22007_DAC_DATA_MASK, data);
> +
> +	return regmap_write(state->regmap, MAX22007_DAC_CHANNEL_REG(channel), reg_val);
> +}
>