[PATCH v8 00/10] Support ROHM BD79124 ADC

[PATCH v8 00/10] Support ROHM BD79124 ADC

[Matti Vaittinen]

[-- Attachment #1: Type: text/plain, Size: 5824 bytes --]

Support ROHM BD79124 ADC.

This series adds also couple of IIO ADC helper functions for parsing the
channel information from the device tree. There are also new helpers
included for iterating and counting firmware child nodes with a specific
name.

Series does also convert couple of drivers to use these helpers. The
rzg2l_adc and the sun20i-gpadc are converted to use the new ADC helper.

The gianfar driver under net and the thp7312 under media/i2c are added as
first users of the newly added "named child node" -helpers.

There has been some discussion about how useful these ADC helpers are,
and whether they should support also differential and single ended channel
configurations. This version does not include support for those - with the
benefit of reduced complexity and easier to use API.

NOTE: Patches 4,5,9 and 10 are untested as I lack of relevant HW.
They have been compile tested only.

The ROHM BD79124 ADC itself is quite usual stuff. 12-bit, 8-channel ADC
with threshold monitoring.

Except that:
 - each ADC input pin can be configured as a general purpose output.
 - manually starting an ADC conversion and reading the result would
   require the I2C _master_ to do clock stretching(!) for the duration
   of the conversion... Let's just say this is not well supported.
 - IC supports 'autonomous measurement mode' and storing latest results
   to the result registers. This mode is used by the driver due to the
   "peculiar" I2C when doing manual reads.

Furthermore, the ADC uses this continuous autonomous measuring,
and the IC keeps producing new 'out of window' IRQs if measurements are
out of window - the driver disables the event for 1 seconds when sending
it to user. This prevents generating storm of events

Revision history:

v7 => v8:
  property helpers:
    - Fix the example in fwnode_get_named_child_node_count() documentation
      to use the fwnode_get_named_child_node_count() and not the
      device_get_named_child_node_count()
    - Fix the rest of the new macro's indentiations
  adc helpers:
    - Treat 0 ADC channels as an error in
      devm_iio_adc_device_alloc_chaninfo_se().
  rzg2l_adc / sun20i-gpadc:
    - Drop zero channels check from the ADC drivers using
      devm_iio_adc_device_alloc_chaninfo_se()
  BD79124:
    - Use unsigned for regmap values
    - Commit message fine tuning
    - Check devm_mutex_init() return value
    - Handle 'ALL pins as ADC or GPO' cleanly in BD79124 driver
    - BD79124 styling / typofixes

v6 => v7:
 - Inline device_get_named_child_node_count()
 - Fix kernel-doc for fwnode_get_named_child_node_count()
 - Minor styling fixes
 More accurate changelog in individual patches.

v5 => v6:
 - Drop applied patch
 - Add *_for_each_named_child_* iterators
 - Add a patch converting the thp7312 driver to use the new helper
 - Styling and minor things pointed by reviewers

v4 => v5: Fixes as per various review comments. Most notably:
 - Drop the patch making the TI's ADC driver to respect device tree.
 - Add (RFC) patch converting gianfar driver to use new name child-node
   counting API as suggested by Andy.
 - Add fwnode_get_child_node_count_named() as suggested by Rob.
 - rebase to v6.14-rc5
 More accurate changelog in individual patches.

v3 => v4:
 - Drop the ADC helper support for differential channels
 - Drop the ADC helper for getting only channel IDs by fwnode.
 - "Promote" the function counting the number of child nodes with a
   specific name to the property.h (As suggested by Jonathan).
 - Add ADC helpers to a namespace.
 - Rebase on v6.14-rc3
 - More minor changes described in individual patches.

v2 => v3:
 - Restrict BD79124 channel numbers as suggested by Conor and add
   Conor's Reviewed-by tag.
 - Support differential and single-ended inputs
 - Convert couple of existing drivers to use the added ADC helpers
 - Minor fixes based on reviews
Link to v2:
https://lore.kernel.org/all/cover.1738761899.git.mazziesaccount@gmail.com/

RFC v1 => v2:
 - Drop MFD and pinmux.
 - Automatically re-enable events after 1 second.
 - Export fwnode parsing helpers for finding the ADC channels.

---

Matti Vaittinen (10):
  dt-bindings: ROHM BD79124 ADC/GPO
  property: Add functions to iterate named child
  iio: adc: add helpers for parsing ADC nodes
  iio: adc: rzg2l_adc: Use adc-helpers
  iio: adc: sun20i-gpadc: Use adc-helpers
  iio: adc: Support ROHM BD79124 ADC
  MAINTAINERS: Add IIO ADC helpers
  MAINTAINERS: Add ROHM BD79124 ADC/GPO
  net: gianfar: Use device_get_child_node_count_named()
  media: thp7312: Use helper for iterating named child nodes

 .../bindings/iio/adc/rohm,bd79124.yaml        |  114 ++
 MAINTAINERS                                   |   12 +
 drivers/base/property.c                       |   27 +
 drivers/iio/adc/Kconfig                       |   17 +
 drivers/iio/adc/Makefile                      |    3 +
 drivers/iio/adc/industrialio-adc.c            |   82 ++
 drivers/iio/adc/rohm-bd79124.c                | 1138 +++++++++++++++++
 drivers/iio/adc/rzg2l_adc.c                   |   39 +-
 drivers/iio/adc/sun20i-gpadc-iio.c            |   39 +-
 drivers/media/i2c/thp7312.c                   |    8 +-
 drivers/net/ethernet/freescale/gianfar.c      |   17 +-
 include/linux/iio/adc-helpers.h               |   27 +
 include/linux/property.h                      |   24 +
 13 files changed, 1481 insertions(+), 66 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/iio/adc/rohm,bd79124.yaml
 create mode 100644 drivers/iio/adc/industrialio-adc.c
 create mode 100644 drivers/iio/adc/rohm-bd79124.c
 create mode 100644 include/linux/iio/adc-helpers.h


base-commit: 7eb172143d5508b4da468ed59ee857c6e5e01da6
-- 
2.48.1


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

[PATCH v8 01/10] dt-bindings: ROHM BD79124 ADC/GPO

[Matti Vaittinen]

[-- Attachment #1: Type: text/plain, Size: 3475 bytes --]

Add binding document for the ROHM BD79124 ADC / GPO.

ROHM BD79124 is a 8-channel, 12-bit ADC. The input pins can also be used
as general purpose outputs.

Signed-off-by: Matti Vaittinen <mazziesaccount@gmail.com>
Reviewed-by: Conor Dooley <conor.dooley@microchip.com>
---
Revision history:
v3 =>
 - No changes
v2 => v3:
 - Restrict channel numbers to 0-7 as suggested by Conor
RFC v1 => v2:
 - drop MFD and represent directly as ADC
 - drop pinmux and treat all non ADC channel pins as GPOs
---
 .../bindings/iio/adc/rohm,bd79124.yaml        | 114 ++++++++++++++++++
 1 file changed, 114 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/iio/adc/rohm,bd79124.yaml

diff --git a/Documentation/devicetree/bindings/iio/adc/rohm,bd79124.yaml b/Documentation/devicetree/bindings/iio/adc/rohm,bd79124.yaml
new file mode 100644
index 000000000000..503285823376
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/adc/rohm,bd79124.yaml
@@ -0,0 +1,114 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/iio/adc/rohm,bd79124.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: ROHM BD79124 ADC/GPO
+
+maintainers:
+  - Matti Vaittinen <mazziesaccount@gmail.com>
+
+description: |
+  The ROHM BD79124 is a 12-bit, 8-channel, SAR ADC. The ADC supports
+  an automatic measurement mode, with an alarm interrupt for out-of-window
+  measurements. ADC input pins can be also configured as general purpose
+  outputs.
+
+properties:
+  compatible:
+    const: rohm,bd79124
+
+  reg:
+    description:
+      I2C slave address.
+    maxItems: 1
+
+  interrupts:
+    maxItems: 1
+
+  gpio-controller: true
+
+  "#gpio-cells":
+    const: 1
+    description:
+      The pin number.
+
+  vdd-supply: true
+
+  iovdd-supply: true
+
+  "#address-cells":
+    const: 1
+
+  "#size-cells":
+    const: 0
+
+patternProperties:
+  "^channel@[0-7]+$":
+    type: object
+    $ref: /schemas/iio/adc/adc.yaml#
+    description: Represents ADC channel.
+
+    properties:
+      reg:
+        description: AIN pin number
+        minimum: 0
+        maximum: 7
+
+    required:
+      - reg
+
+    additionalProperties: false
+
+required:
+  - compatible
+  - reg
+  - iovdd-supply
+  - vdd-supply
+
+additionalProperties: false
+
+examples:
+  - |
+    #include <dt-bindings/interrupt-controller/irq.h>
+    #include <dt-bindings/leds/common.h>
+    i2c {
+        #address-cells = <1>;
+        #size-cells = <0>;
+        adc: adc@10 {
+            compatible = "rohm,bd79124";
+            reg = <0x10>;
+
+            interrupt-parent = <&gpio1>;
+            interrupts = <29 8>;
+
+            vdd-supply = <&dummyreg>;
+            iovdd-supply = <&dummyreg>;
+
+            #address-cells = <1>;
+            #size-cells = <0>;
+
+            channel@0 {
+                reg = <0>;
+            };
+            channel@1 {
+                reg = <1>;
+            };
+            channel@2 {
+                reg = <2>;
+            };
+            channel@3 {
+                reg = <3>;
+            };
+            channel@4 {
+                reg = <4>;
+            };
+            channel@5 {
+                reg = <5>;
+            };
+            channel@6 {
+                reg = <6>;
+            };
+        };
+    };
-- 
2.48.1


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

[PATCH v8 02/10] property: Add functions to iterate named child

[Matti Vaittinen]

[-- Attachment #1: Type: text/plain, Size: 5895 bytes --]

There are a few use-cases where child nodes with a specific name need to
be parsed. Code like:

fwnode_for_each_child_node()
	if (fwnode_name_eq())
		...

can be found from a various drivers/subsystems. Adding a macro for this
can simplify things a bit.

In a few cases the data from the found nodes is later added to an array,
which is allocated based on the number of found nodes. One example of
such use is the IIO subsystem's ADC channel nodes, where the relevant
nodes are named as channel[@N].

Add helpers for iterating and counting device's sub-nodes with certain
name instead of open-coding this in every user.

Suggested-by: Jonathan Cameron <jic23@kernel.org>
Signed-off-by: Matti Vaittinen <mazziesaccount@gmail.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: Marcelo Schmitt <marcelo.schmitt1@gmail.com>
---
Revision history:
v7 => v8:
 - Fix the example in fwnode_get_named_child_node_count() documentation
   to use the fwnode_get_named_child_node_count() and not the
   device_get_named_child_node_count()
 - Fix the rest of the new macro's indentiations
v6 => v7:
 - Improve kerneldoc
 - Inline device_get_named_child_node_count() and change it to call
   fwnode_get_named_child_node_count() inside
 - Fix indentiation of the new macros
v5 => v6:
 - Add helpers to also iterate through the nodes.
v4 => v5:
 - Use given name instead of string 'channel' when counting the nodes
 - Add also fwnode_get_child_node_count_named() as suggested by Rob.
v3 => v4:
 - New patch as suggested by Jonathan, see discussion in:
https://lore.kernel.org/lkml/20250223161338.5c896280@jic23-huawei/
---
 drivers/base/property.c  | 27 +++++++++++++++++++++++++++
 include/linux/property.h | 24 ++++++++++++++++++++++++
 2 files changed, 51 insertions(+)

diff --git a/drivers/base/property.c b/drivers/base/property.c
index c1392743df9c..f42f32ff45fc 100644
--- a/drivers/base/property.c
+++ b/drivers/base/property.c
@@ -945,6 +945,33 @@ unsigned int device_get_child_node_count(const struct device *dev)
 }
 EXPORT_SYMBOL_GPL(device_get_child_node_count);
 
+/**
+ * fwnode_get_named_child_node_count - number of child nodes with given name
+ * @fwnode: Node which child nodes are counted.
+ * @name: String to match child node name against.
+ *
+ * Scan child nodes and count all the nodes with a specific name. Potential
+ * 'number' -ending after the 'at sign' for scanned names is ignored.
+ * E.g.::
+ *   fwnode_get_named_child_node_count(fwnode, "channel");
+ * would match all the nodes::
+ *   channel { }, channel@0 {}, channel@0xabba {}...
+ *
+ * Return: the number of child nodes with a matching name for a given device.
+ */
+unsigned int fwnode_get_named_child_node_count(const struct fwnode_handle *fwnode,
+					       const char *name)
+{
+	struct fwnode_handle *child;
+	unsigned int count = 0;
+
+	fwnode_for_each_named_child_node(fwnode, child, name)
+		count++;
+
+	return count;
+}
+EXPORT_SYMBOL_GPL(fwnode_get_named_child_node_count);
+
 bool device_dma_supported(const struct device *dev)
 {
 	return fwnode_call_bool_op(dev_fwnode(dev), device_dma_supported);
diff --git a/include/linux/property.h b/include/linux/property.h
index e214ecd241eb..a1856e6b714c 100644
--- a/include/linux/property.h
+++ b/include/linux/property.h
@@ -167,10 +167,18 @@ struct fwnode_handle *fwnode_get_next_available_child_node(
 	for (child = fwnode_get_next_child_node(fwnode, NULL); child;	\
 	     child = fwnode_get_next_child_node(fwnode, child))
 
+#define fwnode_for_each_named_child_node(fwnode, child, name)		\
+	fwnode_for_each_child_node(fwnode, child)			\
+		if (!fwnode_name_eq(child, name)) { } else
+
 #define fwnode_for_each_available_child_node(fwnode, child)		       \
 	for (child = fwnode_get_next_available_child_node(fwnode, NULL); child;\
 	     child = fwnode_get_next_available_child_node(fwnode, child))
 
+#define fwnode_for_each_available_named_child_node(fwnode, child, name)	\
+	fwnode_for_each_available_child_node(fwnode, child)		\
+		if (!fwnode_name_eq(child, name)) { } else
+
 struct fwnode_handle *device_get_next_child_node(const struct device *dev,
 						 struct fwnode_handle *child);
 
@@ -178,11 +186,19 @@ struct fwnode_handle *device_get_next_child_node(const struct device *dev,
 	for (child = device_get_next_child_node(dev, NULL); child;	\
 	     child = device_get_next_child_node(dev, child))
 
+#define device_for_each_named_child_node(dev, child, name)		\
+	device_for_each_child_node(dev, child)				\
+		if (!fwnode_name_eq(child, name)) { } else
+
 #define device_for_each_child_node_scoped(dev, child)			\
 	for (struct fwnode_handle *child __free(fwnode_handle) =	\
 		device_get_next_child_node(dev, NULL);			\
 	     child; child = device_get_next_child_node(dev, child))
 
+#define device_for_each_named_child_node_scoped(dev, child, name)	\
+	device_for_each_child_node_scoped(dev, child)			\
+		if (!fwnode_name_eq(child, name)) { } else
+
 struct fwnode_handle *fwnode_get_named_child_node(const struct fwnode_handle *fwnode,
 						  const char *childname);
 struct fwnode_handle *device_get_named_child_node(const struct device *dev,
@@ -210,6 +226,14 @@ int fwnode_irq_get_byname(const struct fwnode_handle *fwnode, const char *name);
 
 unsigned int device_get_child_node_count(const struct device *dev);
 
+unsigned int fwnode_get_named_child_node_count(const struct fwnode_handle *fwnode,
+					       const char *name);
+static inline unsigned int device_get_named_child_node_count(const struct device *dev,
+							     const char *name)
+{
+	return fwnode_get_named_child_node_count(dev_fwnode(dev), name);
+}
+
 static inline int device_property_read_u8(const struct device *dev,
 					  const char *propname, u8 *val)
 {
-- 
2.48.1


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [PATCH v8 02/10] property: Add functions to iterate named child

[Sakari Ailus]

Moi,

On Mon, Mar 17, 2025 at 05:50:38PM +0200, Matti Vaittinen wrote:
> There are a few use-cases where child nodes with a specific name need to
> be parsed. Code like:
> 
> fwnode_for_each_child_node()
> 	if (fwnode_name_eq())
> 		...
> 
> can be found from a various drivers/subsystems. Adding a macro for this
> can simplify things a bit.
> 
> In a few cases the data from the found nodes is later added to an array,
> which is allocated based on the number of found nodes. One example of
> such use is the IIO subsystem's ADC channel nodes, where the relevant
> nodes are named as channel[@N].
> 
> Add helpers for iterating and counting device's sub-nodes with certain
> name instead of open-coding this in every user.
> 
> Suggested-by: Jonathan Cameron <jic23@kernel.org>
> Signed-off-by: Matti Vaittinen <mazziesaccount@gmail.com>
> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
> Reviewed-by: Marcelo Schmitt <marcelo.schmitt1@gmail.com>
> ---
> Revision history:
> v7 => v8:
>  - Fix the example in fwnode_get_named_child_node_count() documentation
>    to use the fwnode_get_named_child_node_count() and not the
>    device_get_named_child_node_count()
>  - Fix the rest of the new macro's indentiations
> v6 => v7:
>  - Improve kerneldoc
>  - Inline device_get_named_child_node_count() and change it to call
>    fwnode_get_named_child_node_count() inside
>  - Fix indentiation of the new macros
> v5 => v6:
>  - Add helpers to also iterate through the nodes.
> v4 => v5:
>  - Use given name instead of string 'channel' when counting the nodes
>  - Add also fwnode_get_child_node_count_named() as suggested by Rob.
> v3 => v4:
>  - New patch as suggested by Jonathan, see discussion in:
> https://lore.kernel.org/lkml/20250223161338.5c896280@jic23-huawei/
> ---
>  drivers/base/property.c  | 27 +++++++++++++++++++++++++++
>  include/linux/property.h | 24 ++++++++++++++++++++++++
>  2 files changed, 51 insertions(+)
> 
> diff --git a/drivers/base/property.c b/drivers/base/property.c
> index c1392743df9c..f42f32ff45fc 100644
> --- a/drivers/base/property.c
> +++ b/drivers/base/property.c
> @@ -945,6 +945,33 @@ unsigned int device_get_child_node_count(const struct device *dev)
>  }
>  EXPORT_SYMBOL_GPL(device_get_child_node_count);
>  
> +/**
> + * fwnode_get_named_child_node_count - number of child nodes with given name
> + * @fwnode: Node which child nodes are counted.
> + * @name: String to match child node name against.
> + *
> + * Scan child nodes and count all the nodes with a specific name. Potential
> + * 'number' -ending after the 'at sign' for scanned names is ignored.
> + * E.g.::
> + *   fwnode_get_named_child_node_count(fwnode, "channel");
> + * would match all the nodes::
> + *   channel { }, channel@0 {}, channel@0xabba {}...
> + *
> + * Return: the number of child nodes with a matching name for a given device.
> + */
> +unsigned int fwnode_get_named_child_node_count(const struct fwnode_handle *fwnode,
> +					       const char *name)
> +{
> +	struct fwnode_handle *child;
> +	unsigned int count = 0;
> +
> +	fwnode_for_each_named_child_node(fwnode, child, name)
> +		count++;
> +
> +	return count;
> +}
> +EXPORT_SYMBOL_GPL(fwnode_get_named_child_node_count);
> +
>  bool device_dma_supported(const struct device *dev)
>  {
>  	return fwnode_call_bool_op(dev_fwnode(dev), device_dma_supported);
> diff --git a/include/linux/property.h b/include/linux/property.h
> index e214ecd241eb..a1856e6b714c 100644
> --- a/include/linux/property.h
> +++ b/include/linux/property.h
> @@ -167,10 +167,18 @@ struct fwnode_handle *fwnode_get_next_available_child_node(
>  	for (child = fwnode_get_next_child_node(fwnode, NULL); child;	\
>  	     child = fwnode_get_next_child_node(fwnode, child))
>  
> +#define fwnode_for_each_named_child_node(fwnode, child, name)		\
> +	fwnode_for_each_child_node(fwnode, child)			\
> +		if (!fwnode_name_eq(child, name)) { } else
> +
>  #define fwnode_for_each_available_child_node(fwnode, child)		       \
>  	for (child = fwnode_get_next_available_child_node(fwnode, NULL); child;\
>  	     child = fwnode_get_next_available_child_node(fwnode, child))
>  
> +#define fwnode_for_each_available_named_child_node(fwnode, child, name)	\
> +	fwnode_for_each_available_child_node(fwnode, child)		\
> +		if (!fwnode_name_eq(child, name)) { } else
> +

OF only enumerates available nodes via the fwnode API, software nodes don't
have the concept but on ACPI I guess you could have a difference in nodes
where you have device sub-nodes that aren't available. Still, these ACPI
device nodes don't have meaningful names in this context (they're
4-character object names) so you wouldn't use them like this anyway.

So my question is: is it useful to provide this besides
fwnode_for_each_named_child_node(), given that both are effectively the
same?

>  struct fwnode_handle *device_get_next_child_node(const struct device *dev,
>  						 struct fwnode_handle *child);
>  
> @@ -178,11 +186,19 @@ struct fwnode_handle *device_get_next_child_node(const struct device *dev,
>  	for (child = device_get_next_child_node(dev, NULL); child;	\
>  	     child = device_get_next_child_node(dev, child))
>  
> +#define device_for_each_named_child_node(dev, child, name)		\
> +	device_for_each_child_node(dev, child)				\
> +		if (!fwnode_name_eq(child, name)) { } else
> +
>  #define device_for_each_child_node_scoped(dev, child)			\
>  	for (struct fwnode_handle *child __free(fwnode_handle) =	\
>  		device_get_next_child_node(dev, NULL);			\
>  	     child; child = device_get_next_child_node(dev, child))
>  
> +#define device_for_each_named_child_node_scoped(dev, child, name)	\
> +	device_for_each_child_node_scoped(dev, child)			\
> +		if (!fwnode_name_eq(child, name)) { } else
> +
>  struct fwnode_handle *fwnode_get_named_child_node(const struct fwnode_handle *fwnode,
>  						  const char *childname);
>  struct fwnode_handle *device_get_named_child_node(const struct device *dev,
> @@ -210,6 +226,14 @@ int fwnode_irq_get_byname(const struct fwnode_handle *fwnode, const char *name);
>  
>  unsigned int device_get_child_node_count(const struct device *dev);
>  
> +unsigned int fwnode_get_named_child_node_count(const struct fwnode_handle *fwnode,
> +					       const char *name);
> +static inline unsigned int device_get_named_child_node_count(const struct device *dev,
> +							     const char *name)
> +{
> +	return fwnode_get_named_child_node_count(dev_fwnode(dev), name);
> +}
> +
>  static inline int device_property_read_u8(const struct device *dev,
>  					  const char *propname, u8 *val)
>  {

-- 
Terveisin,

Sakari Ailus

Re: [PATCH v8 02/10] property: Add functions to iterate named child

[Matti Vaittinen]

Moro Sakari,

Thanks for the review.

On 18/03/2025 17:24, Sakari Ailus wrote:
> Moi,
> 
> On Mon, Mar 17, 2025 at 05:50:38PM +0200, Matti Vaittinen wrote:
>> There are a few use-cases where child nodes with a specific name need to
>> be parsed. Code like:
>>
>> fwnode_for_each_child_node()
>> 	if (fwnode_name_eq())
>> 		...
>>
>> can be found from a various drivers/subsystems. Adding a macro for this
>> can simplify things a bit.
>>
>> In a few cases the data from the found nodes is later added to an array,
>> which is allocated based on the number of found nodes. One example of
>> such use is the IIO subsystem's ADC channel nodes, where the relevant
>> nodes are named as channel[@N].
>>
>> Add helpers for iterating and counting device's sub-nodes with certain
>> name instead of open-coding this in every user.
>>
>> Suggested-by: Jonathan Cameron <jic23@kernel.org>
>> Signed-off-by: Matti Vaittinen <mazziesaccount@gmail.com>
>> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
>> Reviewed-by: Marcelo Schmitt <marcelo.schmitt1@gmail.com>
>> ---
>> Revision history:
>> v7 => v8:
>>   - Fix the example in fwnode_get_named_child_node_count() documentation
>>     to use the fwnode_get_named_child_node_count() and not the
>>     device_get_named_child_node_count()
>>   - Fix the rest of the new macro's indentiations
>> v6 => v7:
>>   - Improve kerneldoc
>>   - Inline device_get_named_child_node_count() and change it to call
>>     fwnode_get_named_child_node_count() inside
>>   - Fix indentiation of the new macros
>> v5 => v6:
>>   - Add helpers to also iterate through the nodes.
>> v4 => v5:
>>   - Use given name instead of string 'channel' when counting the nodes
>>   - Add also fwnode_get_child_node_count_named() as suggested by Rob.
>> v3 => v4:
>>   - New patch as suggested by Jonathan, see discussion in:
>> https://lore.kernel.org/lkml/20250223161338.5c896280@jic23-huawei/
>> ---
>>   drivers/base/property.c  | 27 +++++++++++++++++++++++++++
>>   include/linux/property.h | 24 ++++++++++++++++++++++++
>>   2 files changed, 51 insertions(+)
>>
>> diff --git a/drivers/base/property.c b/drivers/base/property.c
>> index c1392743df9c..f42f32ff45fc 100644
>> --- a/drivers/base/property.c
>> +++ b/drivers/base/property.c
>> @@ -945,6 +945,33 @@ unsigned int device_get_child_node_count(const struct device *dev)
>>   }
>>   EXPORT_SYMBOL_GPL(device_get_child_node_count);
>>   
>> +/**
>> + * fwnode_get_named_child_node_count - number of child nodes with given name
>> + * @fwnode: Node which child nodes are counted.
>> + * @name: String to match child node name against.
>> + *
>> + * Scan child nodes and count all the nodes with a specific name. Potential
>> + * 'number' -ending after the 'at sign' for scanned names is ignored.
>> + * E.g.::
>> + *   fwnode_get_named_child_node_count(fwnode, "channel");
>> + * would match all the nodes::
>> + *   channel { }, channel@0 {}, channel@0xabba {}...
>> + *
>> + * Return: the number of child nodes with a matching name for a given device.
>> + */
>> +unsigned int fwnode_get_named_child_node_count(const struct fwnode_handle *fwnode,
>> +					       const char *name)
>> +{
>> +	struct fwnode_handle *child;
>> +	unsigned int count = 0;
>> +
>> +	fwnode_for_each_named_child_node(fwnode, child, name)
>> +		count++;
>> +
>> +	return count;
>> +}
>> +EXPORT_SYMBOL_GPL(fwnode_get_named_child_node_count);
>> +
>>   bool device_dma_supported(const struct device *dev)
>>   {
>>   	return fwnode_call_bool_op(dev_fwnode(dev), device_dma_supported);
>> diff --git a/include/linux/property.h b/include/linux/property.h
>> index e214ecd241eb..a1856e6b714c 100644
>> --- a/include/linux/property.h
>> +++ b/include/linux/property.h
>> @@ -167,10 +167,18 @@ struct fwnode_handle *fwnode_get_next_available_child_node(
>>   	for (child = fwnode_get_next_child_node(fwnode, NULL); child;	\
>>   	     child = fwnode_get_next_child_node(fwnode, child))
>>   
>> +#define fwnode_for_each_named_child_node(fwnode, child, name)		\
>> +	fwnode_for_each_child_node(fwnode, child)			\
>> +		if (!fwnode_name_eq(child, name)) { } else
>> +
>>   #define fwnode_for_each_available_child_node(fwnode, child)		       \
>>   	for (child = fwnode_get_next_available_child_node(fwnode, NULL); child;\
>>   	     child = fwnode_get_next_available_child_node(fwnode, child))
>>   
>> +#define fwnode_for_each_available_named_child_node(fwnode, child, name)	\
>> +	fwnode_for_each_available_child_node(fwnode, child)		\
>> +		if (!fwnode_name_eq(child, name)) { } else
>> +
> 
> OF only enumerates available nodes via the fwnode API, software nodes don't
> have the concept but on ACPI I guess you could have a difference in nodes
> where you have device sub-nodes that aren't available. Still, these ACPI
> device nodes don't have meaningful names in this context (they're
> 4-character object names) so you wouldn't use them like this anyway.

I believe you have far better understanding on these concepts than I do. 
The reason behind adding fwnode_for_each_available_child_node() was the 
patch 10/10:

-	fwnode_for_each_available_child_node(sensors, node) {
-		if (fwnode_name_eq(node, "sensor")) {
-			if (!thp7312_sensor_parse_dt(thp7312, node))
-				num_sensors++;
-		}
+	fwnode_for_each_available_named_child_node(sensors, node, "sensor") {
+		if (!thp7312_sensor_parse_dt(thp7312, node))
+			num_sensors++;
  	}


> So my question is: is it useful to provide this besides
> fwnode_for_each_named_child_node(), given that both are effectively the
> same?

So, I suppose you're saying the existing thp7312 -driver has no real 
reason to use the 'fwnode_for_each_available_child_node()', but it could 
be using fwnode_for_each_child_node() instead?

If so, I am Ok with dropping the 
'fwnode_for_each_available_named_child_node()' and changing the 10/10 to:

-	fwnode_for_each_available_child_node(sensors, node) {
-		if (fwnode_name_eq(node, "sensor")) {
-			if (!thp7312_sensor_parse_dt(thp7312, node))
-				num_sensors++;
-		}
+	fwnode_for_each_named_child_node(sensors, node, "sensor") {
+		if (!thp7312_sensor_parse_dt(thp7312, node))
+			num_sensors++;
  	}

Do you think that'd be correct?

Yours,
	-- Matti

Re: [PATCH v8 02/10] property: Add functions to iterate named child

[Sakari Ailus]

Hei Matti,

On Wed, Mar 19, 2025 at 08:02:24AM +0200, Matti Vaittinen wrote:
> Moro Sakari,
> 
> Thanks for the review.
> 
> On 18/03/2025 17:24, Sakari Ailus wrote:
> > Moi,
> > 
> > On Mon, Mar 17, 2025 at 05:50:38PM +0200, Matti Vaittinen wrote:
> > > There are a few use-cases where child nodes with a specific name need to
> > > be parsed. Code like:
> > > 
> > > fwnode_for_each_child_node()
> > > 	if (fwnode_name_eq())
> > > 		...
> > > 
> > > can be found from a various drivers/subsystems. Adding a macro for this
> > > can simplify things a bit.
> > > 
> > > In a few cases the data from the found nodes is later added to an array,
> > > which is allocated based on the number of found nodes. One example of
> > > such use is the IIO subsystem's ADC channel nodes, where the relevant
> > > nodes are named as channel[@N].
> > > 
> > > Add helpers for iterating and counting device's sub-nodes with certain
> > > name instead of open-coding this in every user.
> > > 
> > > Suggested-by: Jonathan Cameron <jic23@kernel.org>
> > > Signed-off-by: Matti Vaittinen <mazziesaccount@gmail.com>
> > > Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
> > > Reviewed-by: Marcelo Schmitt <marcelo.schmitt1@gmail.com>
> > > ---
> > > Revision history:
> > > v7 => v8:
> > >   - Fix the example in fwnode_get_named_child_node_count() documentation
> > >     to use the fwnode_get_named_child_node_count() and not the
> > >     device_get_named_child_node_count()
> > >   - Fix the rest of the new macro's indentiations
> > > v6 => v7:
> > >   - Improve kerneldoc
> > >   - Inline device_get_named_child_node_count() and change it to call
> > >     fwnode_get_named_child_node_count() inside
> > >   - Fix indentiation of the new macros
> > > v5 => v6:
> > >   - Add helpers to also iterate through the nodes.
> > > v4 => v5:
> > >   - Use given name instead of string 'channel' when counting the nodes
> > >   - Add also fwnode_get_child_node_count_named() as suggested by Rob.
> > > v3 => v4:
> > >   - New patch as suggested by Jonathan, see discussion in:
> > > https://lore.kernel.org/lkml/20250223161338.5c896280@jic23-huawei/
> > > ---
> > >   drivers/base/property.c  | 27 +++++++++++++++++++++++++++
> > >   include/linux/property.h | 24 ++++++++++++++++++++++++
> > >   2 files changed, 51 insertions(+)
> > > 
> > > diff --git a/drivers/base/property.c b/drivers/base/property.c
> > > index c1392743df9c..f42f32ff45fc 100644
> > > --- a/drivers/base/property.c
> > > +++ b/drivers/base/property.c
> > > @@ -945,6 +945,33 @@ unsigned int device_get_child_node_count(const struct device *dev)
> > >   }
> > >   EXPORT_SYMBOL_GPL(device_get_child_node_count);
> > > +/**
> > > + * fwnode_get_named_child_node_count - number of child nodes with given name
> > > + * @fwnode: Node which child nodes are counted.
> > > + * @name: String to match child node name against.
> > > + *
> > > + * Scan child nodes and count all the nodes with a specific name. Potential
> > > + * 'number' -ending after the 'at sign' for scanned names is ignored.
> > > + * E.g.::
> > > + *   fwnode_get_named_child_node_count(fwnode, "channel");
> > > + * would match all the nodes::
> > > + *   channel { }, channel@0 {}, channel@0xabba {}...
> > > + *
> > > + * Return: the number of child nodes with a matching name for a given device.
> > > + */
> > > +unsigned int fwnode_get_named_child_node_count(const struct fwnode_handle *fwnode,
> > > +					       const char *name)
> > > +{
> > > +	struct fwnode_handle *child;
> > > +	unsigned int count = 0;
> > > +
> > > +	fwnode_for_each_named_child_node(fwnode, child, name)
> > > +		count++;
> > > +
> > > +	return count;
> > > +}
> > > +EXPORT_SYMBOL_GPL(fwnode_get_named_child_node_count);
> > > +
> > >   bool device_dma_supported(const struct device *dev)
> > >   {
> > >   	return fwnode_call_bool_op(dev_fwnode(dev), device_dma_supported);
> > > diff --git a/include/linux/property.h b/include/linux/property.h
> > > index e214ecd241eb..a1856e6b714c 100644
> > > --- a/include/linux/property.h
> > > +++ b/include/linux/property.h
> > > @@ -167,10 +167,18 @@ struct fwnode_handle *fwnode_get_next_available_child_node(
> > >   	for (child = fwnode_get_next_child_node(fwnode, NULL); child;	\
> > >   	     child = fwnode_get_next_child_node(fwnode, child))
> > > +#define fwnode_for_each_named_child_node(fwnode, child, name)		\
> > > +	fwnode_for_each_child_node(fwnode, child)			\
> > > +		if (!fwnode_name_eq(child, name)) { } else
> > > +
> > >   #define fwnode_for_each_available_child_node(fwnode, child)		       \
> > >   	for (child = fwnode_get_next_available_child_node(fwnode, NULL); child;\
> > >   	     child = fwnode_get_next_available_child_node(fwnode, child))
> > > +#define fwnode_for_each_available_named_child_node(fwnode, child, name)	\
> > > +	fwnode_for_each_available_child_node(fwnode, child)		\
> > > +		if (!fwnode_name_eq(child, name)) { } else
> > > +
> > 
> > OF only enumerates available nodes via the fwnode API, software nodes don't
> > have the concept but on ACPI I guess you could have a difference in nodes
> > where you have device sub-nodes that aren't available. Still, these ACPI
> > device nodes don't have meaningful names in this context (they're
> > 4-character object names) so you wouldn't use them like this anyway.
> 
> I believe you have far better understanding on these concepts than I do. The
> reason behind adding fwnode_for_each_available_child_node() was the patch
> 10/10:
> 
> -	fwnode_for_each_available_child_node(sensors, node) {
> -		if (fwnode_name_eq(node, "sensor")) {
> -			if (!thp7312_sensor_parse_dt(thp7312, node))
> -				num_sensors++;
> -		}
> +	fwnode_for_each_available_named_child_node(sensors, node, "sensor") {
> +		if (!thp7312_sensor_parse_dt(thp7312, node))
> +			num_sensors++;
>  	}
> 
> 
> > So my question is: is it useful to provide this besides
> > fwnode_for_each_named_child_node(), given that both are effectively the
> > same?
> 
> So, I suppose you're saying the existing thp7312 -driver has no real reason
> to use the 'fwnode_for_each_available_child_node()', but it could be using
> fwnode_for_each_child_node() instead?
> 
> If so, I am Ok with dropping the
> 'fwnode_for_each_available_named_child_node()' and changing the 10/10 to:
> 
> -	fwnode_for_each_available_child_node(sensors, node) {
> -		if (fwnode_name_eq(node, "sensor")) {
> -			if (!thp7312_sensor_parse_dt(thp7312, node))
> -				num_sensors++;
> -		}
> +	fwnode_for_each_named_child_node(sensors, node, "sensor") {
> +		if (!thp7312_sensor_parse_dt(thp7312, node))
> +			num_sensors++;
>  	}
> 
> Do you think that'd be correct?

I'd say so. Feel free to cc me to the last patch as well.

I guess one way to make this clearer is to switch to
fwnode_for_each_child_node() in a separate patch before
fwnode_for_each_named_child_node() conversion.

There are also just a handful of users of
fwnode_for_each_available_child_node() and I guess these could be
converted, too, but I think it's outside the scope of the set.

-- 
Terveisin,

Sakari Ailus

Re: [PATCH v8 02/10] property: Add functions to iterate named child

[Matti Vaittinen]

On 19/03/2025 17:23, Sakari Ailus wrote:
> On Wed, Mar 19, 2025 at 08:02:24AM +0200, Matti Vaittinen wrote:
>> On 18/03/2025 17:24, Sakari Ailus wrote:
>>> On Mon, Mar 17, 2025 at 05:50:38PM +0200, Matti Vaittinen wrote:
>>>> There are a few use-cases where child nodes with a specific name need to
>>>> be parsed. Code like:

...

>>>> --- a/include/linux/property.h
>>>> +++ b/include/linux/property.h
>>>> @@ -167,10 +167,18 @@ struct fwnode_handle *fwnode_get_next_available_child_node(
>>>>    	for (child = fwnode_get_next_child_node(fwnode, NULL); child;	\
>>>>    	     child = fwnode_get_next_child_node(fwnode, child))
>>>> +#define fwnode_for_each_named_child_node(fwnode, child, name)		\
>>>> +	fwnode_for_each_child_node(fwnode, child)			\
>>>> +		if (!fwnode_name_eq(child, name)) { } else
>>>> +
>>>>    #define fwnode_for_each_available_child_node(fwnode, child)		       \
>>>>    	for (child = fwnode_get_next_available_child_node(fwnode, NULL); child;\
>>>>    	     child = fwnode_get_next_available_child_node(fwnode, child))
>>>> +#define fwnode_for_each_available_named_child_node(fwnode, child, name)	\
>>>> +	fwnode_for_each_available_child_node(fwnode, child)		\
>>>> +		if (!fwnode_name_eq(child, name)) { } else
>>>> +
>>>
>>> OF only enumerates available nodes via the fwnode API, software nodes don't
>>> have the concept but on ACPI I guess you could have a difference in nodes
>>> where you have device sub-nodes that aren't available. Still, these ACPI
>>> device nodes don't have meaningful names in this context (they're
>>> 4-character object names) so you wouldn't use them like this anyway.
>>
>> I believe you have far better understanding on these concepts than I do. The
>> reason behind adding fwnode_for_each_available_child_node() was the patch
>> 10/10:
>>
>> -	fwnode_for_each_available_child_node(sensors, node) {
>> -		if (fwnode_name_eq(node, "sensor")) {
>> -			if (!thp7312_sensor_parse_dt(thp7312, node))
>> -				num_sensors++;
>> -		}
>> +	fwnode_for_each_available_named_child_node(sensors, node, "sensor") {
>> +		if (!thp7312_sensor_parse_dt(thp7312, node))
>> +			num_sensors++;
>>   	}
>>
>>
>>> So my question is: is it useful to provide this besides
>>> fwnode_for_each_named_child_node(), given that both are effectively the
>>> same?
>>
>> So, I suppose you're saying the existing thp7312 -driver has no real reason
>> to use the 'fwnode_for_each_available_child_node()', but it could be using
>> fwnode_for_each_child_node() instead?
>>
>> If so, I am Ok with dropping the
>> 'fwnode_for_each_available_named_child_node()' and changing the 10/10 to:
>>
>> -	fwnode_for_each_available_child_node(sensors, node) {
>> -		if (fwnode_name_eq(node, "sensor")) {
>> -			if (!thp7312_sensor_parse_dt(thp7312, node))
>> -				num_sensors++;
>> -		}
>> +	fwnode_for_each_named_child_node(sensors, node, "sensor") {
>> +		if (!thp7312_sensor_parse_dt(thp7312, node))
>> +			num_sensors++;
>>   	}
>>
>> Do you think that'd be correct?
> 
> I'd say so. Feel free to cc me to the last patch as well.

Thanks. I'll drop the fwnode_for_each_available_named_child_node() then.

> I guess one way to make this clearer is to switch to
> fwnode_for_each_child_node() in a separate patch before
> fwnode_for_each_named_child_node() conversion.

I suppose this makes sense.

I think this series can't make it to 6.15-rc1. Meaning, these 
*_named_*() APIs perhaps land in 6.16-rc1. I assume these *_named_*() 
APIs will go through the IIO. This rather simple IIO driver's review 
took longer than I predicted, with more versions I intended (as always) 
- and I kind of dislike respinning the whole series, with this large 
audience, when changes are not interesting to the most.

Maybe it is simplest to drop the thp7312 (and gianfar) from this series, 
and respin them only when the 6.16-rc1 is out. It's going to be couple 
of months though - so there's always a risk that I forget.

The proposed change for the thp7312, from 
fwnode_for_each_available_child_node() to fwnode_for_each_child_node() 
can be done earlier though.

> There are also just a handful of users of
> fwnode_for_each_available_child_node() and I guess these could be
> converted, too, but I think it's outside the scope of the set.

Definitely not in the scope of the bd79124 support :)

Yours,
	-- Matti

Re: [PATCH v8 02/10] property: Add functions to iterate named child

[Jonathan Cameron]

On Thu, 20 Mar 2025 08:43:44 +0200
Matti Vaittinen <mazziesaccount@gmail.com> wrote:

> On 19/03/2025 17:23, Sakari Ailus wrote:
> > On Wed, Mar 19, 2025 at 08:02:24AM +0200, Matti Vaittinen wrote:  
> >> On 18/03/2025 17:24, Sakari Ailus wrote:  
> >>> On Mon, Mar 17, 2025 at 05:50:38PM +0200, Matti Vaittinen wrote:  
> >>>> There are a few use-cases where child nodes with a specific name need to
> >>>> be parsed. Code like:  
> 
> ...
> 
> >>>> --- a/include/linux/property.h
> >>>> +++ b/include/linux/property.h
> >>>> @@ -167,10 +167,18 @@ struct fwnode_handle *fwnode_get_next_available_child_node(
> >>>>    	for (child = fwnode_get_next_child_node(fwnode, NULL); child;	\
> >>>>    	     child = fwnode_get_next_child_node(fwnode, child))
> >>>> +#define fwnode_for_each_named_child_node(fwnode, child, name)		\
> >>>> +	fwnode_for_each_child_node(fwnode, child)			\
> >>>> +		if (!fwnode_name_eq(child, name)) { } else
> >>>> +
> >>>>    #define fwnode_for_each_available_child_node(fwnode, child)		       \
> >>>>    	for (child = fwnode_get_next_available_child_node(fwnode, NULL); child;\
> >>>>    	     child = fwnode_get_next_available_child_node(fwnode, child))
> >>>> +#define fwnode_for_each_available_named_child_node(fwnode, child, name)	\
> >>>> +	fwnode_for_each_available_child_node(fwnode, child)		\
> >>>> +		if (!fwnode_name_eq(child, name)) { } else
> >>>> +  
> >>>
> >>> OF only enumerates available nodes via the fwnode API, software nodes don't
> >>> have the concept but on ACPI I guess you could have a difference in nodes
> >>> where you have device sub-nodes that aren't available. Still, these ACPI
> >>> device nodes don't have meaningful names in this context (they're
> >>> 4-character object names) so you wouldn't use them like this anyway.  
> >>
> >> I believe you have far better understanding on these concepts than I do. The
> >> reason behind adding fwnode_for_each_available_child_node() was the patch
> >> 10/10:
> >>
> >> -	fwnode_for_each_available_child_node(sensors, node) {
> >> -		if (fwnode_name_eq(node, "sensor")) {
> >> -			if (!thp7312_sensor_parse_dt(thp7312, node))
> >> -				num_sensors++;
> >> -		}
> >> +	fwnode_for_each_available_named_child_node(sensors, node, "sensor") {
> >> +		if (!thp7312_sensor_parse_dt(thp7312, node))
> >> +			num_sensors++;
> >>   	}
> >>
> >>  
> >>> So my question is: is it useful to provide this besides
> >>> fwnode_for_each_named_child_node(), given that both are effectively the
> >>> same?  
> >>
> >> So, I suppose you're saying the existing thp7312 -driver has no real reason
> >> to use the 'fwnode_for_each_available_child_node()', but it could be using
> >> fwnode_for_each_child_node() instead?
> >>
> >> If so, I am Ok with dropping the
> >> 'fwnode_for_each_available_named_child_node()' and changing the 10/10 to:
> >>
> >> -	fwnode_for_each_available_child_node(sensors, node) {
> >> -		if (fwnode_name_eq(node, "sensor")) {
> >> -			if (!thp7312_sensor_parse_dt(thp7312, node))
> >> -				num_sensors++;
> >> -		}
> >> +	fwnode_for_each_named_child_node(sensors, node, "sensor") {
> >> +		if (!thp7312_sensor_parse_dt(thp7312, node))
> >> +			num_sensors++;
> >>   	}
> >>
> >> Do you think that'd be correct?  
> > 
> > I'd say so. Feel free to cc me to the last patch as well.  
> 
> Thanks. I'll drop the fwnode_for_each_available_named_child_node() then.
> 
> > I guess one way to make this clearer is to switch to
> > fwnode_for_each_child_node() in a separate patch before
> > fwnode_for_each_named_child_node() conversion.  
> 
> I suppose this makes sense.

this _available_ thing is ancient history that has tripped us up
many times before. I've very keen to not see another case sneaking
in.  Whether we can definitely 'fix' all existing cases is a different
question..

> 
> I think this series can't make it to 6.15-rc1. Meaning, these 
> *_named_*() APIs perhaps land in 6.16-rc1. I assume these *_named_*() 
> APIs will go through the IIO. This rather simple IIO driver's review 
> took longer than I predicted, with more versions I intended (as always) 
> - and I kind of dislike respinning the whole series, with this large 
> audience, when changes are not interesting to the most.
> 
> Maybe it is simplest to drop the thp7312 (and gianfar) from this series, 
> and respin them only when the 6.16-rc1 is out. It's going to be couple 
> of months though - so there's always a risk that I forget.
> 
> The proposed change for the thp7312, from 
> fwnode_for_each_available_child_node() to fwnode_for_each_child_node() 
> can be done earlier though.
> 
> > There are also just a handful of users of
> > fwnode_for_each_available_child_node() and I guess these could be
> > converted, too, but I think it's outside the scope of the set.  
> 
> Definitely not in the scope of the bd79124 support :)
Agreed. Break this series up however you like and entirely up to
you whether you do further cleanup of other bits of the kernel!

Jonathan

> 
> Yours,
> 	-- Matti

[PATCH v8 03/10] iio: adc: add helpers for parsing ADC nodes

[Matti Vaittinen]

[-- Attachment #1: Type: text/plain, Size: 6527 bytes --]

There are ADC ICs which may have some of the AIN pins usable for other
functions. These ICs may have some of the AIN pins wired so that they
should not be used for ADC.

(Preferred?) way for marking pins which can be used as ADC inputs is to
add corresponding channels@N nodes in the device tree as described in
the ADC binding yaml.

Add couple of helper functions which can be used to retrieve the channel
information from the device node.

Signed-off-by: Matti Vaittinen <mazziesaccount@gmail.com>

---
Revision history:
v7 => v8:
 devm_iio_adc_device_alloc_chaninfo_se():
 - Treat all negative values for the max ID as 'don't care'
 - Return -ENOENT instead of '0' if no channels were found.
v5 => v6:
 - Adapt to changed fwnode helper names
 - Fix spelling
v4 => v5:
 - Inline iio_adc_device_num_channels()
 - Fix Indenting function parameters
 - Combine the max channel ID checks.
v3 => v4:
 - Drop diff-channel support
 - Drop iio_adc_device_channels_by_property()
 - Add IIO_DEVICE namespace
 - Move industrialio-adc.o to top of the Makefile
 - Some styling as suggested by Andy
 - Re-consider included headers
v2 => v3: Mostly based on review comments by Jonathan
 - Support differential and single-ended channels
 - Rename iio_adc_device_get_channels() as
   iio_adc_device_channels_by_property()
 - Improve spelling
 - Drop support for cases where DT comes from parent device's node
 - Decrease loop indent by reverting node name check conditions
 - Don't set 'chan->indexed' by number of channels to keep the
   interface consistent no matter how many channels are connected.
 - Fix ID range check and related comment
RFC v1 => v2:
 - New patch
---
 drivers/iio/adc/Kconfig            |  3 ++
 drivers/iio/adc/Makefile           |  2 +
 drivers/iio/adc/industrialio-adc.c | 82 ++++++++++++++++++++++++++++++
 include/linux/iio/adc-helpers.h    | 27 ++++++++++
 4 files changed, 114 insertions(+)
 create mode 100644 drivers/iio/adc/industrialio-adc.c
 create mode 100644 include/linux/iio/adc-helpers.h

diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig
index 849c90203071..37b70a65da6f 100644
--- a/drivers/iio/adc/Kconfig
+++ b/drivers/iio/adc/Kconfig
@@ -6,6 +6,9 @@
 
 menu "Analog to digital converters"
 
+config IIO_ADC_HELPER
+	tristate
+
 config AB8500_GPADC
 	bool "ST-Ericsson AB8500 GPADC driver"
 	depends on AB8500_CORE && REGULATOR_AB8500
diff --git a/drivers/iio/adc/Makefile b/drivers/iio/adc/Makefile
index ee19afba62b7..1c410f483029 100644
--- a/drivers/iio/adc/Makefile
+++ b/drivers/iio/adc/Makefile
@@ -3,6 +3,8 @@
 # Makefile for IIO ADC drivers
 #
 
+obj-$(CONFIG_IIO_ADC_HELPER) += industrialio-adc.o
+
 # When adding new entries keep the list in alphabetical order
 obj-$(CONFIG_AB8500_GPADC) += ab8500-gpadc.o
 obj-$(CONFIG_AD_SIGMA_DELTA) += ad_sigma_delta.o
diff --git a/drivers/iio/adc/industrialio-adc.c b/drivers/iio/adc/industrialio-adc.c
new file mode 100644
index 000000000000..b4057230e749
--- /dev/null
+++ b/drivers/iio/adc/industrialio-adc.c
@@ -0,0 +1,82 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Helpers for parsing common ADC information from a firmware node.
+ *
+ * Copyright (c) 2025 Matti Vaittinen <mazziesaccount@gmail.com>
+ */
+
+#include <linux/device.h>
+#include <linux/errno.h>
+#include <linux/export.h>
+#include <linux/module.h>
+#include <linux/property.h>
+#include <linux/types.h>
+
+#include <linux/iio/adc-helpers.h>
+#include <linux/iio/iio.h>
+
+/**
+ * devm_iio_adc_device_alloc_chaninfo_se - allocate and fill iio_chan_spec for ADC
+ *
+ * Scan the device node for single-ended ADC channel information. Channel ID is
+ * expected to be found from the "reg" property. Allocate and populate the
+ * iio_chan_spec structure corresponding to channels that are found. The memory
+ * for iio_chan_spec structure will be freed upon device detach.
+ *
+ * @dev:		Pointer to the ADC device.
+ * @template:		Template iio_chan_spec from which the fields of all
+ *			found and allocated channels are initialized.
+ * @max_chan_id:	Maximum value of a channel ID. Use negative value if no
+ *			checking is required.
+ * @cs:			Location where pointer to allocated iio_chan_spec
+ *			should be stored.
+ *
+ * Return:	Number of found channels on success. Negative value to indicate
+ *		failure. Specifically, -ENOENT if no channel nodes were found.
+ */
+int devm_iio_adc_device_alloc_chaninfo_se(struct device *dev,
+					  const struct iio_chan_spec *template,
+					  int max_chan_id,
+					  struct iio_chan_spec **cs)
+{
+	struct iio_chan_spec *chan_array, *chan;
+	int num_chan, ret;
+
+	num_chan = iio_adc_device_num_channels(dev);
+	if (num_chan < 0)
+		return num_chan;
+
+	if (!num_chan)
+		return -ENOENT;
+
+	chan_array = devm_kcalloc(dev, num_chan, sizeof(*chan_array),
+				  GFP_KERNEL);
+	if (!chan_array)
+		return -ENOMEM;
+
+	chan = &chan_array[0];
+
+	device_for_each_named_child_node_scoped(dev, child, "channel") {
+		u32 ch;
+
+		ret = fwnode_property_read_u32(child, "reg", &ch);
+		if (ret)
+			return ret;
+
+		if (max_chan_id >= 0 && ch > max_chan_id)
+			return -ERANGE;
+
+		*chan = *template;
+		chan->channel = ch;
+		chan++;
+	}
+
+	*cs = chan_array;
+
+	return num_chan;
+}
+EXPORT_SYMBOL_NS_GPL(devm_iio_adc_device_alloc_chaninfo_se, "IIO_DRIVER");
+
+MODULE_LICENSE("GPL");
+MODULE_AUTHOR("Matti Vaittinen <mazziesaccount@gmail.com>");
+MODULE_DESCRIPTION("IIO ADC fwnode parsing helpers");
diff --git a/include/linux/iio/adc-helpers.h b/include/linux/iio/adc-helpers.h
new file mode 100644
index 000000000000..56b092a2a4c4
--- /dev/null
+++ b/include/linux/iio/adc-helpers.h
@@ -0,0 +1,27 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+
+/*
+ * The industrial I/O ADC firmware property parsing helpers
+ *
+ * Copyright (c) 2025 Matti Vaittinen <mazziesaccount@gmail.com>
+ */
+
+#ifndef _INDUSTRIAL_IO_ADC_HELPERS_H_
+#define _INDUSTRIAL_IO_ADC_HELPERS_H_
+
+#include <linux/property.h>
+
+struct device;
+struct iio_chan_spec;
+
+static inline int iio_adc_device_num_channels(struct device *dev)
+{
+	return device_get_named_child_node_count(dev, "channel");
+}
+
+int devm_iio_adc_device_alloc_chaninfo_se(struct device *dev,
+					  const struct iio_chan_spec *template,
+					  int max_chan_id,
+					  struct iio_chan_spec **cs);
+
+#endif /* _INDUSTRIAL_IO_ADC_HELPERS_H_ */
-- 
2.48.1


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [PATCH v8 03/10] iio: adc: add helpers for parsing ADC nodes

[Andy Shevchenko]

On Mon, Mar 17, 2025 at 05:50:49PM +0200, Matti Vaittinen wrote:
> There are ADC ICs which may have some of the AIN pins usable for other
> functions. These ICs may have some of the AIN pins wired so that they
> should not be used for ADC.
> 
> (Preferred?) way for marking pins which can be used as ADC inputs is to
> add corresponding channels@N nodes in the device tree as described in
> the ADC binding yaml.
> 
> Add couple of helper functions which can be used to retrieve the channel
> information from the device node.

LGTM now, thanks!
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>

-- 
With Best Regards,
Andy Shevchenko

[PATCH v8 04/10] iio: adc: rzg2l_adc: Use adc-helpers

[Matti Vaittinen]

[-- Attachment #1: Type: text/plain, Size: 5177 bytes --]

The new devm_iio_adc_device_alloc_chaninfo_se() -helper is intended to
help drivers avoid open-coding the for_each_node -loop for getting the
channel IDs. The helper provides standard way to detect the ADC channel
nodes (by the node name), and a standard way to convert the "reg"
-properties to channel identification numbers, used in the struct
iio_chan_spec. Furthermore, the helper can optionally check the found
channel IDs are smaller than given maximum. This is useful for callers
which later use the IDs for example for indexing a channel data array.

The original driver treated all found child nodes as channel nodes. The
new helper requires channel nodes to be named channel[@N]. This should
help avoid problems with devices which may contain also other but ADC
child nodes. Quick grep from arch/* with the rzg2l_adc's compatible
string didn't reveal any in-tree .dts with channel nodes named
otherwise. Also, same grep shows all the .dts seem to have channel IDs
between 0..num of channels.

Use the new helper.

Signed-off-by: Matti Vaittinen <mazziesaccount@gmail.com>

---
NOTE: This change now drops a print "no channel children" which used to
be printed if no channel nodes were found. It also changes the return
value from -ENODEV to -ENOENT.

Revision history:
v7 => v8:
 - drop explicit "no channels check". It is now done inside the
   devm_iio_adc_device_alloc_chaninfo_se().
v6 => v7:
 - Fix function name in the commit message
v5 => v6:
 - Commit message typofix
v4 => v5:
 - Drop the diff-channel stuff from the commit message
v3 => v4:
 - Adapt to 'drop diff-channel support' changes to ADC-helpers
 - select ADC helpers in the Kconfig
 - Rebased to 6.14-rc3 => channel type can no longer come from the
   template.

v2 => v3:
 - New patch

The change is compile tested only!! Testing before applying is highly
appreciated (as always!).
---
 drivers/iio/adc/Kconfig     |  1 +
 drivers/iio/adc/rzg2l_adc.c | 39 +++++++++++++++----------------------
 2 files changed, 17 insertions(+), 23 deletions(-)

diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig
index 37b70a65da6f..e4933de0c366 100644
--- a/drivers/iio/adc/Kconfig
+++ b/drivers/iio/adc/Kconfig
@@ -1222,6 +1222,7 @@ config RICHTEK_RTQ6056
 config RZG2L_ADC
 	tristate "Renesas RZ/G2L ADC driver"
 	depends on ARCH_RZG2L || COMPILE_TEST
+	select IIO_ADC_HELPER
 	help
 	  Say yes here to build support for the ADC found in Renesas
 	  RZ/G2L family.
diff --git a/drivers/iio/adc/rzg2l_adc.c b/drivers/iio/adc/rzg2l_adc.c
index 883c167c0670..8097e59da516 100644
--- a/drivers/iio/adc/rzg2l_adc.c
+++ b/drivers/iio/adc/rzg2l_adc.c
@@ -11,6 +11,7 @@
 #include <linux/cleanup.h>
 #include <linux/completion.h>
 #include <linux/delay.h>
+#include <linux/iio/adc-helpers.h>
 #include <linux/iio/iio.h>
 #include <linux/interrupt.h>
 #include <linux/io.h>
@@ -324,48 +325,39 @@ static irqreturn_t rzg2l_adc_isr(int irq, void *dev_id)
 	return IRQ_HANDLED;
 }
 
+static const struct iio_chan_spec rzg2l_adc_chan_template = {
+	.indexed = 1,
+	.info_mask_separate = BIT(IIO_CHAN_INFO_RAW),
+};
+
 static int rzg2l_adc_parse_properties(struct platform_device *pdev, struct rzg2l_adc *adc)
 {
 	const struct rzg2l_adc_hw_params *hw_params = adc->hw_params;
 	struct iio_chan_spec *chan_array;
 	struct rzg2l_adc_data *data;
-	unsigned int channel;
 	int num_channels;
-	int ret;
 	u8 i;
 
 	data = devm_kzalloc(&pdev->dev, sizeof(*data), GFP_KERNEL);
 	if (!data)
 		return -ENOMEM;
 
-	num_channels = device_get_child_node_count(&pdev->dev);
-	if (!num_channels)
-		return dev_err_probe(&pdev->dev, -ENODEV, "no channel children\n");
+	num_channels = devm_iio_adc_device_alloc_chaninfo_se(&pdev->dev,
+						&rzg2l_adc_chan_template,
+						hw_params->num_channels - 1,
+						&chan_array);
+	if (num_channels < 0)
+		return num_channels;
 
 	if (num_channels > hw_params->num_channels)
 		return dev_err_probe(&pdev->dev, -EINVAL,
 				     "num of channel children out of range\n");
 
-	chan_array = devm_kcalloc(&pdev->dev, num_channels, sizeof(*chan_array),
-				  GFP_KERNEL);
-	if (!chan_array)
-		return -ENOMEM;
+	for (i = 0; i < num_channels; i++) {
+		int channel = chan_array[i].channel;
 
-	i = 0;
-	device_for_each_child_node_scoped(&pdev->dev, fwnode) {
-		ret = fwnode_property_read_u32(fwnode, "reg", &channel);
-		if (ret)
-			return ret;
-
-		if (channel >= hw_params->num_channels)
-			return -EINVAL;
-
-		chan_array[i].type = rzg2l_adc_channels[channel].type;
-		chan_array[i].indexed = 1;
-		chan_array[i].channel = channel;
-		chan_array[i].info_mask_separate = BIT(IIO_CHAN_INFO_RAW);
 		chan_array[i].datasheet_name = rzg2l_adc_channels[channel].name;
-		i++;
+		chan_array[i].type = rzg2l_adc_channels[channel].type;
 	}
 
 	data->num_channels = num_channels;
@@ -626,3 +618,4 @@ module_platform_driver(rzg2l_adc_driver);
 MODULE_AUTHOR("Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>");
 MODULE_DESCRIPTION("Renesas RZ/G2L ADC driver");
 MODULE_LICENSE("GPL v2");
+MODULE_IMPORT_NS("IIO_DRIVER");
-- 
2.48.1


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [PATCH v8 04/10] iio: adc: rzg2l_adc: Use adc-helpers

[Andy Shevchenko]

On Mon, Mar 17, 2025 at 05:51:02PM +0200, Matti Vaittinen wrote:
> The new devm_iio_adc_device_alloc_chaninfo_se() -helper is intended to
> help drivers avoid open-coding the for_each_node -loop for getting the
> channel IDs. The helper provides standard way to detect the ADC channel
> nodes (by the node name), and a standard way to convert the "reg"
> -properties to channel identification numbers, used in the struct
> iio_chan_spec. Furthermore, the helper can optionally check the found
> channel IDs are smaller than given maximum. This is useful for callers
> which later use the IDs for example for indexing a channel data array.
> 
> The original driver treated all found child nodes as channel nodes. The
> new helper requires channel nodes to be named channel[@N]. This should
> help avoid problems with devices which may contain also other but ADC
> child nodes. Quick grep from arch/* with the rzg2l_adc's compatible
> string didn't reveal any in-tree .dts with channel nodes named
> otherwise. Also, same grep shows all the .dts seem to have channel IDs
> between 0..num of channels.
> 
> Use the new helper.

Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>

-- 
With Best Regards,
Andy Shevchenko

[PATCH v8 05/10] iio: adc: sun20i-gpadc: Use adc-helpers

[Matti Vaittinen]

[-- Attachment #1: Type: text/plain, Size: 5225 bytes --]

The new devm_iio_adc_device_alloc_chaninfo_se() -helper is intended to
help drivers avoid open-coding the for_each_node -loop for getting the
channel IDs. The helper provides standard way to detect the ADC channel
nodes (by the node name), and a standard way to convert the "reg"
-properties to channel identification numbers, used in the struct
iio_chan_spec. Furthermore, the helper can optionally check the found
channel IDs are smaller than given maximum. This is useful for callers
which later use the IDs for example for indexing a channel data array.

The original driver treated all found child nodes as channel nodes. The
new helper requires channel nodes to be named channel[@N]. This should
help avoid problems with devices which may contain also other but ADC
child nodes. Quick grep from arch/* with the sun20i-gpadc's compatible
string didn't reveal any in-tree .dts with channel nodes named
otherwise. Also, same grep shows all the in-tree .dts seem to have
channel IDs between 0..num of channels.

Use the new helper.

Signed-off-by: Matti Vaittinen <mazziesaccount@gmail.com>

---
NOTE: This change now drops a print "no channel children" which used to
be printed if no channel nodes were found. It also changes the return
value from -ENODEV to -ENOENT.

Revision history:
v7 => v8:
 - drop explicit "no channels check". It is now done inside the
   devm_iio_adc_device_alloc_chaninfo_se().
v6 => v7:
 - Fix function name in the commit message
v5 => v6:
 - Commit message typofix
v4 => v5:
 - Drop the diff-channel stuff from the commit message
v3 => v4:
 - Adapt to 'drop diff-channel support' changes to ADC-helpers
 - select ADC helpers in the Kconfig
v2 => v3:
 - New patch

I picked the sun20i-gpadc in this series because it has a straightforward
approach for populating the struct iio_chan_spec. Everything else except
the .channel can use 'template'-data.

This makes the sun20i-gpadc well suited to be an example user of this new
helper. I hope this patch helps to evaluate whether these helpers are worth
the hassle.

The change is compile tested only!! Testing before applying is highly
appreciated (as always!). Also, even though I tried to audit the dts
files for the reg-properties in the channel nodes, use of references
didn't make it easy. I can't guarantee I didn't miss anything.
---
 drivers/iio/adc/Kconfig            |  1 +
 drivers/iio/adc/sun20i-gpadc-iio.c | 39 +++++++++++-------------------
 2 files changed, 15 insertions(+), 25 deletions(-)

diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig
index e4933de0c366..0993008a1586 100644
--- a/drivers/iio/adc/Kconfig
+++ b/drivers/iio/adc/Kconfig
@@ -1357,6 +1357,7 @@ config SUN4I_GPADC
 config SUN20I_GPADC
 	tristate "Allwinner D1/T113s/T507/R329 and similar GPADCs driver"
 	depends on ARCH_SUNXI || COMPILE_TEST
+	select IIO_ADC_HELPER
 	help
 	  Say yes here to build support for Allwinner (D1, T113, T507 and R329)
 	  SoCs GPADC. This ADC provides up to 16 channels.
diff --git a/drivers/iio/adc/sun20i-gpadc-iio.c b/drivers/iio/adc/sun20i-gpadc-iio.c
index 136b8d9c294f..2428ea69d676 100644
--- a/drivers/iio/adc/sun20i-gpadc-iio.c
+++ b/drivers/iio/adc/sun20i-gpadc-iio.c
@@ -15,6 +15,7 @@
 #include <linux/property.h>
 #include <linux/reset.h>
 
+#include <linux/iio/adc-helpers.h>
 #include <linux/iio/iio.h>
 
 #define SUN20I_GPADC_DRIVER_NAME	"sun20i-gpadc"
@@ -149,36 +150,23 @@ static void sun20i_gpadc_reset_assert(void *data)
 	reset_control_assert(rst);
 }
 
+static const struct iio_chan_spec sun20i_gpadc_chan_template = {
+	.type = IIO_VOLTAGE,
+	.indexed = 1,
+	.info_mask_separate = BIT(IIO_CHAN_INFO_RAW),
+	.info_mask_shared_by_type = BIT(IIO_CHAN_INFO_SCALE),
+};
+
 static int sun20i_gpadc_alloc_channels(struct iio_dev *indio_dev,
 				       struct device *dev)
 {
-	unsigned int channel;
-	int num_channels, i, ret;
+	int num_channels;
 	struct iio_chan_spec *channels;
 
-	num_channels = device_get_child_node_count(dev);
-	if (num_channels == 0)
-		return dev_err_probe(dev, -ENODEV, "no channel children\n");
-
-	channels = devm_kcalloc(dev, num_channels, sizeof(*channels),
-				GFP_KERNEL);
-	if (!channels)
-		return -ENOMEM;
-
-	i = 0;
-	device_for_each_child_node_scoped(dev, node) {
-		ret = fwnode_property_read_u32(node, "reg", &channel);
-		if (ret)
-			return dev_err_probe(dev, ret, "invalid channel number\n");
-
-		channels[i].type = IIO_VOLTAGE;
-		channels[i].indexed = 1;
-		channels[i].channel = channel;
-		channels[i].info_mask_separate = BIT(IIO_CHAN_INFO_RAW);
-		channels[i].info_mask_shared_by_type = BIT(IIO_CHAN_INFO_SCALE);
-
-		i++;
-	}
+	num_channels = devm_iio_adc_device_alloc_chaninfo_se(dev,
+				&sun20i_gpadc_chan_template, -1, &channels);
+	if (num_channels < 0)
+		return num_channels;
 
 	indio_dev->channels = channels;
 	indio_dev->num_channels = num_channels;
@@ -271,3 +259,4 @@ module_platform_driver(sun20i_gpadc_driver);
 MODULE_DESCRIPTION("ADC driver for sunxi platforms");
 MODULE_AUTHOR("Maksim Kiselev <bigunclemax@gmail.com>");
 MODULE_LICENSE("GPL");
+MODULE_IMPORT_NS("IIO_DRIVER");
-- 
2.48.1


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [PATCH v8 05/10] iio: adc: sun20i-gpadc: Use adc-helpers

[Andy Shevchenko]

On Mon, Mar 17, 2025 at 05:51:14PM +0200, Matti Vaittinen wrote:
> The new devm_iio_adc_device_alloc_chaninfo_se() -helper is intended to
> help drivers avoid open-coding the for_each_node -loop for getting the
> channel IDs. The helper provides standard way to detect the ADC channel
> nodes (by the node name), and a standard way to convert the "reg"
> -properties to channel identification numbers, used in the struct
> iio_chan_spec. Furthermore, the helper can optionally check the found
> channel IDs are smaller than given maximum. This is useful for callers
> which later use the IDs for example for indexing a channel data array.
> 
> The original driver treated all found child nodes as channel nodes. The
> new helper requires channel nodes to be named channel[@N]. This should
> help avoid problems with devices which may contain also other but ADC
> child nodes. Quick grep from arch/* with the sun20i-gpadc's compatible
> string didn't reveal any in-tree .dts with channel nodes named
> otherwise. Also, same grep shows all the in-tree .dts seem to have
> channel IDs between 0..num of channels.
> 
> Use the new helper.

Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>

-- 
With Best Regards,
Andy Shevchenko

[PATCH v8 06/10] iio: adc: Support ROHM BD79124 ADC

[Matti Vaittinen]

[-- Attachment #1: Type: text/plain, Size: 37632 bytes --]

The ROHM BD79124 is a 12-bit, 8-channel, SAR ADC. The ADC supports
an automatic measurement mode, with an alarm interrupt for out-of-window
measurements. The window is configurable for each channel.

The I2C protocol for manual start of the measurement and data reading is
somewhat peculiar. It requires the master to do clock stretching after
sending the I2C slave-address until the slave has captured the data.
Needless to say this is not well suopported by the I2C controllers.

Thus do not support the BD79124's manual measurement mode but implement
the measurements using automatic measurement mode, relying on the
BD79124's ability of storing latest measurements into register.

Support also configuring the threshold events for detecting the
out-of-window events.

The BD79124 keeps asserting IRQ for as long as the measured voltage is
out of the configured window. Thus, prevent the user-space from choking
on the events and mask the received event for a fixed duration (1 second)
when an event is handled.

The ADC input pins can be also configured as general purpose outputs.
Make those pins which don't have corresponding ADC channel node in the
device-tree controllable as GPO.

Signed-off-by: Matti Vaittinen <mazziesaccount@gmail.com>

---
Revision history:
v7 => v8:
 - Use unsigned for regmap values
 - Commit message fine tuning
 - Check devm_mutex_init() return value
 - Typofixes
 - Styling as suggested by Andy
 - Handle cases where all pins are ADCs or GPOs
 - Report 1 to user to indicate enabled event, regardless the direction.
v6 => v7:
 - Styling
v5 => v6:
 - Styling as suggested by Jonathan
v4 => v5:
 - Drop unused interval defines
 - Append unit to interval define and drop a comment
 - Drop parenthesis around bitwise negation operation ~
 - Use proper block comment style
 - Improve the documentation of the re-enabling the events by moving
   comment explaining early return to the point of the return, and
   by adding own comment for the reason of locking before calling the
   re-enabling
 - Indenting
 - Drop unused struct bd79124_reg_init
 - Drop bd79124_init_mux() wrapper and call the regmap_write() directly
v3 => v4:
 - Adapt to 'drop diff-channel support' changes to ADC-helpers
 - Don't parse fwnode in GPIO valid-mask callback but use pin config
   cached at probe()
 - Drop use of iio_adc_device_channels_by_property()
 - Open code the bd79124_reg_init loop (as suggested by Jonathan)
 - Use devm variant of mutex_init()
 - Styling
v2 => v3:
 - Fix uninitialized return value reported by the kernel test robot
 - Fix indent
 - Adapt to adc-helper changes supporting also single-ended and
   differential channels
RFC v1 => v2:
 - Add event throttling (constant delay of 1 sec)
 - rename variable 'd' to 'data'
 - Use ADC helpers to detect pins used for ADC
 - bd79124 drop MFD and pinmux && handle GPO in this driver
 - Drop adc suffix from the IIO file name
---
 drivers/iio/adc/Kconfig        |   12 +
 drivers/iio/adc/Makefile       |    1 +
 drivers/iio/adc/rohm-bd79124.c | 1138 ++++++++++++++++++++++++++++++++
 3 files changed, 1151 insertions(+)
 create mode 100644 drivers/iio/adc/rohm-bd79124.c

diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig
index 0993008a1586..74d749c0cd8f 100644
--- a/drivers/iio/adc/Kconfig
+++ b/drivers/iio/adc/Kconfig
@@ -1191,6 +1191,18 @@ config RN5T618_ADC
 	  This driver can also be built as a module. If so, the module
 	  will be called rn5t618-adc.
 
+config ROHM_BD79124
+	tristate "Rohm BD79124 ADC driver"
+	depends on I2C
+	select REGMAP_I2C
+	select IIO_ADC_HELPER
+	help
+	  Say yes here to build support for the ROHM BD79124 ADC. The
+	  ROHM BD79124 is a 12-bit, 8-channel, SAR ADC. The ADC supports
+	  also an automatic measurement mode, with an alarm interrupt for
+	  out-of-window measurements. The window is configurable for each
+	  channel.
+
 config ROCKCHIP_SARADC
 	tristate "Rockchip SARADC driver"
 	depends on ARCH_ROCKCHIP || COMPILE_TEST
diff --git a/drivers/iio/adc/Makefile b/drivers/iio/adc/Makefile
index 1c410f483029..3e10af9ec4c4 100644
--- a/drivers/iio/adc/Makefile
+++ b/drivers/iio/adc/Makefile
@@ -109,6 +109,7 @@ obj-$(CONFIG_QCOM_VADC_COMMON) += qcom-vadc-common.o
 obj-$(CONFIG_RCAR_GYRO_ADC) += rcar-gyroadc.o
 obj-$(CONFIG_RICHTEK_RTQ6056) += rtq6056.o
 obj-$(CONFIG_RN5T618_ADC) += rn5t618-adc.o
+obj-$(CONFIG_ROHM_BD79124) += rohm-bd79124.o
 obj-$(CONFIG_ROCKCHIP_SARADC) += rockchip_saradc.o
 obj-$(CONFIG_RZG2L_ADC) += rzg2l_adc.o
 obj-$(CONFIG_SC27XX_ADC) += sc27xx_adc.o
diff --git a/drivers/iio/adc/rohm-bd79124.c b/drivers/iio/adc/rohm-bd79124.c
new file mode 100644
index 000000000000..ab6286b5c090
--- /dev/null
+++ b/drivers/iio/adc/rohm-bd79124.c
@@ -0,0 +1,1138 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * ROHM ADC driver for BD79124 ADC/GPO device
+ * https://fscdn.rohm.com/en/products/databook/datasheet/ic/data_converter/dac/bd79124muf-c-e.pdf
+ *
+ * Copyright (c) 2025, ROHM Semiconductor.
+ */
+
+#include <linux/bitfield.h>
+#include <linux/bitmap.h>
+#include <linux/bits.h>
+#include <linux/byteorder/generic.h>
+#include <linux/device.h>
+#include <linux/delay.h>
+#include <linux/devm-helpers.h>
+#include <linux/err.h>
+#include <linux/gpio/driver.h>
+#include <linux/i2c.h>
+#include <linux/interrupt.h>
+#include <linux/irqreturn.h>
+#include <linux/module.h>
+#include <linux/mod_devicetable.h>
+#include <linux/regmap.h>
+#include <linux/types.h>
+
+#include <linux/iio/events.h>
+#include <linux/iio/iio.h>
+#include <linux/iio/adc-helpers.h>
+
+#define BD79124_I2C_MULTI_READ		0x30
+#define BD79124_I2C_MULTI_WRITE		0x28
+#define BD79124_REG_MAX			0xaf
+
+#define BD79124_REG_SYSTEM_STATUS	0x00
+#define BD79124_REG_GEN_CFG		0x01
+#define BD79124_REG_OPMODE_CFG		0x04
+#define BD79124_REG_PINCFG		0x05
+#define BD79124_REG_GPO_VAL		0x0B
+#define BD79124_REG_SEQ_CFG		0x10
+#define BD79124_REG_MANUAL_CHANNELS	0x11
+#define BD79124_REG_AUTO_CHANNELS	0x12
+#define BD79124_REG_ALERT_CH_SEL	0x14
+#define BD79124_REG_EVENT_FLAG		0x18
+#define BD79124_REG_EVENT_FLAG_HI	0x1a
+#define BD79124_REG_EVENT_FLAG_LO	0x1c
+#define BD79124_REG_HYSTERESIS_CH0	0x20
+#define BD79124_REG_EVENTCOUNT_CH0	0x22
+#define BD79124_REG_RECENT_CH0_LSB	0xa0
+#define BD79124_REG_RECENT_CH7_MSB	0xaf
+
+#define BD79124_ADC_BITS 12
+
+/* Masks for the BD79124_REG_OPMODE_CFG */
+#define BD79124_MSK_CONV_MODE GENMASK(6, 5)
+#define BD79124_CONV_MODE_MANSEQ 0
+#define BD79124_CONV_MODE_AUTO 1
+#define BD79124_MSK_AUTO_INTERVAL GENMASK(1, 0)
+#define BD79124_INTERVAL_750_US 0
+
+/* Masks for the BD79124_REG_GEN_CFG */
+#define BD79124_MSK_DWC_EN BIT(4)
+#define BD79124_MSK_STATS_EN BIT(5)
+
+/* Masks for the BD79124_REG_SEQ_CFG */
+#define BD79124_MSK_SEQ_START BIT(4)
+#define BD79124_MSK_SEQ_MODE GENMASK(1, 0)
+#define BD79124_MSK_SEQ_MANUAL 0
+#define BD79124_MSK_SEQ_SEQ 1
+
+#define BD79124_MSK_HYSTERESIS GENMASK(3, 0)
+#define BD79124_LOW_LIMIT_MIN 0
+#define BD79124_HIGH_LIMIT_MAX GENMASK(11, 0)
+
+/*
+ * The high limit, low limit and last measurement result are each stored in
+ * 2 consequtive registers. 4 bits are in the high bits of the first register
+ * and 8 bits in the next register.
+ *
+ * These macros return the address of the first reg for the given channel.
+ */
+#define BD79124_GET_HIGH_LIMIT_REG(ch) (BD79124_REG_HYSTERESIS_CH0 + (ch) * 4)
+#define BD79124_GET_LOW_LIMIT_REG(ch) (BD79124_REG_EVENTCOUNT_CH0 + (ch) * 4)
+#define BD79124_GET_LIMIT_REG(ch, dir) ((dir) == IIO_EV_DIR_RISING ?		\
+		BD79124_GET_HIGH_LIMIT_REG(ch) : BD79124_GET_LOW_LIMIT_REG(ch))
+#define BD79124_GET_RECENT_RES_REG(ch) (BD79124_REG_RECENT_CH0_LSB + (ch) * 2)
+
+/*
+ * The hysteresis for a channel is stored in the same register where the
+ * 4 bits of high limit reside.
+ */
+#define BD79124_GET_HYSTERESIS_REG(ch) BD79124_GET_HIGH_LIMIT_REG(ch)
+
+#define BD79124_MAX_NUM_CHANNELS 8
+
+struct bd79124_data {
+	s64 timestamp;
+	struct regmap *map;
+	struct device *dev;
+	int vmax;
+	/*
+	 * Keep measurement status so read_raw() knows if the measurement needs
+	 * to be started.
+	 */
+	int alarm_monitored[BD79124_MAX_NUM_CHANNELS];
+	/*
+	 * The BD79124 does not allow disabling/enabling limit separately for
+	 * one direction only. Hence, we do the disabling by changing the limit
+	 * to maximum/minimum measurable value. This means we need to cache
+	 * the limit in order to maintain it over the time limit is disabled.
+	 */
+	u16 alarm_r_limit[BD79124_MAX_NUM_CHANNELS];
+	u16 alarm_f_limit[BD79124_MAX_NUM_CHANNELS];
+	/* Bitmask of disabled events (for rate limiting) for each channel. */
+	int alarm_suppressed[BD79124_MAX_NUM_CHANNELS];
+	/*
+	 * The BD79124 is configured to run the measurements in the background.
+	 * This is done for the event monitoring as well as for the read_raw().
+	 * Protect the measurement starting/stopping using a mutex.
+	 */
+	struct mutex mutex;
+	struct delayed_work alm_enable_work;
+	struct gpio_chip gc;
+	u8 gpio_valid_mask;
+};
+
+static const struct regmap_range bd79124_ro_ranges[] = {
+	{
+		.range_min = BD79124_REG_EVENT_FLAG,
+		.range_max = BD79124_REG_EVENT_FLAG,
+	}, {
+		.range_min = BD79124_REG_RECENT_CH0_LSB,
+		.range_max = BD79124_REG_RECENT_CH7_MSB,
+	},
+};
+
+static const struct regmap_access_table bd79124_ro_regs = {
+	.no_ranges	= &bd79124_ro_ranges[0],
+	.n_no_ranges	= ARRAY_SIZE(bd79124_ro_ranges),
+};
+
+static const struct regmap_range bd79124_volatile_ranges[] = {
+	{
+		.range_min = BD79124_REG_RECENT_CH0_LSB,
+		.range_max = BD79124_REG_RECENT_CH7_MSB,
+	}, {
+		.range_min = BD79124_REG_EVENT_FLAG,
+		.range_max = BD79124_REG_EVENT_FLAG,
+	}, {
+		.range_min = BD79124_REG_EVENT_FLAG_HI,
+		.range_max = BD79124_REG_EVENT_FLAG_HI,
+	}, {
+		.range_min = BD79124_REG_EVENT_FLAG_LO,
+		.range_max = BD79124_REG_EVENT_FLAG_LO,
+	}, {
+		.range_min = BD79124_REG_SYSTEM_STATUS,
+		.range_max = BD79124_REG_SYSTEM_STATUS,
+	},
+};
+
+static const struct regmap_access_table bd79124_volatile_regs = {
+	.yes_ranges	= &bd79124_volatile_ranges[0],
+	.n_yes_ranges	= ARRAY_SIZE(bd79124_volatile_ranges),
+};
+
+static const struct regmap_range bd79124_precious_ranges[] = {
+	{
+		.range_min = BD79124_REG_EVENT_FLAG_HI,
+		.range_max = BD79124_REG_EVENT_FLAG_HI,
+	}, {
+		.range_min = BD79124_REG_EVENT_FLAG_LO,
+		.range_max = BD79124_REG_EVENT_FLAG_LO,
+	},
+};
+
+static const struct regmap_access_table bd79124_precious_regs = {
+	.yes_ranges	= &bd79124_precious_ranges[0],
+	.n_yes_ranges	= ARRAY_SIZE(bd79124_precious_ranges),
+};
+
+static const struct regmap_config bd79124_regmap = {
+	.reg_bits		= 16,
+	.val_bits		= 8,
+	.read_flag_mask		= BD79124_I2C_MULTI_READ,
+	.write_flag_mask	= BD79124_I2C_MULTI_WRITE,
+	.max_register		= BD79124_REG_MAX,
+	.cache_type		= REGCACHE_MAPLE,
+	.volatile_table		= &bd79124_volatile_regs,
+	.wr_table		= &bd79124_ro_regs,
+	.precious_table		= &bd79124_precious_regs,
+};
+
+static int bd79124gpo_direction_get(struct gpio_chip *gc, unsigned int offset)
+{
+	return GPIO_LINE_DIRECTION_OUT;
+}
+
+static void bd79124gpo_set(struct gpio_chip *gc, unsigned int offset, int value)
+{
+	struct bd79124_data *data = gpiochip_get_data(gc);
+
+	if (value)
+		regmap_set_bits(data->map, BD79124_REG_GPO_VAL, BIT(offset));
+	else
+		regmap_clear_bits(data->map, BD79124_REG_GPO_VAL, BIT(offset));
+}
+
+static void bd79124gpo_set_multiple(struct gpio_chip *gc, unsigned long *mask,
+				    unsigned long *bits)
+{
+	unsigned int val;
+	int ret;
+	struct bd79124_data *data = gpiochip_get_data(gc);
+
+	/* Ensure all GPIOs in 'mask' are set to be GPIOs */
+	ret = regmap_read(data->map, BD79124_REG_PINCFG, &val);
+	if (ret)
+		return;
+
+	if ((val & *mask) != *mask) {
+		dev_dbg(data->dev, "Invalid mux config. Can't set value.\n");
+		/* Do not set value for pins configured as ADC inputs */
+		*mask &= val;
+	}
+
+	regmap_update_bits(data->map, BD79124_REG_GPO_VAL, *mask, *bits);
+}
+
+static int bd79124_init_valid_mask(struct gpio_chip *gc,
+				   unsigned long *valid_mask,
+				   unsigned int ngpios)
+{
+	struct bd79124_data *data = gpiochip_get_data(gc);
+
+	*valid_mask = data->gpio_valid_mask;
+
+	return 0;
+}
+
+/* Template for GPIO chip */
+static const struct gpio_chip bd79124gpo_chip = {
+	.label			= "bd79124-gpo",
+	.get_direction		= bd79124gpo_direction_get,
+	.set			= bd79124gpo_set,
+	.set_multiple		= bd79124gpo_set_multiple,
+	.init_valid_mask	= bd79124_init_valid_mask,
+	.can_sleep		= true,
+	.ngpio			= 8,
+	.base			= -1,
+};
+
+struct bd79124_raw {
+	u8 bit0_3; /* Is set in high bits of the byte */
+	u8 bit4_11;
+};
+#define BD79124_RAW_TO_INT(r) ((r.bit4_11 << 4) | (r.bit0_3 >> 4))
+#define BD79124_INT_TO_RAW(val) {					\
+	.bit4_11 = (val) >> 4,						\
+	.bit0_3 = (val) << 4,						\
+}
+
+/*
+ * The high and low limits as well as the recent result values are stored in
+ * the same way in 2 consequent registers. The first register contains 4 bits
+ * of the value. These bits are stored in the high bits [7:4] of register, but
+ * they represent the low bits [3:0] of the value.
+ * The value bits [11:4] are stored in the next register.
+ *
+ * Read data from register and convert to integer.
+ */
+static int bd79124_read_reg_to_int(struct bd79124_data *data, int reg,
+				   unsigned int *val)
+{
+	int ret;
+	struct bd79124_raw raw;
+
+	ret = regmap_bulk_read(data->map, reg, &raw, sizeof(raw));
+	if (ret) {
+		dev_dbg(data->dev, "bulk_read failed %d\n", ret);
+
+		return ret;
+	}
+
+	*val = BD79124_RAW_TO_INT(raw);
+
+	return 0;
+}
+
+/*
+ * The high and low limits as well as the recent result values are stored in
+ * the same way in 2 consequent registers. The first register contains 4 bits
+ * of the value. These bits are stored in the high bits [7:4] of register, but
+ * they represent the low bits [3:0] of the value.
+ * The value bits [11:4] are stored in the next register.
+ *
+ * Convert the integer to register format and write it using rmw cycle.
+ */
+static int bd79124_write_int_to_reg(struct bd79124_data *data, int reg,
+				    unsigned int val)
+{
+	struct bd79124_raw raw = BD79124_INT_TO_RAW(val);
+	unsigned int tmp;
+	int ret;
+
+	ret = regmap_read(data->map, reg, &tmp);
+	if (ret)
+		return ret;
+
+	raw.bit0_3 |= (0xf & tmp);
+
+	return regmap_bulk_write(data->map, reg, &raw, sizeof(raw));
+}
+
+static const struct iio_event_spec bd79124_events[] = {
+	{
+		.type = IIO_EV_TYPE_THRESH,
+		.dir = IIO_EV_DIR_RISING,
+		.mask_separate = BIT(IIO_EV_INFO_VALUE) |
+				 BIT(IIO_EV_INFO_ENABLE),
+	},
+	{
+		.type = IIO_EV_TYPE_THRESH,
+		.dir = IIO_EV_DIR_FALLING,
+		.mask_separate = BIT(IIO_EV_INFO_VALUE) |
+				 BIT(IIO_EV_INFO_ENABLE),
+	},
+	{
+		.type = IIO_EV_TYPE_THRESH,
+		.dir = IIO_EV_DIR_EITHER,
+		.mask_separate = BIT(IIO_EV_INFO_HYSTERESIS),
+	},
+};
+
+static const struct iio_chan_spec bd79124_chan_template_noirq = {
+	.type = IIO_VOLTAGE,
+	.info_mask_separate = BIT(IIO_CHAN_INFO_RAW),
+	.info_mask_shared_by_type = BIT(IIO_CHAN_INFO_SCALE),
+	.indexed = 1,
+};
+
+static const struct iio_chan_spec bd79124_chan_template = {
+	.type = IIO_VOLTAGE,
+	.info_mask_separate = BIT(IIO_CHAN_INFO_RAW),
+	.info_mask_shared_by_type = BIT(IIO_CHAN_INFO_SCALE),
+	.indexed = 1,
+	.event_spec = bd79124_events,
+	.num_event_specs = ARRAY_SIZE(bd79124_events),
+};
+
+static int bd79124_read_event_value(struct iio_dev *iio_dev,
+				    const struct iio_chan_spec *chan,
+				    enum iio_event_type type,
+				    enum iio_event_direction dir,
+				    enum iio_event_info info, int *val,
+				    int *val2)
+{
+	struct bd79124_data *data = iio_priv(iio_dev);
+	int ret, reg;
+
+	if (chan->channel >= BD79124_MAX_NUM_CHANNELS)
+		return -EINVAL;
+
+	switch (info) {
+	case IIO_EV_INFO_VALUE:
+		if (dir == IIO_EV_DIR_RISING)
+			*val = data->alarm_r_limit[chan->channel];
+		else if (dir == IIO_EV_DIR_FALLING)
+			*val = data->alarm_f_limit[chan->channel];
+		else
+			return -EINVAL;
+
+		return IIO_VAL_INT;
+
+	case IIO_EV_INFO_HYSTERESIS:
+		reg = BD79124_GET_HYSTERESIS_REG(chan->channel);
+		ret = regmap_read(data->map, reg, val);
+		if (ret)
+			return ret;
+
+		*val &= BD79124_MSK_HYSTERESIS;
+		/*
+		 * The data-sheet says the hysteresis register value needs to be
+		 * sifted left by 3.
+		 */
+		*val <<= 3;
+
+		return IIO_VAL_INT;
+	default:
+		return -EINVAL;
+	}
+}
+
+static int bd79124_start_measurement(struct bd79124_data *data, int chan)
+{
+	unsigned int val, regval;
+	int ret;
+
+	/* See if already started */
+	ret = regmap_read(data->map, BD79124_REG_AUTO_CHANNELS, &val);
+	if (val & BIT(chan))
+		return 0;
+
+	/*
+	 * The sequencer must be stopped when channels are added/removed from
+	 * the list of the measured channels to ensure the new channel
+	 * configuration is used.
+	 */
+	ret = regmap_clear_bits(data->map, BD79124_REG_SEQ_CFG,
+				BD79124_MSK_SEQ_START);
+	if (ret)
+		return ret;
+
+	ret = regmap_write(data->map, BD79124_REG_AUTO_CHANNELS, val | BIT(chan));
+	if (ret)
+		return ret;
+
+	ret = regmap_set_bits(data->map, BD79124_REG_SEQ_CFG,
+			      BD79124_MSK_SEQ_START);
+	if (ret)
+		return ret;
+
+	/*
+	 * Start the measurement at the background. Don't bother checking if
+	 * it was started, regmap has cache.
+	 */
+	regval = FIELD_PREP(BD79124_MSK_CONV_MODE, BD79124_CONV_MODE_AUTO);
+
+	return regmap_update_bits(data->map, BD79124_REG_OPMODE_CFG,
+				BD79124_MSK_CONV_MODE, regval);
+}
+
+static int bd79124_stop_measurement(struct bd79124_data *data, int chan)
+{
+	unsigned int val;
+	int ret;
+
+	/* See if already stopped */
+	ret = regmap_read(data->map, BD79124_REG_AUTO_CHANNELS, &val);
+	if (!(val & BIT(chan)))
+		return 0;
+
+	ret = regmap_clear_bits(data->map, BD79124_REG_SEQ_CFG,
+				BD79124_MSK_SEQ_START);
+
+	/* Clear the channel from the measured channels */
+	ret = regmap_write(data->map, BD79124_REG_AUTO_CHANNELS,
+			   ~BIT(chan) & val);
+	if (ret)
+		return ret;
+
+	/*
+	 * Stop background conversion for power saving if it was the last
+	 * channel
+	 */
+	if (!(~BIT(chan) & val)) {
+		int regval = FIELD_PREP(BD79124_MSK_CONV_MODE,
+					BD79124_CONV_MODE_MANSEQ);
+
+		ret = regmap_update_bits(data->map, BD79124_REG_OPMODE_CFG,
+					 BD79124_MSK_CONV_MODE, regval);
+		if (ret)
+			return ret;
+	}
+
+	return regmap_set_bits(data->map, BD79124_REG_SEQ_CFG,
+			       BD79124_MSK_SEQ_START);
+}
+
+static int bd79124_read_event_config(struct iio_dev *iio_dev,
+				     const struct iio_chan_spec *chan,
+				     enum iio_event_type type,
+				     enum iio_event_direction dir)
+{
+	struct bd79124_data *data = iio_priv(iio_dev);
+
+	if (chan->channel >= BD79124_MAX_NUM_CHANNELS)
+		return -EINVAL;
+
+	return !!(data->alarm_monitored[chan->channel] & BIT(dir));
+}
+
+static int bd79124_disable_event(struct bd79124_data *data,
+				 enum iio_event_direction dir, int channel)
+{
+	int dir_bit = BIT(dir);
+	int reg;
+	unsigned int limit;
+
+	guard(mutex)(&data->mutex);
+	/*
+	 * Set thresholds either to 0 or to 2^12 - 1 as appropriate to prevent
+	 * alerts and thus disable event generation.
+	 */
+	if (dir == IIO_EV_DIR_RISING) {
+		reg = BD79124_GET_HIGH_LIMIT_REG(channel);
+		limit = BD79124_HIGH_LIMIT_MAX;
+	} else if (dir == IIO_EV_DIR_FALLING) {
+		reg = BD79124_GET_LOW_LIMIT_REG(channel);
+		limit = BD79124_LOW_LIMIT_MIN;
+	} else {
+		return -EINVAL;
+	}
+
+	data->alarm_monitored[channel] &= ~dir_bit;
+	/*
+	 * Stop measurement if there is no more events to monitor.
+	 * We don't bother checking the retval because the limit
+	 * setting should in any case effectively disable the alarm.
+	 */
+	if (!data->alarm_monitored[channel]) {
+		bd79124_stop_measurement(data, channel);
+		regmap_clear_bits(data->map, BD79124_REG_ALERT_CH_SEL,
+				  BIT(channel));
+	}
+
+	return bd79124_write_int_to_reg(data, reg, limit);
+}
+
+static int bd79124_enable_event(struct bd79124_data *data,
+				enum iio_event_direction dir,
+				unsigned int channel)
+{
+	int dir_bit = BIT(dir);
+	int reg, ret;
+	u16 *limit;
+
+	guard(mutex)(&data->mutex);
+	ret = bd79124_start_measurement(data, channel);
+	if (ret)
+		return ret;
+
+	data->alarm_monitored[channel] |= dir_bit;
+
+	/* Add the channel to the list of monitored channels */
+	ret = regmap_set_bits(data->map, BD79124_REG_ALERT_CH_SEL,
+			      BIT(channel));
+	if (ret)
+		return ret;
+
+	if (dir == IIO_EV_DIR_RISING) {
+		limit = &data->alarm_f_limit[channel];
+		reg = BD79124_GET_HIGH_LIMIT_REG(channel);
+	} else {
+		limit = &data->alarm_f_limit[channel];
+		reg = BD79124_GET_LOW_LIMIT_REG(channel);
+	}
+	/*
+	 * Don't write the new limit to the hardware if we are in the
+	 * rate-limit period. The timer which re-enables the event will set
+	 * the limit.
+	 */
+	if (!(data->alarm_suppressed[channel] & dir_bit)) {
+		ret = bd79124_write_int_to_reg(data, reg, *limit);
+		if (ret)
+			return ret;
+	}
+
+	/*
+	 * Enable comparator. Trust the regmap cache, no need to check
+	 * if it was already enabled.
+	 *
+	 * We could do this in the hw-init, but there may be users who
+	 * never enable alarms and for them it makes sense to not
+	 * enable the comparator at probe.
+	 */
+	return regmap_set_bits(data->map, BD79124_REG_GEN_CFG,
+				      BD79124_MSK_DWC_EN);
+}
+
+static int bd79124_write_event_config(struct iio_dev *iio_dev,
+				      const struct iio_chan_spec *chan,
+				      enum iio_event_type type,
+				      enum iio_event_direction dir, bool state)
+{
+	struct bd79124_data *data = iio_priv(iio_dev);
+
+	if (chan->channel >= BD79124_MAX_NUM_CHANNELS)
+		return -EINVAL;
+
+	if (state)
+		return bd79124_enable_event(data, dir, chan->channel);
+
+	return bd79124_disable_event(data, dir, chan->channel);
+}
+
+static int bd79124_write_event_value(struct iio_dev *iio_dev,
+				     const struct iio_chan_spec *chan,
+				     enum iio_event_type type,
+				     enum iio_event_direction dir,
+				     enum iio_event_info info, int val,
+				     int val2)
+{
+	struct bd79124_data *data = iio_priv(iio_dev);
+	int reg;
+
+	if (chan->channel >= BD79124_MAX_NUM_CHANNELS)
+		return -EINVAL;
+
+	switch (info) {
+	case IIO_EV_INFO_VALUE:
+		if (dir == IIO_EV_DIR_RISING) {
+			guard(mutex)(&data->mutex);
+
+			data->alarm_r_limit[chan->channel] = val;
+			reg = BD79124_GET_HIGH_LIMIT_REG(chan->channel);
+		} else if (dir == IIO_EV_DIR_FALLING) {
+			guard(mutex)(&data->mutex);
+
+			data->alarm_f_limit[chan->channel] = val;
+			reg = BD79124_GET_LOW_LIMIT_REG(chan->channel);
+		} else {
+			return -EINVAL;
+		}
+		/*
+		 * We don't want to enable the alarm if it is not enabled or
+		 * if it is suppressed. In that case skip writing to the
+		 * register.
+		 */
+		if (!(data->alarm_monitored[chan->channel] & BIT(dir)) ||
+		    data->alarm_suppressed[chan->channel] & BIT(dir))
+			return 0;
+
+		return bd79124_write_int_to_reg(data, reg, val);
+
+	case IIO_EV_INFO_HYSTERESIS:
+		reg = BD79124_GET_HYSTERESIS_REG(chan->channel);
+		val >>= 3;
+
+		return regmap_update_bits(data->map, reg, BD79124_MSK_HYSTERESIS,
+					  val);
+	default:
+		return -EINVAL;
+	}
+}
+
+static int bd79124_single_chan_seq(struct bd79124_data *data, int chan, unsigned int *old)
+{
+	int ret;
+
+	ret = regmap_clear_bits(data->map, BD79124_REG_SEQ_CFG,
+				BD79124_MSK_SEQ_START);
+	if (ret)
+		return ret;
+
+	/*
+	 * It may be we have some channels monitored for alarms so we want to
+	 * cache the old config and return it when the single channel
+	 * measurement has been completed.
+	 */
+	ret = regmap_read(data->map, BD79124_REG_AUTO_CHANNELS, old);
+	if (ret)
+		return ret;
+
+	ret = regmap_write(data->map, BD79124_REG_AUTO_CHANNELS, BIT(chan));
+	if (ret)
+		return ret;
+
+	/* Restart the sequencer */
+	return regmap_set_bits(data->map, BD79124_REG_SEQ_CFG,
+			       BD79124_MSK_SEQ_START);
+}
+
+static int bd79124_single_chan_seq_end(struct bd79124_data *data, unsigned int old)
+{
+	int ret;
+
+	ret = regmap_clear_bits(data->map, BD79124_REG_SEQ_CFG,
+				BD79124_MSK_SEQ_START);
+	if (ret)
+		return ret;
+
+	ret = regmap_write(data->map, BD79124_REG_AUTO_CHANNELS, old);
+	if (ret)
+		return ret;
+
+	return regmap_set_bits(data->map, BD79124_REG_SEQ_CFG,
+			       BD79124_MSK_SEQ_START);
+}
+
+static int bd79124_read_raw(struct iio_dev *iio_dev,
+			    struct iio_chan_spec const *chan,
+			    int *val, int *val2, long m)
+{
+	struct bd79124_data *data = iio_priv(iio_dev);
+	int ret;
+
+	if (chan->channel >= BD79124_MAX_NUM_CHANNELS)
+		return -EINVAL;
+
+	switch (m) {
+	case IIO_CHAN_INFO_RAW:
+	{
+		unsigned int old_chan_cfg, regval;
+		int tmp;
+
+		guard(mutex)(&data->mutex);
+
+		/*
+		 * Start the automatic conversion. This is needed here if no
+		 * events have been enabled.
+		 */
+		regval = FIELD_PREP(BD79124_MSK_CONV_MODE,
+				    BD79124_CONV_MODE_AUTO);
+		ret = regmap_update_bits(data->map, BD79124_REG_OPMODE_CFG,
+					 BD79124_MSK_CONV_MODE, regval);
+		if (ret)
+			return ret;
+
+		ret = bd79124_single_chan_seq(data, chan->channel, &old_chan_cfg);
+		if (ret)
+			return ret;
+
+		/* The maximum conversion time is 6 uS. */
+		udelay(6);
+
+		ret = bd79124_read_reg_to_int(data,
+			BD79124_GET_RECENT_RES_REG(chan->channel), val);
+		/*
+		 * Return the old chan config even if data reading failed in
+		 * order to re-enable the event monitoring.
+		 */
+		tmp = bd79124_single_chan_seq_end(data, old_chan_cfg);
+		if (tmp)
+			dev_err(data->dev,
+				"Failed to return config. Alarms may be disabled\n");
+
+		if (ret)
+			return ret;
+
+		return IIO_VAL_INT;
+	}
+	case IIO_CHAN_INFO_SCALE:
+		*val = data->vmax / 1000;
+		*val2 = BD79124_ADC_BITS;
+		return IIO_VAL_FRACTIONAL_LOG2;
+	default:
+		return -EINVAL;
+	}
+}
+
+static const struct iio_info bd79124_info = {
+	.read_raw = bd79124_read_raw,
+	.read_event_config = &bd79124_read_event_config,
+	.write_event_config = &bd79124_write_event_config,
+	.read_event_value = &bd79124_read_event_value,
+	.write_event_value = &bd79124_write_event_value,
+};
+
+static void bd79124_re_enable_lo(struct bd79124_data *data, unsigned int channel)
+{
+	int ret, evbit = BIT(IIO_EV_DIR_FALLING);
+
+	/*
+	 * We should not re-enable the event if user has disabled it while
+	 * rate-limiting was enabled.
+	 */
+	if (!(data->alarm_suppressed[channel] & evbit))
+		return;
+
+	data->alarm_suppressed[channel] &= ~evbit;
+
+	if (!(data->alarm_monitored[channel] & evbit))
+		return;
+
+	ret = bd79124_write_int_to_reg(data, BD79124_GET_LOW_LIMIT_REG(channel),
+				       data->alarm_f_limit[channel]);
+	if (ret)
+		dev_warn(data->dev, "Low limit enabling failed for channel%d\n",
+			 channel);
+}
+
+static void bd79124_re_enable_hi(struct bd79124_data *data, unsigned int channel)
+{
+	int ret, evbit = BIT(IIO_EV_DIR_RISING);
+
+	/*
+	 * We should not re-enable the event if user has disabled it while
+	 * rate-limiting was enabled.
+	 */
+	if (!(data->alarm_suppressed[channel] & evbit))
+		return;
+
+	data->alarm_suppressed[channel] &= ~evbit;
+
+	if (!(data->alarm_monitored[channel] & evbit))
+		return;
+
+	ret = bd79124_write_int_to_reg(data, BD79124_GET_HIGH_LIMIT_REG(channel),
+				       data->alarm_r_limit[channel]);
+	if (ret)
+		dev_warn(data->dev, "High limit enabling failed for channel%d\n",
+			 channel);
+}
+
+static void bd79124_alm_enable_worker(struct work_struct *work)
+{
+	int i;
+	struct bd79124_data *data = container_of(work, struct bd79124_data,
+						 alm_enable_work.work);
+
+	/* Take the mutex so there is no race with user disabling the alarm */
+	guard(mutex)(&data->mutex);
+	for (i = 0; i < BD79124_MAX_NUM_CHANNELS; i++) {
+		bd79124_re_enable_hi(data, i);
+		bd79124_re_enable_lo(data, i);
+	}
+}
+
+static int __bd79124_event_ratelimit(struct bd79124_data *data, int reg,
+				     unsigned int limit)
+{
+	int ret;
+
+	if (limit > BD79124_HIGH_LIMIT_MAX)
+		return -EINVAL;
+
+	ret = bd79124_write_int_to_reg(data, reg, limit);
+	if (ret)
+		return ret;
+
+	/*
+	 * We use 1 sec 'grace period'. At the moment I see no reason to make
+	 * this user configurable. We need an ABI for this if configuration is
+	 * needed.
+	 */
+	schedule_delayed_work(&data->alm_enable_work,
+			      msecs_to_jiffies(1000));
+
+	return 0;
+}
+
+static int bd79124_event_ratelimit_hi(struct bd79124_data *data,
+				      unsigned int channel)
+{
+	guard(mutex)(&data->mutex);
+	data->alarm_suppressed[channel] |= BIT(IIO_EV_DIR_RISING);
+
+	return __bd79124_event_ratelimit(data,
+					 BD79124_GET_HIGH_LIMIT_REG(channel),
+					 BD79124_HIGH_LIMIT_MAX);
+}
+
+static int bd79124_event_ratelimit_lo(struct bd79124_data *data,
+				      unsigned int channel)
+{
+	guard(mutex)(&data->mutex);
+	data->alarm_suppressed[channel] |= BIT(IIO_EV_DIR_FALLING);
+
+	return __bd79124_event_ratelimit(data,
+					 BD79124_GET_LOW_LIMIT_REG(channel),
+					 BD79124_LOW_LIMIT_MIN);
+}
+
+static irqreturn_t bd79124_event_handler(int irq, void *priv)
+{
+	unsigned int i_hi, i_lo;
+	int i, ret;
+	struct iio_dev *iio_dev = priv;
+	struct bd79124_data *data = iio_priv(iio_dev);
+
+	/*
+	 * Return IRQ_NONE if bailing-out without acking. This allows the IRQ
+	 * subsystem to disable the offending IRQ line if we get a hardware
+	 * problem. This behaviour has saved my poor bottom a few times in the
+	 * past as, instead of getting unusably unresponsive, the system has
+	 * spilled out the magic words "...nobody cared".
+	 */
+	ret = regmap_read(data->map, BD79124_REG_EVENT_FLAG_HI, &i_hi);
+	if (ret)
+		return IRQ_NONE;
+
+	ret = regmap_read(data->map, BD79124_REG_EVENT_FLAG_LO, &i_lo);
+	if (ret)
+		return IRQ_NONE;
+
+	if (!i_lo && !i_hi)
+		return IRQ_NONE;
+
+	for (i = 0; i < BD79124_MAX_NUM_CHANNELS; i++) {
+		u64 ecode;
+
+		if (BIT(i) & i_hi) {
+			ecode = IIO_UNMOD_EVENT_CODE(IIO_VOLTAGE, i,
+						     IIO_EV_TYPE_THRESH,
+						     IIO_EV_DIR_RISING);
+
+			iio_push_event(iio_dev, ecode, data->timestamp);
+			/*
+			 * The BD79124 keeps the IRQ asserted for as long as
+			 * the voltage exceeds the threshold. It causes the IRQ
+			 * to keep firing.
+			 *
+			 * Disable the event for the channel and schedule the
+			 * re-enabling the event later to prevent storm of
+			 * events.
+			 */
+			ret = bd79124_event_ratelimit_hi(data, i);
+			if (ret)
+				return IRQ_NONE;
+		}
+		if (BIT(i) & i_lo) {
+			ecode = IIO_UNMOD_EVENT_CODE(IIO_VOLTAGE, i,
+						     IIO_EV_TYPE_THRESH,
+						     IIO_EV_DIR_FALLING);
+
+			iio_push_event(iio_dev, ecode, data->timestamp);
+			ret = bd79124_event_ratelimit_lo(data, i);
+			if (ret)
+				return IRQ_NONE;
+		}
+	}
+
+	ret = regmap_write(data->map, BD79124_REG_EVENT_FLAG_HI, i_hi);
+	if (ret)
+		return IRQ_NONE;
+
+	ret = regmap_write(data->map, BD79124_REG_EVENT_FLAG_LO, i_lo);
+	if (ret)
+		return IRQ_NONE;
+
+	return IRQ_HANDLED;
+}
+
+static irqreturn_t bd79124_irq_handler(int irq, void *priv)
+{
+	struct iio_dev *iio_dev = priv;
+	struct bd79124_data *data = iio_priv(iio_dev);
+
+	data->timestamp = iio_get_time_ns(iio_dev);
+
+	return IRQ_WAKE_THREAD;
+}
+
+static int bd79124_chan_init(struct bd79124_data *data, int channel)
+{
+	int ret;
+
+	ret = regmap_write(data->map, BD79124_GET_HIGH_LIMIT_REG(channel),
+			   BD79124_HIGH_LIMIT_MAX);
+	if (ret)
+		return ret;
+
+	return regmap_write(data->map, BD79124_GET_LOW_LIMIT_REG(channel),
+			    BD79124_LOW_LIMIT_MIN);
+}
+
+static int bd79124_get_gpio_pins(const struct iio_chan_spec *cs, int num_channels)
+{
+	int i, gpio_channels;
+
+	/*
+	 * Let's initialize the mux config to say that all 8 channels are
+	 * GPIOs. Then we can just loop through the iio_chan_spec and clear the
+	 * bits for found ADC channels.
+	 */
+	gpio_channels = GENMASK(7, 0);
+	for (i = 0; i < num_channels; i++)
+		gpio_channels &= ~BIT(cs[i].channel);
+
+	return gpio_channels;
+}
+
+static int bd79124_hw_init(struct bd79124_data *data)
+{
+	unsigned int regval;
+	int ret, i;
+
+	for (i = 0; i < BD79124_MAX_NUM_CHANNELS; i++) {
+		ret = bd79124_chan_init(data, i);
+		if (ret)
+			return ret;
+		data->alarm_r_limit[i] = BD79124_HIGH_LIMIT_MAX;
+	}
+	/* Stop auto sequencer */
+	ret = regmap_clear_bits(data->map, BD79124_REG_SEQ_CFG,
+				BD79124_MSK_SEQ_START);
+	if (ret)
+		return ret;
+
+	/* Enable writing the measured values to the regsters */
+	ret = regmap_set_bits(data->map, BD79124_REG_GEN_CFG,
+			      BD79124_MSK_STATS_EN);
+	if (ret)
+		return ret;
+
+	/* Set no channels to be auto-measured */
+	ret = regmap_write(data->map, BD79124_REG_AUTO_CHANNELS, 0x0);
+	if (ret)
+		return ret;
+
+	/* Set no channels to be manually measured */
+	ret = regmap_write(data->map, BD79124_REG_MANUAL_CHANNELS, 0x0);
+	if (ret)
+		return ret;
+
+	regval = FIELD_PREP(BD79124_MSK_AUTO_INTERVAL, BD79124_INTERVAL_750_US);
+	ret = regmap_update_bits(data->map, BD79124_REG_OPMODE_CFG,
+				 BD79124_MSK_AUTO_INTERVAL, regval);
+	if (ret)
+		return ret;
+
+	/* Sequencer mode to auto */
+	ret = regmap_set_bits(data->map, BD79124_REG_SEQ_CFG,
+			      BD79124_MSK_SEQ_SEQ);
+	if (ret)
+		return ret;
+
+	/* Don't start the measurement */
+	regval = FIELD_PREP(BD79124_MSK_CONV_MODE, BD79124_CONV_MODE_MANSEQ);
+	return regmap_update_bits(data->map, BD79124_REG_OPMODE_CFG,
+				  BD79124_MSK_CONV_MODE, regval);
+}
+
+static int bd79124_probe(struct i2c_client *i2c)
+{
+	struct bd79124_data *data;
+	struct iio_dev *iio_dev;
+	const struct iio_chan_spec *template;
+	struct iio_chan_spec *cs;
+	struct device *dev = &i2c->dev;
+	unsigned int gpio_pins;
+	int ret;
+
+	iio_dev = devm_iio_device_alloc(dev, sizeof(*data));
+	if (!iio_dev)
+		return -ENOMEM;
+
+	data = iio_priv(iio_dev);
+	data->dev = dev;
+	data->map = devm_regmap_init_i2c(i2c, &bd79124_regmap);
+	if (IS_ERR(data->map))
+		return dev_err_probe(dev, PTR_ERR(data->map),
+				     "Failed to initialize Regmap\n");
+
+	ret = devm_regulator_get_enable_read_voltage(dev, "vdd");
+	if (ret < 0)
+		return dev_err_probe(dev, ret, "Failed to get the Vdd\n");
+
+	data->vmax = ret;
+
+	ret = devm_regulator_get_enable(dev, "iovdd");
+	if (ret < 0)
+		return dev_err_probe(dev, ret, "Failed to enable I/O voltage\n");
+
+	ret = devm_delayed_work_autocancel(dev, &data->alm_enable_work,
+					   bd79124_alm_enable_worker);
+	if (ret)
+		return ret;
+
+	if (i2c->irq) {
+		template = &bd79124_chan_template;
+	} else {
+		template = &bd79124_chan_template_noirq;
+		dev_dbg(dev, "No IRQ found, events disabled\n");
+	}
+
+	ret = devm_mutex_init(dev, &data->mutex);
+	if (ret)
+		return ret;
+
+	ret = devm_iio_adc_device_alloc_chaninfo_se(dev, template,
+		BD79124_MAX_NUM_CHANNELS - 1, &cs);
+	if (ret < 0) {
+		if (ret == -ENOENT)
+			goto register_gpios;
+		return ret;
+	}
+	iio_dev->channels = cs;
+	iio_dev->num_channels = ret;
+	iio_dev->info = &bd79124_info;
+	iio_dev->name = "bd79124";
+	iio_dev->modes = INDIO_DIRECT_MODE;
+
+	ret = bd79124_hw_init(data);
+	if (ret)
+		return ret;
+
+	if (i2c->irq > 0) {
+		ret = devm_request_threaded_irq(dev, i2c->irq,
+			bd79124_irq_handler, &bd79124_event_handler,
+			IRQF_ONESHOT, "adc-thresh-alert", iio_dev);
+		if (ret)
+			return dev_err_probe(data->dev, ret,
+					     "Failed to register IRQ\n");
+	}
+
+	ret = devm_iio_device_register(data->dev, iio_dev);
+	if (ret)
+		return dev_err_probe(data->dev, ret, "Failed to register ADC\n");
+
+register_gpios:
+	gpio_pins = bd79124_get_gpio_pins(iio_dev->channels,
+					  iio_dev->num_channels);
+
+	/*
+	 * The mux should default to "all ADCs", but better to not trust it.
+	 * Thus we do set the mux even when we have only ADCs and no GPOs.
+	 */
+	ret = regmap_write(data->map, BD79124_REG_PINCFG, gpio_pins);
+	if (ret)
+		return ret;
+
+	/* No GPOs if all channels are reserved for ADC, so we're done. */
+	if (!gpio_pins)
+		return 0;
+
+	data->gpio_valid_mask = gpio_pins;
+	data->gc = bd79124gpo_chip;
+	data->gc.parent = dev;
+
+	return devm_gpiochip_add_data(dev, &data->gc, data);
+}
+
+static const struct of_device_id bd79124_of_match[] = {
+	{ .compatible = "rohm,bd79124" },
+	{ }
+};
+MODULE_DEVICE_TABLE(of, bd79124_of_match);
+
+static const struct i2c_device_id bd79124_id[] = {
+	{ "bd79124" },
+	{ }
+};
+MODULE_DEVICE_TABLE(i2c, bd79124_id);
+
+static struct i2c_driver bd79124_driver = {
+	.driver = {
+		.name = "bd79124",
+		.of_match_table = bd79124_of_match,
+	},
+	.probe = bd79124_probe,
+	.id_table = bd79124_id,
+};
+module_i2c_driver(bd79124_driver);
+
+MODULE_AUTHOR("Matti Vaittinen <mazziesaccount@gmail.com>");
+MODULE_DESCRIPTION("Driver for ROHM BD79124 ADC");
+MODULE_LICENSE("GPL");
+MODULE_IMPORT_NS("IIO_DRIVER");
-- 
2.48.1


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [PATCH v8 06/10] iio: adc: Support ROHM BD79124 ADC

[Andy Shevchenko]

On Mon, Mar 17, 2025 at 05:51:25PM +0200, Matti Vaittinen wrote:
> The ROHM BD79124 is a 12-bit, 8-channel, SAR ADC. The ADC supports
> an automatic measurement mode, with an alarm interrupt for out-of-window
> measurements. The window is configurable for each channel.
> 
> The I2C protocol for manual start of the measurement and data reading is
> somewhat peculiar. It requires the master to do clock stretching after
> sending the I2C slave-address until the slave has captured the data.
> Needless to say this is not well suopported by the I2C controllers.
> 
> Thus do not support the BD79124's manual measurement mode but implement
> the measurements using automatic measurement mode, relying on the
> BD79124's ability of storing latest measurements into register.
> 
> Support also configuring the threshold events for detecting the
> out-of-window events.
> 
> The BD79124 keeps asserting IRQ for as long as the measured voltage is
> out of the configured window. Thus, prevent the user-space from choking
> on the events and mask the received event for a fixed duration (1 second)
> when an event is handled.
> 
> The ADC input pins can be also configured as general purpose outputs.
> Make those pins which don't have corresponding ADC channel node in the
> device-tree controllable as GPO.

...

> +#include <linux/bitfield.h>
> +#include <linux/bitmap.h>
> +#include <linux/bits.h>

bits.h is guaranteed by bitmap.h, but it's up to you to leave
or remove this line.

> +#include <linux/byteorder/generic.h>

This is incorrect. In some cases it even may produce build failures.
Should be asm/byteorder.h...

> +#include <linux/device.h>
> +#include <linux/delay.h>
> +#include <linux/devm-helpers.h>
> +#include <linux/err.h>
> +#include <linux/gpio/driver.h>
> +#include <linux/i2c.h>
> +#include <linux/interrupt.h>
> +#include <linux/irqreturn.h>
> +#include <linux/module.h>
> +#include <linux/mod_devicetable.h>
> +#include <linux/regmap.h>
> +#include <linux/types.h>

...somewhere here.

> +#include <linux/iio/events.h>
> +#include <linux/iio/iio.h>
> +#include <linux/iio/adc-helpers.h>

...

> +#define BD79124_GET_LIMIT_REG(ch, dir) ((dir) == IIO_EV_DIR_RISING ?		\
> +		BD79124_GET_HIGH_LIMIT_REG(ch) : BD79124_GET_LOW_LIMIT_REG(ch))

It's hard to read, better to split over few lines:

#define BD79124_GET_LIMIT_REG(ch, dir)						\
	((dir) == IIO_EV_DIR_RISING ?						\
		BD79124_GET_HIGH_LIMIT_REG(ch) : BD79124_GET_LOW_LIMIT_REG(ch))

or alike.

...

> +	/*
> +	 * The BD79124 does not allow disabling/enabling limit separately for
> +	 * one direction only. Hence, we do the disabling by changing the limit
> +	 * to maximum/minimum measurable value. This means we need to cache
> +	 * the limit in order to maintain it over the time limit is disabled.
> +	 */
> +	u16 alarm_r_limit[BD79124_MAX_NUM_CHANNELS];
> +	u16 alarm_f_limit[BD79124_MAX_NUM_CHANNELS];
> +	/* Bitmask of disabled events (for rate limiting) for each channel. */
> +	int alarm_suppressed[BD79124_MAX_NUM_CHANNELS];
> +	/*
> +	 * The BD79124 is configured to run the measurements in the background.
> +	 * This is done for the event monitoring as well as for the read_raw().
> +	 * Protect the measurement starting/stopping using a mutex.
> +	 */
> +	struct mutex mutex;
> +	struct delayed_work alm_enable_work;

> +	struct gpio_chip gc;

Hmm... Have you tried to shuffle fields to see if you gain a better code
generation. Also I don't remember if I asked about struct device *dev to be
the same as in regmap and would it be worse code without it?

> +	u8 gpio_valid_mask;

...

> +static void bd79124gpo_set(struct gpio_chip *gc, unsigned int offset, int value)
> +{
> +	struct bd79124_data *data = gpiochip_get_data(gc);
> +
> +	if (value)
> +		regmap_set_bits(data->map, BD79124_REG_GPO_VAL, BIT(offset));
> +	else
> +		regmap_clear_bits(data->map, BD79124_REG_GPO_VAL, BIT(offset));

regmap_assign_bits()

> +}

...

> +static void bd79124gpo_set_multiple(struct gpio_chip *gc, unsigned long *mask,
> +				    unsigned long *bits)
> +{
> +	unsigned int val;
> +	int ret;
> +	struct bd79124_data *data = gpiochip_get_data(gc);

> +	/* Ensure all GPIOs in 'mask' are set to be GPIOs */

This sounds like it can utilise valid_mask, but it seems you already have it.
So the question is what is the practical issue here? I believe the condition
below will never be the case.

> +	ret = regmap_read(data->map, BD79124_REG_PINCFG, &val);
> +	if (ret)
> +		return;

> +	if ((val & *mask) != *mask) {
> +		dev_dbg(data->dev, "Invalid mux config. Can't set value.\n");
> +		/* Do not set value for pins configured as ADC inputs */
> +		*mask &= val;
> +	}
> +
> +	regmap_update_bits(data->map, BD79124_REG_GPO_VAL, *mask, *bits);

Can you rather utilise the respective bitmap APIs?

> +}

...

> +struct bd79124_raw {
> +	u8 bit0_3; /* Is set in high bits of the byte */
> +	u8 bit4_11;
> +};
> +#define BD79124_RAW_TO_INT(r) ((r.bit4_11 << 4) | (r.bit0_3 >> 4))
> +#define BD79124_INT_TO_RAW(val) {					\
> +	.bit4_11 = (val) >> 4,						\
> +	.bit0_3 = (val) << 4,						\
> +}
> +
> +/*
> + * The high and low limits as well as the recent result values are stored in
> + * the same way in 2 consequent registers. The first register contains 4 bits
> + * of the value. These bits are stored in the high bits [7:4] of register, but
> + * they represent the low bits [3:0] of the value.

I believe this comment should go on top of the data structure. Also this is
still confusing as variable name above suggests one bit mapping, while text
here is referencing to another. Can you elaborate this more, please?

Like

	u8 foo_1; // represents bits 3 2 1 0 x x x x
	// ? or represents bits 0 1 2 3 x x x x

> + * The value bits [11:4] are stored in the next register.
> + *
> + * Read data from register and convert to integer.
> + */

...

> +static int bd79124_read_reg_to_int(struct bd79124_data *data, int reg,
> +				   unsigned int *val)
> +{
> +	int ret;
> +	struct bd79124_raw raw;
> +
> +	ret = regmap_bulk_read(data->map, reg, &raw, sizeof(raw));
> +	if (ret) {

> +		dev_dbg(data->dev, "bulk_read failed %d\n", ret);

Do we need this (and alike)? It can be achieved via regmap tracepoints.

> +		return ret;
> +	}
> +
> +	*val = BD79124_RAW_TO_INT(raw);
> +
> +	return 0;
> +}

...

> +/*
> + * The high and low limits as well as the recent result values are stored in
> + * the same way in 2 consequent registers. The first register contains 4 bits
> + * of the value. These bits are stored in the high bits [7:4] of register, but
> + * they represent the low bits [3:0] of the value.
> + * The value bits [11:4] are stored in the next register.

Same as above, rather comment once at data type.

> + * Convert the integer to register format and write it using rmw cycle.
> + */

...

> +	raw.bit0_3 |= (0xf & tmp);

Btw, why Yoda style?

...

> +static int bd79124_stop_measurement(struct bd79124_data *data, int chan)
> +{
> +	unsigned int val;
> +	int ret;
> +
> +	/* See if already stopped */
> +	ret = regmap_read(data->map, BD79124_REG_AUTO_CHANNELS, &val);
> +	if (!(val & BIT(chan)))
> +		return 0;
> +
> +	ret = regmap_clear_bits(data->map, BD79124_REG_SEQ_CFG,
> +				BD79124_MSK_SEQ_START);
> +
> +	/* Clear the channel from the measured channels */
> +	ret = regmap_write(data->map, BD79124_REG_AUTO_CHANNELS,
> +			   ~BIT(chan) & val);
> +	if (ret)
> +		return ret;
> +
> +	/*
> +	 * Stop background conversion for power saving if it was the last
> +	 * channel

Missing period.

> +	 */
> +	if (!(~BIT(chan) & val)) {

Seems to me as you have the same above, perhaps just update the val?

> +		int regval = FIELD_PREP(BD79124_MSK_CONV_MODE,
> +					BD79124_CONV_MODE_MANSEQ);
> +
> +		ret = regmap_update_bits(data->map, BD79124_REG_OPMODE_CFG,
> +					 BD79124_MSK_CONV_MODE, regval);
> +		if (ret)
> +			return ret;
> +	}
> +
> +	return regmap_set_bits(data->map, BD79124_REG_SEQ_CFG,
> +			       BD79124_MSK_SEQ_START);
> +}

...

> +	/* Add the channel to the list of monitored channels */
> +	ret = regmap_set_bits(data->map, BD79124_REG_ALERT_CH_SEL,
> +			      BIT(channel));

Perfectly one line, and you have similar cases with 82 characters already,
while here it's just 81.

> +	if (ret)
> +		return ret;

...

> +	return regmap_set_bits(data->map, BD79124_REG_GEN_CFG,
> +				      BD79124_MSK_DWC_EN);

Can be done here, as it's only 83 characters.

...

> +{
> +	struct bd79124_data *data = iio_priv(iio_dev);
> +	int reg;
> +
> +	if (chan->channel >= BD79124_MAX_NUM_CHANNELS)
> +		return -EINVAL;
> +
> +	switch (info) {
> +	case IIO_EV_INFO_VALUE:
> +		if (dir == IIO_EV_DIR_RISING) {
> +			guard(mutex)(&data->mutex);

What does this mutex protect? chan->channel access? I don't think so, then it
can be scoped_guard().

> +			data->alarm_r_limit[chan->channel] = val;
> +			reg = BD79124_GET_HIGH_LIMIT_REG(chan->channel);
> +		} else if (dir == IIO_EV_DIR_FALLING) {
> +			guard(mutex)(&data->mutex);

Ditto.

> +			data->alarm_f_limit[chan->channel] = val;
> +			reg = BD79124_GET_LOW_LIMIT_REG(chan->channel);
> +		} else {
> +			return -EINVAL;
> +		}
> +		/*
> +		 * We don't want to enable the alarm if it is not enabled or
> +		 * if it is suppressed. In that case skip writing to the
> +		 * register.
> +		 */
> +		if (!(data->alarm_monitored[chan->channel] & BIT(dir)) ||
> +		    data->alarm_suppressed[chan->channel] & BIT(dir))
> +			return 0;
> +
> +		return bd79124_write_int_to_reg(data, reg, val);
> +
> +	case IIO_EV_INFO_HYSTERESIS:
> +		reg = BD79124_GET_HYSTERESIS_REG(chan->channel);
> +		val >>= 3;
> +
> +		return regmap_update_bits(data->map, reg, BD79124_MSK_HYSTERESIS,
> +					  val);
> +	default:
> +		return -EINVAL;
> +	}
> +}

...

> +static int bd79124_read_raw(struct iio_dev *iio_dev,
> +			    struct iio_chan_spec const *chan,
> +			    int *val, int *val2, long m)
> +{
> +	struct bd79124_data *data = iio_priv(iio_dev);
> +	int ret;
> +
> +	if (chan->channel >= BD79124_MAX_NUM_CHANNELS)
> +		return -EINVAL;
> +
> +	switch (m) {
> +	case IIO_CHAN_INFO_RAW:
> +	{
> +		unsigned int old_chan_cfg, regval;
> +		int tmp;
> +
> +		guard(mutex)(&data->mutex);
> +
> +		/*
> +		 * Start the automatic conversion. This is needed here if no
> +		 * events have been enabled.
> +		 */

> +		regval = FIELD_PREP(BD79124_MSK_CONV_MODE,
> +				    BD79124_CONV_MODE_AUTO);

Only 83 characters for one line.

> +		ret = regmap_update_bits(data->map, BD79124_REG_OPMODE_CFG,
> +					 BD79124_MSK_CONV_MODE, regval);
> +		if (ret)
> +			return ret;
> +
> +		ret = bd79124_single_chan_seq(data, chan->channel, &old_chan_cfg);
> +		if (ret)
> +			return ret;
> +
> +		/* The maximum conversion time is 6 uS. */
> +		udelay(6);
> +
> +		ret = bd79124_read_reg_to_int(data,
> +			BD79124_GET_RECENT_RES_REG(chan->channel), val);
> +		/*
> +		 * Return the old chan config even if data reading failed in
> +		 * order to re-enable the event monitoring.
> +		 */
> +		tmp = bd79124_single_chan_seq_end(data, old_chan_cfg);
> +		if (tmp)
> +			dev_err(data->dev,
> +				"Failed to return config. Alarms may be disabled\n");
> +
> +		if (ret)
> +			return ret;
> +
> +		return IIO_VAL_INT;
> +	}
> +	case IIO_CHAN_INFO_SCALE:
> +		*val = data->vmax / 1000;
> +		*val2 = BD79124_ADC_BITS;
> +		return IIO_VAL_FRACTIONAL_LOG2;
> +	default:
> +		return -EINVAL;
> +	}
> +}

...

> +static int __bd79124_event_ratelimit(struct bd79124_data *data, int reg,
> +				     unsigned int limit)
> +{
> +	int ret;
> +
> +	if (limit > BD79124_HIGH_LIMIT_MAX)
> +		return -EINVAL;
> +
> +	ret = bd79124_write_int_to_reg(data, reg, limit);
> +	if (ret)
> +		return ret;
> +
> +	/*
> +	 * We use 1 sec 'grace period'. At the moment I see no reason to make
> +	 * this user configurable. We need an ABI for this if configuration is
> +	 * needed.
> +	 */
> +	schedule_delayed_work(&data->alm_enable_work,
> +			      msecs_to_jiffies(1000));

Perfectly one line even for the 80 character limit fanatics :-)

> +	return 0;
> +}

> +static int bd79124_get_gpio_pins(const struct iio_chan_spec *cs, int num_channels)
> +{
> +	int i, gpio_channels;
> +
> +	/*
> +	 * Let's initialize the mux config to say that all 8 channels are
> +	 * GPIOs. Then we can just loop through the iio_chan_spec and clear the
> +	 * bits for found ADC channels.
> +	 */
> +	gpio_channels = GENMASK(7, 0);
> +	for (i = 0; i < num_channels; i++)
> +		gpio_channels &= ~BIT(cs[i].channel);
> +
> +	return gpio_channels;
> +}

...

> +	ret = devm_iio_adc_device_alloc_chaninfo_se(dev, template,
> +		BD79124_MAX_NUM_CHANNELS - 1, &cs);
> +	if (ret < 0) {
> +		if (ret == -ENOENT)
> +			goto register_gpios;
> +		return ret;
> +	}

Also can be written as

	ret = devm_iio_adc_device_alloc_chaninfo_se(dev, template,
		BD79124_MAX_NUM_CHANNELS - 1, &cs);
	/* Register all channels as GPIOs in case no ADC functionality required */
	if (ret == -ENOENT)
		goto register_gpios;
	if (ret < 0)
		return ret;

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH v8 06/10] iio: adc: Support ROHM BD79124 ADC

[Matti Vaittinen]

On 17/03/2025 18:43, Andy Shevchenko wrote:
> On Mon, Mar 17, 2025 at 05:51:25PM +0200, Matti Vaittinen wrote:
>> The ROHM BD79124 is a 12-bit, 8-channel, SAR ADC. The ADC supports
>> an automatic measurement mode, with an alarm interrupt for out-of-window
>> measurements. The window is configurable for each channel.
>>
>> The I2C protocol for manual start of the measurement and data reading is
>> somewhat peculiar. It requires the master to do clock stretching after
>> sending the I2C slave-address until the slave has captured the data.
>> Needless to say this is not well suopported by the I2C controllers.
>>
>> Thus do not support the BD79124's manual measurement mode but implement
>> the measurements using automatic measurement mode, relying on the
>> BD79124's ability of storing latest measurements into register.
>>
>> Support also configuring the threshold events for detecting the
>> out-of-window events.
>>
>> The BD79124 keeps asserting IRQ for as long as the measured voltage is
>> out of the configured window. Thus, prevent the user-space from choking
>> on the events and mask the received event for a fixed duration (1 second)
>> when an event is handled.
>>
>> The ADC input pins can be also configured as general purpose outputs.
>> Make those pins which don't have corresponding ADC channel node in the
>> device-tree controllable as GPO.
> 
> ...
> 
>> +#include <linux/bitfield.h>
>> +#include <linux/bitmap.h>
>> +#include <linux/bits.h>
> 
> bits.h is guaranteed by bitmap.h, but it's up to you to leave
> or remove this line.
> 
>> +#include <linux/byteorder/generic.h>
> 
> This is incorrect. In some cases it even may produce build failures.
> Should be asm/byteorder.h...

I had no idea. Thanks.

>> +#include <linux/device.h>
>> +#include <linux/delay.h>
>> +#include <linux/devm-helpers.h>
>> +#include <linux/err.h>
>> +#include <linux/gpio/driver.h>
>> +#include <linux/i2c.h>
>> +#include <linux/interrupt.h>
>> +#include <linux/irqreturn.h>
>> +#include <linux/module.h>
>> +#include <linux/mod_devicetable.h>
>> +#include <linux/regmap.h>
>> +#include <linux/types.h>
> 
> ...somewhere here.

What is the rationale having the "asm/byteorder.h" located down here?

> 
>> +#include <linux/iio/events.h>
>> +#include <linux/iio/iio.h>
>> +#include <linux/iio/adc-helpers.h>
> 
> ...
> 
>> +#define BD79124_GET_LIMIT_REG(ch, dir) ((dir) == IIO_EV_DIR_RISING ?		\
>> +		BD79124_GET_HIGH_LIMIT_REG(ch) : BD79124_GET_LOW_LIMIT_REG(ch))
> 
> It's hard to read, better to split over few lines:
> 
> #define BD79124_GET_LIMIT_REG(ch, dir)						\
> 	((dir) == IIO_EV_DIR_RISING ?						\
> 		BD79124_GET_HIGH_LIMIT_REG(ch) : BD79124_GET_LOW_LIMIT_REG(ch))
> 
> or alike.
> 
> ...
> 
>> +	/*
>> +	 * The BD79124 does not allow disabling/enabling limit separately for
>> +	 * one direction only. Hence, we do the disabling by changing the limit
>> +	 * to maximum/minimum measurable value. This means we need to cache
>> +	 * the limit in order to maintain it over the time limit is disabled.
>> +	 */
>> +	u16 alarm_r_limit[BD79124_MAX_NUM_CHANNELS];
>> +	u16 alarm_f_limit[BD79124_MAX_NUM_CHANNELS];
>> +	/* Bitmask of disabled events (for rate limiting) for each channel. */
>> +	int alarm_suppressed[BD79124_MAX_NUM_CHANNELS];
>> +	/*
>> +	 * The BD79124 is configured to run the measurements in the background.
>> +	 * This is done for the event monitoring as well as for the read_raw().
>> +	 * Protect the measurement starting/stopping using a mutex.
>> +	 */
>> +	struct mutex mutex;
>> +	struct delayed_work alm_enable_work;
> 
>> +	struct gpio_chip gc;
> 
> Hmm... Have you tried to shuffle fields to see if you gain a better code
> generation.

No, I haven't. Effects of such suffling would in any case depend on the 
architecture. Furthermore, it is not expected there will be really many 
instances of this structure so potential savings would be negligible.

> Also I don't remember if I asked about struct device *dev to be
> the same as in regmap and would it be worse code without it?

Not sure I understood your comment. Are you suggesting I would extract 
the device pointer from the regmap in every function where it is needed, 
instead of storing it here?

If so, I prefer storing the pointer in probe and have it directly usable 
where prints are wanted/needed. Results cleaner looking code with the 
cost of one pointer. And again, it is not expected to see this struct 
instantiated a lot. If this happens we can go optimizing, but until that 
I prefer cleaner code.

>> +	u8 gpio_valid_mask;
> 
> ...
> 
>> +static void bd79124gpo_set(struct gpio_chip *gc, unsigned int offset, int value)
>> +{
>> +	struct bd79124_data *data = gpiochip_get_data(gc);
>> +
>> +	if (value)
>> +		regmap_set_bits(data->map, BD79124_REG_GPO_VAL, BIT(offset));
>> +	else
>> +		regmap_clear_bits(data->map, BD79124_REG_GPO_VAL, BIT(offset));
> 
> regmap_assign_bits()

Thanks. I think I've missed introduction of this function :)

> 
>> +}
> 
> ...
> 
>> +static void bd79124gpo_set_multiple(struct gpio_chip *gc, unsigned long *mask,
>> +				    unsigned long *bits)
>> +{
>> +	unsigned int val;
>> +	int ret;
>> +	struct bd79124_data *data = gpiochip_get_data(gc);
> 
>> +	/* Ensure all GPIOs in 'mask' are set to be GPIOs */
> 
> This sounds like it can utilise valid_mask, but it seems you already have it.

Yes.

> So the question is what is the practical issue here? I believe the condition
> below will never be the case.

It can until this gets merged:
https://lore.kernel.org/all/cd5e067b80e1bb590027bc3bfa817e7f794f21c3.1741180097.git.mazziesaccount@gmail.com/

Furthermore, the cost of the check is fairly low. Knowing that the 
drivers tend to get backported (because very few if any device makers 
use latest kernels) I will keep it here for couple of cycles.

>> +	ret = regmap_read(data->map, BD79124_REG_PINCFG, &val);
>> +	if (ret)
>> +		return;
> 
>> +	if ((val & *mask) != *mask) {
>> +		dev_dbg(data->dev, "Invalid mux config. Can't set value.\n");
>> +		/* Do not set value for pins configured as ADC inputs */
>> +		*mask &= val;
>> +	}
>> +
>> +	regmap_update_bits(data->map, BD79124_REG_GPO_VAL, *mask, *bits);
> 
> Can you rather utilise the respective bitmap APIs?

Please elaborate. Which APIs and what's the added benefit? It's not easy 
for me to see how this could get much simpler.

> 
>> +}
> 
> ...
> 
>> +struct bd79124_raw {
>> +	u8 bit0_3; /* Is set in high bits of the byte */
>> +	u8 bit4_11;
>> +};
>> +#define BD79124_RAW_TO_INT(r) ((r.bit4_11 << 4) | (r.bit0_3 >> 4))
>> +#define BD79124_INT_TO_RAW(val) {					\
>> +	.bit4_11 = (val) >> 4,						\
>> +	.bit0_3 = (val) << 4,						\
>> +}
>> +
>> +/*
>> + * The high and low limits as well as the recent result values are stored in
>> + * the same way in 2 consequent registers. The first register contains 4 bits
>> + * of the value. These bits are stored in the high bits [7:4] of register, but
>> + * they represent the low bits [3:0] of the value.
> 
> I believe this comment should go on top of the data structure.

Not sure. I think having this comment preceding the functions which are 
actually used to read/write the register makes sense. The structs / 
macros are only used from this function. Anyone who needs to be reading 
this code _after_ the review stage, is likely to trace the execution of 
the functions (and see the structure definitions only when they're used 
from a function) and not go jumping through the structures alone. Hence, 
having the explanation of a register layout on top of a function which 
reads / writes the register.

> Also this is
> still confusing as variable name above suggests one bit mapping, while text
> here is referencing to another. Can you elaborate this more, please?

Huh? Sorry, but I think the text and variable names match.

Variable names in:
struct bd79124_raw {
	u8 bit0_3; /* Is set in high bits of the byte */
	u8 bit4_11;
};

represent the value. Eg, first byte contains the bits [3:0] of the 12bit 
value. Comment tells that these bits are stored to the high bits of the 
register.
Similarly the "bit4_11" represents the bits of the value. I am fairly 
sure you didn't think the "bit4_11" was referring to bits of a 8-bit 
register...

> 
> Like
> 
> 	u8 foo_1; // represents bits 3 2 1 0 x x x x
> 	// ? or represents bits 0 1 2 3 x x x x

Now, I don't understand what you're saying here. I've a feeling that 
type of comment would just make it more confusing - at least for me.

I suppose I could do:
  struct bd79124_raw {
-       u8 bit0_3; /* Is set in high bits of the byte */
-       u8 bit4_11;
+       u8 val_bit0_3; /* Is set in high bits of the byte */
+       u8 val_bit4_11;
  };

but I am not at all sure this would help?

>> + * The value bits [11:4] are stored in the next register.
>> + *
>> + * Read data from register and convert to integer.
>> + */
> 
> ...
> 
>> +static int bd79124_read_reg_to_int(struct bd79124_data *data, int reg,
>> +				   unsigned int *val)
>> +{
>> +	int ret;
>> +	struct bd79124_raw raw;
>> +
>> +	ret = regmap_bulk_read(data->map, reg, &raw, sizeof(raw));
>> +	if (ret) {
> 
>> +		dev_dbg(data->dev, "bulk_read failed %d\n", ret);
> 
> Do we need this (and alike)? It can be achieved via regmap tracepoints.

I can't speak on anyone else's behalf, but when things fail I am still 
looking at the prints as a first step. This includes enabling the debugs 
too. Something like regmap tracepoints would come to play only if I 
can't find anything using the prints - although, I am not sure I 
wouldn't try _adding_ prints prior using tracepoints.

This is especially true in use-case like this one. This is a path which 
handles the user's data-reading. Imagine you're reading ADC data:

cat /sys/bus/iio/.../..._raw

and get an error. I (and I believe many others) would say "dmesg" (or 
equivalent) as next step. If nothing is visible, changing log level and 
retrying would be my next step.

regmap tracepoints? Maybe after seeing the "bulk_read failed" - but not 
as a first thing to try. And, it's not like the driver has polluted each 
regmap call-site with prints, so cost is again negligible.

>> +		return ret;
>> +	}
>> +
>> +	*val = BD79124_RAW_TO_INT(raw);
>> +
>> +	return 0;
>> +}
> 
> ...
> 
>> +/*
>> + * The high and low limits as well as the recent result values are stored in
>> + * the same way in 2 consequent registers. The first register contains 4 bits
>> + * of the value. These bits are stored in the high bits [7:4] of register, but
>> + * they represent the low bits [3:0] of the value.
>> + * The value bits [11:4] are stored in the next register.
> 
> Same as above, rather comment once at data type.

I think this comment is tightly related to the purpose of this function.
> 
>> + * Convert the integer to register format and write it using rmw cycle.
>> + */
> 
> ...
> 
>> +	raw.bit0_3 |= (0xf & tmp);
> 
> Btw, why Yoda style?

I had to google the Yoda style. So, I assume you mean why:

0xf & tmp
and not
tmp & 0xf.

Absolutely for no reason. I suppose it has just been flowing out of my 
fingers that way :) It can be flipped if it bothers.

>> +static int bd79124_stop_measurement(struct bd79124_data *data, int chan)
>> +{
>> +	unsigned int val;
>> +	int ret;
>> +
>> +	/* See if already stopped */
>> +	ret = regmap_read(data->map, BD79124_REG_AUTO_CHANNELS, &val);
>> +	if (!(val & BIT(chan)))
>> +		return 0;
>> +
>> +	ret = regmap_clear_bits(data->map, BD79124_REG_SEQ_CFG,
>> +				BD79124_MSK_SEQ_START);
>> +
>> +	/* Clear the channel from the measured channels */
>> +	ret = regmap_write(data->map, BD79124_REG_AUTO_CHANNELS,
>> +			   ~BIT(chan) & val);
>> +	if (ret)
>> +		return ret;
>> +
>> +	/*
>> +	 * Stop background conversion for power saving if it was the last
>> +	 * channel
>> +	 */
>> +	if (!(~BIT(chan) & val)) {
> 
> Seems to me as you have the same above, perhaps just update the val?

Good catch. This gets much more readable if the 'val' is renamed as 
'enabled_chans' and updated in place. Thanks!

>> +		int regval = FIELD_PREP(BD79124_MSK_CONV_MODE,
>> +					BD79124_CONV_MODE_MANSEQ);
>> +
>> +		ret = regmap_update_bits(data->map, BD79124_REG_OPMODE_CFG,
>> +					 BD79124_MSK_CONV_MODE, regval);
>> +		if (ret)
>> +			return ret;
>> +	}
>> +
>> +	return regmap_set_bits(data->map, BD79124_REG_SEQ_CFG,
>> +			       BD79124_MSK_SEQ_START);
>> +}

...

> Can be done here, as it's only 83 characters.

The 80 char lines is something we already discussed several times. Won't 
reply on other places.

> ...
> 
>> +{
>> +	struct bd79124_data *data = iio_priv(iio_dev);
>> +	int reg;
>> +
>> +	if (chan->channel >= BD79124_MAX_NUM_CHANNELS)
>> +		return -EINVAL;
>> +
>> +	switch (info) {
>> +	case IIO_EV_INFO_VALUE:
>> +		if (dir == IIO_EV_DIR_RISING) {
>> +			guard(mutex)(&data->mutex);
> 
> What does this mutex protect? chan->channel access? I don't think so, then it
> can be scoped_guard().

I am not sure I understand what you are after here. I'd be grateful if 
you explained.

In any case, after taking another look at this, I think the check for 
suppressed/monitored alarms below is racy. It looks like the mutex 
should be held for the duration of the whole "case IIO_EV_INFO_VALUE" 
here. So, thanks.

> 
>> +			data->alarm_r_limit[chan->channel] = val;
>> +			reg = BD79124_GET_HIGH_LIMIT_REG(chan->channel);
>> +		} else if (dir == IIO_EV_DIR_FALLING) {
>> +			guard(mutex)(&data->mutex);
> 
> Ditto.
> 
>> +			data->alarm_f_limit[chan->channel] = val;
>> +			reg = BD79124_GET_LOW_LIMIT_REG(chan->channel);
>> +		} else {
>> +			return -EINVAL;
>> +		}
>> +		/*
>> +		 * We don't want to enable the alarm if it is not enabled or
>> +		 * if it is suppressed. In that case skip writing to the
>> +		 * register.
>> +		 */
>> +		if (!(data->alarm_monitored[chan->channel] & BIT(dir)) ||
>> +		    data->alarm_suppressed[chan->channel] & BIT(dir))
>> +			return 0;
>> +
>> +		return bd79124_write_int_to_reg(data, reg, val);
>> +
>> +	case IIO_EV_INFO_HYSTERESIS:
>> +		reg = BD79124_GET_HYSTERESIS_REG(chan->channel);
>> +		val >>= 3;
>> +
>> +		return regmap_update_bits(data->map, reg, BD79124_MSK_HYSTERESIS,
>> +					  val);
>> +	default:
>> +		return -EINVAL;
>> +	}
>> +}
> 
> ...
 >
>> +static int __bd79124_event_ratelimit(struct bd79124_data *data, int reg,
>> +				     unsigned int limit)
>> +{
>> +	int ret;
>> +
>> +	if (limit > BD79124_HIGH_LIMIT_MAX)
>> +		return -EINVAL;
>> +
>> +	ret = bd79124_write_int_to_reg(data, reg, limit);
>> +	if (ret)
>> +		return ret;
>> +
>> +	/*
>> +	 * We use 1 sec 'grace period'. At the moment I see no reason to make
>> +	 * this user configurable. We need an ABI for this if configuration is
>> +	 * needed.
>> +	 */
>> +	schedule_delayed_work(&data->alm_enable_work,
>> +			      msecs_to_jiffies(1000));
> 
> Perfectly one line even for the 80 character limit fanatics :-)

Thanks!

> 
>> +	return 0;
>> +}
> 
>> +static int bd79124_get_gpio_pins(const struct iio_chan_spec *cs, int num_channels)
>> +{
>> +	int i, gpio_channels;
>> +
>> +	/*
>> +	 * Let's initialize the mux config to say that all 8 channels are
>> +	 * GPIOs. Then we can just loop through the iio_chan_spec and clear the
>> +	 * bits for found ADC channels.
>> +	 */
>> +	gpio_channels = GENMASK(7, 0);
>> +	for (i = 0; i < num_channels; i++)
>> +		gpio_channels &= ~BIT(cs[i].channel);
>> +
>> +	return gpio_channels;
>> +}
> 
> ...
> 
>> +	ret = devm_iio_adc_device_alloc_chaninfo_se(dev, template,
>> +		BD79124_MAX_NUM_CHANNELS - 1, &cs);
>> +	if (ret < 0) {
>> +		if (ret == -ENOENT)
>> +			goto register_gpios;
>> +		return ret;
>> +	}
> 
> Also can be written as
> 
> 	ret = devm_iio_adc_device_alloc_chaninfo_se(dev, template,
> 		BD79124_MAX_NUM_CHANNELS - 1, &cs);
> 	/* Register all channels as GPIOs in case no ADC functionality required */

I like the comment you added.

> 	if (ret == -ENOENT)
> 		goto register_gpios;
> 	if (ret < 0)
> 		return ret;

We don't need the other check when return value is > 0. This should be 
the majority of cases. The no ADC channels case is very unlikely because 
this IC is meant to be an ADC. Original code reflects that better.

Thanks for the review.

Yours,
	-- Matti

[PATCH v8 07/10] MAINTAINERS: Add IIO ADC helpers

[Matti Vaittinen]

[-- Attachment #1: Type: text/plain, Size: 804 bytes --]

Add undersigned as a maintainer for the IIO ADC helpers.

Signed-off-by: Matti Vaittinen <mazziesaccount@gmail.com>
---
Revision history:
v2 =>
 - No changes
RFC v1 => v2:
 - New patch
---
 MAINTAINERS | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 8e0736dc2ee0..5b96fb864227 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -11208,6 +11208,13 @@ L:	linux-media@vger.kernel.org
 S:	Maintained
 F:	drivers/media/rc/iguanair.c
 
+IIO ADC HELPERS
+M:	Matti Vaittinen <mazziesaccount@gmail.com>
+L:	linux-iio@vger.kernel.org
+S:	Maintained
+F:	drivers/iio/adc/industrialio-adc.c
+F:	include/linux/iio/adc-helpers.h
+
 IIO BACKEND FRAMEWORK
 M:	Nuno Sa <nuno.sa@analog.com>
 R:	Olivier Moysan <olivier.moysan@foss.st.com>
-- 
2.48.1


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

[PATCH v8 08/10] MAINTAINERS: Add ROHM BD79124 ADC/GPO

[Matti Vaittinen]

[-- Attachment #1: Type: text/plain, Size: 789 bytes --]

Add undersigned as a maintainer for the ROHM BD79124 ADC/GPO driver.

Signed-off-by: Matti Vaittinen <mazziesaccount@gmail.com>
---
Revision history:
v2 =>
 - No changes
RFC v1 => v2:
 - Drop MFD and pinmux drivers
---
 MAINTAINERS | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 5b96fb864227..2e4416b59930 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -20547,6 +20547,11 @@ S:	Supported
 F:	drivers/power/supply/bd99954-charger.c
 F:	drivers/power/supply/bd99954-charger.h
 
+ROHM BD79124 ADC / GPO IC
+M:	Matti Vaittinen <mazziesaccount@gmail.com>
+S:	Supported
+F:	drivers/iio/adc/rohm-bd79124.c
+
 ROHM BH1745 COLOUR SENSOR
 M:	Mudit Sharma <muditsharma.info@gmail.com>
 L:	linux-iio@vger.kernel.org
-- 
2.48.1


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

[PATCH net-next v8 09/10] net: gianfar: Use device_get_child_node_count_named()

[Matti Vaittinen]

[-- Attachment #1: Type: text/plain, Size: 2403 bytes --]

We can avoid open-coding the loop construct which counts firmware child
nodes with a specific name by using the newly added
device_get_child_node_count_named().

The gianfar driver has such open-coded loop. Replace it with the
device_get_child_node_count_named().

Suggested-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Matti Vaittinen <mazziesaccount@gmail.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
---
Revision history:
v6 =>:
 - No changes
v5 (RFC) => v6:
 - Drop RFC
 - Adapt to changed function name.

It's fair to tell the pros and cons of this patch.
The simplification is there, but it's not a big one. It comes with a cost
of getting the property.h included in this driver which currently uses
exclusively the of_* APIs.

NOTE: This patch depends on the patch:
[2/10] "property: Add functions to iterate named child"

Compile-tested only!
---
 drivers/net/ethernet/freescale/gianfar.c | 17 ++++-------------
 1 file changed, 4 insertions(+), 13 deletions(-)

diff --git a/drivers/net/ethernet/freescale/gianfar.c b/drivers/net/ethernet/freescale/gianfar.c
index 435138f4699d..d4ee0fc843be 100644
--- a/drivers/net/ethernet/freescale/gianfar.c
+++ b/drivers/net/ethernet/freescale/gianfar.c
@@ -97,6 +97,7 @@
 #include <linux/phy_fixed.h>
 #include <linux/of.h>
 #include <linux/of_net.h>
+#include <linux/property.h>
 
 #include "gianfar.h"
 
@@ -571,18 +572,6 @@ static int gfar_parse_group(struct device_node *np,
 	return 0;
 }
 
-static int gfar_of_group_count(struct device_node *np)
-{
-	struct device_node *child;
-	int num = 0;
-
-	for_each_available_child_of_node(np, child)
-		if (of_node_name_eq(child, "queue-group"))
-			num++;
-
-	return num;
-}
-
 /* Reads the controller's registers to determine what interface
  * connects it to the PHY.
  */
@@ -654,8 +643,10 @@ static int gfar_of_init(struct platform_device *ofdev, struct net_device **pdev)
 		num_rx_qs = 1;
 	} else { /* MQ_MG_MODE */
 		/* get the actual number of supported groups */
-		unsigned int num_grps = gfar_of_group_count(np);
+		unsigned int num_grps;
 
+		num_grps = device_get_named_child_node_count(&ofdev->dev,
+							     "queue-group");
 		if (num_grps == 0 || num_grps > MAXGROUPS) {
 			dev_err(&ofdev->dev, "Invalid # of int groups(%d)\n",
 				num_grps);
-- 
2.48.1


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [PATCH net-next v8 09/10] net: gianfar: Use device_get_child_node_count_named()

[Simon Horman]

On Mon, Mar 17, 2025 at 05:52:25PM +0200, Matti Vaittinen wrote:
> We can avoid open-coding the loop construct which counts firmware child
> nodes with a specific name by using the newly added
> device_get_child_node_count_named().
> 
> The gianfar driver has such open-coded loop. Replace it with the
> device_get_child_node_count_named().
> 
> Suggested-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
> Signed-off-by: Matti Vaittinen <mazziesaccount@gmail.com>
> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>

This patch looks good to me.
But I think it would be best to resubmit it,
as a standalone patch for net-next, once
it's dependencies are present in net-next.

-- 
pw-bot: defer

Re: [PATCH net-next v8 09/10] net: gianfar: Use device_get_child_node_count_named()

[Matti Vaittinen]

On 19/03/2025 18:07, Simon Horman wrote:
> On Mon, Mar 17, 2025 at 05:52:25PM +0200, Matti Vaittinen wrote:
>> We can avoid open-coding the loop construct which counts firmware child
>> nodes with a specific name by using the newly added
>> device_get_child_node_count_named().
>>
>> The gianfar driver has such open-coded loop. Replace it with the
>> device_get_child_node_count_named().
>>
>> Suggested-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
>> Signed-off-by: Matti Vaittinen <mazziesaccount@gmail.com>
>> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
> 
> This patch looks good to me.
> But I think it would be best to resubmit it,
> as a standalone patch for net-next, once
> it's dependencies are present in net-next.

Thanks Simon. I think you're right.

[PATCH v8 10/10] media: thp7312: Use helper for iterating named child nodes

[Matti Vaittinen]

[-- Attachment #1: Type: text/plain, Size: 1221 bytes --]

Slightly simplify code iterating the child nodes with specific names
using the new fwnode_for_each_available_named_child_node().

Signed-off-by: Matti Vaittinen <mazziesaccount@gmail.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
---
Revision history:
v6 =>:
 - No changes
v5 => v6:
 - New patch

NOTE: This patch depends on the patch:
[2/10] "property: Add functions to iterate named child"

Compile-tested only!
---
 drivers/media/i2c/thp7312.c | 8 +++-----
 1 file changed, 3 insertions(+), 5 deletions(-)

diff --git a/drivers/media/i2c/thp7312.c b/drivers/media/i2c/thp7312.c
index 8852c56431fe..104754b2ace2 100644
--- a/drivers/media/i2c/thp7312.c
+++ b/drivers/media/i2c/thp7312.c
@@ -2067,11 +2067,9 @@ static int thp7312_parse_dt(struct thp7312_device *thp7312)
 		return -EINVAL;
 	}
 
-	fwnode_for_each_available_child_node(sensors, node) {
-		if (fwnode_name_eq(node, "sensor")) {
-			if (!thp7312_sensor_parse_dt(thp7312, node))
-				num_sensors++;
-		}
+	fwnode_for_each_available_named_child_node(sensors, node, "sensor") {
+		if (!thp7312_sensor_parse_dt(thp7312, node))
+			num_sensors++;
 	}
 
 	fwnode_handle_put(sensors);
-- 
2.48.1


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]