[PATCH v5 00/10] Support ROHM BD79124 ADC

[PATCH v5 00/10] Support ROHM BD79124 ADC

[Matti Vaittinen]

[-- Attachment #1: Type: text/plain, Size: 4904 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 two helpers
included for counting number of 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 is added as an RFC patch to use the newly
added firmware child node counting function.

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.

patch 6/10 is small simplification for the ti-ads7924, and it can be
taken independently from the rest of the series.

NOTE: Patches 4...6 and the patch 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:
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.
 Changes which were not proposed by reviewers:
 - rebase to v6.14-rc5
 - Do not include all recipients to all of the patches.
 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 count named child nodes
  iio: adc: add helpers for parsing ADC nodes
  iio: adc: rzg2l_adc: Use adc-helpers
  iio: adc: sun20i-gpadc: Use adc-helpers
  iio: adc: ti-ads7924 Drop unnecessary function parameters
  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()

 .../bindings/iio/adc/rohm,bd79124.yaml        |  114 ++
 MAINTAINERS                                   |   12 +
 drivers/base/property.c                       |   57 +
 drivers/iio/adc/Kconfig                       |   17 +
 drivers/iio/adc/Makefile                      |    3 +
 drivers/iio/adc/industrialio-adc.c            |   82 ++
 drivers/iio/adc/rohm-bd79124.c                | 1108 +++++++++++++++++
 drivers/iio/adc/rzg2l_adc.c                   |   38 +-
 drivers/iio/adc/sun20i-gpadc-iio.c            |   38 +-
 drivers/iio/adc/ti-ads7924.c                  |    7 +-
 drivers/net/ethernet/freescale/gianfar.c      |   17 +-
 include/linux/iio/adc-helpers.h               |   27 +
 include/linux/property.h                      |    4 +
 13 files changed, 1462 insertions(+), 62 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 v5 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 v5 02/10] property: Add functions to count named child nodes

[Matti Vaittinen]

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

There are some use-cases where child nodes with a specific name need to
be parsed. In a few cases the data from the found nodes is 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 a helpers for 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>
---
Revision history:
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  | 57 ++++++++++++++++++++++++++++++++++++++++
 include/linux/property.h |  4 +++
 2 files changed, 61 insertions(+)

diff --git a/drivers/base/property.c b/drivers/base/property.c
index c1392743df9c..3faf02b99cff 100644
--- a/drivers/base/property.c
+++ b/drivers/base/property.c
@@ -945,6 +945,63 @@ unsigned int device_get_child_node_count(const struct device *dev)
 }
 EXPORT_SYMBOL_GPL(device_get_child_node_count);
 
+/**
+ * fwnode_get_child_node_count_named - 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. Return the
+ * number of found nodes. Potential '@number' -ending for scanned names is
+ * ignored. Eg,
+ * device_get_child_node_count(dev, "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_child_node_count_named(const struct fwnode_handle *fwnode,
+					       const char *name)
+{
+	struct fwnode_handle *child;
+	unsigned int count = 0;
+
+	fwnode_for_each_child_node(fwnode, child)
+		if (fwnode_name_eq(child, name))
+			count++;
+
+	return count;
+}
+EXPORT_SYMBOL_GPL(fwnode_get_child_node_count_named);
+
+/**
+ * device_get_child_node_count_named - number of child nodes with given name
+ * @dev: Device to count the child nodes for.
+ * @name: String to match child node name against.
+ *
+ * Scan device's child nodes and find all the nodes with a specific name and
+ * return the number of found nodes. Potential '@number' -ending for scanned
+ * names is ignored. Eg,
+ * device_get_child_node_count(dev, "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 device_get_child_node_count_named(const struct device *dev,
+					       const char *name)
+{
+	const struct fwnode_handle *fwnode = dev_fwnode(dev);
+
+	if (!fwnode)
+		return -EINVAL;
+
+	if (IS_ERR(fwnode))
+		return PTR_ERR(fwnode);
+
+	return fwnode_get_child_node_count_named(fwnode, name);
+}
+EXPORT_SYMBOL_GPL(device_get_child_node_count_named);
+
 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..269ab539515b 100644
--- a/include/linux/property.h
+++ b/include/linux/property.h
@@ -209,6 +209,10 @@ int fwnode_irq_get(const struct fwnode_handle *fwnode, unsigned int index);
 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_child_node_count_named(const struct fwnode_handle *fwnode,
+					       const char *name);
+unsigned int device_get_child_node_count_named(const struct device *dev,
+					       const char *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 --]

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

[Matti Vaittinen]

[-- Attachment #1: Type: text/plain, Size: 6220 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:
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..7bdae5330224
--- /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 -1 if no checking
+ *			is required.
+ * @cs:			Location where pointer to allocated iio_chan_spec
+ *			should be stored.
+ *
+ * Return:	Number of found channels on succes. Negative value to indicate
+ *		failure.
+ */
+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 = 0, ret;
+
+	num_chan = iio_adc_device_num_channels(dev);
+	if (num_chan < 1)
+		return num_chan;
+
+	chan_array = devm_kcalloc(dev, num_chan, sizeof(*chan_array),
+				  GFP_KERNEL);
+	if (!chan_array)
+		return -ENOMEM;
+
+	chan = &chan_array[0];
+
+	device_for_each_child_node_scoped(dev, child) {
+		u32 ch;
+
+		if (!fwnode_name_eq(child, "channel"))
+			continue;
+
+		ret = fwnode_property_read_u32(child, "reg", &ch);
+		if (ret)
+			return ret;
+
+		if (max_chan_id != -1 && 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..403a70b109ec
--- /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_child_node_count_named(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 --]

[PATCH v5 08/10] MAINTAINERS: Add IIO ADC helpers

[Matti Vaittinen]

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

Add undersigned as a maintainer for the IIO ADC helpers.

Signed-off-by: Matti Vaittinen <mazziesaccount@gmail.com>
---
Revision history:
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 --]

Re: [PATCH v5 02/10] property: Add functions to count named child nodes

[Heikki Krogerus]

Hi,

> +/**
> + * fwnode_get_child_node_count_named - 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. Return the
> + * number of found nodes. Potential '@number' -ending for scanned names is
> + * ignored. Eg,
> + * device_get_child_node_count(dev, "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_child_node_count_named(const struct fwnode_handle *fwnode,
> +					       const char *name)
> +{
> +	struct fwnode_handle *child;
> +	unsigned int count = 0;
> +
> +	fwnode_for_each_child_node(fwnode, child)
> +		if (fwnode_name_eq(child, name))
> +			count++;
> +
> +	return count;
> +}
> +EXPORT_SYMBOL_GPL(fwnode_get_child_node_count_named);
> +
> +/**
> + * device_get_child_node_count_named - number of child nodes with given name
> + * @dev: Device to count the child nodes for.
> + * @name: String to match child node name against.
> + *
> + * Scan device's child nodes and find all the nodes with a specific name and
> + * return the number of found nodes. Potential '@number' -ending for scanned
> + * names is ignored. Eg,
> + * device_get_child_node_count(dev, "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 device_get_child_node_count_named(const struct device *dev,
> +					       const char *name)
> +{
> +	const struct fwnode_handle *fwnode = dev_fwnode(dev);
> +
> +	if (!fwnode)
> +		return -EINVAL;
> +
> +	if (IS_ERR(fwnode))
> +		return PTR_ERR(fwnode);
> +
> +	return fwnode_get_child_node_count_named(fwnode, name);
> +}
> +EXPORT_SYMBOL_GPL(device_get_child_node_count_named);

Sorry if I missed something in the v4 thread, but why not do all the
checks in fwnode_get_child_node_count_named(), and make this an inline
function?

        static inline unsigned int
        device_get_child_node_count_named(const struct device *dev, const char *name)
        {
                return fwnode_get_child_node_count_named(dev_fwnode(fwnode), name);
        }

thanks,

-- 
heikki

Re: [PATCH v5 02/10] property: Add functions to count named child nodes

[Andy Shevchenko]

On Mon, Mar 03, 2025 at 01:31:45PM +0200, Matti Vaittinen wrote:
> There are some use-cases where child nodes with a specific name need to
> be parsed. In a few cases the data from the found nodes is 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 a helpers for counting device's sub-nodes with certain name instead
> of open-coding this in every user.

...

> +unsigned int fwnode_get_child_node_count_named(const struct fwnode_handle *fwnode,
> +					       const char *name)
> +{
> +	struct fwnode_handle *child;
> +	unsigned int count = 0;

> +	fwnode_for_each_child_node(fwnode, child)
> +		if (fwnode_name_eq(child, name))

I would expect this to be a separate macro

	fwnode_for_each_named_child_node()

(and its device variant) that gives us more consistent approach.

> +			count++;

And the above looks like missing {}, which won't be needed with the other
suggestion in place.

> +	return count;
> +}

> +	if (!fwnode)
> +		return -EINVAL;
> +
> +	if (IS_ERR(fwnode))
> +		return PTR_ERR(fwnode);

I expect that this will return 0 or number of nodes. Why do we need an error code?
If it's really required, it should be in the fwnode API above.

Also do we care about secondary fwnodes?

> +	return fwnode_get_child_node_count_named(fwnode, name);
> +}

...

> +unsigned int fwnode_get_child_node_count_named(const struct fwnode_handle *fwnode,
> +					       const char *name);

To me the following name sounds better: fwnode_get_named_child_node_count().

> +unsigned int device_get_child_node_count_named(const struct device *dev,
> +					       const char *name);

In the similar way.

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH v5 02/10] property: Add functions to count named child nodes

[Andy Shevchenko]

On Mon, Mar 03, 2025 at 01:50:13PM +0200, Heikki Krogerus wrote:

...

> > +unsigned int device_get_child_node_count_named(const struct device *dev,
> > +					       const char *name)
> > +{
> > +	const struct fwnode_handle *fwnode = dev_fwnode(dev);
> > +
> > +	if (!fwnode)
> > +		return -EINVAL;
> > +
> > +	if (IS_ERR(fwnode))
> > +		return PTR_ERR(fwnode);
> > +
> > +	return fwnode_get_child_node_count_named(fwnode, name);
> > +}
> > +EXPORT_SYMBOL_GPL(device_get_child_node_count_named);
> 
> Sorry if I missed something in the v4 thread, but why not do all the
> checks in fwnode_get_child_node_count_named(), and make this an inline
> function?

+1, or drop the checks and make it return 0 depending on the follow up use cases.

>         static inline unsigned int
>         device_get_child_node_count_named(const struct device *dev, const char *name)
>         {
>                 return fwnode_get_child_node_count_named(dev_fwnode(fwnode), name);
>         }

-- 
With Best Regards,
Andy Shevchenko

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

[David Lechner]

On Mon, Mar 3, 2025 at 12:32 PM Matti Vaittinen
<mazziesaccount@gmail.com> 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.
>
> Signed-off-by: Matti Vaittinen <mazziesaccount@gmail.com>
>
> ---
> Revision history:
> 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..7bdae5330224
> --- /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 -1 if no checking
> + *                     is required.
> + * @cs:                        Location where pointer to allocated iio_chan_spec
> + *                     should be stored.
> + *
> + * Return:     Number of found channels on succes. Negative value to indicate

s/succes/success/

> + *             failure.
> + */
> +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 = 0, ret;
> +
> +       num_chan = iio_adc_device_num_channels(dev);
> +       if (num_chan < 1)
> +               return num_chan;
> +
> +       chan_array = devm_kcalloc(dev, num_chan, sizeof(*chan_array),
> +                                 GFP_KERNEL);
> +       if (!chan_array)
> +               return -ENOMEM;
> +
> +       chan = &chan_array[0];
> +
> +       device_for_each_child_node_scoped(dev, child) {
> +               u32 ch;
> +
> +               if (!fwnode_name_eq(child, "channel"))
> +                       continue;
> +
> +               ret = fwnode_property_read_u32(child, "reg", &ch);
> +               if (ret)
> +                       return ret;
> +
> +               if (max_chan_id != -1 && ch > max_chan_id)
> +                       return -ERANGE;
> +

Should we use return dev_err_probe() on these to help with debugging a bad dtb?

> +               *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");

We can make this less verbose by setting #define
DEFAULT_SYMBOL_NAMESPACE at the start of the file. Then we can just do
EXPORT_SYMBOL_GPL() throughout the rest of the file.

Also, I would prefer if the namespace matched config name (IIO_ADC_HELPER).

> +
> +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..403a70b109ec
> --- /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_child_node_count_named(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);
> +

There are some different opinions on this, but on the last patch I did
introducing a new namespace, the consensus seems to be that putting
the MODULE_IMPORT_NS() in the header file was convenient so that users
of the API don't have to remember to both include the header and add
the import macro.

> +#endif /* _INDUSTRIAL_IO_ADC_HELPERS_H_ */
> --
> 2.48.1
>

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

[Andy Shevchenko]

On Tue, Mar 04, 2025 at 10:25:03AM +0100, David Lechner wrote:
> On Mon, Mar 3, 2025 at 12:32 PM Matti Vaittinen
> <mazziesaccount@gmail.com> wrote:

...

> There are some different opinions on this, but on the last patch I did
> introducing a new namespace,

> the consensus

Hmm... I may not call that "the consensus"...

> seems to be that putting
> the MODULE_IMPORT_NS() in the header file was convenient so that users
> of the API don't have to remember to both include the header and add
> the import macro.

Which I am against because it will diminish the point of prevention of
the APIs abuse along with a potential to have the stale headers in
the file when the code is moved somewhere else..

So, please do not do that. We have only two abusers currently:
the PWM and SPI OFFLOAD.

-- 
With Best Regards,
Andy Shevchenko

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

[Matti Vaittinen]

Thanks for the review David.

On 04/03/2025 11:25, David Lechner wrote:
> On Mon, Mar 3, 2025 at 12:32 PM Matti Vaittinen
> <mazziesaccount@gmail.com> 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.
>>
>> Signed-off-by: Matti Vaittinen <mazziesaccount@gmail.com>
>>
>> ---

>> + *
>> + * Return:     Number of found channels on succes. Negative value to indicate
> 
> s/succes/success/

Thanks!

>> +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 = 0, ret;
>> +
>> +       num_chan = iio_adc_device_num_channels(dev);
>> +       if (num_chan < 1)
>> +               return num_chan;
>> +
>> +       chan_array = devm_kcalloc(dev, num_chan, sizeof(*chan_array),
>> +                                 GFP_KERNEL);
>> +       if (!chan_array)
>> +               return -ENOMEM;
>> +
>> +       chan = &chan_array[0];
>> +
>> +       device_for_each_child_node_scoped(dev, child) {
>> +               u32 ch;
>> +
>> +               if (!fwnode_name_eq(child, "channel"))
>> +                       continue;
>> +
>> +               ret = fwnode_property_read_u32(child, "reg", &ch);
>> +               if (ret)
>> +                       return ret;
>> +
>> +               if (max_chan_id != -1 && ch > max_chan_id)
>> +                       return -ERANGE;
>> +
> 
> Should we use return dev_err_probe() on these to help with debugging a bad dtb?
> 

I am not fan of using dev_err_probe() in a 'library code'. This is 
because we never know if there'll be some odd use-case where this is not 
called from the probe.

All in all, I'd leave adding most of the debugs to the callers - 
especially because we do not expect to have bad device-trees after the 
initial 'development stage' of a board. The board 'development stage' 
should really reveal bugs which prevent the channels from being 
registered - and after the DT is correct, these debug prints become 
unnecessary (albeit minor) binary bloat.

>> +               *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");
> 
> We can make this less verbose by setting #define
> DEFAULT_SYMBOL_NAMESPACE at the start of the file. Then we can just do
> EXPORT_SYMBOL_GPL() throughout the rest of the file.

I am not sure what to think of this. I use the good old 'ctrl + ]' in my 
editor when I need to check how a function was supposed to be used. That 
jumps to the spot of code where the function is. I'd like to see the 
namespace mentioned there in order to not accidentally miss the fact the 
function belongs to one.

OTOH, I do like simplifications. Yet, the added simplification might not 
warrant the namespace not being visible in the function definition.

> Also, I would prefer if the namespace matched config name (IIO_ADC_HELPER).

I had some lengthy discussion about this with Andy and Jonathan during 
earlier review versions. In short, I don't like the idea of very 
fragmented namespaces in IIO, which will just complicate the drivers 
without providing any obvious benefit.

https://lore.kernel.org/all/20250222174842.57c091c5@jic23-huawei/

>> +
>> +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);
>> +
> 
> There are some different opinions on this, but on the last patch I did
> introducing a new namespace, the consensus seems to be that putting
> the MODULE_IMPORT_NS() in the header file was convenient so that users
> of the API don't have to remember to both include the header and add
> the import macro.
> 

I do like this suggestion, and I believe this would be the balance 
between getting the benefit of hiding part of the symbols - while not 
unnecessarily complicating the callers. I know some people are opposing 
it though. My personal opinion is that having the MODULE_IMPORT_NS() in 
a header would be neatly simplifying the calling code with very little 
harm, especially here where including the header hardly has use-cases 
outside the IIO ADC.

Unfortunately, the "safety" seems to often be a synonym for just "making 
it intentionally hard". As Finnish people say: "Kärsi, kärsi, 
kirkkaamman kruunun saat". :)
(Roughly translated as "Suffer, suffer, you will get a brighter crown").

Let's hear what Jonathan thinks of your suggestion.

Thanks!
	-- Matti

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

[Jonathan Cameron]

On Wed, 5 Mar 2025 12:54:33 +0200
Matti Vaittinen <mazziesaccount@gmail.com> wrote:

> Thanks for the review David.
> 
> On 04/03/2025 11:25, David Lechner wrote:
> > On Mon, Mar 3, 2025 at 12:32 PM Matti Vaittinen
> > <mazziesaccount@gmail.com> 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.
> >>
> >> Signed-off-by: Matti Vaittinen <mazziesaccount@gmail.com>
> >>
> >> ---  
> 
> >> + *
> >> + * Return:     Number of found channels on succes. Negative value to indicate  
> > 
> > s/succes/success/  
> 
> Thanks!
> 
> >> +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 = 0, ret;
> >> +
> >> +       num_chan = iio_adc_device_num_channels(dev);
> >> +       if (num_chan < 1)
> >> +               return num_chan;
> >> +
> >> +       chan_array = devm_kcalloc(dev, num_chan, sizeof(*chan_array),
> >> +                                 GFP_KERNEL);
> >> +       if (!chan_array)
> >> +               return -ENOMEM;
> >> +
> >> +       chan = &chan_array[0];
> >> +
> >> +       device_for_each_child_node_scoped(dev, child) {
> >> +               u32 ch;
> >> +
> >> +               if (!fwnode_name_eq(child, "channel"))
> >> +                       continue;
> >> +
> >> +               ret = fwnode_property_read_u32(child, "reg", &ch);
> >> +               if (ret)
> >> +                       return ret;
> >> +
> >> +               if (max_chan_id != -1 && ch > max_chan_id)
> >> +                       return -ERANGE;
> >> +  
> > 
> > Should we use return dev_err_probe() on these to help with debugging a bad dtb?
> >   
> 
> I am not fan of using dev_err_probe() in a 'library code'. This is 
> because we never know if there'll be some odd use-case where this is not 
> called from the probe.
> 
> All in all, I'd leave adding most of the debugs to the callers - 
> especially because we do not expect to have bad device-trees after the 
> initial 'development stage' of a board. The board 'development stage' 
> should really reveal bugs which prevent the channels from being 
> registered - and after the DT is correct, these debug prints become 
> unnecessary (albeit minor) binary bloat.
> 
> >> +               *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");  
> > 
> > We can make this less verbose by setting #define
> > DEFAULT_SYMBOL_NAMESPACE at the start of the file. Then we can just do
> > EXPORT_SYMBOL_GPL() throughout the rest of the file.  
> 
> I am not sure what to think of this. I use the good old 'ctrl + ]' in my 
> editor when I need to check how a function was supposed to be used. That 
> jumps to the spot of code where the function is. I'd like to see the 
> namespace mentioned there in order to not accidentally miss the fact the 
> function belongs to one.
> 
> OTOH, I do like simplifications. Yet, the added simplification might not 
> warrant the namespace not being visible in the function definition.
> 
> > Also, I would prefer if the namespace matched config name (IIO_ADC_HELPER).  
> 
> I had some lengthy discussion about this with Andy and Jonathan during 
> earlier review versions. In short, I don't like the idea of very 
> fragmented namespaces in IIO, which will just complicate the drivers 
> without providing any obvious benefit.
> 
> https://lore.kernel.org/all/20250222174842.57c091c5@jic23-huawei/
> 
> >> +
> >> +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);
> >> +  
> > 
> > There are some different opinions on this, but on the last patch I did
> > introducing a new namespace, the consensus seems to be that putting
> > the MODULE_IMPORT_NS() in the header file was convenient so that users
> > of the API don't have to remember to both include the header and add
> > the import macro.
> >   
> 
> I do like this suggestion, and I believe this would be the balance 
> between getting the benefit of hiding part of the symbols - while not 
> unnecessarily complicating the callers. I know some people are opposing 
> it though. My personal opinion is that having the MODULE_IMPORT_NS() in 
> a header would be neatly simplifying the calling code with very little 
> harm, especially here where including the header hardly has use-cases 
> outside the IIO ADC.
> 
> Unfortunately, the "safety" seems to often be a synonym for just "making 
> it intentionally hard". As Finnish people say: "Kärsi, kärsi, 
> kirkkaamman kruunun saat". :)
> (Roughly translated as "Suffer, suffer, you will get a brighter crown").
> 
> Let's hear what Jonathan thinks of your suggestion.

For this particular case my intent was that all the IIO exports that
are suitable for use in simple IIO drives will be in this namespace,
we just haven't started that conversion yet.

As such, having it defined from a header for this helper isn't a good
thing to do.  Generally I prefer to see in driver code what namespaces
are involved but do understand the other viewpoint. In this case I
definitely don't think it is appropriate unless we go for a specific namespace
for just this helper.

Jonathan

> 
> Thanks!
> 	-- Matti
> 

Re: [PATCH v5 02/10] property: Add functions to count named child nodes

[Matti Vaittinen]

On 03/03/2025 13:59, Andy Shevchenko wrote:
> On Mon, Mar 03, 2025 at 01:31:45PM +0200, Matti Vaittinen wrote:

...

> 
>> +	return count;
>> +}
> 
>> +	if (!fwnode)
>> +		return -EINVAL;
>> +
>> +	if (IS_ERR(fwnode))
>> +		return PTR_ERR(fwnode);
> 
> I expect that this will return 0 or number of nodes. Why do we need an error code?
> If it's really required, it should be in the fwnode API above.
> 
> Also do we care about secondary fwnodes?

We have the device_get_child_node_count(). 
device_get_child_node_count_named() should follow the same logic.

> 
>> +	return fwnode_get_child_node_count_named(fwnode, name);
>> +}
> 
> ...
> 
>> +unsigned int fwnode_get_child_node_count_named(const struct fwnode_handle *fwnode,
>> +					       const char *name);
> 
> To me the following name sounds better: fwnode_get_named_child_node_count().

Agree.

> 
>> +unsigned int device_get_child_node_count_named(const struct device *dev,
>> +					       const char *name);
> 
> In the similar way.
> 

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

[Matti Vaittinen]

On 08/03/2025 18:29, Jonathan Cameron wrote:
> On Wed, 5 Mar 2025 12:54:33 +0200
> Matti Vaittinen <mazziesaccount@gmail.com> wrote:
> 
>> Thanks for the review David.
>>
>> On 04/03/2025 11:25, David Lechner wrote:
>>> On Mon, Mar 3, 2025 at 12:32 PM Matti Vaittinen
>>> <mazziesaccount@gmail.com> 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.
>>>>
>>>> Signed-off-by: Matti Vaittinen <mazziesaccount@gmail.com>
>>>>
>>>> ---
>>
>>>> + *
>>>> + * Return:     Number of found channels on succes. Negative value to indicate
>>>
>>> s/succes/success/
>>
>> Thanks!
>>
>>>> +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 = 0, ret;
>>>> +
>>>> +       num_chan = iio_adc_device_num_channels(dev);
>>>> +       if (num_chan < 1)
>>>> +               return num_chan;
>>>> +
>>>> +       chan_array = devm_kcalloc(dev, num_chan, sizeof(*chan_array),
>>>> +                                 GFP_KERNEL);
>>>> +       if (!chan_array)
>>>> +               return -ENOMEM;
>>>> +
>>>> +       chan = &chan_array[0];
>>>> +
>>>> +       device_for_each_child_node_scoped(dev, child) {
>>>> +               u32 ch;
>>>> +
>>>> +               if (!fwnode_name_eq(child, "channel"))
>>>> +                       continue;
>>>> +
>>>> +               ret = fwnode_property_read_u32(child, "reg", &ch);
>>>> +               if (ret)
>>>> +                       return ret;
>>>> +
>>>> +               if (max_chan_id != -1 && ch > max_chan_id)
>>>> +                       return -ERANGE;
>>>> +
>>>
>>> Should we use return dev_err_probe() on these to help with debugging a bad dtb?
>>>    
>>
>> I am not fan of using dev_err_probe() in a 'library code'. This is
>> because we never know if there'll be some odd use-case where this is not
>> called from the probe.
>>
>> All in all, I'd leave adding most of the debugs to the callers -
>> especially because we do not expect to have bad device-trees after the
>> initial 'development stage' of a board. The board 'development stage'
>> should really reveal bugs which prevent the channels from being
>> registered - and after the DT is correct, these debug prints become
>> unnecessary (albeit minor) binary bloat.
>>
>>>> +               *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");
>>>
>>> We can make this less verbose by setting #define
>>> DEFAULT_SYMBOL_NAMESPACE at the start of the file. Then we can just do
>>> EXPORT_SYMBOL_GPL() throughout the rest of the file.
>>
>> I am not sure what to think of this. I use the good old 'ctrl + ]' in my
>> editor when I need to check how a function was supposed to be used. That
>> jumps to the spot of code where the function is. I'd like to see the
>> namespace mentioned there in order to not accidentally miss the fact the
>> function belongs to one.
>>
>> OTOH, I do like simplifications. Yet, the added simplification might not
>> warrant the namespace not being visible in the function definition.
>>
>>> Also, I would prefer if the namespace matched config name (IIO_ADC_HELPER).
>>
>> I had some lengthy discussion about this with Andy and Jonathan during
>> earlier review versions. In short, I don't like the idea of very
>> fragmented namespaces in IIO, which will just complicate the drivers
>> without providing any obvious benefit.
>>
>> https://lore.kernel.org/all/20250222174842.57c091c5@jic23-huawei/
>>
>>>> +
>>>> +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);
>>>> +
>>>
>>> There are some different opinions on this, but on the last patch I did
>>> introducing a new namespace, the consensus seems to be that putting
>>> the MODULE_IMPORT_NS() in the header file was convenient so that users
>>> of the API don't have to remember to both include the header and add
>>> the import macro.
>>>    
>>
>> I do like this suggestion, and I believe this would be the balance
>> between getting the benefit of hiding part of the symbols - while not
>> unnecessarily complicating the callers. I know some people are opposing
>> it though. My personal opinion is that having the MODULE_IMPORT_NS() in
>> a header would be neatly simplifying the calling code with very little
>> harm, especially here where including the header hardly has use-cases
>> outside the IIO ADC.
>>
>> Unfortunately, the "safety" seems to often be a synonym for just "making
>> it intentionally hard". As Finnish people say: "Kärsi, kärsi,
>> kirkkaamman kruunun saat". :)
>> (Roughly translated as "Suffer, suffer, you will get a brighter crown").
>>
>> Let's hear what Jonathan thinks of your suggestion.
> 
> For this particular case my intent was that all the IIO exports that
> are suitable for use in simple IIO drives will be in this namespace,
> we just haven't started that conversion yet.
> 
> As such, having it defined from a header for this helper isn't a good
> thing to do.

Hmm. I agree.

>  Generally I prefer to see in driver code what namespaces
> are involved but do understand the other viewpoint. In this case I
> definitely don't think it is appropriate unless we go for a specific namespace
> for just this helper.

I suppose having the MODULE_IMPORT_NS() in the header would actually 
make the more fine-grained namespaces (like IIO_ADC_HELPERS, IIO_GTS, 
...) much more usable. That'd relieved the drivers from explicitly 
listing multiple namespaces while nicely limiting the visibility.

If IIO was my territory, I might want to ask people to go with that 
approach - but I am quite happy being a freeloade.. errm, I mean, 
bystander ;)

Thanks!

Yours,
	-- Matti

Re: [PATCH v5 02/10] property: Add functions to count named child nodes

[Andy Shevchenko]

On Mon, Mar 10, 2025 at 08:23:15AM +0200, Matti Vaittinen wrote:
> On 03/03/2025 13:59, Andy Shevchenko wrote:
> > On Mon, Mar 03, 2025 at 01:31:45PM +0200, Matti Vaittinen wrote:

...

> > Also do we care about secondary fwnodes?
> 
> We have the device_get_child_node_count().
> device_get_child_node_count_named() should follow the same logic.

Okay, so we don't care about them right now.

-- 
With Best Regards,
Andy Shevchenko

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

[Jonathan Cameron]

On Mon, 10 Mar 2025 09:41:00 +0200
Matti Vaittinen <mazziesaccount@gmail.com> wrote:

> On 08/03/2025 18:29, Jonathan Cameron wrote:
> > On Wed, 5 Mar 2025 12:54:33 +0200
> > Matti Vaittinen <mazziesaccount@gmail.com> wrote:
> >   
> >> Thanks for the review David.
> >>
> >> On 04/03/2025 11:25, David Lechner wrote:  
> >>> On Mon, Mar 3, 2025 at 12:32 PM Matti Vaittinen
> >>> <mazziesaccount@gmail.com> 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.
> >>>>
> >>>> Signed-off-by: Matti Vaittinen <mazziesaccount@gmail.com>
> >>>>
> >>>> ---  
> >>  
> >>>> + *
> >>>> + * Return:     Number of found channels on succes. Negative value to indicate  
> >>>
> >>> s/succes/success/  
> >>
> >> Thanks!
> >>  
> >>>> +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 = 0, ret;
> >>>> +
> >>>> +       num_chan = iio_adc_device_num_channels(dev);
> >>>> +       if (num_chan < 1)
> >>>> +               return num_chan;
> >>>> +
> >>>> +       chan_array = devm_kcalloc(dev, num_chan, sizeof(*chan_array),
> >>>> +                                 GFP_KERNEL);
> >>>> +       if (!chan_array)
> >>>> +               return -ENOMEM;
> >>>> +
> >>>> +       chan = &chan_array[0];
> >>>> +
> >>>> +       device_for_each_child_node_scoped(dev, child) {
> >>>> +               u32 ch;
> >>>> +
> >>>> +               if (!fwnode_name_eq(child, "channel"))
> >>>> +                       continue;
> >>>> +
> >>>> +               ret = fwnode_property_read_u32(child, "reg", &ch);
> >>>> +               if (ret)
> >>>> +                       return ret;
> >>>> +
> >>>> +               if (max_chan_id != -1 && ch > max_chan_id)
> >>>> +                       return -ERANGE;
> >>>> +  
> >>>
> >>> Should we use return dev_err_probe() on these to help with debugging a bad dtb?
> >>>      
> >>
> >> I am not fan of using dev_err_probe() in a 'library code'. This is
> >> because we never know if there'll be some odd use-case where this is not
> >> called from the probe.
> >>
> >> All in all, I'd leave adding most of the debugs to the callers -
> >> especially because we do not expect to have bad device-trees after the
> >> initial 'development stage' of a board. The board 'development stage'
> >> should really reveal bugs which prevent the channels from being
> >> registered - and after the DT is correct, these debug prints become
> >> unnecessary (albeit minor) binary bloat.
> >>  
> >>>> +               *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");  
> >>>
> >>> We can make this less verbose by setting #define
> >>> DEFAULT_SYMBOL_NAMESPACE at the start of the file. Then we can just do
> >>> EXPORT_SYMBOL_GPL() throughout the rest of the file.  
> >>
> >> I am not sure what to think of this. I use the good old 'ctrl + ]' in my
> >> editor when I need to check how a function was supposed to be used. That
> >> jumps to the spot of code where the function is. I'd like to see the
> >> namespace mentioned there in order to not accidentally miss the fact the
> >> function belongs to one.
> >>
> >> OTOH, I do like simplifications. Yet, the added simplification might not
> >> warrant the namespace not being visible in the function definition.
> >>  
> >>> Also, I would prefer if the namespace matched config name (IIO_ADC_HELPER).  
> >>
> >> I had some lengthy discussion about this with Andy and Jonathan during
> >> earlier review versions. In short, I don't like the idea of very
> >> fragmented namespaces in IIO, which will just complicate the drivers
> >> without providing any obvious benefit.
> >>
> >> https://lore.kernel.org/all/20250222174842.57c091c5@jic23-huawei/
> >>  
> >>>> +
> >>>> +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);
> >>>> +  
> >>>
> >>> There are some different opinions on this, but on the last patch I did
> >>> introducing a new namespace, the consensus seems to be that putting
> >>> the MODULE_IMPORT_NS() in the header file was convenient so that users
> >>> of the API don't have to remember to both include the header and add
> >>> the import macro.
> >>>      
> >>
> >> I do like this suggestion, and I believe this would be the balance
> >> between getting the benefit of hiding part of the symbols - while not
> >> unnecessarily complicating the callers. I know some people are opposing
> >> it though. My personal opinion is that having the MODULE_IMPORT_NS() in
> >> a header would be neatly simplifying the calling code with very little
> >> harm, especially here where including the header hardly has use-cases
> >> outside the IIO ADC.
> >>
> >> Unfortunately, the "safety" seems to often be a synonym for just "making
> >> it intentionally hard". As Finnish people say: "Kärsi, kärsi,
> >> kirkkaamman kruunun saat". :)
> >> (Roughly translated as "Suffer, suffer, you will get a brighter crown").
> >>
> >> Let's hear what Jonathan thinks of your suggestion.  
> > 
> > For this particular case my intent was that all the IIO exports that
> > are suitable for use in simple IIO drives will be in this namespace,
> > we just haven't started that conversion yet.
> > 
> > As such, having it defined from a header for this helper isn't a good
> > thing to do.  
> 
> Hmm. I agree.
> 
> >  Generally I prefer to see in driver code what namespaces
> > are involved but do understand the other viewpoint. In this case I
> > definitely don't think it is appropriate unless we go for a specific namespace
> > for just this helper.  
> 
> I suppose having the MODULE_IMPORT_NS() in the header would actually 
> make the more fine-grained namespaces (like IIO_ADC_HELPERS, IIO_GTS, 
> ...) much more usable. That'd relieved the drivers from explicitly 
> listing multiple namespaces while nicely limiting the visibility.
> 
> If IIO was my territory, I might want to ask people to go with that 
> approach - but I am quite happy being a freeloade.. errm, I mean, 
> bystander ;)
> 
It relieves the burden but I'd still prefer explicit opt in to namespaces
unless there is general agreement on the approach of doing it in headers
which there has not been so far.

Jonathan

> Thanks!
> 
> Yours,
> 	-- Matti