* [PATCH v5 03/10] iio: adc: add helpers for parsing ADC nodes
2025-03-03 11:30 [PATCH v5 00/10] Support ROHM BD79124 ADC Matti Vaittinen
@ 2025-03-03 11:32 ` Matti Vaittinen
2025-03-04 9:25 ` David Lechner
2025-03-03 11:33 ` [PATCH v5 05/10] iio: adc: sun20i-gpadc: Use adc-helpers Matti Vaittinen
2025-03-03 11:34 ` [PATCH v5 08/10] MAINTAINERS: Add IIO ADC helpers Matti Vaittinen
2 siblings, 1 reply; 11+ messages in thread
From: Matti Vaittinen @ 2025-03-03 11:32 UTC (permalink / raw)
To: Matti Vaittinen, Matti Vaittinen
Cc: Jonathan Cameron, Lars-Peter Clausen, Andy Shevchenko,
Matti Vaittinen, Lad Prabhakar, Chen-Yu Tsai, Jernej Skrabec,
Samuel Holland, Hugo Villeneuve, Nuno Sa, David Lechner,
Javier Carrasco, Guillaume Stols, Dumitru Ceclan, Trevor Gamblin,
Matteo Martelli, Alisa-Dariana Roman, Ramona Alexandra Nechita,
AngeloGioacchino Del Regno, linux-iio, devicetree, linux-kernel,
linux-acpi, linux-renesas-soc, linux-arm-kernel, linux-sunxi
[-- 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 --]
^ permalink raw reply related [flat|nested] 11+ messages in thread* Re: [PATCH v5 03/10] iio: adc: add helpers for parsing ADC nodes
2025-03-03 11:32 ` [PATCH v5 03/10] iio: adc: add helpers for parsing ADC nodes Matti Vaittinen
@ 2025-03-04 9:25 ` David Lechner
2025-03-04 12:07 ` Andy Shevchenko
2025-03-05 10:54 ` Matti Vaittinen
0 siblings, 2 replies; 11+ messages in thread
From: David Lechner @ 2025-03-04 9:25 UTC (permalink / raw)
To: Matti Vaittinen
Cc: Matti Vaittinen, Jonathan Cameron, Lars-Peter Clausen,
Andy Shevchenko, Lad Prabhakar, Chen-Yu Tsai, Jernej Skrabec,
Samuel Holland, Hugo Villeneuve, Nuno Sa, Javier Carrasco,
Guillaume Stols, Dumitru Ceclan, Trevor Gamblin, Matteo Martelli,
Alisa-Dariana Roman, Ramona Alexandra Nechita,
AngeloGioacchino Del Regno, linux-iio, devicetree, linux-kernel,
linux-acpi, linux-renesas-soc, linux-arm-kernel, linux-sunxi
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
>
^ permalink raw reply [flat|nested] 11+ messages in thread* Re: [PATCH v5 03/10] iio: adc: add helpers for parsing ADC nodes
2025-03-04 9:25 ` David Lechner
@ 2025-03-04 12:07 ` Andy Shevchenko
2025-03-05 10:54 ` Matti Vaittinen
1 sibling, 0 replies; 11+ messages in thread
From: Andy Shevchenko @ 2025-03-04 12:07 UTC (permalink / raw)
To: David Lechner
Cc: Matti Vaittinen, Matti Vaittinen, Jonathan Cameron,
Lars-Peter Clausen, Lad Prabhakar, Chen-Yu Tsai, Jernej Skrabec,
Samuel Holland, Hugo Villeneuve, Nuno Sa, Javier Carrasco,
Guillaume Stols, Dumitru Ceclan, Trevor Gamblin, Matteo Martelli,
Alisa-Dariana Roman, Ramona Alexandra Nechita,
AngeloGioacchino Del Regno, linux-iio, devicetree, linux-kernel,
linux-acpi, linux-renesas-soc, linux-arm-kernel, linux-sunxi
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
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH v5 03/10] iio: adc: add helpers for parsing ADC nodes
2025-03-04 9:25 ` David Lechner
2025-03-04 12:07 ` Andy Shevchenko
@ 2025-03-05 10:54 ` Matti Vaittinen
2025-03-08 16:29 ` Jonathan Cameron
1 sibling, 1 reply; 11+ messages in thread
From: Matti Vaittinen @ 2025-03-05 10:54 UTC (permalink / raw)
To: David Lechner
Cc: Matti Vaittinen, Jonathan Cameron, Lars-Peter Clausen,
Andy Shevchenko, Lad Prabhakar, Chen-Yu Tsai, Jernej Skrabec,
Samuel Holland, Hugo Villeneuve, Nuno Sa, Javier Carrasco,
Guillaume Stols, Dumitru Ceclan, Trevor Gamblin, Matteo Martelli,
Alisa-Dariana Roman, Ramona Alexandra Nechita,
AngeloGioacchino Del Regno, linux-iio, devicetree, linux-kernel,
linux-acpi, linux-renesas-soc, linux-arm-kernel, linux-sunxi
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
^ permalink raw reply [flat|nested] 11+ messages in thread* Re: [PATCH v5 03/10] iio: adc: add helpers for parsing ADC nodes
2025-03-05 10:54 ` Matti Vaittinen
@ 2025-03-08 16:29 ` Jonathan Cameron
2025-03-10 7:41 ` Matti Vaittinen
0 siblings, 1 reply; 11+ messages in thread
From: Jonathan Cameron @ 2025-03-08 16:29 UTC (permalink / raw)
To: Matti Vaittinen
Cc: David Lechner, Matti Vaittinen, Lars-Peter Clausen,
Andy Shevchenko, Lad Prabhakar, Chen-Yu Tsai, Jernej Skrabec,
Samuel Holland, Hugo Villeneuve, Nuno Sa, Javier Carrasco,
Guillaume Stols, Dumitru Ceclan, Trevor Gamblin, Matteo Martelli,
Alisa-Dariana Roman, Ramona Alexandra Nechita,
AngeloGioacchino Del Regno, linux-iio, devicetree, linux-kernel,
linux-acpi, linux-renesas-soc, linux-arm-kernel, linux-sunxi
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
>
^ permalink raw reply [flat|nested] 11+ messages in thread* Re: [PATCH v5 03/10] iio: adc: add helpers for parsing ADC nodes
2025-03-08 16:29 ` Jonathan Cameron
@ 2025-03-10 7:41 ` Matti Vaittinen
2025-03-10 19:25 ` Jonathan Cameron
0 siblings, 1 reply; 11+ messages in thread
From: Matti Vaittinen @ 2025-03-10 7:41 UTC (permalink / raw)
To: Jonathan Cameron
Cc: David Lechner, Matti Vaittinen, Lars-Peter Clausen,
Andy Shevchenko, Lad Prabhakar, Chen-Yu Tsai, Jernej Skrabec,
Samuel Holland, Hugo Villeneuve, Nuno Sa, Javier Carrasco,
Guillaume Stols, Dumitru Ceclan, Trevor Gamblin, Matteo Martelli,
Alisa-Dariana Roman, Ramona Alexandra Nechita,
AngeloGioacchino Del Regno, linux-iio, devicetree, linux-kernel,
linux-acpi, linux-renesas-soc, linux-arm-kernel, linux-sunxi
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
^ permalink raw reply [flat|nested] 11+ messages in thread* Re: [PATCH v5 03/10] iio: adc: add helpers for parsing ADC nodes
2025-03-10 7:41 ` Matti Vaittinen
@ 2025-03-10 19:25 ` Jonathan Cameron
0 siblings, 0 replies; 11+ messages in thread
From: Jonathan Cameron @ 2025-03-10 19:25 UTC (permalink / raw)
To: Matti Vaittinen
Cc: David Lechner, Matti Vaittinen, Lars-Peter Clausen,
Andy Shevchenko, Lad Prabhakar, Chen-Yu Tsai, Jernej Skrabec,
Samuel Holland, Hugo Villeneuve, Nuno Sa, Javier Carrasco,
Guillaume Stols, Dumitru Ceclan, Trevor Gamblin, Matteo Martelli,
Alisa-Dariana Roman, Ramona Alexandra Nechita,
AngeloGioacchino Del Regno, linux-iio, devicetree, linux-kernel,
linux-acpi, linux-renesas-soc, linux-arm-kernel, linux-sunxi
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
^ permalink raw reply [flat|nested] 11+ messages in thread
* [PATCH v5 05/10] iio: adc: sun20i-gpadc: Use adc-helpers
2025-03-03 11:30 [PATCH v5 00/10] Support ROHM BD79124 ADC Matti Vaittinen
2025-03-03 11:32 ` [PATCH v5 03/10] iio: adc: add helpers for parsing ADC nodes Matti Vaittinen
@ 2025-03-03 11:33 ` Matti Vaittinen
2025-03-08 16:35 ` Jonathan Cameron
2025-03-03 11:34 ` [PATCH v5 08/10] MAINTAINERS: Add IIO ADC helpers Matti Vaittinen
2 siblings, 1 reply; 11+ messages in thread
From: Matti Vaittinen @ 2025-03-03 11:33 UTC (permalink / raw)
To: Matti Vaittinen, Matti Vaittinen
Cc: Jonathan Cameron, Lars-Peter Clausen, Chen-Yu Tsai,
Jernej Skrabec, Samuel Holland, Nuno Sa, David Lechner,
Javier Carrasco, Matti Vaittinen, Olivier Moysan, Guillaume Stols,
Dumitru Ceclan, Trevor Gamblin, Matteo Martelli,
Alisa-Dariana Roman, Andy Shevchenko, linux-iio, linux-kernel,
linux-arm-kernel, linux-sunxi
[-- Attachment #1: Type: text/plain, Size: 4837 bytes --]
The new devm_iio_adc_device_alloc_chaninfo() -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"
-propereties 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>
---
Revision history:
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 | 38 ++++++++++++------------------
2 files changed, 16 insertions(+), 23 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..bf1db2a3de9b 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,37 +150,27 @@ 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);
+ num_channels = devm_iio_adc_device_alloc_chaninfo_se(dev,
+ &sun20i_gpadc_chan_template, -1, &channels);
+ if (num_channels < 0)
+ return num_channels;
+
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++;
- }
-
indio_dev->channels = channels;
indio_dev->num_channels = num_channels;
@@ -271,3 +262,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 --]
^ permalink raw reply related [flat|nested] 11+ messages in thread* Re: [PATCH v5 05/10] iio: adc: sun20i-gpadc: Use adc-helpers
2025-03-03 11:33 ` [PATCH v5 05/10] iio: adc: sun20i-gpadc: Use adc-helpers Matti Vaittinen
@ 2025-03-08 16:35 ` Jonathan Cameron
0 siblings, 0 replies; 11+ messages in thread
From: Jonathan Cameron @ 2025-03-08 16:35 UTC (permalink / raw)
To: Matti Vaittinen
Cc: Matti Vaittinen, Lars-Peter Clausen, Chen-Yu Tsai, Jernej Skrabec,
Samuel Holland, Nuno Sa, David Lechner, Javier Carrasco,
Olivier Moysan, Guillaume Stols, Dumitru Ceclan, Trevor Gamblin,
Matteo Martelli, Alisa-Dariana Roman, Andy Shevchenko, linux-iio,
linux-kernel, linux-arm-kernel, linux-sunxi
On Mon, 3 Mar 2025 13:33:02 +0200
Matti Vaittinen <mazziesaccount@gmail.com> wrote:
> The new devm_iio_adc_device_alloc_chaninfo() -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"
> -propereties to channel identification numbers, used in the struct
same typo.
> 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>
>
Otherwise LGTM
^ permalink raw reply [flat|nested] 11+ messages in thread
* [PATCH v5 08/10] MAINTAINERS: Add IIO ADC helpers
2025-03-03 11:30 [PATCH v5 00/10] Support ROHM BD79124 ADC Matti Vaittinen
2025-03-03 11:32 ` [PATCH v5 03/10] iio: adc: add helpers for parsing ADC nodes Matti Vaittinen
2025-03-03 11:33 ` [PATCH v5 05/10] iio: adc: sun20i-gpadc: Use adc-helpers Matti Vaittinen
@ 2025-03-03 11:34 ` Matti Vaittinen
2 siblings, 0 replies; 11+ messages in thread
From: Matti Vaittinen @ 2025-03-03 11:34 UTC (permalink / raw)
To: Matti Vaittinen, Matti Vaittinen
Cc: Jonathan Cameron, Lars-Peter Clausen, Andy Shevchenko,
Matti Vaittinen, Lad Prabhakar, Chen-Yu Tsai, Jernej Skrabec,
Samuel Holland, Hugo Villeneuve, Nuno Sa, David Lechner,
Javier Carrasco, Guillaume Stols, Dumitru Ceclan, Trevor Gamblin,
Matteo Martelli, Alisa-Dariana Roman, Ramona Alexandra Nechita,
AngeloGioacchino Del Regno, linux-iio, devicetree, linux-kernel,
linux-acpi, linux-renesas-soc, linux-arm-kernel, linux-sunxi
[-- 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 --]
^ permalink raw reply related [flat|nested] 11+ messages in thread