This adds GPIO and regulator management to the I2C OF component prober.
Components that the prober intends to probe likely require their
regulator supplies be enabled, and GPIOs be toggled to enable them or
bring them out of reset before they will respond to probe attempts.

Without specific knowledge of each component's resource names or
power sequencing requirements, the prober can only enable the
regulator supplies all at once, and toggle the GPIOs all at once.
Luckily, reset pins tend to be active low, while enable pins tend to
be active high, so setting the raw status of all GPIO pins to high
should work. The wait time before and after resources are enabled
are collected from existing drivers and device trees.

The prober collects resources from all possible components and enables
them together, instead of enabling resources and probing each component
one by one. The latter approach does not provide any boot time benefits
over simply enabling each component and letting each driver probe
sequentially.

The prober will also deduplicate the resources, since on a component
swap out or co-layout design, the resources are always the same.
While duplicate regulator supplies won't cause much issue, shared
GPIOs don't work reliably, especially with other drivers. For the
same reason, the prober will release the GPIOs before the successfully
probed component is actually enabled.

Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
---
Changes since v3:
- New patch

This change is kept as a separate patch for now since the changes are
quite numerous.
---
 drivers/i2c/i2c-core-of-prober.c | 272 ++++++++++++++++++++++++++++++-
 1 file changed, 271 insertions(+), 1 deletion(-)

diff --git a/drivers/i2c/i2c-core-of-prober.c b/drivers/i2c/i2c-core-of-prober.c
index 08aa736cc7a9..76d26768e12c 100644
--- a/drivers/i2c/i2c-core-of-prober.c
+++ b/drivers/i2c/i2c-core-of-prober.c
@@ -5,11 +5,14 @@
  * Copyright (C) 2024 Google LLC
  */
 
+#include <linux/delay.h>
 #include <linux/device.h>
 #include <linux/err.h>
+#include <linux/gpio/consumer.h>
 #include <linux/i2c.h>
 #include <linux/module.h>
 #include <linux/of.h>
+#include <linux/regulator/consumer.h>
 #include <linux/slab.h>
 
 /*
@@ -25,10 +28,242 @@
  * address responds.
  *
  * TODO:
- * - Support handling common regulators and GPIOs.
  * - Support I2C muxes
  */
 
+/*
+ * While 8 seems like a small number, especially when probing many component
+ * options, in practice all the options will have the same resources. The
+ * code getting the resources below does deduplication to avoid conflicts.
+ */
+#define RESOURCE_MAX 8
+
+struct i2c_of_probe_data {
+	struct of_phandle_args gpio_phandles[RESOURCE_MAX];
+	unsigned int gpio_phandles_num;
+	struct gpio_desc *gpiods[RESOURCE_MAX];
+	unsigned int gpiods_num;
+	struct regulator *regulators[RESOURCE_MAX];
+	unsigned int regulators_num;
+};
+
+#define REGULATOR_SUFFIX "-supply"
+
+/* Returns 1 if regulator found for property, 0 if not, or error. */
+static int i2c_of_probe_get_regulator(struct device_node *node, struct property *prop,
+				      struct i2c_of_probe_data *data)
+{
+	struct regulator *regulator = NULL;
+	char con[32]; /* 32 is max size of property name */
+	char *p;
+
+	p = strstr(prop->name, REGULATOR_SUFFIX);
+	if (!p)
+		return 0;
+
+	if (strcmp(p, REGULATOR_SUFFIX))
+		return 0;
+
+	strscpy(con, prop->name, p - prop->name + 1);
+	regulator = regulator_of_get_optional(node, con);
+	/* DT lookup should never return -ENODEV */
+	if (IS_ERR(regulator))
+		return PTR_ERR(regulator);
+
+	for (int i = 0; i < data->regulators_num; i++)
+		if (regulator_is_equal(regulator, data->regulators[i])) {
+			regulator_put(regulator);
+			regulator = NULL;
+			break;
+		}
+
+	if (!regulator)
+		return 1;
+
+	if (data->regulators_num == ARRAY_SIZE(data->regulators)) {
+		regulator_put(regulator);
+		return -ENOMEM;
+	}
+
+	data->regulators[data->regulators_num++] = regulator;
+
+	return 1;
+}
+
+#define GPIO_SUFFIX "-gpio"
+
+/* Returns 1 if GPIO found for property, 0 if not, or error. */
+static int i2c_of_probe_get_gpiod(struct device_node *node, struct property *prop,
+				  struct i2c_of_probe_data *data)
+{
+	struct fwnode_handle *fwnode = of_fwnode_handle(node);
+	struct gpio_desc *gpiod = NULL;
+	char con[32]; /* 32 is max size of property name */
+	char *con_id = NULL;
+	char *p;
+	struct of_phandle_args phargs;
+	int ret;
+	bool duplicate_found;
+
+	p = strstr(prop->name, GPIO_SUFFIX);
+	if (p) {
+		strscpy(con, prop->name, p - prop->name + 1);
+		con_id = con;
+	} else if (strcmp(prop->name, "gpio") && strcmp(prop->name, "gpios")) {
+		return 0;
+	}
+
+	ret = of_parse_phandle_with_args_map(node, prop->name, "gpio", 0, &phargs);
+	if (ret)
+		return ret;
+
+	/*
+	 * GPIO descriptors are not reference counted. GPIOD_FLAGS_BIT_NONEXCLUSIVE
+	 * can't differentiate between GPIOs shared between devices to be probed and
+	 * other devices (which is incorrect). Instead we check the parsed phandle
+	 * for duplicates. Ignore the flags (the last arg) in this case.
+	 */
+	phargs.args[phargs.args_count - 1] = 0;
+	duplicate_found = false;
+	for (int i = 0; i < data->gpio_phandles_num; i++)
+		if (of_phandle_args_equal(&phargs, &data->gpio_phandles[i])) {
+			duplicate_found = true;
+			break;
+		}
+
+	if (duplicate_found) {
+		of_node_put(phargs.np);
+		return 1;
+	}
+
+	gpiod = fwnode_gpiod_get_index(fwnode, con_id, 0, GPIOD_ASIS, "i2c-of-prober");
+	if (IS_ERR(gpiod)) {
+		of_node_put(phargs.np);
+		return PTR_ERR(gpiod);
+	}
+
+	if (data->gpiods_num == ARRAY_SIZE(data->gpiods)) {
+		of_node_put(phargs.np);
+		gpiod_put(gpiod);
+		return -ENOMEM;
+	}
+
+	memcpy(&data->gpio_phandles[data->gpio_phandles_num++], &phargs, sizeof(phargs));
+	data->gpiods[data->gpiods_num++] = gpiod;
+
+	return 1;
+}
+
+/*
+ * This is split into two functions because in the normal flow the GPIOs
+ * have to be released before the actual driver probes so that the latter
+ * can acquire them.
+ */
+static void i2c_of_probe_free_gpios(struct i2c_of_probe_data *data)
+{
+	for (int i = data->gpio_phandles_num - 1; i >= 0; i--)
+		of_node_put(data->gpio_phandles[i].np);
+	data->gpio_phandles_num = 0;
+
+	for (int i = data->gpiods_num - 1; i >= 0; i--)
+		gpiod_put(data->gpiods[i]);
+	data->gpiods_num = 0;
+}
+
+static void i2c_of_probe_free_res(struct i2c_of_probe_data *data)
+{
+	i2c_of_probe_free_gpios(data);
+
+	for (int i = data->regulators_num; i >= 0; i--)
+		regulator_put(data->regulators[i]);
+	data->regulators_num = 0;
+}
+
+static int i2c_of_probe_get_res(struct device *dev, struct device_node *node,
+				struct i2c_of_probe_data *data)
+{
+	struct property *prop;
+	int ret;
+
+	for_each_property_of_node(node, prop) {
+		dev_dbg(dev, "Trying property %pOF/%s\n", node, prop->name);
+
+		/* regulator supplies */
+		ret = i2c_of_probe_get_regulator(node, prop, data);
+		if (ret > 0)
+			continue;
+		if (ret < 0) {
+			dev_err_probe(dev, ret, "Failed to get regulator supply from %pOF/%s\n",
+				      node, prop->name);
+			goto err_cleanup;
+		}
+
+		/* GPIOs */
+		ret = i2c_of_probe_get_gpiod(node, prop, data);
+		if (ret < 0) {
+			dev_err_probe(dev, ret, "Failed to get GPIO from %pOF/%s\n",
+				      node, prop->name);
+			goto err_cleanup;
+		}
+	}
+
+	return 0;
+
+err_cleanup:
+	i2c_of_probe_free_res(data);
+	return ret;
+}
+
+static int i2c_of_probe_enable_res(struct device *dev, struct i2c_of_probe_data *data)
+{
+	int ret = 0;
+	int reg_i, gpio_i;
+
+	dev_dbg(dev, "Enabling resources\n");
+
+	for (reg_i = 0; reg_i < data->regulators_num; reg_i++) {
+		dev_dbg(dev, "Enabling regulator %d\n", reg_i);
+		ret = regulator_enable(data->regulators[reg_i]);
+		if (ret)
+			goto disable_regulators;
+	}
+
+	/* largest post-power-on pre-reset-deassert delay seen among drivers */
+	msleep(500);
+
+	for (gpio_i = 0; gpio_i < data->gpiods_num; gpio_i++) {
+		/*
+		 * reset GPIOs normally have opposite polarity compared to
+		 * enable GPIOs. Instead of parsing the flags again, simply
+		 * set the raw value to high.
+		 */
+		dev_dbg(dev, "Setting GPIO %d\n", gpio_i);
+		ret = gpiod_direction_output_raw(data->gpiods[gpio_i], 1);
+		if (ret)
+			goto disable_gpios;
+	}
+
+	/* largest post-reset-deassert delay seen in tree for Elan I2C HID */
+	msleep(300);
+
+	return 0;
+
+disable_gpios:
+	for (gpio_i--; gpio_i >= 0; gpio_i--)
+		gpiod_set_raw_value_cansleep(data->gpiods[gpio_i], 0);
+disable_regulators:
+	for (reg_i--; reg_i >= 0; reg_i--)
+		regulator_disable(data->regulators[reg_i]);
+
+	return ret;
+}
+
+static void i2c_of_probe_disable_regulators(struct i2c_of_probe_data *data)
+{
+	for (int i = data->regulators_num - 1; i >= 0; i--)
+		regulator_disable(data->regulators[i]);
+}
+
 /**
  * i2c_of_probe_component() - probe for devices of "type" on the same i2c bus
  * @dev: &struct device of the caller, only used for dev_* printk messages
@@ -64,6 +299,7 @@ int i2c_of_probe_component(struct device *dev, const char *type)
 	struct device_node *node, *i2c_node;
 	struct i2c_adapter *i2c;
 	struct of_changeset *ocs = NULL;
+	struct i2c_of_probe_data data = {0};
 	int ret;
 
 	node = of_find_node_by_name(NULL, type);
@@ -101,6 +337,34 @@ int i2c_of_probe_component(struct device *dev, const char *type)
 		return dev_err_probe(dev, -EPROBE_DEFER, "Couldn't get I2C adapter\n");
 	}
 
+	/* Grab resources */
+	for_each_child_of_node_scoped(i2c_node, node) {
+		u32 addr;
+
+		if (!of_node_name_prefix(node, type))
+			continue;
+		if (of_property_read_u32(node, "reg", &addr))
+			continue;
+
+		dev_dbg(dev, "Requesting resources for %pOF\n", node);
+		ret = i2c_of_probe_get_res(dev, node, &data);
+		if (ret) {
+			of_node_put(i2c_node);
+			return ret;
+		}
+	}
+
+	dev_dbg(dev, "Resources: # of GPIOs = %d, # of regulator supplies = %d\n",
+		data.gpiods_num, data.regulators_num);
+
+	/* Enable resources */
+	ret = i2c_of_probe_enable_res(dev, &data);
+	if (ret) {
+		i2c_of_probe_free_res(&data);
+		of_node_put(i2c_node);
+		return dev_err_probe(dev, ret, "Failed to enable resources\n");
+	}
+
 	ret = 0;
 	for_each_child_of_node(i2c_node, node) {
 		union i2c_smbus_data data;
@@ -116,6 +380,8 @@ int i2c_of_probe_component(struct device *dev, const char *type)
 		break;
 	}
 
+	i2c_of_probe_free_gpios(&data);
+
 	/* Found a device that is responding */
 	if (node) {
 		dev_info(dev, "Enabling %pOF\n", node);
@@ -137,6 +403,8 @@ int i2c_of_probe_component(struct device *dev, const char *type)
 		of_node_put(node);
 	}
 
+	i2c_of_probe_disable_regulators(&data);
+	i2c_of_probe_free_res(&data);
 	i2c_put_adapter(i2c);
 	of_node_put(i2c_node);
 
@@ -148,6 +416,8 @@ int i2c_of_probe_component(struct device *dev, const char *type)
 	kfree(ocs);
 err_put_node:
 	of_node_put(node);
+	i2c_of_probe_disable_regulators(&data);
+	i2c_of_probe_free_res(&data);
 	i2c_put_adapter(i2c);
 	of_node_put(i2c_node);
 	return ret;
-- 
2.46.0.rc2.264.g509ed76dc8-goog

On Thu, Aug 08, 2024 at 05:59:27PM +0800, Chen-Yu Tsai wrote:
> This adds GPIO and regulator management to the I2C OF component prober.

Can this be two patches?

> Components that the prober intends to probe likely require their
> regulator supplies be enabled, and GPIOs be toggled to enable them or
> bring them out of reset before they will respond to probe attempts.
> 
> Without specific knowledge of each component's resource names or
> power sequencing requirements, the prober can only enable the
> regulator supplies all at once, and toggle the GPIOs all at once.
> Luckily, reset pins tend to be active low, while enable pins tend to
> be active high, so setting the raw status of all GPIO pins to high
> should work. The wait time before and after resources are enabled
> are collected from existing drivers and device trees.
> 
> The prober collects resources from all possible components and enables
> them together, instead of enabling resources and probing each component
> one by one. The latter approach does not provide any boot time benefits
> over simply enabling each component and letting each driver probe
> sequentially.
> 
> The prober will also deduplicate the resources, since on a component
> swap out or co-layout design, the resources are always the same.
> While duplicate regulator supplies won't cause much issue, shared
> GPIOs don't work reliably, especially with other drivers. For the
> same reason, the prober will release the GPIOs before the successfully
> probed component is actually enabled.

...

> +/*
> + * While 8 seems like a small number, especially when probing many component
> + * options, in practice all the options will have the same resources. The
> + * code getting the resources below does deduplication to avoid conflicts.
> + */
> +#define RESOURCE_MAX 8

Badly (broadly) named constant. Is it not the same that defines arguments in
the OF phandle lookup? Can you use that instead?

...

> +#define REGULATOR_SUFFIX "-supply"

Name is bad, also move '-' to the code, it's not part of the suffix, it's a
separator AFAICT.

...

> +	p = strstr(prop->name, REGULATOR_SUFFIX);

strstr()?! Are you sure it will have no side effects on some interesting names?

> +	if (!p)
> +		return 0;

> +	if (strcmp(p, REGULATOR_SUFFIX))
> +		return 0;

Ah, you do it this way...

What about




> +
> +	strscpy(con, prop->name, p - prop->name + 1);
> +	regulator = regulator_of_get_optional(node, con);
> +	/* DT lookup should never return -ENODEV */
> +	if (IS_ERR(regulator))
> +		return PTR_ERR(regulator);

...

> +	for (int i = 0; i < data->regulators_num; i++)

Why signed?

> +		if (regulator_is_equal(regulator, data->regulators[i])) {
> +			regulator_put(regulator);
> +			regulator = NULL;
> +			break;
> +		}

...

> +#define GPIO_SUFFIX "-gpio"

Bad define name, and why not "gpios"?

...

> +	p = strstr(prop->name, GPIO_SUFFIX);
> +	if (p) {
> +		strscpy(con, prop->name, p - prop->name + 1);
> +		con_id = con;
> +	} else if (strcmp(prop->name, "gpio") && strcmp(prop->name, "gpios")) {
> +		return 0;

We have an array of these suffixes, please use it. If required make it exported
to the others.

> +	}

...

> +	ret = of_parse_phandle_with_args_map(node, prop->name, "gpio", 0, &phargs);
> +	if (ret)
> +		return ret;

> +	gpiod = fwnode_gpiod_get_index(fwnode, con_id, 0, GPIOD_ASIS, "i2c-of-prober");
> +	if (IS_ERR(gpiod)) {
> +		of_node_put(phargs.np);
> +		return PTR_ERR(gpiod);
> +	}

Try not to mix fwnode and OF specifics. You may rely on fwnode for GPIO completely.

> +	if (data->gpiods_num == ARRAY_SIZE(data->gpiods)) {
> +		of_node_put(phargs.np);
> +		gpiod_put(gpiod);
> +		return -ENOMEM;
> +	}

...

> +	for (int i = data->gpiods_num - 1; i >= 0; i--)
> +		gpiod_put(data->gpiods[i]);

This sounds like reinvention of gpiod_*_array() call.

...

> +	for (int i = data->regulators_num; i >= 0; i--)
> +		regulator_put(data->regulators[i]);

Bulk regulators?

...

> +	for_each_child_of_node_scoped(i2c_node, node) {

Eventually _scoped(), but...

> +		u32 addr;
> +
> +		if (!of_node_name_prefix(node, type))
> +			continue;
> +		if (of_property_read_u32(node, "reg", &addr))
> +			continue;
> +
> +		dev_dbg(dev, "Requesting resources for %pOF\n", node);
> +		ret = i2c_of_probe_get_res(dev, node, &data);
> +		if (ret) {

> +			of_node_put(i2c_node);

...huh?!

> +			return ret;
> +		}
> +	}

-- 
With Best Regards,
Andy Shevchenko

On Tue, Aug 13, 2024 at 7:41 PM Andy Shevchenko
<andriy.shevchenko@linux.intel.com> wrote:
>
> On Thu, Aug 08, 2024 at 05:59:27PM +0800, Chen-Yu Tsai wrote:
> > This adds GPIO and regulator management to the I2C OF component prober.
>
> Can this be two patches?

You mean one for GPIOs and one for regulators right? Sure.

> > Components that the prober intends to probe likely require their
> > regulator supplies be enabled, and GPIOs be toggled to enable them or
> > bring them out of reset before they will respond to probe attempts.
> >
> > Without specific knowledge of each component's resource names or
> > power sequencing requirements, the prober can only enable the
> > regulator supplies all at once, and toggle the GPIOs all at once.
> > Luckily, reset pins tend to be active low, while enable pins tend to
> > be active high, so setting the raw status of all GPIO pins to high
> > should work. The wait time before and after resources are enabled
> > are collected from existing drivers and device trees.
> >
> > The prober collects resources from all possible components and enables
> > them together, instead of enabling resources and probing each component
> > one by one. The latter approach does not provide any boot time benefits
> > over simply enabling each component and letting each driver probe
> > sequentially.
> >
> > The prober will also deduplicate the resources, since on a component
> > swap out or co-layout design, the resources are always the same.
> > While duplicate regulator supplies won't cause much issue, shared
> > GPIOs don't work reliably, especially with other drivers. For the
> > same reason, the prober will release the GPIOs before the successfully
> > probed component is actually enabled.
>
> ...
>
> > +/*
> > + * While 8 seems like a small number, especially when probing many component
> > + * options, in practice all the options will have the same resources. The
> > + * code getting the resources below does deduplication to avoid conflicts.
> > + */
> > +#define RESOURCE_MAX 8
>
> Badly (broadly) named constant. Is it not the same that defines arguments in
> the OF phandle lookup? Can you use that instead?

I'm not sure what you are referring to. This is how many unique instances
of a given resource (GPIOs or regulators) the prober will track.

MAX_TRACKED_RESOURCES maybe?

> ...
>
> > +#define REGULATOR_SUFFIX "-supply"
>
> Name is bad, also move '-' to the code, it's not part of the suffix, it's a
> separator AFAICT.

OF_REGULATOR_SUPPLY_SUFFIX then?

Also, "supply" is not a valid property. It is always "X-supply".
Having the '-' directly in the string makes things simpler, albeit
making the name slightly off.

> ...
>
> > +     p = strstr(prop->name, REGULATOR_SUFFIX);
>
> strstr()?! Are you sure it will have no side effects on some interesting names?
>
> > +     if (!p)
> > +             return 0;
>
> > +     if (strcmp(p, REGULATOR_SUFFIX))
> > +             return 0;
>
> Ah, you do it this way...
>
> What about

About? (feels like an unfinished comment)

Looking around, it seems I could just rename and export "is_supply_name()"
from drivers/regulator/of_regulator.c .

> > +
> > +     strscpy(con, prop->name, p - prop->name + 1);
> > +     regulator = regulator_of_get_optional(node, con);
> > +     /* DT lookup should never return -ENODEV */
> > +     if (IS_ERR(regulator))
> > +             return PTR_ERR(regulator);
>
> ...
>
> > +     for (int i = 0; i < data->regulators_num; i++)
>
> Why signed?

No real reason, other than being the same as the for loops in the
free functions.

> > +             if (regulator_is_equal(regulator, data->regulators[i])) {
> > +                     regulator_put(regulator);
> > +                     regulator = NULL;
> > +                     break;
> > +             }
>
> ...
>
> > +#define GPIO_SUFFIX "-gpio"
>
> Bad define name, and why not "gpios"?

"-gpio" in strstr() would match against both "foo-gpio" and "foo-gpios".
More like laziness.

> ...
>
> > +     p = strstr(prop->name, GPIO_SUFFIX);
> > +     if (p) {
> > +             strscpy(con, prop->name, p - prop->name + 1);
> > +             con_id = con;
> > +     } else if (strcmp(prop->name, "gpio") && strcmp(prop->name, "gpios")) {
> > +             return 0;
>
> We have an array of these suffixes, please use it. If required make it exported
> to the others.

OK. I'll rewrite this section with that then.

> > +     }
>
> ...
>
> > +     ret = of_parse_phandle_with_args_map(node, prop->name, "gpio", 0, &phargs);
> > +     if (ret)
> > +             return ret;
>
> > +     gpiod = fwnode_gpiod_get_index(fwnode, con_id, 0, GPIOD_ASIS, "i2c-of-prober");
> > +     if (IS_ERR(gpiod)) {
> > +             of_node_put(phargs.np);
> > +             return PTR_ERR(gpiod);
> > +     }
>
> Try not to mix fwnode and OF specifics. You may rely on fwnode for GPIO completely.

Well, fwnode doesn't give a way to identify GPIOs without requesting them.

Instead I think I could first request GPIOs exclusively, and if that fails
try non-exclusive and see if that GPIO descriptor matches any known one.
If not then something in the DT is broken and it should error out. Then
the phandle parsing code could be dropped.

> > +     if (data->gpiods_num == ARRAY_SIZE(data->gpiods)) {
> > +             of_node_put(phargs.np);
> > +             gpiod_put(gpiod);
> > +             return -ENOMEM;
> > +     }
>
> ...
>
> > +     for (int i = data->gpiods_num - 1; i >= 0; i--)
> > +             gpiod_put(data->gpiods[i]);
>
> This sounds like reinvention of gpiod_*_array() call.

Indeed. Will switch to gpiod_put_array() with some slight tweaks.

> ...
>
> > +     for (int i = data->regulators_num; i >= 0; i--)
> > +             regulator_put(data->regulators[i]);
>
> Bulk regulators?

Bulk regulators API uses its own data structure which is not just an
array. So unlike gpiod_*_array() it can't be used in this case.

> ...
>
> > +     for_each_child_of_node_scoped(i2c_node, node) {
>
> Eventually _scoped(), but...
>
> > +             u32 addr;
> > +
> > +             if (!of_node_name_prefix(node, type))
> > +                     continue;
> > +             if (of_property_read_u32(node, "reg", &addr))
> > +                     continue;
> > +
> > +             dev_dbg(dev, "Requesting resources for %pOF\n", node);
> > +             ret = i2c_of_probe_get_res(dev, node, &data);
> > +             if (ret) {
>
> > +                     of_node_put(i2c_node);
>
> ...huh?!

Oops. This and the next "of_node_put(i2c_node)" should be
"i2c_put_adapter(i2c)" instead.


Thank you for the review. More stuff to try.


Regards
ChenYu

> > +                     return ret;
> > +             }
> > +     }
>
> --
> With Best Regards,
> Andy Shevchenko
>
>

On Wed, Aug 14, 2024 at 07:34:00PM +0800, Chen-Yu Tsai wrote:
> On Tue, Aug 13, 2024 at 7:41 PM Andy Shevchenko
> <andriy.shevchenko@linux.intel.com> wrote:
> > On Thu, Aug 08, 2024 at 05:59:27PM +0800, Chen-Yu Tsai wrote:

...

> > > This adds GPIO and regulator management to the I2C OF component prober.

> > Can this be two patches?
> 
> You mean one for GPIOs and one for regulators right? Sure.

Yes.

...

> > > +#define RESOURCE_MAX 8
> >
> > Badly (broadly) named constant. Is it not the same that defines arguments in
> > the OF phandle lookup? Can you use that instead?
> 
> I'm not sure what you are referring to. This is how many unique instances
> of a given resource (GPIOs or regulators) the prober will track.
> 
> MAX_TRACKED_RESOURCES maybe?

Better, but still ambiguous. We have a namespace approach, something like
I2C_PROBER_... I have checked the existing constant and it's not what you
want, so forget about that part, only name of the definition is questionable.

...

> > > +#define REGULATOR_SUFFIX "-supply"
> >
> > Name is bad, also move '-' to the code, it's not part of the suffix, it's a
> > separator AFAICT.
> 
> OF_REGULATOR_SUPPLY_SUFFIX then?
> 
> Also, "supply" is not a valid property. It is always "X-supply".
> Having the '-' directly in the string makes things simpler, albeit
> making the name slightly off.

Let's use proper SUFFIX and separator separately.

#define I2C_PROBER_..._SUFFIX "supply"

(or alike)

...

> > > +     p = strstr(prop->name, REGULATOR_SUFFIX);
> >
> > strstr()?! Are you sure it will have no side effects on some interesting names?
> >
> > > +     if (!p)
> > > +             return 0;
> >
> > > +     if (strcmp(p, REGULATOR_SUFFIX))
> > > +             return 0;
> >
> > Ah, you do it this way...
> >
> > What about
> 
> About? (feels like an unfinished comment)

Yes, sorry for that. Since you found a better alternative, no need to finish
this part :-)

> Looking around, it seems I could just rename and export "is_supply_name()"
> from drivers/regulator/of_regulator.c .

Even better!

Something similar most likely can be done with GPIO (if not, we are always open
to the ideas how to deduplicate the code).

...

> > > +#define GPIO_SUFFIX "-gpio"
> >
> > Bad define name, and why not "gpios"?
> 
> "-gpio" in strstr() would match against both "foo-gpio" and "foo-gpios".
> More like laziness.

And opens can of worms with whatever ending of the property name.
Again, let's have something that GPIO library provides for everybody.

...

> > > +     ret = of_parse_phandle_with_args_map(node, prop->name, "gpio", 0, &phargs);
> > > +     if (ret)
> > > +             return ret;

(1)

> > > +     gpiod = fwnode_gpiod_get_index(fwnode, con_id, 0, GPIOD_ASIS, "i2c-of-prober");
> > > +     if (IS_ERR(gpiod)) {
> > > +             of_node_put(phargs.np);
> > > +             return PTR_ERR(gpiod);
> > > +     }
> >
> > Try not to mix fwnode and OF specifics. You may rely on fwnode for GPIO completely.
> 
> Well, fwnode doesn't give a way to identify GPIOs without requesting them.
> 
> Instead I think I could first request GPIOs exclusively, and if that fails
> try non-exclusive and see if that GPIO descriptor matches any known one.
> If not then something in the DT is broken and it should error out. Then
> the phandle parsing code could be dropped.

What I meant, the, e.g., (1) can be rewritten using fwnode API, but if you know
better way of doing things, then go for it.

> > > +     if (data->gpiods_num == ARRAY_SIZE(data->gpiods)) {
> > > +             of_node_put(phargs.np);
> > > +             gpiod_put(gpiod);
> > > +             return -ENOMEM;
> > > +     }

...

> > > +     for (int i = data->regulators_num; i >= 0; i--)
> > > +             regulator_put(data->regulators[i]);
> >
> > Bulk regulators?
> 
> Bulk regulators API uses its own data structure which is not just an
> array. So unlike gpiod_*_array() it can't be used in this case.

But it sounds like a bulk regulator case...
Whatever, it's Mark's area and he might suggest something better.

-- 
With Best Regards,
Andy Shevchenko

On Wed, Aug 14, 2024 at 9:53 PM Andy Shevchenko
<andriy.shevchenko@linux.intel.com> wrote:
>
> On Wed, Aug 14, 2024 at 07:34:00PM +0800, Chen-Yu Tsai wrote:
> > On Tue, Aug 13, 2024 at 7:41 PM Andy Shevchenko
> > <andriy.shevchenko@linux.intel.com> wrote:
> > > On Thu, Aug 08, 2024 at 05:59:27PM +0800, Chen-Yu Tsai wrote:
>
> ...
>
> > > > This adds GPIO and regulator management to the I2C OF component prober.
>
> > > Can this be two patches?
> >
> > You mean one for GPIOs and one for regulators right? Sure.
>
> Yes.
>
> ...
>
> > > > +#define RESOURCE_MAX 8
> > >
> > > Badly (broadly) named constant. Is it not the same that defines arguments in
> > > the OF phandle lookup? Can you use that instead?
> >
> > I'm not sure what you are referring to. This is how many unique instances
> > of a given resource (GPIOs or regulators) the prober will track.
> >
> > MAX_TRACKED_RESOURCES maybe?
>
> Better, but still ambiguous. We have a namespace approach, something like
> I2C_PROBER_... I have checked the existing constant and it's not what you
> want, so forget about that part, only name of the definition is questionable.
>
> ...
>
> > > > +#define REGULATOR_SUFFIX "-supply"
> > >
> > > Name is bad, also move '-' to the code, it's not part of the suffix, it's a
> > > separator AFAICT.
> >
> > OF_REGULATOR_SUPPLY_SUFFIX then?
> >
> > Also, "supply" is not a valid property. It is always "X-supply".
> > Having the '-' directly in the string makes things simpler, albeit
> > making the name slightly off.
>
> Let's use proper SUFFIX and separator separately.
>
> #define I2C_PROBER_..._SUFFIX "supply"
>
> (or alike)
>
> ...
>
> > > > +     p = strstr(prop->name, REGULATOR_SUFFIX);
> > >
> > > strstr()?! Are you sure it will have no side effects on some interesting names?
> > >
> > > > +     if (!p)
> > > > +             return 0;
> > >
> > > > +     if (strcmp(p, REGULATOR_SUFFIX))
> > > > +             return 0;
> > >
> > > Ah, you do it this way...
> > >
> > > What about
> >
> > About? (feels like an unfinished comment)
>
> Yes, sorry for that. Since you found a better alternative, no need to finish
> this part :-)
>
> > Looking around, it seems I could just rename and export "is_supply_name()"
> > from drivers/regulator/of_regulator.c .
>
> Even better!
>
> Something similar most likely can be done with GPIO (if not, we are always open
> to the ideas how to deduplicate the code).
>
> ...

I ended up reworking around of_regulator_bulk_get_all(). See below.

> > > > +#define GPIO_SUFFIX "-gpio"
> > >
> > > Bad define name, and why not "gpios"?
> >
> > "-gpio" in strstr() would match against both "foo-gpio" and "foo-gpios".
> > More like laziness.
>
> And opens can of worms with whatever ending of the property name.
> Again, let's have something that GPIO library provides for everybody.

Ack.

> ...
>
> > > > +     ret = of_parse_phandle_with_args_map(node, prop->name, "gpio", 0, &phargs);
> > > > +     if (ret)
> > > > +             return ret;
>
> (1)
>
> > > > +     gpiod = fwnode_gpiod_get_index(fwnode, con_id, 0, GPIOD_ASIS, "i2c-of-prober");
> > > > +     if (IS_ERR(gpiod)) {
> > > > +             of_node_put(phargs.np);
> > > > +             return PTR_ERR(gpiod);
> > > > +     }
> > >
> > > Try not to mix fwnode and OF specifics. You may rely on fwnode for GPIO completely.
> >
> > Well, fwnode doesn't give a way to identify GPIOs without requesting them.
> >
> > Instead I think I could first request GPIOs exclusively, and if that fails
> > try non-exclusive and see if that GPIO descriptor matches any known one.
> > If not then something in the DT is broken and it should error out. Then
> > the phandle parsing code could be dropped.
>
> What I meant, the, e.g., (1) can be rewritten using fwnode API, but if you know
> better way of doing things, then go for it.
>
> > > > +     if (data->gpiods_num == ARRAY_SIZE(data->gpiods)) {
> > > > +             of_node_put(phargs.np);
> > > > +             gpiod_put(gpiod);
> > > > +             return -ENOMEM;
> > > > +     }

After reworking around |struct gpio_descs|, i.e. gpio_*_array() APIs,
this ended up being the only bit that actually used the _array variant
with gpiod_put_array(). The other bits remained for-loop-based.

> ...
>
> > > > +     for (int i = data->regulators_num; i >= 0; i--)
> > > > +             regulator_put(data->regulators[i]);
> > >
> > > Bulk regulators?
> >
> > Bulk regulators API uses its own data structure which is not just an
> > array. So unlike gpiod_*_array() it can't be used in this case.
>
> But it sounds like a bulk regulator case...
> Whatever, it's Mark's area and he might suggest something better.

There's of_regulator_bulk_get_all(), which has had no users since it was
merged. It gets all supplies under one device node and gives a handle for
the bulk regulator API. After reworking it to do lookups directly from
DT, all the regulator stuff can be converted to the bulk regulator API.
There's no deduplication anymore, though it's not a huge problem given
that regulators are reference counted.

I'll do one last pass over the code and send out a new version tomorrow.

Thanks
ChenYu