From: Jonathan Cameron <jic23@kernel.org>
To: Matti Vaittinen <mazziesaccount@gmail.com>
Cc: Mehdi Djait <mehdi.djait.k@gmail.com>,
krzysztof.kozlowski+dt@linaro.org,
andriy.shevchenko@linux.intel.com, robh+dt@kernel.org,
lars@metafoo.de, linux-iio@vger.kernel.org,
linux-kernel@vger.kernel.org, devicetree@vger.kernel.org
Subject: Re: [PATCH v3 7/7] iio: accel: Add support for Kionix/ROHM KX132-1211 accelerometer
Date: Mon, 1 May 2023 16:04:31 +0100 [thread overview]
Message-ID: <20230501160431.602e3086@jic23-huawei> (raw)
In-Reply-To: <00905352-f9a4-a8bf-63b7-92e3b1d2a4f4@gmail.com>
> > +static int kx132_get_fifo_bytes(struct kx022a_data *data)
> > +{
> > + struct device *dev = regmap_get_device(data->regmap);
> > + __le16 buf_status;
> > + int ret, fifo_bytes;
> > +
> > + ret = regmap_bulk_read(data->regmap, data->chip_info->buf_status1,
> > + &buf_status, sizeof(buf_status));
> > + if (ret) {
> > + dev_err(dev, "Error reading buffer status\n");
> > + return ret;
> > + }
> > +
> > + fifo_bytes = le16_to_cpu(buf_status);
> > + fifo_bytes &= data->chip_info->buf_smp_lvl_mask;
>
> This is probably just my limitation but I've hard time thinking how this
> works out on BE machines. It'd be much easier for me to understand this
> if the data was handled as two u8 values and mask was applied before
> endianes conversion. (Eg - untested pseudo code follows;
>
> __le16 buf_status;
> u8 *reg_data;
>
> ...
>
> ret = regmap_bulk_read(data->regmap, data->chip_info->buf_status1,
> &buf_status, sizeof(buf_status));
> ...
>
> reg_data = (u8 *)&buf_status;
>
> /* Clear the unused bits form 2.nd reg */
> reg_data[1] = reg_data[i] & MASK_SMP_LVL_REG_HIGH_BITS;
>
> /* Convert to CPU endianess */
> fifo_bytes = le16_to_cpu(buf_status);
>
> Well, others may have different view on this :)
:)
I go the other way. It's less obvious to me that it is appropriate
to apply le16_to_cpu(buf_status) after applying a mask to some
bits. The moment that is appropriate, then we certainly hope a single
mask application is as well.
I think treating it as a 16 bit register is appropriate, in particular
as the field is described as SMP_LEV[9:0] on the datasheet
(of course there are datasheets that do that for unconnected sets of
bits so this doesn't always work ;)
Jonathan
next prev parent reply other threads:[~2023-05-01 14:48 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-04-24 22:22 [PATCH v3 0/7] iio: accel: Add support for Kionix/ROHM KX132-1211 accelerometer Mehdi Djait
2023-04-24 22:22 ` [PATCH v3 1/7] dt-bindings: iio: Add " Mehdi Djait
2023-04-24 22:22 ` [PATCH v3 2/7] iio: accel: kionix-kx022a: Remove blank lines Mehdi Djait
2023-04-25 5:26 ` Matti Vaittinen
2023-04-24 22:22 ` [PATCH v3 3/7] iio: accel: kionix-kx022a: Warn on failed matches and assume compatibility Mehdi Djait
2023-04-24 22:22 ` [PATCH v3 4/7] iio: accel: kionix-kx022a: Add an i2c_device_id table Mehdi Djait
2023-04-25 5:31 ` Matti Vaittinen
2023-05-01 14:42 ` Jonathan Cameron
2023-04-25 13:40 ` Andy Shevchenko
2023-04-29 13:10 ` Mehdi Djait
2023-04-24 22:22 ` [PATCH v3 5/7] iio: accel: kionix-kx022a: Refactor driver and add chip_info structure Mehdi Djait
2023-04-25 6:50 ` Matti Vaittinen
2023-04-25 7:24 ` Mehdi Djait
2023-04-25 8:12 ` Matti Vaittinen
2023-04-29 12:59 ` Mehdi Djait
2023-04-29 13:56 ` Matti Vaittinen
2023-05-01 14:50 ` Jonathan Cameron
2023-05-07 20:45 ` Mehdi Djait
2023-05-08 6:12 ` Matti Vaittinen
2023-04-25 15:57 ` Andi Shyti
2023-04-29 13:07 ` Mehdi Djait
2023-04-30 17:49 ` Jonathan Cameron
2023-05-02 19:41 ` Andy Shevchenko
2023-05-05 18:12 ` Mehdi Djait
2023-04-24 22:22 ` [PATCH v3 6/7] iio: accel: kionix-kx022a: Add a function to retrieve number of bytes in buffer Mehdi Djait
2023-04-25 7:07 ` Matti Vaittinen
2023-04-25 7:26 ` Mehdi Djait
2023-04-24 22:22 ` [PATCH v3 7/7] iio: accel: Add support for Kionix/ROHM KX132-1211 accelerometer Mehdi Djait
2023-04-25 8:06 ` Matti Vaittinen
2023-05-01 15:04 ` Jonathan Cameron [this message]
2023-05-01 14:56 ` Jonathan Cameron
2023-05-05 18:11 ` Mehdi Djait
2023-05-06 16:46 ` Jonathan Cameron
2023-05-07 14:56 ` Mehdi Djait
2023-05-13 17:13 ` 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=20230501160431.602e3086@jic23-huawei \
--to=jic23@kernel.org \
--cc=andriy.shevchenko@linux.intel.com \
--cc=devicetree@vger.kernel.org \
--cc=krzysztof.kozlowski+dt@linaro.org \
--cc=lars@metafoo.de \
--cc=linux-iio@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mazziesaccount@gmail.com \
--cc=mehdi.djait.k@gmail.com \
--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 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.