* Re: [PATCH 0/3] iio: light: al3xxx: add missing REGMAP_I2C to Kconfig entries
From: Andy Shevchenko @ 2026-06-25 7:01 UTC (permalink / raw)
To: Joshua Crofts
Cc: Jonathan Cameron, David Lechner, Nuno Sá, Andy Shevchenko,
Svyatoslav Ryhel, David Heidelberg, linux-iio, linux-kernel
In-Reply-To: <20260625085329.00007959@gmail.com>
On Thu, Jun 25, 2026 at 08:53:29AM +0200, Joshua Crofts wrote:
> On Thu, 25 Jun 2026 09:41:31 +0300
> Andy Shevchenko <andriy.shevchenko@intel.com> wrote:
> > On Thu, Jun 25, 2026 at 07:20:42AM +0200, Joshua Crofts wrote:
> > > This series adds REGMAP_I2C support to three AL3xxx ambient light
> > > sensors that were previously missing this dependency, causing build
> > > failures.
> >
> > There are two problems with the commit message:
> > - SELECT versus select (see the comment against patch 1)
> > - you mentioned build failures but haven't provided any evidence, please
> > provide a reasonable lines of build output to prove that
> Sure, I could elaborate a bit more.
>
> Just run `make allnoconfig` and `make menuconfig` in which you select
> IIO, I2C and any AL3xxx sensor and `make .` will fail with errors such as
>
> drivers/iio/light/al3010.c: In function ‘al3010_probe’:
> drivers/iio/light/al3010.c:185:24: error: implicit declaration of function ‘devm_regmap_init_i2c’ [-Wimplicit-function-declaration]
> 185 | data->regmap = devm_regmap_init_i2c(client, &al3010_regmap_config);
> | ^~~~~~~~~~~~~~~~~~~~
> drivers/iio/light/al3010.c:185:22: error: assignment to ‘struct regmap *’ from ‘int’ makes pointer from integer without a cast [-Wint-conversion]
> 185 | data->regmap = devm_regmap_init_i2c(client, &al3010_regmap_config);
> | ^
> drivers/iio/light/al3010.c: At top level:
> drivers/iio/light/al3010.c:48:35: error: storage size of ‘al3010_regmap_config’ isn’t known
> 48 | static const struct regmap_config al3010_regmap_config = {
> | ^~~~~~~~~~~~~~~~~~~~
>
> Hopefully this is enough.
Yes, put it into the cover letter of the v2.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH v3 1/2] iio: imu: inv_icm42600: reorder includes for buffer module
From: Andy Shevchenko @ 2026-06-25 6:57 UTC (permalink / raw)
To: jean-baptiste.maneyrol
Cc: Jonathan Cameron, David Lechner, Nuno Sá, Andy Shevchenko,
linux-iio, linux-kernel
In-Reply-To: <ajzQ_FUr--jTxYWr@ashevche-desk.local>
On Thu, Jun 25, 2026 at 09:56:01AM +0300, Andy Shevchenko wrote:
> On Thu, Jun 25, 2026 at 09:49:47AM +0300, Andy Shevchenko wrote:
> > On Wed, Jun 24, 2026 at 06:21:18PM +0200, Jean-Baptiste Maneyrol via B4 Relay wrote:
> >
> > > Reorder includes following rules and delete unneeded kernel.h.
> >
> > Actually it's needed as 'proxy' header. If you want to get rid of it, it should
> > be another patch to replace that with the used headers following IWYU
> > principle.
> >
> > Suggested-by: Andy Shevchenko <andriy.shevchenko@intel.com>
>
> Also for the consistency's sake this should be done in all files in that
> folder. I see the same issue(s) in the _gyro and _accel and I assume the rest
> *.c and *.h also might be updated.
For the simplicity, just sort the each group of headers in all files. The IWYU
can be applied later on as it's not in the scope of your series.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH v3 1/2] iio: imu: inv_icm42600: reorder includes for buffer module
From: Andy Shevchenko @ 2026-06-25 6:55 UTC (permalink / raw)
To: jean-baptiste.maneyrol
Cc: Jonathan Cameron, David Lechner, Nuno Sá, Andy Shevchenko,
linux-iio, linux-kernel
In-Reply-To: <ajzPhi3ymeIBYHRr@ashevche-desk.local>
On Thu, Jun 25, 2026 at 09:49:47AM +0300, Andy Shevchenko wrote:
> On Wed, Jun 24, 2026 at 06:21:18PM +0200, Jean-Baptiste Maneyrol via B4 Relay wrote:
>
> > Reorder includes following rules and delete unneeded kernel.h.
>
> Actually it's needed as 'proxy' header. If you want to get rid of it, it should
> be another patch to replace that with the used headers following IWYU
> principle.
>
> Suggested-by: Andy Shevchenko <andriy.shevchenko@intel.com>
Also for the consistency's sake this should be done in all files in that
folder. I see the same issue(s) in the _gyro and _accel and I assume the rest
*.c and *.h also might be updated.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH v3 2/2] iio: imu: inv_icm42600: add buffer hwfifo watermark attributes
From: Andy Shevchenko @ 2026-06-25 6:54 UTC (permalink / raw)
To: jean-baptiste.maneyrol
Cc: Jonathan Cameron, David Lechner, Nuno Sá, Andy Shevchenko,
linux-iio, linux-kernel
In-Reply-To: <20260624-inv-icm42600-add-buffer-hwfifo_attributes-v3-2-5d9a4c662f50@tdk.com>
On Wed, Jun 24, 2026 at 06:21:19PM +0200, Jean-Baptiste Maneyrol via B4 Relay wrote:
> Add hwfifo_watermark/min/max/enabled buffer attributes.
> Hardware FIFO is always enabled and used.
These attributes are already documented and being used by a few drivers.
Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com>
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH 0/3] iio: light: al3xxx: add missing REGMAP_I2C to Kconfig entries
From: Joshua Crofts @ 2026-06-25 6:53 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Jonathan Cameron, David Lechner, Nuno Sá, Andy Shevchenko,
Svyatoslav Ryhel, David Heidelberg, linux-iio, linux-kernel
In-Reply-To: <ajzNmy3Vhh_Zl9Rs@ashevche-desk.local>
On Thu, 25 Jun 2026 09:41:31 +0300
Andy Shevchenko <andriy.shevchenko@intel.com> wrote:
> On Thu, Jun 25, 2026 at 07:20:42AM +0200, Joshua Crofts wrote:
> > This series adds REGMAP_I2C support to three AL3xxx ambient light
> > sensors that were previously missing this dependency, causing build
> > failures.
>
> There are two problems with the commit message:
> - SELECT versus select (see the comment against patch 1)
> - you mentioned build failures but haven't provided any evidence, please
> provide a reasonable lines of build output to prove that
>
Sure, I could elaborate a bit more.
Just run `make allnoconfig` and `make menuconfig` in which you select
IIO, I2C and any AL3xxx sensor and `make .` will fail with errors such as
drivers/iio/light/al3010.c: In function ‘al3010_probe’:
drivers/iio/light/al3010.c:185:24: error: implicit declaration of function ‘devm_regmap_init_i2c’ [-Wimplicit-function-declaration]
185 | data->regmap = devm_regmap_init_i2c(client, &al3010_regmap_config);
| ^~~~~~~~~~~~~~~~~~~~
drivers/iio/light/al3010.c:185:22: error: assignment to ‘struct regmap *’ from ‘int’ makes pointer from integer without a cast [-Wint-conversion]
185 | data->regmap = devm_regmap_init_i2c(client, &al3010_regmap_config);
| ^
drivers/iio/light/al3010.c: At top level:
drivers/iio/light/al3010.c:48:35: error: storage size of ‘al3010_regmap_config’ isn’t known
48 | static const struct regmap_config al3010_regmap_config = {
| ^~~~~~~~~~~~~~~~~~~~
Hopefully this is enough.
--
Kind regards
CJD
^ permalink raw reply
* Re: [PATCH v3 1/2] iio: imu: inv_icm42600: reorder includes for buffer module
From: Andy Shevchenko @ 2026-06-25 6:49 UTC (permalink / raw)
To: jean-baptiste.maneyrol
Cc: Jonathan Cameron, David Lechner, Nuno Sá, Andy Shevchenko,
linux-iio, linux-kernel
In-Reply-To: <20260624-inv-icm42600-add-buffer-hwfifo_attributes-v3-1-5d9a4c662f50@tdk.com>
On Wed, Jun 24, 2026 at 06:21:18PM +0200, Jean-Baptiste Maneyrol via B4 Relay wrote:
> Reorder includes following rules and delete unneeded kernel.h.
Actually it's needed as 'proxy' header. If you want to get rid of it, it should
be another patch to replace that with the used headers following IWYU
principle.
Suggested-by: Andy Shevchenko <andriy.shevchenko@intel.com>
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH v2] iio: adc: ti-ads124s08: Return reset GPIO lookup errors
From: Andy Shevchenko @ 2026-06-25 6:47 UTC (permalink / raw)
To: Pengpeng Hou
Cc: Jonathan Cameron, David Lechner, Nuno Sa, Andy Shevchenko,
Dan Murphy, linux-iio, linux-kernel, stable, Joshua Crofts
In-Reply-To: <20260625054407.82228-1-pengpeng@iscas.ac.cn>
On Thu, Jun 25, 2026 at 01:44:07PM +0800, Pengpeng Hou wrote:
> devm_gpiod_get_optional() returns NULL when the optional GPIO is absent,
> but returns an ERR_PTR when the GPIO provider lookup fails, including
> probe deferral.
>
> Probe currently logs the ERR_PTR case as if the reset GPIO were simply
> absent and keeps the error pointer in reset_gpio. Later ads124s_reset()
> treats any non-NULL reset_gpio as a valid descriptor and passes it to
> gpiod_set_value_cansleep().
The GPIOLIB code will print an error message each time that's called.
This might flood the logs with a noise.
> Return the lookup error instead of retaining the ERR_PTR.
Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com>
It's good as a fix for backport, but can you consider switching to use reset
framework and reset-gpio driver instead? (As a separate change on top of this
one.)
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH 1/3] iio: light: al3000a: add missing REGMAP_I2C to Kconfig
From: Joshua Crofts @ 2026-06-25 6:43 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Jonathan Cameron, David Lechner, Nuno Sá, Andy Shevchenko,
Svyatoslav Ryhel, David Heidelberg, linux-iio, linux-kernel
In-Reply-To: <ajzNMwT8Y640fnw_@ashevche-desk.local>
On Thu, 25 Jun 2026 09:39:47 +0300
Andy Shevchenko <andriy.shevchenko@intel.com> wrote:
> On Thu, Jun 25, 2026 at 07:20:43AM +0200, Joshua Crofts wrote:
> > The KConfig entry for the al3000a is missing a `SELECT REGMAP_I2C`,
>
> SELECT is not a SQL term here, but Kconfig, hence small letters only.
>
> > causing build failures.
>
Haha, good point. Will fix.
--
Kind regards
CJD
^ permalink raw reply
* Re: [PATCH v2] iio: temperature: Build mlx90635 with CONFIG_MLX90635
From: Andy Shevchenko @ 2026-06-25 6:43 UTC (permalink / raw)
To: Pengpeng Hou
Cc: Jonathan Cameron, David Lechner, Nuno Sa, Andy Shevchenko,
Crt Mori, linux-iio, linux-kernel, stable
In-Reply-To: <20260625054259.76774-1-pengpeng@iscas.ac.cn>
On Thu, Jun 25, 2026 at 01:42:59PM +0800, Pengpeng Hou wrote:
> drivers/iio/temperature/Kconfig has a dedicated MLX90635 option, but
> the Makefile currently builds mlx90635.o under CONFIG_MLX90632.
>
> This means enabling CONFIG_MLX90635 alone does not carry its provider
> object into the build, while enabling CONFIG_MLX90632 unexpectedly also
> builds mlx90635.o.
>
> Gate mlx90635.o on the matching generated Kconfig symbol.
Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com>
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH 0/3] iio: light: al3xxx: add missing REGMAP_I2C to Kconfig entries
From: Andy Shevchenko @ 2026-06-25 6:41 UTC (permalink / raw)
To: Joshua Crofts
Cc: Jonathan Cameron, David Lechner, Nuno Sá, Andy Shevchenko,
Svyatoslav Ryhel, David Heidelberg, linux-iio, linux-kernel
In-Reply-To: <20260625-fix-al3xxx-kconfig-v1-0-d41cbc0c3cf4@gmail.com>
On Thu, Jun 25, 2026 at 07:20:42AM +0200, Joshua Crofts wrote:
> This series adds REGMAP_I2C support to three AL3xxx ambient light
> sensors that were previously missing this dependency, causing build
> failures.
There are two problems with the commit message:
- SELECT versus select (see the comment against patch 1)
- you mentioned build failures but haven't provided any evidence, please
provide a reasonable lines of build output to prove that
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH 1/3] iio: light: al3000a: add missing REGMAP_I2C to Kconfig
From: Andy Shevchenko @ 2026-06-25 6:39 UTC (permalink / raw)
To: Joshua Crofts
Cc: Jonathan Cameron, David Lechner, Nuno Sá, Andy Shevchenko,
Svyatoslav Ryhel, David Heidelberg, linux-iio, linux-kernel
In-Reply-To: <20260625-fix-al3xxx-kconfig-v1-1-d41cbc0c3cf4@gmail.com>
On Thu, Jun 25, 2026 at 07:20:43AM +0200, Joshua Crofts wrote:
> The KConfig entry for the al3000a is missing a `SELECT REGMAP_I2C`,
SELECT is not a SQL term here, but Kconfig, hence small letters only.
> causing build failures.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH v5 1/3] dt-bindings: iio: health: add adi,max86150
From: Krzysztof Kozlowski @ 2026-06-25 6:33 UTC (permalink / raw)
To: Md Shofiqul Islam
Cc: linux-iio, jic23, lars, conor, conor+dt, robh, krzk+dt,
devicetree, linux-kernel
In-Reply-To: <20260623201124.18271-2-shofiqtest@gmail.com>
On Tue, Jun 23, 2026 at 11:11:21PM +0300, Md Shofiqul Islam wrote:
Do not attach (thread) your patchsets to some other threads (unrelated
or older versions). This buries them deep in the mailbox and might
interfere with applying entire sets. See also:
https://elixir.bootlin.com/linux/v6.16-rc2/source/Documentation/process/submitting-patches.rst#L830
> + reg:
> + maxItems: 1
> +
> + interrupts:
> + maxItems: 1
> + description: |
Do not need '|' unless you need to preserve formatting.
> + Active-low interrupt line. Asserted when the FIFO almost-full
> + threshold is reached or when a new PPG sample is ready.
> +
> + vdd-supply:
vdddig? Which supply is this?
> + description: Digital core power supply (1.8 V).
> +
> + avdd-supply:
I cannot find it in datasheet.
> + description: Analog core power supply (1.8 V).
> +
> + vref-supply:
> + description: ECG reference voltage supply.
> +
> + leds-supply:
Datasheet calls this VLED. Don't invent names.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 1/2] iio: dac: dac8163: Add driver for DAC8163
From: Andy Shevchenko @ 2026-06-25 6:18 UTC (permalink / raw)
To: Lukas
Cc: Jonathan Cameron, David Lechner, Nuno Sá, Andy Shevchenko,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, linux-kernel,
linux-iio, devicetree
In-Reply-To: <ajvt5J5Cs5cOdTLt@berta-MS-7693>
On Wed, Jun 24, 2026 at 04:47:00PM +0200, Lukas wrote:
> On Tue, Jun 23, 2026 at 10:39:23PM +0300, Andy Shevchenko wrote:
>
> > > + dev_dbg(dev, "%s: val=%d val2=%d\n", __func__, val, val2);
> >
> > No. Is it RFC? PoC? Or production-ready? If not the latter, come when it will
> > be production-ready.
>
> I will remove the debug print. I tried my best to make this driver production-ready.
> I saw that other drivers also have similar debug messages so i didnt
> remove it after my first tests and thought it is ok to leave it in
> there.
Debug messages are different. And in IIO we don't have them (perhaps some
historical leftovers or corner cases, dunno). If you have an example, share
the pointer, I will check that. Perhaps we can drop them in that driver.
(The debug prints like above are fine in the drivers in staging, but staging
is not really accepting much nowadays, so it's not the point.)
> My intention was to try to apply the suggestions and comments i
> get and send a second revision. Do you think thats the right way?
That's the way how it goes. You address all or almost all comments,
send a new version where in the comments you need to explain the
non-addressed pieces ("why?" they haven't been addressed).
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH v2 03/12] iio: adc: at91-sama5d2_adc: adapt the driver for sama7d65
From: Varshini.Rajendran @ 2026-06-25 5:53 UTC (permalink / raw)
To: andriy.shevchenko
Cc: ehristev, jic23, dlechner, nuno.sa, andy, robh, krzk+dt, conor+dt,
Nicolas.Ferre, alexandre.belloni, claudiu.beznea, srini,
linux-iio, devicetree, linux-arm-kernel, linux-kernel
In-Reply-To: <ajrO3-buCfS0vx1L@ashevche-desk.local>
Hi Andy,
On 23/06/26 11:52 pm, Andy Shevchenko wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
>
> On Tue, Jun 23, 2026 at 04:29:35PM +0530, Varshini Rajendran wrote:
>> Add support for sama7d65 ADC. The differences are highlighted with the
>> compatible. The calibration data layout is the main difference.
>
> Do you need to update a Kconfig help text?
Yes. I will update the supported SoC specifics in the Kconfig help text.
I will also address the rest of your review comments in the v3 patchset.
Thanks for your time.
>
> --
> With Best Regards,
> Andy Shevchenko
>
>
--
Thanks,
Varshini Rajendran.
^ permalink raw reply
* [PATCH v2] iio: adc: ti-ads124s08: Return reset GPIO lookup errors
From: Pengpeng Hou @ 2026-06-25 5:44 UTC (permalink / raw)
To: Jonathan Cameron, David Lechner, Nuno Sa, Andy Shevchenko
Cc: Pengpeng Hou, Dan Murphy, linux-iio, linux-kernel, stable,
Joshua Crofts
In-Reply-To: <20260624055325.32388-1-pengpeng@iscas.ac.cn>
devm_gpiod_get_optional() returns NULL when the optional GPIO is absent,
but returns an ERR_PTR when the GPIO provider lookup fails, including
probe deferral.
Probe currently logs the ERR_PTR case as if the reset GPIO were simply
absent and keeps the error pointer in reset_gpio. Later ads124s_reset()
treats any non-NULL reset_gpio as a valid descriptor and passes it to
gpiod_set_value_cansleep().
Return the lookup error instead of retaining the ERR_PTR.
Fixes: e717f8c6dfec ("iio: adc: Add the TI ads124s08 ADC code")
Cc: stable@vger.kernel.org
Reviewed-by: Joshua Crofts <joshua.crofts1@gmail.com>
Signed-off-by: Pengpeng Hou <pengpeng@iscas.ac.cn>
---
Changes in v2:
- Split from the v1 combined reset-failure patch.
- Keep only the GPIO ERR_PTR/probe-deferral fix.
- Add the Fixes tag requested by Andy.
- Carry Joshua's Reviewed-by, as allowed for a split version.
drivers/iio/adc/ti-ads124s08.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/iio/adc/ti-ads124s08.c b/drivers/iio/adc/ti-ads124s08.c
index 8ea1269f74db..73ad6ea9ef5d 100644
--- a/drivers/iio/adc/ti-ads124s08.c
+++ b/drivers/iio/adc/ti-ads124s08.c
@@ -321,7 +321,8 @@ static int ads124s_probe(struct spi_device *spi)
ads124s_priv->reset_gpio = devm_gpiod_get_optional(&spi->dev,
"reset", GPIOD_OUT_LOW);
if (IS_ERR(ads124s_priv->reset_gpio))
- dev_info(&spi->dev, "Reset GPIO not defined\n");
+ return dev_err_probe(&spi->dev, PTR_ERR(ads124s_priv->reset_gpio),
+ "Failed to get reset GPIO\n");
ads124s_priv->chip_info = &ads124s_chip_info_tbl[spi_id->driver_data];
--
2.50.1
^ permalink raw reply related
* [PATCH v2] iio: temperature: Build mlx90635 with CONFIG_MLX90635
From: Pengpeng Hou @ 2026-06-25 5:42 UTC (permalink / raw)
To: Jonathan Cameron, David Lechner, Nuno Sa, Andy Shevchenko
Cc: Crt Mori, Pengpeng Hou, linux-iio, linux-kernel, stable
In-Reply-To: <20260624081309.77805-1-pengpeng@iscas.ac.cn>
drivers/iio/temperature/Kconfig has a dedicated MLX90635 option, but
the Makefile currently builds mlx90635.o under CONFIG_MLX90632.
This means enabling CONFIG_MLX90635 alone does not carry its provider
object into the build, while enabling CONFIG_MLX90632 unexpectedly also
builds mlx90635.o.
Gate mlx90635.o on the matching generated Kconfig symbol.
Fixes: a1d1ba5e1c28 ("iio: temperature: mlx90635 MLX90635 IR Temperature sensor")
Cc: stable@vger.kernel.org
Signed-off-by: Pengpeng Hou <pengpeng@iscas.ac.cn>
---
Changes in v2:
- Add the Fixes tag after Andy asked whether one is needed.
- Add stable Cc because this is a released Kbuild symbol mismatch.
drivers/iio/temperature/Makefile | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/iio/temperature/Makefile b/drivers/iio/temperature/Makefile
index f046bb2f8a98..192b65965a27 100644
--- a/drivers/iio/temperature/Makefile
+++ b/drivers/iio/temperature/Makefile
@@ -13,7 +13,7 @@ obj-$(CONFIG_MAX31856) += maxim_thermocouple.o
obj-$(CONFIG_MAX31865) += max31865.o
obj-$(CONFIG_MCP9600) += mcp9600.o
obj-$(CONFIG_MLX90614) += mlx90614.o
obj-$(CONFIG_MLX90632) += mlx90632.o
-obj-$(CONFIG_MLX90632) += mlx90635.o
+obj-$(CONFIG_MLX90635) += mlx90635.o
obj-$(CONFIG_TMP006) += tmp006.o
obj-$(CONFIG_TMP007) += tmp007.o
obj-$(CONFIG_TMP117) += tmp117.o
--
2.50.1
^ permalink raw reply related
* [PATCH 3/3] iio: light: al3320a: add missing REGMAP_I2C to Kconfig
From: Joshua Crofts @ 2026-06-25 5:20 UTC (permalink / raw)
To: Jonathan Cameron, David Lechner, Nuno Sá, Andy Shevchenko,
Svyatoslav Ryhel, David Heidelberg
Cc: linux-iio, linux-kernel, Joshua Crofts, Jonathan Cameron
In-Reply-To: <20260625-fix-al3xxx-kconfig-v1-0-d41cbc0c3cf4@gmail.com>
The Kconfig entry for the al3320a is missing a `SELECT REGMAP_I2C`,
causing build failures.
Fixes: 1850e6ae7f91 ("iio: light: al3320a: Implement regmap support")
Signed-off-by: Joshua Crofts <joshua.crofts1@gmail.com>
---
drivers/iio/light/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/iio/light/Kconfig b/drivers/iio/light/Kconfig
index 4ba3151ebea7..f23bbce12c72 100644
--- a/drivers/iio/light/Kconfig
+++ b/drivers/iio/light/Kconfig
@@ -67,6 +67,7 @@ config AL3010
config AL3320A
tristate "AL3320A ambient light sensor"
+ select REGMAP_I2C
depends on I2C
help
Say Y here if you want to build a driver for the Dyna Image AL3320A
--
2.54.0
^ permalink raw reply related
* [PATCH 1/3] iio: light: al3000a: add missing REGMAP_I2C to Kconfig
From: Joshua Crofts @ 2026-06-25 5:20 UTC (permalink / raw)
To: Jonathan Cameron, David Lechner, Nuno Sá, Andy Shevchenko,
Svyatoslav Ryhel, David Heidelberg
Cc: linux-iio, linux-kernel, Joshua Crofts, Jonathan Cameron
In-Reply-To: <20260625-fix-al3xxx-kconfig-v1-0-d41cbc0c3cf4@gmail.com>
The KConfig entry for the al3000a is missing a `SELECT REGMAP_I2C`,
causing build failures.
Fixes: d531b9f78949 ("iio: light: Add support for AL3000a illuminance sensor")
Signed-off-by: Joshua Crofts <joshua.crofts1@gmail.com>
---
drivers/iio/light/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/iio/light/Kconfig b/drivers/iio/light/Kconfig
index ef36824f312f..a33920568904 100644
--- a/drivers/iio/light/Kconfig
+++ b/drivers/iio/light/Kconfig
@@ -45,6 +45,7 @@ config ADUX1020
config AL3000A
tristate "AL3000a ambient light sensor"
+ select REGMAP_I2C
depends on I2C
help
Say Y here if you want to build a driver for the Dyna Image AL3000a
--
2.54.0
^ permalink raw reply related
* [PATCH 2/3] iio: light: al3010: add missing REGMAP_I2C to Kconfig
From: Joshua Crofts @ 2026-06-25 5:20 UTC (permalink / raw)
To: Jonathan Cameron, David Lechner, Nuno Sá, Andy Shevchenko,
Svyatoslav Ryhel, David Heidelberg
Cc: linux-iio, linux-kernel, Joshua Crofts, Jonathan Cameron
In-Reply-To: <20260625-fix-al3xxx-kconfig-v1-0-d41cbc0c3cf4@gmail.com>
The KConfig entry for the AL3010 is missing a `SELECT REGMAP_I2C`,
causing build failures.
Fixes: 0e5e21e23dd6 ("iio: light: al3010: Implement regmap support")
Signed-off-by: Joshua Crofts <joshua.crofts1@gmail.com>
---
drivers/iio/light/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/iio/light/Kconfig b/drivers/iio/light/Kconfig
index a33920568904..4ba3151ebea7 100644
--- a/drivers/iio/light/Kconfig
+++ b/drivers/iio/light/Kconfig
@@ -56,6 +56,7 @@ config AL3000A
config AL3010
tristate "AL3010 ambient light sensor"
+ select REGMAP_I2C
depends on I2C
help
Say Y here if you want to build a driver for the Dyna Image AL3010
--
2.54.0
^ permalink raw reply related
* [PATCH 0/3] iio: light: al3xxx: add missing REGMAP_I2C to Kconfig entries
From: Joshua Crofts @ 2026-06-25 5:20 UTC (permalink / raw)
To: Jonathan Cameron, David Lechner, Nuno Sá, Andy Shevchenko,
Svyatoslav Ryhel, David Heidelberg
Cc: linux-iio, linux-kernel, Joshua Crofts, Jonathan Cameron
This series adds REGMAP_I2C support to three AL3xxx ambient light
sensors that were previously missing this dependency, causing build
failures.
I made a separate commit for each driver, to ensure a proper Fixes:
tag is appended for easy backporting. Let me know if you prefer
squashing!
Signed-off-by: Joshua Crofts <joshua.crofts1@gmail.com>
---
Joshua Crofts (3):
iio: light: al3000a: add missing REGMAP_I2C to Kconfig
iio: light: al3010: add missing REGMAP_I2C to Kconfig
iio: light: al3320a: add missing REGMAP_I2C to Kconfig
drivers/iio/light/Kconfig | 3 +++
1 file changed, 3 insertions(+)
---
base-commit: 7667a80340e99fd45357d0c90ae05813b01bbfef
change-id: 20260625-fix-al3xxx-kconfig-ddb1f00a2615
Best regards,
--
Kind regards
CJD
^ permalink raw reply
* Re: [RFC] Maintenance status of SPS30 driver and related Tomasz Duszynski entries
From: Matti Vaittinen @ 2026-06-25 5:11 UTC (permalink / raw)
To: Joshua Crofts, Maxwell Doose
Cc: Jonathan Cameron, Andy Shevchenko, open list, open list, tduszyns,
heikki.haikola, antti.sakkinen
In-Reply-To: <a2b1acbb-f8f2-4d6f-9681-986f42feddfa@gmail.com>
On 10/06/2026 12:46, Matti Vaittinen wrote:
> On 10/06/2026 11:36, Joshua Crofts wrote:
>> On Tue, 9 Jun 2026 10:21:59 -0500
>> Maxwell Doose <m32285159@gmail.com> wrote:
>>> Alrighty then. I'll probably take his chemical/ drivers since I've
>>> been spending some time in there. Regarding his light/ driver (ROHM
>>> BH1750 AMBIENT LIGHT SENSOR DRIVER) I can take it but I want to see if
>>> anyone else wants to first.
>>>
>>
>> I believe that there are a few ROHM folk in IIO, perhaps they would take
>> interest in maintaining the driver.
>>
>
> Thanks for pinging me. I need to see if we have any of the:BH1710,
> BH1715, BH1721, BH1750 or BH1751 here - and if we don't, then I need to
> ask from the HQ.
The HQ promised to provide me BH1721 and BH1751 so I am fine maintaining
(S:) this driver.
Yours,
-- Matti
--
Matti Vaittinen
Linux kernel developer at ROHM Semiconductors
Oulu Finland
~~ When things go utterly wrong vim users can always type :help! ~~
^ permalink raw reply
* Re: [PATCH v1] iio: temperature: hid-sensor-temperature: switch to non-devm iio_device_register()
From: Sanjay Chitroda @ 2026-06-25 1:52 UTC (permalink / raw)
To: Jonathan Cameron, srinivas pandruvada
Cc: Maxwell Doose, jikos, dlechner, nuno.sa, andy, hongyan.song,
linux-input, linux-iio, linux-kernel
In-Reply-To: <20260623200616.56a44b3e@jic23-huawei>
On 24 June 2026 12:36:16 am IST, Jonathan Cameron <jic23@kernel.org> wrote:
>On Mon, 22 Jun 2026 13:50:22 -0700
>srinivas pandruvada <srinivas.pandruvada@linux.intel.com> wrote:
>
>> On Mon, 2026-06-22 at 10:27 -0500, Maxwell Doose wrote:
>> > On Mon, Jun 22, 2026 at 10:26 AM srinivas pandruvada
>> > <srinivas.pandruvada@linux.intel.com> wrote:
>> > >
>> > > On Mon, 2026-06-22 at 10:51 +0530, Sanjay Chitroda wrote:
>> > > > From: Sanjay Chitroda <sanjayembeddedse@gmail.com>
>> > > >
>> > > > Avoid using devm_iio_device_register(), as this driver requires
>> > > > explicit
>> > > > error handling and teardown ordering.
>> > > >
>> > > > Mixing devm_* APIs with goto-based error unwinding breaks the
>> > > > expected
>> > > > LIFO resource release model and can introduce race windows during
>> > > > device
>> > > > removal. In particular, the IIO device may remain visible to
>> > > > userspace
>> > > > while dependent resources are already being freed, potentially
>> > > > leading
>> > > > to use-after-free issues.
>> > >
>> > > Please explain this use after free case here.
>> > >
>> > > Thanks,
>> > > Srinivas
>> >
>> > My guess is that because the device would still be registered but
>> > would actually be removed, sysfs still has "wild" pointers to
>> > read_raw() and write_raw() (which don't exist anymore), causing the
>> > UAF. If I'm wrong feel free to correct me though.
>>
>> iio_device_unregister() will be last one to be called after device
>> removal from devm action handler. This will cleanup attributes. So,
>> read_raw() or write_raw() can be called. The problem can be handlers
>> for read_raw() and write_raw() if anything there which are dependent on
>> clean done by hid_temperature_remove(). Here callbacks are cleaned up,
>> so nothing to respond to read sensor_hub_input_attr_get_raw_value(),
>> so it has to wait for 5 seconds to timeout, which is not great. So
>> nothing against change done here.
>>
>> But still not sure any use after free case, unless I am missing
>> something.
>>
>Agreed that to call UAF you need an explained path (and preferably
>testing that it happens). The timeout issue Srinivas calls out is
>sufficient for us to merge this as a fix, but the patch description
>should then talk about that.
>
Thank you all for the review.
I investigated the remove path in more detail. I agree that my original use-after-free explanation was not sufficiently justified.
The issue is actually the teardown ordering. With "devm_iio_device_register()", the IIO device remains registered until the devres cleanup phase, while "remove()" first removes the sensor hub callback. During this window, the IIO device is still visible to userspace and "read_raw()" requests may be issued. These requests eventually wait for a response from the sensor hub callback, but the callback has already been removed, resulting in the operation timing out.
I'll update the commit message in v2 to describe this observable behaviour instead of mentioning a potential use-after-free. The code change itself remains the same.
Thanks, Sanjay
>Thanks,
>
>Jonathan
>> Thanks,
>> Srinivas
>>
>>
>
^ permalink raw reply
* Re: [PATCH V14 0/9] Add Invensense ICM42607
From: Chris Morgan @ 2026-06-24 21:18 UTC (permalink / raw)
To: Chris Morgan
Cc: linux-iio, andy, nuno.sa, dlechner, jic23, jean-baptiste.maneyrol,
linux-rockchip, devicetree, heiko, conor+dt, krzk+dt, robh,
andriy.shevchenko
In-Reply-To: <20260624182350.50467-1-macroalpha82@gmail.com>
On Wed, Jun 24, 2026 at 01:23:39PM -0500, Chris Morgan wrote:
> From: Chris Morgan <macromorgan@hotmail.com>
>
> Add support for the ICM42607 IMU. This sensor shares the same
> functionality but a different register layout with the existing
> ICM42600.
>
> This driver should work with the ICM42607 and ICM42607P over both I2C
> and SPI, however only the ICM42607P over I2C could be tested.
>
> Changes Since V1:
> - Instead of creating a new driver, merged with the existing inv_icm42600
> driver. This necessitated adding some code to the existing driver to
> permit using a different register layout for the same functionality.
> - Split changes up a bit more to decrease the size of the individual
> patches. Note that patch 0004 is still pretty hefty; if I need to split
> further I may need to create some temporary stub functions.
> - Used guard() and PM_RUNTIME_ACQUIRE_AUTOSUSPEND() on the new functions
> per Jonathan's recommendations.
>
> Changes Since V2:
> - Went back to using a new driver on advice from Invensense engineer.
> - Further split changes up into smaller chunks of functionality. Note
> still that the largest patch is approximately 900 lines, and that while
> the driver compiles cleanly at each commit it is not able to drive the
> hardware until the commit that adds the Interrupt (as it also adds the
> Makefile).
> - Change the error to a warning when the devicetree binding does not match
> the hardware ID.
> - Dropped the ack on the devicetree bindings, as I am creating a new file
> (for a new driver) instead of modifying the existing one.
>
> Changes Since V3:
> - Numerous small fixes (too many to list here). Thank you to everyone who
> provided feedback.
> - Split power management additions into an additional commit to break
> things up further.
> - Consolidated devicetree documentation in existing
> invensense,icm42600.yaml file.
> - Removed most of the FIELD_PREP from header file to c files to make code
> easier to read.
> - Changed scale values to 2D arrays for Gyro and Accelerometer.
> - Removed IIO_CHAN_INFO_CALIBBIAS attribute.
>
> Changes Since V4:
> - Additional numerous small fixes, thank you again for all the feedback.
> - Dropped power control API and instead run device in low noise mode.
> - Split devicetree bindings into two distinct changes.
> - Reordered adding of enums and structs to main header file so that they
> are only brought in when needed.
> - Stopped using enum for driver data and instead am using pointer to
> device specific driver data.
>
> Changes Since V5:
> - Corrected use of "dev_warn_probe" to just "dev_warn".
> - Fixed some return scenarios which would unconditionally return 0
> when an error was present.
> - Corrected use of max() to min() for bounds checking. max() was
> incorrect.
> - Fixed using "st->conf.accel.odr" in the gyroscope function. It
> should have been "st->conf.gyro.odr" which it now is.
> - Additional small fixes suggested by "sashiko.dev".
> - Added a regmap cache. I used the datasheet to try and determine
> which registers might change without explicit writes.
>
> Changes Since V6:
> - Corrected additional errors identified by sashiko.dev, mostly
> fixing potential deadlocks, missing calls for pm runtime, and
> potential overflow issues.
>
> Changes Since V7:
> - Dropped Wake on Movement patches, since some of the functionality
> was only available for a device on which I cannot test.
> - Dropped support for SPI 3-Wire mode, since it complicated the
> bus setup (and I lack the hardware to test such features anyway).
> - Fixed a few additional bugs identified by sashiko.dev bot.
>
> Changes Since V8:
> - Added back IRQ dropped accidentally when dropping wake on movement
> patches.
> - Dropped "Reviewed-By" tag on patch 2 because of substantial changes
> made to devicetree binding documentation.
> - Additional small fixes as suggested.
>
> Changes Since V9:
> - Removed interrupts (and buffers) from the driver. I previously was
> unable to detect deadlocks because it turns out my IRQ was not even
> wired correctly in my device.
> - Updated devicetree binding commits to make interrupts optional for
> users of the icm42607 driver.
>
> Changes Since V10:
> - Explicitly specified enum values in header file.
> - Removed additional dead code for buffer handling.
> - Cleaned up headers.
> - Added additional locks as requested by sashiko.dev bot.
>
> Changes Since V11:
> - Since driver has shrunk in size considerably, moved i2c bits into
> first code commit. This ensures that the very first commit with code
> can now be compiled. The commit after that adds SPI support as it
> was in the previous versions.
> - Used pahole to optimize inv_icm42607_state. Reordering elements
> reduced size in memory from 384 bytes to 256 bytes.
> - Added a map of all readable registers and all writeable registers
> according to the datasheet.
> - Added back some missing headers pointed out by the maintainers.
> - Added FIELD_PREP in a few more places to make the code more
> obvious on what it's doing.
> - Added a comment to the power management code to note that
> temperature sensor being enabled doesn't matter as the clocks
> are off by default when the gyro and accel channels are off.
> - Removed iio_device_claim_direct() calls since it was no longer
> needed.
> - Fixed shared_by_all attributes for temperature sensor.
> - Additional miscellanous fixes as requested.
>
> Changes Since V12:
> - Removed aligned buffer from inv_icm42607_state struct as we do not
> currently have the need for it.
> - Corrected the order of the odr values in the accel and gyro files
> as the values were out of order (the place in the array corresponds
> to the register value).
> - Stopped setting the clock value depending upon the temp config. The
> datasheet advised to keep using the default value.
> - Corrected logic when changing between states. We only need to pause
> when a sensor changes from off to an on state or when the gyro
> changes from an on state to off.
> - Added missing includes for several files.
>
> Changes Since V13:
> - Refactored inv_icm42607_set_accel_conf() and
> inv_icm42607_set_gyro_conf() into a single function.
> - Refactored inv_icm42607_accel_read_sensor() and
> inv_icm42607_gyro_read_sensor() into a single function.
> - Merged inv_icm42607_set_temp_conf() into initial init function
> since it only really needs to be called once.
> - Saved adding temp sensor for last and updated
> inv_icm42607_temp_read() to either confirm other sensors are already
> enabled or enable the accelerometer so it can get a reading.
> - Updated inv_icm42607_set_pwr_mgmt0() so that it does not update the
> sensor mode and forcibly keep the sensor enabled.
> - Added inv_icm42607_temp_filter_bw enums since it appears to use
> different values than the accel or gyro sensor.
> - Set the temp startup time from 77ms to 77us, as I previously misread
> the datasheet.
> - Additional minor fixes.
>
> Chris Morgan (9):
> dt-bindings: iio: imu: icm42600: Add mount-matrix
> dt-bindings: iio: imu: icm42600: Add icm42607
> iio: imu: inv_icm42607: Add inv_icm42607 Core Driver
> iio: imu: inv_icm42607: Add SPI For icm42607
> iio: imu: inv_icm42607: Add PM support for icm42607
> iio: imu: inv_icm42607: Add Accelerometer for icm42607
> iio: imu: inv_icm42607: Add Gyroscope to icm42607
> iio: imu: inv_icm42607: Add Temp Support in icm42607
> arm64: dts: rockchip: Add icm42607p IMU for RG-DS
>
> .../bindings/iio/imu/invensense,icm42600.yaml | 20 +-
> .../dts/rockchip/rk3568-anbernic-rg-ds.dts | 8 +-
> drivers/iio/imu/Kconfig | 1 +
> drivers/iio/imu/Makefile | 1 +
> drivers/iio/imu/inv_icm42607/Kconfig | 30 +
> drivers/iio/imu/inv_icm42607/Makefile | 13 +
> drivers/iio/imu/inv_icm42607/inv_icm42607.h | 423 ++++++++++++
> .../iio/imu/inv_icm42607/inv_icm42607_accel.c | 317 +++++++++
> .../iio/imu/inv_icm42607/inv_icm42607_core.c | 606 ++++++++++++++++++
> .../iio/imu/inv_icm42607/inv_icm42607_gyro.c | 313 +++++++++
> .../iio/imu/inv_icm42607/inv_icm42607_i2c.c | 98 +++
> .../iio/imu/inv_icm42607/inv_icm42607_spi.c | 108 ++++
> .../iio/imu/inv_icm42607/inv_icm42607_temp.c | 99 +++
> .../iio/imu/inv_icm42607/inv_icm42607_temp.h | 37 ++
> 14 files changed, 2072 insertions(+), 2 deletions(-)
> create mode 100644 drivers/iio/imu/inv_icm42607/Kconfig
> create mode 100644 drivers/iio/imu/inv_icm42607/Makefile
> create mode 100644 drivers/iio/imu/inv_icm42607/inv_icm42607.h
> create mode 100644 drivers/iio/imu/inv_icm42607/inv_icm42607_accel.c
> create mode 100644 drivers/iio/imu/inv_icm42607/inv_icm42607_core.c
> create mode 100644 drivers/iio/imu/inv_icm42607/inv_icm42607_gyro.c
> create mode 100644 drivers/iio/imu/inv_icm42607/inv_icm42607_i2c.c
> create mode 100644 drivers/iio/imu/inv_icm42607/inv_icm42607_spi.c
> create mode 100644 drivers/iio/imu/inv_icm42607/inv_icm42607_temp.c
> create mode 100644 drivers/iio/imu/inv_icm42607/inv_icm42607_temp.h
>
> --
> 2.43.0
>
I got sashiko.dev's review, and agree with everything except 2 points.
1) It asks "Is it appropriate to omit the interrupts property based on
driver behavior rather than hardware wiring?" I would say no, but in
my case the hardware is not wired for an interrupt so it's moot.
2) It asks "Does this code update the software state cache for the
sensor mode?" No, it doesn't. The goal is for the device to stay
powered up for up to 2 seconds until runtime PM turns it off if it
isn't active, but I don't mind something turning around and shutting
the hardware down if it's not in use before then. Anything that needs
to read the specific sensor in question will be holding the mutex so
that there shouldn't be a risk of another thread turning stuff off
while I'm trying to use it, I don't think. What I want to avoid is
calling to turn the hardware on for a one-shot read and then
immediately turning it off once I'm done. I can wait the two seconds
for runtime PM to do it when the alternative is to call the shutdown
routine every single time for one-shot reads and wait for the startup
and in the case of the gyro shutdown times otherwise.
Thoughts?
I can fix the remaining issues it points out and resubmit.
Thank you,
Chris
^ permalink raw reply
* [PATCH V14 9/9] arm64: dts: rockchip: Add icm42607p IMU for RG-DS
From: Chris Morgan @ 2026-06-24 18:23 UTC (permalink / raw)
To: linux-iio
Cc: andy, nuno.sa, dlechner, jic23, jean-baptiste.maneyrol,
linux-rockchip, devicetree, heiko, conor+dt, krzk+dt, robh,
andriy.shevchenko, Chris Morgan
In-Reply-To: <20260624182350.50467-1-macroalpha82@gmail.com>
From: Chris Morgan <macromorgan@hotmail.com>
Add the Invensense ICM42607P IMU for the Anbernic RG-DS. Mount-matrix
was tested with iio-sensor-proxy and reports correct orientation.
Signed-off-by: Chris Morgan <macromorgan@hotmail.com>
---
arch/arm64/boot/dts/rockchip/rk3568-anbernic-rg-ds.dts | 8 +++++++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/rockchip/rk3568-anbernic-rg-ds.dts b/arch/arm64/boot/dts/rockchip/rk3568-anbernic-rg-ds.dts
index 8d906ab02c5f..b770bfd5268d 100644
--- a/arch/arm64/boot/dts/rockchip/rk3568-anbernic-rg-ds.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3568-anbernic-rg-ds.dts
@@ -871,7 +871,13 @@ aw87391_pa_r: audio-codec@5b {
sound-name-prefix = "Right Amp";
};
- /* invensense,icm42607p at 0x68 */
+ icm42607p: imu@68 {
+ compatible = "invensense,icm42607p";
+ reg = <0x68>;
+ mount-matrix = "-1", "0", "0",
+ "0", "1", "0",
+ "0", "0", "-1";
+ };
};
&i2c3 {
--
2.43.0
^ permalink raw reply related
* [PATCH V14 8/9] iio: imu: inv_icm42607: Add Temp Support in icm42607
From: Chris Morgan @ 2026-06-24 18:23 UTC (permalink / raw)
To: linux-iio
Cc: andy, nuno.sa, dlechner, jic23, jean-baptiste.maneyrol,
linux-rockchip, devicetree, heiko, conor+dt, krzk+dt, robh,
andriy.shevchenko, Chris Morgan
In-Reply-To: <20260624182350.50467-1-macroalpha82@gmail.com>
From: Chris Morgan <macromorgan@hotmail.com>
Add functions for reading temperature sensor data.
Signed-off-by: Chris Morgan <macromorgan@hotmail.com>
---
drivers/iio/imu/inv_icm42607/Makefile | 1 +
.../iio/imu/inv_icm42607/inv_icm42607_accel.c | 8 ++
.../iio/imu/inv_icm42607/inv_icm42607_gyro.c | 8 ++
.../iio/imu/inv_icm42607/inv_icm42607_temp.c | 99 +++++++++++++++++++
.../iio/imu/inv_icm42607/inv_icm42607_temp.h | 37 +++++++
5 files changed, 153 insertions(+)
create mode 100644 drivers/iio/imu/inv_icm42607/inv_icm42607_temp.c
create mode 100644 drivers/iio/imu/inv_icm42607/inv_icm42607_temp.h
diff --git a/drivers/iio/imu/inv_icm42607/Makefile b/drivers/iio/imu/inv_icm42607/Makefile
index 8e73385c8f4b..7b907e019601 100644
--- a/drivers/iio/imu/inv_icm42607/Makefile
+++ b/drivers/iio/imu/inv_icm42607/Makefile
@@ -4,6 +4,7 @@ obj-$(CONFIG_INV_ICM42607) += inv-icm42607.o
inv-icm42607-y += inv_icm42607_core.o
inv-icm42607-y += inv_icm42607_gyro.o
inv-icm42607-y += inv_icm42607_accel.o
+inv-icm42607-y += inv_icm42607_temp.o
obj-$(CONFIG_INV_ICM42607_I2C) += inv-icm42607-i2c.o
inv-icm42607-i2c-y += inv_icm42607_i2c.o
diff --git a/drivers/iio/imu/inv_icm42607/inv_icm42607_accel.c b/drivers/iio/imu/inv_icm42607/inv_icm42607_accel.c
index 8ef9fdae1bc8..5ff6756b9515 100644
--- a/drivers/iio/imu/inv_icm42607/inv_icm42607_accel.c
+++ b/drivers/iio/imu/inv_icm42607/inv_icm42607_accel.c
@@ -15,6 +15,7 @@
#include <linux/types.h>
#include "inv_icm42607.h"
+#include "inv_icm42607_temp.h"
#define INV_ICM42607_ACCEL_CHAN(_modifier, _index, _ext_info) \
{ \
@@ -40,6 +41,7 @@ enum inv_icm42607_accel_scan {
INV_ICM42607_ACCEL_SCAN_X,
INV_ICM42607_ACCEL_SCAN_Y,
INV_ICM42607_ACCEL_SCAN_Z,
+ INV_ICM42607_ACCEL_SCAN_TEMP,
};
static const struct iio_chan_spec_ext_info inv_icm42607_accel_ext_infos[] = {
@@ -54,6 +56,7 @@ static const struct iio_chan_spec inv_icm42607_accel_channels[] = {
inv_icm42607_accel_ext_infos),
INV_ICM42607_ACCEL_CHAN(IIO_MOD_Z, INV_ICM42607_ACCEL_SCAN_Z,
inv_icm42607_accel_ext_infos),
+ INV_ICM42607_TEMP_CHAN(INV_ICM42607_ACCEL_SCAN_TEMP),
};
static const int inv_icm42607_accel_scale_nano[][2] = {
@@ -186,6 +189,11 @@ static int inv_icm42607_accel_read_raw(struct iio_dev *indio_dev,
switch (chan->type) {
case IIO_ACCEL:
break;
+ case IIO_TEMP:
+ if (mask != IIO_CHAN_INFO_SAMP_FREQ)
+ return inv_icm42607_temp_read_raw(indio_dev, chan,
+ val, val2, mask);
+ break;
default:
return -EINVAL;
}
diff --git a/drivers/iio/imu/inv_icm42607/inv_icm42607_gyro.c b/drivers/iio/imu/inv_icm42607/inv_icm42607_gyro.c
index c7215b3826ad..4e5db5e19e9f 100644
--- a/drivers/iio/imu/inv_icm42607/inv_icm42607_gyro.c
+++ b/drivers/iio/imu/inv_icm42607/inv_icm42607_gyro.c
@@ -15,6 +15,7 @@
#include <linux/types.h>
#include "inv_icm42607.h"
+#include "inv_icm42607_temp.h"
#define INV_ICM42607_GYRO_CHAN(_modifier, _index, _ext_info) \
{ \
@@ -40,6 +41,7 @@ enum inv_icm42607_gyro_scan {
INV_ICM42607_GYRO_SCAN_X,
INV_ICM42607_GYRO_SCAN_Y,
INV_ICM42607_GYRO_SCAN_Z,
+ INV_ICM42607_GYRO_SCAN_TEMP,
};
static const struct iio_chan_spec_ext_info inv_icm42607_gyro_ext_infos[] = {
@@ -54,6 +56,7 @@ static const struct iio_chan_spec inv_icm42607_gyro_channels[] = {
inv_icm42607_gyro_ext_infos),
INV_ICM42607_GYRO_CHAN(IIO_MOD_Z, INV_ICM42607_GYRO_SCAN_Z,
inv_icm42607_gyro_ext_infos),
+ INV_ICM42607_TEMP_CHAN(INV_ICM42607_GYRO_SCAN_TEMP),
};
static const int inv_icm42607_gyro_scale_nano[][2] = {
@@ -182,6 +185,11 @@ static int inv_icm42607_gyro_read_raw(struct iio_dev *indio_dev,
switch (chan->type) {
case IIO_ANGL_VEL:
break;
+ case IIO_TEMP:
+ if (mask != IIO_CHAN_INFO_SAMP_FREQ)
+ return inv_icm42607_temp_read_raw(indio_dev, chan,
+ val, val2, mask);
+ break;
default:
return -EINVAL;
}
diff --git a/drivers/iio/imu/inv_icm42607/inv_icm42607_temp.c b/drivers/iio/imu/inv_icm42607/inv_icm42607_temp.c
new file mode 100644
index 000000000000..f7e286ecb5cd
--- /dev/null
+++ b/drivers/iio/imu/inv_icm42607/inv_icm42607_temp.c
@@ -0,0 +1,99 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * Copyright (C) 2026 InvenSense, Inc.
+ */
+
+#include <linux/cleanup.h>
+#include <linux/device.h>
+#include <linux/err.h>
+#include <linux/iio/iio.h>
+#include <linux/mutex.h>
+#include <linux/pm_runtime.h>
+#include <linux/regmap.h>
+#include <linux/types.h>
+#include <linux/unaligned.h>
+
+#include "inv_icm42607.h"
+#include "inv_icm42607_temp.h"
+
+static int inv_icm42607_temp_read(struct inv_icm42607_state *st, s16 *temp)
+{
+ struct inv_icm42607_sensor_conf conf = INV_ICM42607_SENSOR_CONF_INIT;
+ struct device *dev = regmap_get_device(st->map);
+ int ret, gyro_mode, accel_mode;
+ unsigned int val;
+ u8 raw[2];
+
+ PM_RUNTIME_ACQUIRE_AUTOSUSPEND(dev, pm);
+ ret = PM_RUNTIME_ACQUIRE_ERR(&pm);
+ if (ret)
+ return ret;
+
+ guard(mutex)(&st->lock);
+
+ /*
+ * Check if both the gyro and accel are off and if so, enable one
+ * of them. The temp sensor cannot be read if both the gyro and
+ * accel sensor are off. Prefer to enable the accel over the gyro
+ * as the datasheet says the gyro uses 5x more power and it has
+ * a minimum run time of 45ms.
+ */
+ ret = regmap_read(st->map, INV_ICM42607_REG_PWR_MGMT0, &val);
+ if (ret)
+ return ret;
+
+ accel_mode = FIELD_GET(INV_ICM42607_PWR_MGMT0_ACCEL_MODE_MASK, val);
+ gyro_mode = FIELD_GET(INV_ICM42607_PWR_MGMT0_GYRO_MODE_MASK, val);
+ if (!gyro_mode && !accel_mode) {
+ /* enable accel sensor */
+ conf.mode = INV_ICM42607_SENSOR_MODE_LOW_NOISE;
+// ret = inv_icm42607_set_accel_conf(st, &conf);
+ ret = inv_icm42607_set_sensor_conf(st, &conf, IIO_ACCEL);
+ if (ret)
+ return ret;
+ }
+
+ ret = regmap_bulk_read(st->map, INV_ICM42607_REG_TEMP_DATA1,
+ raw, sizeof(raw));
+ if (ret)
+ return ret;
+
+ *temp = get_unaligned_be16(raw);
+ if (*temp == INV_ICM42607_DATA_INVALID)
+ return -EINVAL;
+
+ return 0;
+}
+
+int inv_icm42607_temp_read_raw(struct iio_dev *indio_dev,
+ struct iio_chan_spec const *chan,
+ int *val, int *val2, long mask)
+{
+ struct inv_icm42607_state *st = iio_device_get_drvdata(indio_dev);
+ s16 temp;
+ int ret;
+
+ switch (mask) {
+ case IIO_CHAN_INFO_RAW:
+ ret = inv_icm42607_temp_read(st, &temp);
+ if (ret)
+ return ret;
+ *val = temp;
+ return IIO_VAL_INT;
+ /*
+ * T°C = (temp / 128) + 25
+ * Tm°C = 1000 * ((temp * 100 / 12800) + 25)
+ * scale: 100000 / 12800 ~= 7.8125
+ * offset: 3200
+ */
+ case IIO_CHAN_INFO_SCALE:
+ *val = 7;
+ *val2 = 812500000;
+ return IIO_VAL_INT_PLUS_NANO;
+ case IIO_CHAN_INFO_OFFSET:
+ *val = 3200;
+ return IIO_VAL_INT;
+ default:
+ return -EINVAL;
+ }
+}
diff --git a/drivers/iio/imu/inv_icm42607/inv_icm42607_temp.h b/drivers/iio/imu/inv_icm42607/inv_icm42607_temp.h
new file mode 100644
index 000000000000..cb7b460ffb44
--- /dev/null
+++ b/drivers/iio/imu/inv_icm42607/inv_icm42607_temp.h
@@ -0,0 +1,37 @@
+/* SPDX-License-Identifier: GPL-2.0-or-later */
+/*
+ * Copyright (C) 2026 InvenSense, Inc.
+ */
+
+#ifndef INV_ICM42607_TEMP_H_
+#define INV_ICM42607_TEMP_H_
+
+#include <linux/bitops.h>
+
+struct iio_dev;
+struct iio_chan_spec;
+
+#define INV_ICM42607_TEMP_CHAN(_index) \
+{ \
+ .type = IIO_TEMP, \
+ .info_mask_separate = \
+ BIT(IIO_CHAN_INFO_RAW) | \
+ BIT(IIO_CHAN_INFO_OFFSET) | \
+ BIT(IIO_CHAN_INFO_SCALE), \
+ .info_mask_shared_by_all = \
+ BIT(IIO_CHAN_INFO_SAMP_FREQ), \
+ .info_mask_shared_by_all_available = \
+ BIT(IIO_CHAN_INFO_SAMP_FREQ), \
+ .scan_index = _index, \
+ .scan_type = { \
+ .sign = 's', \
+ .realbits = 16, \
+ .storagebits = 16, \
+ }, \
+}
+
+int inv_icm42607_temp_read_raw(struct iio_dev *indio_dev,
+ struct iio_chan_spec const *chan,
+ int *val, int *val2, long mask);
+
+#endif
--
2.43.0
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox