From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-oo1-f49.google.com (mail-oo1-f49.google.com [209.85.161.49]) (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 6283C305673 for ; Sun, 17 May 2026 19:21:35 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.161.49 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779045698; cv=none; b=c/Ud45gwFXk74gDHT4xxZNLzRwrFUsrFrXHpkeCHxdwJZRQkuAv/ZKX3W5WPdLLPrO+wdZuQhHB89kAs0JDm9nE8jEPMp5zlQGn7BTNAW++igZxt2L5Yd86nTyjeexAnJceLkWNIK9O/xEuf93NsbcYtd2evtkFQg4egQ+AfLeU= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779045698; c=relaxed/simple; bh=lH1GgG6AZ3p8TFNccFcpJy8FScpxCDQooWelGA+EHCY=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=Ni3ixQli4UVCTALYwXsmG8ioRzysE3llU5ImfvyNEig+jX0UQBX3q+2ez0KSQFxv2lEyssijbdpGqkw6CaM906Ps96FSSWHecqZD3AHaNdVLYLif4/p57W5simgLns+qSj9JtohnW8G7c8pj4NdswUdNpp6LfU+uacxAONSiI5I= 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=WNgLu7g9; arc=none smtp.client-ip=209.85.161.49 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="WNgLu7g9" Received: by mail-oo1-f49.google.com with SMTP id 006d021491bc7-69b8cdfcf50so738048eaf.2 for ; Sun, 17 May 2026 12:21:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=baylibre-com.20251104.gappssmtp.com; s=20251104; t=1779045694; x=1779650494; 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=avFUFeQjZc5s2Fh1Gw+bXzbv6Nmu8tEYY1j2IJydQzo=; b=WNgLu7g9882rZjfblRCA0f7R+Si3jCbcL1IoVyJ8xem5nV0o4D+3VgpV6BfeA4DypW 7Vo0DDNEbaIeGQq9qpNKAXpZ3JbsRUKtkXXyQbd7LYp+UzlHtbWugKcwH9IYl6v+zreR KhBLKDwI1nosZXqI7ZfeE+rJ1YwQVs/CmhQpEBtyQpi5ukocCLV7/wsBXGELBKHDcbGB jQUO0U0mVjc2XXiatiROYmSGkeYuWtLX3PIGK25sItq8Y0yZxQKl3Yr3clEDHEZwTrzK o/JNEU0loLdHQ2z5VhS0G0B/wYf0i1l9qJZLFJlBmossgWlMzZJb73d4iQJ+pXbLR2yZ db8Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1779045694; x=1779650494; 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=avFUFeQjZc5s2Fh1Gw+bXzbv6Nmu8tEYY1j2IJydQzo=; b=fNrv/ivEIXZDwVhiu7rG8UbPX1CKisYLvpIn78AReJvxfh2T+lOFe35bcSitMtEGrk X2tZlNdtXkNQATy1SmbTLUwrBXbBdZew8BUwh3LdQINuIfKxGsNXJ7JxyhROTg2CJpYS Lk1KaUlQG5xSSg681Ozs+cVdmtXUtSqY669GsQfI474xAjf3dsX4VE1Z+uvu5BsCZxO/ r3fZ5T59v/VhapUBJ3AuaMdLIG4YvYxxmffw/VWRZxIdzYOUHJOcpt9vb0O1mbeM7ZlV sSIOukGTK2yuQiugg3DOADBzxtRsajy2MWvMKVt2Br4GEeEKVjvMeRw9VgxMsOTGaLL5 FDRw== X-Forwarded-Encrypted: i=1; AFNElJ+76DRzaoYpPqkj4Bsjlq/6vhGSAP96kGkWiOi0ailfNzZ73r7k1eUm37yfMF56hgMSH/ET+ywNwMbralY=@vger.kernel.org X-Gm-Message-State: AOJu0Ywv69LtboFnCxMTdhPXIqMFXxfG1S//5PADXkTCkGShByU3x/81 P6oHY/F1LYGoxwv8SDWI6oQD7Wy1+qgK+iq+hnxSX8xJQATfPHcM1wfFCW9j2OeaCf8= X-Gm-Gg: Acq92OHO3VufyrEoCFnFUdvcTQkdOVNbCfoyVpus/jwUQC4oI6lc/WkmfXrF5EigXqO WaTF9jeIgofLImDoskaqx1pgH4WQ5AMdkSGEDT5fJlBXKJPvmxYi8G9Trgyp9G9Ym7tpjcCMwb5 lH+AsSR0M7efHZ6T6tYuNFQsWdKrLYzibW/8p3Kc4Ngco8lG0gZejA6Or/4AqtiF1IP9uJQD/zE sMNa6DR+3DKO/FBUn9tzs+G4iEHjFV+PQm6riZZLKD3kUMEd0dsDsv5H2DG71Op5ElEN8WHwaJi XfpdYWGlbo2LIPUt22L+skIDkM5NL+cxGlgabEEUAN9IwcHKu+hxzGdzXkf9IxluUVTet83gUjt wgtouhpn4thb2Hi7e3/a0tHDAq82APXg58OImSUGSf0BFTjJB2+EN1ODgVbON9g5Dy10ghejmxH f91j+aMqqpreZCFcDkgs7tIrzBAaOVOXblLO/qfbP1vObcU/JST9ys1lkPxp03+Ty/dHYW5zCBf W//Sb0x1w== X-Received: by 2002:a05:6820:4c0b:b0:694:8e6e:2e1c with SMTP id 006d021491bc7-69c9bfc92a9mr7692055eaf.60.1779045694287; Sun, 17 May 2026 12:21:34 -0700 (PDT) Received: from ?IPV6:2600:8803:e7e4:500:7a4b:ddf0:f61:f58d? ([2600:8803:e7e4:500:7a4b:ddf0:f61:f58d]) by smtp.gmail.com with ESMTPSA id 006d021491bc7-69d045e6567sm4530406eaf.3.2026.05.17.12.21.31 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 17 May 2026 12:21:32 -0700 (PDT) Message-ID: <58a66855-9fb3-48ca-8cae-ff9277f745df@baylibre.com> Date: Sun, 17 May 2026 14:21:30 -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 v11 3/6] iio: adc: ad4691: add triggered buffer support To: Jonathan Cameron Cc: radu.sabau@analog.com, Lars-Peter Clausen , Michael Hennerich , =?UTF-8?Q?Nuno_S=C3=A1?= , Andy Shevchenko , Rob Herring , Krzysztof Kozlowski , Conor Dooley , =?UTF-8?Q?Uwe_Kleine-K=C3=B6nig?= , Liam Girdwood , Mark Brown , Linus Walleij , Bartosz Golaszewski , Philipp Zabel , Jonathan Corbet , Shuah Khan , linux-iio@vger.kernel.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, linux-pwm@vger.kernel.org, linux-gpio@vger.kernel.org, linux-doc@vger.kernel.org References: <20260515-ad4692-multichannel-sar-adc-driver-v11-0-eab27d852ac2@analog.com> <20260515-ad4692-multichannel-sar-adc-driver-v11-3-eab27d852ac2@analog.com> <9b7986e1-6550-415d-b301-33089ba10177@baylibre.com> <20260517132526.27c71b70@jic23-huawei> Content-Language: en-US From: David Lechner In-Reply-To: <20260517132526.27c71b70@jic23-huawei> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 5/17/26 7:25 AM, Jonathan Cameron wrote: > On Sat, 16 May 2026 12:32:51 -0500 > David Lechner wrote: > >> On 5/15/26 8:31 AM, Radu Sabau via B4 Relay wrote: >>> From: Radu Sabau >>> >>> Add buffered capture support using the IIO triggered buffer framework. >>> >>> CNV Burst Mode: the GP pin identified by interrupt-names in the device >>> tree is configured as DATA_READY output. The IRQ handler stops >>> conversions and fires the IIO trigger; the trigger handler executes a >>> pre-built SPI message that reads all active channels from the AVG_IN >>> accumulator registers and then resets accumulator state and restarts >>> conversions for the next cycle. >>> >>> Manual Mode: CNV is tied to SPI CS so each transfer simultaneously >>> reads the previous result and starts the next conversion (pipelined >>> N+1 scheme). At preenable time a pre-built, optimised SPI message of >>> N+1 transfers is constructed (N channel reads plus one NOOP to drain >>> the pipeline). The trigger handler executes the message in a single >>> spi_sync() call and collects the results. An external trigger (e.g. >>> iio-trig-hrtimer) is required to drive the trigger at the desired >>> sample rate. >>> >>> Both modes share the same trigger handler and push a complete scan — >>> one big-endian 16-bit (__be16) slot per active channel, densely packed >>> in scan_index order, followed by a timestamp. >>> >>> The CNV Burst Mode sampling frequency (PWM period) is exposed as a >>> buffer-level attribute via IIO_DEVICE_ATTR. >>> >>> Signed-off-by: Radu Sabau > >>> + >>> +static int ad4691_manual_buffer_preenable(struct iio_dev *indio_dev) >>> +{ >>> + struct ad4691_state *st = iio_priv(indio_dev); >>> + unsigned int k, i; >>> + int ret; >>> + >>> + memset(st->scan_xfers, 0, sizeof(st->scan_xfers)); >>> + memset(st->scan_tx, 0, sizeof(st->scan_tx)); >>> + >>> + spi_message_init(&st->scan_msg); >>> + >>> + k = 0; >>> + iio_for_each_active_channel(indio_dev, i) { >>> + if (i >= indio_dev->num_channels - 1) >>> + break; /* skip soft timestamp */ >> >> I don't think timestamp gets set in the scan mask. It is handled separately. > > FWIW that is a sashiko false postive (I believe anyway!) > If we do hit this please shout as we have a core bug. > > If anyone has time to look at how hard it would be to tweak > iio_for_each_active_channel to skip a last element timestamp that > would be great. > > I think that iterates one too far which is what sashiko is tripping over. > > I'm only keen to fix that if we can make it low cost and hid it entirely > from drivers. > > Jonathan > This is what I came up with (totally untested). Since timestamp can never be set in scan_mask/active_scan_mask, it should be safe to exclude it from masklength without breaking existing code. I didn't check all callers of masklength/iio_get_masklength() though. --- diff --git a/drivers/iio/industrialio-buffer.c b/drivers/iio/industrialio-buffer.c index 9d66510a1d49..17f539fc23e2 100644 --- a/drivers/iio/industrialio-buffer.c +++ b/drivers/iio/industrialio-buffer.c @@ -2300,8 +2300,10 @@ int iio_buffers_alloc_sysfs_and_mask(struct iio_dev *indio_dev) if (channels) { int ml = 0; - for (i = 0; i < indio_dev->num_channels; i++) - ml = max(ml, channels[i].scan_index + 1); + for (i = 0; i < indio_dev->num_channels; i++) { + if (channels[i].type != IIO_TIMESTAMP) + ml = max(ml, channels[i].scan_index + 1); + } ACCESS_PRIVATE(indio_dev, masklength) = ml; }