* [PATCH 2/2] iio: adc: Add Nuvoton MA35D1 EADC driver
From: Chi-Wen Weng @ 2026-06-25 11:06 UTC (permalink / raw)
To: jic23, robh, krzk+dt, conor+dt
Cc: dlechner, nuno.sa, andy, linux-arm-kernel, linux-iio, devicetree,
linux-kernel, cwweng, cwweng.linux
In-Reply-To: <20260625110638.38438-1-cwweng.linux@gmail.com>
From: Chi-Wen Weng <cwweng@nuvoton.com>
Add an IIO driver for the Nuvoton MA35D1 Enhanced ADC controller.
The driver supports direct raw reads and triggered buffered capture. The
controller end-of-conversion interrupt is exposed as the device trigger
and is used to push samples into the IIO buffer.
Channels are described by firmware child nodes and can be configured as
single-ended or differential inputs. Since the differential enable bit is
global, mixed single-ended and differential buffered scans are rejected.
DMA support is intentionally not included in this initial upstream driver;
conversions are handled through the interrupt-driven path.
Signed-off-by: Chi-Wen Weng <cwweng@nuvoton.com>
---
drivers/iio/adc/Kconfig | 10 +
drivers/iio/adc/Makefile | 1 +
drivers/iio/adc/ma35d1_eadc.c | 636 ++++++++++++++++++++++++++++++++++
3 files changed, 647 insertions(+)
create mode 100644 drivers/iio/adc/ma35d1_eadc.c
diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig
index 1c663c98c6c9..43409999a94b 100644
--- a/drivers/iio/adc/Kconfig
+++ b/drivers/iio/adc/Kconfig
@@ -981,6 +981,16 @@ config LTC2497
To compile this driver as a module, choose M here: the module will be
called ltc2497.
+config MA35D1_EADC
+ tristate "MA35D1 EADC driver"
+ select IIO_BUFFER
+ select IIO_TRIGGERED_BUFFER
+ help
+ Say yes here to build support for MA35D1 EADC.
+
+ To compile this driver as a module, choose M here: the module will be
+ called ma35d1.
+
config MAX1027
tristate "Maxim max1027 ADC driver"
depends on SPI
diff --git a/drivers/iio/adc/Makefile b/drivers/iio/adc/Makefile
index 707dd708912f..7b9b38688223 100644
--- a/drivers/iio/adc/Makefile
+++ b/drivers/iio/adc/Makefile
@@ -85,6 +85,7 @@ obj-$(CONFIG_LTC2471) += ltc2471.o
obj-$(CONFIG_LTC2485) += ltc2485.o
obj-$(CONFIG_LTC2496) += ltc2496.o ltc2497-core.o
obj-$(CONFIG_LTC2497) += ltc2497.o ltc2497-core.o
+obj-$(CONFIG_MA35D1_EADC) += ma35d1_eadc.o
obj-$(CONFIG_MAX1027) += max1027.o
obj-$(CONFIG_MAX11100) += max11100.o
obj-$(CONFIG_MAX1118) += max1118.o
diff --git a/drivers/iio/adc/ma35d1_eadc.c b/drivers/iio/adc/ma35d1_eadc.c
new file mode 100644
index 000000000000..0c075126e139
--- /dev/null
+++ b/drivers/iio/adc/ma35d1_eadc.c
@@ -0,0 +1,636 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Nuvoton MA35D1 EADC driver
+ *
+ * Copyright (c) 2026 Nuvoton Technology Corp.
+ */
+
+#include <linux/bitfield.h>
+#include <linux/bits.h>
+#include <linux/bitmap.h>
+#include <linux/clk.h>
+#include <linux/completion.h>
+#include <linux/device.h>
+#include <linux/err.h>
+#include <linux/interrupt.h>
+#include <linux/io.h>
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/mod_devicetable.h>
+#include <linux/mutex.h>
+#include <linux/platform_device.h>
+#include <linux/pm.h>
+#include <linux/property.h>
+
+#include <linux/iio/buffer.h>
+#include <linux/iio/iio.h>
+#include <linux/iio/trigger.h>
+#include <linux/iio/trigger_consumer.h>
+#include <linux/iio/triggered_buffer.h>
+
+#define MA35D1_EADC_DAT(n) (0x00 + (n) * 0x04)
+#define MA35D1_EADC_CTL 0x50
+#define MA35D1_EADC_SWTRG 0x54
+#define MA35D1_EADC_SCTL(n) (0x80 + (n) * 0x04)
+#define MA35D1_EADC_INTSRC0 0xd0
+#define MA35D1_EADC_STATUS2 0xf8
+#define MA35D1_EADC_SELSMP0 0x140
+#define MA35D1_EADC_REFADJCTL 0x150
+
+#define MA35D1_EADC_CTL_ADCEN BIT(0)
+#define MA35D1_EADC_CTL_ADCIEN0 BIT(2)
+#define MA35D1_EADC_CTL_DIFFEN BIT(8)
+
+#define MA35D1_EADC_SCTL_CHSEL_MASK GENMASK(3, 0)
+#define MA35D1_EADC_SCTL_TRGDLY_MASK GENMASK(15, 8)
+#define MA35D1_EADC_SCTL_TRGSEL_MASK GENMASK(21, 16)
+#define MA35D1_EADC_SCTL_TRGSEL_ADINT0 \
+ FIELD_PREP(MA35D1_EADC_SCTL_TRGSEL_MASK, 2)
+
+#define MA35D1_EADC_DAT_MASK GENMASK(11, 0)
+#define MA35D1_EADC_STATUS2_ADIF0 BIT(0)
+#define MA35D1_EADC_INTSRC0_ADINT0 BIT(0)
+#define MA35D1_EADC_REFADJCTL_EXT_VREF BIT(0)
+
+#define MA35D1_EADC_MAX_CHANNELS 9
+#define MA35D1_EADC_MAX_SAMPLE_MODULES 16
+#define MA35D1_EADC_CHAN_NAME_LEN 16
+#define MA35D1_EADC_TIMEOUT msecs_to_jiffies(1000)
+
+struct ma35d1_adc {
+ struct device *dev;
+ void __iomem *regs;
+ struct clk *clk;
+ struct completion completion;
+ /* Protects direct conversions against concurrent register access. */
+ struct mutex lock;
+ struct iio_trigger *trig;
+ unsigned int scan_chancnt;
+ bool scan_differential;
+ char chan_name[MA35D1_EADC_MAX_CHANNELS][MA35D1_EADC_CHAN_NAME_LEN];
+ struct {
+ u16 channels[MA35D1_EADC_MAX_SAMPLE_MODULES];
+ aligned_s64 timestamp;
+ } scan;
+};
+
+static inline u32 ma35d1_adc_read(struct ma35d1_adc *adc, u32 reg)
+{
+ return readl(adc->regs + reg);
+}
+
+static inline void ma35d1_adc_write(struct ma35d1_adc *adc, u32 reg, u32 val)
+{
+ writel(val, adc->regs + reg);
+}
+
+static void ma35d1_adc_rmw(struct ma35d1_adc *adc, u32 reg, u32 mask, u32 val)
+{
+ u32 tmp;
+
+ tmp = ma35d1_adc_read(adc, reg);
+ tmp &= ~mask;
+ tmp |= val;
+ ma35d1_adc_write(adc, reg, tmp);
+}
+
+static void ma35d1_adc_set_diff(struct ma35d1_adc *adc, bool differential)
+{
+ ma35d1_adc_rmw(adc, MA35D1_EADC_CTL, MA35D1_EADC_CTL_DIFFEN,
+ differential ? MA35D1_EADC_CTL_DIFFEN : 0);
+}
+
+static void ma35d1_adc_config_sample(struct ma35d1_adc *adc,
+ unsigned int sample, unsigned int channel)
+{
+ u32 reg = MA35D1_EADC_SCTL(sample);
+
+ ma35d1_adc_rmw(adc, reg,
+ MA35D1_EADC_SCTL_CHSEL_MASK |
+ MA35D1_EADC_SCTL_TRGSEL_MASK,
+ FIELD_PREP(MA35D1_EADC_SCTL_CHSEL_MASK, channel) |
+ MA35D1_EADC_SCTL_TRGSEL_ADINT0);
+}
+
+static void ma35d1_adc_disable_irq(struct ma35d1_adc *adc)
+{
+ ma35d1_adc_rmw(adc, MA35D1_EADC_CTL, MA35D1_EADC_CTL_ADCIEN0, 0);
+}
+
+static void ma35d1_adc_hw_init(struct ma35d1_adc *adc)
+{
+ ma35d1_adc_disable_irq(adc);
+ ma35d1_adc_rmw(adc, MA35D1_EADC_CTL,
+ MA35D1_EADC_CTL_ADCEN, MA35D1_EADC_CTL_ADCEN);
+ ma35d1_adc_write(adc, MA35D1_EADC_STATUS2, MA35D1_EADC_STATUS2_ADIF0);
+ ma35d1_adc_rmw(adc, MA35D1_EADC_INTSRC0,
+ MA35D1_EADC_INTSRC0_ADINT0,
+ MA35D1_EADC_INTSRC0_ADINT0);
+ ma35d1_adc_rmw(adc, MA35D1_EADC_REFADJCTL,
+ MA35D1_EADC_REFADJCTL_EXT_VREF,
+ MA35D1_EADC_REFADJCTL_EXT_VREF);
+ ma35d1_adc_rmw(adc, MA35D1_EADC_SELSMP0, GENMASK(1, 0), 3);
+}
+
+static void ma35d1_adc_hw_disable(void *data)
+{
+ struct ma35d1_adc *adc = data;
+
+ ma35d1_adc_disable_irq(adc);
+ ma35d1_adc_rmw(adc, MA35D1_EADC_CTL, MA35D1_EADC_CTL_ADCEN, 0);
+}
+
+static irqreturn_t ma35d1_adc_isr(int irq, void *data)
+{
+ struct iio_dev *indio_dev = data;
+ struct ma35d1_adc *adc = iio_priv(indio_dev);
+ u32 status;
+
+ status = ma35d1_adc_read(adc, MA35D1_EADC_STATUS2);
+ if (!(status & MA35D1_EADC_STATUS2_ADIF0))
+ return IRQ_NONE;
+
+ ma35d1_adc_write(adc, MA35D1_EADC_STATUS2, MA35D1_EADC_STATUS2_ADIF0);
+
+ if (iio_buffer_enabled(indio_dev)) {
+ ma35d1_adc_disable_irq(adc);
+ iio_trigger_poll(adc->trig);
+ } else {
+ complete(&adc->completion);
+ }
+
+ return IRQ_HANDLED;
+}
+
+static irqreturn_t ma35d1_adc_trigger_handler(int irq, void *p)
+{
+ struct iio_poll_func *pf = p;
+ struct iio_dev *indio_dev = pf->indio_dev;
+ struct ma35d1_adc *adc = iio_priv(indio_dev);
+ int i;
+
+ for (i = 0; i < adc->scan_chancnt; i++)
+ adc->scan.channels[i] =
+ ma35d1_adc_read(adc, MA35D1_EADC_DAT(i)) &
+ MA35D1_EADC_DAT_MASK;
+
+ iio_push_to_buffers_with_timestamp(indio_dev, &adc->scan, pf->timestamp);
+ iio_trigger_notify_done(adc->trig);
+
+ ma35d1_adc_rmw(adc, MA35D1_EADC_CTL, MA35D1_EADC_CTL_ADCIEN0,
+ MA35D1_EADC_CTL_ADCIEN0);
+ ma35d1_adc_write(adc, MA35D1_EADC_SWTRG, 1);
+
+ return IRQ_HANDLED;
+}
+
+static int ma35d1_adc_read_conversion(struct iio_dev *indio_dev,
+ const struct iio_chan_spec *chan,
+ int *val)
+{
+ struct ma35d1_adc *adc = iio_priv(indio_dev);
+ long timeout;
+
+ reinit_completion(&adc->completion);
+
+ ma35d1_adc_write(adc, MA35D1_EADC_STATUS2, MA35D1_EADC_STATUS2_ADIF0);
+ ma35d1_adc_rmw(adc, MA35D1_EADC_SCTL(0),
+ MA35D1_EADC_SCTL_CHSEL_MASK |
+ MA35D1_EADC_SCTL_TRGSEL_MASK,
+ FIELD_PREP(MA35D1_EADC_SCTL_CHSEL_MASK,
+ chan->channel));
+ ma35d1_adc_set_diff(adc, chan->differential);
+ ma35d1_adc_rmw(adc, MA35D1_EADC_CTL, MA35D1_EADC_CTL_ADCIEN0,
+ MA35D1_EADC_CTL_ADCIEN0);
+ ma35d1_adc_write(adc, MA35D1_EADC_SWTRG, 1);
+
+ timeout = wait_for_completion_interruptible_timeout(&adc->completion,
+ MA35D1_EADC_TIMEOUT);
+ ma35d1_adc_disable_irq(adc);
+
+ if (timeout < 0)
+ return timeout;
+ if (!timeout)
+ return -ETIMEDOUT;
+
+ *val = ma35d1_adc_read(adc, MA35D1_EADC_DAT(0)) & MA35D1_EADC_DAT_MASK;
+
+ return 0;
+}
+
+static int ma35d1_adc_read_raw(struct iio_dev *indio_dev,
+ const struct iio_chan_spec *chan,
+ int *val, int *val2, long mask)
+{
+ struct ma35d1_adc *adc = iio_priv(indio_dev);
+ int ret;
+
+ switch (mask) {
+ case IIO_CHAN_INFO_RAW:
+ if (!iio_device_claim_direct(indio_dev))
+ return -EBUSY;
+
+ mutex_lock(&adc->lock);
+ ret = ma35d1_adc_read_conversion(indio_dev, chan, val);
+ mutex_unlock(&adc->lock);
+
+ iio_device_release_direct(indio_dev);
+ if (ret)
+ return ret;
+
+ return IIO_VAL_INT;
+ default:
+ return -EINVAL;
+ }
+}
+
+static int ma35d1_adc_validate_scan(struct iio_dev *indio_dev,
+ const unsigned long *scan_mask)
+{
+ const struct iio_chan_spec *chan;
+ bool have_single = false;
+ bool have_diff = false;
+ unsigned int count = 0;
+ unsigned long bit;
+
+ for_each_set_bit(bit, scan_mask, indio_dev->masklength) {
+ chan = &indio_dev->channels[bit];
+
+ if (chan->type == IIO_TIMESTAMP)
+ continue;
+ count++;
+ if (chan->differential)
+ have_diff = true;
+ else
+ have_single = true;
+ }
+
+ if (!count || count > MA35D1_EADC_MAX_SAMPLE_MODULES)
+ return -EINVAL;
+
+ if (have_single && have_diff)
+ return -EINVAL;
+
+ return 0;
+}
+
+static int ma35d1_adc_update_scan_mode(struct iio_dev *indio_dev,
+ const unsigned long *scan_mask)
+{
+ struct ma35d1_adc *adc = iio_priv(indio_dev);
+ const struct iio_chan_spec *chan;
+ unsigned int sample = 0;
+ unsigned long bit;
+ bool differential = false;
+ int ret;
+
+ ret = ma35d1_adc_validate_scan(indio_dev, scan_mask);
+ if (ret)
+ return ret;
+
+ for_each_set_bit(bit, scan_mask, indio_dev->masklength) {
+ chan = &indio_dev->channels[bit];
+ if (chan->type == IIO_TIMESTAMP)
+ continue;
+
+ if (!sample)
+ differential = chan->differential;
+
+ ma35d1_adc_config_sample(adc, sample, chan->channel);
+ sample++;
+ }
+
+ adc->scan_chancnt = sample;
+ adc->scan_differential = differential;
+
+ return 0;
+}
+
+static int ma35d1_adc_buffer_postenable(struct iio_dev *indio_dev)
+{
+ struct ma35d1_adc *adc = iio_priv(indio_dev);
+ int i;
+
+ if (!adc->scan_chancnt)
+ return -EINVAL;
+
+ ma35d1_adc_write(adc, MA35D1_EADC_STATUS2, MA35D1_EADC_STATUS2_ADIF0);
+ ma35d1_adc_rmw(adc, MA35D1_EADC_INTSRC0,
+ MA35D1_EADC_INTSRC0_ADINT0,
+ MA35D1_EADC_INTSRC0_ADINT0);
+ ma35d1_adc_rmw(adc, MA35D1_EADC_REFADJCTL,
+ MA35D1_EADC_REFADJCTL_EXT_VREF,
+ MA35D1_EADC_REFADJCTL_EXT_VREF);
+ ma35d1_adc_rmw(adc, MA35D1_EADC_SELSMP0, GENMASK(1, 0), 3);
+ ma35d1_adc_set_diff(adc, adc->scan_differential);
+
+ for (i = 0; i < adc->scan_chancnt; i++)
+ ma35d1_adc_rmw(adc, MA35D1_EADC_SCTL(i),
+ MA35D1_EADC_SCTL_TRGDLY_MASK,
+ MA35D1_EADC_SCTL_TRGDLY_MASK);
+
+ ma35d1_adc_rmw(adc, MA35D1_EADC_CTL, MA35D1_EADC_CTL_ADCIEN0,
+ MA35D1_EADC_CTL_ADCIEN0);
+ ma35d1_adc_write(adc, MA35D1_EADC_SWTRG, 1);
+
+ return 0;
+}
+
+static int ma35d1_adc_buffer_predisable(struct iio_dev *indio_dev)
+{
+ struct ma35d1_adc *adc = iio_priv(indio_dev);
+ int i;
+
+ ma35d1_adc_disable_irq(adc);
+ for (i = 0; i < adc->scan_chancnt; i++)
+ ma35d1_adc_rmw(adc, MA35D1_EADC_SCTL(i),
+ MA35D1_EADC_SCTL_TRGSEL_MASK, 0);
+
+ return 0;
+}
+
+static const struct iio_buffer_setup_ops ma35d1_adc_buffer_ops = {
+ .postenable = ma35d1_adc_buffer_postenable,
+ .predisable = ma35d1_adc_buffer_predisable,
+};
+
+static const struct iio_info ma35d1_adc_info = {
+ .read_raw = ma35d1_adc_read_raw,
+ .update_scan_mode = ma35d1_adc_update_scan_mode,
+};
+
+static const struct iio_trigger_ops ma35d1_adc_trigger_ops = {
+ .validate_device = iio_trigger_validate_own_device,
+};
+
+static void ma35d1_adc_init_channel(struct ma35d1_adc *adc,
+ struct iio_chan_spec *chan, u32 vinp,
+ u32 vinn, int scan_index, bool differential)
+{
+ char *name = adc->chan_name[vinp];
+
+ chan->type = IIO_VOLTAGE;
+ chan->indexed = 1;
+ chan->channel = vinp;
+ chan->address = vinp;
+ chan->scan_index = scan_index;
+ chan->info_mask_separate = BIT(IIO_CHAN_INFO_RAW);
+ chan->scan_type.sign = 'u';
+ chan->scan_type.realbits = 12;
+ chan->scan_type.storagebits = 16;
+ chan->scan_type.endianness = IIO_CPU;
+
+ if (differential) {
+ chan->differential = 1;
+ chan->channel2 = vinn;
+ snprintf(name, MA35D1_EADC_CHAN_NAME_LEN, "in%d-in%d", vinp,
+ vinn);
+ } else {
+ snprintf(name, MA35D1_EADC_CHAN_NAME_LEN, "in%d", vinp);
+ }
+
+ chan->datasheet_name = name;
+}
+
+static int ma35d1_adc_parse_channels(struct iio_dev *indio_dev,
+ struct device *dev)
+{
+ struct ma35d1_adc *adc = iio_priv(indio_dev);
+ DECLARE_BITMAP(used_channels, MA35D1_EADC_MAX_CHANNELS);
+ struct fwnode_handle *child;
+ struct iio_chan_spec *channels;
+ int num_channels;
+ int scan_index = 0;
+ int ret;
+
+ bitmap_zero(used_channels, MA35D1_EADC_MAX_CHANNELS);
+
+ num_channels = device_get_child_node_count(dev);
+ if (!num_channels)
+ return dev_err_probe(dev, -ENODATA,
+ "no ADC channels configured\n");
+
+ if (num_channels > MA35D1_EADC_MAX_CHANNELS)
+ return dev_err_probe(dev, -EINVAL, "too many ADC channels\n");
+
+ channels = devm_kcalloc(dev, num_channels + 1, sizeof(*channels),
+ GFP_KERNEL);
+ if (!channels)
+ return -ENOMEM;
+
+ device_for_each_child_node(dev, child) {
+ u32 diff[2];
+ u32 reg;
+ bool differential = false;
+
+ ret = fwnode_property_read_u32(child, "reg", ®);
+ if (ret) {
+ fwnode_handle_put(child);
+ return dev_err_probe(dev, ret,
+ "missing channel reg property\n");
+ }
+
+ if (reg >= MA35D1_EADC_MAX_CHANNELS) {
+ fwnode_handle_put(child);
+ return dev_err_probe(dev, -EINVAL,
+ "invalid ADC channel %u\n", reg);
+ }
+
+ if (test_and_set_bit(reg, used_channels)) {
+ fwnode_handle_put(child);
+ return dev_err_probe(dev, -EINVAL,
+ "duplicate ADC channel %u\n", reg);
+ }
+
+ if (fwnode_property_present(child, "diff-channels")) {
+ ret = fwnode_property_read_u32_array(child,
+ "diff-channels",
+ diff,
+ ARRAY_SIZE(diff));
+ if (ret) {
+ fwnode_handle_put(child);
+ return dev_err_probe(dev, ret,
+ "invalid diff-channels for channel %u\n",
+ reg);
+ }
+
+ if (diff[0] != reg ||
+ diff[1] >= MA35D1_EADC_MAX_CHANNELS ||
+ diff[0] == diff[1]) {
+ fwnode_handle_put(child);
+ return dev_err_probe(dev, -EINVAL,
+ "invalid differential ADC channel %u-%u\n",
+ diff[0], diff[1]);
+ }
+
+ if (test_and_set_bit(diff[1], used_channels)) {
+ fwnode_handle_put(child);
+ return dev_err_probe(dev, -EINVAL,
+ "ADC channel %u already used\n",
+ diff[1]);
+ }
+
+ differential = true;
+ }
+
+ ma35d1_adc_init_channel(adc, &channels[scan_index], reg,
+ differential ? diff[1] : 0,
+ scan_index, differential);
+ scan_index++;
+ }
+
+ channels[scan_index] = (struct iio_chan_spec)
+ IIO_CHAN_SOFT_TIMESTAMP(scan_index);
+
+ indio_dev->channels = channels;
+ indio_dev->num_channels = scan_index + 1;
+ indio_dev->masklength = indio_dev->num_channels;
+
+ return 0;
+}
+
+static int ma35d1_adc_setup_trigger(struct iio_dev *indio_dev,
+ struct device *dev)
+{
+ struct ma35d1_adc *adc = iio_priv(indio_dev);
+ int ret;
+
+ adc->trig = devm_iio_trigger_alloc(dev, "%s-trigger", dev_name(dev));
+ if (!adc->trig)
+ return -ENOMEM;
+
+ adc->trig->ops = &ma35d1_adc_trigger_ops;
+ iio_trigger_set_drvdata(adc->trig, indio_dev);
+
+ ret = devm_iio_trigger_register(dev, adc->trig);
+ if (ret)
+ return dev_err_probe(dev, ret, "failed to register trigger\n");
+
+ ret = iio_trigger_set_immutable(indio_dev, adc->trig);
+ if (ret)
+ return dev_err_probe(dev, ret, "failed to set trigger\n");
+
+ return 0;
+}
+
+static int ma35d1_adc_probe(struct platform_device *pdev)
+{
+ struct device *dev = &pdev->dev;
+ struct iio_dev *indio_dev;
+ struct ma35d1_adc *adc;
+ int irq;
+ int ret;
+
+ indio_dev = devm_iio_device_alloc(dev, sizeof(*adc));
+ if (!indio_dev)
+ return -ENOMEM;
+ adc = iio_priv(indio_dev);
+ adc->dev = dev;
+ mutex_init(&adc->lock);
+ init_completion(&adc->completion);
+
+ adc->regs = devm_platform_ioremap_resource(pdev, 0);
+ if (IS_ERR(adc->regs))
+ return dev_err_probe(dev, PTR_ERR(adc->regs),
+ "failed to map registers\n");
+
+ adc->clk = devm_clk_get_enabled(dev, NULL);
+ if (IS_ERR(adc->clk))
+ return dev_err_probe(dev, PTR_ERR(adc->clk),
+ "failed to get and enable ADC clock\n");
+
+ indio_dev->name = "ma35d1-eadc";
+ indio_dev->modes = INDIO_DIRECT_MODE | INDIO_BUFFER_TRIGGERED;
+ indio_dev->info = &ma35d1_adc_info;
+
+ ret = ma35d1_adc_parse_channels(indio_dev, dev);
+ if (ret)
+ return ret;
+
+ ma35d1_adc_hw_init(adc);
+
+ ret = devm_add_action_or_reset(dev, ma35d1_adc_hw_disable, adc);
+ if (ret)
+ return ret;
+
+ ret = ma35d1_adc_setup_trigger(indio_dev, dev);
+ if (ret)
+ return ret;
+
+ irq = platform_get_irq(pdev, 0);
+ if (irq < 0)
+ return irq;
+
+ ret = devm_request_irq(dev, irq, ma35d1_adc_isr, 0, dev_name(dev),
+ indio_dev);
+ if (ret)
+ return dev_err_probe(dev, ret, "failed to request IRQ %d\n", irq);
+
+ ret = devm_iio_triggered_buffer_setup(dev, indio_dev,
+ iio_pollfunc_store_time,
+ ma35d1_adc_trigger_handler,
+ &ma35d1_adc_buffer_ops);
+ if (ret)
+ return dev_err_probe(dev, ret,
+ "failed to setup triggered buffer\n");
+
+ platform_set_drvdata(pdev, indio_dev);
+
+ ret = devm_iio_device_register(dev, indio_dev);
+ if (ret)
+ return dev_err_probe(dev, ret, "failed to register IIO device\n");
+
+ return 0;
+}
+
+static int ma35d1_adc_suspend(struct device *dev)
+{
+ struct iio_dev *indio_dev = dev_get_drvdata(dev);
+ struct ma35d1_adc *adc = iio_priv(indio_dev);
+
+ if (iio_buffer_enabled(indio_dev))
+ return -EBUSY;
+
+ ma35d1_adc_hw_disable(adc);
+ clk_disable_unprepare(adc->clk);
+
+ return 0;
+}
+
+static int ma35d1_adc_resume(struct device *dev)
+{
+ struct iio_dev *indio_dev = dev_get_drvdata(dev);
+ struct ma35d1_adc *adc = iio_priv(indio_dev);
+ int ret;
+
+ ret = clk_prepare_enable(adc->clk);
+ if (ret)
+ return ret;
+
+ ma35d1_adc_hw_init(adc);
+
+ return 0;
+}
+
+static DEFINE_SIMPLE_DEV_PM_OPS(ma35d1_adc_pm_ops,
+ ma35d1_adc_suspend, ma35d1_adc_resume);
+
+static const struct of_device_id ma35d1_adc_of_match[] = {
+ { .compatible = "nuvoton,ma35d1-eadc" },
+ { }
+};
+MODULE_DEVICE_TABLE(of, ma35d1_adc_of_match);
+
+static struct platform_driver ma35d1_adc_driver = {
+ .probe = ma35d1_adc_probe,
+ .driver = {
+ .name = "ma35d1-eadc",
+ .of_match_table = ma35d1_adc_of_match,
+ .pm = pm_sleep_ptr(&ma35d1_adc_pm_ops),
+ },
+};
+module_platform_driver(ma35d1_adc_driver);
+
+MODULE_AUTHOR("Chi-Wen Weng <cwweng@nuvoton.com>");
+MODULE_DESCRIPTION("Nuvoton MA35D1 EADC driver");
+MODULE_LICENSE("GPL");
--
2.25.1
^ permalink raw reply related
* [PATCH 1/2] dt-bindings: iio: adc: Add Nuvoton MA35D1 EADC
From: Chi-Wen Weng @ 2026-06-25 11:06 UTC (permalink / raw)
To: jic23, robh, krzk+dt, conor+dt
Cc: dlechner, nuno.sa, andy, linux-arm-kernel, linux-iio, devicetree,
linux-kernel, cwweng, cwweng.linux
In-Reply-To: <20260625110638.38438-1-cwweng.linux@gmail.com>
From: Chi-Wen Weng <cwweng@nuvoton.com>
Add devicetree binding for the Enhanced ADC controller found on
Nuvoton MA35D1 SoCs.
The controller has one register region, one interrupt and one functional
clock. ADC inputs are described using standard channel child nodes,
including optional differential channel pairs.
Signed-off-by: Chi-Wen Weng <cwweng@nuvoton.com>
---
.../bindings/iio/adc/nuvoton,ma35d1-eadc.yaml | 100 ++++++++++++++++++
1 file changed, 100 insertions(+)
create mode 100644 Documentation/devicetree/bindings/iio/adc/nuvoton,ma35d1-eadc.yaml
diff --git a/Documentation/devicetree/bindings/iio/adc/nuvoton,ma35d1-eadc.yaml b/Documentation/devicetree/bindings/iio/adc/nuvoton,ma35d1-eadc.yaml
new file mode 100644
index 000000000000..ae7ad0f7689a
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/adc/nuvoton,ma35d1-eadc.yaml
@@ -0,0 +1,100 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/iio/adc/nuvoton,ma35d1-eadc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Nuvoton MA35D1 Enhanced Analog to Digital Converter
+
+maintainers:
+ - Chi-Wen Weng <cwweng@nuvoton.com>
+
+description: |
+ The Nuvoton MA35D1 Enhanced Analog to Digital Converter (EADC) is a
+ 12-bit ADC controller integrated in the MA35D1 SoC. Each enabled ADC
+ input is described by a child channel node.
+
+properties:
+ compatible:
+ const: nuvoton,ma35d1-eadc
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ '#address-cells':
+ const: 1
+
+ '#size-cells':
+ const: 0
+
+patternProperties:
+ '^channel@[0-8]$':
+ type: object
+ $ref: adc.yaml
+ unevaluatedProperties: false
+
+ properties:
+ reg:
+ minimum: 0
+ maximum: 8
+
+ diff-channels:
+ minItems: 2
+ maxItems: 2
+ items:
+ minimum: 0
+ maximum: 8
+
+ required:
+ - reg
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - clocks
+ - '#address-cells'
+ - '#size-cells'
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/nuvoton,ma35d1-clk.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/interrupt-controller/irq.h>
+
+ soc {
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ adc@40430000 {
+ compatible = "nuvoton,ma35d1-eadc";
+ reg = <0x0 0x40430000 0x0 0x10000>;
+ interrupts = <GIC_SPI 65 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&clk EADC_GATE>;
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ channel@0 {
+ reg = <0>;
+ };
+
+ channel@1 {
+ reg = <1>;
+ };
+
+ channel@2 {
+ reg = <2>;
+ diff-channels = <2 3>;
+ };
+ };
+ };
+...
--
2.25.1
^ permalink raw reply related
* [PATCH 0/2] iio: adc: Add Nuvoton MA35D1 EADC support
From: Chi-Wen Weng @ 2026-06-25 11:06 UTC (permalink / raw)
To: jic23, robh, krzk+dt, conor+dt
Cc: dlechner, nuno.sa, andy, linux-arm-kernel, linux-iio, devicetree,
linux-kernel, cwweng, cwweng.linux
From: Chi-Wen Weng <cwweng@nuvoton.com>
This series adds devicetree binding and IIO driver support for the
Nuvoton MA35D1 Enhanced ADC controller.
The MA35D1 EADC controller supports multiple ADC input channels. This
initial upstream driver supports direct raw reads and triggered buffered
capture using the controller end-of-conversion interrupt as the IIO
device trigger.
ADC channels are described using standard firmware child nodes. Both
single-ended and differential channels are supported. Since the
differential enable bit is global in the controller, mixed single-ended
and differential buffered scans are rejected.
DMA support is intentionally not included in this initial version. The
driver uses the interrupt-driven conversion path to keep the first
upstream submission small and easier to review.
Patch 1 adds the devicetree binding.
Patch 2 adds the MA35D1 EADC IIO driver.
Chi-Wen Weng (2):
dt-bindings: iio: adc: Add Nuvoton MA35D1 EADC
iio: adc: Add Nuvoton MA35D1 EADC driver
.../bindings/iio/adc/nuvoton,ma35d1-eadc.yaml | 100 +++
drivers/iio/adc/Kconfig | 10 +
drivers/iio/adc/Makefile | 1 +
drivers/iio/adc/ma35d1_eadc.c | 636 ++++++++++++++++++
4 files changed, 747 insertions(+)
create mode 100644 Documentation/devicetree/bindings/iio/adc/nuvoton,ma35d1-eadc.yaml
create mode 100644 drivers/iio/adc/ma35d1_eadc.c
--
2.25.1
^ permalink raw reply
* Re: [PATCH v16 04/14] lib: kstrtox: add initial value to _parse_integer_limit()
From: Jonathan Cameron @ 2026-06-25 10:58 UTC (permalink / raw)
To: Rodrigo Alencar
Cc: rodrigo.alencar, linux-kernel, linux-iio, devicetree, linux-doc,
linux, David Lechner, Andy Shevchenko, Lars-Peter Clausen,
Michael Hennerich, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Jonathan Corbet, Andrew Morton, Petr Mladek, Steven Rostedt,
Andy Shevchenko, Rasmus Villemoes, Sergey Senozhatsky, Shuah Khan
In-Reply-To: <ssrckqgv3rqpfgxwpx4ca3m5m2mp3frxs6sd673chvsorhsjiq@63t3eosivg3a>
On Thu, 25 Jun 2026 08:30:07 +0100
Rodrigo Alencar <455.rodrigo.alencar@gmail.com> wrote:
> On 24/06/26 15:54, Jonathan Cameron wrote:
> > On Sun, 14 Jun 2026 21:00:44 +0100
> > Jonathan Cameron <jic23@kernel.org> wrote:
> >
> > > On Thu, 4 Jun 2026 11:09:33 +0100
> > > Rodrigo Alencar <455.rodrigo.alencar@gmail.com> wrote:
> > >
> > > > On 26/06/04 10:58AM, Rodrigo Alencar via B4 Relay wrote:
> > > > > From: Rodrigo Alencar <rodrigo.alencar@analog.com>
> > > > >
> > > > > Add init parameter to _parse_integer_limit() that defines an initial
> > > > > value for the accumulated result when parsing an 64-bit integer. The
> > > > > new function prototype is adjusted so that the _parse_integer() macros
> > > > > stay consistent allowing for one more argument, which defaults to 0.
> > > >
> > > > ...
> > > >
> > > > > noinline
> > > > > unsigned int _parse_integer_limit(const char *s, unsigned int base, unsigned long long *p,
> > > > > - size_t max_chars)
> > > > > + size_t max_chars, unsigned long long init)
> > > > > {
> > > > > unsigned long long res;
> > > > > unsigned int rv;
> > > > >
> > > > > - res = 0;
> > > > > + res = init;
> > > >
> > > > This might generate conflict, as the code around have changed in linux-next.
> > > > It is an easy fix though.
> > > >
> > > Thanks for the heads up. Hopefully that will all fall out when I rebase testing
> > > on rc1 once that is out.
> > I've done a mid merge cycle rebase as the char-misc branches have merged.
> > So this should be resolve on my testing branch now.
>
> https://lore.kernel.org/oe-kbuild-all/202606250230.etPGuolf-lkp@intel.com/
>
> Apparently, the documentation header now includes parameter descriptions.
> The new one is missing.
I'm snowed under for next few days so if you have time to spin me a fixup patch
that I can just apply that would be great.
If not I'll get to it next week probably.
Jonathan
>
^ permalink raw reply
* RE: [PATCH v2 4/4] iio: dac: ad3530r: Add support for AD3532R/AD3532
From: Paller, Kim Seer @ 2026-06-25 10:07 UTC (permalink / raw)
To: Jonathan Cameron, Andy Shevchenko
Cc: David Lechner, Sa, Nuno, Andy Shevchenko, Hennerich, Michael,
Rob Herring, Krzysztof Kozlowski, Conor Dooley,
linux-iio@vger.kernel.org, linux-kernel@vger.kernel.org, linux,
devicetree@vger.kernel.org
In-Reply-To: <20260621174548.5eca5db6@jic23-huawei>
> From: Jonathan Cameron <jic23@kernel.org>
> Sent: Monday, June 22, 2026 12:46 AM
> To: Andy Shevchenko <andriy.shevchenko@intel.com>
> Cc: Paller, Kim Seer <KimSeer.Paller@analog.com>; David Lechner
> <dlechner@baylibre.com>; Sa, Nuno <Nuno.Sa@analog.com>; Andy
> Shevchenko <andy@kernel.org>; Hennerich, Michael
> <Michael.Hennerich@analog.com>; Rob Herring <robh@kernel.org>; Krzysztof
> Kozlowski <krzk+dt@kernel.org>; Conor Dooley <conor+dt@kernel.org>;
> linux-iio@vger.kernel.org; linux-kernel@vger.kernel.org; linux
> <linux@analog.com>; devicetree@vger.kernel.org
> Subject: Re: [PATCH v2 4/4] iio: dac: ad3530r: Add support for
> AD3532R/AD3532
>
> [External]
>
> On Mon, 15 Jun 2026 13:05:44 +0300
> Andy Shevchenko <andriy.shevchenko@intel.com> wrote:
>
> > On Mon, Jun 15, 2026 at 02:20:18PM +0800, Kim Seer Paller wrote:
> > > The AD3532R/AD3532 is a 16-channel, 16-bit voltage output DAC with a
> > > dual-bank register architecture (bank 0 at 0x1000 for channels 0-7,
> > > bank 1 at 0x3000 for channels 8-15). It shares similar functionality
> > > with AD3530R (channel configuration, LDAC triggering, powerdown
> > > control), the main difference being the register address map due to
> > > the dual-bank architecture, handled by table-driven helpers.
> > >
> > > Add AD3532R-specific register definitions, channel specs, per-bank
> > > register arrays, a dedicated ad3532r_set_dac_powerdown(), and
> > > per-chip regmap_config to limit debugfs-exposed register space to
> > > each variant's actual address range.
> >
> > ...
> >
> >
> > > help
> > > - Say yes here to build support for Analog Devices AD3530R, AD3531R
> > > - Digital to Analog Converter.
> > > + Say yes here to build support for Analog Devices AD3530/AD3530R,
> > > + AD3531/AD3531R, and AD3532/AD3532R Digital to Analog
> Converters.
> >
> > This just shows how unscalable the above text is. That's why we
> > usually recommend to make the list explicit and separated.
> >
> > Say yes here to build support for the following Analog Devices
> > Digital to Analog Converters:
> > - AD3530/AD3530R (8-channel)
> > - AD3531/AD3531R (4-channel)
> > - AD3532/AD3532R (16-channel)
> >
> > (and looking into the C-file change, perhaps add here as well
> > distinctive information, such as number of channels, in the parentheses).
> >
> > > To compile this driver as a module, choose M here: the
> > > module will be called ad3530r.
> >
> > ...
> >
> > > +#define AD3532R_INTERFACE_CONFIG_A_0 0x1000
> > > +#define AD3532R_INTERFACE_CONFIG_A_1 0x3000
> > > +#define AD3532R_OUTPUT_OPERATING_MODE_0 0x1020
> > > +#define AD3532R_OUTPUT_OPERATING_MODE_1 0x1021
> > > +#define AD3532R_OUTPUT_OPERATING_MODE_2 0x3020
> > > +#define AD3532R_OUTPUT_OPERATING_MODE_3 0x3021
> > > +#define AD3532R_OUTPUT_CONTROL_0 0x102A
> > > +#define AD3532R_OUTPUT_CONTROL_1 0x302A
> > > +#define AD3532R_REFERENCE_CONTROL_0 0x103C
> > > +#define AD3532R_REFERENCE_CONTROL_1 0x303C
> > > +#define AD3532R_SW_LDAC_TRIG_0 0x10E5
> > > +#define AD3532R_SW_LDAC_TRIG_1 0x30E5
> > > +#define AD3532R_INPUT_CH_0 0x10EB
> > > +#define AD3532R_INPUT_CH_1 0x30EB
> > > +#define AD3532R_MAX_REG_ADDR 0x30F9
> Whilst we are here, Sashiko thinks there is an off by one on that value as it's
> the lower of the two registers that make up channel 15.
> https://urldefense.com/v3/__https://sashiko.dev/*/patchset/20260615-iio-
> ad3532r-support-v2-0-
> 84a0af8b83fa*40analog.com__;IyU!!A3Ni8CS0y2Y!88afCOStwucx32wuoeR
> SyZ9GpkZge9YDw5_PIMAf7SLs3OLykUC_qNRDUCnRw7wTwsxiIT1V-
> R8sH17sTg$
> It also suggests an existing bug that it would be good to look into.
I don't think it's off-by-one. INPUT_CHn registers are listed by LSB, so channel 15 is 0x30F8 (LSB) / 0x30F9 (MSB).
The driver addresses the MSB and the part defaults to descending mode, so the access goes 0x30F9 -> 0x30F8.
0x30F9 is also the highest valid address per the datasheet, so max_register looks correct same for AD3530R's 0xF9.
Does that match our understanding, or am I missing a case?
>
> >
> > Hmm... I dunno if it's better to sort by values (so the "bank" 0 goes
> > together followed by "bank" 1). Jonathan, what's your preference here?
> Nuno, David?
> That is how people will typically check them vs the datasheet so I agree with
> numeric order. Maybe with a comment at the top about there effectively
> being two banks. Many of the registers are effectively copies for the new
> channels but not all of them, so a macro approach would probably be even
> more confusing.
>
> Jonathan
^ permalink raw reply
* RE: [PATCH v2 4/4] iio: dac: ad3530r: Add support for AD3532R/AD3532
From: Paller, Kim Seer @ 2026-06-25 10:06 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Jonathan Cameron, David Lechner, Sa, Nuno, Andy Shevchenko,
Hennerich, Michael, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, linux-iio@vger.kernel.org,
linux-kernel@vger.kernel.org, linux, devicetree@vger.kernel.org
In-Reply-To: <ai_OeEegWavHcNF1@ashevche-desk.local>
> From: Andy Shevchenko <andriy.shevchenko@intel.com>
> Sent: Monday, June 15, 2026 6:06 PM
> To: Paller, Kim Seer <KimSeer.Paller@analog.com>
> Cc: Jonathan Cameron <jic23@kernel.org>; David Lechner
> <dlechner@baylibre.com>; Sa, Nuno <Nuno.Sa@analog.com>; Andy
> Shevchenko <andy@kernel.org>; Hennerich, Michael
> <Michael.Hennerich@analog.com>; Rob Herring <robh@kernel.org>; Krzysztof
> Kozlowski <krzk+dt@kernel.org>; Conor Dooley <conor+dt@kernel.org>; linux-
> iio@vger.kernel.org; linux-kernel@vger.kernel.org; linux <linux@analog.com>;
> devicetree@vger.kernel.org
> Subject: Re: [PATCH v2 4/4] iio: dac: ad3530r: Add support for
> AD3532R/AD3532
>
> [External]
>
> On Mon, Jun 15, 2026 at 02:20:18PM +0800, Kim Seer Paller wrote:
> > The AD3532R/AD3532 is a 16-channel, 16-bit voltage output DAC with a
> > dual-bank register architecture (bank 0 at 0x1000 for channels 0-7,
> > bank 1 at 0x3000 for channels 8-15). It shares similar functionality
> > with AD3530R (channel configuration, LDAC triggering, powerdown
> > control), the main difference being the register address map due to
> > the dual-bank architecture, handled by table-driven helpers.
> >
> > Add AD3532R-specific register definitions, channel specs, per-bank
> > register arrays, a dedicated ad3532r_set_dac_powerdown(), and per-chip
> > regmap_config to limit debugfs-exposed register space to each
> > variant's actual address range.
>
> ...
>
>
> > help
> > - Say yes here to build support for Analog Devices AD3530R, AD3531R
> > - Digital to Analog Converter.
> > + Say yes here to build support for Analog Devices AD3530/AD3530R,
> > + AD3531/AD3531R, and AD3532/AD3532R Digital to Analog
> Converters.
>
> This just shows how unscalable the above text is. That's why we usually
> recommend to make the list explicit and separated.
>
> Say yes here to build support for the following Analog Devices
> Digital to Analog Converters:
> - AD3530/AD3530R (8-channel)
> - AD3531/AD3531R (4-channel)
> - AD3532/AD3532R (16-channel)
>
> (and looking into the C-file change, perhaps add here as well distinctive
> information, such as number of channels, in the parentheses).
>
> > To compile this driver as a module, choose M here: the
> > module will be called ad3530r.
>
> ...
>
> > +#define AD3532R_INTERFACE_CONFIG_A_0 0x1000
> > +#define AD3532R_INTERFACE_CONFIG_A_1 0x3000
> > +#define AD3532R_OUTPUT_OPERATING_MODE_0 0x1020
> > +#define AD3532R_OUTPUT_OPERATING_MODE_1 0x1021
> > +#define AD3532R_OUTPUT_OPERATING_MODE_2 0x3020
> > +#define AD3532R_OUTPUT_OPERATING_MODE_3 0x3021
> > +#define AD3532R_OUTPUT_CONTROL_0 0x102A
> > +#define AD3532R_OUTPUT_CONTROL_1 0x302A
> > +#define AD3532R_REFERENCE_CONTROL_0 0x103C
> > +#define AD3532R_REFERENCE_CONTROL_1 0x303C
> > +#define AD3532R_SW_LDAC_TRIG_0 0x10E5
> > +#define AD3532R_SW_LDAC_TRIG_1 0x30E5
> > +#define AD3532R_INPUT_CH_0 0x10EB
> > +#define AD3532R_INPUT_CH_1 0x30EB
> > +#define AD3532R_MAX_REG_ADDR 0x30F9
>
> Hmm... I dunno if it's better to sort by values (so the "bank" 0 goes together
> followed by "bank" 1). Jonathan, what's your preference here? Nuno, David?
>
> ...
>
> > +static ssize_t ad3532r_set_dac_powerdown(struct iio_dev *indio_dev,
> > + uintptr_t private,
> > + const struct iio_chan_spec *chan,
> > + const char *buf, size_t len)
> > +{
> > + struct ad3530r_state *st = iio_priv(indio_dev);
> > + unsigned int reg, pdmode, mask, val, local_ch;
> > + bool powerdown;
> > + int ret;
> > +
> > + ret = kstrtobool(buf, &powerdown);
>
> Do you need to include kstrtox.h?
Yes, kstrtobool() is declared in <linux/kstrtox.h>. I also ran IWYU and
it confirms <linux/kstrtox.h> belongs in the include list.
>
> > + if (ret)
> > + return ret;
> > +
> > + guard(mutex)(&st->lock);
>
> + blank line here.
>
> > + local_ch = chan->channel % AD3530R_CH_PER_BANK;
>
> > + reg = (chan->channel < AD3530R_CH_PER_BANK ?
> AD3532R_OUTPUT_OPERATING_MODE_0 :
> > + AD3532R_OUTPUT_OPERATING_MODE_2) +
> > + local_ch / AD3530R_CH_PER_REG;
>
> This is unreadable. Can you refactor it?
Would this be clearer?
unsigned int bank_base;
local_ch = chan->channel % AD3530R_CH_PER_BANK;
bank_base = chan->channel < AD3530R_CH_PER_BANK ?
AD3532R_OUTPUT_OPERATING_MODE_0 : AD3532R_OUTPUT_OPERATING_MODE_2;
reg = bank_base + local_ch / AD3530R_CH_PER_REG;
>
> > + mask = AD3530R_OP_MODE_CHAN_MSK(local_ch %
> AD3530R_CH_PER_REG);
> > +
> > + pdmode = powerdown ? st->chan[chan->channel].powerdown_mode :
> 0;
> > + val = field_prep(mask, pdmode);
> > +
> > + ret = regmap_update_bits(st->regmap, reg, mask, val);
> > + if (ret)
> > + return ret;
> > +
> > + st->chan[chan->channel].powerdown = powerdown;
> > +
> > + return len;
> > +}
>
> ...
>
> > + .num_banks = ARRAY_SIZE(ad3532r_if_config),
>
> Also check if array_size.h is included.
>
> --
> With Best Regards,
> Andy Shevchenko
>
^ permalink raw reply
* Re: [PATCH v3 1/2] iio: imu: inv_icm42600: reorder includes for buffer module
From: Jean-Baptiste Maneyrol @ 2026-06-25 9:03 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Jonathan Cameron, David Lechner, Nuno Sá, Andy Shevchenko,
linux-iio@vger.kernel.org, linux-kernel@vger.kernel.org
In-Reply-To: <ajzRX7Zr7BzUJFNb@ashevche-desk.local>
>From: Andy Shevchenko <andriy.shevchenko@intel.com>
>Sent: Thursday, June 25, 2026 08:57
>To: Jean-Baptiste Maneyrol
>Cc: Jonathan Cameron; David Lechner; Nuno Sá; Andy Shevchenko; linux-iio@vger.kernel.org; linux-kernel@vger.kernel.org
>Subject: Re: [PATCH v3 1/2] iio: imu: inv_icm42600: reorder includes for buffer module
>
>On Thu, Jun 25, 2026 at 09: 56: 01AM +0300, Andy Shevchenko wrote: > On Thu, Jun 25, 2026 at 09: 49: 47AM +0300, Andy Shevchenko wrote: > > On Wed, Jun 24, 2026 at 06: 21: 18PM +0200, Jean-Baptiste Maneyrol via B4 Relay wrote: > > >
>ZjQcmQRYFpfptBannerStart
>This Message Is From an External Sender
>This message came from outside your organization.
>
>ZjQcmQRYFpfptBannerEnd
>
>On Thu, Jun 25, 2026 at 09:56:01AM +0300, Andy Shevchenko wrote:
>> On Thu, Jun 25, 2026 at 09:49:47AM +0300, Andy Shevchenko wrote:
>> > On Wed, Jun 24, 2026 at 06:21:18PM +0200, Jean-Baptiste Maneyrol via B4 Relay wrote:
>> >
>> > > Reorder includes following rules and delete unneeded kernel.h.
>> >
>> > Actually it's needed as 'proxy' header. If you want to get rid of it, it should
>> > be another patch to replace that with the used headers following IWYU
>> > principle.
>> >
>> > Suggested-by: Andy Shevchenko <andriy.shevchenko@intel.com>
>>
>> Also for the consistency's sake this should be done in all files in that
>> folder. I see the same issue(s) in the _gyro and _accel and I assume the rest
>> *.c and *.h also might be updated.
>
>For the simplicity, just sort the each group of headers in all files. The IWYU
>can be applied later on as it's not in the scope of your series.
>
>--
>With Best Regards,
>Andy Shevchenko
>
Hello Andy,
no problem, I will do that in the next version.
Thanks,
JB
^ permalink raw reply
* Re: [PATCH RFC 2/3] dmaengine: dma-axi-dmac: Switch to bitmap-based address width masks
From: Nuno Sá @ 2026-06-25 8:54 UTC (permalink / raw)
To: Frank Li
Cc: Andy Shevchenko, nuno.sa, dmaengine, linux-iio, Vinod Koul,
Frank Li, Lars-Peter Clausen, Jonathan Cameron, David Lechner,
Andy Shevchenko
In-Reply-To: <ajwKq0CB8sGdvvcO@SMW015318>
On Wed, Jun 24, 2026 at 11:49:47AM -0500, Frank Li wrote:
> On Wed, Jun 24, 2026 at 04:33:53PM +0100, Nuno Sá wrote:
> > On Tue, Jun 23, 2026 at 01:27:37PM +0300, Andy Shevchenko wrote:
> > > On Tue, Jun 23, 2026 at 11:14:51AM +0100, Nuno Sá wrote:
> > > > On Mon, Jun 22, 2026 at 01:34:39PM -0500, Frank Li wrote:
> > > > > On Mon, Jun 22, 2026 at 05:09:10PM +0100, Nuno Sá wrote:
> > > > > > On Mon, Jun 22, 2026 at 09:51:46AM -0500, Frank Li wrote:
> > > > > > > On Mon, Jun 22, 2026 at 10:26:41AM +0100, Nuno Sá wrote:
> > >
> > > ...
> > >
> > > > > If support 4Byte, it native supportted any N*4Byte.
> > > > >
> > > > > So needn't bit mask to indicate all support bytes.
> > > >
> > > > > > > each transfer, dma_slave_cfg should set specific bus width requirement.
> > > > > > >
> > > > > > > If memory have requirement for 32bytes, typical cache line length for
> > > > > > > hardwaer coherence transfer, it should use dmaengine_alignment.
> > > > > > >
> > > > > > > So I think only need set min value should be enough if fix pcm_dmaegine.c.
> > > > > >
> > > > > > What fix for pcm_dmaegine.c? Not sure there's anything to be fixed in
> > > > > > there... The code seems to use the dma bus width to match against PCM
> > > > > > formats supported and filter only the ones we can support (per dma cap).
> > > > >
> > > > > if cap is one byte, it should support 8, 16, 24, 32, 64
> > > > > if cap is two byte, it should support 16, 32, 64
> > > > > if cap is 4 byte, it only support 32 and 64.
> > > >
> > > > Well, Now I see your point but not exactly. Because we do have
> > > >
> > > > DMA_SLAVE_BUSWIDTH_3_BYTES
> > > >
> > > > and it might be used by the pcm_dmaengine code,
> > > >
> > > > There are also some controllers that set it. But it looks like all that
> > > > set it also set 1byte.
> > >
> > > But this might be not true for all HW in the world. In previous reply I made
> > > a comparison with MMIO accesses where not all HW that needs 1-byte read can
> > > cope with that. If there is some proof that this is the case when 1-byte
> > > DMA bus implies 3-bytes (or other odd number), I would like to see it.
> >
> > True. I'm also not too keen in making the above assumption and have no
> > proof that it will work for the controllers we support.
>
> Okay, I think it is fine by use bitmask. suggest change name to
> src_bus_widths, addr_wdiths is quite confused.
Ack
>
> And since not much place use it. suggest change all consumers and cleanup
> original u32 src_addr_widths in followup patches.
>
Alright! Will include all consumers conversion in followups of the
initial patchset!
Thx!
- Nuno Sá
>
>
> >
> > - Nuno Sá
> >
> > >
> > > > So your suggestion might still hold and work but I'm not too convinced
> > > > that having the array complicates things that bad when compared with the
> > > > risk of breaking existing code.
> > >
> > > > > Needn't mask each bit.
> > >
> > > --
> > > With Best Regards,
> > > Andy Shevchenko
> > >
> > >
^ permalink raw reply
* Re: [PATCH v2] iio: temperature: Build mlx90635 with CONFIG_MLX90635
From: Crt Mori @ 2026-06-25 7:54 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Pengpeng Hou, Jonathan Cameron, David Lechner, Nuno Sa,
Andy Shevchenko, linux-iio, linux-kernel, stable
In-Reply-To: <ajzOA3MGaCqrgCDp@ashevche-desk.local>
Thanks for spotting this Pengpeng Hou; it's strange that nobody
noticed until now. I would like to apologize to everyone for this
mistake.
Acked-by: Crt Mori <cmo@melexis.com>
On Thu, 25 Jun 2026 at 08:43, Andy Shevchenko
<andriy.shevchenko@intel.com> wrote:
>
> On Thu, Jun 25, 2026 at 01:42:59PM +0800, Pengpeng Hou wrote:
> > drivers/iio/temperature/Kconfig has a dedicated MLX90635 option, but
> > the Makefile currently builds mlx90635.o under CONFIG_MLX90632.
> >
> > This means enabling CONFIG_MLX90635 alone does not carry its provider
> > object into the build, while enabling CONFIG_MLX90632 unexpectedly also
> > builds mlx90635.o.
> >
> > Gate mlx90635.o on the matching generated Kconfig symbol.
>
> Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com>
>
> --
> With Best Regards,
> Andy Shevchenko
>
>
^ permalink raw reply
* Re: [PATCH v16 04/14] lib: kstrtox: add initial value to _parse_integer_limit()
From: Rodrigo Alencar @ 2026-06-25 7:30 UTC (permalink / raw)
To: Jonathan Cameron, Rodrigo Alencar
Cc: rodrigo.alencar, linux-kernel, linux-iio, devicetree, linux-doc,
linux, David Lechner, Andy Shevchenko, Lars-Peter Clausen,
Michael Hennerich, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Jonathan Corbet, Andrew Morton, Petr Mladek, Steven Rostedt,
Andy Shevchenko, Rasmus Villemoes, Sergey Senozhatsky, Shuah Khan
In-Reply-To: <20260624155414.61755e9a@jic23-huawei>
On 24/06/26 15:54, Jonathan Cameron wrote:
> On Sun, 14 Jun 2026 21:00:44 +0100
> Jonathan Cameron <jic23@kernel.org> wrote:
>
> > On Thu, 4 Jun 2026 11:09:33 +0100
> > Rodrigo Alencar <455.rodrigo.alencar@gmail.com> wrote:
> >
> > > On 26/06/04 10:58AM, Rodrigo Alencar via B4 Relay wrote:
> > > > From: Rodrigo Alencar <rodrigo.alencar@analog.com>
> > > >
> > > > Add init parameter to _parse_integer_limit() that defines an initial
> > > > value for the accumulated result when parsing an 64-bit integer. The
> > > > new function prototype is adjusted so that the _parse_integer() macros
> > > > stay consistent allowing for one more argument, which defaults to 0.
> > >
> > > ...
> > >
> > > > noinline
> > > > unsigned int _parse_integer_limit(const char *s, unsigned int base, unsigned long long *p,
> > > > - size_t max_chars)
> > > > + size_t max_chars, unsigned long long init)
> > > > {
> > > > unsigned long long res;
> > > > unsigned int rv;
> > > >
> > > > - res = 0;
> > > > + res = init;
> > >
> > > This might generate conflict, as the code around have changed in linux-next.
> > > It is an easy fix though.
> > >
> > Thanks for the heads up. Hopefully that will all fall out when I rebase testing
> > on rc1 once that is out.
> I've done a mid merge cycle rebase as the char-misc branches have merged.
> So this should be resolve on my testing branch now.
https://lore.kernel.org/oe-kbuild-all/202606250230.etPGuolf-lkp@intel.com/
Apparently, the documentation header now includes parameter descriptions.
The new one is missing.
--
Kind regards,
Rodrigo Alencar
^ permalink raw reply
* Re: [PATCH v5 07/14] mfd: lm3533: Use dev_groups in struct device_driver
From: Andy Shevchenko @ 2026-06-25 7:26 UTC (permalink / raw)
To: Svyatoslav Ryhel
Cc: Lee Jones, Daniel Thompson, Jingoo Han, Pavel Machek, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Jonathan Cameron,
David Lechner, Nuno Sá, Andy Shevchenko, Helge Deller,
Johan Hovold, dri-devel, linux-leds, devicetree, linux-kernel,
linux-iio, linux-fbdev
In-Reply-To: <ajzXidQCd8pe-L5b@ashevche-desk.local>
On Thu, Jun 25, 2026 at 10:24:00AM +0300, Andy Shevchenko wrote:
> On Wed, Jun 17, 2026 at 11:00:24AM +0300, Svyatoslav Ryhel wrote:
...
> > .attrs = lm3533_attributes
> > };
> >
> > +static const struct attribute_group *lm3533_attribute_groups[] = {
> > + &lm3533_attribute_group,
> > + NULL,
> > +};
>
> We have ATTRIBUTE_GROUPS() macro.
Okay, it uses is_visible, so __ATTRIBUTE_GROUPS() that we can still use.
...
> > +++ b/drivers/video/backlight/lm3533_bl.c
>
> Same as per above.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH v5 07/14] mfd: lm3533: Use dev_groups in struct device_driver
From: Andy Shevchenko @ 2026-06-25 7:23 UTC (permalink / raw)
To: Svyatoslav Ryhel
Cc: Lee Jones, Daniel Thompson, Jingoo Han, Pavel Machek, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Jonathan Cameron,
David Lechner, Nuno Sá, Andy Shevchenko, Helge Deller,
Johan Hovold, dri-devel, linux-leds, devicetree, linux-kernel,
linux-iio, linux-fbdev
In-Reply-To: <20260617080031.99156-8-clamor95@gmail.com>
On Wed, Jun 17, 2026 at 11:00:24AM +0300, Svyatoslav Ryhel wrote:
> Instead of creating and removing the device sysfs attributes directly
> during probe and remove of the driver, respectively, use dev_groups in
> struct device_driver to point to the attribute definitions and let the
> core take care of creating and removing them.
>
> No intentional functional impact.
Suggested-by: Andy Shevchenko <andriy.shevchenko@intel.com>
And thanks for doing that!
...
> .attrs = lm3533_attributes
> };
>
> +static const struct attribute_group *lm3533_attribute_groups[] = {
> + &lm3533_attribute_group,
> + NULL,
> +};
We have ATTRIBUTE_GROUPS() macro.
...
> +++ b/drivers/video/backlight/lm3533_bl.c
Same as per above.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH 0/3] iio: light: al3xxx: add missing REGMAP_I2C to Kconfig entries
From: Andy Shevchenko @ 2026-06-25 7:01 UTC (permalink / raw)
To: Joshua Crofts
Cc: Jonathan Cameron, David Lechner, Nuno Sá, Andy Shevchenko,
Svyatoslav Ryhel, David Heidelberg, linux-iio, linux-kernel
In-Reply-To: <20260625085329.00007959@gmail.com>
On Thu, Jun 25, 2026 at 08:53:29AM +0200, Joshua Crofts wrote:
> On Thu, 25 Jun 2026 09:41:31 +0300
> Andy Shevchenko <andriy.shevchenko@intel.com> wrote:
> > On Thu, Jun 25, 2026 at 07:20:42AM +0200, Joshua Crofts wrote:
> > > This series adds REGMAP_I2C support to three AL3xxx ambient light
> > > sensors that were previously missing this dependency, causing build
> > > failures.
> >
> > There are two problems with the commit message:
> > - SELECT versus select (see the comment against patch 1)
> > - you mentioned build failures but haven't provided any evidence, please
> > provide a reasonable lines of build output to prove that
> Sure, I could elaborate a bit more.
>
> Just run `make allnoconfig` and `make menuconfig` in which you select
> IIO, I2C and any AL3xxx sensor and `make .` will fail with errors such as
>
> drivers/iio/light/al3010.c: In function ‘al3010_probe’:
> drivers/iio/light/al3010.c:185:24: error: implicit declaration of function ‘devm_regmap_init_i2c’ [-Wimplicit-function-declaration]
> 185 | data->regmap = devm_regmap_init_i2c(client, &al3010_regmap_config);
> | ^~~~~~~~~~~~~~~~~~~~
> drivers/iio/light/al3010.c:185:22: error: assignment to ‘struct regmap *’ from ‘int’ makes pointer from integer without a cast [-Wint-conversion]
> 185 | data->regmap = devm_regmap_init_i2c(client, &al3010_regmap_config);
> | ^
> drivers/iio/light/al3010.c: At top level:
> drivers/iio/light/al3010.c:48:35: error: storage size of ‘al3010_regmap_config’ isn’t known
> 48 | static const struct regmap_config al3010_regmap_config = {
> | ^~~~~~~~~~~~~~~~~~~~
>
> Hopefully this is enough.
Yes, put it into the cover letter of the v2.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH v3 1/2] iio: imu: inv_icm42600: reorder includes for buffer module
From: Andy Shevchenko @ 2026-06-25 6:57 UTC (permalink / raw)
To: jean-baptiste.maneyrol
Cc: Jonathan Cameron, David Lechner, Nuno Sá, Andy Shevchenko,
linux-iio, linux-kernel
In-Reply-To: <ajzQ_FUr--jTxYWr@ashevche-desk.local>
On Thu, Jun 25, 2026 at 09:56:01AM +0300, Andy Shevchenko wrote:
> On Thu, Jun 25, 2026 at 09:49:47AM +0300, Andy Shevchenko wrote:
> > On Wed, Jun 24, 2026 at 06:21:18PM +0200, Jean-Baptiste Maneyrol via B4 Relay wrote:
> >
> > > Reorder includes following rules and delete unneeded kernel.h.
> >
> > Actually it's needed as 'proxy' header. If you want to get rid of it, it should
> > be another patch to replace that with the used headers following IWYU
> > principle.
> >
> > Suggested-by: Andy Shevchenko <andriy.shevchenko@intel.com>
>
> Also for the consistency's sake this should be done in all files in that
> folder. I see the same issue(s) in the _gyro and _accel and I assume the rest
> *.c and *.h also might be updated.
For the simplicity, just sort the each group of headers in all files. The IWYU
can be applied later on as it's not in the scope of your series.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH v3 1/2] iio: imu: inv_icm42600: reorder includes for buffer module
From: Andy Shevchenko @ 2026-06-25 6:55 UTC (permalink / raw)
To: jean-baptiste.maneyrol
Cc: Jonathan Cameron, David Lechner, Nuno Sá, Andy Shevchenko,
linux-iio, linux-kernel
In-Reply-To: <ajzPhi3ymeIBYHRr@ashevche-desk.local>
On Thu, Jun 25, 2026 at 09:49:47AM +0300, Andy Shevchenko wrote:
> On Wed, Jun 24, 2026 at 06:21:18PM +0200, Jean-Baptiste Maneyrol via B4 Relay wrote:
>
> > Reorder includes following rules and delete unneeded kernel.h.
>
> Actually it's needed as 'proxy' header. If you want to get rid of it, it should
> be another patch to replace that with the used headers following IWYU
> principle.
>
> Suggested-by: Andy Shevchenko <andriy.shevchenko@intel.com>
Also for the consistency's sake this should be done in all files in that
folder. I see the same issue(s) in the _gyro and _accel and I assume the rest
*.c and *.h also might be updated.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH v3 2/2] iio: imu: inv_icm42600: add buffer hwfifo watermark attributes
From: Andy Shevchenko @ 2026-06-25 6:54 UTC (permalink / raw)
To: jean-baptiste.maneyrol
Cc: Jonathan Cameron, David Lechner, Nuno Sá, Andy Shevchenko,
linux-iio, linux-kernel
In-Reply-To: <20260624-inv-icm42600-add-buffer-hwfifo_attributes-v3-2-5d9a4c662f50@tdk.com>
On Wed, Jun 24, 2026 at 06:21:19PM +0200, Jean-Baptiste Maneyrol via B4 Relay wrote:
> Add hwfifo_watermark/min/max/enabled buffer attributes.
> Hardware FIFO is always enabled and used.
These attributes are already documented and being used by a few drivers.
Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com>
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH 0/3] iio: light: al3xxx: add missing REGMAP_I2C to Kconfig entries
From: Joshua Crofts @ 2026-06-25 6:53 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Jonathan Cameron, David Lechner, Nuno Sá, Andy Shevchenko,
Svyatoslav Ryhel, David Heidelberg, linux-iio, linux-kernel
In-Reply-To: <ajzNmy3Vhh_Zl9Rs@ashevche-desk.local>
On Thu, 25 Jun 2026 09:41:31 +0300
Andy Shevchenko <andriy.shevchenko@intel.com> wrote:
> On Thu, Jun 25, 2026 at 07:20:42AM +0200, Joshua Crofts wrote:
> > This series adds REGMAP_I2C support to three AL3xxx ambient light
> > sensors that were previously missing this dependency, causing build
> > failures.
>
> There are two problems with the commit message:
> - SELECT versus select (see the comment against patch 1)
> - you mentioned build failures but haven't provided any evidence, please
> provide a reasonable lines of build output to prove that
>
Sure, I could elaborate a bit more.
Just run `make allnoconfig` and `make menuconfig` in which you select
IIO, I2C and any AL3xxx sensor and `make .` will fail with errors such as
drivers/iio/light/al3010.c: In function ‘al3010_probe’:
drivers/iio/light/al3010.c:185:24: error: implicit declaration of function ‘devm_regmap_init_i2c’ [-Wimplicit-function-declaration]
185 | data->regmap = devm_regmap_init_i2c(client, &al3010_regmap_config);
| ^~~~~~~~~~~~~~~~~~~~
drivers/iio/light/al3010.c:185:22: error: assignment to ‘struct regmap *’ from ‘int’ makes pointer from integer without a cast [-Wint-conversion]
185 | data->regmap = devm_regmap_init_i2c(client, &al3010_regmap_config);
| ^
drivers/iio/light/al3010.c: At top level:
drivers/iio/light/al3010.c:48:35: error: storage size of ‘al3010_regmap_config’ isn’t known
48 | static const struct regmap_config al3010_regmap_config = {
| ^~~~~~~~~~~~~~~~~~~~
Hopefully this is enough.
--
Kind regards
CJD
^ permalink raw reply
* Re: [PATCH v3 1/2] iio: imu: inv_icm42600: reorder includes for buffer module
From: Andy Shevchenko @ 2026-06-25 6:49 UTC (permalink / raw)
To: jean-baptiste.maneyrol
Cc: Jonathan Cameron, David Lechner, Nuno Sá, Andy Shevchenko,
linux-iio, linux-kernel
In-Reply-To: <20260624-inv-icm42600-add-buffer-hwfifo_attributes-v3-1-5d9a4c662f50@tdk.com>
On Wed, Jun 24, 2026 at 06:21:18PM +0200, Jean-Baptiste Maneyrol via B4 Relay wrote:
> Reorder includes following rules and delete unneeded kernel.h.
Actually it's needed as 'proxy' header. If you want to get rid of it, it should
be another patch to replace that with the used headers following IWYU
principle.
Suggested-by: Andy Shevchenko <andriy.shevchenko@intel.com>
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH v2] iio: adc: ti-ads124s08: Return reset GPIO lookup errors
From: Andy Shevchenko @ 2026-06-25 6:47 UTC (permalink / raw)
To: Pengpeng Hou
Cc: Jonathan Cameron, David Lechner, Nuno Sa, Andy Shevchenko,
Dan Murphy, linux-iio, linux-kernel, stable, Joshua Crofts
In-Reply-To: <20260625054407.82228-1-pengpeng@iscas.ac.cn>
On Thu, Jun 25, 2026 at 01:44:07PM +0800, Pengpeng Hou wrote:
> devm_gpiod_get_optional() returns NULL when the optional GPIO is absent,
> but returns an ERR_PTR when the GPIO provider lookup fails, including
> probe deferral.
>
> Probe currently logs the ERR_PTR case as if the reset GPIO were simply
> absent and keeps the error pointer in reset_gpio. Later ads124s_reset()
> treats any non-NULL reset_gpio as a valid descriptor and passes it to
> gpiod_set_value_cansleep().
The GPIOLIB code will print an error message each time that's called.
This might flood the logs with a noise.
> Return the lookup error instead of retaining the ERR_PTR.
Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com>
It's good as a fix for backport, but can you consider switching to use reset
framework and reset-gpio driver instead? (As a separate change on top of this
one.)
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH 1/3] iio: light: al3000a: add missing REGMAP_I2C to Kconfig
From: Joshua Crofts @ 2026-06-25 6:43 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Jonathan Cameron, David Lechner, Nuno Sá, Andy Shevchenko,
Svyatoslav Ryhel, David Heidelberg, linux-iio, linux-kernel
In-Reply-To: <ajzNMwT8Y640fnw_@ashevche-desk.local>
On Thu, 25 Jun 2026 09:39:47 +0300
Andy Shevchenko <andriy.shevchenko@intel.com> wrote:
> On Thu, Jun 25, 2026 at 07:20:43AM +0200, Joshua Crofts wrote:
> > The KConfig entry for the al3000a is missing a `SELECT REGMAP_I2C`,
>
> SELECT is not a SQL term here, but Kconfig, hence small letters only.
>
> > causing build failures.
>
Haha, good point. Will fix.
--
Kind regards
CJD
^ permalink raw reply
* Re: [PATCH v2] iio: temperature: Build mlx90635 with CONFIG_MLX90635
From: Andy Shevchenko @ 2026-06-25 6:43 UTC (permalink / raw)
To: Pengpeng Hou
Cc: Jonathan Cameron, David Lechner, Nuno Sa, Andy Shevchenko,
Crt Mori, linux-iio, linux-kernel, stable
In-Reply-To: <20260625054259.76774-1-pengpeng@iscas.ac.cn>
On Thu, Jun 25, 2026 at 01:42:59PM +0800, Pengpeng Hou wrote:
> drivers/iio/temperature/Kconfig has a dedicated MLX90635 option, but
> the Makefile currently builds mlx90635.o under CONFIG_MLX90632.
>
> This means enabling CONFIG_MLX90635 alone does not carry its provider
> object into the build, while enabling CONFIG_MLX90632 unexpectedly also
> builds mlx90635.o.
>
> Gate mlx90635.o on the matching generated Kconfig symbol.
Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com>
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH 0/3] iio: light: al3xxx: add missing REGMAP_I2C to Kconfig entries
From: Andy Shevchenko @ 2026-06-25 6:41 UTC (permalink / raw)
To: Joshua Crofts
Cc: Jonathan Cameron, David Lechner, Nuno Sá, Andy Shevchenko,
Svyatoslav Ryhel, David Heidelberg, linux-iio, linux-kernel
In-Reply-To: <20260625-fix-al3xxx-kconfig-v1-0-d41cbc0c3cf4@gmail.com>
On Thu, Jun 25, 2026 at 07:20:42AM +0200, Joshua Crofts wrote:
> This series adds REGMAP_I2C support to three AL3xxx ambient light
> sensors that were previously missing this dependency, causing build
> failures.
There are two problems with the commit message:
- SELECT versus select (see the comment against patch 1)
- you mentioned build failures but haven't provided any evidence, please
provide a reasonable lines of build output to prove that
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH 1/3] iio: light: al3000a: add missing REGMAP_I2C to Kconfig
From: Andy Shevchenko @ 2026-06-25 6:39 UTC (permalink / raw)
To: Joshua Crofts
Cc: Jonathan Cameron, David Lechner, Nuno Sá, Andy Shevchenko,
Svyatoslav Ryhel, David Heidelberg, linux-iio, linux-kernel
In-Reply-To: <20260625-fix-al3xxx-kconfig-v1-1-d41cbc0c3cf4@gmail.com>
On Thu, Jun 25, 2026 at 07:20:43AM +0200, Joshua Crofts wrote:
> The KConfig entry for the al3000a is missing a `SELECT REGMAP_I2C`,
SELECT is not a SQL term here, but Kconfig, hence small letters only.
> causing build failures.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH v5 1/3] dt-bindings: iio: health: add adi,max86150
From: Krzysztof Kozlowski @ 2026-06-25 6:33 UTC (permalink / raw)
To: Md Shofiqul Islam
Cc: linux-iio, jic23, lars, conor, conor+dt, robh, krzk+dt,
devicetree, linux-kernel
In-Reply-To: <20260623201124.18271-2-shofiqtest@gmail.com>
On Tue, Jun 23, 2026 at 11:11:21PM +0300, Md Shofiqul Islam wrote:
Do not attach (thread) your patchsets to some other threads (unrelated
or older versions). This buries them deep in the mailbox and might
interfere with applying entire sets. See also:
https://elixir.bootlin.com/linux/v6.16-rc2/source/Documentation/process/submitting-patches.rst#L830
> + reg:
> + maxItems: 1
> +
> + interrupts:
> + maxItems: 1
> + description: |
Do not need '|' unless you need to preserve formatting.
> + Active-low interrupt line. Asserted when the FIFO almost-full
> + threshold is reached or when a new PPG sample is ready.
> +
> + vdd-supply:
vdddig? Which supply is this?
> + description: Digital core power supply (1.8 V).
> +
> + avdd-supply:
I cannot find it in datasheet.
> + description: Analog core power supply (1.8 V).
> +
> + vref-supply:
> + description: ECG reference voltage supply.
> +
> + leds-supply:
Datasheet calls this VLED. Don't invent names.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 1/2] iio: dac: dac8163: Add driver for DAC8163
From: Andy Shevchenko @ 2026-06-25 6:18 UTC (permalink / raw)
To: Lukas
Cc: Jonathan Cameron, David Lechner, Nuno Sá, Andy Shevchenko,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, linux-kernel,
linux-iio, devicetree
In-Reply-To: <ajvt5J5Cs5cOdTLt@berta-MS-7693>
On Wed, Jun 24, 2026 at 04:47:00PM +0200, Lukas wrote:
> On Tue, Jun 23, 2026 at 10:39:23PM +0300, Andy Shevchenko wrote:
>
> > > + dev_dbg(dev, "%s: val=%d val2=%d\n", __func__, val, val2);
> >
> > No. Is it RFC? PoC? Or production-ready? If not the latter, come when it will
> > be production-ready.
>
> I will remove the debug print. I tried my best to make this driver production-ready.
> I saw that other drivers also have similar debug messages so i didnt
> remove it after my first tests and thought it is ok to leave it in
> there.
Debug messages are different. And in IIO we don't have them (perhaps some
historical leftovers or corner cases, dunno). If you have an example, share
the pointer, I will check that. Perhaps we can drop them in that driver.
(The debug prints like above are fine in the drivers in staging, but staging
is not really accepting much nowadays, so it's not the point.)
> My intention was to try to apply the suggestions and comments i
> get and send a second revision. Do you think thats the right way?
That's the way how it goes. You address all or almost all comments,
send a new version where in the comments you need to explain the
non-addressed pieces ("why?" they haven't been addressed).
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox