| 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
| ||
|
Message-ID: <45170936-3eeb-4b7a-b75b-560660979b72@baylibre.com>
Date: Tue, 26 Aug 2025 12:20:39 -0500
From: David Lechner <dlechner@...libre.com>
To: Ben Collins <bcollins@...nel.org>, Jonathan Cameron <jic23@...nel.org>,
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>
Cc: linux-iio@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v7 4/5] iio: mcp9600: Add support for IIR filter
On 8/25/25 7:10 PM, Ben Collins wrote:
> MCP9600 supports an IIR filter with 7 levels. Add IIR attribute
> to allow get/set of this value.
>
> Use filter_type[none, ema] for enabling the IIR filter.
>
> Signed-off-by: Ben Collins <bcollins@...nel.org>
> ---
> drivers/iio/temperature/mcp9600.c | 147 ++++++++++++++++++++++++++++++++++++++
> 1 file changed, 147 insertions(+)
>
> diff --git a/drivers/iio/temperature/mcp9600.c b/drivers/iio/temperature/mcp9600.c
> index aa42c2b1a369edbd36e0d6d6d1738ed0069fd990..d3309e30628ae5cdc74378403952ba285990f4c0 100644
> --- a/drivers/iio/temperature/mcp9600.c
> +++ b/drivers/iio/temperature/mcp9600.c
> @@ -31,6 +31,7 @@
> #define MCP9600_STATUS_ALERT(x) BIT(x)
> #define MCP9600_SENSOR_CFG 0x05
> #define MCP9600_SENSOR_TYPE_MASK GENMASK(6, 4)
> +#define MCP9600_FILTER_MASK GENMASK(2, 0)
> #define MCP9600_ALERT_CFG1 0x08
> #define MCP9600_ALERT_CFG(x) (MCP9600_ALERT_CFG1 + (x - 1))
> #define MCP9600_ALERT_CFG_ENABLE BIT(0)
> @@ -94,6 +95,27 @@ static const int mcp9600_tc_types[] = {
> [THERMOCOUPLE_TYPE_R] = 'R',
> };
>
> +enum mcp9600_filter {
> + MCP9600_FILTER_TYPE_NONE,
> + MCP9600_FILTER_TYPE_EMA,
> +};
> +
> +static const char * const mcp9600_filter_type[] = {
> + [MCP9600_FILTER_TYPE_NONE] = "none",
> + [MCP9600_FILTER_TYPE_EMA] = "ema",
> +};
> +
> +static const int mcp_iir_coefficients_avail[7][2] = {
> + /* Level 0 is no filter */
> + { 0, 524549 },
> + { 0, 243901 },
> + { 0, 119994 },
> + { 0, 59761 },
> + { 0, 29851 },
> + { 0, 14922 },
> + { 0, 7461 },
> +};
> +
> static const struct iio_event_spec mcp9600_events[] = {
> {
> .type = IIO_EV_TYPE_THRESH,
> @@ -119,6 +141,8 @@ struct mcp_chip_info {
> struct mcp9600_data {
> struct i2c_client *client;
> u32 thermocouple_type;
> + int filter_level;
> + int filter_enabled;
> };
>
> static int mcp9600_config(struct mcp9600_data *data)
> @@ -129,6 +153,9 @@ static int mcp9600_config(struct mcp9600_data *data)
>
> cfg = FIELD_PREP(MCP9600_SENSOR_TYPE_MASK,
> mcp9600_type_map[data->thermocouple_type]);
> + /* The chip understands 0 as "none", and 1-7 as ema filter levels. */
> + if (data->filter_enabled)
> + FIELD_MODIFY(MCP9600_FILTER_MASK, &cfg, data->filter_level + 1);
>
> ret = i2c_smbus_write_byte_data(client, MCP9600_SENSOR_CFG, cfg);
> if (ret < 0) {
> @@ -146,7 +173,11 @@ static int mcp9600_config(struct mcp9600_data *data)
> .address = MCP9600_HOT_JUNCTION, \
> .info_mask_separate = BIT(IIO_CHAN_INFO_RAW) | \
> BIT(IIO_CHAN_INFO_THERMOCOUPLE_TYPE) | \
> + BIT(IIO_CHAN_INFO_LOW_PASS_FILTER_3DB_FREQUENCY) | \
Does the filter actually only apply to the hot junction and not the
cold junction? There is a mismatch between this being info_mask_separate
and the filter_type being IIO_SHARED_BY_ALL.
Not related to this patch, but the comment same applies to
IIO_CHAN_INFO_THERMOCOUPLE_TYPE - I missed that in previous reviews.
> BIT(IIO_CHAN_INFO_SCALE), \
> + .info_mask_separate_available = \
> + BIT(IIO_CHAN_INFO_LOW_PASS_FILTER_3DB_FREQUENCY), \
> + .ext_info = mcp9600_ext_filter, \
> .event_spec = &mcp9600_events[hj_ev_spec_off], \
> .num_event_specs = hj_num_ev, \
> }, \
> @@ -162,6 +193,57 @@ static int mcp9600_config(struct mcp9600_data *data)
> }, \
> }
>
> +static int mcp9600_get_filter(struct iio_dev *indio_dev,
> + struct iio_chan_spec const *chan)
> +{
> + struct mcp9600_data *data = iio_priv(indio_dev);
> +
> + return data->filter_enabled ? MCP9600_FILTER_TYPE_EMA :
> + MCP9600_FILTER_TYPE_NONE;
> +}
> +
> +static int mcp9600_set_filter(struct iio_dev *indio_dev,
> + struct iio_chan_spec const *chan,
> + unsigned int mode)
> +{
> + struct mcp9600_data *data = iio_priv(indio_dev);
> + int new_type;
This variable name is a little confusing. It looks like it should
rather be:
bool new_filter_enabled;
> +
> + switch (mode) {
> + case MCP9600_FILTER_TYPE_NONE:
> + new_type = 0;
> + break;
> +
> + case MCP9600_FILTER_TYPE_EMA:
> + new_type = 1;
> + break;
> +
> + default:
> + return -EINVAL;
> + }
> +
> + /* Do not reset the filter if we don't need to. */
> + if (data->filter_enabled == new_type)
> + return 0;
> +
> + data->filter_enabled = new_type;
> + return mcp9600_config(data);
> +}
> +
> +static const struct iio_enum mcp9600_filter_enum = {
> + .items = mcp9600_filter_type,
> + .num_items = ARRAY_SIZE(mcp9600_filter_type),
> + .get = mcp9600_get_filter,
> + .set = mcp9600_set_filter,
> +};
> +
> +static const struct iio_chan_spec_ext_info mcp9600_ext_filter[] = {
> + IIO_ENUM("filter_type", IIO_SHARED_BY_ALL, &mcp9600_filter_enum),
> + IIO_ENUM_AVAILABLE("filter_type", IIO_SHARED_BY_ALL,
> + &mcp9600_filter_enum),
> + { }
> +};
> +
> static const struct iio_chan_spec mcp9600_channels[][2] = {
> MCP9600_CHANNELS(0, 0, 0, 0), /* Alerts: - - - - */
> MCP9600_CHANNELS(1, 0, 0, 0), /* Alerts: 1 - - - */
> @@ -216,6 +298,69 @@ static int mcp9600_read_raw(struct iio_dev *indio_dev,
> 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_enabled)
> + return IIO_VAL_EMPTY;
This brings us back to the earlier discussion of what should this
be when the filter is disabled. Mathematically, it would be infinite.
I wonder if it would be reasonable to return "inf" here since many
floating point parsers will already handle that as a valid value.
> +
> + *val = mcp_iir_coefficients_avail[data->filter_level][0];
> + *val2 = mcp_iir_coefficients_avail[data->filter_level][1];
> + return IIO_VAL_INT_PLUS_MICRO;
> + default:
> + return -EINVAL;
> + }
> +}
> +
Powered by blists - more mailing lists