linux-kernel - Re: [PATCH v7 1/5] iio: core: Add IIO_VAL

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20250831161909.1bc5872a@jic23-huawei>
Date: Sun, 31 Aug 2025 16:19:09 +0100
From: Jonathan Cameron <jic23@...nel.org>
To: Ben Collins <bcollins@...nel.org>
Cc: David Lechner <dlechner@...libre.com>, Nuno Sá
 <nuno.sa@...log.com>, Andy Shevchenko <andy@...nel.org>, Antoniu Miclaus
 <antoniu.miclaus@...log.com>, Lars-Peter Clausen <lars@...afoo.de>, Michael
 Hennerich <Michael.Hennerich@...log.com>, linux-iio@...r.kernel.org,
 linux-kernel@...r.kernel.org
Subject: Re: [PATCH v7 1/5] iio: core: Add IIO_VAL_EMPTY type

On Tue, 26 Aug 2025 14:52:27 -0400
Ben Collins <bcollins@...nel.org> wrote:

> On Tue, Aug 26, 2025 at 12:00:05PM -0500, David Lechner wrote:
> > On 8/25/25 7:10 PM, Ben Collins wrote:  
> > > In certain situations it may be necessary to return nothing when reading
> > > an attribute.
> > > 
> > > For example, when a driver has a filter_type of "none" it should not
> > > print any information for frequency or available frequencies.
> > > 
> > > Signed-off-by: Ben Collins <bcollins@...nel.org>
> > > ---
> > >  drivers/iio/industrialio-core.c | 1 +
> > >  include/linux/iio/types.h       | 1 +
> > >  2 files changed, 2 insertions(+)
> > > 
> > > diff --git a/drivers/iio/industrialio-core.c b/drivers/iio/industrialio-core.c
> > > index 159d6c5ca3cec3f5c37ee9b85ef1681cca36f5c7..e4ff5b940223ab58bf61b394cc9357cd3674cfda 100644
> > > --- a/drivers/iio/industrialio-core.c
> > > +++ b/drivers/iio/industrialio-core.c
> > > @@ -702,6 +702,7 @@ static ssize_t __iio_format_value(char *buf, size_t offset, unsigned int type,
> > >  	case IIO_VAL_INT_64:
> > >  		tmp2 = (s64)((((u64)vals[1]) << 32) | (u32)vals[0]);
> > >  		return sysfs_emit_at(buf, offset, "%lld", tmp2);
> > > +	case IIO_VAL_EMPTY:
> > >  	default:
> > >  		return 0;
> > >  	}
> > > diff --git a/include/linux/iio/types.h b/include/linux/iio/types.h
> > > index ad2761efcc8315e1f9907d2a7159447fb463333e..261745c2d94e582bcca1a2abb297436e8314c930 100644
> > > --- a/include/linux/iio/types.h
> > > +++ b/include/linux/iio/types.h
> > > @@ -32,6 +32,7 @@ enum iio_event_info {
> > >  #define IIO_VAL_FRACTIONAL 10
> > >  #define IIO_VAL_FRACTIONAL_LOG2 11
> > >  #define IIO_VAL_CHAR 12
> > > +#define IIO_VAL_EMPTY 13
> > >  
> > >  enum iio_available_type {
> > >  	IIO_AVAIL_LIST,
> > >   
> > 
> > This is an interesting idea, but I think it would be a lot of work
> > to teach existing userspace tools to handle this new possibility.
> > 
> > On top of that, I'm not quite convinced it is necessary. If a numeric
> > value is undefined, then there is already a well known expression for
> > that: "nan". Or in the case of this series, the 3dB point when the
> > filter is disable could also be considered "inf". Using these would have
> > a better chance of working with existing userspace tools since things
> > like `scanf()` can already handle these.  
> 
> I'm ok with "inf", but then would there also be an "inf" in available
> frequencies?
> 
> This would take us all the way back to where I could just not even need
> a filter_type==none and make the 3db available values:
> 
> { inf, 0.5xxx, ... }
> 
> And inf would just be the filter is disabled.
> 

Definitely an interesting concept and with appropriate documentation
additions I rather like it.  What particular formating of INF do
fscanf and friends accept?  looks like it's the strtod() man page
which says INF of INFINITY (disregarding case).  So indeed inf seems
like a valid choice.

Jonathan