From: Jonathan Cameron <jic23@kernel.org>
To: Rodrigo Alencar via B4 Relay
<devnull+rodrigo.alencar.analog.com@kernel.org>
Cc: rodrigo.alencar@analog.com, linux-kernel@vger.kernel.org,
linux-iio@vger.kernel.org, devicetree@vger.kernel.org,
linux-doc@vger.kernel.org, David Lechner <dlechner@baylibre.com>,
Andy Shevchenko <andy@kernel.org>,
Lars-Peter Clausen <lars@metafoo.de>,
Michael Hennerich <Michael.Hennerich@analog.com>,
Rob Herring <robh@kernel.org>,
Krzysztof Kozlowski <krzk+dt@kernel.org>,
Conor Dooley <conor+dt@kernel.org>,
Jonathan Corbet <corbet@lwn.net>
Subject: Re: [PATCH v3 2/6] iio: frequency: adf41513: driver implementation
Date: Sun, 11 Jan 2026 13:53:52 +0000 [thread overview]
Message-ID: <20260111135352.5f37bb51@jic23-huawei> (raw)
In-Reply-To: <20260108-adf41513-iio-driver-v3-2-23d1371aef48@analog.com>
On Thu, 08 Jan 2026 12:14:51 +0000
Rodrigo Alencar via B4 Relay <devnull+rodrigo.alencar.analog.com@kernel.org> wrote:
> From: Rodrigo Alencar <rodrigo.alencar@analog.com>
>
> The driver is based on existing PLL drivers in the IIO subsystem and
> implements the following key features:
>
> - Integer-N and fractional-N (fixed/variable modulus) synthesis modes
> - High-resolution frequency calculations using microhertz (µHz) precision
> to handle sub-Hz resolution across multi-GHz frequency ranges
> - IIO debugfs interface for direct register access
> - FW property parsing from devicetree including charge pump settings,
> reference path configuration and muxout options
> - Power management support with suspend/resume callbacks
> - Lock detect GPIO monitoring
>
> The driver uses 64-bit microhertz values throughout PLL calculations to
> maintain precision when working with frequencies that exceed 32-bit Hz
> representation while requiring fractional Hz resolution.
>
> Signed-off-by: Rodrigo Alencar <rodrigo.alencar@analog.com>
Hi Rodrigo,
Just one significant point (though it's repeated a few times!).
I think you can simplify the firmware parsing code by changing how you
set the defaults. That should both make it more readable and make
it more obvious that the necessary checks have parsed when you have
a mixture of default and values from DT.
thanks,
Jonathan
> diff --git a/drivers/iio/frequency/adf41513.c b/drivers/iio/frequency/adf41513.c
> new file mode 100644
> index 000000000000..69dcbbc1f393
> --- /dev/null
> +++ b/drivers/iio/frequency/adf41513.c
...
> +
> +static ssize_t adf41513_read_uhz(struct iio_dev *indio_dev,
> + uintptr_t private,
> + const struct iio_chan_spec *chan,
> + char *buf)
> +{
> + struct adf41513_state *st = iio_priv(indio_dev);
> + u64 freq_uhz;
> +
> + guard(mutex)(&st->lock);
> +
> + switch ((u32)private) {
> + case ADF41513_FREQ:
> + freq_uhz = adf41513_pll_get_rate(st);
> + if (st->lock_detect)
> + if (!gpiod_get_value_cansleep(st->lock_detect)) {
Trivial, ignore if you like:
Might as well combine the conditions
if (st->lock_detect &&
!gpio_get_value_can_sleep(st->lock_detect)) {
}
given the first is just a check on whether the second makes sense or not.
> + dev_dbg(&st->spi->dev, "PLL un-locked\n");
> + return -EBUSY;
> + }
> + break;
> +
> +static int adf41513_reg_access(struct iio_dev *indio_dev,
> + unsigned int reg,
> + unsigned int writeval,
> + unsigned int *readval)
static int adf41513_reg_access(struct iio_dev *indio_dev, unsigned int reg,
unsigned int writeval, unsigned int *readval)
would be fine for wrap here and save us a few lines of scrolling.
> +
> +static int adf41513_parse_fw(struct adf41513_state *st)
> +{
> + struct device *dev = &st->spi->dev;
> + int ret;
> + u32 tmp, cp_resistance, cp_current;
> +
> + /* power-up frequency */
> + st->data.power_up_frequency_hz = ADF41510_MAX_RF_FREQ;
> + ret = device_property_read_u32(dev, "adi,power-up-frequency-mhz", &tmp);
> + if (!ret) {
> + st->data.power_up_frequency_hz = (u64)tmp * HZ_PER_MHZ;
> + if (st->data.power_up_frequency_hz < ADF41513_MIN_RF_FREQ ||
> + st->data.power_up_frequency_hz > ADF41513_MAX_RF_FREQ)
> + return dev_err_probe(dev, -ERANGE,
> + "power-up frequency %llu Hz out of range\n",
> + st->data.power_up_frequency_hz);
> + }
> +
> + st->data.ref_div_factor = ADF41513_MIN_R_CNT;
Small thing, but for all of these, if you instead set the temporary variable
to whatever is the DT default (not the register value it maps to) then the handling
ends up simpler. We don't care if we have to do a small amount of unnecessary maths
if the default is used.
tmp = ADF41513_MIN_R_CNT;
device_property_read_u32(dev, "adi,....", &tmp);
if (tmp < ......)
return dev_err_probe();
st->data.ref_div_factor = tmp;
etc. If you want to check ret for the explicit return value that means no property
then that's fine too but I've always been a bit relaxed on these.
> + ret = device_property_read_u32(dev, "adi,reference-div-factor", &tmp);
> + if (!ret) {
> + if (tmp < ADF41513_MIN_R_CNT || tmp > ADF41513_MAX_R_CNT)
> + return dev_err_probe(dev, -ERANGE,
> + "invalid reference div factor %u\n", tmp);
> + st->data.ref_div_factor = tmp;
> + }
> +
> + st->data.ref_doubler_en = device_property_read_bool(dev, "adi,reference-doubler-enable");
> + st->data.ref_div2_en = device_property_read_bool(dev, "adi,reference-div2-enable");
> +
> + cp_resistance = ADF41513_DEFAULT_R_SET;
> + ret = device_property_read_u32(dev, "adi,charge-pump-resistor-ohms", &cp_resistance);
> + if (!ret && (cp_resistance < ADF41513_MIN_R_SET || cp_resistance > ADF41513_MAX_R_SET))
Don't need the if (!ret) bit, as the default will pass the other tests.
> + return dev_err_probe(dev, -ERANGE, "R_SET %u Ohms out of range\n", cp_resistance);
> +
> + st->data.charge_pump_voltage_mv = ADF41513_DEFAULT_CP_VOLTAGE_mV;
> + ret = device_property_read_u32(dev, "adi,charge-pump-current-microamp", &cp_current);
> + if (!ret) {
> + tmp = DIV_ROUND_CLOSEST(cp_current * cp_resistance, MILLI); /* convert to mV */
> + if (tmp < ADF41513_MIN_CP_VOLTAGE_mV || tmp > ADF41513_MAX_CP_VOLTAGE_mV)
One advantage of the suggested approach above is that we don't have to think
carefully on whether the default here * a custom value for cp_resistance would fail this
test because we check that explicitly.
> + return dev_err_probe(dev, -ERANGE, "I_CP %u uA (%u Ohms) out of range\n",
> + cp_current, cp_resistance);
> + st->data.charge_pump_voltage_mv = tmp;
> + }
> +
> + st->data.phase_detector_polarity =
> + device_property_read_bool(dev, "adi,phase-detector-polarity-positive-enable");
> +
> + st->data.logic_lvl_1v8_en = device_property_read_bool(dev, "adi,logic-level-1v8-enable");
> +
> + st->data.lock_detect_count = ADF41513_LD_COUNT_MIN;
> + ret = device_property_read_u32(dev, "adi,lock-detector-count", &tmp);
> + if (!ret) {
> + if (tmp < ADF41513_LD_COUNT_FAST_MIN || tmp > ADF41513_LD_COUNT_MAX ||
> + !is_power_of_2(tmp))
> + return dev_err_probe(dev, -ERANGE,
> + "invalid lock detect count: %u\n", tmp);
> + st->data.lock_detect_count = tmp;
> + }
> +
> + st->data.freq_resolution_uhz = MICROHZ_PER_HZ;
> +
> + return 0;
> +}
next prev parent reply other threads:[~2026-01-11 13:54 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-01-08 12:14 [PATCH v3 0/6] ADF41513/ADF41510 PLL frequency synthesizers Rodrigo Alencar via B4 Relay
2026-01-08 12:14 ` [PATCH v3 1/6] dt-bindings: iio: frequency: add adf41513 Rodrigo Alencar via B4 Relay
2026-01-09 8:13 ` Krzysztof Kozlowski
2026-01-12 10:04 ` Rodrigo Alencar
2026-01-12 16:32 ` Krzysztof Kozlowski
2026-01-08 12:14 ` [PATCH v3 2/6] iio: frequency: adf41513: driver implementation Rodrigo Alencar via B4 Relay
2026-01-09 18:55 ` Andy Shevchenko
2026-01-12 9:56 ` Rodrigo Alencar
2026-01-12 10:57 ` Andy Shevchenko
2026-01-13 9:32 ` Rodrigo Alencar
2026-01-16 11:31 ` Rodrigo Alencar
2026-01-16 13:50 ` Andy Shevchenko
2026-01-16 13:53 ` Andy Shevchenko
2026-01-11 13:53 ` Jonathan Cameron [this message]
2026-01-08 12:14 ` [PATCH v3 3/6] iio: frequency: adf41513: handle LE synchronization feature Rodrigo Alencar via B4 Relay
2026-01-11 13:58 ` Jonathan Cameron
2026-01-08 12:14 ` [PATCH v3 4/6] iio: frequency: adf41513: features on frequency change Rodrigo Alencar via B4 Relay
2026-01-09 19:07 ` Andy Shevchenko
2026-01-12 9:45 ` Rodrigo Alencar
2026-01-12 10:54 ` Andy Shevchenko
2026-01-16 17:57 ` Jonathan Cameron
2026-01-19 7:38 ` Andy Shevchenko
2026-01-19 10:41 ` Jonathan Cameron
2026-01-19 13:18 ` Andy Shevchenko
2026-01-08 12:14 ` [PATCH v3 5/6] docs: iio: add documentation for adf41513 driver Rodrigo Alencar via B4 Relay
2026-01-08 12:14 ` [PATCH v3 6/6] Documentation: ABI: testing: add common ABI file for iio/frequency Rodrigo Alencar via B4 Relay
2026-01-11 14:01 ` Jonathan Cameron
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=20260111135352.5f37bb51@jic23-huawei \
--to=jic23@kernel.org \
--cc=Michael.Hennerich@analog.com \
--cc=andy@kernel.org \
--cc=conor+dt@kernel.org \
--cc=corbet@lwn.net \
--cc=devicetree@vger.kernel.org \
--cc=devnull+rodrigo.alencar.analog.com@kernel.org \
--cc=dlechner@baylibre.com \
--cc=krzk+dt@kernel.org \
--cc=lars@metafoo.de \
--cc=linux-doc@vger.kernel.org \
--cc=linux-iio@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--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