From: Lorenzo Bianconi <lorenzo.bianconi83@gmail.com>
To: Jonathan Cameron <jic23@kernel.org>
Cc: linux-iio@vger.kernel.org,
Lorenzo BIANCONI <lorenzo.bianconi@st.com>,
Denis Ciocca <denis.ciocca@st.com>,
Gregor Boirie <gregor.boirie@parrot.com>
Subject: Re: [PATCH] iio: common: st_sensors: fix channel data parsing
Date: Sat, 1 Oct 2016 19:32:30 +0200 [thread overview]
Message-ID: <20161001173229.GC22409@lorenzobianconi.net> (raw)
In-Reply-To: <8b3ae000-43fc-9624-acc6-8416ef22fb5f@kernel.org>
On Oct 01, Jonathan Cameron wrote:
> On 01/10/16 15:18, Lorenzo Bianconi wrote:
> >> On 28/09/16 21:06, Lorenzo Bianconi wrote:
> >>> Using realbits as i2c/spi read len, when that value is not byte aligned
> >>> (e.g 12 bits), lead to skip msb part of out data registers.
> >>> Fix this using storagebits as read length
> >>>
> >>> Signed-off-by: Lorenzo Bianconi <lorenzo.bianconi@st.com>
> >> Hi Lorenzo,
> >
> > Hi Jonathan,
> >
> >>
> >> This would ideally have had a fixes tag.
> >>
> >> I think it was
> >> Fixes: e7385de5 ("iio:st_sensors: align on storagebits boundaries")
> >> Doing that would also have lead to you to the logic that lead to
> >> this buggy change in the first place. Would also have shown
> >> you that there is another place that probably suffers from the
> >> same sort of issue.
> >>
> >
> > Right. I missed the same issue in st_sensors_read_axis_data()
> >
> >> Gregor can you take a look at this please.
> >>
> >> If I recall the issue that lead to the original patch it was
> >> that we were miss handling 24 bit values on pressure sensors and
> >> this was intended to pad them?
> >>
> >> I think the 'right' fix will be something along the lines of:
> >> unsigned int bytes_to_read = (channel->scan_type.realbits + 7) >> 3;
> >>
> >
> > This should not be correct if you consider 8bit accel like LIS331DL.
> 8 + 7 = 15
> 15 >> 3 = 1 byte.
Right sorry :)
>
> Would get interest if the data was shifted to run across two bytes, but
> it's not. Could handle that case as well by doing
> (channel->scan_type.realbits + channel->scan_type.shift + 7) >> 3
>
Ack. I will send a v2 afer testing on multiple devices (8, 12, 24 realbits)
> > Taking a look to lps22hb code I think storagebits should be 24 and not
> > 32 for pressure channel. What do you think?
> No. Storage bytes must always be a power of 2. It's assumed at various
> points in the buffer handling code in the core and userspace code.
> This is why Gregor's fix was needed.
>
> These 24 bit packed readings are a pain, but it was much worse to try
> and remove the aligned data assumptions that need them to be powers
> of 2. Just think about 3 bytes floating in a little endian integer
> field vs the big endian version. It's a real pain to unwind.
Right :)
Regards,
Lorenzo
> >
> >> Should give 2 bytes for a 12 bit and still the 3 bytes needed for a
> >> 24 bit read.
> >>
> >> Thanks,
> >>
> >
> > Thanks,
> > Lorenzo
> >
> >> Jonathan
> >>> ---
> >>> drivers/iio/common/st_sensors/st_sensors_buffer.c | 5 ++---
> >>> 1 file changed, 2 insertions(+), 3 deletions(-)
> >>>
> >>> diff --git a/drivers/iio/common/st_sensors/st_sensors_buffer.c b/drivers/iio/common/st_sensors/st_sensors_buffer.c
> >>> index fe7775b..d01aa34 100644
> >>> --- a/drivers/iio/common/st_sensors/st_sensors_buffer.c
> >>> +++ b/drivers/iio/common/st_sensors/st_sensors_buffer.c
> >>> @@ -30,16 +30,15 @@ static int st_sensors_get_buffer_element(struct iio_dev *indio_dev, u8 *buf)
> >>>
> >>> for_each_set_bit(i, indio_dev->active_scan_mask, num_data_channels) {q
> >>> const struct iio_chan_spec *channel = &indio_dev->channels[i];
> >>> - unsigned int bytes_to_read = channel->scan_type.realbits >> 3;
> >>> unsigned int storage_bytes =
> >>> channel->scan_type.storagebits >> 3;
> >>>
> >>> buf = PTR_ALIGN(buf, storage_bytes);
> >>> if (sdata->tf->read_multiple_byte(&sdata->tb, sdata->dev,
> >>> channel->address,
> >>> - bytes_to_read, buf,
> >>> + storage_bytes, buf,
> >>> sdata->multiread_bit) <
> >>> - bytes_to_read)
> >>> + storage_bytes)
> >>> return -EIO;
> >>>
> >>> /* Advance the buffer pointer */
> >>>
> >>
> >
> >
> >
>
--
UNIX is Sexy: who | grep -i blonde | talk; cd ~; wine; talk; touch; unzip; touch; strip; gasp; finger; gasp; mount; fsck; more; yes; gasp; umount; make clean; sleep
next prev parent reply other threads:[~2016-10-01 17:32 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-09-28 20:06 [PATCH] iio: common: st_sensors: fix channel data parsing Lorenzo Bianconi
2016-10-01 13:30 ` Jonathan Cameron
2016-10-01 14:18 ` Lorenzo Bianconi
2016-10-01 14:58 ` Jonathan Cameron
2016-10-01 17:32 ` Lorenzo Bianconi [this message]
2016-10-03 9:52 ` Gregor Boirie
2016-10-03 10:16 ` Lorenzo Bianconi
2016-10-03 19:35 ` Lorenzo Bianconi
2016-10-03 19:49 ` Jonathan Cameron
2016-10-24 12:51 ` Lorenzo Bianconi
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=20161001173229.GC22409@lorenzobianconi.net \
--to=lorenzo.bianconi83@gmail.com \
--cc=denis.ciocca@st.com \
--cc=gregor.boirie@parrot.com \
--cc=jic23@kernel.org \
--cc=linux-iio@vger.kernel.org \
--cc=lorenzo.bianconi@st.com \
/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.