public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Andy Shevchenko <andriy.shevchenko@intel.com>
To: rodrigo.alencar@analog.com
Cc: linux-iio@vger.kernel.org, devicetree@vger.kernel.org,
	linux-kernel@vger.kernel.org,
	Lars-Peter Clausen <lars@metafoo.de>,
	Michael Hennerich <Michael.Hennerich@analog.com>,
	Jonathan Cameron <jic23@kernel.org>,
	David Lechner <dlechner@baylibre.com>,
	Andy Shevchenko <andy@kernel.org>, Rob Herring <robh@kernel.org>,
	Krzysztof Kozlowski <krzk+dt@kernel.org>,
	Conor Dooley <conor+dt@kernel.org>,
	Philipp Zabel <p.zabel@pengutronix.de>
Subject: Re: [PATCH RFC 3/8] iio: frequency: ad9910: add simple parallel port mode support
Date: Mon, 23 Feb 2026 10:27:09 +0200	[thread overview]
Message-ID: <aZwPXRadocNL9rQs@smile.fi.intel.com> (raw)
In-Reply-To: <20260220-ad9910-iio-driver-v1-3-3b264aa48a10@analog.com>

On Fri, Feb 20, 2026 at 04:46:07PM +0000, Rodrigo Alencar via B4 Relay wrote:

> Add parallel port channel with frequency scale, frequency offset, phase
> offset, and amplitude offset extended attributes for configuring the
> parallel data path.

...

> +	case AD9910_PP_FREQ_SCALE:
> +		if (val32 > BIT(15) || !is_power_of_2(val32))
> +			return -EINVAL;


> +		val32 = FIELD_PREP(AD9910_CFR2_FM_GAIN_MSK, ilog2(val32));

My gut feelings here that this can be simplified to avoid some checks,
or make it more like an expression.

In any case this is an edge between code readability and the size of
the generated binary object.

> +		ret = ad9910_reg32_update(st, AD9910_REG_CFR2,
> +					  AD9910_CFR2_FM_GAIN_MSK,
> +					  val32, true);
> +		break;

...

> +static ssize_t ad9910_pp_attrs_read(struct iio_dev *indio_dev,
> +				    uintptr_t private,

Hmm... Is it a requirement to have uintptr_t? Linus was clear that this is
the type that shouldn't be used in the kernel. unsigned long does the same.

Jonathan, is there any plans to get rid of uintptr_t in IIO?

> +				    const struct iio_chan_spec *chan,
> +				    char *buf)
> +{
> +	struct ad9910_state *st = iio_priv(indio_dev);
> +	int vals[2];
> +	u32 tmp32;
> +	u64 tmp64;

> +	guard(mutex)(&st->lock);

I don't see the need to have vals assignment followed by iio_format_value()
call be under the lock. OTOH, I understand that this makes code simple...

> +	switch (private) {
> +	case AD9910_PP_FREQ_OFFSET:
> +		tmp64 = (u64)st->reg[AD9910_REG_FTW].val32 * st->data.sysclk_freq_hz;
> +		vals[0] = upper_32_bits(tmp64);
> +		vals[1] = upper_32_bits((u64)lower_32_bits(tmp64) * MICRO);
> +		break;
> +	case AD9910_PP_PHASE_OFFSET:
> +		tmp32 = FIELD_GET(AD9910_POW_PP_LSB_MSK,
> +				  st->reg[AD9910_REG_POW].val16);
> +		tmp32 = (tmp32 * AD9910_MAX_PHASE_MICRORAD) >> 16;
> +		vals[0] = tmp32 / MICRO;
> +		vals[1] = tmp32 % MICRO;
> +		break;
> +	case AD9910_PP_AMP_OFFSET:
> +		tmp32 = FIELD_GET(AD9910_ASF_SCALE_FACTOR_PP_LSB_MSK,
> +				  st->reg[AD9910_REG_ASF].val32);
> +		vals[0] = 0;
> +		vals[1] = (u64)tmp32 * MICRO >> 14;
> +		break;
> +	default:
> +		return -EINVAL;
> +	}
> +
> +	return iio_format_value(buf, IIO_VAL_INT_PLUS_MICRO, ARRAY_SIZE(vals), vals);
> +}

...

> +static ssize_t ad9910_pp_attrs_write(struct iio_dev *indio_dev,
> +				     uintptr_t private,
> +				     const struct iio_chan_spec *chan,
> +				     const char *buf, size_t len)
> +{
> +	struct ad9910_state *st = iio_priv(indio_dev);
> +	int val, val2;
> +	u32 tmp32;
> +	int ret;
> +
> +	ret = iio_str_to_fixpoint(buf, MICRO / 10, &val, &val2);
> +	if (ret)
> +		return ret;
> +
> +	guard(mutex)(&st->lock);
> +
> +	switch (private) {
> +	case AD9910_PP_FREQ_OFFSET:
> +		if (val < 0 || val >= st->data.sysclk_freq_hz / 2)

in_range() ?

> +			return -EINVAL;
> +
> +		tmp32 = ad9910_rational_scale((u64)val * MICRO + val2, BIT_ULL(32),
> +					      (u64)MICRO * st->data.sysclk_freq_hz);
> +		ret = ad9910_reg32_write(st, AD9910_REG_FTW, tmp32, true);
> +		break;
> +	case AD9910_PP_PHASE_OFFSET:
> +		if (val != 0 || val2 < 0 || val2 >= (AD9910_MAX_PHASE_MICRORAD >> 8))

		if (val)
			return -EINVAL;

		if (!in_range(val2, ...))

> +			return -EINVAL;

?

> +		tmp32 = DIV_ROUND_CLOSEST((u32)val2 << 16, AD9910_MAX_PHASE_MICRORAD);
> +		tmp32 = min(tmp32, AD9910_POW_PP_LSB_MAX);
> +		tmp32 = FIELD_PREP(AD9910_POW_PP_LSB_MSK, tmp32);
> +		ret = ad9910_reg16_update(st, AD9910_REG_POW,
> +					  AD9910_POW_PP_LSB_MSK,
> +					  tmp32, true);
> +		break;
> +	case AD9910_PP_AMP_OFFSET:
> +		if (val != 0 || val2 < 0 || val2 >= (MICRO >> 8))
> +			return -EINVAL;
> +
> +		tmp32 = DIV_ROUND_CLOSEST((u32)val2 << 14, MICRO);
> +		tmp32 = min(tmp32, AD9910_ASF_PP_LSB_MAX);
> +		tmp32 = FIELD_PREP(AD9910_ASF_SCALE_FACTOR_PP_LSB_MSK, tmp32);
> +		ret = ad9910_reg32_update(st, AD9910_REG_ASF,
> +					  AD9910_ASF_SCALE_FACTOR_PP_LSB_MSK,
> +					  tmp32, true);
> +		break;
> +	default:
> +		return -EINVAL;
> +	}
> +
> +	return ret ?: len;
> +}

...

> +static const struct iio_chan_spec_ext_info ad9910_pp_ext_info[] = {
> +	AD9910_EXT_INFO("frequency_scale", AD9910_PP_FREQ_SCALE, IIO_SEPARATE),
> +	AD9910_PP_EXT_INFO("frequency_offset", AD9910_PP_FREQ_OFFSET),
> +	AD9910_PP_EXT_INFO("phase_offset", AD9910_PP_PHASE_OFFSET),
> +	AD9910_PP_EXT_INFO("scale_offset", AD9910_PP_AMP_OFFSET),
> +	{ },

Please, use IIO accepted style for terminator entry.
(Yes, for the consistency's sake it might require another cleanup patch.)

> +};

...

> +		val = val ? 1 : 0;

Replaces this...

> +		switch (chan->channel) {
> +		case AD9910_CHANNEL_PARALLEL_PORT:
> +			tmp32 = FIELD_PREP(AD9910_CFR2_PARALLEL_DATA_PORT_EN_MSK, val);

...by  !!val here.

> +			return ad9910_reg32_update(st, AD9910_REG_CFR2,
> +						   AD9910_CFR2_PARALLEL_DATA_PORT_EN_MSK,
> +						   tmp32, true);

-- 
With Best Regards,
Andy Shevchenko



  reply	other threads:[~2026-02-23  8:27 UTC|newest]

Thread overview: 46+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-02-20 16:46 [PATCH RFC 0/8] AD9910 Direct Digital Synthesizer Rodrigo Alencar via B4 Relay
2026-02-20 16:46 ` [PATCH RFC 1/8] dt-bindings: iio: frequency: add ad9910 Rodrigo Alencar via B4 Relay
2026-02-21 20:43   ` David Lechner
2026-02-21 22:43     ` Conor Dooley
2026-02-22 10:49       ` Rodrigo Alencar
2026-02-22 13:24         ` Conor Dooley
2026-02-22 10:47     ` Rodrigo Alencar
2026-02-22 20:28       ` David Lechner
2026-02-22 20:31       ` Conor Dooley
2026-03-01 12:50   ` Jonathan Cameron
2026-02-20 16:46 ` [PATCH RFC 2/8] iio: frequency: ad9910: initial driver implementation Rodrigo Alencar via B4 Relay
2026-03-01 13:20   ` Jonathan Cameron
2026-02-20 16:46 ` [PATCH RFC 3/8] iio: frequency: ad9910: add simple parallel port mode support Rodrigo Alencar via B4 Relay
2026-02-23  8:27   ` Andy Shevchenko [this message]
2026-03-01 13:22   ` Jonathan Cameron
2026-02-20 16:46 ` [PATCH RFC 4/8] iio: frequency: ad9910: expose sysclk_frequency device attribute Rodrigo Alencar via B4 Relay
2026-03-01 13:23   ` Jonathan Cameron
2026-02-20 16:46 ` [PATCH RFC 5/8] iio: frequency: ad9910: add digital ramp generator support Rodrigo Alencar via B4 Relay
2026-03-01 13:26   ` Jonathan Cameron
2026-02-20 16:46 ` [PATCH RFC 6/8] iio: frequency: ad9910: add RAM mode support Rodrigo Alencar via B4 Relay
2026-03-01 13:31   ` Jonathan Cameron
2026-03-03 15:32     ` Rodrigo Alencar
2026-03-03 17:16       ` Nuno Sá
2026-03-03 17:32         ` Rodrigo Alencar
2026-03-07 14:07     ` Jonathan Cameron
2026-03-10 17:40       ` Rodrigo Alencar
2026-03-11  0:11         ` David Lechner
2026-03-11 13:11           ` Rodrigo Alencar
2026-03-11 16:54             ` Nuno Sá
2026-03-11 17:08               ` Rodrigo Alencar
2026-02-20 16:46 ` [PATCH RFC 7/8] iio: frequency: ad9910: add output shift keying support Rodrigo Alencar via B4 Relay
2026-02-20 16:46 ` [PATCH RFC 8/8] iio: frequency: ad9910: add channel labels Rodrigo Alencar via B4 Relay
2026-02-21 20:16 ` [PATCH RFC 0/8] AD9910 Direct Digital Synthesizer David Lechner
2026-02-22 10:01   ` Rodrigo Alencar
2026-02-22 20:32     ` David Lechner
2026-02-23 10:02       ` Nuno Sá
2026-03-01 13:38         ` Jonathan Cameron
2026-03-02 10:22           ` Rodrigo Alencar
2026-03-07 14:09             ` Jonathan Cameron
2026-03-07 16:50               ` David Lechner
2026-03-07 16:58                 ` Jonathan Cameron
2026-03-07 18:54                   ` Rodrigo Alencar
2026-03-07 20:01                     ` David Lechner
2026-03-08 18:12                       ` Jonathan Cameron
2026-03-09  9:52                         ` Rodrigo Alencar
2026-03-09 13:14                           ` Nuno Sá

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=aZwPXRadocNL9rQs@smile.fi.intel.com \
    --to=andriy.shevchenko@intel.com \
    --cc=Michael.Hennerich@analog.com \
    --cc=andy@kernel.org \
    --cc=conor+dt@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=dlechner@baylibre.com \
    --cc=jic23@kernel.org \
    --cc=krzk+dt@kernel.org \
    --cc=lars@metafoo.de \
    --cc=linux-iio@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=p.zabel@pengutronix.de \
    --cc=robh@kernel.org \
    --cc=rodrigo.alencar@analog.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox