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

["Nuno Sá" <nuno.sa@analog.com>]

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