| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <aQCgD3iVOXoNr7uY@smile.fi.intel.com>
Date: Tue, 28 Oct 2025 12:50:55 +0200
From: Andy Shevchenko <andriy.shevchenko@...el.com>
To: Frank Li <Frank.Li@....com>
Cc: Alexandre Belloni <alexandre.belloni@...tlin.com>,
Miquel Raynal <miquel.raynal@...tlin.com>,
Jonathan Cameron <jic23@...nel.org>,
David Lechner <dlechner@...libre.com>,
Nuno Sá <nuno.sa@...log.com>,
Andy Shevchenko <andy@...nel.org>, Rob Herring <robh@...nel.org>,
Krzysztof Kozlowski <krzk+dt@...nel.org>,
Conor Dooley <conor+dt@...nel.org>, linux-i3c@...ts.infradead.org,
linux-kernel@...r.kernel.org, imx@...ts.linux.dev,
linux-iio@...r.kernel.org, joshua.yeong@...rfivetech.com,
devicetree@...r.kernel.org, Carlos Song <carlos.song@....com>,
Adrian Fluturel <fluturel.adrian@...il.com>
Subject: Re: [PATCH v7 5/5] iio: magnetometer: Add mmc5633 sensor
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
Powered by blists - more mailing lists