Re: [PATCH v2 4/6] iio: amplifiers: ad8366: add device tree support

From: Rodrigo Alencar

Date: Wed Jan 28 2026 - 04:59:49 EST


On 26/01/27 11:21PM, Andy Shevchenko wrote:
> On Mon, Jan 26, 2026 at 01:51:05PM +0000, Rodrigo Alencar via B4 Relay wrote:
>
> > Add device-tree support by dropping the enum ID in favor of extended
> > chip info table, containing:
> > - gain_step, indicating with sign the start of the code range;
> > - num_channels, to indicate the number IIO channels;
> > - pack_code() function to describe how SPI buffer is populated;
> >
> > With this, switch cases on the device type were dropped:
> > - probe() function adjusted accordingly;
> > - Simplified read_raw() and write_raw() callbacks;
>
> > - mutex_lock()/mutex_unlock() replaced for guard(mutex)() to allow
> > moving to early returns;
>
> Shouldn't this be in a separate change? I dunno. Let Jonathan to decide.
>

As read_raw() and write_raw() were refactored, I thought it would not be
a problem. I can drop the change... as it is not a function with many
complicated returns.

>
> > +static size_t ad8366_pack_code(struct ad8366_state *st)
> > +{
> > + u8 ch_a = bitrev8(st->ch[0] & 0x3F);
> > + u8 ch_b = bitrev8(st->ch[1] & 0x3F);
>
> GENMASK() in both cases? But I don't see why ch_a needs this at all,
> isn't the 2 LSBs are not used anyway?

Yes, I can adjust with:

u8 ch_a = bitrev8(st->ch[0]) >> 2;
u8 ch_b = bitrev8(st->ch[1]) >> 2;

st->data[0] = ch_b >> 2;
st->data[1] = (ch_b << 6) | ch_a;

so no need for masking both.

> Also missed header inclusion for this? And also perhaps sorting headers first
> to see what's there and what needs to be updated (ideally another patch to move
> to IWYU principle).

linux/bitrev.h is there, but indeed header includes are not sorted.
I will create a separate patch for that.

>
> > + st->data[0] = ch_b >> 4;
> > + st->data[1] = (ch_b << 4) | (ch_a >> 2);
> > + return 2;
> > +}

--
Kind regards,

Rodrigo Alencar