Re: [PATCH v3 2/2] iio: dac: ad5706r: Add support for AD5706R DAC

[Andy Shevchenko]

On Wed, Mar 25, 2026 at 01:07:44AM +0000, Torreno, Alexis Czezar wrote:
> > > > > Changes since v1:
> > > > >   - Removed PWM, GPIO, clock generator, debugfs, regmap,
> > > > > IIO_BUFFER
> > > >
> > > > Why was regmap removed?! Was it not used?
> > >
> > > As far as I understand it, regmap also gives access to debugfs. When I
> > > removed debugfs I also added regmap as removed.
> > 
> > Not only debugfs, and it's unrelated to the any custom debugfs interfaces in
> > the driver, it's just a feature out-of-the-box of regmap.
> > 
> > > For the spi write/read I am not using regmap as the device has some
> > > features that I think regmap_read/write couldn't support. Namely the
> > > variable data width, as the device only accepts exact amount of clock
> > > cycles. Future patches will also add variable SPI speed.
> > 
> > We have a lot of flexibility in regmap core. Do you think it can be improved /
> > extended to cover the cases like yours?
> 
> To neatly summarize, my needs are: (in future patches)
> 1. SPI read/write can have different frequencies and runtime changeable

How does it related to regmap? Is it dependent on the register?

> 2. SPI data bits needs to be exactly 8bits or 16bits depending on register width

This is solved very easily with regmap, no problem at all (two regmaps with
configuration for 8-bit and 16-bit registers), I believe we have even driver
in kernel that does exactly this.

> 3. DAC Device reads SPI command bits [14:12] for communication, not just chip select

Okay, but I'm not sure how this is a limitation...

> For regmap to be used
> 1. regmap_config would need new read_speed and write_speed entries.
> 2. val_bits must now be changeable depending on the need.
> 3. I think the read/write_flag_mask can do this.
> 
> 1) is relatively easy I think, but am not sure with 2) as it might break other regmap core code
> that already assumes it to be fixed.
> Feels like a lot of work for a niche amount of devices, I may still lean on the opinion of
> keeping regmap as is.

Okay, I leave it to others, for the simplicity we can leave driver as is, but
make sure you put the summary of this into the cover letter, so we will be
crystal clear why regmap hasn't been chosen.

-- 
With Best Regards,
Andy Shevchenko