From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-qv1-f41.google.com (mail-qv1-f41.google.com [209.85.219.41]) (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 878D82E9EC7 for ; Mon, 9 Feb 2026 21:38:37 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.219.41 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770673118; cv=none; b=fE2ssx2fYsxef5S7RxePuaA23nX8MgLPiBf3hzJEofYIXyxF9d7ZZWeKHtZIO8+gZqhOiUU6YjNhvS64anwhZN0FoKc8yEojuexqmxXZ4vjJvqq42Q/oIS6RtYUz0Ih9JP798OeXdQlErgwUxT2MOXKRFvv8D2w9Dw42XhhU6EY= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770673118; c=relaxed/simple; bh=5GHYEKMlDul7BOm0jgDqV+4gn5HRhQHy4qrYeQfhomQ=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=YTOOU4jIKHhHSa8+iz4W2Bz5qXe/QFyGp+ZdzKAFNCQzgXnD+A2hZsyaLt5F69vdbbGgrRv5UZ0a3j8RjybLS6OVA6ViXFE0Dly8TaiStUd3RaYdcTCnOTCGbl9c+4DLlin6RHz3fNQXVeeE4wvUhNKGlXLrs0sBWdNnp/tiVfI= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=aSzneRZK; arc=none smtp.client-ip=209.85.219.41 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="aSzneRZK" Received: by mail-qv1-f41.google.com with SMTP id 6a1803df08f44-8954d10e62dso5163556d6.2 for ; Mon, 09 Feb 2026 13:38:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1770673116; x=1771277916; darn=vger.kernel.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=Q102/CAL/7wui07Domg8kQEolGIu9Ft5psDg1cdjPtA=; b=aSzneRZKCV/IQoZAC7nu2OnqYHIYxVnLZ2ZH0Qrdnuqgw76l0cJRRBLYtSnbUQlrFs Y25VJkHjYasUdcfA9QRQxPXG9hgwuJ1sb4XG1K+d41ORTkEsLvPJ4Y1OzU1am81snKLF /+IIB1KJB+UVV29ebBkGbdEjYEVLdGI0sgZQsnLVsJVqJRVz6e3odJe1UDNwAu3quLLW tTavBzu4/vcAbqMQ/M8OsOWxnokwNXb9p/qBmJpjYIlaAAe3EZVCM+Zr1O0zsqw8XXFp oAMKRitzAj8TJfbQTgSS3nSXMrb8I1wD28ZH0iFUbPQx6H/VmQTyQDzLiNH/BXwEMUuP W9mg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1770673116; x=1771277916; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=Q102/CAL/7wui07Domg8kQEolGIu9Ft5psDg1cdjPtA=; b=ddVJjamH6x2yYPEpcG1L98fcAfXXMc6u2tNoTMoPDxwPqA0+op+H6Cg4CEI/0suyFr RNz3/b6lB3uqh0+GCveGux/Y10vblDSzI/D9/X4bkLvZ5B0paqck1xoM8hg51UZ1bI/w rSEuqCDMXuFzLmSfU5T0rdlQwpEdd1HTibsuysrOe5mCAlfCuwCByX5OeLlFFXerfgI2 zvWOqmW8h30HalQORscYPhEegSWAwVwtB4oxUdQ1H1GEZ04Mbu7Kjn7mhBztNoORkCUG Qfb4kGjyGPY/GQOFqzdjmDZol/0oDFHDWb2yVC70IRb6rpLQeTm/UpPY6scNw3kyVQYm oshQ== X-Forwarded-Encrypted: i=1; AJvYcCXjQ9wX+B8kZ0hGkorSsm/oSvQM5v7yxrjb2NPLe1zk2jysyQuqxnlraHkdVsAQ9ONX1zheWKcFciWU+h8=@vger.kernel.org X-Gm-Message-State: AOJu0Yw5/fwTIq0SdKXQ1WMYkavIuUEu2DF09pr2KB2Rpg2FYh/iBEJu dC+hJY/4xBBm2Kv/lgjiwpF4PaWPDeBeih7bgLAHuV4NsNsXeDElBjMi X-Gm-Gg: AZuq6aKmrwbs9+EKds776nSjVBKuGywIscK9s/i9e8yipgFbJFXwfQovX6mzYyolgxA ZrN7Efzoj3Crzk0pShxeNFYodLfQc9/LOGYNCz3J/pzkfSFIqyHaLHcNby+DqPQG0vF+6sCFwnu SqphMiNibu+Ul11MtE1SKK3Tuy/98poPCMQCVx3VwD2+ctA6/v9dDRnKvBX+fH1DzZon/zPnzZX gur1YQl5cTn9JFlgDePXbbhejQww9Z2AtR3ohvMuM4mEnX48nwJpdTnK/ZEs0vd+J4g6Ah9rKSV FeXuVHu7THN6zCmWEYJAQar1PsGItgeEFvT3T6dDiJxjbASyEZGqS9IiX9D7C2elA9/jm2vVQn4 L5g6SLsFAMh1MmuxmAQrShCOzxYwH7PgDg6IWHdBeTlO0rEXl0x85eLIMszHQrVUFrsrTQqyP5a Pgm840k3RRPM5jAjfIpofUvP4WT0C2y9f7RMOGrhFywT0m5mH66wWcDgFBa7FowdWOG7XRmy4+8 Q== X-Received: by 2002:a05:622a:1392:b0:4f1:ac43:8122 with SMTP id d75a77b69052e-506398657d8mr138801681cf.1.1770673116300; Mon, 09 Feb 2026 13:38:36 -0800 (PST) Received: from JSANTO12-L01.ad.analog.com (200-100-197-209.dial-up.telesp.net.br. [200.100.197.209]) by smtp.gmail.com with ESMTPSA id d75a77b69052e-5064f581107sm55698271cf.28.2026.02.09.13.38.33 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 09 Feb 2026 13:38:35 -0800 (PST) Date: Mon, 9 Feb 2026 18:38:31 -0300 From: Jonathan Santos To: Jonathan Cameron Cc: Jonathan Santos , linux-iio@vger.kernel.org, linux-kernel@vger.kernel.org, Michael.Hennerich@analog.com, lars@metafoo.de, dlechner@baylibre.com, nuno.sa@analog.com, andy@kernel.org Subject: Re: [PATCH 1/3] iio: adc: ad7768-1: fix one-shot mode data acquisition Message-ID: References: <20260207164851.51874c46@jic23-huawei> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20260207164851.51874c46@jic23-huawei> On 02/07, Jonathan Cameron wrote: > On Sat, 31 Jan 2026 22:35:20 -0300 > Jonathan Santos wrote: > > > According to the datasheet, one-shot mode requires a SYNC_IN pulse to > > trigger a new sample conversion. In the current implementation, No sync > > pulse was sent after switching to one-shot mode and reinit_completion() > > was called before mode switching, creating a race condition where spurious > > interrupts during mode change could trigger completion prematurely. > > > > Fix by sending a sync pulse after configuring one-shot mode and moving > > reinit_completion() after the pulse to ensure it only waits for the > > actual conversion completion. > That smells like a race... > > What stops us taking a long break between ending that sync pulse and > the reinit_completition() such that we have initialized if before the > complete()? > Yes, you are right, we have a race here. The inital problem was having the ad7768_set_mode() before the reinit_completion() because, almost everytime, a new conversion is done before setting the one-shot mode, so the complete() happens before the expected trigger (that never happened because ad7768_send_sync_pulse() was not present). > You always have to do it before what ever ultimately makes the complete() > happen. Have you seen an sign of the spurious interrupts or is that > more a conjecture of what might happen? > Agreed, I can put reinit_completion() before sending the sync pulse to avoid this situation. But maybe it is better just to remove the one-shot mode as discussed in the patch 2/3. What do you think? > Jonathan > > > > > Fixes: a5f8c7da3dbe ("iio: adc: Add AD7768-1 ADC basic support") > > Signed-off-by: Jonathan Santos > > --- > > drivers/iio/adc/ad7768-1.c | 9 +++++++-- > > 1 file changed, 7 insertions(+), 2 deletions(-) > > > > diff --git a/drivers/iio/adc/ad7768-1.c b/drivers/iio/adc/ad7768-1.c > > index fcd8aea7152e..8d39b71703ae 100644 > > --- a/drivers/iio/adc/ad7768-1.c > > +++ b/drivers/iio/adc/ad7768-1.c > > @@ -463,12 +463,17 @@ static int ad7768_scan_direct(struct iio_dev *indio_dev) > > struct ad7768_state *st = iio_priv(indio_dev); > > int readval, ret; > > > > - reinit_completion(&st->completion); > > - > > ret = ad7768_set_mode(st, AD7768_ONE_SHOT); > > if (ret < 0) > > return ret; > > > > + /* One-shot mode requires a SYNC pulse to generate a new sample */ > > + ret = ad7768_send_sync_pulse(st); > > + if (ret) > > + return ret; > > + > > + reinit_completion(&st->completion); > > + > > ret = wait_for_completion_timeout(&st->completion, > > msecs_to_jiffies(1000)); > > if (!ret)