Re: [PATCH v7 1/5] iio: core: Add IIO_VAL_EMPTY type

[Jonathan Cameron <jic23@kernel.org>]

On Tue, 26 Aug 2025 14:52:27 -0400
Ben Collins <bcollins@kernel.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@kernel.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