On 09/06/26 21:15, Andy Shevchenko wrote:
> On Tue, Jun 09, 2026 at 11:13:07AM +0100, Rodrigo Alencar via B4 Relay wrote:
>
> > Most of the supported devices rely on a GAIN pin to control a 2x
> > multiplier applied to the output voltage. Other devices, e.g. the
> > single-channel ones, provides a gain control through a bit field in the
> > control register. Some designs might have the GAIN pin hardwired to
> > VDD/VLOGIC or GND, which would still be fine for this patch, that allows
> > the scale property to be configurable with two available options.
> > vref_mv field is moved down in the ad5686_state struct, so that
>
> Slightly better to use same terminology as in C and documentation, id est
>
> "...the struct ad5686_state, ..."
>
> > overall size increase is reduced.
>
> ...
>
> > + case IIO_CHAN_INFO_SCALE:
> > + if (val == st->scale_avail[0] && val2 == st->scale_avail[1])
> > + st->double_scale = false;
> > + else if (val == st->scale_avail[2] && val2 ==
> > st->scale_avail[3])
> > + st->double_scale = true;
> > + else
> > + return -EINVAL;
> > +
> > + switch (st->chip_info->regmap_type) {
> > + case AD5310_REGMAP:
> > + return ad5310_control_sync(st);
> > + case AD5683_REGMAP:
> > + return ad5683_control_sync(st);
> > + case AD5686_REGMAP:
> > + /*
> > + * Even if the gain pin is hardwired on the board, the
> > + * user is able to control the scale such that it
> > + * matches the actual gain setting.
>
> Rebalance the line lengths to
>
> * Even if the gain pin is hardwired on the board,
> * the user is able to control the scale such that
> * it matches the actual gain setting.
>
> makes it more consistent.
Thanks for looking into this one. I will address sashiko's concern here
as userspace might not be fully aware of hardwired signals.
Will drop this commment.
> > + */
> > + gpiod_set_value_cansleep(st->gain_gpio,
> > + st->double_scale ? 1 : 0);
> > + return 0;
> > + default:
> > + return -EINVAL;
> > + }
> > + default:
> > + return -EINVAL;
> > + }
> > +}
>
> ...
>
> > + unsigned short vref_mv;
>
> _mV
Renaming would need to be a separate refactoring patch. I'll just keep
as is and just have the field moved down.
--
Kind regards,
Rodrigo Alencar
