All of lore.kernel.org
 help / color / mirror / Atom feed
From: Siratul Islam <siratul.islam@linux.dev>
To: Jorijn van der Graaf <jorijnvdgraaf@catcrafts.net>,
	Jonathan Cameron <jic23@kernel.org>
Cc: "David Lechner" <dlechner@baylibre.com>,
	"Nuno Sá" <nuno.sa@analog.com>,
	"Andy Shevchenko" <andy@kernel.org>,
	"Rob Herring" <robh@kernel.org>,
	"Krzysztof Kozlowski" <krzk+dt@kernel.org>,
	"Conor Dooley" <conor+dt@kernel.org>,
	"Luca Weiss" <luca.weiss@fairphone.com>,
	linux-iio@vger.kernel.org, devicetree@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH 2/2] iio: magnetometer: add support for QST QMC6308
Date: Thu, 16 Jul 2026 15:52:51 +0600	[thread overview]
Message-ID: <d7fffbeacc77c3135564f902c41f19a219ddce75.camel@linux.dev> (raw)
In-Reply-To: <20260714202842.340293-3-jorijnvdgraaf@catcrafts.net>

On Tue, 2026-07-14 at 22:28 +0200, Jorijn van der Graaf wrote:
> ...
> 
Hi! the driver looks clean overall. I see you have followed ;
> 
> +// SPDX-License-Identifier: GPL-2.0 OR BSD-2-Clause
> +/*
> + * Support for QST QMC6308 3-Axis Magnetic Sensor on I2C bus.
> + *
> + * Copyright (C) 2026 Jorijn van der Graaf <jorijnvdgraaf@catcrafts.net>
> + *
> + * Datasheet available at
> + * <https://qstcorp.com/upload/pdf/202202/13-52-15%20QMC6308%20Datasheet%20Rev.%20F(1).pdf>
> + */
> +
> 
...
> + #define QMC6308_OSR2_MASK GENMASK(7, 6)
This is never used so it's dead code. Are you supposed to use it somewhere?
> +
> +/*
> + * Power-on completion time (datasheet Table 7), also used as a
> + * conservative bound after soft reset, for which the datasheet
> + * gives no figure.
> + */
> +#define QMC6308_POR_US 250
Describe what this value is here, and explain in call sites why you are 
using it for something else too. i.e.,

/* Power-on completion time (datasheet Table 7) */
#define QMC6308_POR_US 250

And then in call sites,
"reusing por time because..."

> +
> +#define QMC6308_AUTOSUSPEND_DELAY_MS 500
You can call it QMC6308_SLEEP_DELAY_MS to align with other values.
> +
> +struct qmc6308_data {
> + struct regmap *regmap;
> + /*
> + * Protect data->range/odr/osr.
> + * Protect poll and read during measurement (reading the status
> + * register clears DRDY).
> + */
"reading the status register clears DRDY" - This bit of information is not
describing the mutex. Explain it at a call site. i.e, where you read STATUS register
to clear DRDY.
> + struct mutex mutex;
> + struct iio_mount_matrix orientation;
> + u8 range;
> + u8 odr;
> + u8 osr;
> +};
> +
...
> +
> +static int qmc6308_take_measurement(struct iio_dev *indio_dev, int index,
> +     int *val)
> +{
> + struct qmc6308_data *data = iio_priv(indio_dev);
> + struct regmap *map = data->regmap;
> + struct device *dev = regmap_get_device(map);
> + unsigned int status;
> + __le16 buf[3];
> + int ret;
Use reverse x-mas tree order.
struct qmc6308_data *data = iio_priv(indio_dev);
struct device *dev = regmap_get_device(map);
struct regmap *map = data->regmap;
> +
> 
...
> +static int qmc6308_write_raw(struct iio_dev *indio_dev,
> +      const struct iio_chan_spec *chan,
> +      int val, int val2, long mask)
> +{
> + struct qmc6308_data *data = iio_priv(indio_dev);
> + unsigned int status;
> + unsigned int i;
Why not use a switch here instead of depending on 'i'. In it's current form,
we would need to keep going back to check what the scales, odr, osr arrays look like.
I would suggest following the same pattern as the QMC5883L driver.

The arrays could also be flattened like this if you follow the above suggestion.
+static const int qmc6308_odr_avail[] = { 10, 50, 100, 200 };
> + int ret;
> +
> + switch (mask) {
> + case IIO_CHAN_INFO_SCALE: {
> + if (val != 0)
> + return -EINVAL;
> +
> + for (i = 0; i < ARRAY_SIZE(qmc6308_scales); i++) {
> + if (val2 == qmc6308_scales[i][1])
> + break;
> + }
> + if (i == ARRAY_SIZE(qmc6308_scales))
> + return -EINVAL;
This check won't be needed then. 
> ...
> 

> +		ret = regmap_update_bits(data->regmap, QMC6308_REG_CTRL2,
> +					 QMC6308_RNG_MASK,
> +					 FIELD_PREP(QMC6308_RNG_MASK, i));
> 
> +		data->range = i;
Another issue I noticed, what happens if the update succeeds but the "status read to clear" below fails?
You are returning an incorrect error to the userspace even though the scale change took effect. 
I think a better approach here would be a log and continue instead of failing.
> + 
> + 		return regmap_read(data->regmap, QMC6308_REG_STATUS,
> + 				&status);

...
> +}
> +
> +static int qmc6308_init(struct qmc6308_data *data)
> +{
> + struct regmap *map = data->regmap;
> + unsigned int reg;
> + int ret;
> +
> + ret = regmap_read(map, QMC6308_REG_ID, &reg);
> + if (ret)
> + return ret;
> +
> + /* Allow unknown IDs so that fallback compatibles work */
> + if (reg != QMC6308_CHIP_ID)
> + dev_warn(regmap_get_device(map),
> + "Unknown chip id: 0x%02x, continuing\n", reg);
> +
> + /* The SOFT_RST bit is not auto-cleared and must be written back 0 */
> + ret = regmap_write(map, QMC6308_REG_CTRL2, QMC6308_SOFT_RST);
> + if (ret)
> + return ret;
> +
> + fsleep(QMC6308_POR_US);
> +
Add a comment why you are using this value here as I suggested above.
(i.e., as a conservative bound)
> + data->range = QMC6308_RNG_30G;
> +
> + ret = regmap_write(map, QMC6308_REG_CTRL2,
> +    FIELD_PREP(QMC6308_SET_RESET_MASK,
> +       QMC6308_SET_RESET_ON) |
> +    FIELD_PREP(QMC6308_RNG_MASK, data->range));
> + if (ret)
> + return ret;
> +
> + data->odr = QMC6308_ODR_50HZ;
> + data->osr = QMC6308_OSR1_8;
Might as well assign the default values for data->{range, odr, osr} together?
data->range = QMC6308_RNG_30G;
data->odr = QMC6308_ODR_50HZ;
data->osr = QMC6308_OSR1_8;

I find to easier to glance.
> +
> + return regmap_write(map, QMC6308_REG_CTRL1,
> +     FIELD_PREP(QMC6308_MODE_MASK,
> +        QMC6308_MODE_NORMAL) |
> +     FIELD_PREP(QMC6308_ODR_MASK, data->odr) |
> +     FIELD_PREP(QMC6308_OSR1_MASK, data->osr));
> +}
> +
> 
...
> +
> +MODULE_DESCRIPTION("QST QMC6308 3-Axis Magnetic Sensor driver");
> +MODULE_AUTHOR("Jorijn van der Graaf <jorijnvdgraaf@catcrafts.net>");
> +MODULE_LICENSE("Dual BSD/GPL");
--
Best regards,
Sirat

  parent reply	other threads:[~2026-07-16  9:53 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-14 20:28 [PATCH 0/2] iio: magnetometer: add support for QST QMC6308 Jorijn van der Graaf
2026-07-14 20:28 ` [PATCH 1/2] dt-bindings: iio: magnetometer: add " Jorijn van der Graaf
2026-07-15 18:32   ` Siratul Islam
2026-07-15 20:46     ` Jorijn van der Graaf
2026-07-15 22:16       ` Siratul Islam
2026-07-16 14:18         ` Jorijn van der Graaf
2026-07-14 20:28 ` [PATCH 2/2] iio: magnetometer: add support for " Jorijn van der Graaf
2026-07-14 20:38   ` sashiko-bot
2026-07-14 21:21   ` Uwe Kleine-König
2026-07-15 20:46     ` Jorijn van der Graaf
2026-07-16  9:52   ` Siratul Islam [this message]
2026-07-16 10:11     ` Siratul Islam
2026-07-16 14:18     ` Jorijn van der Graaf
2026-07-16 14:45       ` Siratul Islam
2026-07-16 19:06       ` Siratul Islam

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=d7fffbeacc77c3135564f902c41f19a219ddce75.camel@linux.dev \
    --to=siratul.islam@linux.dev \
    --cc=andy@kernel.org \
    --cc=conor+dt@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=dlechner@baylibre.com \
    --cc=jic23@kernel.org \
    --cc=jorijnvdgraaf@catcrafts.net \
    --cc=krzk+dt@kernel.org \
    --cc=linux-iio@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luca.weiss@fairphone.com \
    --cc=nuno.sa@analog.com \
    --cc=robh@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.