Skip to content

Conversation

@jansunil
Copy link
Collaborator

@jansunil jansunil commented Nov 7, 2025

PR Description

  • Please replace this comment with a summary of your changes, and add any context
    necessary to understand them. List any dependencies required for this change.
  • To check the checkboxes below, insert a 'x' between square brackets (without
    any space), or simply check them after publishing the PR.
  • If you changes include a breaking change, please specify dependent PRs in the
    description and try to push all related PRs simultaneously.

PR Type

  • Bug fix (a change that fixes an issue)
  • New feature (a change that adds new functionality)
  • Breaking change (a change that affects other repos or cause CIs to fail)

PR Checklist

  • I have conducted a self-review of my own code changes
  • I have compiled my changes, including the documentation
  • I have tested the changes on the relevant hardware
  • I have updated the documentation outside this repo accordingly
  • I have provided links for the relevant upstream lore

Copy link
Contributor

@gastmaier gastmaier left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hi @jansunil overall looks good, just some comments from my side.
I believe we can drop the crc feature and really streamline the driver reg access as a consequence.

Best regards,

@nunojsa
Copy link
Collaborator

nunojsa commented Nov 12, 2025

I'll wait this getting out of draft to jump in :)

Copy link
Collaborator

@nunojsa nunojsa left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Here it goes my first round. Couple more points:

  • In the bindings patch do not day "...Add MAX22007 DAC bindings". I mean, dont mention "bindings". Its already obvious from the prefix. So instead say something like "Document MAX22007 DAC". Also refactor a bit the message and add a small description of the device.
  • Also refactor the driver patch commit message. See git log for other examples. Give a small description of the device. It is also a fairly simple driver so I do not think there is any meaningful to state about the implementation in the commit message.

Regarding process, note that I expect this PR to be opened against main (without the overlay). Then after merged with main, you can open a PR against the PI branch only with the overlay.

@jansunil jansunil force-pushed the max22007-dev branch 2 times, most recently from ae84b9d to bb72180 Compare November 14, 2025 10:42
@jansunil
Copy link
Collaborator Author

Changelog V2:

    1) Remove description for spi max frequency in the yaml
2) Remove "|" character in the yaml
3) Add a default field in the properties wherever required
4) Add regmap in the Kconfig
5) Correct copyright year in the driver
6) Rearrange includes in alphabetical order and add  missing includes
7) Pass SPI buffers into state structure
8) Reformat code to meet 80 column limit
9) Remove redundant masking of buffer elements in max22007_spi_reg_write()
10) Remove locking within APIs
11) Remove explicit function for softreset and use regmap directly
12) Add macros for MAX value check for DAC Raw data
13) Implement custom regmap bus
14) Removed caching of channel configuration as it is not used again
15) Add validation for values passed from devicetree
16) Remove spi_setup
17) Add extra spaces at necessary lines of code
18) Parse CRC value from devicetree inside the max22007_configure_crc()
19) Return error code from max22007_parse_channel_cfg() and add an argument to capture the number of channels
20) Add RESET pin gpio support
21) Switch the CRC functionality to use adi,crc-disable instead of adi,crc-enable
22) Remove CRC from the Tx buffer during SPI read operations
    23) Add ABI documentation for per channel LDAC update

Copy link
Contributor

@machschmitt machschmitt left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hi @jansunil ,

Commenting mostly about the dt docs and proposed ABI. Only superficially looked into the driver code as that might change significantly depending on the discussion about the dt properties and IIO ABI.

Comment on lines 48 to 52
adi,crc-disable:
type: boolean
description:
Disable CRC8 error checking for SPI communications. By default, CRC8 is
enabled for data integrity verification. Set this property to disable it.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I see in the data sheet that SPI transfers can run with CRC disabled (set CRC_EN field to 0x0 within the configuration register (0x03) ). For max22007, CRC is a runtime configuration and has nothing to do with how hardware is set up. Drop this property.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The property here was added so that it enables the user to take a decision on the state of the CRC and not hardcoding it in the driver. Do you still suggest removing the CRC property and hardcoding it in the driver?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's not about hardcoding, it's about hardware description. Devicetree is useful because it follows a specification that makes it easier to describe hardware such that the description is both readable to humans and compilable by machines. Some info clearly relates to the hardware, e.g. pins that have device-specific functionality, specific types of inputs/outputs to/from device pins (clocks, voltage/current supplies, GPIOs, ...), non-conventional hardware connections (e.g. controller CS connected to peripheral SDI), characteristics intrinsic to a design (e.g. max transfer clock frequency, chip address, etc.). Other info might not need to be encoded into the hardware description (note: in some platforms, the only way to update the hardware device tree is with a system reboot).
IMHO, the ideal for MAX22007 CRC would be to have some sort of CRC toggle device property. That way, the user would be able to enable/disable CRC at runtime, and there would be no need to have a CRC property in dt. Though I didn't find any documented ABI for that so it would have to be proposed. An alternative might be to always have CRC checking enabled on initial MAX22007 support.

That said, there is indeed some precedent for CRC dt properties.
regulator/nxp,pf0900.yaml (nxp,i2c-crc-enable)
net/adi,adin1110.yaml (adi,spi-crc)
mtd/qcom,nandc.yaml (qcom,cmd-crci and qcom,data-crci) (looks like CRC but not really sure)
qcom/qcom,gsbi.yaml (qcom,crci) (not sure it's about CRC either)
If you are confident that you do need a CRC dt prop for MAX22007, then please use adi,spi-crc (so we may at least try to keep only a few property names).

Copy link
Collaborator

@nunojsa nunojsa left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Some more comments from me. An additional note regarding commits. Your git subject for the bindings is nok. Please run git log --oneline Documentation/devicetree/bindings/ and follow the sytle.

TomasBorquez and others added 3 commits December 7, 2025 12:43
Remove legacy platform_data support as there are no in tree users and
this approach belongs to a long gone era. The policy decision on what
to output is a userspace problem, not something that should be provided
from firmware.

The driver now initializes the device to a safe state (SLEEP|RESET|CLR)
outputting nothing. Userspace can configure the desired frequencies and
phases via the existing sysfs attributes once the device is ready to be
used.

Original discussion started here [1].

Link: https://lore.kernel.org/linux-iio/20250628161040.3d21e2c4@jic23-huawei/ #[1]
Suggested-by: Jonathan Cameron <jic23@kernel.org>
Signed-off-by: Tomas Borquez <tomasborquez13@gmail.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Support configuring output calibration value. Among the devices
currently supported by this driver, this setting is specific to
ad9434. The offset can be used to calibrate the output against
a known input. The register is called offset, but the procedure
is best mapped internally with calibbias operation.

Reviewed-by: David Lechner <dlechner@baylibre.com>
Signed-off-by: Tomas Melin <tomas.melin@vaisala.com>
Reviewed-by: Nuno Sá <nuno.sa@analog.com>
Reviewed-by: Andy Shevchenko <andy@kernel.org>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
The st_lsm6dsx_event_settings structure contains fields specific for one
event type (wakeup). In preparation for adding support for more event
types, introduce an event id enum and a generic event source structure, and
replace wakeup-specific data in struct st_lsm6dsx_event_settings with an
array of event source structures.

Signed-off-by: Francesco Lavra <flavra@baylibre.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com>
Acked-by: Lorenzo Bianconi <lorenzo@kernel.org>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
amiclaus and others added 9 commits December 13, 2025 16:27
Add support for adl8113 10MHz to 12GHz Low Noise Amplifier with
10MHz to 14GHz bypass switches.

Signed-off-by: Antoniu Miclaus <antoniu.miclaus@analog.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
The device has interrupts allocated according to the datasheet, and
the devicetree already defines the interrupt property. Address existing
warnings by allowing the property.

Signed-off-by: Andrew Jeffery <andrew@codeconstruct.com.au>
Acked-by: Rob Herring (Arm) <robh@kernel.org>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Add documentation for Texas Instruments ADS1018 and ADS1118
analog-to-digital converters.

Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Signed-off-by: Kurt Borja <kuurtb@gmail.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Add ti-ads1018 driver for Texas Instruments ADS1018 and ADS1118 SPI
analog-to-digital converters.

This chips' MOSI pin is shared with a data-ready interrupt. Defining
this interrupt in devicetree is optional, therefore we only create an
IIO trigger if one is found.

Handling this interrupt requires some considerations. When enabling the
trigger the CS line is tied low (active), thus we need to hold
spi_bus_lock() too, to avoid state corruption. This is done inside the
set_trigger_state() callback, to let users use other triggers without
wasting a bus lock.

Reviewed-by: Andy Shevchenko <andy@kernel.org>
Signed-off-by: Kurt Borja <kuurtb@gmail.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
This device has e.g. different scaling values than currently
listed devices.

Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Signed-off-by: Tomas Melin <tomas.melin@vaisala.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Include headers in ascending order.

Signed-off-by: Tomas Melin <tomas.melin@vaisala.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
The AD9211 is a 10-bit monolithic sampling analog-to-digital converter
optimized for high performance, low power, and ease of use. The product
operates at up to a 300 MSPS conversion rate and is optimized for
outstanding dynamic performance in wideband carrier and broadband systems.

The scale table implemented here is not an exact match with the
datasheet as the table presented there is missing some information.
The reference presents these values as being linear,
but that does not add up. There is information missing in the table.
Implemented scale table matches values at the middle and at the ends,
smoothing the curve towards middle and end.
Impact on end result from deviation in scale factor affects only software
using it for scaling. All the possible hw-settings are also available with
this implementation.

Datasheet: https://www.analog.com/media/en/technical-documentation/data-sheets/AD9211.pdf
Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com>
Signed-off-by: Tomas Melin <tomas.melin@vaisala.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Adds binding for digital Honeywell ABP2 series pressure and temperature
sensors.
The i2c address is hardcoded and depends on the part number.
There is an optional interrupt that signals the end of conversion.

Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org>
Signed-off-by: Petre Rodan <petre.rodan@subdimension.ro>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Adds driver for digital Honeywell ABP2 series of board mount
pressure and temperature sensors.

This driver covers 113 different pressure ranges and units on
both i2c and SPI buses.

The communication protocol involves sending two simple commands
to the sensor and there is no register access or a memory map.
For this reason the regmap API was not used.

The i2c address is hardcoded and depends on the part number.

Optional end of conversion interrupt control is present on the
i2c variants of the chips.
The EOC can also be defined for the SPI variants if a non-ABP2
but compatible chip is to be driven.

Tested on two sensors (ABP2MRRT001PDSA3 and ABP2DANT001BA2A3).

ocuments/sps-siot-abp2-series-datasheet-32350268-en.pdf

Datasheet: https://prod-edam.honeywell.com/content/dam/honeywell-edam/sps/siot/en-us/products/sensors/pressure-sensors/board-mount-pressure-sensors/basic-abp2-series/d
Signed-off-by: Petre Rodan <petre.rodan@subdimension.ro>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Copy link
Collaborator

@nunojsa nunojsa left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Some more feedback from me...

@jansunil jansunil force-pushed the max22007-dev branch 2 times, most recently from 180dae0 to c320631 Compare December 16, 2025 14:47
@jansunil
Copy link
Collaborator Author

Changelog:

  1. Remove dts from the commit
  2. output-range-microamp -> adi,type (string property)
  3. CRC configuration in runtime has been removed. It has been defaulted to true.
  4. Removed extra lines
  5. Updated maintainers
  6. Updated the regmap configurations so that the Tx command is built by the regmap config itself, updated the eindianness
  7. Power down API now uses simple if-else structure as suggested
  8. Corrected spacing of multi-line function calls

@jansunil
Copy link
Collaborator Author

Changelog:
Remove rpi-max22007.dtbo entry from makefile

Copy link
Collaborator

@nunojsa nunojsa left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Minor things from me. I think we should be fine to go upstream after addressing my last comments

@jansunil
Copy link
Collaborator Author

Changelog:

  1. Remove explicit assignments for enums
  2. Remove memset of tx and rxbuf in the max22007_spi_read() function
  3. Remove helper function for configuring crc
  4. Remove crc_en member from the device
  5. Added a macro to define the CRC overhead

This patch series introduces support for the Analog Devices MAX22007, a
quad-channel, 12-bit digital-to-analog converter (DAC) with integrated
precision output amplifiers and configurable voltage/current output capability.

**Device Overview:**
The MAX22007 features four independent DAC channels that can each be configured
for either voltage output (0-12.5V) or current output (0-25mA) mode. The device
communicates via SPI interface with built-in CRC8 error checking for data integrity.

**Features Implemented:**
- Support for all 4 DAC channels with 12-bit resolution
- Per-channel voltage/current mode configuration via device tree
  property `adi,type = [voltage, current]`
- Independent power control for each channel (attribute)
- Hardware reset support via GPIO (during probe)
- CRC8 error checking for SPI communication

**Patch Summary:**
1. dt-bindings: Binding documentation with channel configuration
2. documentation: Driver documentation with usage examples
3. driver: Implement IIO DAC driver

**Testing:**
The driver was hardware tested on a Raspberry Pi4 on top of v6.12.y
kernel using the MAX22007EVKIT evaluation board.

Janani Sunil (3):
dt-bindings: iio: dac: Add max22007
iio: dac: Add MAX22007 DAC driver support
docs: iio: Add documentation for MAX22007 driver

   .../bindings/iio/dac/adi,max22007.yaml       | 117 ++++
   Documentation/iio/index.rst                  |   1 +
   Documentation/iio/max22007.rst                | 170 ++++++
   drivers/iio/dac/Kconfig                       |  12 +
   drivers/iio/dac/Makefile                      |   1 +
   drivers/iio/dac/max22007.c                    | 522 ++++++++++++++++++
   6 files changed, 823 insertions(+)
   create mode 100644 Documentation/devicetree/bindings/iio/dac/adi,max22007.yaml
   create mode 100644 Documentation/iio/max22007.rst
   create mode 100644 drivers/iio/dac/max22007.c

---

To: Lars-Peter Clausen <lars@metafoo.de>
To: Michael Hennerich <Michael.Hennerich@analog.com>
To: Alexandru Ardelean <alexandru.ardelean@analog.com>
To: Jonathan Cameron <jic23@kernel.org>
To: Rob Herring <robh@kernel.org>
To: Krzysztof Kozlowski <krzk+dt@kernel.org>
To: Conor Dooley <conor+dt@kernel.org>
To: Jonathan Corbet <corbet@lwn.net>
Cc: linux-iio@vger.kernel.org
Cc: devicetree@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-doc@vger.kernel.org
Signed-off-by: Janani Sunil <janani.sunil@analog.com>

--- b4-submit-tracking ---
# This section is used internally by b4 prep for tracking purposes.
{
  "series": {
    "revision": 1,
    "change-id": "20251219-max22007-dev-1aaf08db7890",
    "prefixes": []
  }
}
@jansunil jansunil changed the base branch from rpi-6.12.y to mirror_ci/jic23/iio/testing December 19, 2025 13:51
@jansunil jansunil force-pushed the max22007-dev branch 2 times, most recently from 4e963a2 to 28afaa5 Compare December 19, 2025 14:15
Devicetree bindings for MAX22007 4-channel
12-bit DAC that drives a voltage or current
output on each channel

Signed-off-by: Janani Sunil <janani.sunil@analog.com>
Add documentation for MAX22007 driver which describes how the user
can access the driver using dtoverlays

Signed-off-by: Janani Sunil <janani.sunil@analog.com>
Add support for the MAX22007 4 channel DAC
that drives a voltage or current output on each channel.

Signed-off-by: Janani Sunil <janani.sunil@analog.com>
@github-actions github-actions bot force-pushed the mirror_ci/jic23/iio/testing branch 3 times, most recently from 9f4f115 to 1e4e20b Compare December 22, 2025 00:01
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.