* [PATCH v2 2/3] hwmon: ina2xx: support ina232
From: Loic Poulain @ 2026-06-11 14:05 UTC (permalink / raw)
To: Guenter Roeck, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Bjorn Andersson, Konrad Dybcio
Cc: Krzysztof Kozlowski, linux-hwmon, devicetree, linux-kernel,
linux-arm-msm, Loic Poulain, Martino Facchin
In-Reply-To: <20260611-monza-ina232-v2-0-e4375ce652d0@oss.qualcomm.com>
From: Martino Facchin <m.facchin@arduino.cc>
The INA232 is a current/power monitor. It shares the same register
layout as the INA2xx and uses the INA226 default configuration, but
differs in its electrical characteristics:
Signed-off-by: Martino Facchin <m.facchin@arduino.cc>
Signed-off-by: Loic Poulain <loic.poulain@oss.qualcomm.com>
---
drivers/hwmon/ina2xx.c | 20 ++++++++++++++++++++
1 file changed, 20 insertions(+)
diff --git a/drivers/hwmon/ina2xx.c b/drivers/hwmon/ina2xx.c
index 613ffb622b7c42b8b6090d3b4ec7b2fa412e24a4..fc2319ad99fc398a50e97ee617f67255bd0b3038 100644
--- a/drivers/hwmon/ina2xx.c
+++ b/drivers/hwmon/ina2xx.c
@@ -122,6 +122,7 @@ static const struct regmap_config ina2xx_regmap_config = {
enum ina2xx_ids {
ina219,
ina226,
+ ina232,
ina234,
ina260,
sy24655
@@ -196,6 +197,20 @@ static const struct ina2xx_config ina2xx_config[] = {
.current_shift = 4,
.has_update_interval = true,
},
+ [ina232] = {
+ .config_default = INA226_CONFIG_DEFAULT,
+ .calibration_value = 2048,
+ .shunt_div = 400,
+ .shunt_voltage_shift = 0,
+ .bus_voltage_shift = 0,
+ .bus_voltage_lsb = 1600,
+ .power_lsb_factor = 32,
+ .has_alerts = true,
+ .has_ishunt = false,
+ .has_power_average = false,
+ .current_shift = 0,
+ .has_update_interval = true,
+ },
[ina260] = {
.config_default = INA260_CONFIG_DEFAULT,
.shunt_div = 400,
@@ -1005,6 +1020,7 @@ static const struct i2c_device_id ina2xx_id[] = {
{ "ina226", ina226 },
{ "ina230", ina226 },
{ "ina231", ina226 },
+ { "ina232", ina232 },
{ "ina234", ina234 },
{ "ina260", ina260 },
{ "sy24655", sy24655 },
@@ -1037,6 +1053,10 @@ static const struct of_device_id __maybe_unused ina2xx_of_match[] = {
.compatible = "ti,ina231",
.data = (void *)ina226
},
+ {
+ .compatible = "ti,ina232",
+ .data = (void *)ina232
+ },
{
.compatible = "ti,ina234",
.data = (void *)ina234
--
2.34.1
^ permalink raw reply related
* [PATCH v2 1/3] dt-bindings: hwmon: ina2xx: add ina232 compatible
From: Loic Poulain @ 2026-06-11 14:05 UTC (permalink / raw)
To: Guenter Roeck, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Bjorn Andersson, Konrad Dybcio
Cc: Krzysztof Kozlowski, linux-hwmon, devicetree, linux-kernel,
linux-arm-msm, Loic Poulain, Martino Facchin
In-Reply-To: <20260611-monza-ina232-v2-0-e4375ce652d0@oss.qualcomm.com>
From: Martino Facchin <m.facchin@arduino.cc>
The INA232 is a current/power monitor from Texas Instruments sharing
the same register map as the other INA2xx.
Signed-off-by: Martino Facchin <m.facchin@arduino.cc>
Signed-off-by: Loic Poulain <loic.poulain@oss.qualcomm.com>
---
Documentation/devicetree/bindings/hwmon/ti,ina2xx.yaml | 3 +++
1 file changed, 3 insertions(+)
diff --git a/Documentation/devicetree/bindings/hwmon/ti,ina2xx.yaml b/Documentation/devicetree/bindings/hwmon/ti,ina2xx.yaml
index 009d78b308596ca795bebdd160431bd718b127e0..a79ade3142fa4f36f2ae4655bbf0db8ad84ec13a 100644
--- a/Documentation/devicetree/bindings/hwmon/ti,ina2xx.yaml
+++ b/Documentation/devicetree/bindings/hwmon/ti,ina2xx.yaml
@@ -28,6 +28,7 @@ properties:
- ti,ina228
- ti,ina230
- ti,ina231
+ - ti,ina232
- ti,ina233
- ti,ina234
- ti,ina237
@@ -114,6 +115,7 @@ allOf:
- ti,ina228
- ti,ina230
- ti,ina231
+ - ti,ina232
- ti,ina234
- ti,ina237
- ti,ina238
@@ -136,6 +138,7 @@ allOf:
- ti,ina226
- ti,ina230
- ti,ina231
+ - ti,ina232
- ti,ina234
- ti,ina260
- ti,ina700
--
2.34.1
^ permalink raw reply related
* [PATCH v2 0/3] Add INA232 power monitor support for Arduino VENTUNO Q
From: Loic Poulain @ 2026-06-11 14:05 UTC (permalink / raw)
To: Guenter Roeck, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Bjorn Andersson, Konrad Dybcio
Cc: Krzysztof Kozlowski, linux-hwmon, devicetree, linux-kernel,
linux-arm-msm, Loic Poulain, Martino Facchin
Add support for the TI INA232 current/power monitor to the ina2xx
hwmon driver, and enable it on the Arduino Monza board.
The INA232 is a bidirectional current/power monitor that shares the
same I2C register layout as the INA226, but has different electrical
characteristics.
On the Arduino Monza/Ventuno-Q board, the INA232 is connected on
I2C12 at address 0x40 with a 2 mΩ shunt resistor, and is used to
monitor the board supply current.
Signed-off-by: Loic Poulain <loic.poulain@oss.qualcomm.com>
---
Changes in v2:
- has_update_interval was missing and should be set to true/supported
(sashiko/Guenter)
- ti,ina232 added to two allOf conditional exclusion blocks. (sashiko)
- Fix commit message, it incorrectly mentioned 2Mohm instead of
milli-ohm. (sahiko, Konrad).
- Link to v1: https://lore.kernel.org/r/20260610-monza-ina232-v1-0-925b0d12771b@oss.qualcomm.com
---
Loic Poulain (1):
arm64: dts: qcom: monaco-arduino-monza: add ina232 power sensor
Martino Facchin (2):
dt-bindings: hwmon: ina2xx: add ina232 compatible
hwmon: ina2xx: support ina232
.../devicetree/bindings/hwmon/ti,ina2xx.yaml | 3 +++
arch/arm64/boot/dts/qcom/monaco-arduino-monza.dts | 6 ++++++
drivers/hwmon/ina2xx.c | 20 ++++++++++++++++++++
3 files changed, 29 insertions(+)
---
base-commit: 8a4062d204752e0d66a1e7e1a2f8834571a8d40f
change-id: 20260610-monza-ina232-de180e669dc1
Best regards,
--
Loic Poulain <loic.poulain@oss.qualcomm.com>
^ permalink raw reply
* Re: [PATCH v4 2/4] dt-bindings: iio: flow: add Sensirion SLF3S liquid flow sensor
From: Krzysztof Kozlowski @ 2026-06-11 14:01 UTC (permalink / raw)
To: Wadim Mueller, Jonathan Cameron, Krzysztof Kozlowski, Rob Herring,
Conor Dooley, David Lechner, Nuno Sá, Andy Shevchenko,
Maxwell Doose
Cc: linux-iio, devicetree, linux-kernel, Marcelo Schmitt,
Rodrigo Alencar
In-Reply-To: <20260611132700.671322-3-wafgo01@gmail.com>
On 11/06/2026 15:26, Wadim Mueller wrote:
> Document the bindings for the Sensirion SLF3S family of digital
> liquid-flow sensors on I2C. The family currently covers the
> SLF3S-0600F, SLF3S-1300F and SLF3S-4000B variants.
>
> All variants share the same register map and are fully detectable
> from the product-information register at probe time, so
> sensirion,slf3s-1300f serves as the fallback compatible for the
> other variants.
>
> The active calibration medium (water / IPA) is runtime-switchable
> via the in_volumeflow_medium sysfs attribute and therefore not a
> DT property.
>
> Signed-off-by: Wadim Mueller <wafgo01@gmail.com>
> ---
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v4 4/4] iio: flow: add Sensirion SLF3S liquid flow sensor driver
From: Krzysztof Kozlowski @ 2026-06-11 14:01 UTC (permalink / raw)
To: Wadim Mueller, Jonathan Cameron, Krzysztof Kozlowski, Rob Herring,
Conor Dooley, David Lechner, Nuno Sá, Andy Shevchenko,
Maxwell Doose
Cc: linux-iio, devicetree, linux-kernel, Marcelo Schmitt,
Rodrigo Alencar
In-Reply-To: <20260611132700.671322-5-wafgo01@gmail.com>
On 11/06/2026 15:27, Wadim Mueller wrote:
> +
> +static const struct of_device_id slf3s_of_match[] = {
> + { .compatible = "sensirion,slf3s-0600f", .data = &slf3s_variants[0] },
> + { .compatible = "sensirion,slf3s-1300f", .data = &slf3s_variants[1] },
> + { .compatible = "sensirion,slf3s-4000b", .data = &slf3s_variants[2] },
You should have only 1300f here and detect the variants. That was my
point when I suggested to use the fallback.
Best regards,
Krzysztof
^ permalink raw reply
* Re: (subset) [PATCH v2 0/3] pinctrl: sunxi: a523: fix GPIO IRQ operation
From: Chen-Yu Tsai @ 2026-06-11 13:56 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Jernej Skrabec,
Samuel Holland, Andre Przywara
Cc: linux-gpio, devicetree, linux-arm-kernel, linux-sunxi,
linux-kernel
In-Reply-To: <20260327113006.3135663-1-andre.przywara@arm.com>
On Fri, 27 Mar 2026 11:30:03 +0000, Andre Przywara wrote:
> this is the minimal fix version for the GPIO IRQ operation on the
> Allwinner A523/A527/T527 SoCs. SD card detection is broken as a result,
> which is a major annoyance. Those patches here fix that problem, and
> should go into v7.0 still, if possible.
> I dropped the more involved fixes from v1, the risk for regressions is
> now very low:
> - The quirk flag is just dropped from the A523, not the other SoCs. I
> confirmed this again with an experiment, for both the primary and
> secondary pincontroller. This avoids fixing the workaround code for
> now, which is more involved, but for now unneeded.
> - The DT patch just adds the missing interrupt. The IRQ association was
> always wrong and never worked, so this can't make it possibly worse.
> Together those two patches (plus the required binding change) fix the
> problem, I would appreciate if this could be taken ASAP, into v7.0 still.
> The generic pinctrl code is now untouched, which makes this also much
> easier to backport, and drops the dependencies on other v7.0-rc fixes.
>
> [...]
Applied to sunxi/dt-for-7.2 in sunxi, thanks!
[3/3] arm64: dts: allwinner: a523: Add missing GPIO interrupt
https://git.kernel.org/sunxi/linux/c/6b81aa0c8a4f
Best regards,
--
Chen-Yu Tsai <wens@kernel.org>
^ permalink raw reply
* Re: [PATCH 2/4] dt-bindings: arm: qcom: Add Lenovo Yoga Slim 7x Gen11
From: Krzysztof Kozlowski @ 2026-06-11 13:48 UTC (permalink / raw)
To: Abel Vesa, Konrad Dybcio
Cc: rob.clark, Neil Armstrong, Jessica Zhang, David Airlie,
Simona Vetter, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Douglas Anderson, Bjorn Andersson, Konrad Dybcio, dri-devel,
devicetree, linux-kernel, linux-arm-msm
In-Reply-To: <uieb6ukjokwnppc5zfr6bjychqsnpikwmiy7j7dmt2kgk7k4zi@2stv37ijv36o>
On 10/06/2026 15:31, Abel Vesa wrote:
>>>>>> @@ -68,6 +68,7 @@ properties:
>>>>>>
>>>>>> - items:
>>>>>> - enum:
>>>>>> + - lenovo,yoga-slim7x-gen11
>>>>>
>>>>> I imagine you might want different panel variants, just like T14s has
>>>>> LCD and OLED?
>>>>
>>>> I expect this will be the case.
>>>
>>> Then better to prepare for this now, otherwise later you need to change
>>> bindings. If unsure what other variants are, then at least make this
>>> compatible panel-specific, e.g. lenovo,yoga-slim7x-gen11-oled-foo-bar.
>>
>> I took another look at psref [1] and there's only OLED SKUs (today?).
>> There are however, two different resolutions available and both can be
>> touch/notouch.
>
> If the other SKU doesn't have touch, then you might as well mark now this
> one with touch suffix or something like that.
If you decide not to have any changes (new compatibles), then at least
please document the above reasoning in commit msg.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v2 1/4] dt-bindings: remoteproc: imx_rproc: document optional "memory-region-names"
From: Krzysztof Kozlowski @ 2026-06-11 13:47 UTC (permalink / raw)
To: Frank Li
Cc: Mathieu Poirier, Laurentiu Mihalcea, Bjorn Andersson, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Sascha Hauer, Peng Fan,
Fabio Estevam, Daniel Baluta, Francesco Dolcini, linux-remoteproc,
devicetree, imx, linux-arm-kernel, linux-kernel
In-Reply-To: <ail0sH1UhnQBPRkr@SMW015318>
On 10/06/2026 16:29, Frank Li wrote:
> For example:
>
> rsc_table: rsc-table@90000000
> { ret = <0x90000000>;
> no-map;
> }
>
> m4 {
> ...
> memory-region = <&rsc_table>;
> }
>
> If you change node name "rsc-table" to "memory", driver will failure
> because it parse node name "rsc-table", which phandle point to. but no
> binding to restrict node name to "rsc-table". So rsc-table became hidden
> ABI.
Then you need to fix the driver to not parse the node names. Node names
are not supposed to be ABI.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 2/2] MAINTAINERS: Add myself as maintainer for PMS7003
From: Tomasz Duszyński @ 2026-06-11 13:41 UTC (permalink / raw)
To: Maxwell Doose
Cc: Andy Shevchenko, Krzysztof Kozlowski, Jonathan Cameron,
David Lechner, Nuno Sá, Andy Shevchenko, Rob Herring,
Krzysztof Kozlowski, Conor Dooley,
open list:IIO SUBSYSTEM AND DRIVERS,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
open list
In-Reply-To: <CAKqfh0FQb6tSZrrTHGWcoQqPe-OwD-mW02GOOn9y+ysstRPVzA@mail.gmail.com>
Hi,
I've been trying to catch up on the recent discussion. A few things I
want to address:
1. My email is active and I do read patches (when CCd), but by the
time I have a proper slot to sit down and review something, it's
usually already gone through several rounds.
Chiming in at that point just for the sake of it doesn't add much value imo.
2. I get the impression you're thinking that since I'm not actively
maintaining these drivers, you can step in and take ownership. I'm
broadly fine with that, but I'd want to see more work and patches
coming from you first. If that happens, we can revisit the ownership
question. That said, do you actually have these sensors on hand to
test more invasive changes? If you've already answered that just skip
it as I'll probably stumble upon it whilst going through overdue
mails.
3. I've managed to carve out some extra time lately, so I'm happy to
be more involved with reviews going forward if that's useful.
In the meantime I'll go through the remaining emails to get better context.
On Thu, Jun 11, 2026 at 2:23 PM Maxwell Doose <m32285159@gmail.com> wrote:
>
> On Thu, Jun 11, 2026 at 2:12 AM Andy Shevchenko
> <andriy.shevchenko@intel.com> wrote:
> >
> > On Thu, Jun 11, 2026 at 10:09:57AM +0300, Andy Shevchenko wrote:
> > > On Thu, Jun 11, 2026 at 08:58:47AM +0200, Krzysztof Kozlowski wrote:
> > > > On 11/06/2026 08:50, Andy Shevchenko wrote:
> > > > > On Thu, Jun 11, 2026 at 08:37:33AM +0200, Krzysztof Kozlowski wrote:
> > > > >> On 11/06/2026 00:24, Maxwell Doose wrote:
> > > > >>> On Wed, Jun 10, 2026 at 4:09 AM Krzysztof Kozlowski <krzk@kernel.org> wrote:
> > > > >>>> On Tue, Jun 09, 2026 at 11:03:26AM -0500, Maxwell Doose wrote:
> > > > >>>>> Tomasz's entry is no longer valid, as he is not active anymore. Add
> > > > >>>>
> > > > >>>> Why is not longer valid? I see activity in Feb...
> > > > >>>
> > > > >>> Strange. According to git log --author="Tomasz Duszynski" last commit
> > > > >>> I have from him is 2023. We also did have an RFC open for a month on
> > > > >>> linux-iio with Tomasz Cced with no response.
> > > > >>
> > > > >> So you did not check enough... and no one needs to read RFC :/
> > > > >
> > > > > Hmm... lore.kernel.org shows last activity November last year (07-11-2025).
> > > > > What other sources do you suggest to check?
> > > >
> > > > No, only lore.
> > >
> > > I used this request:
> > > https://lore.kernel.org/all/?q=f%3A%22Tomasz+Duszynski%22
> > >
> > > > As I said, February this year.
> > > >
> > > > https://lore.kernel.org/all/CAObtm8zKUAWNS23nRMhc9ZR-zn7xeVOFPiV4ai_x7Bkd5puiyA@mail.gmail.com/
> > >
> > > Okay, you used UTF-8 name, Where did you get it from? MAINTAINERS has no
> > > diacritics.
> >
> > OTOH, you may have used simply email approach. With
> > https://lore.kernel.org/all/?q=f%3Atduszyns%40gmail.com
> > I got it as well.
>
> Ok, now I see it. I will say though that we've emailed Tomasz at least
> 10 times at this point for various things and hasn't responded to even
> one :/ if we need to we can allow Jonathan to chime in.
--
Tomasz Duszyński
^ permalink raw reply
* Re: (subset) [PATCH v2 00/15] var-som-6ul: improve support for variants
From: Hugo Villeneuve @ 2026-06-11 13:36 UTC (permalink / raw)
To: Frank.Li
Cc: robh, krzk+dt, conor+dt, andrzej.hajda, neil.armstrong, rfoss,
Laurent.pinchart, jonas, jernej.skrabec, maarten.lankhorst,
mripard, tzimmermann, airlied, simona, s.hauer, kernel, festevam,
shawnguo, laurent.pinchart+renesas, antonin.godard, Frank Li,
devicetree, linux-kernel, dri-devel, imx, linux-arm-kernel,
Hugo Villeneuve
In-Reply-To: <178111898079.1109057.8610962818602994576.b4-ty@b4>
On Wed, 10 Jun 2026 15:18:16 -0400
Frank.Li@oss.nxp.com wrote:
> From: Frank Li <Frank.Li@nxp.com>
>
>
> On Thu, 05 Mar 2026 13:06:15 -0500, Hugo Villeneuve wrote:
> > From: Hugo Villeneuve <hvilleneuve@dimonoff.com>
> >
> > Hello,
> > this patch series improves support for Variscite VAR-SOM-6UL based boards.
> >
> > The first two patches fix DT/dmesg warnings.
> >
> > [...]
>
> Applied, thanks!
>
> [14/15] dt-bindings: display/lvds-codec: add ti,sn65lvds93
> commit: bd584193a91ef2e190a2cf19f9320387fda1a21d
>
> Other dts part already picked by me. This binding have not picked by
> subsystem mainatiner by twice ping. I picked it to avoid CHECK_DTB warnings.
Thank you for that.
Hugo.
>
>
> Best regards,
> --
> Frank Li <Frank.Li@nxp.com>
^ permalink raw reply
* Re: [PATCH v7 1/2] dt-bindings: ufs: Document static TX Equalization settings properties
From: Krzysztof Kozlowski @ 2026-06-11 13:32 UTC (permalink / raw)
To: Can Guo, bvanassche, beanhuo, peter.wang, martin.petersen, mani
Cc: linux-scsi, Alim Akhtar, Avri Altman, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Zhaoming Luo,
Ram Kumar Dwivedi,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
open list
In-Reply-To: <20260610071516.3763916-2-can.guo@oss.qualcomm.com>
On 10/06/2026 09:15, Can Guo wrote:
> UFS v5.0/UFSHCI v5.0 add HS-G6 support via UniPro v3.0 and M-PHY v6.0.
> These specs define TX Equalization for all High Speed Gears, and HS-G6 may
> also require TX precode depending on channel characteristics.
>
> Document vendor-neutral DT properties in ufs-common.yaml:
>
> - patternProperties for txeq-preshoot-g[1-6] and txeq-deemphasis-g[1-6]
> - tx-precode-g6-host-lanes
> - tx-precode-g6-device-lanes
>
> txeq-preshoot-g[1-6] and txeq-deemphasis-g[1-6] accept per-lane tuples:
> <Host_Lane0 Device_Lane0>, [<Host_Lane1 Device_Lane1>]
Instead of repeating the diff, you should explain why these properties
are needed. Insufficient explanation was also pointed out at v1.
Why this cannot be deduced from the IP compatible? Does it depend on the
device memory? Who determines the values here and what do they depend
on? Also here you explain lack of auto tuning for example.
>
> PreShoot and DeEmphasis values are 0..7 and accept 2 or 4 values for x1/x2
> lane configurations.
>
...
> + Lane indices for static Host-side TX precode enable settings for HS-G6
> + only. Listed lanes have precode enabled; unlisted lanes are disabled.
> +
> + tx-precode-g6-device-lanes:
> + $ref: /schemas/types.yaml#/definitions/uint32-array
> + minItems: 1
> + maxItems: 2
> + uniqueItems: true
> + items:
> + minimum: 0
> + maximum: 1
> + description: |
> + Lane indices for static Device-side TX precode enable settings for HS-G6
> + only. Listed lanes have precode enabled; unlisted lanes are disabled.
I need to reverse my opinion and let's go to v6 implementation. These
properties look more consistent in v6 with respect to preshoot and
deepmhasis properties.
You want actually matrix, so:
tx-precode-enable-g6:
$ref: /schemas/types.yaml#/definitions/uint32-matrix
oneOf:
- items:
- description: Host_Lane0 precode
- description: Device_Lane0 precode
- items:
- description: Host_Lane0 precode
- description: Device_Lane0 precode
- description: Host_Lane1 precode
- description: Device_Lane1 precode
items:
enum: [0, 1]
description:
Static TX Precode enable values for HS-G6 only.
And similar style with items also for preshoot and deepmhasis.
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH v4 4/4] iio: flow: add Sensirion SLF3S liquid flow sensor driver
From: Wadim Mueller @ 2026-06-11 13:27 UTC (permalink / raw)
To: Jonathan Cameron, Krzysztof Kozlowski, Rob Herring, Conor Dooley,
David Lechner, Nuno Sá, Andy Shevchenko, Maxwell Doose
Cc: linux-iio, devicetree, linux-kernel, Marcelo Schmitt,
Rodrigo Alencar, Wadim Mueller
In-Reply-To: <20260611132700.671322-1-wafgo01@gmail.com>
Add a driver for the Sensirion SLF3S family of digital
liquid-flow sensors on I2C. Currently supported variants are
SLF3S-0600F, SLF3S-1300F and SLF3S-4000B; they share the same
register map and differ only in flow-scale factor and calibrated
measurement range. The variant (and therefore the scale) is
auto-detected from the product-information register at probe time;
a sensor reporting an unknown sub-type falls back to the variant
named in the device tree, as promised by the fallback compatible.
Each measurement frame returns a 16-bit signed flow value, a
16-bit signed temperature reading and a status word, each
protected by a CRC-8 byte. The driver exposes the flow rate as
IIO_VOLUMEFLOW and the temperature as IIO_TEMP via the standard
IIO read_raw / read_scale interface.
The volume-flow scale is reported in m^3/s. As the per-LSB scale
is on the order of 1e-12 m^3/s, it is emitted as a 64-bit
fixed-point value with femto (1e-15) resolution
(IIO_VAL_DECIMAL64_FEMTO) so the small SI value keeps full
precision. This relies on the IIO_VAL_DECIMAL64_FEMTO format type
added earlier in this series, which extends the IIO_VAL_DECIMAL64
core formatting introduced by Rodrigo Alencar's ADF41513 series.
The active calibration medium can be switched at runtime between
the factory-calibrated water and isopropyl-alcohol modes via the
in_volumeflow_medium sysfs attribute; the sensor starts in water
mode after probe.
The sensor has no low-power state of its own, so system suspend
stops the measurement and disables the vdd supply; resume powers
the sensor back up, waits out the power-up time and restarts the
measurement with the previously active medium, following the
scd30/scd4x precedent.
This driver also creates the drivers/iio/flow/ subdirectory and
the corresponding Kconfig/Makefile glue.
Signed-off-by: Wadim Mueller <wafgo01@gmail.com>
---
Documentation/ABI/testing/sysfs-bus-iio-flow | 21 +
MAINTAINERS | 1 +
drivers/iio/Kconfig | 1 +
drivers/iio/Makefile | 1 +
drivers/iio/flow/Kconfig | 22 +
drivers/iio/flow/Makefile | 7 +
drivers/iio/flow/slf3s.c | 521 +++++++++++++++++++
7 files changed, 574 insertions(+)
create mode 100644 Documentation/ABI/testing/sysfs-bus-iio-flow
create mode 100644 drivers/iio/flow/Kconfig
create mode 100644 drivers/iio/flow/Makefile
create mode 100644 drivers/iio/flow/slf3s.c
diff --git a/Documentation/ABI/testing/sysfs-bus-iio-flow b/Documentation/ABI/testing/sysfs-bus-iio-flow
new file mode 100644
index 000000000..fece2ecfa
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-bus-iio-flow
@@ -0,0 +1,21 @@
+What: /sys/bus/iio/devices/iio:deviceX/in_volumeflow_medium
+What: /sys/bus/iio/devices/iio:deviceX/in_volumeflowY_medium
+KernelVersion: 7.3
+Contact: linux-iio@vger.kernel.org
+Description:
+ The calibration medium the flow sensor uses to convert its
+ raw reading into a volumetric flow rate. Liquid flow sensors
+ are factory-calibrated per medium, so the selected medium has
+ to match the fluid actually flowing through the sensor for the
+ reported flow rate to be correct.
+
+ Reading returns the currently active medium; writing one of the
+ strings listed in in_volumeflow_medium_available selects it.
+
+What: /sys/bus/iio/devices/iio:deviceX/in_volumeflow_medium_available
+What: /sys/bus/iio/devices/iio:deviceX/in_volumeflowY_medium_available
+KernelVersion: 7.3
+Contact: linux-iio@vger.kernel.org
+Description:
+ Space separated list of the calibration media supported by the
+ device, e.g. "water ipa".
diff --git a/MAINTAINERS b/MAINTAINERS
index cdc18a601..222a03b6d 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -24193,6 +24193,7 @@ R: Maxwell Doose <m32285159@gmail.com>
L: linux-iio@vger.kernel.org
S: Maintained
F: Documentation/devicetree/bindings/iio/flow/sensirion,slf3s.yaml
+F: drivers/iio/flow/slf3s.c
SENSIRION SPS30 AIR POLLUTION SENSOR DRIVER
M: Tomasz Duszynski <tduszyns@gmail.com>
diff --git a/drivers/iio/Kconfig b/drivers/iio/Kconfig
index 661127aed..652557a5b 100644
--- a/drivers/iio/Kconfig
+++ b/drivers/iio/Kconfig
@@ -92,6 +92,7 @@ source "drivers/iio/common/Kconfig"
source "drivers/iio/dac/Kconfig"
source "drivers/iio/dummy/Kconfig"
source "drivers/iio/filter/Kconfig"
+source "drivers/iio/flow/Kconfig"
source "drivers/iio/frequency/Kconfig"
source "drivers/iio/gyro/Kconfig"
source "drivers/iio/health/Kconfig"
diff --git a/drivers/iio/Makefile b/drivers/iio/Makefile
index cb80ef837..f03a4100c 100644
--- a/drivers/iio/Makefile
+++ b/drivers/iio/Makefile
@@ -29,6 +29,7 @@ obj-y += dac/
obj-y += dummy/
obj-y += gyro/
obj-y += filter/
+obj-y += flow/
obj-y += frequency/
obj-y += health/
obj-y += humidity/
diff --git a/drivers/iio/flow/Kconfig b/drivers/iio/flow/Kconfig
new file mode 100644
index 000000000..e0e1a8e36
--- /dev/null
+++ b/drivers/iio/flow/Kconfig
@@ -0,0 +1,22 @@
+# SPDX-License-Identifier: GPL-2.0-only
+#
+# Liquid / gas flow sensor drivers
+#
+# When adding new entries keep the list in alphabetical order
+
+menu "Flow sensors"
+
+config SENSIRION_SLF3S
+ tristate "Sensirion SLF3S liquid flow sensor"
+ depends on I2C
+ select CRC8
+ help
+ Say yes here to build support for the Sensirion SLF3S family of
+ digital liquid-flow sensors (SLF3S-0600F, SLF3S-1300F and
+ SLF3S-4000B). The driver reports the volumetric flow rate and the
+ embedded temperature reading via the standard IIO interface.
+
+ To compile this driver as a module, choose M here: the module
+ will be called slf3s.
+
+endmenu
diff --git a/drivers/iio/flow/Makefile b/drivers/iio/flow/Makefile
new file mode 100644
index 000000000..3cf4ab95c
--- /dev/null
+++ b/drivers/iio/flow/Makefile
@@ -0,0 +1,7 @@
+# SPDX-License-Identifier: GPL-2.0
+#
+# Makefile for industrial I/O flow sensor drivers
+#
+
+# When adding new entries keep the list in alphabetical order
+obj-$(CONFIG_SENSIRION_SLF3S) += slf3s.o
diff --git a/drivers/iio/flow/slf3s.c b/drivers/iio/flow/slf3s.c
new file mode 100644
index 000000000..ed7b89e8e
--- /dev/null
+++ b/drivers/iio/flow/slf3s.c
@@ -0,0 +1,521 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Sensirion SLF3S liquid flow sensor driver.
+ *
+ * Supports the SLF3S-0600F, SLF3S-1300F and SLF3S-4000B liquid-flow
+ * sensors over I2C. Each measurement frame returns a 16-bit signed
+ * flow value, a 16-bit signed temperature value and a status word,
+ * each protected by a CRC-8 byte.
+ *
+ * The active calibration medium (water or isopropyl alcohol) is
+ * runtime-switchable via the in_volumeflow_medium sysfs attribute and
+ * defaults to water.
+ *
+ * Datasheet: https://sensirion.com/products/catalog/SLF3S-0600F/
+ *
+ * Copyright (C) 2026 CMBlu Energy GmbH
+ * Author: Wadim Mueller <wafgo01@gmail.com>
+ */
+
+#include <linux/array_size.h>
+#include <linux/bitops.h>
+#include <linux/cleanup.h>
+#include <linux/crc8.h>
+#include <linux/delay.h>
+#include <linux/dev_printk.h>
+#include <linux/device.h>
+#include <linux/errno.h>
+#include <linux/i2c.h>
+#include <linux/math64.h>
+#include <linux/mod_devicetable.h>
+#include <linux/module.h>
+#include <linux/mutex.h>
+#include <linux/pm.h>
+#include <linux/regulator/consumer.h>
+#include <linux/types.h>
+#include <linux/unaligned.h>
+#include <linux/units.h>
+
+#include <linux/iio/iio.h>
+
+#define SLF3S_CRC8_POLY 0x31
+#define SLF3S_CRC8_INIT 0xff
+
+#define SLF3S_PRODUCT_ID_LEN 18
+#define SLF3S_PRODUCT_FAMILY_BYTE 1
+#define SLF3S_PRODUCT_SUBTYPE_BYTE 3
+#define SLF3S_PRODUCT_FAMILY_ID 0x03
+
+/* Datasheet section 2.2: tPU = 25 ms max from power-on to first cmd. */
+#define SLF3S_POWER_UP_DELAY_US (25 * USEC_PER_MSEC)
+/* Datasheet section 2.2: tw = 60 ms typical until first valid sample. */
+#define SLF3S_MEAS_START_DELAY_US (60 * USEC_PER_MSEC)
+
+static const u8 slf3s_cmd_prep_pid[] = { 0x36, 0x7c };
+static const u8 slf3s_cmd_read_pid[] = { 0xe1, 0x02 };
+static const u8 slf3s_cmd_start_water[] = { 0x36, 0x08 };
+static const u8 slf3s_cmd_start_ipa[] = { 0x36, 0x15 };
+static const u8 slf3s_cmd_stop_meas[] = { 0x3f, 0xf9 };
+
+enum slf3s_medium {
+ SLF3S_MEDIUM_WATER,
+ SLF3S_MEDIUM_IPA,
+};
+
+static const char * const slf3s_medium_modes[] = {
+ [SLF3S_MEDIUM_WATER] = "water",
+ [SLF3S_MEDIUM_IPA] = "ipa",
+};
+
+/**
+ * struct slf3s_variant - per-variant calibration constants
+ * @sub_type: product-info sub-type byte returned by the sensor
+ * @name: name reported via @iio_dev.name
+ * @scale_num: flow scale numerator (l/s per LSB)
+ * @scale_den: flow scale denominator (l/s per LSB)
+ */
+struct slf3s_variant {
+ u8 sub_type;
+ const char *name;
+ int scale_num;
+ int scale_den;
+};
+
+static const struct slf3s_variant slf3s_variants[] = {
+ [0] = {
+ .sub_type = 0x03,
+ .name = "slf3s-0600f",
+ .scale_num = 1,
+ .scale_den = 600 * MICRO,
+ },
+ [1] = {
+ .sub_type = 0x02,
+ .name = "slf3s-1300f",
+ .scale_num = 1,
+ .scale_den = 30 * MICRO,
+ },
+ [2] = {
+ .sub_type = 0x05,
+ .name = "slf3s-4000b",
+ .scale_num = 1,
+ .scale_den = 1920 * MILLI,
+ },
+};
+
+/**
+ * struct slf3s_data - per-device state
+ * @client: I2C client this instance is bound to
+ * @vdd: supply regulator, disabled while suspended
+ * @variant: pointer into @slf3s_variants for the detected device
+ * @medium: currently active calibration medium
+ * @lock: serialises the multi-step command/response exchanges
+ * @crc_table: pre-computed CRC-8 lookup table for SLF3S_CRC8_POLY
+ */
+struct slf3s_data {
+ struct i2c_client *client;
+ struct regulator *vdd;
+ const struct slf3s_variant *variant;
+ enum slf3s_medium medium;
+ struct mutex lock; /* serialises command/response exchanges */
+ u8 crc_table[CRC8_TABLE_SIZE];
+};
+
+static int slf3s_send_cmd(struct i2c_client *client, const u8 cmd[at_least 2])
+{
+ int ret = i2c_master_send(client, cmd, 2);
+
+ if (ret == 2)
+ return 0;
+
+ return ret < 0 ? ret : -EIO;
+}
+
+/* Start continuous measurement and wait until the first sample is valid. */
+static int slf3s_start_meas(struct slf3s_data *sf, enum slf3s_medium medium)
+{
+ const u8 *cmd = (medium == SLF3S_MEDIUM_IPA) ? slf3s_cmd_start_ipa
+ : slf3s_cmd_start_water;
+ int ret;
+
+ ret = slf3s_send_cmd(sf->client, cmd);
+ if (ret)
+ return ret;
+
+ fsleep(SLF3S_MEAS_START_DELAY_US);
+
+ return 0;
+}
+
+static bool slf3s_crc_valid(const struct slf3s_data *sf, const u8 *block)
+{
+ return crc8(sf->crc_table, block, 2, SLF3S_CRC8_INIT) == block[2];
+}
+
+/*
+ * Read the product-info block and pick the matching variant. The
+ * sub-type byte returned by the sensor is the source of truth; a
+ * DT-supplied compatible only seeds an initial guess and is overridden
+ * on mismatch (with an informational message so misconfigured device
+ * trees are easy to spot).
+ *
+ * Bus / CRC failures are real errors and fail probe. An unknown
+ * sub-type byte falls back to the variant named in the device tree /
+ * I2C table: the fallback compatible promises that future family
+ * members work as an SLF3S-1300F, so do not reject them. Without any
+ * match data probe fails since no meaningful scale can be published.
+ */
+static int slf3s_detect_variant(struct slf3s_data *sf)
+{
+ struct i2c_client *client = sf->client;
+ u8 buf[SLF3S_PRODUCT_ID_LEN];
+ int ret;
+
+ ret = slf3s_send_cmd(client, slf3s_cmd_prep_pid);
+ if (ret)
+ return ret;
+
+ ret = slf3s_send_cmd(client, slf3s_cmd_read_pid);
+ if (ret)
+ return ret;
+
+ ret = i2c_master_recv(client, buf, sizeof(buf));
+ if (ret < 0)
+ return ret;
+ if (ret != sizeof(buf))
+ return -EIO;
+
+ for (unsigned int i = 0; i < SLF3S_PRODUCT_ID_LEN; i += 3) {
+ if (!slf3s_crc_valid(sf, &buf[i]))
+ return -EIO;
+ }
+
+ if (buf[SLF3S_PRODUCT_FAMILY_BYTE] != SLF3S_PRODUCT_FAMILY_ID)
+ dev_info(&client->dev,
+ "unexpected family byte 0x%02x (expected 0x%02x)\n",
+ buf[SLF3S_PRODUCT_FAMILY_BYTE],
+ SLF3S_PRODUCT_FAMILY_ID);
+
+ for (unsigned int i = 0; i < ARRAY_SIZE(slf3s_variants); i++) {
+ if (buf[SLF3S_PRODUCT_SUBTYPE_BYTE] !=
+ slf3s_variants[i].sub_type)
+ continue;
+
+ if (sf->variant && sf->variant != &slf3s_variants[i])
+ dev_info(&client->dev,
+ "DT compatible says %s but sensor reports %s; using %s\n",
+ sf->variant->name,
+ slf3s_variants[i].name,
+ slf3s_variants[i].name);
+
+ sf->variant = &slf3s_variants[i];
+
+ return 0;
+ }
+
+ if (sf->variant) {
+ dev_warn(&client->dev,
+ "unknown SLF3S sub-type 0x%02x, assuming %s\n",
+ buf[SLF3S_PRODUCT_SUBTYPE_BYTE], sf->variant->name);
+ return 0;
+ }
+
+ dev_err(&client->dev, "unknown SLF3S sub-type 0x%02x\n",
+ buf[SLF3S_PRODUCT_SUBTYPE_BYTE]);
+
+ return -ENODEV;
+}
+
+static int slf3s_read_sample(struct slf3s_data *sf, int *flow, int *temp)
+{
+ /*
+ * A measurement frame is flow, temperature and a signaling-flags
+ * word, each followed by a CRC byte. Only flow and temperature are
+ * used, so the read is stopped after their two words (6 bytes).
+ */
+ u8 buf[6];
+ int ret;
+
+ ret = i2c_master_recv(sf->client, buf, ARRAY_SIZE(buf));
+ if (ret < 0)
+ return ret;
+ if (ret != ARRAY_SIZE(buf))
+ return -EIO;
+
+ for (unsigned int i = 0; i < ARRAY_SIZE(buf); i += 3) {
+ if (!slf3s_crc_valid(sf, &buf[i]))
+ return -EIO;
+ }
+
+ *flow = sign_extend32(get_unaligned_be16(&buf[0]), 15);
+ *temp = sign_extend32(get_unaligned_be16(&buf[3]), 15);
+
+ return 0;
+}
+
+static int slf3s_get_medium(struct iio_dev *indio_dev,
+ const struct iio_chan_spec *chan)
+{
+ struct slf3s_data *sf = iio_priv(indio_dev);
+
+ return sf->medium;
+}
+
+static int slf3s_set_medium(struct iio_dev *indio_dev,
+ const struct iio_chan_spec *chan, unsigned int mode)
+{
+ struct slf3s_data *sf = iio_priv(indio_dev);
+ int ret;
+
+ guard(mutex)(&sf->lock);
+
+ ret = slf3s_send_cmd(sf->client, slf3s_cmd_stop_meas);
+ if (ret)
+ return ret;
+
+ ret = slf3s_start_meas(sf, mode);
+ if (ret) {
+ /*
+ * Try to restart with the previous medium so the sensor is
+ * not left idle, which would fail all subsequent reads.
+ */
+ if (slf3s_start_meas(sf, sf->medium))
+ dev_warn(&sf->client->dev,
+ "failed to restart measurement, reads will fail until a medium is set\n");
+ return ret;
+ }
+
+ sf->medium = mode;
+
+ return 0;
+}
+
+static const struct iio_enum slf3s_medium_enum = {
+ .items = slf3s_medium_modes,
+ .num_items = ARRAY_SIZE(slf3s_medium_modes),
+ .get = slf3s_get_medium,
+ .set = slf3s_set_medium,
+};
+
+static const struct iio_chan_spec_ext_info slf3s_ext_info[] = {
+ IIO_ENUM("medium", IIO_SHARED_BY_TYPE, &slf3s_medium_enum),
+ IIO_ENUM_AVAILABLE("medium", IIO_SHARED_BY_TYPE, &slf3s_medium_enum),
+ { }
+};
+
+static const struct iio_chan_spec slf3s_channels[] = {
+ {
+ .type = IIO_VOLUMEFLOW,
+ .info_mask_separate = BIT(IIO_CHAN_INFO_RAW) |
+ BIT(IIO_CHAN_INFO_SCALE),
+ .ext_info = slf3s_ext_info,
+ },
+ {
+ .type = IIO_TEMP,
+ .info_mask_separate = BIT(IIO_CHAN_INFO_RAW) |
+ BIT(IIO_CHAN_INFO_SCALE),
+ },
+};
+
+static int slf3s_read_raw(struct iio_dev *indio_dev,
+ struct iio_chan_spec const *chan, int *val,
+ int *val2, long mask)
+{
+ struct slf3s_data *sf = iio_priv(indio_dev);
+ int flow, temp, ret;
+
+ switch (mask) {
+ case IIO_CHAN_INFO_RAW:
+ scoped_guard(mutex, &sf->lock)
+ ret = slf3s_read_sample(sf, &flow, &temp);
+ if (ret)
+ return ret;
+
+ *val = (chan->type == IIO_VOLUMEFLOW) ? flow : temp;
+
+ return IIO_VAL_INT;
+ case IIO_CHAN_INFO_SCALE:
+ if (chan->type == IIO_VOLUMEFLOW) {
+ /*
+ * scale_num/scale_den is the flow per LSB in l/s, but
+ * IIO reports volume flow in m^3/s (1 l = 1e-3 m^3).
+ * These values are tiny (~1.67e-12 m^3/s for the
+ * SLF3S-0600F), so emit a 64-bit fixed-point value with
+ * femto (1e-15) resolution to preserve precision.
+ * Converting l/s to m^3/s (/ MILLI) and scaling to femto
+ * (* FEMTO) leaves a net * (FEMTO / MILLI) factor.
+ */
+ const struct slf3s_variant *v = sf->variant;
+ s64 num = (s64)v->scale_num * FEMTO / MILLI;
+ s64 scale = DIV_S64_ROUND_CLOSEST(num, v->scale_den);
+
+ iio_val_s64_decompose(scale, val, val2);
+
+ return IIO_VAL_DECIMAL64_FEMTO;
+ }
+ /* Temperature LSB = 1/200 degC; IIO_TEMP wants milli-degC. */
+ *val = 1000 / 200;
+
+ return IIO_VAL_INT;
+ default:
+ return -EINVAL;
+ }
+}
+
+static const struct iio_info slf3s_info = {
+ .read_raw = slf3s_read_raw,
+};
+
+static void slf3s_stop_meas(void *data)
+{
+ struct slf3s_data *sf = data;
+
+ slf3s_send_cmd(sf->client, slf3s_cmd_stop_meas);
+}
+
+static void slf3s_disable_vdd(void *data)
+{
+ struct slf3s_data *sf = data;
+
+ regulator_disable(sf->vdd);
+}
+
+static int slf3s_probe(struct i2c_client *client)
+{
+ struct device *dev = &client->dev;
+ struct iio_dev *indio_dev;
+ struct slf3s_data *sf;
+ int ret;
+
+ indio_dev = devm_iio_device_alloc(dev, sizeof(*sf));
+ if (!indio_dev)
+ return -ENOMEM;
+
+ sf = iio_priv(indio_dev);
+ sf->client = client;
+ i2c_set_clientdata(client, indio_dev);
+ sf->variant = i2c_get_match_data(client);
+ sf->medium = SLF3S_MEDIUM_WATER;
+ crc8_populate_msb(sf->crc_table, SLF3S_CRC8_POLY);
+
+ ret = devm_mutex_init(dev, &sf->lock);
+ if (ret)
+ return ret;
+
+ sf->vdd = devm_regulator_get(dev, "vdd");
+ if (IS_ERR(sf->vdd))
+ return dev_err_probe(dev, PTR_ERR(sf->vdd),
+ "failed to get vdd supply\n");
+
+ ret = regulator_enable(sf->vdd);
+ if (ret)
+ return dev_err_probe(dev, ret, "failed to enable vdd supply\n");
+
+ ret = devm_add_action_or_reset(dev, slf3s_disable_vdd, sf);
+ if (ret)
+ return ret;
+
+ fsleep(SLF3S_POWER_UP_DELAY_US);
+
+ /*
+ * The sensor may still be in continuous measurement mode from a
+ * previous boot (warm reboot / kexec); in that case it would NACK
+ * the product-id command below. Stop it first and ignore the error
+ * if it was already idle.
+ */
+ slf3s_send_cmd(client, slf3s_cmd_stop_meas);
+
+ ret = slf3s_detect_variant(sf);
+ if (ret)
+ return dev_err_probe(dev, ret, "product info read failed\n");
+
+ ret = slf3s_start_meas(sf, sf->medium);
+ if (ret)
+ return dev_err_probe(dev, ret,
+ "failed to start measurement\n");
+
+ ret = devm_add_action_or_reset(dev, slf3s_stop_meas, sf);
+ if (ret)
+ return ret;
+
+ indio_dev->name = sf->variant->name;
+ indio_dev->channels = slf3s_channels;
+ indio_dev->num_channels = ARRAY_SIZE(slf3s_channels);
+ indio_dev->info = &slf3s_info;
+ indio_dev->modes = INDIO_DIRECT_MODE;
+
+ return devm_iio_device_register(dev, indio_dev);
+}
+
+/*
+ * The sensor has no low-power state of its own, so stop the measurement
+ * and cut the supply while suspended. Resume powers it back up, waits
+ * out the power-up time and restarts with the medium that was active
+ * before.
+ */
+static int slf3s_suspend(struct device *dev)
+{
+ struct iio_dev *indio_dev = dev_get_drvdata(dev);
+ struct slf3s_data *sf = iio_priv(indio_dev);
+ int ret;
+
+ guard(mutex)(&sf->lock);
+
+ ret = slf3s_send_cmd(sf->client, slf3s_cmd_stop_meas);
+ if (ret)
+ return ret;
+
+ return regulator_disable(sf->vdd);
+}
+
+static int slf3s_resume(struct device *dev)
+{
+ struct iio_dev *indio_dev = dev_get_drvdata(dev);
+ struct slf3s_data *sf = iio_priv(indio_dev);
+ int ret;
+
+ guard(mutex)(&sf->lock);
+
+ ret = regulator_enable(sf->vdd);
+ if (ret)
+ return ret;
+
+ fsleep(SLF3S_POWER_UP_DELAY_US);
+
+ return slf3s_start_meas(sf, sf->medium);
+}
+
+static DEFINE_SIMPLE_DEV_PM_OPS(slf3s_pm_ops, slf3s_suspend, slf3s_resume);
+
+static const struct i2c_device_id slf3s_id[] = {
+ { .name = "slf3s-0600f",
+ .driver_data = (kernel_ulong_t)&slf3s_variants[0] },
+ { .name = "slf3s-1300f",
+ .driver_data = (kernel_ulong_t)&slf3s_variants[1] },
+ { .name = "slf3s-4000b",
+ .driver_data = (kernel_ulong_t)&slf3s_variants[2] },
+ { }
+};
+MODULE_DEVICE_TABLE(i2c, slf3s_id);
+
+static const struct of_device_id slf3s_of_match[] = {
+ { .compatible = "sensirion,slf3s-0600f", .data = &slf3s_variants[0] },
+ { .compatible = "sensirion,slf3s-1300f", .data = &slf3s_variants[1] },
+ { .compatible = "sensirion,slf3s-4000b", .data = &slf3s_variants[2] },
+ { }
+};
+MODULE_DEVICE_TABLE(of, slf3s_of_match);
+
+static struct i2c_driver slf3s_driver = {
+ .driver = {
+ .name = "slf3s",
+ .of_match_table = slf3s_of_match,
+ .pm = pm_sleep_ptr(&slf3s_pm_ops),
+ },
+ .probe = slf3s_probe,
+ .id_table = slf3s_id,
+};
+module_i2c_driver(slf3s_driver);
+
+MODULE_AUTHOR("Wadim Mueller <wafgo01@gmail.com>");
+MODULE_DESCRIPTION("Sensirion SLF3S liquid flow sensor driver");
+MODULE_LICENSE("GPL");
--
2.52.0
^ permalink raw reply related
* [PATCH v4 3/4] iio: core: add IIO_VAL_DECIMAL64_FEMTO format type
From: Wadim Mueller @ 2026-06-11 13:26 UTC (permalink / raw)
To: Jonathan Cameron, Krzysztof Kozlowski, Rob Herring, Conor Dooley,
David Lechner, Nuno Sá, Andy Shevchenko, Maxwell Doose
Cc: linux-iio, devicetree, linux-kernel, Marcelo Schmitt,
Rodrigo Alencar, Wadim Mueller
In-Reply-To: <20260611132700.671322-1-wafgo01@gmail.com>
Extend the IIO_VAL_DECIMAL64_* family with a femto-scaled variant
(scale 15), following the existing MILLI/MICRO/NANO/PICO pattern. Both
the read formatting path in __iio_format_value() and the write parsing
path in iio_write_channel_info() (via kstrtodec64()) already derive
their scale from "type - IIO_VAL_DECIMAL64_BASE", so the new type only
needs to be added to the respective switch cases.
This is needed by drivers reporting very small SI quantities where the
existing pico scale loses precision. For example the Sensirion SLF3S
liquid flow sensor reports its volume-flow scale in m^3/s, where the
SLF3S-0600F scale is ~1.667e-12 m^3/s: at pico scale only a single
significant digit survives, whereas femto scale preserves the full
sensor resolution.
Signed-off-by: Wadim Mueller <wafgo01@gmail.com>
---
drivers/iio/industrialio-core.c | 2 ++
include/linux/iio/types.h | 1 +
2 files changed, 3 insertions(+)
diff --git a/drivers/iio/industrialio-core.c b/drivers/iio/industrialio-core.c
index 571b8ba4e..685661cd8 100644
--- a/drivers/iio/industrialio-core.c
+++ b/drivers/iio/industrialio-core.c
@@ -713,6 +713,7 @@ static ssize_t __iio_format_value(char *buf, size_t offset, unsigned int type,
case IIO_VAL_DECIMAL64_MICRO:
case IIO_VAL_DECIMAL64_NANO:
case IIO_VAL_DECIMAL64_PICO:
+ case IIO_VAL_DECIMAL64_FEMTO:
{
int scale = type - IIO_VAL_DECIMAL64_BASE;
s64 frac;
@@ -1030,6 +1031,7 @@ static ssize_t iio_write_channel_info(struct device *dev,
case IIO_VAL_DECIMAL64_MICRO:
case IIO_VAL_DECIMAL64_NANO:
case IIO_VAL_DECIMAL64_PICO:
+ case IIO_VAL_DECIMAL64_FEMTO:
dec_scale = type - IIO_VAL_DECIMAL64_BASE;
fallthrough;
case IIO_VAL_INT_64:
diff --git a/include/linux/iio/types.h b/include/linux/iio/types.h
index 3b8a2d82f..1f2f03d5d 100644
--- a/include/linux/iio/types.h
+++ b/include/linux/iio/types.h
@@ -41,6 +41,7 @@ enum iio_event_info {
#define IIO_VAL_DECIMAL64_MICRO (IIO_VAL_DECIMAL64_BASE + 6)
#define IIO_VAL_DECIMAL64_NANO (IIO_VAL_DECIMAL64_BASE + 9)
#define IIO_VAL_DECIMAL64_PICO (IIO_VAL_DECIMAL64_BASE + 12)
+#define IIO_VAL_DECIMAL64_FEMTO (IIO_VAL_DECIMAL64_BASE + 15)
static inline s64 iio_val_s64_compose(s32 val0, s32 val1)
{
--
2.52.0
^ permalink raw reply related
* [PATCH v4 2/4] dt-bindings: iio: flow: add Sensirion SLF3S liquid flow sensor
From: Wadim Mueller @ 2026-06-11 13:26 UTC (permalink / raw)
To: Jonathan Cameron, Krzysztof Kozlowski, Rob Herring, Conor Dooley,
David Lechner, Nuno Sá, Andy Shevchenko, Maxwell Doose
Cc: linux-iio, devicetree, linux-kernel, Marcelo Schmitt,
Rodrigo Alencar, Wadim Mueller
In-Reply-To: <20260611132700.671322-1-wafgo01@gmail.com>
Document the bindings for the Sensirion SLF3S family of digital
liquid-flow sensors on I2C. The family currently covers the
SLF3S-0600F, SLF3S-1300F and SLF3S-4000B variants.
All variants share the same register map and are fully detectable
from the product-information register at probe time, so
sensirion,slf3s-1300f serves as the fallback compatible for the
other variants.
The active calibration medium (water / IPA) is runtime-switchable
via the in_volumeflow_medium sysfs attribute and therefore not a
DT property.
Signed-off-by: Wadim Mueller <wafgo01@gmail.com>
---
.../bindings/iio/flow/sensirion,slf3s.yaml | 58 +++++++++++++++++++
MAINTAINERS | 7 +++
2 files changed, 65 insertions(+)
create mode 100644 Documentation/devicetree/bindings/iio/flow/sensirion,slf3s.yaml
diff --git a/Documentation/devicetree/bindings/iio/flow/sensirion,slf3s.yaml b/Documentation/devicetree/bindings/iio/flow/sensirion,slf3s.yaml
new file mode 100644
index 000000000..c054a505b
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/flow/sensirion,slf3s.yaml
@@ -0,0 +1,58 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/iio/flow/sensirion,slf3s.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Sensirion SLF3S liquid flow sensor
+
+maintainers:
+ - Wadim Mueller <wafgo01@gmail.com>
+
+description:
+ Family of digital liquid-flow sensors from Sensirion with I2C interface. All
+ family members share the same register map; sub-types differ only in the flow
+ scale factor and the calibrated measurement range. The sub-type can be
+ identified from the product-information register.
+
+properties:
+ compatible:
+ oneOf:
+ - const: sensirion,slf3s-1300f
+ - items:
+ - enum:
+ - sensirion,slf3s-0600f
+ - sensirion,slf3s-4000b
+ - const: sensirion,slf3s-1300f
+
+ reg:
+ maxItems: 1
+
+ vdd-supply: true
+
+ interrupts:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - vdd-supply
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ flow-sensor@8 {
+ compatible = "sensirion,slf3s-0600f", "sensirion,slf3s-1300f";
+ reg = <0x08>;
+ vdd-supply = <®_3v3>;
+ interrupt-parent = <&gpio0>;
+ interrupts = <0 IRQ_TYPE_EDGE_RISING>;
+ };
+ };
diff --git a/MAINTAINERS b/MAINTAINERS
index 06a8c7457..cdc18a601 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -24187,6 +24187,13 @@ S: Maintained
F: Documentation/ABI/testing/sysfs-bus-iio-chemical-sgp40
F: drivers/iio/chemical/sgp40.c
+SENSIRION SLF3S LIQUID FLOW SENSOR DRIVER
+M: Wadim Mueller <wafgo01@gmail.com>
+R: Maxwell Doose <m32285159@gmail.com>
+L: linux-iio@vger.kernel.org
+S: Maintained
+F: Documentation/devicetree/bindings/iio/flow/sensirion,slf3s.yaml
+
SENSIRION SPS30 AIR POLLUTION SENSOR DRIVER
M: Tomasz Duszynski <tduszyns@gmail.com>
S: Maintained
--
2.52.0
^ permalink raw reply related
* [PATCH v4 1/4] iio: types: add IIO_VOLUMEFLOW channel type
From: Wadim Mueller @ 2026-06-11 13:26 UTC (permalink / raw)
To: Jonathan Cameron, Krzysztof Kozlowski, Rob Herring, Conor Dooley,
David Lechner, Nuno Sá, Andy Shevchenko, Maxwell Doose
Cc: linux-iio, devicetree, linux-kernel, Marcelo Schmitt,
Rodrigo Alencar, Wadim Mueller
In-Reply-To: <20260611132700.671322-1-wafgo01@gmail.com>
Add a new IIO channel type for liquid volumetric flow sensors. The
unit exposed via the standard _scale attribute is cubic metres per
second (m^3/s), following the SI convention used by the other IIO
channel types.
Update iio-core's name table, the iio_event_monitor whitelist and
the sysfs-bus-iio ABI document to match. The new _scale attribute is
folded into the existing shared _scale block; only the per-type _raw
needs a fresh entry.
Signed-off-by: Wadim Mueller <wafgo01@gmail.com>
---
Documentation/ABI/testing/sysfs-bus-iio | 11 +++++++++++
drivers/iio/industrialio-core.c | 1 +
include/uapi/linux/iio/types.h | 1 +
tools/iio/iio_event_monitor.c | 2 ++
4 files changed, 15 insertions(+)
diff --git a/Documentation/ABI/testing/sysfs-bus-iio b/Documentation/ABI/testing/sysfs-bus-iio
index 5f87dcee7..e278fda4b 100644
--- a/Documentation/ABI/testing/sysfs-bus-iio
+++ b/Documentation/ABI/testing/sysfs-bus-iio
@@ -507,6 +507,8 @@ What: /sys/bus/iio/devices/iio:deviceX/in_intensity_red_scale
What: /sys/bus/iio/devices/iio:deviceX/in_intensity_green_scale
What: /sys/bus/iio/devices/iio:deviceX/in_intensity_blue_scale
What: /sys/bus/iio/devices/iio:deviceX/in_concentration_co2_scale
+What: /sys/bus/iio/devices/iio:deviceX/in_volumeflow_scale
+What: /sys/bus/iio/devices/iio:deviceX/in_volumeflowY_scale
KernelVersion: 2.6.35
Contact: linux-iio@vger.kernel.org
Description:
@@ -2458,3 +2460,12 @@ Description:
seconds, expressed as:
- a range specified as "[min step max]"
+
+What: /sys/bus/iio/devices/iio:deviceX/in_volumeflow_raw
+What: /sys/bus/iio/devices/iio:deviceX/in_volumeflowY_raw
+KernelVersion: 7.3
+Contact: linux-iio@vger.kernel.org
+Description:
+ Raw (unscaled) volumetric flow rate reading from the channel.
+ To convert to standard units (cubic metres per second, m^3/s)
+ apply the channel's _scale (and _offset, when present).
diff --git a/drivers/iio/industrialio-core.c b/drivers/iio/industrialio-core.c
index 93c7b8c46..571b8ba4e 100644
--- a/drivers/iio/industrialio-core.c
+++ b/drivers/iio/industrialio-core.c
@@ -98,6 +98,7 @@ static const char * const iio_chan_type_name_spec[] = {
[IIO_CHROMATICITY] = "chromaticity",
[IIO_ATTENTION] = "attention",
[IIO_ALTCURRENT] = "altcurrent",
+ [IIO_VOLUMEFLOW] = "volumeflow",
};
static const char * const iio_modifier_names[] = {
diff --git a/include/uapi/linux/iio/types.h b/include/uapi/linux/iio/types.h
index 6d269b844..49480f321 100644
--- a/include/uapi/linux/iio/types.h
+++ b/include/uapi/linux/iio/types.h
@@ -53,6 +53,7 @@ enum iio_chan_type {
IIO_CHROMATICITY,
IIO_ATTENTION,
IIO_ALTCURRENT,
+ IIO_VOLUMEFLOW,
};
enum iio_modifier {
diff --git a/tools/iio/iio_event_monitor.c b/tools/iio/iio_event_monitor.c
index 03ca33869..078004750 100644
--- a/tools/iio/iio_event_monitor.c
+++ b/tools/iio/iio_event_monitor.c
@@ -65,6 +65,7 @@ static const char * const iio_chan_type_name_spec[] = {
[IIO_CHROMATICITY] = "chromaticity",
[IIO_ATTENTION] = "attention",
[IIO_ALTCURRENT] = "altcurrent",
+ [IIO_VOLUMEFLOW] = "volumeflow",
};
static const char * const iio_ev_type_text[] = {
@@ -193,6 +194,7 @@ static bool event_is_known(struct iio_event_data *event)
case IIO_CHROMATICITY:
case IIO_ATTENTION:
case IIO_ALTCURRENT:
+ case IIO_VOLUMEFLOW:
break;
default:
return false;
--
2.52.0
^ permalink raw reply related
* [PATCH v4 0/4] iio: flow: Sensirion SLF3S liquid flow sensor
From: Wadim Mueller @ 2026-06-11 13:26 UTC (permalink / raw)
To: Jonathan Cameron, Krzysztof Kozlowski, Rob Herring, Conor Dooley,
David Lechner, Nuno Sá, Andy Shevchenko, Maxwell Doose
Cc: linux-iio, devicetree, linux-kernel, Marcelo Schmitt,
Rodrigo Alencar, Wadim Mueller
Hi all,
this series adds a driver for the Sensirion SLF3S family of I2C liquid
flow sensors (SLF3S-0600F / -1300F / -4000B) and a new IIO_VOLUMEFLOW
channel type. As in v3 this is posted as a fresh thread.
Dependency
----------
The volume-flow scale is reported in m^3/s as a 64-bit fixed-point value
(IIO_VAL_DECIMAL64_FEMTO), so this series depends on Rodrigo Alencar's
"ADF41513/ADF41510 PLL frequency synthesizers" series, which adds the
IIO_VAL_DECIMAL64_* core formatting (and the kstrtodec64() and
div64_s64_rem() helpers it builds on):
https://lore.kernel.org/linux-iio/20260604-adf41513-iio-driver-v16-0-1a7d09143bc2@analog.com/
Patch 3/4 adds the IIO_VAL_DECIMAL64_FEMTO format type on top of that.
Changes since v3
----------------
* volumeflow unit switched from l/s to m^3/s (SI), per Jonathan
* scale now reported as IIO_VAL_DECIMAL64_FEMTO instead of
IIO_VAL_FRACTIONAL, so the small m^3/s values (~1.7e-12 m^3/s for the
SLF3S-0600F) keep full precision; this needs the new FEMTO core type
(3/4) and the dependency above
* dt-bindings: sensirion,slf3s-1300f now serves as the fallback
compatible for the other variants (all variants are detectable from
the product-information register), per Krzysztof; Marcelo's
Reviewed-by dropped because of this change
* dt-bindings: add interrupts (maxItems: 1) back
* dt-bindings: reflow the description to 80 columns
* dt-bindings: move "F: drivers/iio/flow/slf3s.c" to the driver patch
* driver: add system PM ops following the scd30/scd4x precedent: stop
the measurement and disable the supply on suspend; power back up,
wait out the power-up time and restart with the previously active
medium on resume
* driver: if switching the medium fails after the stop command, restart
with the previous medium instead of leaving the sensor idle
* driver: a sensor reporting an unknown sub-type now falls back to the
variant named in the device tree instead of failing probe, matching
the fallback-compatible semantics
* driver: serialise the command/response exchanges with a local mutex
instead of iio_device_claim_direct() / release_direct()
* driver: issue a stop-measurement at the start of probe(), so a sensor
left in continuous mode across a warm reboot does not NACK probe
* driver: read only the 6 bytes actually used (flow + temperature) per
measurement frame instead of 9
* driver: trim the per-variant list out of the Kconfig help text
* ABI: in_volumeflow_medium[_available] documented in
Documentation/ABI/testing/sysfs-bus-iio-flow; KernelVersion 7.3
The signaling-flags word (air-in-line / high-flow / smoothing status) in
each measurement frame is intentionally not read; exposing it can be a
later follow-up.
Thanks,
Wadim
Wadim Mueller (4):
iio: types: add IIO_VOLUMEFLOW channel type
dt-bindings: iio: flow: add Sensirion SLF3S liquid flow sensor
iio: core: add IIO_VAL_DECIMAL64_FEMTO format type
iio: flow: add Sensirion SLF3S liquid flow sensor driver
Documentation/ABI/testing/sysfs-bus-iio | 11 +
Documentation/ABI/testing/sysfs-bus-iio-flow | 21 +
.../bindings/iio/flow/sensirion,slf3s.yaml | 58 ++
MAINTAINERS | 8 +
drivers/iio/Kconfig | 1 +
drivers/iio/Makefile | 1 +
drivers/iio/flow/Kconfig | 22 +
drivers/iio/flow/Makefile | 7 +
drivers/iio/flow/slf3s.c | 521 ++++++++++++++++++
drivers/iio/industrialio-core.c | 3 +
include/linux/iio/types.h | 1 +
include/uapi/linux/iio/types.h | 1 +
tools/iio/iio_event_monitor.c | 2 +
13 files changed, 657 insertions(+)
create mode 100644 Documentation/ABI/testing/sysfs-bus-iio-flow
create mode 100644 Documentation/devicetree/bindings/iio/flow/sensirion,slf3s.yaml
create mode 100644 drivers/iio/flow/Kconfig
create mode 100644 drivers/iio/flow/Makefile
create mode 100644 drivers/iio/flow/slf3s.c
base-commit: 3cd8b194bf3428dfa53120fee47e827a7c495815
prerequisite-patch-id: b51a25b69f7b78155e78d1a3aab809bcb57e11ae
prerequisite-patch-id: 1b26fb01ab41218c214fa58657305437565c06f8
prerequisite-patch-id: 7745e957a25b8673c7f838a9ae7a55269cd21798
prerequisite-patch-id: 5f805ccb0be820042ac732d0d8e1b188bfd2b2bc
prerequisite-patch-id: 80967f95ecb0c10fc66b3d073e99906126d5b40b
prerequisite-patch-id: 729fdedcf2055c506693d28a5dab65a6a3791598
--
2.52.0
^ permalink raw reply
* [PATCH v3] riscv: dts: spacemit: Use symbolic PDMA request numbers on K1
From: Guodong Xu @ 2026-06-11 13:17 UTC (permalink / raw)
To: Vinod Koul, Frank Li, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Yixun Lan, Paul Walmsley, Palmer Dabbelt, Albert Ou,
Alexandre Ghiti
Cc: linux-kernel, dmaengine, devicetree, linux-riscv, spacemit,
Guodong Xu
Add a local DTS header, k1-pdma.h, that gives symbolic names to the K1
PDMA request numbers. These request numbers are hardware-fixed; their
allocation can be found in K1 manual.
Replace the hard-coded numbers in the SPI3 "dmas" property with the
K1_PDMA_SPI3_RX/TX macros.
Signed-off-by: Guodong Xu <docular.xu@gmail.com>
---
Add a local DTS header naming the K1 PDMA request lines and convert the
current user (the K1 SPI3 node) to the new K1_PDMA_* macros. The request
numbers come from the SpacemiT K1 User Manual [1], Chapter 9.4.3 DMA
Connectivity & Assignments.
[1]: https://www.spacemit.com/community/document/info?lang=en&nodepath=hardware/key_stone/k1/k1_docs/k1_usermanual/9.Top_System.md
Changes in v3:
- Move the request-number macros from include/dt-bindings/dma/ to a local
DTS header arch/riscv/boot/dts/spacemit/k1-pdma.h (Conor).
- Squash the header and its user into a single patch.
- Link to v2: https://patch.msgid.link/20260609-b4-k1-pdma-req-macros-v2-0-5d5d7b997b54@gmail.com
Changes in v2:
- Drop the #dma-cells description change in spacemit,k1-pdma.yaml; the request
numbers are hardware-fixed and unused by the driver (Conor)
- Link to v1: https://patch.msgid.link/20260607-b4-k1-pdma-req-macros-v1-0-5b2a3955007c@gmail.com
BR,
Guodong Xu
---
arch/riscv/boot/dts/spacemit/k1-pdma.h | 56 ++++++++++++++++++++++++++++++++++
arch/riscv/boot/dts/spacemit/k1.dtsi | 4 ++-
2 files changed, 59 insertions(+), 1 deletion(-)
diff --git a/arch/riscv/boot/dts/spacemit/k1-pdma.h b/arch/riscv/boot/dts/spacemit/k1-pdma.h
new file mode 100644
index 0000000000000..65112d5847add
--- /dev/null
+++ b/arch/riscv/boot/dts/spacemit/k1-pdma.h
@@ -0,0 +1,56 @@
+/* SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) */
+/*
+ * This header provides DMA request number for non-secure peripherals of
+ * SpacemiT K1 PDMA.
+ *
+ * Copyright (c) 2026 Guodong Xu <docular.xu@gmail.com>
+ */
+
+#ifndef _DTS_SPACEMIT_K1_PDMA_H
+#define _DTS_SPACEMIT_K1_PDMA_H
+
+#define K1_PDMA_UART0_TX 3
+#define K1_PDMA_UART0_RX 4
+#define K1_PDMA_UART2_TX 5
+#define K1_PDMA_UART2_RX 6
+#define K1_PDMA_UART3_TX 7
+#define K1_PDMA_UART3_RX 8
+#define K1_PDMA_UART4_TX 9
+#define K1_PDMA_UART4_RX 10
+#define K1_PDMA_I2C0_TX 11
+#define K1_PDMA_I2C0_RX 12
+#define K1_PDMA_I2C1_TX 13
+#define K1_PDMA_I2C1_RX 14
+#define K1_PDMA_I2C2_TX 15
+#define K1_PDMA_I2C2_RX 16
+#define K1_PDMA_I2C4_TX 17
+#define K1_PDMA_I2C4_RX 18
+#define K1_PDMA_SPI3_TX 19
+#define K1_PDMA_SPI3_RX 20
+#define K1_PDMA_I2S0_TX 21
+#define K1_PDMA_I2S0_RX 22
+#define K1_PDMA_I2S1_TX 23
+#define K1_PDMA_I2S1_RX 24
+#define K1_PDMA_UART5_TX 25
+#define K1_PDMA_UART5_RX 26
+#define K1_PDMA_UART6_TX 27
+#define K1_PDMA_UART6_RX 28
+#define K1_PDMA_UART7_TX 29
+#define K1_PDMA_UART7_RX 30
+#define K1_PDMA_UART8_TX 31
+#define K1_PDMA_UART8_RX 32
+#define K1_PDMA_UART9_TX 33
+#define K1_PDMA_UART9_RX 34
+#define K1_PDMA_I2C5_TX 35
+#define K1_PDMA_I2C5_RX 36
+#define K1_PDMA_I2C6_TX 37
+#define K1_PDMA_I2C6_RX 38
+#define K1_PDMA_I2C7_TX 39
+#define K1_PDMA_I2C7_RX 40
+#define K1_PDMA_I2C8_TX 41
+#define K1_PDMA_I2C8_RX 42
+#define K1_PDMA_CAN0_RX 43
+#define K1_PDMA_QSPI_RX 44
+#define K1_PDMA_QSPI_TX 45
+
+#endif /* _DTS_SPACEMIT_K1_PDMA_H */
diff --git a/arch/riscv/boot/dts/spacemit/k1.dtsi b/arch/riscv/boot/dts/spacemit/k1.dtsi
index 08a0f28d011fe..7d414e15d2cc2 100644
--- a/arch/riscv/boot/dts/spacemit/k1.dtsi
+++ b/arch/riscv/boot/dts/spacemit/k1.dtsi
@@ -6,6 +6,8 @@
#include <dt-bindings/clock/spacemit,k1-syscon.h>
#include <dt-bindings/phy/phy.h>
+#include "k1-pdma.h"
+
/dts-v1/;
/ {
#address-cells = <2>;
@@ -1094,7 +1096,7 @@ spi3: spi@d401c000 {
clock-names = "core", "bus";
resets = <&syscon_apbc RESET_SSP3>;
interrupts = <55>;
- dmas = <&pdma 20>, <&pdma 19>;
+ dmas = <&pdma K1_PDMA_SPI3_RX>, <&pdma K1_PDMA_SPI3_TX>;
dma-names = "rx", "tx";
status = "disabled";
};
---
base-commit: 793cc54475b49b5b558902b5c13e4bfe66530a50
change-id: 20260607-b4-k1-pdma-req-macros-8d276d0126df
Best regards,
--
Guodong Xu <docular.xu@gmail.com>
^ permalink raw reply related
* Re: [PATCH] dt-bindings: iio: accel: Convert lis302 binding to YAML schema
From: Jonathan Cameron @ 2026-06-11 13:07 UTC (permalink / raw)
To: Rob Herring
Cc: Md Shofiqul Islam, linux-iio, devicetree, dlechner, nuno.sa, andy,
krzk+dt, conor+dt, krzk, linux-kernel
In-Reply-To: <20260610192338.GB626285-robh@kernel.org>
On Wed, 10 Jun 2026 14:23:38 -0500
Rob Herring <robh@kernel.org> wrote:
> On Wed, Jun 10, 2026 at 04:56:40PM +0100, Jonathan Cameron wrote:
> > On Wed, 10 Jun 2026 14:00:51 +0300
> > Md Shofiqul Islam <shofiqtest@gmail.com> wrote:
> >
> > > Convert the STMicroelectronics LIS302DL/LIS3LV02D accelerometer device
> > > tree binding from plain text format to YAML schema format.
> > >
> > > The binding covers two variants matched via their respective bus drivers:
> > > - SPI: st,lis302dl-spi (drivers/misc/lis3lv02d/lis3lv02d_spi.c)
> > > - I2C: st,lis3lv02d (drivers/misc/lis3lv02d/lis3lv02d_i2c.c)
> > >
> > > Document all vendor-specific properties read by the driver via
> > > of_property_read_*(), including click detection, IRQ routing, free-fall/
> > > wake-up engines, high-pass filtering, axis remapping, output data rate,
> > > and self-test limits.
> > >
> > > Also correct the click threshold property names: the driver reads
> > > "st,click-threshold-{x,y,z}" but the old .txt documented them as
> > > "st,click-thresh-{x,y,z}".
> > >
> > > Validated with: make dt_binding_check DT_SCHEMA_FILES=Documentation/devicetree/bindings/iio/accel/st,lis302dl.yaml
> > >
> > > Signed-off-by: Md Shofiqul Islam <shofiqtest@gmail.com>
> >
> > Hi.
> >
> > So the conundrum here is whether we want to keep carrying this binding
> > as it dates to a previous era.
> >
> > The driver never made it to IIO and is still in drivers/misc.
> > The majority of what is the text document should never have been
> > in DT in the first place. I'll guess this dates all the way back
> > to the wild west days before we had regular binding review.
>
> Where the driver is doesn't matter for the binding. Unless the 1
> apparent user is will to change things, we should just document what is
> in use (and nothing more). Some of this looks like it can be droppped.
I don't mind documenting it, but with a big warning at the top to make
sure no one copies it for a newer part!
Jonathan
>
> Rob
^ permalink raw reply
* Re: [PATCH] dt-bindings: iio: accel: Convert lis302 binding to YAML schema
From: Jonathan Cameron @ 2026-06-11 13:06 UTC (permalink / raw)
To: Conor Dooley
Cc: Md Shofiqul Islam, linux-iio, devicetree, dlechner, nuno.sa, andy,
robh, krzk+dt, conor+dt, krzk, linux-kernel
In-Reply-To: <20260610-cytoplast-pessimism-dea888887526@spud>
On Wed, 10 Jun 2026 17:40:04 +0100
Conor Dooley <conor@kernel.org> wrote:
> On Wed, Jun 10, 2026 at 04:56:40PM +0100, Jonathan Cameron wrote:
> > On Wed, 10 Jun 2026 14:00:51 +0300
> > Md Shofiqul Islam <shofiqtest@gmail.com> wrote:
> >
> > > Convert the STMicroelectronics LIS302DL/LIS3LV02D accelerometer device
> > > tree binding from plain text format to YAML schema format.
> > >
> > > The binding covers two variants matched via their respective bus drivers:
> > > - SPI: st,lis302dl-spi (drivers/misc/lis3lv02d/lis3lv02d_spi.c)
> > > - I2C: st,lis3lv02d (drivers/misc/lis3lv02d/lis3lv02d_i2c.c)
> > >
> > > Document all vendor-specific properties read by the driver via
> > > of_property_read_*(), including click detection, IRQ routing, free-fall/
> > > wake-up engines, high-pass filtering, axis remapping, output data rate,
> > > and self-test limits.
> > >
> > > Also correct the click threshold property names: the driver reads
> > > "st,click-threshold-{x,y,z}" but the old .txt documented them as
> > > "st,click-thresh-{x,y,z}".
> > >
> > > Validated with: make dt_binding_check DT_SCHEMA_FILES=Documentation/devicetree/bindings/iio/accel/st,lis302dl.yaml
> > >
> > > Signed-off-by: Md Shofiqul Islam <shofiqtest@gmail.com>
> >
> > Hi.
> >
> > So the conundrum here is whether we want to keep carrying this binding
> > as it dates to a previous era.
> >
> > The driver never made it to IIO and is still in drivers/misc.
> > The majority of what is the text document should never have been
> > in DT in the first place. I'll guess this dates all the way back
> > to the wild west days before we had regular binding review.
>
> I'd say this should be treated like a staging binding but for the fact
> that this has a user in arm. Problem of course is that it's probably
> impossible to get that board and so doing any rework is probably not
> realistic for this submitter?
> Is there a general policy for iio devices in misc? Do they get reworked
> to be moved?
It is tricky if we have upstream users because the ABI will change on them.
I'm not sure how easy this would be to add to the existing st sensors driver
as these are very early parts. If we could maybe we'd do so and just deal
with the mess of having to disable one or other driver.
My gut feeling here is ancient part, let it get dropped in a year or
two and not worry about adding support to a standard IIO driver unless
anyone actually has hardware and wants to do it.
>
> The user funnily enough has the binding's click-thresh properties:
> st,click-single-x;
> st,click-single-y;
> st,click-single-z;
> st,click-thresh-x = <10>;
> st,click-thresh-y = <10>;
> st,click-thresh-z = <10>;
> st,irq1-click;
> st,irq2-click;
> st,wakeup-x-lo;
> st,wakeup-x-hi;
> st,wakeup-y-lo;
> st,wakeup-y-hi;
> st,wakeup-z-lo;
> st,wakeup-z-hi;
> Dunno what that ultimately means in terms of which should be used
> though.
Set those as defaults in the driver if all upstream users have those
values and then drop reading them from dt?
^ permalink raw reply
* [PATCH/RFC 9/9] arm64: dts: renesas: ironhide: Switch to pure SCMI
From: Geert Uytterhoeven @ 2026-06-11 13:02 UTC (permalink / raw)
To: Sudeep Holla, Cristian Marussi, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Michael Turquette, Stephen Boyd, Brian Masney,
Ulf Hansson
Cc: arm-scmi, linux-arm-kernel, devicetree, linux-clk, linux-pm,
linux-renesas-soc, linux-kernel, Geert Uytterhoeven
In-Reply-To: <cover.1781171705.git.geert+renesas@glider.be>
Switch from CPG/MDLC remapping to pure SCMI:
- Add SCMI IDs for selected devices, supporting SCP FW SDK v4.28,
v4.31, and v4.32,
- Enable SCMI clock domain support,
- Replace clocks, power-domains, and resets properties by pure SCMI
references.
Note that the user must uncomment the line that defines
R_CAR_X5H_SCP_FW_SDK_VERSION to the SCP FW SDK version being used.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
This patch is included as a PoC.
This fails to apply, as the SCMI protocol subnodes are not added in this
series.
---
.../boot/dts/renesas/r8a78000-ironhide.dts | 44 +++++++++++++++++++
1 file changed, 44 insertions(+)
diff --git a/arch/arm64/boot/dts/renesas/r8a78000-ironhide.dts b/arch/arm64/boot/dts/renesas/r8a78000-ironhide.dts
index 00b5a010b7247722..f4093c359b21379e 100644
--- a/arch/arm64/boot/dts/renesas/r8a78000-ironhide.dts
+++ b/arch/arm64/boot/dts/renesas/r8a78000-ironhide.dts
@@ -9,6 +9,45 @@
#include <dt-bindings/soc/renesas,r8a78000-mfis.h>
#include "r8a78000.dtsi"
+#define V4_28 4028
+#define V4_31 4031 // Supports v4.31 and v4.32
+
+//#define R_CAR_X5H_SCP_FW_SDK_VERSION V4_28
+#define R_CAR_X5H_SCP_FW_SDK_VERSION V4_31
+
+#if R_CAR_X5H_SCP_FW_SDK_VERSION == V4_28
+
+#define CLK_SGD4_PERW_BUS 1661
+#define MDLC_HSCIF0 228
+#define MDLC_HSCIF1 229
+#define MDLC_SCIF0 209
+#define MDLC_SCIF1 210
+#define MDLC_UFS1 203
+#define RESET_HSCIF0 228
+#define RESET_HSCIF1 229
+#define RESET_SCIF0 209
+#define RESET_SCIF1 210
+#define RESET_UFS1 203
+
+#elif R_CAR_X5H_SCP_FW_SDK_VERSION == V4_31
+
+#define CLK_SGD4_PERW_BUS 1657
+#define MDLC_HSCIF0 224
+#define MDLC_HSCIF1 225
+#define MDLC_SCIF0 205
+#define MDLC_SCIF1 206
+#define MDLC_UFS1 199
+#define RESET_HSCIF0 224
+#define RESET_HSCIF1 225
+#define RESET_SCIF0 205
+#define RESET_SCIF1 206
+#define RESET_UFS1 199
+
+#endif
+
+#define PD_APL 257
+#define PD_UFS1 13
+
/ {
model = "Renesas Ironhide board based on r8a78000";
compatible = "renesas,ironhide", "renesas,r8a78000";
@@ -35,6 +74,7 @@ scmi: scmi {
scmi_devpd: protocol@11 {
reg = <0x11>;
#power-domain-cells = <1>;
+ arm,clock-domain = <&scmi_clk>;
};
scmi_sys: protocol@12 {
@@ -138,6 +178,10 @@ &extalr_clk {
};
&hscif0 {
+ clocks = <&scmi_clk MDLC_HSCIF0>, <&scmi_clk CLK_SGD4_PERW_BUS>,
+ <&scif_clk>;
+ power-domains = <&scmi_devpd PD_APL>;
+ resets = <&scmi_reset RESET_HSCIF0>;
uart-has-rtscts;
status = "okay";
};
--
2.43.0
^ permalink raw reply related
* [PATCH/RFC 8/9] firmware: arm_scmi: quirk: Handle power management clocks on R-Car X5H
From: Geert Uytterhoeven @ 2026-06-11 13:02 UTC (permalink / raw)
To: Sudeep Holla, Cristian Marussi, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Michael Turquette, Stephen Boyd, Brian Masney,
Ulf Hansson
Cc: arm-scmi, linux-arm-kernel, devicetree, linux-clk, linux-pm,
linux-renesas-soc, linux-kernel, Geert Uytterhoeven
In-Reply-To: <cover.1781171705.git.geert+renesas@glider.be>
On Renesas R-Car X5H, power management of on-SoC modules is handled
through two methods: module power control and module clock gating. The
former is exposed as an SCMI power domain, the latter as an SCMI clock.
Currently the SCMI clock protocol does not support advertizing
power-management clocks yet. Add quirks to mark all module clocks
suitable for power management, reusing the existing clock_rcar_x5h_4_28
and clock_rcar_x5h_4_31 quirk keys.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
This patch is included as a PoC.
This does not build as the quirk keys are not added in this series.
---
drivers/firmware/arm_scmi/clock.c | 15 +++++++++++++++
1 file changed, 15 insertions(+)
diff --git a/drivers/firmware/arm_scmi/clock.c b/drivers/firmware/arm_scmi/clock.c
index 42e666a628c732e5..c2648f9f283f2488 100644
--- a/drivers/firmware/arm_scmi/clock.c
+++ b/drivers/firmware/arm_scmi/clock.c
@@ -355,6 +355,18 @@ scmi_clock_get_permissions(const struct scmi_protocol_handle *ph, u32 clk_id,
return ret;
}
+#define QUIRK_RCAR_X5H_4_28_PM_CLK \
+ ({ \
+ if (clk_id <= 818 /* Last MDLC clock MDLC_GPIODM3 */) \
+ clk->pm_clk = true; \
+ })
+
+#define QUIRK_RCAR_X5H_4_31_PM_CLK \
+ ({ \
+ if (clk_id <= 814 /* Last MDLC clock MDLC_GPIODM3 */) \
+ clk->pm_clk = true; \
+ })
+
static int scmi_clock_attributes_get(const struct scmi_protocol_handle *ph,
u32 clk_id, struct clock_info *cinfo)
{
@@ -410,6 +422,9 @@ static int scmi_clock_attributes_get(const struct scmi_protocol_handle *ph,
if (SUPPORTS_EXTENDED_CONFIG(attributes))
clk->extended_config = true;
}
+
+ SCMI_QUIRK(clock_rcar_x5h_4_28, QUIRK_RCAR_X5H_4_28_PM_CLK);
+ SCMI_QUIRK(clock_rcar_x5h_4_31, QUIRK_RCAR_X5H_4_31_PM_CLK);
}
return ret;
--
2.43.0
^ permalink raw reply related
* [PATCH/RFC 7/9] pmdomain: arm: scmi: Add clock domain support
From: Geert Uytterhoeven @ 2026-06-11 13:02 UTC (permalink / raw)
To: Sudeep Holla, Cristian Marussi, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Michael Turquette, Stephen Boyd, Brian Masney,
Ulf Hansson
Cc: arm-scmi, linux-arm-kernel, devicetree, linux-clk, linux-pm,
linux-renesas-soc, linux-kernel, Geert Uytterhoeven
In-Reply-To: <cover.1781171705.git.geert+renesas@glider.be>
PM domain consumer devices may also part of a clock domain.
Add support for managing power management clocks in a clock domain
through Runtime PM.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
drivers/pmdomain/arm/Kconfig | 1 +
drivers/pmdomain/arm/scmi_pm_domain.c | 81 ++++++++++++++++++++++++++-
2 files changed, 81 insertions(+), 1 deletion(-)
diff --git a/drivers/pmdomain/arm/Kconfig b/drivers/pmdomain/arm/Kconfig
index afed10d382ad7f66..11c4db47c1eadab0 100644
--- a/drivers/pmdomain/arm/Kconfig
+++ b/drivers/pmdomain/arm/Kconfig
@@ -14,6 +14,7 @@ config ARM_SCMI_PERF_DOMAIN
config ARM_SCMI_POWER_DOMAIN
tristate "SCMI power domain driver"
depends on ARM_SCMI_PROTOCOL || (COMPILE_TEST && OF)
+ depends on COMMON_CLK_SCMI || !COMMON_CLK_SCMI
default ARM_SCMI_PROTOCOL
select PM_GENERIC_DOMAINS if PM
help
diff --git a/drivers/pmdomain/arm/scmi_pm_domain.c b/drivers/pmdomain/arm/scmi_pm_domain.c
index 8e67f971c707e121..838917d3b236e3aa 100644
--- a/drivers/pmdomain/arm/scmi_pm_domain.c
+++ b/drivers/pmdomain/arm/scmi_pm_domain.c
@@ -5,9 +5,12 @@
* Copyright (C) 2018-2021 ARM Ltd.
*/
+#include <linux/clk.h>
+#include <linux/clk/scmi.h>
#include <linux/err.h>
#include <linux/io.h>
#include <linux/module.h>
+#include <linux/pm_clock.h>
#include <linux/pm_domain.h>
#include <linux/scmi_protocol.h>
@@ -16,6 +19,7 @@ static const struct scmi_power_proto_ops *power_ops;
struct scmi_pm_domain {
struct generic_pm_domain genpd;
const struct scmi_protocol_handle *ph;
+ struct device_node *clock_domain;
const char *name;
u32 domain;
};
@@ -39,6 +43,67 @@ static int scmi_pd_power_off(struct generic_pm_domain *domain)
return scmi_pd_power(domain, SCMI_POWER_STATE_GENERIC_OFF);
}
+static int scmi_pd_attach_dev(struct generic_pm_domain *domain,
+ struct device *dev)
+{
+ struct scmi_pm_domain *pd = to_scmi_pd(domain);
+ struct device_node *np = dev->of_node;
+ struct of_phandle_args clkspec;
+ bool once = true;
+ struct clk *clk;
+ int ret;
+
+ for (int i = 0;
+ !of_parse_phandle_with_args(np, "clocks", "#clock-cells", i, &clkspec);
+ i++) {
+ if (clkspec.np != pd->clock_domain || clkspec.args_count != 1) {
+ of_node_put(clkspec.np);
+ continue;
+ }
+
+ clk = of_clk_get_from_provider(&clkspec);
+ of_node_put(clkspec.np);
+ if (!clk)
+ continue;
+
+ if (IS_ERR(clk)) {
+ ret = PTR_ERR(clk);
+ clk = NULL;
+ goto fail;
+ }
+
+ if (!scmi_clk_is_pm_clk(clk)) {
+ clk_put(clk);
+ continue;
+ }
+
+ if (once) {
+ once = false;
+ ret = pm_clk_create(dev);
+ if (ret)
+ goto fail;
+ }
+
+ ret = pm_clk_add_clk(dev, clk);
+ if (ret)
+ goto fail;
+ }
+
+ return 0;
+
+fail:
+ pm_clk_destroy(dev);
+ clk_put(clk);
+ return ret;
+}
+
+static void scmi_pd_detach_dev(struct generic_pm_domain *domain,
+ struct device *dev)
+{
+ if (!pm_clk_no_clocks(dev))
+ pm_clk_destroy(dev);
+}
+
static int scmi_pm_domain_probe(struct scmi_device *sdev)
{
int num_domains, i, ret;
@@ -48,6 +113,7 @@ static int scmi_pm_domain_probe(struct scmi_device *sdev)
struct genpd_onecell_data *scmi_pd_data;
struct generic_pm_domain **domains;
const struct scmi_handle *handle = sdev->handle;
+ struct device_node *clock_domain;
struct scmi_protocol_handle *ph;
if (!handle)
@@ -75,6 +141,8 @@ static int scmi_pm_domain_probe(struct scmi_device *sdev)
if (!domains)
return -ENOMEM;
+ clock_domain = of_parse_phandle(np, "arm,clock-domain", 0);
+
for (i = 0; i < num_domains; i++, scmi_pd++) {
const struct scmi_power_domain_info *info;
u32 state;
@@ -106,6 +174,12 @@ static int scmi_pm_domain_probe(struct scmi_device *sdev)
scmi_pd->genpd.power_on = scmi_pd_power_on;
scmi_pd->genpd.flags = GENPD_FLAG_ACTIVE_WAKEUP |
info->genpd_flags;
+ if (clock_domain) {
+ scmi_pd->clock_domain = of_node_get(clock_domain);
+ scmi_pd->genpd.attach_dev = scmi_pd_attach_dev;
+ scmi_pd->genpd.detach_dev = scmi_pd_detach_dev;
+ scmi_pd->genpd.flags |= GENPD_FLAG_PM_CLK;
+ }
pm_genpd_init(&scmi_pd->genpd, NULL,
state == SCMI_POWER_STATE_GENERIC_OFF);
@@ -113,6 +187,8 @@ static int scmi_pm_domain_probe(struct scmi_device *sdev)
domains[i] = &scmi_pd->genpd;
}
+ of_node_put(clock_domain);
+
scmi_pd_data->domains = domains;
scmi_pd_data->num_domains = num_domains;
@@ -134,8 +210,10 @@ static int scmi_pm_domain_probe(struct scmi_device *sdev)
return 0;
err_rm_genpds:
- for (i = num_domains - 1; i >= 0; i--)
+ for (i = num_domains - 1; i >= 0; i--) {
pm_genpd_remove(domains[i]);
+ of_node_put(to_scmi_pd(domains[i])->clock_domain);
+ }
return ret;
}
@@ -158,6 +236,7 @@ static void scmi_pm_domain_remove(struct scmi_device *sdev)
if (!scmi_pd_data->domains[i])
continue;
pm_genpd_remove(scmi_pd_data->domains[i]);
+ of_node_put(to_scmi_pd(scmi_pd_data->domains[i])->clock_domain);
}
}
--
2.43.0
^ permalink raw reply related
* [PATCH/RFC 6/9] dt-bindings: firmware: arm,scmi: Document arm,clock-domain
From: Geert Uytterhoeven @ 2026-06-11 13:02 UTC (permalink / raw)
To: Sudeep Holla, Cristian Marussi, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Michael Turquette, Stephen Boyd, Brian Masney,
Ulf Hansson
Cc: arm-scmi, linux-arm-kernel, devicetree, linux-clk, linux-pm,
linux-renesas-soc, linux-kernel, Geert Uytterhoeven
In-Reply-To: <cover.1781171705.git.geert+renesas@glider.be>
Power management of on-SoC modules is typically handled through two
methods: module power control and module clock gating. The former is
exposed as an SCMI power domain, the latter as an SCMI clock.
Document the new arm,clock-domain property, to link the SCMI power domain
provider to the clock domain provider that is responsible for module
clock gating.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
Documentation/devicetree/bindings/firmware/arm,scmi.yaml | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/Documentation/devicetree/bindings/firmware/arm,scmi.yaml b/Documentation/devicetree/bindings/firmware/arm,scmi.yaml
index d06cca9273c483c0..18e4da3884c4c12e 100644
--- a/Documentation/devicetree/bindings/firmware/arm,scmi.yaml
+++ b/Documentation/devicetree/bindings/firmware/arm,scmi.yaml
@@ -174,6 +174,13 @@ properties:
'#power-domain-cells':
const: 1
+ arm,clock-domain:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description:
+ When PM domain consumer devices are also part of a clock domain, this
+ property should be a reference to the SCMI clock protocol node for
+ the power management clocks in the clock domain.
+
required:
- '#power-domain-cells'
--
2.43.0
^ permalink raw reply related
* [PATCH/RFC 5/9] clk: scmi: Add scmi_clk_is_pm_clk()
From: Geert Uytterhoeven @ 2026-06-11 13:02 UTC (permalink / raw)
To: Sudeep Holla, Cristian Marussi, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Michael Turquette, Stephen Boyd, Brian Masney,
Ulf Hansson
Cc: arm-scmi, linux-arm-kernel, devicetree, linux-clk, linux-pm,
linux-renesas-soc, linux-kernel, Geert Uytterhoeven
In-Reply-To: <cover.1781171705.git.geert+renesas@glider.be>
Add a helper for querying if an SCMI clock can be used for
power-management.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
drivers/clk/clk-scmi.c | 9 +++++++++
include/linux/clk/scmi.h | 17 +++++++++++++++++
2 files changed, 26 insertions(+)
create mode 100644 include/linux/clk/scmi.h
diff --git a/drivers/clk/clk-scmi.c b/drivers/clk/clk-scmi.c
index 7c562559ad8bb47f..20e6da1859290b75 100644
--- a/drivers/clk/clk-scmi.c
+++ b/drivers/clk/clk-scmi.c
@@ -7,6 +7,7 @@
#include <linux/bits.h>
#include <linux/clk-provider.h>
+#include <linux/clk/scmi.h>
#include <linux/device.h>
#include <linux/err.h>
#include <linux/of.h>
@@ -364,6 +365,14 @@ scmi_clk_ops_select(struct scmi_clk *sclk, bool atomic_capable,
return ops;
}
+bool scmi_clk_is_pm_clk(struct clk *clk)
+{
+ struct clk_hw *hw = __clk_get_hw(clk);
+
+ return hw && to_scmi_clk(hw)->info->pm_clk;
+}
+EXPORT_SYMBOL_GPL(scmi_clk_is_pm_clk);
+
static int scmi_clocks_probe(struct scmi_device *sdev)
{
int idx, count, err;
diff --git a/include/linux/clk/scmi.h b/include/linux/clk/scmi.h
new file mode 100644
index 0000000000000000..12c338598d09296f
--- /dev/null
+++ b/include/linux/clk/scmi.h
@@ -0,0 +1,17 @@
+/* SPDX-License-Identifier: GPL-2.0+
+ */
+
+#ifndef __LINUX_CLK_SCMI_H_
+#define __LINUX_CLK_SCMI_H_
+
+#include <linux/types.h>
+
+struct clk;
+
+#if IS_ENABLED(CONFIG_COMMON_CLK_SCMI)
+bool scmi_clk_is_pm_clk(struct clk *clk);
+#else
+static inline bool scmi_clk_is_pm_clk(struct clk *clk) { return false; }
+#endif
+
+#endif /* __LINUX_CLK_SCMI_H_ */
--
2.43.0
^ permalink raw reply related
* [PATCH/RFC 4/9] firmware: arm_scmi: Add a flag for power-management clocks
From: Geert Uytterhoeven @ 2026-06-11 13:02 UTC (permalink / raw)
To: Sudeep Holla, Cristian Marussi, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Michael Turquette, Stephen Boyd, Brian Masney,
Ulf Hansson
Cc: arm-scmi, linux-arm-kernel, devicetree, linux-clk, linux-pm,
linux-renesas-soc, linux-kernel, Geert Uytterhoeven
In-Reply-To: <cover.1781171705.git.geert+renesas@glider.be>
Power management of on-SoC modules is typically handled through two
methods: module power control and module clock gating. The former is
exposed as an SCMI power domain, the latter as an SCMI clock.
Add a flag to indicate if a clock is intended for power-management of a
hardware module.
As the SCMI clock protocol does not support advertizing power-management
clocks yet, this flag can only be set by a quirk.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
include/linux/scmi_protocol.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/include/linux/scmi_protocol.h b/include/linux/scmi_protocol.h
index 1d55374bc8cdcc72..c98e0add25f0c6c6 100644
--- a/include/linux/scmi_protocol.h
+++ b/include/linux/scmi_protocol.h
@@ -55,6 +55,7 @@ struct scmi_clock_info {
bool rate_ctrl_forbidden;
bool parent_ctrl_forbidden;
bool extended_config;
+ bool pm_clk;
u64 min_rate;
u64 max_rate;
int num_parents;
--
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