From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-oi1-f178.google.com (mail-oi1-f178.google.com [209.85.167.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 65DF529E11A for ; Sun, 8 Mar 2026 01:45:09 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.167.178 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772934311; cv=none; b=n+SCO+9SqFcJpxBu81QRQxOtAU5SChuMk2H2stjKJaxBvzJ0EyHVoWNQooJnybSCs6X1C+sbgs787NZDRY1uWpIJN3KZNe98gueU17ZDqkgkQDhEX9Y9UJnVWjMmP6zyUX3LvYMlpItjL4uJOjbHYW+v//2h7Wah539A4vP1dzE= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772934311; c=relaxed/simple; bh=w0Og34GEi1Pn7pz/AH2AqV6Spqskx9CZxx/s0UZTH+c=; h=From:Date:Subject:MIME-Version:Content-Type:Message-Id:References: In-Reply-To:To:Cc; b=qbOftgJFya6TmQ2P9SOfjfTJYGEJC9/kYh7HFeu09xYDsXOB/4le/hgqupuBZVGc1JbNVqH7LuUfP0WqVS4UCd01sBcMGuEk93+R1uw0kR1kMpZYh1VT7MmlrABld17m24SCO3U9/HNmhb7GRgfS2nuZzwFh+Ow9D8L3+pTb5Ig= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=baylibre.com; spf=pass smtp.mailfrom=baylibre.com; dkim=pass (2048-bit key) header.d=baylibre-com.20230601.gappssmtp.com header.i=@baylibre-com.20230601.gappssmtp.com header.b=QvchBrTQ; arc=none smtp.client-ip=209.85.167.178 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=baylibre.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=baylibre.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=baylibre-com.20230601.gappssmtp.com header.i=@baylibre-com.20230601.gappssmtp.com header.b="QvchBrTQ" Received: by mail-oi1-f178.google.com with SMTP id 5614622812f47-463a0e14abfso7797236b6e.2 for ; Sat, 07 Mar 2026 17:45:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=baylibre-com.20230601.gappssmtp.com; s=20230601; t=1772934308; x=1773539108; darn=vger.kernel.org; h=cc:to:in-reply-to:references:message-id:content-transfer-encoding :mime-version:subject:date:from:from:to:cc:subject:date:message-id :reply-to; bh=2CGaHrjCmbnPLyL4ZyvnQXb7Y/JQNhM/tEkjcoUuxPI=; b=QvchBrTQnquNbz8bDuvk3Wy/bC3PW/J7Ocl4e5DGvthIKN7y4wgaVHjfh8s56+zuPO sTLIrLQJ/gGv0SdJiam87TUs57Uhtct6x6yI4Y82JxJsMgqs6sVyLgsvRjDOwst+SBEc VcNKpf8/FaK6qTl0JIU7lrT3rLiE0c+mRQ5mg+7vM0/AKRWbeo62GGTLlqmmmWekO8Rp CM0HBaVOaUrgMmkxQgAK8jnDIkJo5vzA2OHcOwsODlrKENf8mgiYl9Bqyq5bFe/3PONj pcWmvTDs0Rlq60Wm4E3yImnmBZSrGn0syn6vgwijZhEaC4U3dCWkkhwj44wFoKyB9WbO ml+Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1772934308; x=1773539108; h=cc:to:in-reply-to:references:message-id:content-transfer-encoding :mime-version:subject:date:from:x-gm-gg:x-gm-message-state:from:to :cc:subject:date:message-id:reply-to; bh=2CGaHrjCmbnPLyL4ZyvnQXb7Y/JQNhM/tEkjcoUuxPI=; b=AfPTOZKalwhhyXhjsBVyXCulUDgJ3xJOcpPK6mTacx23+wmCM79rj/WgYuRuYJUnPx b+LO0ils+dzfv19wpCJozW4obiwah4RJs9I9AkA7HrCL9+hlZWcV3ll7dlgJ0SnA/RjB 4Zr6rjiDia2/pPbqhb2iDj/1SOBZVEgYRbQiFPDQXdfaRlKB9kNCk0fXDsSiFmFrPz/8 bjhi+ESyGvthSwNsoIibvvkSEi1TgN7p9TPXcrl4YDgS19IgWK+SFGPVQST8TT8uPJPJ B4s5uUKZoU8CjTEVcmMdM8b3lAfOqiF7ao2eqN3l66mwzj9xoFO8gNI/BXs6ZlouJXSu qpjA== X-Forwarded-Encrypted: i=1; AJvYcCWdM//oCHRBfcgNTD5tFaolc9KZmDq9Zt+QCLCVb4m8xkPr+YLaPssftA1zh91fu4WQheGarehf908=@vger.kernel.org X-Gm-Message-State: AOJu0YyLzBeyuEVeCYlqkWqL6uxXFIsS71Rj4lVvwq0NdJxZnUsIg0yH VzTjZA61I8BX082+G0DtPZX9QHVn1FZQzO1VA24NglfVlABmFTx5HRgVCX8ywuUSFkY= X-Gm-Gg: ATEYQzyLjhj0SmgsKjivj6+YM9Jl+A31L990fWgPiSLOMGUDaQOvpE//FyXXkbGMIdt u6etOmgFq9O0OylmuWwtB3U5pMOXGQNM+nAzkUOjnXrIydeWSorRAcde1nCkLt5MNKrpn+puEuB ueXnIAf/WkrE7Rr22WRVm6eW0yCLaYGgQ+4Y6H7RC0rDQmKKdQZBL+U1IaR81F9jTU2reURN6+Y BY0H49MXxFo4mO/AUhwo6tn1AurgRYGirnPu10S+Nkl3gAiXKCkpmFqh+g76H15MAYPdwx9AoBA gnx+aODdborThTXkHvr/HOrvEIxTzNjkoQcN8Nz/rEzS50WDsUiiOj4QCa4ANBt0zTmGdTf0jY4 YGM70ZCFrO42ndQvoEiJqjubeTQILUp3xSr3bqBOxTPpx0CnJyal3n6xK+u6e2/x0efNt3h0FXY I9iXWJgOui28v0jGHyQptVq0nOlVkFeWLUct9rU/Y= X-Received: by 2002:a05:6808:a54a:20b0:45e:ada4:f2ba with SMTP id 5614622812f47-466dcb1aa0fmr2781061b6e.38.1772934308352; Sat, 07 Mar 2026 17:45:08 -0800 (PST) Received: from [127.0.1.1] ([2600:8803:e7e4:500:a7b4:e550:6d81:e067]) by smtp.gmail.com with ESMTPSA id 5614622812f47-466dfa96903sm3244357b6e.13.2026.03.07.17.45.06 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 07 Mar 2026 17:45:07 -0800 (PST) From: David Lechner Date: Sat, 07 Mar 2026 19:44:13 -0600 Subject: [PATCH v2 5/5] iio: buffer: fix timestamp alignment when quaternion in scan Precedence: bulk X-Mailing-List: linux-iio@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <20260307-iio-fix-timestamp-alignment-v2-5-d1d48fbadbbf@baylibre.com> References: <20260307-iio-fix-timestamp-alignment-v2-0-d1d48fbadbbf@baylibre.com> In-Reply-To: <20260307-iio-fix-timestamp-alignment-v2-0-d1d48fbadbbf@baylibre.com> To: Jiri Kosina , Jonathan Cameron , Srinivas Pandruvada , =?utf-8?q?Nuno_S=C3=A1?= , Andy Shevchenko , =?utf-8?q?Lars_M=C3=B6llendorf?= , Lars-Peter Clausen , Greg Kroah-Hartman Cc: Jonathan Cameron , Lixu Zhang , Francesco Lavra , linux-input@vger.kernel.org, linux-iio@vger.kernel.org, linux-kernel@vger.kernel.org, David Lechner X-Mailer: b4 0.15-dev X-Developer-Signature: v=1; a=openpgp-sha256; l=3379; i=dlechner@baylibre.com; h=from:subject:message-id; bh=w0Og34GEi1Pn7pz/AH2AqV6Spqskx9CZxx/s0UZTH+c=; b=owEBbQGS/pANAwAKAcLMIAH/AY/AAcsmYgBprNSPruc5cJFHnS3aL00cqgukj78lxIP6Uxqvq YxfRHlWNXiJATMEAAEKAB0WIQTsGNmeYg6D1pzYaJjCzCAB/wGPwAUCaazUjwAKCRDCzCAB/wGP wHA7CACcsWKER/egQdfZKlLPUp16lhhStL2FvmJ9UEsQmzoM1cI9FSIBa/G9/kJRYeM+fs36Ab+ imG1igOODLYZZoQfaR/AtT4avUA9JPGG8Xv/UVfRPq9UUS5Br8vxjlJXCuX5zcTVlsPXDmrBjmp ryG+2cpQF3cC733JZ3M3Uid5YV7/wr5yCKTpqppTj8A/BVk+4Q+BH60BxpEpxLPMY3UxWCMHnk3 62hiX7mbBmhfQRkDJzOhCGRy1OB8Pcj0/EDZrRtJG5RisEtoooA2jS7k1cGnUVUrTbuRLXZ0E8S v8deHr2r8HastiMcZJviIAiGBghNZD5mHcM0R0Qrv6yGzrQg X-Developer-Key: i=dlechner@baylibre.com; a=openpgp; fpr=8A73D82A6A1F509907F373881F8AF88C82F77C03 Fix timestamp alignment when a scan buffer contains an element larger than sizeof(int64_t). Currently s32 quaternions are the only such element, and the one driver that has this (hid-sensor-rotation) has a workaround in place already so this change does not affect it. Previously, we assumed that the timestamp would always be 8-byte aligned relative to the end of the scan buffer, but in the case of a scan buffer a 16-byte quaternion vector, scan_bytes == 32, but the timestamp needs to be placed at offset 16, not 24. ts_offset is now a value in bytes so we have to change how the array access is done. Signed-off-by: David Lechner --- v2 changes: * Use cached timestamp offset instead of largest scan element size. * Mention change of ts_offset semantics in commit message. To test this, I used hid-sensor-rotation minus the first patch in the series so that we can see that the timestamp actually moved to the correct location. Before this patch, the timestamp (8 bytes ending with "98 18") is in the wrong location. 00000000 6a 18 00 00 ac f3 ff ff 83 2d 00 00 02 d3 ff ff |j........-......| 00000010 00 00 00 00 00 00 00 00 5a 17 a0 2a 73 cb 98 18 |........Z..*s...| 00000020 ad 17 00 00 6a f4 ff ff 35 2b 00 00 ca d0 ff ff |....j...5+......| 00000030 00 00 00 00 00 00 00 00 2a a6 bb 30 73 cb 98 18 |........*..0s...| 00000040 92 1e 00 00 50 ec ff ff ea c1 ff ff 78 f0 ff ff |....P.......x...| 00000050 00 00 00 00 00 00 00 00 8f 3b a7 39 77 cb 98 18 |.........;.9w...| After this patch, timestamp is now in the correct location. 00000000 55 0f 00 00 dd 1f 00 00 af 0b 00 00 ec 3e 00 00 |U............>..| 00000010 c7 17 68 42 6d d0 98 18 00 00 00 00 00 00 00 00 |..hBm...........| 00000020 57 0e 00 00 c8 1f 00 00 d1 0e 00 00 42 3e 00 00 |W...........B>..| 00000030 56 a2 87 48 6d d0 98 18 00 00 00 00 00 00 00 00 |V..Hm...........| 00000040 a3 e2 ff ff d3 1b 00 00 0b c9 ff ff cc 20 00 00 |............. ..| 00000050 27 59 4d b3 72 d0 98 18 00 00 00 00 00 00 00 00 |'YM.r...........| I also tested this with a different driver not affected by this bug to make sure that the timestamp is still in the correct location for all other drivers. --- include/linux/iio/buffer.h | 12 ++++++++++-- 1 file changed, 10 insertions(+), 2 deletions(-) diff --git a/include/linux/iio/buffer.h b/include/linux/iio/buffer.h index d37f82678f71..8fd0d57d238f 100644 --- a/include/linux/iio/buffer.h +++ b/include/linux/iio/buffer.h @@ -34,8 +34,16 @@ static inline int iio_push_to_buffers_with_timestamp(struct iio_dev *indio_dev, void *data, int64_t timestamp) { if (ACCESS_PRIVATE(indio_dev, scan_timestamp)) { - size_t ts_offset = indio_dev->scan_bytes / sizeof(int64_t) - 1; - ((int64_t *)data)[ts_offset] = timestamp; + size_t ts_offset = ACCESS_PRIVATE(indio_dev, scan_timestamp_offset); + + /* + * The size of indio_dev->scan_bytes is always aligned to the + * largest scan element's alignment (see iio_compute_scan_bytes()). + * So there may be padding after the timestamp. ts_offset contains + * the offset in bytes that was already computed for correctly + * aligning the timestamp. + */ + *(int64_t *)(data + ts_offset) = timestamp; } return iio_push_to_buffers(indio_dev, data); -- 2.43.0