linux-iio.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jonathan Cameron <jic23@kernel.org>
To: "Lars Möllendorf" <lars.moellendorf@plating.de>
Cc: Hartmut Knaack <knaack.h@gmx.de>,
	Lars-Peter Clausen <lars@metafoo.de>,
	Peter Meerwald-Stadler <pmeerw@pmeerw.net>,
	linux-iio@vger.kernel.org
Subject: Re: [PATCH] iio: buffer: align the size of scan bytes to size of the largest element
Date: Fri, 6 Dec 2019 17:34:07 +0000	[thread overview]
Message-ID: <20191206173407.651ac889@archlinux> (raw)
In-Reply-To: <20191202142714.12030-1-lars.moellendorf@plating.de>

On Mon,  2 Dec 2019 15:27:14 +0100
Lars Möllendorf <lars.moellendorf@plating.de> wrote:

Even when fixing a patch send issue as you did here, please mark clearly
with v2 and add a change log saying that's what you did.  Also
please don't send in reply to the earlier thread, but instead as a
completely new thread.   The reply to thread thing seems sensible for
simple cases, but when we get to v20 (it happens ;) things get really
confusing :)

> Previous versions of `iio_compute_scan_bytes` only aligned the current
> element to its own length (i.e. its own natural alignment). This worked
> in case the length of each channel's scan elements had been smaller then
> the length of the successive channel's scan elements.

I'd modify this description a little bit.  The key thing was the length of the
last element - didn't matter what happened before that.

u32
u16
u32
would be aligned correctly I hope?

> 
> E.g.
> 
> u16
> u32 <- aligned to its natural alignment
> 
> But if the length of a channel's scan elements is greater then the
> length of scan elements of the consecutive channel no alignment had
> been taken into account. This is however needed to preserve the
> alignment for multiple consecutive sets of scan elements.
> 
> u32 <- alignment is off by two byte for the second set of scan elements
> u16 <- no alignment takes place
> 
> This commit fixes this by aligning the scan bytes to the size of the
> largest scan element.
> 
> Signed-off-by: Lars Möllendorf <lars.moellendorf@plating.de>
Code looks good to me, so just a v3 tidying up the message.

Thanks for sorting this out!  Ideally we'd add a specific
fixes tag as well for when this was introduced but I fear
it goes back nearly all the way (at least before the move
out of staging) so we can probably leave that vague for this
one unless you fancy some archaeology. 

Jonathan

> ---
>  drivers/iio/industrialio-buffer.c | 6 +++++-
>  1 file changed, 5 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/iio/industrialio-buffer.c b/drivers/iio/industrialio-buffer.c
> index 5d05c38c4ba9..2f037cd59d53 100644
> --- a/drivers/iio/industrialio-buffer.c
> +++ b/drivers/iio/industrialio-buffer.c
> @@ -546,7 +546,7 @@ static int iio_compute_scan_bytes(struct iio_dev *indio_dev,
>  				const unsigned long *mask, bool timestamp)
>  {
>  	unsigned bytes = 0;
> -	int length, i;
> +	int length, i, largest = 0;
>  
>  	/* How much space will the demuxed element take? */
>  	for_each_set_bit(i, mask,
> @@ -554,13 +554,17 @@ static int iio_compute_scan_bytes(struct iio_dev *indio_dev,
>  		length = iio_storage_bytes_for_si(indio_dev, i);
>  		bytes = ALIGN(bytes, length);
>  		bytes += length;
> +		largest = max(largest, length);
>  	}
>  
>  	if (timestamp) {
>  		length = iio_storage_bytes_for_timestamp(indio_dev);
>  		bytes = ALIGN(bytes, length);
>  		bytes += length;
> +		largest = max(largest, length);
>  	}
> +
> +	bytes = ALIGN(bytes, largest);
>  	return bytes;
>  }
>  


  reply	other threads:[~2019-12-06 17:34 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-11-29 14:30 iio_compute_scan_bytes does not seem to account for alignment if first channel uses more storagebits than its successors Lars Möllendorf
2019-11-29 17:23 ` Lars-Peter Clausen
2019-12-01 12:03   ` Jonathan Cameron
2019-12-01 12:10   ` Jonathan Cameron
2019-12-01 12:29     ` Lars-Peter Clausen
2019-12-02 13:01       ` [PATCH 1/3] iio: buffer: align the size of scan bytes to size of the largest element Lars Möllendorf
2019-12-02 13:37         ` Ardelean, Alexandru
2019-12-02 14:27           ` [PATCH] " Lars Möllendorf
2019-12-06 17:34             ` Jonathan Cameron [this message]
2019-12-04  9:24           ` [PATCH 1/3] " Lars Möllendorf
2019-12-04 11:12             ` Ardelean, Alexandru
2020-01-24 10:07 [PATCH] " Lars Möllendorf

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=20191206173407.651ac889@archlinux \
    --to=jic23@kernel.org \
    --cc=knaack.h@gmx.de \
    --cc=lars.moellendorf@plating.de \
    --cc=lars@metafoo.de \
    --cc=linux-iio@vger.kernel.org \
    --cc=pmeerw@pmeerw.net \
    /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).