From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f44.google.com (mail-wm1-f44.google.com [209.85.128.44]) (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 536FF3812EC for ; Tue, 2 Jun 2026 16:55:30 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.44 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780419332; cv=none; b=TU/EH8S/oprvmJvPyZSKR9We5LlPnFGrI7ttg2z/kWS0u/hRFjvN/QiEyg9P3u/vnWPJjvo1jVRIj2qIX3RWZ3RSw1B9tmFx8rP4P8xT3Ju7OYpWh8b5dgf51tVULjnkDPhkiGrcJOEY/rA9eN7GPji8UdFTuPraSYKelID8NA0= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780419332; c=relaxed/simple; bh=7M6qQwSwD+XrHhy1JS5GMZiaeqWwjrdH7qVYXbsQEsU=; h=Message-ID:Subject:From:To:Cc:Date:In-Reply-To:References: Content-Type:MIME-Version; b=Wbtzf2wetwdCW/S/CoDZpo0puIEgr8D6oJC8cl5pjnRm6FCQD5YTftPz1X7AIG3bZ9UNSxN06BW61ibDg5Kr1sUW7FeFATMe/AxfsQFN3yCUfB8CYb7neyTh+YydsfFMgqHRrds+oIn+4pgAEADELKJwaD4n2NQ0WX/VPHZIFiI= 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=YbUN5+uK; arc=none smtp.client-ip=209.85.128.44 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="YbUN5+uK" Received: by mail-wm1-f44.google.com with SMTP id 5b1f17b1804b1-490388fd0dbso116883085e9.0 for ; Tue, 02 Jun 2026 09:55:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1780419329; x=1781024129; darn=vger.kernel.org; h=mime-version:user-agent:content-transfer-encoding:references :in-reply-to:date:cc:to:from:subject:message-id:from:to:cc:subject :date:message-id:reply-to; bh=lR1aiUfHvK9pACcDS8heDpRLK9T5JqYjX9U4vnMG5Yk=; b=YbUN5+uKTXcpMd9xhLVeeQZGG5docKseXHF5TmwoxiE4nMYMAJxfsKQTg37mwoJYcH xaU3G4ehkfD32MKuXv+mfyhUx0ifb6S2jMfccJFIoqCmCLw1dP8cFu5vzQmcEwBIYgli K93N/VnsTsn8sPFrtA7Ft125FayhLyryQqncEA0D8fn+oetH3feBHqVsozFJQaXMTjS6 taA+0vLN6tDMFI3Lbj7QFOPwreLZMj3WyX/NtTesXV955YiafHWhDjfhgNVJjNy1ViTh s4JN0xytM+5k/+qwiukNaJpMkgp0pePOS+DjUHMInIyDgLUJGWc6gaLZgjKQfNdeYtxo sbnw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1780419329; x=1781024129; h=mime-version:user-agent:content-transfer-encoding:references :in-reply-to:date:cc:to:from:subject:message-id:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=lR1aiUfHvK9pACcDS8heDpRLK9T5JqYjX9U4vnMG5Yk=; b=dUReC8Rat0MBR6Shvic99OfaXa7vrG5HgSoujROc2KlX0n7ATI7qg/Xv3o5nJRjnkS Zmwow67HoxLfkSU2jfvmVB1rBKb/QT/0BR08pRB2aebqGT1wnLLB/9VX8F0J5jNskQEy yBewsIBZ7n7ocwWfiJQVOokcxtQiR34eEKfzKXk6czClwkqJ7wI2mCqtQrdrefdvjLqg r0rvj6UJVlM+CRLfrtUGNVBqaTU3HKvwm657w28pR+A8ql0b0o1BEBV3y7mbOEjim63t k/7oSEJNT8qj2p/p9nskzLtT9DzrDN3am/ZAlCfnmDyieC2wkg3QTOGx2styK65AiFhp 93cw== X-Forwarded-Encrypted: i=1; AFNElJ8Ly8zLwYa9Ul41BtF4fWx4KzHH74sG3VVSYpVawjIy7LXXF1t08Ul/as3QDiaC927lfX8p5b7dmRU=@vger.kernel.org X-Gm-Message-State: AOJu0YxD4gVpXbpI6iDxsdTysZU1O+KFbrGv++gcjncLIp9o3NOA/2hV UhrNjtwoXFsLCx7G3+Tlf6ZWLNvEI1FLTZ8d5zwzmif1C2BKawnXmcCF X-Gm-Gg: Acq92OFDvq54+o9I7YoU5GLRRtIjJXGhui0u21by5X7oI8/x7sBWuxiRDKHVKmQROY7 d+ck8T/UoJgkI0qC2CXGMv6Fp1CL04yqHIGxulusYikpOTWUb/9AQIt1V52wbmZNCuIHT/AuRNp 4LbijdIfrMEnkCKAH2ynJGI5kV6FRoNZi8OLVxmEaXWiVwIJ67fxLHM5ZorVU4dG4mTAerZoBas skA4KSypTvRdEImAE4wxZMgbEYpDq4C5Lye1mxbfIdyoE31hj5pT8b4xJUUTv60sv+33IFij7R9 c+LbmHNNPHbMahA/HtSQmOF9OImMXlpQi1mJv3na0G+PvdYtsDXr9Etz9rFBSl6zUABC8FPBctz apLwE+Vg2V5C1A6sJO/WJTCjzyEllHWM/6ja+5Br7x+v9RWBsoifnm0IAd0tj6ZjpX15Xu8HNUZ xpbgZwpTSDV3PKbJhcQWz4/2o7tGsWAjgYX5scvEB61R6b6ysIGz/jxHw6ozvFcTNphw0zvLHC7 vJq237H1wBO X-Received: by 2002:a05:600c:c3db:20b0:48e:5fb8:f80f with SMTP id 5b1f17b1804b1-490b50bfabdmr7086835e9.24.1780419328608; Tue, 02 Jun 2026 09:55:28 -0700 (PDT) Received: from ?IPv6:2001:818:ea56:d000:56e0:ceba:7da4:6673? ([2001:818:ea56:d000:56e0:ceba:7da4:6673]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-490b0e0f343sm82850455e9.1.2026.06.02.09.55.27 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 02 Jun 2026 09:55:28 -0700 (PDT) Message-ID: Subject: Re: [PATCH v15 06/12] iio: core: add decimal value formatting into 64-bit value From: Nuno =?ISO-8859-1?Q?S=E1?= To: Rodrigo Alencar <455.rodrigo.alencar@gmail.com>, rodrigo.alencar@analog.com Cc: linux-kernel@vger.kernel.org, linux-iio@vger.kernel.org, devicetree@vger.kernel.org, linux-doc@vger.kernel.org, Jonathan Cameron , David Lechner , Andy Shevchenko , Lars-Peter Clausen , Michael Hennerich , Rob Herring , Krzysztof Kozlowski , Conor Dooley , Jonathan Corbet , Andrew Morton , Petr Mladek , Steven Rostedt , Andy Shevchenko , Rasmus Villemoes , Sergey Senozhatsky , Shuah Khan Date: Tue, 02 Jun 2026 17:56:32 +0100 In-Reply-To: References: <20260531-adf41513-iio-driver-v15-0-da09adf1c0dd@analog.com> <20260531-adf41513-iio-driver-v15-6-da09adf1c0dd@analog.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.56.2 (3.56.2-2.fc42) Precedence: bulk X-Mailing-List: linux-doc@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 On Mon, 2026-06-01 at 16:12 +0100, Rodrigo Alencar wrote: > On 26/06/01 10:43AM, Nuno S=C3=A1 wrote: > > On Sun, May 31, 2026 at 09:30:49AM +0100, Rodrigo Alencar via B4 Relay = wrote: > > > From: Rodrigo Alencar > > >=20 > > > Create new format types for iio values (IIO_VAL_DECIMAL64_*), which > > > defines the representation of fixed decimal point values into a singl= e > > > 64-bit number. This new format increases the range of represented val= ues, > > > allowing for integer parts greater than 2^32, as bits are not "wasted= " > > > in the fractional part, which can be seen in IIO_VAL_INT_PLUS_MICRO a= nd > > > IIO_VAL_INT_PLUS_NANO. Helpers are created to compose and decompose 6= 4-bit > > > decimals into integer values used in IIO formatting interfaces, which > > > creates consistency and avoid error-prone manual assignments when usi= ng > > > wordpart macros. When doing the parsing, kstrtodec64() is used with t= he > > > scale defined by the specific decimal format type. > > >=20 > > > Signed-off-by: Rodrigo Alencar > > > --- > > > =C2=A0drivers/iio/industrialio-core.c | 47 ++++++++++++++++++++++++++= +++++++-------- > > > =C2=A0include/linux/iio/types.h=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |= 30 ++++++++++++++++++++++++++ > > > =C2=A02 files changed, 68 insertions(+), 9 deletions(-) > > >=20 > > > diff --git a/drivers/iio/industrialio-core.c b/drivers/iio/industrial= io-core.c > > > index bd6f4f9f4533..a88088cac641 100644 > > > --- a/drivers/iio/industrialio-core.c > > > +++ b/drivers/iio/industrialio-core.c > > > @@ -19,6 +19,7 @@ > > > =C2=A0#include > > > =C2=A0#include > > > =C2=A0#include > > > +#include > > > =C2=A0#include > > > =C2=A0#include > > > =C2=A0#include > > > @@ -26,7 +27,6 @@ > > > =C2=A0#include > > > =C2=A0#include > > > =C2=A0#include > > > -#include > > > =C2=A0 > > > =C2=A0#include > > > =C2=A0#include > > > @@ -655,6 +655,7 @@ static ssize_t __iio_format_value(char *buf, size= _t offset, > > > unsigned int type, > > > =C2=A0 =C2=A0 int size, const int *vals) > > > =C2=A0{ > > > =C2=A0 int tmp0, tmp1; > > > + int l =3D 0; > > > =C2=A0 s64 tmp2; > > > =C2=A0 bool scale_db =3D false; > > > =C2=A0 > > > @@ -698,7 +699,6 @@ static ssize_t __iio_format_value(char *buf, size= _t offset, > > > unsigned int type, > > > =C2=A0 case IIO_VAL_INT_MULTIPLE: > > > =C2=A0 { > > > =C2=A0 int i; > > > - int l =3D 0; > > > =C2=A0 > > > =C2=A0 for (i =3D 0; i < size; ++i) > > > =C2=A0 l +=3D sysfs_emit_at(buf, offset + l, "%d ", vals[i]); > > > @@ -707,8 +707,25 @@ static ssize_t __iio_format_value(char *buf, siz= e_t > > > offset, unsigned int type, > > > =C2=A0 case IIO_VAL_CHAR: > > > =C2=A0 return sysfs_emit_at(buf, offset, "%c", (char)vals[0]); > > > =C2=A0 case IIO_VAL_INT_64: > > > - tmp2 =3D (s64)((((u64)vals[1]) << 32) | (u32)vals[0]); > > > + tmp2 =3D iio_val_s64_from_s32s(vals); > >=20 > > I might be missing something but can't we just call > > iio_val_s64_compose()? Likely even inline in sysfs_emit_at()? >=20 > There is a compose() already. >=20 Yes and I was suggesting using that one instead iio_val_s64_from_s32s() :).= To be consistent to what you use in the other path (which is decompose() if I'm n= ot mistaken). > =C2=A0 > > It would match your call to iio_val_s64_decompose() below. >=20 > here are the helpers prototype: >=20 > s64 iio_val_s64_compose(s32 val0, s32 val1); > s64 iio_val_s64_from_s32s(const s32 *vals); >=20 > void iio_val_s64_decompose(s64 dec64, s32 *val0, s32 *val1); > void iio_val_s64_to_s32s(s64 dec64, s32 *vals); > =C2=A0 Yes and it feels that iio_val_s64_compose() and iio_val_s64_decompose() are= the only ones we really need? (Maybe with other naming if you prefer iio_val_s64_fro= m_s32s() and iio_val_s64_to_s32s()). > > And the above makes me wonder if the compose()/decompose() are not the > > only helpers we need? At least in terms of parameters? I mean, just > > assuming we only have two integers instead of allowing s32* and opening > > the door for misbehave :)? >=20 > I suppose we would really need some sort of: >=20 > union iio_val { > s32 val32[2]; > s64 val64; > }; >=20 > or even add a: >=20 > struct { void *ptr, size_t size } I just meant using two where we just have (s32 val1, s32 vals2) given that = is what IIO has anyways. No need to overthinking it for now IMO. - Nuno S=C3=A1 > > - Nuno S=C3=A1 > >=20