From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-oi1-f179.google.com (mail-oi1-f179.google.com [209.85.167.179]) (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 830E936F42D for ; Mon, 11 May 2026 16:05:19 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.167.179 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778515522; cv=none; b=bqhYczjNkfOLZFezEI+sx9Qq3RbCd83+2uixNmzf3CAkk7ml8ooYqNDzT1xTwuPSIpgUMGQxVoB2htLr+R3QnjXnMayRe1Va67HPxxhSLQQk0+mX2TUh7BWqljEZ+VM0dHDErdovLnvgPAohhCnnumunCSCXJzutUQ0NYMIUyTY= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778515522; c=relaxed/simple; bh=uNxTZHy6hBKRG2nwBuXWKk+HJWsmPsaMDZjnsyp9Hws=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=R40XFtUqp4YAwq9Rz+WcpdkLygDkwij4AEOhjU4DL9pJD6wltEBlbSCbfIDrpOb6R37kVfpdIXw6j57u+LJRrfysrBzlKmlgBWXZ8pPiMN1sOC/1LtIQab86uEvGqSdVzKQV+fp0zd/IWwdGETWw26QbgBnjjZQ/VLleLKnCGtA= 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.20251104.gappssmtp.com header.i=@baylibre-com.20251104.gappssmtp.com header.b=ADzugxLR; arc=none smtp.client-ip=209.85.167.179 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.20251104.gappssmtp.com header.i=@baylibre-com.20251104.gappssmtp.com header.b="ADzugxLR" Received: by mail-oi1-f179.google.com with SMTP id 5614622812f47-47c35be031dso2865567b6e.3 for ; Mon, 11 May 2026 09:05:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=baylibre-com.20251104.gappssmtp.com; s=20251104; t=1778515518; x=1779120318; darn=vger.kernel.org; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=hpvyj6Jcfot6MCDnve5ReW22UI34QHDg5W5s/ynN2wU=; b=ADzugxLRRLmVxHPwrm6M2xDKuy12rm0KK7VMw5nEFKaawHjiin8j+EAZ/+37YPjNJJ RAyvsFAzFYjl6iNs3tRMXg+Ov8maowUVqyqvI0kPppu20nU4WQCkZ15nTb89ey5JyBYY 7+LPgzDByYmvb+doL8vNRD0z7FH3nWKvFH1IA+XZT7qalVksum+BFGTrkcjw2jtiYCgQ tp+GyPw92XPESiLNN0NtSUSz9Rs+A6ESE5MwiXwiZiuHhyZ9cXKV+wx5GXjApo6f48dJ TcXFXuXSUdTHgqEOa33qmQXfWHz20SL/vaVdR2OZUUt8XY43ycZqg47YfEsNdrYrKRu9 jpeA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1778515518; x=1779120318; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=hpvyj6Jcfot6MCDnve5ReW22UI34QHDg5W5s/ynN2wU=; b=prhbS5a+w36Mo0n16sLm29VTEmwQyQZXMjjigR5FsYse8Z6u9X3sL4BX2g3RewK5gI Xt/+2SWLOlJOPbuFS+YlKObBoPQ7hd489S+aulgvanWOqw5TqaP4MkwKowMacyNQl1wQ IsVe47zHGwjvfm+RMywovVDdPCC+/uEW8okxCB2VN8qUqhL1BaKMBfUrZTmd7Q9kz0/i cBjrpw7wf1OMDVqoHNHO6DmsgT3uemLj2iByssUY2u2QDAk7H4m/6Hz34/mCJCAMRZNt 5AEuyyZZX64JI3+WjjvQSU80JDKAy4DClGgQBJFAVxsgIB/kdq7M0/4FX5dcUDoHA+I8 LhoA== X-Forwarded-Encrypted: i=1; AFNElJ/xGF2ba0s8OPWkrfBQwcYfMTznl+SR3VXfOY4aFTJfIqpIwOwbzjNpxVpC5bNJAXmNvmBR6olffMFDtOw=@vger.kernel.org X-Gm-Message-State: AOJu0YxrpjPewDctcjsOc/AWUx7Hzpul/1ZHEh20z+N7e0tk8S1Ny3uQ PawuuF5/kQ8hymV0TJ+ZyVXMVNk5PTp51jNldA2MhX6Aog9Bj5wMh04C+vrwG+7yzhk= X-Gm-Gg: Acq92OElWxrK7cHizygWmIf5mAn/02UjxvetPCGEB+EcAdhQDOqdLfp+y3jW22Tafuj WAxuEMM6ZzgEagsOY2eBYf25MyoQDRQVP+XEbmOwH48epMo3D+vJ/O1lSVCTksKTkiG9wUGOrIG cIQJ+Su0tmzBKXZ9yLpDMrrFqqCFLVY5w07P08V81MkpcpUkFs7OuSBttxsLYwQ4Ax+83v1wuf+ QxlEemA4zb9FV8n8uCQV9Dw8Y/y6mSJZ4Ep+QAvUFG5xyPNAkGDvT3udcgEoVx5acaI6MVfNv6F 3n8LlHVeWDwMktsyTYJn7Ee0oq9B7zFQiHtU/+QsKJSb1+0VVkhhDl1La2RUmi400nSwOYdQ+6T RYilHPsfMqfMrrQExPoAF3RyJp3OOpwFaIaoZr/csQiitvwjZCyytpudPGmKUNYxURBPMmoDUGi bIpsucjLBPpjAowiEIi5NLLXWu/apBo/hbKdREu/ULJ5F44sgB2pTP0EuCfpIXjNfKcIIP9uw= X-Received: by 2002:a05:6808:1b23:b0:479:d605:64ab with SMTP id 5614622812f47-4807f92a250mr7995938b6e.0.1778515518378; Mon, 11 May 2026 09:05:18 -0700 (PDT) Received: from ?IPV6:2600:8803:e7e4:500:591:4577:3439:3a1e? ([2600:8803:e7e4:500:591:4577:3439:3a1e]) by smtp.gmail.com with ESMTPSA id 5614622812f47-47c76936271sm20420540b6e.9.2026.05.11.09.05.17 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 11 May 2026 09:05:17 -0700 (PDT) Message-ID: <36fc2a82-004a-470e-b625-b1795d3f4fe3@baylibre.com> Date: Mon, 11 May 2026 11:05:16 -0500 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] iio: adc: ad7766: Update to use iio_push_to_buffers_with_ts() To: Ethan Tidmore , Lars-Peter Clausen , Michael Hennerich , Jonathan Cameron Cc: =?UTF-8?Q?Nuno_S=C3=A1?= , Andy Shevchenko , linux-iio@vger.kernel.org, linux-kernel@vger.kernel.org References: <20260510221404.22834-1-ethantidmore06@gmail.com> Content-Language: en-US From: David Lechner In-Reply-To: <20260510221404.22834-1-ethantidmore06@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 5/10/26 5:14 PM, Ethan Tidmore wrote: > The old ABI function iio_push_to_buffers_with_timestamp() is no longer > preferred due to it being inherently unsafe. > > Update to the current standard iio_push_to_buffers_with_ts(). > > Signed-off-by: Ethan Tidmore > --- > I asked a while back regarding possible things that would suffice for a > GSoC proposal, that has came and went, but I remember Jonathan > mentioning wanting this to be done. If this is correct, would a series > be preferred next time? When I look at these, I always look at how the buffer is being defined and used elsewhere to see if there are any bugs or room for improvement. In this case, we could consider changing: unsigned char data[ALIGN(3, sizeof(s64)) + sizeof(s64)] __aligned(IIO_DMA_MINALIGN); to something a bit easier to understand. The most direct replacement would be: IIO_DECLARE_DMA_BUFFER_WITH_TS(u8, data, 4); In addition to improving readability, there are two more improvements in this change that need to be called out. I used u8 because that is shorter than unsigned char, but it is the same type. And the 3 in the original implementation is actually wrong. The SPI transfer is doing: /* First byte always 0 */ ad7766->xfer.rx_buf = &ad7766->data[1]; ad7766->xfer.len = 3; So it skipping the first element of the array and writing to the next 3 elements, so we actually need to declare 4 elements in the array. Other than those 2 changes, the macro expands to the original code. In cases like this where there is only one channel (or cases where there are multiple channels, but we always read all channels), we prefer a struct instead to make it easier to see the layout. This case is a bit odd since there isn't a 24-bit data type but it works to use a struct anyway. So we could also write the buffer declaration as: struct { /* 24-bit big-endian value stored in 32-bits */ u8 data[4]: aligned_s64 ts; } __aligned(IIO_DMA_MINALIGN); > > drivers/iio/adc/ad7766.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/drivers/iio/adc/ad7766.c b/drivers/iio/adc/ad7766.c > index 9e4a66477d2d..4f256ce522c2 100644 > --- a/drivers/iio/adc/ad7766.c > +++ b/drivers/iio/adc/ad7766.c > @@ -74,8 +74,8 @@ static irqreturn_t ad7766_trigger_handler(int irq, void *p) > if (ret < 0) > goto done; > > - iio_push_to_buffers_with_timestamp(indio_dev, ad7766->data, > - pf->timestamp); > + iio_push_to_buffers_with_ts(indio_dev, ad7766->data, sizeof(ad7766->data), > + pf->timestamp); > done: > iio_trigger_notify_done(indio_dev->trig); >