| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <9f1ba4d9-8a94-4445-988a-56725a197a1c@vaisala.com>
Date: Tue, 2 Dec 2025 12:20:51 +0200
From: Tomas Melin <tomas.melin@...sala.com>
To: David Lechner <dlechner@...libre.com>,
Lars-Peter Clausen <lars@...afoo.de>,
Michael Hennerich <Michael.Hennerich@...log.com>,
Nuno Sa <nuno.sa@...log.com>, Jonathan Cameron <jic23@...nel.org>,
Andy Shevchenko <andy@...nel.org>,
Alexandru Ardelean <alexandru.ardelean@...log.com>
Cc: Jonathan Cameron <Jonathan.Cameron@...wei.com>,
linux-iio@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2/2] iio: adc: ad9467: support write/read offset
Hi David,
On 01/12/2025 19:40, David Lechner wrote:
> On 12/1/25 5:59 AM, Tomas Melin wrote:
>> Support configuring output offset value. Among the devices
>> currently supported by this driver, this setting is specific to
>> ad9434.
>
> What is the purpose of adjusting the offset. If it is to compensate
> e.g. for manufacturing variations, the CALIBBIAS might be a better
> choice. In any case, the commit message should explain a bit better
> the intended use.
This is indeed more of a calibration. It should compensate for
difference between expected and actual output. I agree that the
CALIBBIAS seems to be a better fit.
>
>>
>> Signed-off-by: Tomas Melin <tomas.melin@...sala.com>
>> ---
>> drivers/iio/adc/ad9467.c | 58 +++++++++++++++++++++++++++++++++++++++++++++++-
>> 1 file changed, 57 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/iio/adc/ad9467.c b/drivers/iio/adc/ad9467.c
>> index 2910b6c5b576d101a25c0b5f0fb9024f0b4da63d..41b29e9e765b4296358bb277d63993889ce46290 100644
>> --- a/drivers/iio/adc/ad9467.c
>> +++ b/drivers/iio/adc/ad9467.c
>> @@ -145,6 +145,7 @@ struct ad9467_chip_info {
>> unsigned int num_lanes;
>> unsigned int dco_en;
>> unsigned int test_points;
>> + const int *offset_range;
>> /* data clock output */
>> bool has_dco;
>> bool has_dco_invert;
>> @@ -234,6 +235,10 @@ static int ad9467_reg_access(struct iio_dev *indio_dev, unsigned int reg,
>> return 0;
>> }
>>
>> +static const int ad9434_offset_range[] = {
>> + -128, 1, 127,
>> +};
>> +
>> static const unsigned int ad9265_scale_table[][2] = {
>> {1250, 0x00}, {1500, 0x40}, {1750, 0x80}, {2000, 0xC0},
>> };
>> @@ -281,6 +286,23 @@ static void __ad9467_get_scale(struct ad9467_state *st, int index,
>> *val2 = tmp % 1000000;
>> }
>>
>> +#define AD9434_CHAN(_chan, avai_mask, _si, _bits, _sign) \
>> +{ \
>> + .type = IIO_VOLTAGE, \
>> + .indexed = 1, \
>> + .channel = _chan, \
>> + .info_mask_shared_by_type = BIT(IIO_CHAN_INFO_SCALE) | \
>> + BIT(IIO_CHAN_INFO_SAMP_FREQ) | \
>> + BIT(IIO_CHAN_INFO_OFFSET), \
>> + .info_mask_shared_by_type_available = avai_mask, \
>> + .scan_index = _si, \
>> + .scan_type = { \
>> + .sign = _sign, \
>> + .realbits = _bits, \
>> + .storagebits = 16, \
>> + }, \
>> +}
>> +
>> #define AD9467_CHAN(_chan, avai_mask, _si, _bits, _sign) \
>> { \
>> .type = IIO_VOLTAGE, \
>> @@ -298,7 +320,8 @@ static void __ad9467_get_scale(struct ad9467_state *st, int index,
>> }
>>
>> static const struct iio_chan_spec ad9434_channels[] = {
>> - AD9467_CHAN(0, BIT(IIO_CHAN_INFO_SCALE), 0, 12, 's'),
>> + AD9434_CHAN(0, BIT(IIO_CHAN_INFO_SCALE) | BIT(IIO_CHAN_INFO_OFFSET),
>> + 0, 12, 's'),
>> };
>>
>> static const struct iio_chan_spec ad9467_channels[] = {
>> @@ -367,6 +390,7 @@ static const struct ad9467_chip_info ad9434_chip_tbl = {
>> .default_output_mode = AD9434_DEF_OUTPUT_MODE,
>> .vref_mask = AD9434_REG_VREF_MASK,
>> .num_lanes = 6,
>> + .offset_range = ad9434_offset_range,
>> };
>>
>> static const struct ad9467_chip_info ad9265_chip_tbl = {
>> @@ -499,6 +523,29 @@ static int ad9467_set_scale(struct ad9467_state *st, int val, int val2)
>> return -EINVAL;
>> }
>>
>> +static int ad9467_get_offset(struct ad9467_state *st, int *val)
>> +{
>> + *val = ad9467_spi_read(st, AN877_ADC_REG_OFFSET);
>> + if (*val < 0)
>> + return *val;
>
>
> Since processed value is (raw + offset) * scale, this means that
> the offset will be applied twice, once in hardware and once in
> software. I don't think that is the intended case here?
offset has not been used in "official" way here. But I think this should
be sorted out if moving to CALIBBIAS?
>
>> +
>> + return IIO_VAL_INT;
>> +}
>> +
>> +static int ad9467_set_offset(struct ad9467_state *st, int val)
>> +{
>> + int ret;
>> +
>> + if (val < st->info->offset_range[0] || val > st->info->offset_range[2])
>> + return -EINVAL;
>> +
>> + ret = ad9467_spi_write(st, AN877_ADC_REG_OFFSET, val);
>> + if (ret < 0)
>> + return ret;
>
> This could use a comment explaining why we need to do the sync after
> adjusting the offset.
Certain registers in the map needs the sync to take effect. I can add
comment.>
>> + return ad9467_spi_write(st, AN877_ADC_REG_TRANSFER,
>> + AN877_ADC_TRANSFER_SYNC);
>> +}
>> +
>> static int ad9467_outputmode_set(struct ad9467_state *st, unsigned int mode)
>> {
>> int ret;
>> @@ -802,6 +849,8 @@ static int ad9467_read_raw(struct iio_dev *indio_dev,
>> struct ad9467_state *st = iio_priv(indio_dev);
>>
>> switch (m) {
>> + case IIO_CHAN_INFO_OFFSET:
>> + return ad9467_get_offset(st, val);
>> case IIO_CHAN_INFO_SCALE:
>> return ad9467_get_scale(st, val, val2);
>> case IIO_CHAN_INFO_SAMP_FREQ:
>> @@ -836,6 +885,8 @@ static int ad9467_write_raw(struct iio_dev *indio_dev,
>> int ret;
>>
>> switch (mask) {
>> + case IIO_CHAN_INFO_OFFSET:
>> + return ad9467_set_offset(st, val);
>> case IIO_CHAN_INFO_SCALE:
>> return ad9467_set_scale(st, val, val2);
>> case IIO_CHAN_INFO_SAMP_FREQ:
>> @@ -874,6 +925,11 @@ static int ad9467_read_avail(struct iio_dev *indio_dev,
>> const struct ad9467_chip_info *info = st->info;
>>
>> switch (mask) {
>> + case IIO_CHAN_INFO_OFFSET:
>> + *type = IIO_VAL_INT;
>> + *vals = info->offset_range;
>> + *length = 3;
>
> We don't need to specify length when using IIO_AVAIL_RANGE.
>
>> + return IIO_AVAIL_RANGE;
>> case IIO_CHAN_INFO_SCALE:
>> *vals = (const int *)st->scales;
>> *type = IIO_VAL_INT_PLUS_MICRO;
>>
>
Powered by blists - more mailing lists