RE: [PATCH 0/2] iio: dac: add support for AD5413

[Tsao, Bruce]

On Mon, Nov 02, 2026 at 10:52:22AM +0000, Nuno Sá wrote:
> If the differences boil down to what was stated in here, seems to me to
> merging the device in the existing driver is very much doable and right.

Thanks, both -- that's a fair call. I'll respin v2 with the AD5413 added as a
variant of ad5758 rather than as a new driver.

My plan is to first refactor ad5758 into a chip_info-based form with no
functional change for the AD5758, then add the AD5413 on top. The per-device
differences (14- vs 16-bit, the output ranges, and the absence of the DC-DC
block) fit naturally into chip_info.

For the CRC I'd handle it per-variant behind a flag: the AD5758 keeps its
current behaviour (CRC disabled at probe, no CRC byte) so existing users are
unaffected, while the AD5413 keeps CRC enabled and appends a CRC-8 to each
frame.

David -- since you have the background here: ad5758 currently carries CRC as a
TODO and disables it at probe, whereas the AD5413 implements per-frame CRC. For
the merged driver, would you prefer (a) keeping the AD5758 CRC-off via the flag
(no behaviour change), or (b) also enabling CRC on the AD5758 to finish that
TODO?

I'll get started on the no-functional-change refactor in the meantime.

Thanks,
Bruce
 
 
-----Original Message-----
From: Sa, Nuno <nuno.sa@xxxxxxxxxx> 
Sent: Monday, November 2, 2026 6:52 PM
To: Andy Shevchenko <andriy.shevchenko@xxxxxxxxx>
Cc: Tsao, Bruce <bruce.tsao@xxxxxxxxxx>; Jonathan Cameron <jic23@xxxxxxxxxx>; linux-iio@xxxxxxxxxxxxxxx; David Lechner <dlechner@xxxxxxxxxxxx>; Andy Shevchenko <andy@xxxxxxxxxx>; Rob Herring <robh@xxxxxxxxxx>; Krzysztof Kozlowski <krzk+dt@xxxxxxxxxx>; Conor Dooley <conor+dt@xxxxxxxxxx>; devicetree@xxxxxxxxxxxxxxx; linux-kernel@xxxxxxxxxxxxxxx
Subject: Re: [PATCH 0/2] iio: dac: add support for AD5413

On Wed, Oct 21, 2026 at 09:19:02AM +0300, Andy Shevchenko wrote:
> On Tue, Oct 20, 2026 at 11:53:53AM +0000, Tsao, Bruce wrote:
> > On Mon, Oct 19, 2026 at 11:46:26AM +0300, Andy Shevchenko wrote:
> > > Why in a brand new driver?
> > 
> > Thanks for taking a look.
> > 
> > The nearest existing driver is ad5758, and the two parts are closely 
> > related at the register level (the DAC_CONFIG RANGE field, 
> > DIGITAL_DIAG, the slew-rate block, the reset and calibration-refresh 
> > keys), so an
> > ad5758 variant is certainly feasible -- that was the first option I 
> > considered.
> > 
> > The differences are a mix of hardware and current implementation:
> > 
> > - Hardware: the AD5758 integrates a DC-DC converter (adi,dc-dc-mode is
> >   mandatory in its DT parse and currently drives channel selection) that
> >   the AD5413 does not have; the AD5413 is also 14-bit rather than 16-bit
> >   and supports a different set of ranges.
> > 
> > - Current implementation: ad5758 disables the SPI CRC at probe, whereas
> >   the AD5413 driver keeps it on and computes a CRC-8 per outgoing frame
> >   (CRC is optional on the AD5413 too); the two also use different reset
> >   APIs.
> > 
> > None of this makes a shared driver impossible -- there's a genuine 
> > common layer (two-stage readback, read-modify-write, the 
> > reset/calibration/slew/output-enable sequences). I went with a 
> > self-contained driver mainly to keep the change off existing ad5758 
> > users and keep the blast radius small, at the cost of some duplication.
> > That's a tradeoff rather than a hard line, so if you or Jonathan 
> > would prefer AD5413 as an ad5758 variant, I'm happy to prototype it; 
> > I'd just like to agree the direction before spinning a v2.
> 
> I also would let David to comment as he has an expertise in the 
> combining drivers (if I'm not mistaken). In any case he is also an 
> official reviewer of IIO and might have some good ideas.
> 
> From my perspective sounds like there is not enough justification for 
> a brand new driver. I remember seeing such a configurations (as per 
> your item 1) just be provided via driver data depending on the compatible line.
> As for your item 2, I saw some development for CRC case in another 
> driver and IIRC David driven that activity and he might give a better view.
> 

Yeah, tbh I did not even questioned using an existing driver (internally). Normally I just assume that work was already done but need to ask the question you did more times :).

If the differences boil down to what was stated in here, seems to me to merging the device in the existing driver is very much doable and right.
Normally, if the register map+ fits, that's a good indication we can integrate the device in an existing driver.

- Nuno Sá

> --
> With Best Regards,
> Andy Shevchenko
> 
>