From: Andy Shevchenko <andriy.shevchenko@intel.com>
To: Frank Li <Frank.Li@nxp.com>
Cc: "Alexandre Belloni" <alexandre.belloni@bootlin.com>,
"Miquel Raynal" <miquel.raynal@bootlin.com>,
"Jonathan Cameron" <jic23@kernel.org>,
"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>,
linux-i3c@lists.infradead.org, linux-kernel@vger.kernel.org,
imx@lists.linux.dev, linux-iio@vger.kernel.org,
joshua.yeong@starfivetech.com, devicetree@vger.kernel.org,
"Carlos Song" <carlos.song@nxp.com>,
"Adrian Fluturel" <fluturel.adrian@gmail.com>
Subject: Re: [PATCH v7 5/5] iio: magnetometer: Add mmc5633 sensor
Date: Tue, 28 Oct 2025 12:50:55 +0200 [thread overview]
Message-ID: <aQCgD3iVOXoNr7uY@smile.fi.intel.com> (raw)
In-Reply-To: <20251027-i3c_ddr-v7-5-866a0ff7fc46@nxp.com>
On Mon, Oct 27, 2025 at 04:08:33PM -0400, Frank Li wrote:
> Add mmc5633 sensor basic support.
> - Support read 20 bits X/Y/Z magnetic.
> - Support I3C HDR mode to send start measurememt command.
> - Support I3C HDR mode to read all sensors data by one command.
...
+ time.h // for time constants
...
> +struct mmc5633_data {
> + struct device *dev;
> + struct i3c_device *i3cdev;
> + struct mutex mutex; /* protect to finish one whole measurement */
> + struct regmap *regmap;
regmap has struct device, i3c_device presumable also, and here is struct
device. Don't we have some overhead?
> +};
...
> +static const struct {
> + int val;
> + int val2;
No need. Just
> +} mmc5633_samp_freq[] = {
static const int mmc5633_samp_freq[][2] = {
> + { 1, 200000 },
> + { 2, 0 },
> + { 3, 500000 },
> + { 6, 600000 },
> +};
...
> +static int mmc5633_get_samp_freq_index(struct mmc5633_data *data,
> + int val, int val2)
> +{
> + u32 i;
unsigned int is enough. uXX rather would suggest we use it as a such, but here
you compare with size_t and return an int.
> +
> + for (i = 0; i < ARRAY_SIZE(mmc5633_samp_freq); i++)
> + if (mmc5633_samp_freq[i].val == val &&
> + mmc5633_samp_freq[i].val2 == val2)
> + return i;
> + return -EINVAL;
> +}
...
> +static int mmc5633_init(struct mmc5633_data *data)
> +{
> + unsigned int reg_id;
> + int ret;
> +
> + ret = regmap_read(data->regmap, MMC5633_REG_ID, ®_id);
> + if (ret < 0)
These ' < 0' have an explanation? Or do we expect regmap_*() return positive
numbers here? If the latter, it would be a least problem here.
> + return dev_err_probe(data->dev, ret,
> + "Error reading product id\n");
> +
> + /*
> + * Make sure we restore sensor characteristics, by doing
> + * a SET/RESET sequence, the axis polarity being naturally
> + * aligned after RESET.
> + */
> + ret = regmap_write(data->regmap, MMC5633_REG_CTRL0, MMC5633_CTRL0_SET);
> + if (ret < 0)
> + return ret;
Ditto and so on...
> + /*
> + * Minimum time interval between SET or RESET to other operations is
> + * 1ms according to Operating Timing Diagram in datasheet.
> + */
> + fsleep(MMC5633_WAIT_SET_RESET_US);
> +
> + ret = regmap_write(data->regmap, MMC5633_REG_CTRL0, MMC5633_CTRL0_RESET);
> + if (ret < 0)
> + return ret;
> +
> + /* set default sampling frequency */
> + return regmap_update_bits(data->regmap, MMC5633_REG_CTRL1,
> + MMC5633_CTRL1_BW_MASK,
> + FIELD_PREP(MMC5633_CTRL1_BW_MASK, 0));
> +}
...
> +static int mmc5633_read_measurement(struct mmc5633_data *data, int address, void *buf, size_t sz)
> +{
> + u8 data_cmd[2], status[2];
> + int ret, val, ready;
> +
> + if (mmc5633_is_support_hdr(data)) {
> + struct i3c_xfer xfers_wr_cmd[] = {
> + {
> + .cmd = 0x3b,
> + .len = 2,
> + .data.out = data_cmd,
> + }
> + };
> + struct i3c_xfer xfers_rd_sta_cmd[] = {
> + {
> + .cmd = 0x23 | BIT(7), /* RDSTA CMD */
> + .len = 2,
> + .data.in = status,
> + },
> + };
> + struct i3c_xfer xfers_rd_data_cmd[] = {
> + {
> + .cmd = 0x22 | BIT(7), /* RDLONG CMD */
> + .len = sz,
> + .data.in = buf,
> + },
> + };
> +
> + data_cmd[0] = 0;
> + data_cmd[1] = (address == MMC5633_TEMPERATURE) ?
> + MMC5633_HDR_CTRL0_MEAS_T : MMC5633_HDR_CTRL0_MEAS_M;
> +
> + ret = i3c_device_do_xfers(data->i3cdev, xfers_wr_cmd, 1, I3C_HDR_DDR);
1 --> ARRAY_SIZE(), but TBH I do not see the point them to be an array to begin
with. Any elaboration on the data type choice?
> + if (ret < 0)
> + return ret;
> +
> + ready = (address == MMC5633_TEMPERATURE) ?
> + MMC5633_STATUS1_MEAS_T_DONE_BIT : MMC5633_STATUS1_MEAS_M_DONE_BIT;
> + ret = read_poll_timeout(i3c_device_do_xfers, val,
> + val ||
> + status[0] & ready,
> + 10 * USEC_PER_MSEC,
> + 100 * 10 * USEC_PER_MSEC, 0,
> + data->i3cdev, xfers_rd_sta_cmd, 1, I3C_HDR_DDR);
> + if (ret) {
> + dev_err(data->dev, "data not ready\n");
> + return ret;
> + }
> + if (val) {
> + dev_err(data->dev, "i3c transfer error\n");
> + return val;
> + }
> + return i3c_device_do_xfers(data->i3cdev, xfers_rd_data_cmd, 1, I3C_HDR_DDR);
> + }
> +
> + /* Fallback to use SDR/I2C mode */
> + ret = mmc5633_take_measurement(data, address);
> + if (ret < 0)
> + return ret;
> +
> + if (address == MMC5633_TEMPERATURE)
> + /*
> + * Put tempeature to last byte of buff to align HDR case.
> + * I3C will early terminate data read if previous data is not
> + * available.
> + */
> + return regmap_bulk_read(data->regmap, MMC5633_REG_TOUT, buf + sz - 1, 1);
> +
> + return regmap_bulk_read(data->regmap, MMC5633_REG_XOUT_L, buf, sz);
> +}
...
> +static int mmc5633_write_raw(struct iio_dev *indio_dev,
> + struct iio_chan_spec const *chan, int val,
> + int val2, long mask)
> +{
> + struct mmc5633_data *data = iio_priv(indio_dev);
> + int i, ret;
> +
> + switch (mask) {
> + case IIO_CHAN_INFO_SAMP_FREQ:
> + i = mmc5633_get_samp_freq_index(data, val, val2);
> + if (i < 0)
> + return -EINVAL;
Hmm... Can't that return already an error and we just pass it to the caller?
> + scoped_guard(mutex, &data->mutex) {
> + ret = regmap_update_bits(data->regmap, MMC5633_REG_CTRL1,
> + MMC5633_CTRL1_BW_MASK,
> + FIELD_PREP(MMC5633_CTRL1_BW_MASK, i));
> + if (ret)
> + return ret;
> + };
> + return 0;
I didn't get why scoped_guard() is used when simple guard()() will do in
shorter all this.
guard(mutex)(&data->mutex);
return regmap_update_bits(data->regmap, MMC5633_REG_CTRL1,
MMC5633_CTRL1_BW_MASK,
FIELD_PREP(MMC5633_CTRL1_BW_MASK, i));
With that you may drop 'int i' part and use ret in the above.
> + default:
> + return -EINVAL;
> + }
> +}
...
> +static int mmc5633_common_probe(struct device *dev, struct regmap *regmap,
> + char *name, struct i3c_device *i3cdev)
> +{
> + struct mmc5633_data *data;
> + struct iio_dev *indio_dev;
> + int ret;
> +
> + indio_dev = devm_iio_device_alloc(dev, sizeof(*data));
> + if (!indio_dev)
> + return -ENOMEM;
> + dev_set_drvdata(dev, indio_dev);
If you use regmap stored device this won't be needed. See below.
> + data = iio_priv(indio_dev);
> +
> + data->regmap = regmap;
> + data->i3cdev = i3cdev;
> + data->dev = dev;
> +
> + ret = devm_mutex_init(dev, &data->mutex);
> + if (ret)
> + return ret;
> +
> + indio_dev->info = &mmc5633_info;
> + indio_dev->name = name;
> + indio_dev->channels = mmc5633_channels;
> + indio_dev->num_channels = ARRAY_SIZE(mmc5633_channels);
> + indio_dev->modes = INDIO_DIRECT_MODE;
> +
> + ret = mmc5633_init(data);
> + if (ret < 0)
> + return dev_err_probe(dev, ret, "mmc5633 chip init failed\n");
> +
> + return devm_iio_device_register(dev, indio_dev);
> +}
> +
> +static int mmc5633_suspend(struct device *dev)
> +{
> + struct mmc5633_data *data = iio_priv(dev_get_drvdata(dev));
Than regmap will be derived directly from a device.
> + regcache_cache_only(data->regmap, true);
> +
> + return 0;
> +}
> +
> +static int mmc5633_resume(struct device *dev)
> +{
Ditto.
> + struct mmc5633_data *data = iio_priv(dev_get_drvdata(dev));
> + int ret;
> +
> + regcache_mark_dirty(data->regmap);
> + ret = regcache_sync_region(data->regmap, MMC5633_REG_CTRL0,
> + MMC5633_REG_CTRL1);
> + if (ret < 0)
> + dev_err(dev, "Failed to restore control registers\n");
> +
> + regcache_cache_only(data->regmap, false);
> +
> + return 0;
> +}
...
> + return mmc5633_common_probe(dev, regmap, client->name, NULL);
dev can be derived from regmap.
...
> + return mmc5633_common_probe(dev, regmap, "mmc5633_i3c", i3cdev);
Ditto.
struct i3c_device doesn't have a name, does it?
--
With Best Regards,
Andy Shevchenko
next prev parent reply other threads:[~2025-10-28 10:51 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-10-27 20:08 [PATCH v7 0/5] i3c: Add basic HDR mode support Frank Li
2025-10-27 20:08 ` [PATCH v7 1/5] i3c: Add HDR API support Frank Li
2025-10-28 15:30 ` Guenter Roeck
2025-10-27 20:08 ` [PATCH v7 2/5] i3c: master: svc: Replace bool rnw with union for HDR support Frank Li
2025-10-27 20:08 ` [PATCH v7 3/5] i3c: master: svc: Add basic HDR mode support Frank Li
2025-10-27 20:08 ` [PATCH v7 4/5] dt-bindings: trivial-devices: add MEMSIC 3-axis magnetometer Frank Li
2025-10-27 20:08 ` [PATCH v7 5/5] iio: magnetometer: Add mmc5633 sensor Frank Li
2025-10-28 10:50 ` Andy Shevchenko [this message]
2025-10-28 15:31 ` Frank Li
2025-10-29 8:07 ` Andy Shevchenko
2025-10-29 15:54 ` Frank Li
2025-10-30 7:51 ` Andy Shevchenko
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=aQCgD3iVOXoNr7uY@smile.fi.intel.com \
--to=andriy.shevchenko@intel.com \
--cc=Frank.Li@nxp.com \
--cc=alexandre.belloni@bootlin.com \
--cc=andy@kernel.org \
--cc=carlos.song@nxp.com \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=dlechner@baylibre.com \
--cc=fluturel.adrian@gmail.com \
--cc=imx@lists.linux.dev \
--cc=jic23@kernel.org \
--cc=joshua.yeong@starfivetech.com \
--cc=krzk+dt@kernel.org \
--cc=linux-i3c@lists.infradead.org \
--cc=linux-iio@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=miquel.raynal@bootlin.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