From: Jonathan Cameron <jic23@kernel.org>
To: "Shen Jianping (ME-SE/EAD2)" <Jianping.Shen@de.bosch.com>
Cc: "lars@metafoo.de" <lars@metafoo.de>,
"robh@kernel.org" <robh@kernel.org>,
"krzk+dt@kernel.org" <krzk+dt@kernel.org>,
"conor+dt@kernel.org" <conor+dt@kernel.org>,
"dima.fedrau@gmail.com" <dima.fedrau@gmail.com>,
"marcelo.schmitt1@gmail.com" <marcelo.schmitt1@gmail.com>,
"linux-iio@vger.kernel.org" <linux-iio@vger.kernel.org>,
"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"Lorenz Christian (ME-SE/EAD2)" <Christian.Lorenz3@de.bosch.com>,
"Frauendorf Ulrike (ME/PJ-SW3)" <Ulrike.Frauendorf@de.bosch.com>,
"Dolde Kai (ME-SE/PAE-A3)" <Kai.Dolde@de.bosch.com>
Subject: Re: [PATCH v7 2/2] iio: imu: smi240: add driver
Date: Tue, 17 Sep 2024 12:13:01 +0100 [thread overview]
Message-ID: <20240917121301.3864a3f7@jic23-huawei> (raw)
In-Reply-To: <AM8PR10MB4721196E13BCDAD7ABAD8E85CD602@AM8PR10MB4721.EURPRD10.PROD.OUTLOOK.COM>
On Mon, 16 Sep 2024 20:32:56 +0000
"Shen Jianping (ME-SE/EAD2)" <Jianping.Shen@de.bosch.com> wrote:
> >Hi Shen,
> >
> >I suspect I led you astray. regmap core seems unlikely to feed us little endian
> >buffers on writes (they should be CPU endian I think) so there should be memcpy()
> >for that not a get_unaligned_le16()
> >
> >> +
> >> +static int smi240_regmap_spi_write(void *context, const void *data,
> >> + size_t count)
> >> +{
> >> + u8 reg_addr;
> >> + u16 reg_data;
> >> + u32 request;
> >> + struct spi_device *spi = context;
> >> + struct iio_dev *indio_dev = dev_get_drvdata(&spi->dev);
> >> + struct smi240_data *iio_priv_data = iio_priv(indio_dev);
> >> +
> >> + if (count < 2)
> >> + return -EINVAL;
> >> +
> >> + reg_addr = ((u8 *)data)[0];
> >> + reg_data = get_unaligned_le16(&((u8 *)data)[1]);
> >
> >Why is the regmap core giving us an le16?
> >I probably sent you wrong way with this earlier :( memcpy probably the correct
> >choice here.
>
> Yes, you are right. We shall use memcpy to keep the be CPU endian. Just using memcpy may be not enough.
>
> Shall we also change regmap_config.val_format_endian from REGMAP_ENDIAN_LITTLE to REGMAP_ENDIAN_NATIVE ?
>
> This is to make sure that regmap_write passes the reg-value to smi240_regmap_spi_write without changing the CPU endian.
>
Hmm. I'd missed that control. If the register data needs to be little endian
then it is correct to leave that set as REGMAP_ENDIAN_LITTLE as then
the regmap core will do the endian swap for you on Big endian systems.
If I follow that bit of regmap correctly it will then have the data
in the right order so the above still wants to just be a memcpy.
As it stands, on a Big endian host, regmap will use the val_format_endian
to decide to flip the bytes. This code then flips them back again and
the value written is big endian which is not what you intend!
Easy way to check this will be to set it, on your little endian
host, to REGMAP_BIG_ENDIAN and see what you get in the value.
Then consider if you'd had get_unaligned_be16
then it would end up as little endian again. This should mirror
the current situation if this driver runs on a big endian host.
Hope that confusing set of comments helps!
Jonathan
next prev parent reply other threads:[~2024-09-17 11:13 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-09-13 10:00 [PATCH v7 0/2] iio: imu: smi240: add bosch smi240 driver Jianping.Shen
2024-09-13 10:00 ` [PATCH v7 1/2] dt-bindings: iio: imu: smi240: add Bosch smi240 Jianping.Shen
2024-09-13 17:54 ` Conor Dooley
2024-09-17 16:58 ` Krzysztof Kozlowski
2024-09-17 20:42 ` Conor Dooley
2024-09-13 10:00 ` [PATCH v7 2/2] iio: imu: smi240: add driver Jianping.Shen
2024-09-14 16:32 ` Jonathan Cameron
2024-09-16 20:32 ` Shen Jianping (ME-SE/EAD2)
2024-09-17 11:13 ` Jonathan Cameron [this message]
2024-09-17 13:13 ` Shen Jianping (ME-SE/EAD2)
2024-09-28 14:36 ` Jonathan Cameron
2024-09-17 16:59 ` [PATCH v7 0/2] iio: imu: smi240: add bosch smi240 driver Krzysztof Kozlowski
2024-09-18 8:14 ` Shen Jianping (ME-SE/EAD2)
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=20240917121301.3864a3f7@jic23-huawei \
--to=jic23@kernel.org \
--cc=Christian.Lorenz3@de.bosch.com \
--cc=Jianping.Shen@de.bosch.com \
--cc=Kai.Dolde@de.bosch.com \
--cc=Ulrike.Frauendorf@de.bosch.com \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=dima.fedrau@gmail.com \
--cc=krzk+dt@kernel.org \
--cc=lars@metafoo.de \
--cc=linux-iio@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=marcelo.schmitt1@gmail.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;
as well as URLs for NNTP newsgroup(s).