devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Andy Shevchenko <andriy.shevchenko@intel.com>
To: Antoniu Miclaus <antoniu.miclaus@analog.com>
Cc: jic23@kernel.org, robh+dt@kernel.org, linux-iio@vger.kernel.org,
	devicetree@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v5 1/4] iio:frequency:admv1014: add support for ADMV1014
Date: Sat, 5 Feb 2022 20:23:09 +0200	[thread overview]
Message-ID: <Yf7AjXsRuhFeFTpD@smile.fi.intel.com> (raw)
In-Reply-To: <20220131100102.15372-1-antoniu.miclaus@analog.com>

On Mon, Jan 31, 2022 at 12:00:59PM +0200, Antoniu Miclaus wrote:
> The ADMV1014 is a silicon germanium (SiGe), wideband,
> microwave downconverter optimized for point to point microwave
> radio designs operating in the 24 GHz to 44 GHz frequency range.

Excellent job!
A few comments / questions below.

...

> +config ADMV1014
> +	tristate "Analog Devices ADMV1014 Microwave Downconverter"
> +	depends on SPI && COMMON_CLK && 64BIT

Why 64BIT only?

..

> +enum {
> +	ADMV1014_IQ_MODE,
> +	ADMV1014_IF_MODE

+ Comma.

> +};
> +
> +enum {
> +	ADMV1014_SE_MODE_POS = 6,
> +	ADMV1014_SE_MODE_NEG = 9,
> +	ADMV1014_SE_MODE_DIFF = 12

+ Comma.

> +};

> +
> +enum {
> +	ADMV1014_CALIBSCALE_COARSE,
> +	ADMV1014_CALIBSCALE_FINE,
> +};

...

> +	int ret;
> +	struct spi_transfer t = {0};

{} would suffice.
Also, can we here and everywhere else use reversed xmas tree order?

	struct spi_transfer t = {};
	int ret;

...

> +	st->data[0] = ADMV1014_READ | FIELD_PREP(ADMV1014_REG_ADDR_READ_MSK, reg);
> +	st->data[1] = 0x0;
> +	st->data[2] = 0x0;

0x0 --> 0

Or I would rather put it cleaner with

	put_unaligned_be16(...);

(or is it le16?)

...

> +	t.len = 3;

sizeof()?

...

> +	put_unaligned_be24(FIELD_PREP(ADMV1014_REG_DATA_MSK, val) |
> +			   FIELD_PREP(ADMV1014_REG_ADDR_WRITE_MSK, reg), &st->data[0]);

Looking at the above I think the proper one will be byte assignment + put_unaligned_be16().

...

> +	return spi_write(st->spi, &st->data[0], 3);

sizeof() ?

...

> +	if (rate >= (5400 * HZ_PER_MHZ) && rate <= (7000 * HZ_PER_MHZ))
> +		filt_raw = 15;

> +	else if (rate >= (5400 * HZ_PER_MHZ) && rate <= (8000 * HZ_PER_MHZ))

What's the point to have 5400 here? Shouldn't be 7000?

> +		filt_raw = 10;
> +	else if (rate >= (6600 * HZ_PER_MHZ) && rate <= (9200 * HZ_PER_MHZ))
> +		filt_raw = 5;
> +	else
> +		filt_raw = 0;

...

> +		vcm_comp = 1050 + (i * 50) + (i / 8 * 50);

		vcm_comp = 1050 + mult_frac(i, 450, 8);
		// alternatively mult_frac(i * 50, 9, 8)

?

> +		if (vcm_mv != vcm_comp)
> +			continue;

...

> +	ret = kstrtou32(buf, 10, &data);

Should be kstrtouint(). Please check all such calls to be in align with the
type of variables that are used as a receptor.

> +	if (ret)
> +		return ret;

...

> +	switch ((u32)private) {

Why casting? Switch-case with castings is quite unusual.

> +	}

...

> +	return ret ? ret : len;

	return ret ?: len; ?

...

> +static const char * const admv1014_reg_name[] = {
> +	 "vcm", "vcc-if-bb", "vcc-vga", "vcc-vva", "vcc-lna-3p3", "vcc-lna-1p5",
> +	 "vcc-bg", "vcc-quad", "vcc-mixer"

4 or 5 on one line is easier to read and follow the index (if needed).
Also add a comma to the end.

> +};

...

> +#define ADMV1014_CHAN_IQ(_channel, rf_comp) {				\
> +	.type = IIO_ALTVOLTAGE,						\
> +	.modified = 1,							\
> +	.output = 0,							\
> +	.indexed = 1,							\
> +	.channel2 = IIO_MOD_##rf_comp,					\
> +	.channel = _channel,						\
> +	.info_mask_separate = BIT(IIO_CHAN_INFO_PHASE) |		\
> +		BIT(IIO_CHAN_INFO_OFFSET),				\
> +	.info_mask_shared_by_type = BIT(IIO_CHAN_INFO_CALIBSCALE)	\

+ Comma, same for the rest similar cases below.

> +	}

...

> +#define ADMV1014_CHAN_CALIBSCALE(_channel, rf_comp, _admv1014_ext_info) {	\
> +	.type = IIO_ALTVOLTAGE,							\
> +	.modified = 1,								\
> +	.output = 0,								\
> +	.indexed = 1,								\
> +	.channel2 = IIO_MOD_##rf_comp,						\
> +	.channel = _channel,							\
> +	.ext_info = _admv1014_ext_info						\

+ Comma.

> +	}
> +
> +static const struct iio_chan_spec admv1014_channels_iq[] = {
> +	ADMV1014_CHAN_IQ(0, I),
> +	ADMV1014_CHAN_IQ(0, Q),
> +	ADMV1014_CHAN_POWER(0)

+ Comma.

> +};
> +
> +static const struct iio_chan_spec admv1014_channels_if[] = {
> +	ADMV1014_CHAN_IF(0, I),
> +	ADMV1014_CHAN_IF(0, Q),
> +	ADMV1014_CHAN_CALIBSCALE(0, I, admv1014_ext_info),
> +	ADMV1014_CHAN_CALIBSCALE(0, Q, admv1014_ext_info),
> +	ADMV1014_CHAN_POWER(0)

+ Comma.

> +};

...

> +	enable_reg = FIELD_PREP(ADMV1014_P1DB_COMPENSATION_MSK, st->p1db_comp ? 3 : 0) |

3 --> GENMASK() ?

> +		     FIELD_PREP(ADMV1014_IF_AMP_PD_MSK, !(st->input_mode)) |
> +		     FIELD_PREP(ADMV1014_BB_AMP_PD_MSK, st->input_mode) |
> +		     FIELD_PREP(ADMV1014_DET_EN_MSK, st->det_en);
> +
> +	return __admv1014_spi_update_bits(st, ADMV1014_REG_ENABLE, enable_reg_msk, enable_reg);
> +}

...

> +	str = "iq";
> +	device_property_read_string(&spi->dev, "adi,input-mode", &str);
> +
> +	if (!strcmp(str, "iq"))
> +		st->input_mode = ADMV1014_IQ_MODE;
> +	else if (!strcmp(str, "if"))
> +		st->input_mode = ADMV1014_IF_MODE;
> +	else
> +		return -EINVAL;

Please, put the array of strings near to the enums and use match-string here.
Something like:

static const char const *mode_names = { "iq", "if" };

	ret = device_property_read_string(&spi->dev, "adi,input-mode", &str);
	if (ret)
		input_mode = ...
	else {
		ret = match_string();
		if (ret < 0)
			return ret;
		input_mode = ret;
	}

...

> +	str = "diff";
> +	device_property_read_string(&spi->dev, "adi,quad-se-mode", &str);
> +
> +	if (!strcmp(str, "diff"))
> +		st->quad_se_mode = ADMV1014_SE_MODE_DIFF;
> +	else if (!strcmp(str, "se-pos"))
> +		st->quad_se_mode = ADMV1014_SE_MODE_POS;
> +	else if (!strcmp(str, "se-neg"))
> +		st->quad_se_mode = ADMV1014_SE_MODE_NEG;
> +	else
> +		return -EINVAL;

Ditto.

While in the above case no win in LOCs, here already a little win.
The most important not that, the possibility to extend without changing the
code much.

...

> +	st->clkin = devm_clk_get(&spi->dev, "lo_in");

Perhaps _optional?

> +	if (IS_ERR(st->clkin))
> +		return dev_err_probe(&spi->dev, PTR_ERR(st->clkin),
> +				     "failed to get the LO input clock\n");

-- 
With Best Regards,
Andy Shevchenko



  parent reply	other threads:[~2022-02-05 18:24 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-01-31 10:00 [PATCH v5 1/4] iio:frequency:admv1014: add support for ADMV1014 Antoniu Miclaus
2022-01-31 10:01 ` [PATCH v5 2/4] dt-bindings:iio:frequency: add admv1014 binding Antoniu Miclaus
2022-02-04 22:38   ` Rob Herring
2022-01-31 10:01 ` [PATCH v5 3/4] Documentation:ABI:testing:admv1014: add ABI docs Antoniu Miclaus
2022-01-31 10:01 ` [PATCH v5 4/4] MAINTAINERS: add maintainer for ADMV1014 driver Antoniu Miclaus
2022-02-05 18:23 ` Andy Shevchenko [this message]
2022-02-06 15:22   ` [PATCH v5 1/4] iio:frequency:admv1014: add support for ADMV1014 Jonathan Cameron
2022-02-07 20:29   ` Nuno Sá
2022-02-09 12:01     ` Andy Shevchenko
2022-02-10  8:26       ` Nuno Sá
2022-02-05 18:34 ` 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=Yf7AjXsRuhFeFTpD@smile.fi.intel.com \
    --to=andriy.shevchenko@intel.com \
    --cc=antoniu.miclaus@analog.com \
    --cc=devicetree@vger.kernel.org \
    --cc=jic23@kernel.org \
    --cc=linux-iio@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=robh+dt@kernel.org \
    /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;
as well as URLs for NNTP newsgroup(s).