Re: [PATCH v2 4/4] iio: dac: ad3530r: Add support for AD3532R/AD3532

[Andy Shevchenko]

On Thu, Jun 25, 2026 at 10:07:47AM +0000, Paller, Kim Seer wrote:
> > From: Jonathan Cameron <jic23@xxxxxxxxxx>
> > Sent: Monday, June 22, 2026 12:46 AM
> > On Mon, 15 Jun 2026 13:05:44 +0300
> > Andy Shevchenko <andriy.shevchenko@xxxxxxxxx> wrote:
> > > On Mon, Jun 15, 2026 at 02:20:18PM +0800, Kim Seer Paller wrote:

...

> > > > +#define AD3532R_MAX_REG_ADDR			0x30F9
> > Whilst we are here, Sashiko thinks there is an off by one on that value as it's
> > the lower of the two registers that make up channel 15.
> > https://urldefense.com/v3/__https://sashiko.dev/*/patchset/20260615-iio-
> > ad3532r-support-v2-0-
> > 84a0af8b83fa*40analog.com__;IyU!!A3Ni8CS0y2Y!88afCOStwucx32wuoeR
> > SyZ9GpkZge9YDw5_PIMAf7SLs3OLykUC_qNRDUCnRw7wTwsxiIT1V-
> > R8sH17sTg$
> > It also suggests an existing bug that it would be good to look into.
> 
> I don't think it's off-by-one. INPUT_CHn registers are listed by LSB, so
> channel 15 is 0x30F8 (LSB) / 0x30F9 (MSB).  The driver addresses the MSB and
> the part defaults to descending mode, so the access goes 0x30F9 -> 0x30F8.
> 0x30F9 is also the highest valid address per the datasheet, so max_register
> looks correct same for AD3530R's 0xF9.  Does that match our understanding, or
> am I missing a case?

If it's the value for .max_register in regmap configuration, then it's fine.

> > > Hmm... I dunno if it's better to sort by values (so the "bank" 0 goes
> > > together followed by "bank" 1). Jonathan, what's your preference here?
> > Nuno, David?
> > That is how people will typically check them vs the datasheet so I agree with
> > numeric order.  Maybe with a comment at the top about there effectively
> > being two banks. Many of the registers are effectively copies for the new
> > channels but not all of them, so a macro approach would probably be even
> > more confusing.

-- 
With Best Regards,
Andy Shevchenko