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, ®);
> + 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
next prev parent reply other threads:[~2026-07-16 9:53 UTC|newest]
Thread overview: 14+ 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 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox