From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id A8DC238237D; Mon, 18 May 2026 18:26:18 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=192.198.163.11 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779128780; cv=none; b=K4qKyOo+CdkeUWENeTkd4r0lLziTuYsFg+M55ficJ9WjVLE0P6nUCQviCcPdpzoHfo5JCP046pn1YltIcpN4f1FgKtpiXxm3O2s8W9lx66St9syzvZt4LhmeUDrDa8tB2I44L5+MNe9U5Vm7Op4L7HHzp3JimzOcWjdkhYCE0Gg= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779128780; c=relaxed/simple; bh=pbXYLQ1mwct3+ssZlrWJpr6OzTUkZbnMsQ/G5sb/T3M=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=AD7/43eDuGOoEq+T35lC4QD/Y67eyRbJR31nR957MQEP33uzEiMhdd1Os9xCmMCY3IwNa6mJtH6kuzid6b1V1V0QMwYGzZ6Tal+6X1pqp/x9GUTkgvMDhlVWjPAxjcz1/VE5QjG9NyaeTs7t4nCrxNpTKBXlgY277v65NDN6foI= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=intel.com; spf=pass smtp.mailfrom=intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=A2T0DUHL; arc=none smtp.client-ip=192.198.163.11 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=intel.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=intel.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="A2T0DUHL" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1779128779; x=1810664779; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=pbXYLQ1mwct3+ssZlrWJpr6OzTUkZbnMsQ/G5sb/T3M=; b=A2T0DUHLXSAZYQw2jRiF+UoKrVoD0sUG+NgJtbnOEQb18t2vQsGxLopw YUxKWtYH8sxVruSa43cAl3BbpnZ04oBxA4nDyeKXLSbRW1afM6G4WSkr4 ZJObrW+BGc0Icc6onS9dZJE4WOU0QPpHzD8wHPszfE+/amcnq74W8dnKi ojxajFEfbqExWClaWwZqO4rARkYfU4V+fyjqBpaVjrQhtM0PqYc19qSsI 3nLaQA3OGxSSKCqC+ljONKYwvx39XAdeaOkXLxRLKrsuiGC3BZF3e3Dub /9Ft5tR0johwFWGFLRiCCXov2JNgAOk0WOR15314fzbbobb8vfam97s1H A==; X-CSE-ConnectionGUID: 9qriItO/ScWlODNBpfRg1Q== X-CSE-MsgGUID: +k3VPqE9SVOFJAvzB/QnXg== X-IronPort-AV: E=McAfee;i="6800,10657,11790"; a="90575555" X-IronPort-AV: E=Sophos;i="6.23,242,1770624000"; d="scan'208";a="90575555" Received: from orviesa007.jf.intel.com ([10.64.159.147]) by fmvoesa105.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 18 May 2026 11:26:18 -0700 X-CSE-ConnectionGUID: O0zap/NiRba3AYD16GFVrA== X-CSE-MsgGUID: e9aNJkI4TGO68gsQIjE1Pw== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.23,242,1770624000"; d="scan'208";a="239764455" Received: from fpallare-mobl4.ger.corp.intel.com (HELO localhost) ([10.245.244.3]) by orviesa007-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 18 May 2026 11:26:12 -0700 Date: Mon, 18 May 2026 21:26:09 +0300 From: Andy Shevchenko To: David Lechner Cc: "Sabau, Radu bogdan" , Lars-Peter Clausen , "Hennerich, Michael" , Jonathan Cameron , "Sa, Nuno" , Andy Shevchenko , Rob Herring , Krzysztof Kozlowski , Conor Dooley , Uwe =?iso-8859-1?Q?Kleine-K=F6nig?= , 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" Subject: Re: [PATCH v11 4/6] iio: adc: ad4691: add SPI offload support Message-ID: References: <20260515-ad4692-multichannel-sar-adc-driver-v11-0-eab27d852ac2@analog.com> <20260515-ad4692-multichannel-sar-adc-driver-v11-4-eab27d852ac2@analog.com> <80f61c0b-1f36-4fee-9f76-b93f63b87abe@baylibre.com> <60d66897-41cc-4f3f-afd2-64e49f0bb55e@baylibre.com> Precedence: bulk X-Mailing-List: linux-doc@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: <60d66897-41cc-4f3f-afd2-64e49f0bb55e@baylibre.com> Organization: Intel Finland Oy - BIC 0357606-4 - c/o Alberga Business Park, 6 krs, Bertel Jungin Aukio 5, 02600 Espoo On Mon, May 18, 2026 at 10:16:38AM -0500, David Lechner wrote: > On 5/18/26 10:14 AM, Sabau, Radu bogdan wrote: > >> -----Original Message----- > >> From: David Lechner > >> Sent: Saturday, May 16, 2026 8:53 PM ... > >>> + if (st->manual_mode && st->offload) > >>> + return sysfs_emit(buf, "%llu\n", READ_ONCE(st->offload- > >>> trigger_hz)); > >> > >> Why do we need READ_ONCE? > > > > trigger_hz is u64 and if the target is 32-bit, a 64-bit access compiles to two 32-bit > > instructions, so show() reading it without a lock and store() writing it concurrently > > can produce a torn value at the compiler level. READ_ONCE/WRITE_ONCE suppress > > the compiler transformations that would allow that splitting or caching. We could > > have st->lock in show() instead, but that felt heavier than necessary for a single > > scalar where a transiently stale-but-whole read is fine. > > I would go with the mutex. It will be easier for people to understand. But why? READ_ONCE() here is exactly enough. We do not care about serialisation, we care only about integrity. With mutex it will confuse (some) people more, e.g., me. Because in that case I would think about some specific access to it that may happen. Yes, I saw many times the show functions that do mutex and then print the result when mutex is not held anymore, but for simple cases like here, mutex is overkill. Interestingly that using guard()() inside show makes the mentioned functions to print (almost) latest value of the variable in question. It narrows window down as printing will go inside critical section. -- With Best Regards, Andy Shevchenko