iio: adc: Add initial driver support for MAX22531 #2854

KernelShinobi · 2025-07-15T21:12:26Z

MAX22531 is a galvanically isolated, field-side self-powered, 4-channel, multiplexed, 12-bit ADC.

PR Description

Basic IIO ADC max22531 driver features:

Definitions for register addresses and useful constants (if any).
Definitions for the IIO channels.
A device state struct.
A read_raw function implementation (may be just a mock for now).
An iio_info struct populated with a reference to the read_raw function.
A probe function to initialize and setup the device.
SPI and device tree MODULE_DEVICE_TABLEs

PR Type

New feature (a change that adds new functionality)

PR Checklist

I have conducted a self-review of my own code changes
I could not test the DT overlay and/or the driver probing. However, I have compiled it on my machine and used static tools to ensure the code is okay.

Signed-off-by: Abhinav Jain <[email protected]>

machschmitt

Hi @KernelShinobi , a few comments about this initial driver version.
Note that, aside from the comments above, there are still some improvements that need to be made to make this driver usable (e.g. read ADC sample data, provide scale to convert output codes to mV). Those features shall be implemented next. Though, overall, this looks good to me as an initial driver version.

machschmitt · 2025-07-17T05:02:55Z

arch/arm/boot/dts/overlays/rpi-max22531-overlay.dts

+/plugin/;
+
+/ {
+	compatible = "brcm,bcm2835-spi", "brcm,bcm2711";


You may need to add brcm,bcm2712 to this list to actually indicate this overlay is compatible with rpi5.

- compatible = "brcm,bcm2835-spi", "brcm,bcm2711"; + compatible = "brcm,bcm2712", "brcm,bcm2835-spi", "brcm,bcm2711";

machschmitt · 2025-07-17T05:10:06Z

arch/arm/boot/dts/overlays/rpi-max22531-overlay.dts

+	max22531@0 {
+		compatible = "maxim,max22531";
+		reg = <0>;	/* Using CS0 on spi0 */
+		spi-max-frequency = <10000000>;


10 MHz is relatively fast for a rpi SPI controller. If you observe transfers bringing strange results or failing when you receive the hw, then consider decreasing the SPI clock frequency.

Ack, will drop to 5 MHz.

machschmitt · 2025-07-17T05:13:51Z

drivers/iio/adc/Kconfig

+        tristate "Analog Devices MAX22531 ADC Driver"
+        depends on SPI
+        help
+          Say yes here to build support for this driver.


Not a thing crucial for the moment, but I'd add the usual config help text boilerplate here. Upstream folks may request it, and there's nothing preventing us from adding a few more lines of text here.

machschmitt · 2025-07-17T05:15:53Z

drivers/iio/adc/max22531.c

+		.info_mask_separate = BIT(IIO_CHAN_INFO_RAW),		\
+		.info_mask_shared_by_type = BIT(IIO_CHAN_INFO_SCALE),	\
+		.scan_index = ch,					\
+		.output = 0,						\


not needed

- .output = 0, \

machschmitt · 2025-07-17T05:17:57Z

drivers/iio/adc/max22531.c

+	MAX22531_CHANNEL(1),
+	MAX22531_CHANNEL(2),
+	MAX22531_CHANNEL(3),
+	IIO_CHAN_SOFT_TIMESTAMP(2),


Let's leave the timestamp channel for after buffer support is implemented. Timestamp channels are not very useful on their own.

machschmitt · 2025-07-17T05:53:16Z

drivers/iio/adc/max22531.c

+	adc = iio_priv(indio_dev);
+	adc->spi_dev = spi;
+
+	indio_dev->name = "max22531";


this can be better set according to the specific device (max22530, max22531, or max22532) if a chip_info struct is implemented. See https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/iio/adc/ad7124.c?h=v6.16-rc6#n196 for an example.

machschmitt · 2025-07-17T05:53:44Z

drivers/iio/adc/max22531.c

+}
+
+static const struct spi_device_id max22531_id[] = {
+	{ "max22531" },


provide entries for max22530, and max22532 too

machschmitt · 2025-07-17T05:54:48Z

drivers/iio/adc/max22531.c

+MODULE_DEVICE_TABLE(spi, max22531_id);
+
+static const struct of_device_id max22531_spi_of_id[] = {
+	{ .compatible = "adi,max22531" },


same here, add OF entries for matching with max22530 and max22532.

machschmitt · 2025-07-17T06:12:37Z

drivers/iio/adc/max22531.c

+	adc->vref = devm_regulator_get(&spi->dev, "vref");
+	if (IS_ERR(adc->vref))
+		dev_err(&spi->dev, "Failed to retrieve vref\n");
+
+	ret = regulator_enable(adc->vref);
+	if (ret)
+		return ret;


vref is an internal voltage reference that is always on/enabled. If I'm not missing anything, we can just use vref. E.g.

#define MAX22531_VREF_MV 1800

thus we don't need to keep a vref regulator field in struct max22351.
For regulators, the driver should request VDDL and VDDPL regulators, as those must be supplied to power the MAX22531 chip.

Ack, in case of VDDL and VDDPL, I am declaring VDDL as the external supply and pointing VDDPL’s supply to the same regulator as VDDL since it’s not a separate external rail. The data sheet lists VDDL as the REF SUPPLY for VDDPL under pin description.

https://www.analog.com/media/en/technical-documentation/data-sheets/max22530-max22532.pdf

in case of VDDL and VDDPL, I am declaring VDDL as the external supply and pointing VDDPL’s supply to the same regulator as VDDL since it’s not a separate external rail.

That may be reasonable for the device tree overlay if the eval board uses the same power supply for VDDL and VDDPL. Though, the diagram on page 11 (https://www.analog.com/media/en/technical-documentation/data-sheets/MAX22530EVKIT-MAX22531EVKIT.pdf) shows VDDL and VDDPL being supplied with different sources.

The data sheet lists VDDL as the REF SUPPLY for VDDPL under pin description.

Hmm, that's strange. I didn't even notice that REF SUPPLY column until now. Still, I don't think VDDL supplies VDDPL. If we look at MAX22531 datasheet (link you provided above), we can see at page 14 that there are distinct pin descriptions for VDDL and VDDPL. Also, if we follow this logic of pins listed in the REF SUPPLY column to be voltage supplies, we would also have VDDF as a supply, which would not be correct since VDDF is an output.

At datasheet page 18 it is stated that:

The logic-side supply VDDPL powers an integrated, inductively coupled DC-DC converter that generates a
nominal field supply VDDF of 3.1V with just enough output current to power the field-side of the
MAX22530– MAX22532 family.

The Power Supply Decoupling section at page 24 treats both VDDL and VDDPL as power supplies. The diagram at page 36 shows both VDDL and VDDPL being provided with power supplies.

You are right, thank you for confirming. I will read more on what the REF SUPPLY column means. For now, I have submitted improvements based on your suggestions.

machschmitt · 2025-07-17T06:32:26Z

drivers/iio/adc/max22531.c

+};
+
+static const struct regmap_config regmap_config = {
+	.reg_bits = 16,


The SPI read/write commands (datasheet Table 1 and Table 2) have 8-bit header so we would have .reg_bits = 8 (or reg_bits = 6 maybe).
Though, the header also contains the W/R and burst bits.
I think the W/R can be handled with
.write_flag_mask = BIT(1)
the burst bit skipped with
.pad_bits = 1
See https://elixir.bootlin.com/linux/v6.15.6/source/include/linux/regmap.h#L254

jonathanns · 2025-07-17T12:42:49Z

drivers/iio/adc/max22531.c

+
+	adc->regmap = devm_regmap_init_spi(spi, &regmap_config);
+	if (IS_ERR(adc->regmap))
+		dev_err(&spi->dev, "regmap init failure\n");


Usually when something critical fails in the probe it is better to stop and return, like:
return dev_err_probe(&spi->dev, PTR_ERR(adc->regmap), "regmap init failure\n")

Same for other similar cases here.

machschmitt · 2025-07-27T21:01:45Z

Hello, so I've set up MAX2531_EVKIT_A and tested the initial MAX22531 driver version.

I've added "brcm,bcm2712" to device tree overlay compatible list and added another dev_info print at the end of driver probe.

Here's the result

@KernelShinobi , please, update the PR code according to the provided suggestions.

Despite the message printed to kernel logs, the MAX22531_REG_PROD_ID read is clearly not successful, as we should get 0x0001 from that register. As we talked about in a previous meeting, drop the regmap implementation and make direct use of SPI transfers to comply with the protocol described on datasheet page 19 correctly.

I'll test it again after you update the driver code and register access functions accordingly.

Improve initial DT Overlay for MAX22530-MAX22532. Add MAX22530-MAX22532 device tree documentation. Signed-off-by: Abhinav Jain <[email protected]>

Add device entries for MAX22530 and MAX22532. Retrieve logic and DC-DC power supplies post fixes in DT overlay. Add chip_info structure for the device. Fix regmap_config for SPI read/write commands as per the datasheet. Implement scale in max22531_read_raw function. Add boilerplate text to Kconfig for the driver. Signed-off-by: Abhinav Jain <[email protected]>

psychild added 4 commits July 10, 2025 15:58

arch: dts: overlays: Add MAX22531 Overlay

09db106

Signed-off-by: Abhinav Jain <[email protected]>

iio: adc: Update DT Overlay for MAX22531

15b53e9

Signed-off-by: Abhinav Jain <[email protected]>

iio: adc: Add initial basic support for MAX22531 ADC

fad64a4

Signed-off-by: Abhinav Jain <[email protected]>

iio: adc: Add regmap support and device tree support

3aec57d

Signed-off-by: Abhinav Jain <[email protected]>

KernelShinobi requested review from nunojsa, mhennerich, dbogdan, btogorean, chegbeli, buha, amiclaus, rbolboac, danmois, CiprianRegus and machschmitt as code owners July 15, 2025 21:12

machschmitt reviewed Jul 17, 2025

View reviewed changes

jonathanns reviewed Jul 17, 2025

View reviewed changes

psychild added 2 commits August 7, 2025 14:34

iio: adc: Device tree improvements for MAX22530-MAX22532

8de7c35

Improve initial DT Overlay for MAX22530-MAX22532. Add MAX22530-MAX22532 device tree documentation. Signed-off-by: Abhinav Jain <[email protected]>

iio: adc: Add initial driver support for MAX22531 #2854

Are you sure you want to change the base?

iio: adc: Add initial driver support for MAX22531 #2854

Uh oh!

Conversation

KernelShinobi commented Jul 15, 2025

PR Description

PR Type

PR Checklist

Uh oh!

machschmitt left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

machschmitt commented Jul 27, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Uh oh!

machschmitt commented Jul 27, 2025 •

edited

Loading