Linux IIO development
 help / color / mirror / Atom feed
From: Jonathan Cameron <jic23@kernel.org>
To: Ben Collins <bcollins@kernel.org>
Cc: "David Lechner" <dlechner@baylibre.com>,
	"Nuno Sá" <nuno.sa@analog.com>,
	"Andy Shevchenko" <andy@kernel.org>,
	linux-iio@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v5 5/5] iio: mcp9600: Add support for IIR filter
Date: Mon, 18 Aug 2025 20:10:35 +0100	[thread overview]
Message-ID: <20250818201035.7a107dec@jic23-huawei> (raw)
In-Reply-To: <2025081814-grumpy-prawn-ef1a0e@boujee-and-buff>


> > >  	case IIO_CHAN_INFO_SCALE:
> > >  		*val = 62;
> > >  		*val2 = 500000;
> > >  		return IIO_VAL_INT_PLUS_MICRO;
> > > +  
> > If you want the extra space put it in previous patch.
> >   
> > >  	case IIO_CHAN_INFO_THERMOCOUPLE_TYPE:
> > >  		*val = mcp9600_tc_types[data->thermocouple_type];
> > >  		return IIO_VAL_CHAR;
> > > +
> > > +	case IIO_CHAN_INFO_LOW_PASS_FILTER_3DB_FREQUENCY:
> > > +		if (data->filter_level == 0)  
> > 
> > Return the current requested value. An error is just going to confuse
> > someone who tried to write this before enabling the filter and then
> > checked to see if the write was successful.  
> 
> I could not get a concensus on this. On the one hand, if a user sets a
> value here, would they not assume that the filter was enabled? What
> about cases where a filter_type can be more than one valid type with
> different available coefficients for each? What should it show then?

So I was thinking of this like other things with 'enables' such as events.
For those you always set the value first.  They don't really have a type
field though (well they do but the ABI allows multiple at once unlike filters
so we end up with a quite different looking ABI).

Agreed it gets challenging with multiple filter types. If it weren't for
advertising the range I'd suggest just stashing whatever was written and
then mapping it to nearest possible when the filter type is set.
That's what the ad7124 does for changing between filters anyway
though oddly it doesn't seem to have a control for filter type.

This is a good argument against the whole 'none' value for filter type
- that's not much used so we could deprecate it for new drivers.

I'm not particularly keen on filter_enable but seems we are coming back
around to that option to avoid this corner case.  Alternative being what
you have here which isn't great for ease of use.

So for next version let's go for that. Make sure to include Documentation
in a separate patch though so it's easy to see an poke holes in.

ABI design is a pain sometimes.

Thanks,

Jonathan

  parent reply	other threads:[~2025-08-18 19:10 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-08-18  3:59 [PATCH v5 0/5] iio: mcp9600: Features and improvements Ben Collins
2025-08-18  3:59 ` [PATCH v5 1/5] dt-bindings: iio: mcp9600: Add microchip,mcp9601 and add constraints Ben Collins
2025-08-18  6:28   ` Krzysztof Kozlowski
2025-08-18 17:20     ` Conor Dooley
2025-08-18  6:33   ` Rob Herring (Arm)
2025-08-18  6:46     ` Ben Collins
2025-08-18  6:40   ` Krzysztof Kozlowski
2025-08-18  6:52     ` Ben Collins
2025-08-18  3:59 ` [PATCH v5 2/5] iio: mcp9600: White space and fixed width cleanup Ben Collins
2025-08-18  3:59 ` [PATCH v5 3/5] iio: mcp9600: Recognize chip id for mcp9601 Ben Collins
2025-08-18 18:03   ` Jonathan Cameron
2025-08-18  3:59 ` [PATCH v5 4/5] iio: mcp9600: Add support for thermocouple-type Ben Collins
2025-08-18  3:59 ` [PATCH v5 5/5] iio: mcp9600: Add support for IIR filter Ben Collins
2025-08-18 18:15   ` Jonathan Cameron
2025-08-18 18:47     ` Ben Collins
2025-08-18 18:59       ` David Lechner
2025-08-18 19:31         ` Ben Collins
2025-08-18 19:10       ` Jonathan Cameron [this message]
2025-08-18 20:00         ` Ben Collins
2025-08-19 18:28           ` Jonathan Cameron
2025-08-19 18:38             ` Jonathan Cameron
2025-08-19 20:41               ` Ben Collins
2025-08-19 20:37             ` Ben Collins

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20250818201035.7a107dec@jic23-huawei \
    --to=jic23@kernel.org \
    --cc=andy@kernel.org \
    --cc=bcollins@kernel.org \
    --cc=dlechner@baylibre.com \
    --cc=linux-iio@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=nuno.sa@analog.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox