From: Jonathan Cameron <jic23@kernel.org>
To: Marilene Andrade Garcia <marilene.agarcia@gmail.com>
Cc: linux-iio@vger.kernel.org, linux-kernel@vger.kernel.org,
devicetree@vger.kernel.org,
"David Lechner" <dlechner@baylibre.com>,
"Nuno Sá" <nuno.sa@analog.com>,
"Andy Shevchenko" <andy@kernel.org>,
"Lars-Peter Clausen" <lars@metafoo.de>,
"Michael Hennerich" <Michael.Hennerich@analog.com>,
"Rob Herring" <robh@kernel.org>,
"Krzysztof Kozlowski" <krzk+dt@kernel.org>,
"Conor Dooley" <conor+dt@kernel.org>,
"Marcelo Schmitt" <marcelo.schmitt1@gmail.com>,
"Marcelo Schmitt" <Marcelo.Schmitt@analog.com>,
"Ceclan Dumitru" <dumitru.ceclan@analog.com>,
"Jonathan Santos" <Jonathan.Santos@analog.com>,
"Dragos Bogdan" <dragos.bogdan@analog.com>
Subject: Re: [PATCH v1 2/2] iio: adc: Add basic support for MAX14001
Date: Mon, 25 Aug 2025 12:16:32 +0100 [thread overview]
Message-ID: <20250825121632.605b50a2@jic23-huawei> (raw)
In-Reply-To: <2919a00f86c1188b83446853bcb9740138d70f44.1755778212.git.marilene.agarcia@gmail.com>
On Thu, 21 Aug 2025 10:39:07 -0300
Marilene Andrade Garcia <marilene.agarcia@gmail.com> wrote:
> The MAX14001/MAX14002 are configurable, isolated 10-bit ADCs for
> multi-range binary inputs. Besides the ADC readings, the MAX14001/MAX14002
> offers more features, like a binary comparator, a filtered reading that
> can provide the average of the last 2, 4, or 8 ADC readings, and an inrush
> comparator that triggers the inrush current. There is also a fault feature
> that can diagnose seven possible fault conditions. And an option to select
> an external or internal ADC voltage reference.
>
> Add basic support for MAX14001/MAX14002 with the following features:
> - Raw ADC reading.
> - Filtered ADC average reading with the default configuration.
>
> Signed-off-by: Marilene Andrade Garcia <marilene.agarcia@gmail.com>
Given the discussion on the cover letter, perhaps this will need to be
merged with the earlier set. I'll do a quick review anyway!
Fairly minor comments inline. This is in a pretty good state for a v1.
Thanks,
Jonathan
> ---
> MAINTAINERS | 1 +
> drivers/iio/adc/Kconfig | 10 ++
> drivers/iio/adc/Makefile | 1 +
> drivers/iio/adc/max14001.c | 213 +++++++++++++++++++++++++++++++++++++
> 4 files changed, 225 insertions(+)
> create mode 100644 drivers/iio/adc/max14001.c
> diff --git a/drivers/iio/adc/max14001.c b/drivers/iio/adc/max14001.c
> new file mode 100644
> index 000000000000..fb79f3b81e0c
> --- /dev/null
> +++ b/drivers/iio/adc/max14001.c
> @@ -0,0 +1,213 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +/*
> + * MAX14001/MAX14002 SPI ADC driver
> + *
> + * Copyright (c) 2025 Marilene Andrade Garcia <marilene.agarcia@gmail.com>
> + *
> + * Datasheet: https://www.analog.com/media/en/technical-documentation/data-sheets/MAX14001-MAX14002.pdf
> + */
> +
> +#include <asm/unaligned.h>
As per build bot this doesn't work on modern kernels. linux/unaligned.
> +#include <linux/bitfield.h>
> +#include <linux/bitrev.h>
> +#include <linux/module.h>
various headers missing. Please follow approximate include what you use principles.
There are some headers that are obviously going to be included by another one
because they cannot stand alone, so for those you can include just the parent.
E.g. mutex.h not mutex_types.h but in most other cases all includes with definitions
that are used in this file should be here.
> +#include <linux/spi/spi.h>
> +#include <linux/iio/iio.h>
> +#include <linux/regulator/consumer.h>
> +
> +/* MAX14001 registers definition */
> +#define MAX14001_REG_ADC 0x00
> +#define MAX14001_REG_FADC 0x01
> +#define MAX14001_REG_FLAGS 0x02
> +#define MAX14001_REG_FLTEN 0x03
> +#define MAX14001_REG_THL 0x04
> +#define MAX14001_REG_THU 0x05
> +#define MAX14001_REG_INRR 0x06
> +#define MAX14001_REG_INRT 0x07
> +#define MAX14001_REG_INRP 0x08
> +#define MAX14001_REG_CFG 0x09
> +#define MAX14001_REG_ENBL 0x0A
> +#define MAX14001_REG_ACT 0x0B
> +#define MAX14001_REG_WEN 0x0C
> +
> +/* MAX14001 CONTROL values*/
Missing space before */
They are going in the WR field below I'd rename that MASK_W
then you can just 1 and 0 with their boolean meaning and
not bother with these defines.
> +#define MAX14001_REG_WRITE 0x1
> +#define MAX14001_REG_READ 0x0
> +
> +/* MAX14001 MASKS */
The comment isn't very useful. Masks of what? These seems to be
SPI message related. Also no point in prefixing comments
with MAX14001 when the naming makes that clear.
> +#define MAX14001_MASK_ADDR GENMASK(15, 11)
> +#define MAX14001_MASK_WR BIT(10)
> +#define MAX14001_MASK_DATA GENMASK(9, 0)
> +
> +enum max14001_chip_model {
> + max14001,
> + max14002,
> +};
> +
> +struct max14001_chip_info {
> + const char *name;
> +};
> +
> +struct max14001_state {
> + const struct max14001_chip_info *chip_info;
> + struct spi_device *spi;
> + int vref_mv;
> +
> + __be16 rx_buffer __aligned(IIO_DMA_MINALIGN);
> + __be16 tx_buffer;
I'd add a comment on these to mention they are also bit
reversed after we've flipped the bytes to be in the right order.
> +};
> +
> +static struct max14001_chip_info max14001_chip_info_tbl[] = {
> + [max14001] = {
> + .name = "max14001",
> + },
> + [max14002] = {
> + .name = "max14002",
> + },
> +};
> +
> +static int max14001_spi_read(struct max14001_state *st, u16 reg, int *val)
The register map is large enough I'd consider using a custom regmap
as then we can take advantage of caching and the field manipulation
functions that we get from regmap.
> +{
> + struct spi_transfer xfer[] = {
> + {
> + .tx_buf = &st->tx_buffer,
> + .len = sizeof(st->tx_buffer),
> + .cs_change = 1,
> + },
> + {
> + .rx_buf = &st->rx_buffer,
> + .len = sizeof(st->rx_buffer),
> + },
> + };
> + int ret;
> +
No locking? Given use of shared buffers I would suggest you need
a mutex here, the bus lock won't be enough.
> + st->tx_buffer = FIELD_PREP(MAX14001_MASK_ADDR, reg) |
> + FIELD_PREP(MAX14001_MASK_WR, MAX14001_REG_READ);
> + st->tx_buffer = bitrev16(st->tx_buffer);
> +
> + ret = spi_sync_transfer(st->spi, xfer, ARRAY_SIZE(xfer));
> + if (ret < 0)
> + return ret;
> +
> + st->rx_buffer = bitrev16(be16_to_cpu(st->rx_buffer));
> + *val = FIELD_GET(MAX14001_MASK_DATA, st->rx_buffer);
> +
> + return 0;
> +}
> +static const struct spi_device_id max14001_id_table[] = {
> + { "max14001", (kernel_ulong_t)&max14001_chip_info_tbl[max14001] },
> + { "max14002", (kernel_ulong_t)&max14001_chip_info_tbl[max14002] },
> + {}
Trivial but for consistency
{ }
which is the preferred style in IIO. There isn't any general agreement
across the kernel so I picked a choice at random a while back as any choice
is better than a mix like we have here.
> +};
> +MODULE_DEVICE_TABLE(spi, max14001_id_table);
> +
> +static const struct of_device_id max14001_of_match[] = {
> + { .compatible = "adi,max14001",
> + .data = &max14001_chip_info_tbl[max14001], },
> + { .compatible = "adi,max14002",
> + .data = &max14001_chip_info_tbl[max14002], },
> + { }
> +};
> +MODULE_DEVICE_TABLE(of, max14001_of_match);
next prev parent reply other threads:[~2025-08-25 11:16 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-08-21 13:36 [PATCH v1 0/2] Add MAX14001/MAX14002 support Marilene Andrade Garcia
2025-08-21 13:38 ` [PATCH v1 1/2] dt-bindings: iio: adc: Add MAX14001 Marilene Andrade Garcia
2025-10-02 16:25 ` ChaosEsque Team
2025-08-21 13:39 ` [PATCH v1 2/2] iio: adc: Add basic support for MAX14001 Marilene Andrade Garcia
2025-08-22 6:52 ` kernel test robot
2025-08-25 11:16 ` Jonathan Cameron [this message]
2025-08-21 18:06 ` [PATCH v1 0/2] Add MAX14001/MAX14002 support Conor Dooley
2025-08-21 19:24 ` Marcelo Schmitt
2025-08-22 16:25 ` Conor Dooley
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20250825121632.605b50a2@jic23-huawei \
--to=jic23@kernel.org \
--cc=Jonathan.Santos@analog.com \
--cc=Marcelo.Schmitt@analog.com \
--cc=Michael.Hennerich@analog.com \
--cc=andy@kernel.org \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=dlechner@baylibre.com \
--cc=dragos.bogdan@analog.com \
--cc=dumitru.ceclan@analog.com \
--cc=krzk+dt@kernel.org \
--cc=lars@metafoo.de \
--cc=linux-iio@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=marcelo.schmitt1@gmail.com \
--cc=marilene.agarcia@gmail.com \
--cc=nuno.sa@analog.com \
--cc=robh@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox