Received: by 2002:a25:1985:0:0:0:0:0 with SMTP id 127csp2334967ybz; Thu, 23 Apr 2020 16:14:20 -0700 (PDT) X-Google-Smtp-Source: APiQypJtElVpI6mxps84uis7HsCYWRg56VxPZ0O3Lb//Mv4h6SjBv8SF6YihlM49R6CYOZv6zY6i X-Received: by 2002:a17:906:6c93:: with SMTP id s19mr4500658ejr.135.1587683660185; Thu, 23 Apr 2020 16:14:20 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1587683660; cv=none; d=google.com; s=arc-20160816; b=XZG8q1CyoQaQM6Q56Mc3VOiet7j9tdRwXAYL2e9ry0p7sRdNGb193DOBdUlKOTSmHF XNZC14kKMxvaUovo3cgbkAF6b4+SPCrVb/NQl2HUf20qJdAtzauGnA1mn8V8vTxeaETs e9ySCcPRxuvvZXefuDd+7dHX8PVMMjyalJsXisofNZczcL0eOK3sjt7wZQAAZU2LgBmX wn4RpQpFlQ0H3Lm0HEyIzM0EtSoxBTBdF7wbOVOOjd/pCTbDagYso34e7Ip/FBteNpX5 V3fNymnShSbTaxUAcMjXe67LakH/NzQEeoDMtJnG5aWKxp97Xwl12raamjtQt2h652rq gsIg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:subject:message-id:date:cc:to :from:mime-version:content-transfer-encoding:content-disposition; bh=ZTtc8czrwwVF7+ytqKXbLdJrxZsmrS/SNbQvLyXwrOE=; b=etDcjRIWPlNtJ6bDeDo4GZgandW2JC2eiXcV/sk0c9ySCFX1YMJG2Ac9YXOoBv+hPQ EFFthimHULMJKUHECeSL9xpGjk7RLe8jtQA+DXUkrT9iAU3jhF3YxhvfvFGMNlDKaoWI 1kSvGyTTM7o5Rl3nkXL6NHSltWIvXNcgGImHvGLYY6y6lsqyP2Nv2iFdH5onXHZW8asT dudtd9NOxi2OpdY24ZNnhZvMXNrAGA9A8obAnJ54gB7RTbSaJmT69vMNWOEit9CbkGCr op+hXbWKeWFN+y0y0cxVYrpfNpkBly42OtRXJyQHeNaJRCCiFs7fmJErIO0ZgeQM5gdP 9Tfw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id e8si1943934ejt.23.2020.04.23.16.13.56; Thu, 23 Apr 2020 16:14:20 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729224AbgDWXLT (ORCPT + 99 others); Thu, 23 Apr 2020 19:11:19 -0400 Received: from shadbolt.e.decadent.org.uk ([88.96.1.126]:50270 "EHLO shadbolt.e.decadent.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728575AbgDWXGw (ORCPT ); Thu, 23 Apr 2020 19:06:52 -0400 Received: from [192.168.4.242] (helo=deadeye) by shadbolt.decadent.org.uk with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1jRkvZ-0004nR-IX; Fri, 24 Apr 2020 00:06:41 +0100 Received: from ben by deadeye with local (Exim 4.93) (envelope-from ) id 1jRkvV-00E6vx-Ln; Fri, 24 Apr 2020 00:06:37 +0100 Content-Type: text/plain; charset="UTF-8" Content-Disposition: inline Content-Transfer-Encoding: 8bit MIME-Version: 1.0 From: Ben Hutchings To: linux-kernel@vger.kernel.org, stable@vger.kernel.org CC: akpm@linux-foundation.org, Denis Kirjanov , "Jonathan Cameron" , "Greg Kroah-Hartman" , "Lars-Peter Clausen" , "=?UTF-8?q?Lars=20M=C3=B6llendorf?=" Date: Fri, 24 Apr 2020 00:06:43 +0100 Message-ID: X-Mailer: LinuxStableQueue (scripts by bwh) X-Patchwork-Hint: ignore Subject: [PATCH 3.16 176/245] iio: buffer: align the size of scan bytes to size of the largest element In-Reply-To: X-SA-Exim-Connect-IP: 192.168.4.242 X-SA-Exim-Mail-From: ben@decadent.org.uk X-SA-Exim-Scanned: No (on shadbolt.decadent.org.uk); SAEximRunCond expanded to false Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 3.16.83-rc1 review patch. If anyone has any objections, please let me know. ------------------ From: Lars Möllendorf commit 883f616530692d81cb70f8a32d85c0d2afc05f69 upstream. Previous versions of `iio_compute_scan_bytes` only aligned each element to its own length (i.e. its own natural alignment). Because multiple consecutive sets of scan elements are buffered this does not work in case the computed scan bytes do not align with the natural alignment of the first scan element in the set. This commit fixes this by aligning the scan bytes to the natural alignment of the largest scan element in the set. Fixes: 959d2952d124 ("staging:iio: make iio_sw_buffer_preenable much more general.") Signed-off-by: Lars Möllendorf Reviewed-by: Lars-Peter Clausen Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman [bwh: Backported to 3.16: adjust context] Signed-off-by: Ben Hutchings --- drivers/iio/industrialio-buffer.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) --- a/drivers/iio/industrialio-buffer.c +++ b/drivers/iio/industrialio-buffer.c @@ -478,7 +478,7 @@ static int iio_compute_scan_bytes(struct { const struct iio_chan_spec *ch; 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, @@ -491,6 +491,7 @@ static int iio_compute_scan_bytes(struct length = ch->scan_type.storagebits / 8; bytes = ALIGN(bytes, length); bytes += length; + largest = max(largest, length); } if (timestamp) { ch = iio_find_channel_from_si(indio_dev, @@ -502,7 +503,10 @@ static int iio_compute_scan_bytes(struct length = ch->scan_type.storagebits / 8; bytes = ALIGN(bytes, length); bytes += length; + largest = max(largest, length); } + + bytes = ALIGN(bytes, largest); return bytes; }