Max22007 dev #3015

jansunil · 2025-11-07T16:33:39Z

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

gastmaier

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,

Documentation/devicetree/bindings/iio/dac/adi,max22007.yaml

drivers/iio/dac/max22007.c

nunojsa · 2025-11-12T09:05:17Z

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

nunojsa

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.

Documentation/devicetree/bindings/iio/dac/adi,max22007.yaml

drivers/iio/dac/max22007.c

jansunil · 2025-11-14T10:50:58Z

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

machschmitt

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.

Documentation/devicetree/bindings/iio/dac/adi,max22007.yaml

machschmitt · 2025-11-19T12:49:43Z

Documentation/devicetree/bindings/iio/dac/adi,max22007.yaml

+  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.


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.

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?

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).

Documentation/devicetree/bindings/iio/dac/adi,max22007.yaml

Documentation/ABI/testing/sysfs-bus-iio-dac-max22007

drivers/iio/dac/max22007.c

nunojsa

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.

Documentation/devicetree/bindings/iio/dac/adi,max22007.yaml

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

drivers/iio/dac/max22007.c

gastmaier

Adding here to also note that to avoid the merge conflicts due to the mirror_ci head, base your work on the common stable commit, in this case

Linux 6.19-rc1 8f0b4cc

drivers/iio/dac/max22007.c

jansunil · 2026-01-14T10:18:30Z

Changelog: Rebased with stable commit: Linux 6.19-rc1 8f0b4cc

When a W-LUN resume fails, its parent devices in the SCSI hierarchy, including the scsi_target, may be runtime suspended. Subsequently, the error handler in ufshcd_recover_pm_error() fails to set the W-LUN device back to active because the parent target is not active. This results in the following errors: google-ufshcd 3c2d0000.ufs: ufshcd_err_handler started; HBA state eh_fatal; ... ufs_device_wlun 0:0:0:49488: START_STOP failed for power mode: 1, result 40000 ufs_device_wlun 0:0:0:49488: ufshcd_wl_runtime_resume failed: -5 ... ufs_device_wlun 0:0:0:49488: runtime PM trying to activate child device 0:0:0:49488 but parent (target0:0:0) is not active Address this by: 1. Ensuring the W-LUN's parent scsi_target is runtime resumed before attempting to set the W-LUN to active within ufshcd_recover_pm_error(). 2. Explicitly checking for power.runtime_error on the HBA and W-LUN devices before calling pm_runtime_set_active() to clear the error state. 3. Adding pm_runtime_get_sync(hba->dev) in ufshcd_err_handling_prepare() to ensure the HBA itself is active during error recovery, even if a child device resume failed. These changes ensure the device power states are managed correctly during error recovery. Signed-off-by: Brian Kao <[email protected]> Tested-by: Brian Kao <[email protected]> Reviewed-by: Bart Van Assche <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Martin K. Petersen <[email protected]>

If allocation of cmd->t_task_cdb fails, it remains NULL but is later dereferenced in the 'err' path. In case of error, reset NULL t_task_cdb value to point at the default fixed-size buffer. Found by Linux Verification Center (linuxtesting.org) with SVACE. Fixes: 9e95fb8 ("scsi: target: Fix NULL pointer dereference") Cc: [email protected] Signed-off-by: Andrey Vatoropin <[email protected]> Reviewed-by: Mike Christie <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Martin K. Petersen <[email protected]>

Avoid scanning SAS/SATA devices in channel 1 when SAS transport is enabled, as the SAS/SATA devices are exposed through channel 0. Signed-off-by: Suganath Prabu S <[email protected]> Signed-off-by: Ranjan Kumar <[email protected]> Link: https://lore.kernel.org/stable/20251120071955.463475-1-suganath-prabu.subramani%40broadcom.com Link: https://patch.msgid.link/[email protected] Signed-off-by: Martin K. Petersen <[email protected]>

If scsi_device_quiesce() returns zero, the function executed successfully. Signed-off-by: Miao Li <[email protected]> Reviewed-by: Johannes Thumshirn <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Martin K. Petersen <[email protected]>

The KMSG_COMPONENT macro is a leftover of the s390 specific "kernel message catalog" from 2008 [1] which never made it upstream. The macro was added to s390 code to allow for an out-of-tree patch which used this to generate unique message ids. Also this out-of-tree doesn't exist anymore. The pattern of how the KMSG_COMPONENT is used was partially also used for non s390 specific code, for whatever reasons. Remove the macro in order to get rid of a pointless indirection. [1] https://lwn.net/Articles/292650/ Signed-off-by: Heiko Carstens <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Martin K. Petersen <[email protected]>

The delayed work item 'imm_tq' is initialized in imm_attach() and scheduled via imm_queuecommand() for processing SCSI commands. When the IMM parallel port SCSI host adapter is detached through imm_detach(), the imm_struct device instance is deallocated. However, the delayed work might still be pending or executing when imm_detach() is called, leading to use-after-free bugs when the work function imm_interrupt() accesses the already freed imm_struct memory. The race condition can occur as follows: CPU 0(detach thread) | CPU 1 | imm_queuecommand() | imm_queuecommand_lck() imm_detach() | schedule_delayed_work() kfree(dev) //FREE | imm_interrupt() | dev = container_of(...) //USE dev-> //USE Add disable_delayed_work_sync() in imm_detach() to guarantee proper cancellation of the delayed work item before imm_struct is deallocated. Fixes: 1da177e ("Linux-2.6.12-rc2") Signed-off-by: Duoming Zhou <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Martin K. Petersen <[email protected]>

A dynamic remove/add storage adapter test hits EEH on PowerPC: EEH: [c00000000004f75c] __eeh_send_failure_event+0x7c/0x160 EEH: [c000000000048444] eeh_dev_check_failure.part.0+0x254/0x650 EEH: [c008000001650678] eeh_readl+0x60/0x90 [ipr] EEH: [c00800000166746c] ipr_cancel_op+0x2b8/0x524 [ipr] EEH: [c008000001656524] ipr_eh_abort+0x6c/0x130 [ipr] EEH: [c000000000ab0d20] scmd_eh_abort_handler+0x140/0x440 EEH: [c00000000017e558] process_one_work+0x298/0x590 EEH: [c00000000017eef8] worker_thread+0xa8/0x620 EEH: [c00000000018be34] kthread+0x124/0x130 EEH: [c00000000000cd64] ret_from_kernel_thread+0x5c/0x64 A PCIe bus trace reveals that a vector of MSI-X is cleared to 0 by irqbalance daemon. If we disable irqbalance daemon, we won't see the issue. With debug enabled in ipr driver: [ 44.103071] ipr: Entering __ipr_remove [ 44.103083] ipr: Entering ipr_initiate_ioa_bringdown [ 44.103091] ipr: Entering ipr_reset_shutdown_ioa [ 44.103099] ipr: Leaving ipr_reset_shutdown_ioa [ 44.103105] ipr: Leaving ipr_initiate_ioa_bringdown [ 44.149918] ipr: Entering ipr_reset_ucode_download [ 44.149935] ipr: Entering ipr_reset_alert [ 44.150032] ipr: Entering ipr_reset_start_timer [ 44.150038] ipr: Leaving ipr_reset_alert [ 44.244343] scsi 1:2:3:0: alua: Detached [ 44.254300] ipr: Entering ipr_reset_start_bist [ 44.254320] ipr: Entering ipr_reset_start_timer [ 44.254325] ipr: Leaving ipr_reset_start_bist [ 44.364329] scsi 1:2:4:0: alua: Detached [ 45.134341] scsi 1:2:5:0: alua: Detached [ 45.860949] ipr: Entering ipr_reset_shutdown_ioa [ 45.860962] ipr: Leaving ipr_reset_shutdown_ioa [ 45.860966] ipr: Entering ipr_reset_alert [ 45.861028] ipr: Entering ipr_reset_start_timer [ 45.861035] ipr: Leaving ipr_reset_alert [ 45.964302] ipr: Entering ipr_reset_start_bist [ 45.964309] ipr: Entering ipr_reset_start_timer [ 45.964313] ipr: Leaving ipr_reset_start_bist [ 46.264301] ipr: Entering ipr_reset_bist_done [ 46.264309] ipr: Leaving ipr_reset_bist_done During adapter reset, ipr device driver blocks config space access but can't block MMIO access for MSI-X entries. There is very small window: irqbalance daemon kicks in during adapter reset before ipr driver calls pci_restore_state(pdev) to restore MSI-X table. irqbalance daemon reads back all 0 for that MSI-X vector in __pci_read_msi_msg(). irqbalance daemon: msi_domain_set_affinity() ->irq_chip_set_affinity_patent() ->xive_irq_set_affinity() ->irq_chip_compose_msi_msg() ->pseries_msi_compose_msg() ->__pci_read_msi_msg(): read all 0 since didn't call pci_restore_state ->irq_chip_write_msi_msg() -> pci_write_msg_msi(): write 0 to the msix vector entry When ipr driver calls pci_restore_state(pdev) in ipr_reset_restore_cfg_space(), the MSI-X vector entry has been cleared by irqbalance daemon in pci_write_msg_msix(). pci_restore_state() ->__pci_restore_msix_state() Below is the MSI-X table for ipr adapter after irqbalance daemon kicked in during adapter reset: Dump MSIx table: index=0 address_lo=c800 address_hi=10000000 msg_data=0 Dump MSIx table: index=1 address_lo=c810 address_hi=10000000 msg_data=0 Dump MSIx table: index=2 address_lo=c820 address_hi=10000000 msg_data=0 Dump MSIx table: index=3 address_lo=c830 address_hi=10000000 msg_data=0 Dump MSIx table: index=4 address_lo=c840 address_hi=10000000 msg_data=0 Dump MSIx table: index=5 address_lo=c850 address_hi=10000000 msg_data=0 Dump MSIx table: index=6 address_lo=c860 address_hi=10000000 msg_data=0 Dump MSIx table: index=7 address_lo=c870 address_hi=10000000 msg_data=0 Dump MSIx table: index=8 address_lo=0 address_hi=0 msg_data=0 ---------> Hit EEH since msix vector of index=8 are 0 Dump MSIx table: index=9 address_lo=c890 address_hi=10000000 msg_data=0 Dump MSIx table: index=10 address_lo=c8a0 address_hi=10000000 msg_data=0 Dump MSIx table: index=11 address_lo=c8b0 address_hi=10000000 msg_data=0 Dump MSIx table: index=12 address_lo=c8c0 address_hi=10000000 msg_data=0 Dump MSIx table: index=13 address_lo=c8d0 address_hi=10000000 msg_data=0 Dump MSIx table: index=14 address_lo=c8e0 address_hi=10000000 msg_data=0 Dump MSIx table: index=15 address_lo=c8f0 address_hi=10000000 msg_data=0 [ 46.264312] ipr: Entering ipr_reset_restore_cfg_space [ 46.267439] ipr: Entering ipr_fail_all_ops [ 46.267447] ipr: Leaving ipr_fail_all_ops [ 46.267451] ipr: Leaving ipr_reset_restore_cfg_space [ 46.267454] ipr: Entering ipr_ioa_bringdown_done [ 46.267458] ipr: Leaving ipr_ioa_bringdown_done [ 46.267467] ipr: Entering ipr_worker_thread [ 46.267470] ipr: Leaving ipr_worker_thread IRQ balancing is not required during adapter reset. Enable "IRQ_NO_BALANCING" flag before starting adapter reset and disable it after calling pci_restore_state(). The irqbalance daemon is disabled for this short period of time (~2s). Co-developed-by: Kyle Mahlkuch <[email protected]> Signed-off-by: Kyle Mahlkuch <[email protected]> Signed-off-by: Wen Xiong <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Martin K. Petersen <[email protected]>

A dynamic remove/add storage adapter test hits EEH on PowerPC: EEH: [c00000000004f77c] __eeh_send_failure_event+0x7c/0x160 EEH: [c000000000048464] eeh_dev_check_failure.part.0+0x254/0x660 EEH: [c000000000934e0c] __pci_read_msi_msg+0x1ac/0x280 EEH: [c000000000100f68] pseries_msi_compose_msg+0x28/0x40 EEH: [c00000000020e1cc] irq_chip_compose_msi_msg+0x5c/0x90 EEH: [c000000000214b1c] msi_domain_set_affinity+0xbc/0x100 EEH: [c000000000206be4] irq_do_set_affinity+0x214/0x2c0 EEH: [c000000000206e04] irq_set_affinity_locked+0x174/0x230 EEH: [c000000000207044] irq_set_affinity+0x64/0xa0 EEH: [c000000000212890] write_irq_affinity.constprop.0.isra.0+0x130/0x150 EEH: [c00000000068868c] proc_reg_write+0xfc/0x160 EEH: [c0000000005adb48] vfs_write+0xf8/0x4e0 EEH: [c0000000005ae234] ksys_write+0x84/0x140 EEH: [c00000000002e994] system_call_exception+0x164/0x310 EEH: [c00000000000bfe8] system_call_vectored_common+0xe8/0x278 The irqbalance daemon kicks in before invoking qla2xxx->slot_reset during the EEH recovery process. irqbalance daemon ->irq_set_affinity() ->msi_domain_set_affinity() ->irq_chip_set_affiinity_parent() ->xive_irq_set_affinity() ->pseries_msi_compose_ms() ->__pci_read_msi_msg() ->irq_chip_compose_msi_msg() In __pci_read_msi_msg(), the first MSI-X vector is set to all F by the irqbalance daemon. pci_write_msg_msix: index=0, lo=ffffffff hi=fffffff IRQ balancing is not required during adapter reset. Enable "IRQ_NO_BALANCING" bit before starting adapter reset and disable it calling pci_restore_state(). The irqbalance daemon is disabled for this short period of time (~2s). Co-developed-by: Kyle Mahlkuch <[email protected]> Signed-off-by: Kyle Mahlkuch <[email protected]> Signed-off-by: Wen Xiong <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Martin K. Petersen <[email protected]>

Replace the raw use of 500 value in schedule_timeout() function with msecs_to_jiffies() to ensure intended value across different kernel configurations regardless of HZ value. Signed-off-by: Shi Hao <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Martin K. Petersen <[email protected]>

When CONFIG_SCSI_UFSHCD=y and CONFIG_RPMB=m, the kernel fails to link with undefined references to ufs_rpmb_probe() and ufs_rpmb_remove(): ld: drivers/ufs/core/ufshcd.c:8950: undefined reference to `ufs_rpmb_probe' ld: drivers/ufs/core/ufshcd.c:10505: undefined reference to `ufs_rpmb_remove' The issue is that RPMB depends on its consumers (MMC, UFS) in Kconfig, which is backwards. This prevents proper module dependency handling when the library is modular but consumers are built-in. Fix by reversing the dependency: - Remove 'depends on MMC || SCSI_UFSHCD' from RPMB Kconfig - Add 'depends on RPMB || !RPMB' to SCSI_UFSHCD Kconfig This allows RPMB to be an independent library while ensuring correct linking in all module/built-in combinations. Fixes: b06b8c4 ("scsi: ufs: core: Add OP-TEE based RPMB driver for UFS devices") Reported-by: kernel test robot <[email protected]> Closes: https://lore.kernel.org/oe-kbuild-all/[email protected]/ Suggested-by: Arnd Bergmann <[email protected]> Cc: Bart Van Assche <[email protected]> Cc: Jens Wiklander <[email protected]> Cc: Ulf Hansson <[email protected]> Signed-off-by: Bean Huo <[email protected]> Reviewed-by: Arnd Bergmann <[email protected]> Reviewed-by: Jens Wiklander <[email protected]> Reviewed-by: Bart Van Assche <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Martin K. Petersen <[email protected]>

…failure scanned in again after probe failed" This reverts commit ab2068a. When probing the exp-attached sata device, libsas/libata will issue a hard reset in sas_probe_sata() -> ata_sas_async_probe(), then a broadcast event will be received after the disk probe fails, and this commit causes the probe will be re-executed on the disk, and a faulty disk may get into an indefinite loop of probe. Therefore, revert this commit, although it can fix some temporary issues with disk probe failure. Signed-off-by: Xingui Yang <[email protected]> Reviewed-by: Jason Yan <[email protected]> Reviewed-by: John Garry <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Martin K. Petersen <[email protected]>

The UFS error handler may be activated before SCSI scanning has started and hence before hba->ufs_device_wlun has been set. Check the hba->ufs_device_wlun pointer before using it. Cc: Peter Wang <[email protected]> Cc: Nitin Rawat <[email protected]> Fixes: e23ef4f ("scsi: ufs: core: Fix error handler host_sem issue") Fixes: f966e02 ("scsi: ufs: core: Fix runtime suspend error deadlock") Signed-off-by: Bart Van Assche <[email protected]> Reviewed-by: Peter Wang <[email protected]> Reviewed-by: Nitin Rawat <[email protected]> Tested-by: Nitin Rawat <[email protected]> #SM8750 Link: https://patch.msgid.link/[email protected] Signed-off-by: Martin K. Petersen <[email protected]>

Commit 08b12cd ("scsi: ufs: core: Switch to scsi_get_internal_cmd()") accidentally introduced a deadlock in the frequency scaling code. ufshcd_clock_scaling_unprepare() may submit a device management command while SCSI command processing is blocked. The deadlock was introduced by using the SCSI core for submitting device management commands (scsi_get_internal_cmd() + blk_execute_rq()). Fix this deadlock by calling blk_mq_unquiesce_tagset() before any device management commands are submitted by ufshcd_clock_scaling_unprepare(). Fixes: 08b12cd ("scsi: ufs: core: Switch to scsi_get_internal_cmd()") Reported-by: Manivannan Sadhasivam <[email protected]> Reported-by: Roger Shimizu <[email protected]> Closes: https://lore.kernel.org/linux-scsi/ehorjaflathzab5oekx2nae2zss5vi2r36yqkqsfjb2fgsifz2@yk3us5g3igow/ Tested-by: Roger Shimizu <[email protected]> Cc: Nitin Rawat <[email protected]> Signed-off-by: Bart Van Assche <[email protected]> Reviewed-by: Peter Wang <[email protected]> Reviewed-by: Nitin Rawat <[email protected]> Tested-by: Alexey Klimov <[email protected]> # RB5 board Link: https://patch.msgid.link/[email protected] Signed-off-by: Martin K. Petersen <[email protected]>

…r_name() If scsi_dh_attached_handler_name() fails to allocate the handler name, dm-multipath (its only caller) assumes there is no attached device handler, and sets the device up incorrectly. Return an error pointer instead, so multipath can distinguish between failure, success where there is no attached device handler, or when the path device is not a SCSI device at all. Signed-off-by: Benjamin Marzinski <[email protected]> Reviewed-by: Martin Wilck <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Martin K. Petersen <[email protected]>

In sas_register_phys(), if an error is triggered in the loop process, we need to roll back the resources that have already been requested. Add sas_unregister_phys() when an error occurs in sas_register_ha(). [mkp: a few coding style tweaks and address John's comment] Signed-off-by: Chaohai Chen <[email protected]> Reviewed-by: John Garry <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Martin K. Petersen <[email protected]>

Initializing automatic __free variables to NULL without need (e.g. branches with different allocations), followed by actual allocation is in contrary to explicit coding rules guiding cleanup.h: "Given that the "__free(...) = NULL" pattern for variables defined at the top of the function poses this potential interdependency problem the recommendation is to always define and assign variables in one statement and not group variable definitions at the top of the function when __free() is used." Code does not have a bug, but is less readable and uses discouraged coding practice, so fix that by moving declaration to the place of assignment. Signed-off-by: Krzysztof Kozlowski <[email protected]> Reviewed-by: Manivannan Sadhasivam <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Martin K. Petersen <[email protected]>

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,ch-func = [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. 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 --- To: Lars-Peter Clausen <[email protected]> To: Michael Hennerich <[email protected]> To: Jonathan Cameron <[email protected]> To: Rob Herring <[email protected]> To: Krzysztof Kozlowski <[email protected]> To: Conor Dooley <[email protected]> To: Jonathan Corbet <[email protected]> Cc: [email protected] Cc: [email protected] Cc: [email protected] Cc: [email protected] Cc: [email protected] Cc: [email protected] Signed-off-by: Janani Sunil <[email protected]> --- Changes in v4: - EDITME: describe what is new in this series revision. - EDITME: use bulletpoints and terse descriptions. - Link to v3: https://lore.kernel.org/r/[email protected] Changes in v3: - Remove node defined for power supplies in the devicetree documentaiton - Made use of CRC8_TABLE_SIZE macro in the crc table definition - Corrected casting of reg address in the SPI read function - Applied reverse christmas tree variable ordering - Added a macro fro the reference voltage and reused the same in the scale factor - Removed usage of 'supplies' in enabling bulk regulator and removed unused variable 'i' - Added step n the probe function to toggle the reset GPIO - Updated spacing in macro definitions - Link to v2: https://lore.kernel.org/r/[email protected]/ Changes in v2: - Wrap commit messages as per coding guidelines - Removed all driver references from the hardware - Update property description for reset-gpio - Removed allOf - Added minimum/maximum limits for channel number in the devicetree binding - Replaced adi,type with adi,ch-func. - Added reference to required supplies in the binding, configured them in the driver - Channels are not a required property anymore. - Replaced instances of 'channel' in macros to just 'ch' - Added trailing commas wherever necessary, removed them as per comments - Add explicit values for enum- max22007_channel_power - Replace channel spec structure member 'iio_chan' with 'iio_chans' - Use spi_write_then_read() API in the max22007_spi_read() API - Check for reg_size ==1 and hardcode the size otherwise - Wrap lines in the driver to 80 characters - Update in-line comment on the resolution - Separate declarations with assignment, from the ones that don't - Update the usage of channel template - Add a local device descriptor to point to the SPI device - Add a transition of the Reset GPIO from low to high in the probe - Make use of regmap_set_bits() instead of regmap_update_bits during CRC Enable function call. - Remove the documentation commit, as it is not needed anymore. - Link to v1: https://lore.kernel.org/r/[email protected] --- b4-submit-tracking --- # This section is used internally by b4 prep for tracking purposes. { "series": { "revision": 4, "change-id": "20260114-max22007-patch-6b5c48e37457", "prefixes": [], "history": { "v3": [ "[email protected]" ] } } }

Devicetree bindings for MAX22007 4-channel 12-bit DAC that drives a voltage or current output on each channel Reviewed-by: Krzysztof Kozlowski <[email protected]> Signed-off-by: Janani Sunil <[email protected]>

Add support for the MAX22007 4 channel DAC that drives a voltage or current output on each channel. Signed-off-by: Janani Sunil <[email protected]>

jansunil requested review from amiclaus and gastmaier November 7, 2025 16:33

jansunil force-pushed the max22007-dev branch from 4ab9538 to bd8314f Compare November 10, 2025 05:41

gastmaier requested changes Nov 10, 2025

View reviewed changes

gastmaier reviewed Nov 10, 2025

View reviewed changes

drivers/iio/dac/max22007.c Outdated Show resolved Hide resolved

gastmaier reviewed Nov 11, 2025

View reviewed changes

drivers/iio/dac/max22007.c Show resolved Hide resolved

jansunil force-pushed the max22007-dev branch from bd8314f to 39b2409 Compare November 12, 2025 13:10

jansunil marked this pull request as ready for review November 12, 2025 13:55

jansunil requested review from CiprianRegus, btogorean, buha, chegbeli, danmois, dbogdan, machschmitt, mhennerich, nunojsa and rbolboac as code owners November 12, 2025 13:55

nunojsa reviewed Nov 12, 2025

View reviewed changes

gastmaier reviewed Nov 13, 2025

View reviewed changes

drivers/iio/dac/max22007.c Outdated Show resolved Hide resolved

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

jansunil force-pushed the max22007-dev branch from bb72180 to 6e82321 Compare November 14, 2025 10:52

machschmitt reviewed Nov 19, 2025

View reviewed changes

nunojsa reviewed Nov 20, 2025

View reviewed changes

jansunil force-pushed the max22007-dev branch 3 times, most recently from b39e6d8 to 7d8c82d Compare December 10, 2025 12:50

gastmaier reviewed Jan 12, 2026

View reviewed changes

github-actions bot force-pushed the mirror_ci/jic23/iio/testing branch 2 times, most recently from 12aeb0c to 7f609d0 Compare January 14, 2026 00:09

jansunil force-pushed the max22007-dev branch from c35c425 to 9be9126 Compare January 14, 2026 10:17

jansunil force-pushed the max22007-dev branch 2 times, most recently from 68a68e9 to 2e9660e Compare January 14, 2026 15:14

github-actions bot force-pushed the mirror_ci/jic23/iio/testing branch from 7f609d0 to 3bef8c7 Compare January 15, 2026 00:00

Brian Kao and others added 20 commits January 15, 2026 10:56

Linux 6.19-rc1

c39ddfa

dt-bindings: iio: dac: Add max22007

4d6945e

Devicetree bindings for MAX22007 4-channel 12-bit DAC that drives a voltage or current output on each channel Reviewed-by: Krzysztof Kozlowski <[email protected]> Signed-off-by: Janani Sunil <[email protected]>

iio: dac: Add MAX22007 DAC driver support

36a3c7f

Add support for the MAX22007 4 channel DAC that drives a voltage or current output on each channel. Signed-off-by: Janani Sunil <[email protected]>

jansunil force-pushed the max22007-dev branch from 2e9660e to 36a3c7f Compare January 15, 2026 10:07

github-actions bot force-pushed the mirror_ci/jic23/iio/testing branch from 3bef8c7 to 692752b Compare January 16, 2026 00:00

Max22007 dev #3015

Are you sure you want to change the base?

Max22007 dev #3015

Uh oh!

Conversation

jansunil commented Nov 7, 2025

PR Description

PR Type

PR Checklist

Uh oh!

gastmaier left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

nunojsa commented Nov 12, 2025

Uh oh!

nunojsa left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

jansunil commented Nov 14, 2025

Uh oh!

machschmitt left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

machschmitt Nov 19, 2025

Choose a reason for hiding this comment

Uh oh!

jansunil Dec 10, 2025

Choose a reason for hiding this comment

Uh oh!

machschmitt Dec 10, 2025

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

nunojsa left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

gastmaier left a comment

Choose a reason for hiding this comment

nunojsa left a comment •

edited

Loading