Re: [PATCH 00/22] Extend device support for AD5686 driver

[Jonathan Cameron <jic23@kernel.org>]

On Wed, 22 Apr 2026 23:28:00 +0300
Andy Shevchenko <andriy.shevchenko@intel.com> wrote:

> On Wed, Apr 22, 2026 at 03:45:34PM +0100, Rodrigo Alencar via B4 Relay wrote:
> > This series adds support for multiple nanoDAC parts, adding triggered
> > buffer and gain control support to the ad5686 DAC driver family, along
> > with a number of driver cleanups and fixes.
> > 
> > Initial patches update the device-tree bindings:
> > - Add compatible entries for missing and new parts;
> > - Add GPIO properties for RESET, GAIN and LDAC pins;
> > - Add missing power supplies properties.  
> 
> > Driver cleanups and fixes:
> > - Refactor include headers (IWYU);
> > - Switch to device managed mutex initialization;
> > - Drop enum chip id in favor of per-device chip_info structs;
> > - Fix voltage reference control on single-channel devices;
> > - Fix powerdown control on dual-channel devices;
> > - Introduce bus ops struct with a sync() operation for batching
> >   bus transfers.
> > 
> > New functionality:
> > - Device support for: AD5316R, AD5675, AD5697R, AD5313R, AD5317R,
> >   AD5674, AD5679, AD5687, AD5687R, AD5689 and AD5689R;
> > - Consume optional reset and new power supplies;
> > - LDAC GPIO handling (active-low, held low when unused);
> > - SPI bus sync() implementation for batching multiple transfers;
> > - Triggered buffer support, leveraging LDAC and sync() to flush
> >   all channel writes atomically;
> > - Gain control support through the scale property.  
> 
> This is rather long series. Please, start from the fixes series first that is
> independent on the features.
> 
> I see here ~3 sequential series. Can we rather do them this way?
> 
> Personally I stopped reviewing on patch 12 (without even opening DT stuff)
> because it's exhaustive. Documentation usually suggests the series to be
> limited by ~15 patches IIRC.
> 
On plus side this one was easier to review than the RFC that Rodrigo
has outstanding so I reviewed this one instead :)

Better split up though as Andy suggests. I'm less bothered than some
about merge window timing, but a set that does 3 different types of
things is never a good thing even if they are all on one driver.

Thanks,

Jonathan