linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
* [PATCH v7 00/10] platform/chrome: Introduce DT hardware prober
@ 2024-09-11  7:27 Chen-Yu Tsai
  2024-09-11  7:27 ` [PATCH v7 01/10] of: dynamic: Add of_changeset_update_prop_string Chen-Yu Tsai
                   ` (10 more replies)
  0 siblings, 11 replies; 37+ messages in thread
From: Chen-Yu Tsai @ 2024-09-11  7:27 UTC (permalink / raw)
  To: Rob Herring, Saravana Kannan, Matthias Brugger,
	AngeloGioacchino Del Regno, Wolfram Sang, Benson Leung,
	Tzung-Bi Shih, Mark Brown, Liam Girdwood
  Cc: Chen-Yu Tsai, chrome-platform, devicetree, linux-arm-kernel,
	linux-mediatek, linux-kernel, Douglas Anderson, Johan Hovold,
	Jiri Kosina, Andy Shevchenko, linux-i2c

Hi everyone,

This is v7 of my "of: Introduce hardware prober driver" [1] series.
v7 mainly refactors the code into a series of helpers. The scope of
supported components is also reduced to those with at most one regulator
supply and one GPIO pin. Also the helpers expect these to be named and
so the "bulk get" API changes have been dropped.

Also, a pull request to document the "fail-needs-probe" status has been
sent: https://github.com/devicetree-org/dt-schema/pull/141

v2 continued Doug's "of: device: Support 2nd sources of probeable but
undiscoverable devices" [2] series, but follows the scheme suggested by
Rob, marking all second source component device nodes as "fail-needs-probe",
and having a hardware prober driver enable the one of them.


Changes since v6:
- Link to v6:
  https://lore.kernel.org/all/20240904090016.2841572-1-wenst@chromium.org/
- Dropped patch "gpiolib: Add gpio_property_name_length()"
  No longer needed
- Dropped patch "regulator: Move OF-specific regulator lookup code to of_regulator.c"
  Already merged
- Patch 2 "of: base: Add for_each_child_of_node_with_prefix()"
  - Changed helper name to "for_each_child_of_node_with_prefix()"
- Patch 4 "regulator: Add of_regulator_get_optional() for pure DT regulator lookup"
  - Was "regulator: Do pure DT regulator lookup in of_regulator_bulk_get_all()"
  - Changed reference [1] to Link: tag
  - Rebased on top of commit 401d078eaf2e ("regulator: of: Refactor
    of_get_*regulator() to decrease indentation")
  - Exported of_regulator_get_optional()
  - Changed commit message to focus on "of_regulator_get_optional()"
  - Dropped change to of_regulator_bulk_get_all()
- Patch 5 "i2c: core: Remove extra space in Makefile"
  - Collected Andy's Reviewed-by
- Patch 6 "i2c: Introduce OF component probe function"
  - Correctly replaced for_each_child_of_node_scoped() with
    for_each_child_of_node_with_prefix()
  - Added namespace for exported symbols
  - Made the probe function a framework with hooks
  - Split out a new header file
  - Added MAINTAINERS entry
  - Reworded kernel-doc
  - Dropped usage of __free from i2c_of_probe_component() since error
    path cleanup is needed anyway
- Patch 7 "i2c: of-prober: Add simple helpers for regulator support"
  - Moved change of of_get_next_child_scoped() to
    of_get_next_child_with_prefix() to previous patch
  - Restructured into helpers for the I2C OF component prober
  - Reduced to only handle one regulator
  - Commit message updated
- Patch 8 "i2c: of-prober: Add GPIO support to simple helpers"
  - Restructured into helpers for the I2C OF component prober
  - Reduced to only handle one GPIO
  - Set GPIO to input on (failure) cleanup
  - Updated commit message
- Patch 9 "platform/chrome: Introduce device tree hardware prober"
  - Adapted to new I2C OF prober interface
  - Collected Acked-by tag

Changes since v5:
- Link to v5:
  https://lore.kernel.org/all/20240822092006.3134096-1-wenst@chromium.org/
- Patch 1 "of: dynamic: Add of_changeset_update_prop_string"
  - Collected Rob's reviewed-by
- Patch 2 "of: base: Add for_each_child_of_node_with_prefix_scoped()"
  - New patch
- Patch 3 "regulator: Move OF-specific regulator lookup code to of_regulator.c"
  - Fix kerneldoc format of of_regulator_dev_lookup()
  - Fix stub compile error for !CONFIG_OF in drivers/regulator/internal.h
- Patch 4 "regulator: Split up _regulator_get()"
  - Fixed kerneldoc "Return" section format for _regulator_get_common()
  - Slightly reworded return value description
- Patch 5 "regulator: Do pure DT regulator lookup in of_regulator_bulk_get_all()"
  - Used "dev_of_node(dev)" instead of "dev->of_node"
  - Replaced "dev_printk" with "dev_printk()" in kerneldoc mentions
  - Fixed kerneldoc "Return" section format for of_regulator_get_optional()
  - Fix @np parameter name in of_regulator_dev_lookup() kerneldoc
- Patch 6 "gpiolib: Add gpio_property_name_length()"
  - Changed function name to "gpio_get_property_name_length()"
  - Changed argument name to "propname"
  - Clarified return value for "*-<GPIO suffix>" case
  - Reworked according to Andy's suggestion
  - Added stub function
- Patch 7 "i2c: core: Remove extra space in Makefile"
  - New patch
- Patch 8 "i2c: Introduce OF component probe function"
  - Fixed indent in Makefile
  - Split regulator and GPIO TODO items
  - Reversed final conditional in i2c_of_probe_enable_node()
- Patch 9 "i2c: of-prober: Add regulator support"
  - Split of_regulator_bulk_get_all() return value check and explain
    "ret == 0" case
  - Switched to of_get_next_child_with_prefix_scoped() where applicable
  - Used krealloc_array() instead of directly calculating size
  - copy whole regulator array in one memcpy() call
  - Drop "0" from struct zeroing initializer
  - Split out regulator helper from i2c_of_probe_enable_res() to keep
    code cleaner when combined with the next patch
  - Added options for customizing power sequencing delay
  - Rename i2c_of_probe_get_regulator() to i2c_of_probe_get_regulators()
  - Add i2c_of_probe_free_regulator() helper
- Patch 10 "i2c: of-prober: Add GPIO support"
  - Renamed "con" to "propname" in i2c_of_probe_get_gpiod()
  - Copy string first and check return value of strscpy() for overflow in
    i2c_of_probe_get_gpiod()
  - Add parenthesis around "enable" and "reset" GPIO names in comments
  - Split resource count debug message into two separate lines
  - Split out GPIO helper from i2c_of_probe_enable_res() to keep code
    cleaner following the previous patch
  - Adopted options for customizing power sequencing delay following
    previous patch
- Patch 11 "platform/chrome: Introduce device tree hardware prober"
  - Adapt to new i2c_of_probe_component() parameters
- Patch 12 "arm64: dts: mediatek: mt8173-elm-hana: Mark touchscreens and
	    trackpads as fail"
  - None

See v5 cover letter for previous change logs.

For the I2C component (touchscreens and trackpads) case from the
original series, the hardware prober driver finds the particular
class of device in the device tree, gets its parent I2C adapter,
and tries to initiate a simple I2C read for each device under that
I2C bus. When it finds one that responds, it considers that one
present, marks it as "okay", and returns, letting the driver core
actually probe the device.

This works fine in most cases since these components are connected
via a ribbon cable and always have the same resources. The prober
will also grab these resources and enable them.

The other case, selecting a display panel to use based on the SKU ID
from the firmware, hit a bit of an issue with fixing the OF graph.
It has been left out since v3.

Patch 1 adds of_changeset_update_prop_string(), as requested by Rob.

Patch 2 adds for_each_child_of_node_with_prefix(), as suggested by Andy.

Patches 3 through 4 reorganize the OF-specific regulator core code and
adds a new of_regulator_get_optional() function to look up regulator
supplies solely using device tree nodes.

Patch 5 cleans up some extra spaces in the i2c core Makefile

Patch 6 implements probing the I2C bus for presence of components as
a hookable helper function in the I2C core.

Patch 7 implements regulator supply support as a set of simple helpers
for the I2C component prober.

Patch 8 implements GPIO support for the I2C component prober simple
helpers.

Patch 9 adds a ChromeOS specific DT hardware prober. This initial
version targets the Hana Chromebooks, probing its I2C trackpads and
touchscreens.

Patch 10 modifies the Hana device tree and marks the touchscreens
and trackpads as "fail-needs-probe", ready for the driver to probe.


The patch and build time dependencies for this series is now quite
complicated:

  regulator cleanups in -next -> regulator patches here ----
							   |
							   v
  platform/chrome device tree hardware prober <--- i2c of-prober
 
The regulator patches in this series depend on other cleanup patches [1]
that are already in -next. Patches 6 through 8 introducting i2c of-prober
depend on the first 5 patches. Patch 11, The chrome prober, depends on
patch 6 for now.

I think it would be easier if the respective maintainers take the first
four patches for -rc1. Wolfram has agreed to take the remaining i2c and
chrome patches through the i2c tree once the other bits have landed,
Patch 12 can go in only after everything else is in. This should be
better than having an immutable branch on top of some commit in -next
for other trees to consume.

This might be the last revision I send out before ELCE / Plumbers, as
I'm traveling to Austria a few day earlier. If there are more concerns
about the design, maybe we could discuss it in person then if all
concerned parties are present.


Thanks
ChenYu


Chen-Yu Tsai (10):
  of: dynamic: Add of_changeset_update_prop_string
  of: base: Add for_each_child_of_node_with_prefix()
  regulator: Split up _regulator_get()
  regulator: Add of_regulator_get_optional() for pure DT regulator
    lookup
  i2c: core: Remove extra space in Makefile
  i2c: Introduce OF component probe function
  i2c: of-prober: Add simple helpers for regulator support
  i2c: of-prober: Add GPIO support to simple helpers
  platform/chrome: Introduce device tree hardware prober
  arm64: dts: mediatek: mt8173-elm-hana: Mark touchscreens and trackpads
    as fail

 MAINTAINERS                                   |   8 +
 .../boot/dts/mediatek/mt8173-elm-hana.dtsi    |  13 +
 arch/arm64/boot/dts/mediatek/mt8173-elm.dtsi  |   4 +-
 drivers/i2c/Makefile                          |   7 +-
 drivers/i2c/i2c-core-of-prober.c              | 455 ++++++++++++++++++
 drivers/of/base.c                             |  35 ++
 drivers/of/dynamic.c                          |  44 ++
 drivers/platform/chrome/Kconfig               |  11 +
 drivers/platform/chrome/Makefile              |   1 +
 .../platform/chrome/chromeos_of_hw_prober.c   | 125 +++++
 drivers/regulator/core.c                      |  58 ++-
 drivers/regulator/internal.h                  |   6 +
 drivers/regulator/of_regulator.c              |  51 +-
 include/linux/i2c-of-prober.h                 | 131 +++++
 include/linux/of.h                            |  13 +
 include/linux/regulator/consumer.h            |   4 +
 16 files changed, 942 insertions(+), 24 deletions(-)
 create mode 100644 drivers/i2c/i2c-core-of-prober.c
 create mode 100644 drivers/platform/chrome/chromeos_of_hw_prober.c
 create mode 100644 include/linux/i2c-of-prober.h

-- 
2.46.0.598.g6f2099f65c-goog



^ permalink raw reply	[flat|nested] 37+ messages in thread

* [PATCH v7 01/10] of: dynamic: Add of_changeset_update_prop_string
  2024-09-11  7:27 [PATCH v7 00/10] platform/chrome: Introduce DT hardware prober Chen-Yu Tsai
@ 2024-09-11  7:27 ` Chen-Yu Tsai
  2024-09-11  7:27 ` [PATCH v7 02/10] of: base: Add for_each_child_of_node_with_prefix() Chen-Yu Tsai
                   ` (9 subsequent siblings)
  10 siblings, 0 replies; 37+ messages in thread
From: Chen-Yu Tsai @ 2024-09-11  7:27 UTC (permalink / raw)
  To: Rob Herring, Saravana Kannan, Matthias Brugger,
	AngeloGioacchino Del Regno, Wolfram Sang, Benson Leung,
	Tzung-Bi Shih, Mark Brown, Liam Girdwood
  Cc: Chen-Yu Tsai, chrome-platform, devicetree, linux-arm-kernel,
	linux-mediatek, linux-kernel, Douglas Anderson, Johan Hovold,
	Jiri Kosina, Andy Shevchenko, linux-i2c

Add a helper function to add string property updates to an OF changeset.
This is similar to of_changeset_add_prop_string(), but instead of adding
the property (and failing if it exists), it will update the property.

This shall be used later in the DT hardware prober.

Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
---
Changes since v6:
None.

Changes since v5:
- Collected Rob's tag

Changes since v4:
- Use modern designated initializer for |prop|

Changes since v3:
- Use new __of_prop_free() helper
- Add new line before header declaration

Changes since v2:
- New patch added in v3
---
 drivers/of/dynamic.c | 44 ++++++++++++++++++++++++++++++++++++++++++++
 include/linux/of.h   |  4 ++++
 2 files changed, 48 insertions(+)

diff --git a/drivers/of/dynamic.c b/drivers/of/dynamic.c
index 110104a936d9..daa69d160a78 100644
--- a/drivers/of/dynamic.c
+++ b/drivers/of/dynamic.c
@@ -1072,3 +1072,47 @@ int of_changeset_add_prop_bool(struct of_changeset *ocs, struct device_node *np,
 	return of_changeset_add_prop_helper(ocs, np, &prop);
 }
 EXPORT_SYMBOL_GPL(of_changeset_add_prop_bool);
+
+static int of_changeset_update_prop_helper(struct of_changeset *ocs,
+					   struct device_node *np,
+					   const struct property *pp)
+{
+	struct property *new_pp;
+	int ret;
+
+	new_pp = __of_prop_dup(pp, GFP_KERNEL);
+	if (!new_pp)
+		return -ENOMEM;
+
+	ret = of_changeset_update_property(ocs, np, new_pp);
+	if (ret)
+		__of_prop_free(new_pp);
+
+	return ret;
+}
+
+/**
+ * of_changeset_update_prop_string - Add a string property update to a changeset
+ *
+ * @ocs:	changeset pointer
+ * @np:		device node pointer
+ * @prop_name:	name of the property to be updated
+ * @str:	pointer to null terminated string
+ *
+ * Create a string property to be updated and add it to a changeset.
+ *
+ * Return: 0 on success, a negative error value in case of an error.
+ */
+int of_changeset_update_prop_string(struct of_changeset *ocs,
+				    struct device_node *np,
+				    const char *prop_name, const char *str)
+{
+	struct property prop = {
+		.name = (char *)prop_name,
+		.length = strlen(str) + 1,
+		.value = (void *)str,
+	};
+
+	return of_changeset_update_prop_helper(ocs, np, &prop);
+}
+EXPORT_SYMBOL_GPL(of_changeset_update_prop_string);
diff --git a/include/linux/of.h b/include/linux/of.h
index 85b60ac9eec5..046283be1cd3 100644
--- a/include/linux/of.h
+++ b/include/linux/of.h
@@ -1651,6 +1651,10 @@ static inline int of_changeset_add_prop_u32(struct of_changeset *ocs,
 	return of_changeset_add_prop_u32_array(ocs, np, prop_name, &val, 1);
 }
 
+int of_changeset_update_prop_string(struct of_changeset *ocs,
+				    struct device_node *np,
+				    const char *prop_name, const char *str);
+
 int of_changeset_add_prop_bool(struct of_changeset *ocs, struct device_node *np,
 			       const char *prop_name);
 
-- 
2.46.0.598.g6f2099f65c-goog



^ permalink raw reply related	[flat|nested] 37+ messages in thread

* [PATCH v7 02/10] of: base: Add for_each_child_of_node_with_prefix()
  2024-09-11  7:27 [PATCH v7 00/10] platform/chrome: Introduce DT hardware prober Chen-Yu Tsai
  2024-09-11  7:27 ` [PATCH v7 01/10] of: dynamic: Add of_changeset_update_prop_string Chen-Yu Tsai
@ 2024-09-11  7:27 ` Chen-Yu Tsai
  2024-09-12 20:31   ` Rob Herring (Arm)
  2024-09-11  7:27 ` [PATCH v7 03/10] regulator: Split up _regulator_get() Chen-Yu Tsai
                   ` (8 subsequent siblings)
  10 siblings, 1 reply; 37+ messages in thread
From: Chen-Yu Tsai @ 2024-09-11  7:27 UTC (permalink / raw)
  To: Rob Herring, Saravana Kannan, Matthias Brugger,
	AngeloGioacchino Del Regno, Wolfram Sang, Benson Leung,
	Tzung-Bi Shih, Mark Brown, Liam Girdwood
  Cc: Chen-Yu Tsai, chrome-platform, devicetree, linux-arm-kernel,
	linux-mediatek, linux-kernel, Douglas Anderson, Johan Hovold,
	Jiri Kosina, Andy Shevchenko, linux-i2c

There are cases where drivers would go through child device nodes and
operate on only the ones whose node name starts with a given prefix.

Provide a helper for these users. This will mainly be used in a
subsequent patch that implements a hardware component prober for I2C
busses.

Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
---
Changes since v6:
- Changed helper name to "for_each_child_of_node_with_prefix()"
Changes since v5:
- New patch
---
 drivers/of/base.c  | 35 +++++++++++++++++++++++++++++++++++
 include/linux/of.h |  9 +++++++++
 2 files changed, 44 insertions(+)

diff --git a/drivers/of/base.c b/drivers/of/base.c
index 20603d3c9931..d3c123b3261a 100644
--- a/drivers/of/base.c
+++ b/drivers/of/base.c
@@ -628,6 +628,41 @@ struct device_node *of_get_next_child(const struct device_node *node,
 }
 EXPORT_SYMBOL(of_get_next_child);
 
+/**
+ * of_get_next_child_with_prefix - Find the next child node with prefix
+ * @node:	parent node
+ * @prev:	previous child of the parent node, or NULL to get first
+ *
+ * This function is like of_get_next_child(), except that it automatically
+ * skips any nodes whose name doesn't have the given prefix.
+ *
+ * Return: A node pointer with refcount incremented, use
+ * of_node_put() on it when done.
+ */
+struct device_node *of_get_next_child_with_prefix(const struct device_node *node,
+						  struct device_node *prev,
+						  const char *prefix)
+{
+	struct device_node *next;
+	unsigned long flags;
+
+	if (!node)
+		return NULL;
+
+	raw_spin_lock_irqsave(&devtree_lock, flags);
+	next = prev ? prev->sibling : node->child;
+	for (; next; next = next->sibling) {
+		if (!of_node_name_prefix(next, prefix))
+			continue;
+		if (of_node_get(next))
+			break;
+	}
+	of_node_put(prev);
+	raw_spin_unlock_irqrestore(&devtree_lock, flags);
+	return next;
+}
+EXPORT_SYMBOL(of_get_next_child_with_prefix);
+
 static struct device_node *of_get_next_status_child(const struct device_node *node,
 						    struct device_node *prev,
 						    bool (*checker)(const struct device_node *))
diff --git a/include/linux/of.h b/include/linux/of.h
index 046283be1cd3..48cfb39197d6 100644
--- a/include/linux/of.h
+++ b/include/linux/of.h
@@ -289,6 +289,9 @@ extern struct device_node *of_get_parent(const struct device_node *node);
 extern struct device_node *of_get_next_parent(struct device_node *node);
 extern struct device_node *of_get_next_child(const struct device_node *node,
 					     struct device_node *prev);
+extern struct device_node *of_get_next_child_with_prefix(const struct device_node *node,
+							 struct device_node *prev,
+							 const char *prefix);
 extern struct device_node *of_get_next_available_child(
 	const struct device_node *node, struct device_node *prev);
 extern struct device_node *of_get_next_reserved_child(
@@ -1468,6 +1471,12 @@ static inline int of_property_read_s32(const struct device_node *np,
 	     child != NULL;						\
 	     child = of_get_next_child(parent, child))
 
+#define for_each_child_of_node_with_prefix(parent, child, prefix)	\
+	for (struct device_node *child __free(device_node) =		\
+	     of_get_next_child_with_prefix(parent, NULL, prefix);	\
+	     child != NULL;						\
+	     child = of_get_next_child_with_prefix(parent, child, prefix))
+
 #define for_each_available_child_of_node(parent, child) \
 	for (child = of_get_next_available_child(parent, NULL); child != NULL; \
 	     child = of_get_next_available_child(parent, child))
-- 
2.46.0.598.g6f2099f65c-goog



^ permalink raw reply related	[flat|nested] 37+ messages in thread

* [PATCH v7 03/10] regulator: Split up _regulator_get()
  2024-09-11  7:27 [PATCH v7 00/10] platform/chrome: Introduce DT hardware prober Chen-Yu Tsai
  2024-09-11  7:27 ` [PATCH v7 01/10] of: dynamic: Add of_changeset_update_prop_string Chen-Yu Tsai
  2024-09-11  7:27 ` [PATCH v7 02/10] of: base: Add for_each_child_of_node_with_prefix() Chen-Yu Tsai
@ 2024-09-11  7:27 ` Chen-Yu Tsai
  2024-09-13 10:27   ` Andy Shevchenko
  2024-09-11  7:27 ` [PATCH v7 04/10] regulator: Add of_regulator_get_optional() for pure DT regulator lookup Chen-Yu Tsai
                   ` (7 subsequent siblings)
  10 siblings, 1 reply; 37+ messages in thread
From: Chen-Yu Tsai @ 2024-09-11  7:27 UTC (permalink / raw)
  To: Rob Herring, Saravana Kannan, Matthias Brugger,
	AngeloGioacchino Del Regno, Wolfram Sang, Benson Leung,
	Tzung-Bi Shih, Mark Brown, Liam Girdwood
  Cc: Chen-Yu Tsai, chrome-platform, devicetree, linux-arm-kernel,
	linux-mediatek, linux-kernel, Douglas Anderson, Johan Hovold,
	Jiri Kosina, Andy Shevchenko, linux-i2c

_regulator_get() contains a lot of common code doing checks prior to the
regulator lookup and housekeeping work after the lookup. Almost all the
code could be shared with a OF-specific variant of _regulator_get().

Split out the common parts so that they can be reused. The OF-specific
version of _regulator_get() will be added in a subsequent patch.
No functional changes were made.

Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
---
Changes since v6:
None.

Changes since v5:
- Fixed kerneldoc "Return" section format for _regulator_get_common()
- Slightly reworded return value description

Changes since v4:
- New patch
---
 drivers/regulator/core.c     | 54 ++++++++++++++++++++++++++++--------
 drivers/regulator/internal.h |  4 +++
 2 files changed, 47 insertions(+), 11 deletions(-)

diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c
index 835a5531d045..d60c86477ac2 100644
--- a/drivers/regulator/core.c
+++ b/drivers/regulator/core.c
@@ -2103,26 +2103,43 @@ static int regulator_resolve_supply(struct regulator_dev *rdev)
 	return ret;
 }
 
-/* Internal regulator request function */
-struct regulator *_regulator_get(struct device *dev, const char *id,
-				 enum regulator_get_type get_type)
+/* common pre-checks for regulator requests */
+int _regulator_get_common_check(struct device *dev, const char *id,
+				enum regulator_get_type get_type)
 {
-	struct regulator_dev *rdev;
-	struct regulator *regulator;
-	struct device_link *link;
-	int ret;
-
 	if (get_type >= MAX_GET_TYPE) {
 		dev_err(dev, "invalid type %d in %s\n", get_type, __func__);
-		return ERR_PTR(-EINVAL);
+		return -EINVAL;
 	}
 
 	if (id == NULL) {
 		dev_err(dev, "regulator request with no identifier\n");
-		return ERR_PTR(-EINVAL);
+		return -EINVAL;
 	}
 
-	rdev = regulator_dev_lookup(dev, id);
+	return 0;
+}
+
+/**
+ * _regulator_get_common - Common code for regulator requests
+ * @rdev: regulator device pointer as returned by *regulator_dev_lookup()
+ *       Its reference count is expected to have been incremented.
+ * @dev: device used for dev_printk messages
+ * @id: Supply name or regulator ID
+ * @get_type: enum regulator_get_type value corresponding to type of request
+ *
+ * Returns: pointer to struct regulator corresponding to @rdev, or ERR_PTR()
+ *	    encoded error.
+ *
+ * This function should be chained with *regulator_dev_lookup() functions.
+ */
+struct regulator *_regulator_get_common(struct regulator_dev *rdev, struct device *dev,
+					const char *id, enum regulator_get_type get_type)
+{
+	struct regulator *regulator;
+	struct device_link *link;
+	int ret;
+
 	if (IS_ERR(rdev)) {
 		ret = PTR_ERR(rdev);
 
@@ -2238,6 +2255,21 @@ struct regulator *_regulator_get(struct device *dev, const char *id,
 	return regulator;
 }
 
+/* Internal regulator request function */
+struct regulator *_regulator_get(struct device *dev, const char *id,
+				 enum regulator_get_type get_type)
+{
+	struct regulator_dev *rdev;
+	int ret;
+
+	ret = _regulator_get_common_check(dev, id, get_type);
+	if (ret)
+		return ERR_PTR(ret);
+
+	rdev = regulator_dev_lookup(dev, id);
+	return _regulator_get_common(rdev, dev, id, get_type);
+}
+
 /**
  * regulator_get - lookup and obtain a reference to a regulator.
  * @dev: device for regulator "consumer"
diff --git a/drivers/regulator/internal.h b/drivers/regulator/internal.h
index 8e5506c5ee94..5b43f802468d 100644
--- a/drivers/regulator/internal.h
+++ b/drivers/regulator/internal.h
@@ -121,6 +121,10 @@ enum regulator_get_type {
 	MAX_GET_TYPE
 };
 
+int _regulator_get_common_check(struct device *dev, const char *id,
+				enum regulator_get_type get_type);
+struct regulator *_regulator_get_common(struct regulator_dev *rdev, struct device *dev,
+					const char *id, enum regulator_get_type get_type);
 struct regulator *_regulator_get(struct device *dev, const char *id,
 				 enum regulator_get_type get_type);
 int _regulator_bulk_get(struct device *dev, int num_consumers,
-- 
2.46.0.598.g6f2099f65c-goog



^ permalink raw reply related	[flat|nested] 37+ messages in thread

* [PATCH v7 04/10] regulator: Add of_regulator_get_optional() for pure DT regulator lookup
  2024-09-11  7:27 [PATCH v7 00/10] platform/chrome: Introduce DT hardware prober Chen-Yu Tsai
                   ` (2 preceding siblings ...)
  2024-09-11  7:27 ` [PATCH v7 03/10] regulator: Split up _regulator_get() Chen-Yu Tsai
@ 2024-09-11  7:27 ` Chen-Yu Tsai
  2024-09-11  7:27 ` [PATCH v7 05/10] i2c: core: Remove extra space in Makefile Chen-Yu Tsai
                   ` (6 subsequent siblings)
  10 siblings, 0 replies; 37+ messages in thread
From: Chen-Yu Tsai @ 2024-09-11  7:27 UTC (permalink / raw)
  To: Rob Herring, Saravana Kannan, Matthias Brugger,
	AngeloGioacchino Del Regno, Wolfram Sang, Benson Leung,
	Tzung-Bi Shih, Mark Brown, Liam Girdwood
  Cc: Chen-Yu Tsai, chrome-platform, devicetree, linux-arm-kernel,
	linux-mediatek, linux-kernel, Douglas Anderson, Johan Hovold,
	Jiri Kosina, Andy Shevchenko, linux-i2c

The to-be-introduced I2C component prober needs to enable regulator
supplies (and toggle GPIO pins) for the various components it intends
to probe. To support this, a new "pure DT lookup" method for getting
regulator supplies is needed, since the device normally requesting
the supply won't get created until after the component is probed to
be available.

Add a new of_regulator_get_optional() function for this. This mirrors
the existing regulator_get_optional() function, but is OF-specific.
The underlying code that supports the existing regulator_get*()
functions has been reworked in previous patches to support this
specific case.

Also convert an existing usage of "dev && dev->of_node" to
"dev_of_node(dev)".

Link: https://lore.kernel.org/all/20231220203537.83479-2-jernej.skrabec@gmail.com/ [1]
Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
---
Changes since v6:
- Changed reference [1] to Link: tag
- Rebased on top of commit 401d078eaf2e ("regulator: of: Refactor
  of_get_*regulator() to decrease indentation")
- Exported of_regulator_get_optional()
- Changed commit message to focus on "of_regulator_get_optional()"
- Dropped change to of_regulator_bulk_get_all()

Changes since v5:
- Used "dev_of_node(dev)" instead of "dev->of_node"
- Replaced "dev_printk" with "dev_printk()" in kerneldoc mentions
- Fixed kerneldoc "Return" section format for of_regulator_get_optional()
- Fix @np parameter name in of_regulator_dev_lookup() kerneldoc

Changes since v4:
- Restore platform-agnostic regulator consumer code to original state
- Move OF-specific regulator code to of_regulator.c (separate patch)
- Split _regulator_get() into three parts for reuse (separate patch)
- Add OF-specific _of_regulator_get() function
- Rename regulator_of_get_optional() to of_regulator_get_optional() for
  consistency
- Make of_regulator_get_optional static, as it is only used internally
- Convert of_regulator_bulk_get_all()

Changes since v3:
- New patch
---
 drivers/regulator/core.c           |  4 +--
 drivers/regulator/internal.h       |  2 ++
 drivers/regulator/of_regulator.c   | 51 ++++++++++++++++++++++++++----
 include/linux/regulator/consumer.h |  4 +++
 4 files changed, 53 insertions(+), 8 deletions(-)

diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c
index d60c86477ac2..f94a06ac2109 100644
--- a/drivers/regulator/core.c
+++ b/drivers/regulator/core.c
@@ -1959,8 +1959,8 @@ static struct regulator_dev *regulator_dev_lookup(struct device *dev,
 	regulator_supply_alias(&dev, &supply);
 
 	/* first do a dt based lookup */
-	if (dev && dev->of_node) {
-		r = of_regulator_dev_lookup(dev, supply);
+	if (dev_of_node(dev)) {
+		r = of_regulator_dev_lookup(dev, dev_of_node(dev), supply);
 		if (!IS_ERR(r))
 			return r;
 		if (PTR_ERR(r) == -EPROBE_DEFER)
diff --git a/drivers/regulator/internal.h b/drivers/regulator/internal.h
index 5b43f802468d..f62cacbbc729 100644
--- a/drivers/regulator/internal.h
+++ b/drivers/regulator/internal.h
@@ -67,6 +67,7 @@ static inline struct regulator_dev *dev_to_rdev(struct device *dev)
 
 #ifdef CONFIG_OF
 struct regulator_dev *of_regulator_dev_lookup(struct device *dev,
+					      struct device_node *np,
 					      const char *supply);
 struct regulator_init_data *regulator_of_get_init_data(struct device *dev,
 			         const struct regulator_desc *desc,
@@ -82,6 +83,7 @@ bool of_check_coupling_data(struct regulator_dev *rdev);
 
 #else
 static inline struct regulator_dev *of_regulator_dev_lookup(struct device *dev,
+							    struct device_node *np,
 							    const char *supply)
 {
 	return ERR_PTR(-ENODEV);
diff --git a/drivers/regulator/of_regulator.c b/drivers/regulator/of_regulator.c
index 3f490d81abc2..358c3ed791db 100644
--- a/drivers/regulator/of_regulator.c
+++ b/drivers/regulator/of_regulator.c
@@ -588,7 +588,8 @@ static struct device_node *of_get_child_regulator(struct device_node *parent,
 
 /**
  * of_get_regulator - get a regulator device node based on supply name
- * @dev: Device pointer for the consumer (of regulator) device
+ * @dev: Device pointer for dev_printk() messages
+ * @node: Device node pointer for supply property lookup
  * @supply: regulator supply name
  *
  * Extract the regulator device node corresponding to the supply name.
@@ -596,15 +597,16 @@ static struct device_node *of_get_child_regulator(struct device_node *parent,
  * Return: Pointer to the &struct device_node corresponding to the regulator
  *	   if found, or %NULL if not found.
  */
-static struct device_node *of_get_regulator(struct device *dev, const char *supply)
+static struct device_node *of_get_regulator(struct device *dev, struct device_node *node,
+					    const char *supply)
 {
 	struct device_node *regnode = NULL;
 	char prop_name[64]; /* 64 is max size of property name */
 
-	dev_dbg(dev, "Looking up %s-supply from device tree\n", supply);
+	dev_dbg(dev, "Looking up %s-supply from device node %pOF\n", supply, node);
 
 	snprintf(prop_name, 64, "%s-supply", supply);
-	regnode = of_parse_phandle(dev->of_node, prop_name, 0);
+	regnode = of_parse_phandle(node, prop_name, 0);
 	if (regnode)
 		return regnode;
 
@@ -628,6 +630,7 @@ static struct regulator_dev *of_find_regulator_by_node(struct device_node *np)
 /**
  * of_regulator_dev_lookup - lookup a regulator device with device tree only
  * @dev: Device pointer for regulator supply lookup.
+ * @np: Device node pointer for regulator supply lookup.
  * @supply: Supply name or regulator ID.
  *
  * Return: Pointer to the &struct regulator_dev on success, or ERR_PTR()
@@ -642,13 +645,13 @@ static struct regulator_dev *of_find_regulator_by_node(struct device_node *np)
  * * -%ENODEV if lookup fails permanently.
  * * -%EPROBE_DEFER if lookup could succeed in the future.
  */
-struct regulator_dev *of_regulator_dev_lookup(struct device *dev,
+struct regulator_dev *of_regulator_dev_lookup(struct device *dev, struct device_node *np,
 					      const char *supply)
 {
 	struct regulator_dev *r;
 	struct device_node *node;
 
-	node = of_get_regulator(dev, supply);
+	node = of_get_regulator(dev, np, supply);
 	if (node) {
 		r = of_find_regulator_by_node(node);
 		of_node_put(node);
@@ -665,6 +668,42 @@ struct regulator_dev *of_regulator_dev_lookup(struct device *dev,
 	return ERR_PTR(-ENODEV);
 }
 
+static struct regulator *_of_regulator_get(struct device *dev, struct device_node *node,
+					   const char *id, enum regulator_get_type get_type)
+{
+	struct regulator_dev *r;
+	int ret;
+
+	ret = _regulator_get_common_check(dev, id, get_type);
+	if (ret)
+		return ERR_PTR(ret);
+
+	r = of_regulator_dev_lookup(dev, node, id);
+	return _regulator_get_common(r, dev, id, get_type);
+}
+
+/**
+ * of_regulator_get_optional - get optional regulator via device tree lookup
+ * @dev: device used for dev_printk() messages
+ * @node: device node for regulator "consumer"
+ * @id: Supply name
+ *
+ * Return: pointer to struct regulator corresponding to the regulator producer,
+ *	   or PTR_ERR() encoded error number.
+ *
+ * This is intended for use by consumers that want to get a regulator
+ * supply directly from a device node, and can and want to deal with
+ * absence of such supplies. This will _not_ consider supply aliases.
+ * See regulator_dev_lookup().
+ */
+struct regulator *of_regulator_get_optional(struct device *dev,
+					    struct device_node *node,
+					    const char *id)
+{
+	return _of_regulator_get(dev, node, id, OPTIONAL_GET);
+}
+EXPORT_SYMBOL_GPL(of_regulator_get_optional);
+
 /*
  * Returns number of regulators coupled with rdev.
  */
diff --git a/include/linux/regulator/consumer.h b/include/linux/regulator/consumer.h
index b9ce521910a0..d7325e27a1ce 100644
--- a/include/linux/regulator/consumer.h
+++ b/include/linux/regulator/consumer.h
@@ -168,6 +168,10 @@ int devm_regulator_get_enable_read_voltage(struct device *dev, const char *id);
 void regulator_put(struct regulator *regulator);
 void devm_regulator_put(struct regulator *regulator);
 
+struct regulator *__must_check of_regulator_get_optional(struct device *dev,
+							 struct device_node *node,
+							 const char *id);
+
 int regulator_register_supply_alias(struct device *dev, const char *id,
 				    struct device *alias_dev,
 				    const char *alias_id);
-- 
2.46.0.598.g6f2099f65c-goog



^ permalink raw reply related	[flat|nested] 37+ messages in thread

* [PATCH v7 05/10] i2c: core: Remove extra space in Makefile
  2024-09-11  7:27 [PATCH v7 00/10] platform/chrome: Introduce DT hardware prober Chen-Yu Tsai
                   ` (3 preceding siblings ...)
  2024-09-11  7:27 ` [PATCH v7 04/10] regulator: Add of_regulator_get_optional() for pure DT regulator lookup Chen-Yu Tsai
@ 2024-09-11  7:27 ` Chen-Yu Tsai
  2024-09-13 14:59   ` Andi Shyti
  2024-09-11  7:27 ` [PATCH v7 06/10] i2c: Introduce OF component probe function Chen-Yu Tsai
                   ` (5 subsequent siblings)
  10 siblings, 1 reply; 37+ messages in thread
From: Chen-Yu Tsai @ 2024-09-11  7:27 UTC (permalink / raw)
  To: Rob Herring, Saravana Kannan, Matthias Brugger,
	AngeloGioacchino Del Regno, Wolfram Sang, Benson Leung,
	Tzung-Bi Shih, Mark Brown, Liam Girdwood
  Cc: Chen-Yu Tsai, chrome-platform, devicetree, linux-arm-kernel,
	linux-mediatek, linux-kernel, Douglas Anderson, Johan Hovold,
	Jiri Kosina, Andy Shevchenko, linux-i2c

Some lines in the Makefile have a space before tabs. Remove those.

Reported-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Closes: https://lore.kernel.org/all/ZsdE0PxKnGRjzChl@smile.fi.intel.com/
Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
---
Changes since v6:
- Collected Andy's Reviewed-by
Changes since v5:
- new patch
---
 drivers/i2c/Makefile | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/i2c/Makefile b/drivers/i2c/Makefile
index 3f71ce4711e3..f12d6b10a85e 100644
--- a/drivers/i2c/Makefile
+++ b/drivers/i2c/Makefile
@@ -5,10 +5,10 @@
 
 obj-$(CONFIG_I2C_BOARDINFO)	+= i2c-boardinfo.o
 obj-$(CONFIG_I2C)		+= i2c-core.o
-i2c-core-objs 			:= i2c-core-base.o i2c-core-smbus.o
+i2c-core-objs			:= i2c-core-base.o i2c-core-smbus.o
 i2c-core-$(CONFIG_ACPI)		+= i2c-core-acpi.o
-i2c-core-$(CONFIG_I2C_SLAVE) 	+= i2c-core-slave.o
-i2c-core-$(CONFIG_OF) 		+= i2c-core-of.o
+i2c-core-$(CONFIG_I2C_SLAVE)	+= i2c-core-slave.o
+i2c-core-$(CONFIG_OF)		+= i2c-core-of.o
 
 obj-$(CONFIG_I2C_SMBUS)		+= i2c-smbus.o
 obj-$(CONFIG_I2C_CHARDEV)	+= i2c-dev.o
-- 
2.46.0.598.g6f2099f65c-goog



^ permalink raw reply related	[flat|nested] 37+ messages in thread

* [PATCH v7 06/10] i2c: Introduce OF component probe function
  2024-09-11  7:27 [PATCH v7 00/10] platform/chrome: Introduce DT hardware prober Chen-Yu Tsai
                   ` (4 preceding siblings ...)
  2024-09-11  7:27 ` [PATCH v7 05/10] i2c: core: Remove extra space in Makefile Chen-Yu Tsai
@ 2024-09-11  7:27 ` Chen-Yu Tsai
  2024-09-13 10:25   ` Andy Shevchenko
                     ` (2 more replies)
  2024-09-11  7:27 ` [PATCH v7 07/10] i2c: of-prober: Add simple helpers for regulator support Chen-Yu Tsai
                   ` (4 subsequent siblings)
  10 siblings, 3 replies; 37+ messages in thread
From: Chen-Yu Tsai @ 2024-09-11  7:27 UTC (permalink / raw)
  To: Rob Herring, Saravana Kannan, Matthias Brugger,
	AngeloGioacchino Del Regno, Wolfram Sang, Benson Leung,
	Tzung-Bi Shih, Mark Brown, Liam Girdwood
  Cc: Chen-Yu Tsai, chrome-platform, devicetree, linux-arm-kernel,
	linux-mediatek, linux-kernel, Douglas Anderson, Johan Hovold,
	Jiri Kosina, Andy Shevchenko, linux-i2c

Some devices are designed and manufactured with some components having
multiple drop-in replacement options. These components are often
connected to the mainboard via ribbon cables, having the same signals
and pin assignments across all options. These may include the display
panel and touchscreen on laptops and tablets, and the trackpad on
laptops. Sometimes which component option is used in a particular device
can be detected by some firmware provided identifier, other times that
information is not available, and the kernel has to try to probe each
device.

This change attempts to make the "probe each device" case cleaner. The
current approach is to have all options added and enabled in the device
tree. The kernel would then bind each device and run each driver's probe
function. This works, but has been broken before due to the introduction
of asynchronous probing, causing multiple instances requesting "shared"
resources, such as pinmuxes, GPIO pins, interrupt lines, at the same
time, with only one instance succeeding. Work arounds for these include
moving the pinmux to the parent I2C controller, using GPIO hogs or
pinmux settings to keep the GPIO pins in some fixed configuration, and
requesting the interrupt line very late. Such configurations can be seen
on the MT8183 Krane Chromebook tablets, and the Qualcomm sc8280xp-based
Lenovo Thinkpad 13S.

Instead of this delicate dance between drivers and device tree quirks,
this change introduces a simple I2C component probe. function For a
given class of devices on the same I2C bus, it will go through all of
them, doing a simple I2C read transfer and see which one of them responds.
It will then enable the device that responds.

This requires some minor modifications in the existing device tree. The
status for all the device nodes for the component options must be set
to "failed-needs-probe". This makes it clear that some mechanism is
needed to enable one of them, and also prevents the prober and device
drivers running at the same time.

Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
---
Changes since v6:
- Correctly replaced for_each_child_of_node_scoped() with
  for_each_child_of_node_with_prefix()
- Added namespace for exported symbol
- Made the probe function a framework with hooks
- Split out a new header file
- Added MAINTAINERS entry
- Reworded kernel-doc
- Dropped usage of __free from i2c_of_probe_component() since error
  path cleanup is needed anyway

Changes since v5:
- Fixed indent in Makefile
- Split regulator and GPIO TODO items
- Reversed final conditional in i2c_of_probe_enable_node()

Changes since v4:
- Split code into helper functions
- Use scoped helpers and __free() to reduce error path

Changes since v3:
- Complete kernel-doc
- Return different error if I2C controller is disabled
- Expand comment to explain assumptions and constraints
- Split for-loop finding target node and operations on target node
- Add missing i2c_put_adapter()
- Move prober code to separate file

Rob also asked why there was a limitation of "exactly one touchscreen
will be enabled across the whole tree".

The use case this prober currently targets is a component on consumer
electronics (tablet or laptop) being swapped out due to cost or supply
reasons. Designs with multiple components of the same type are pretty
rare. The way the next patch is written also assumes this for efficiency
reasons.

Changes since v2:
- New patch split out from "of: Introduce hardware prober driver"
- Addressed Rob's comments
  - Move i2c prober to i2c subsystem
  - Use of_node_is_available() to check if node is enabled.
  - Use OF changeset API to update status property
- Addressed Andy's comments
  - Probe function now accepts "struct device *dev" instead to reduce
    line length and dereferences
  - Move "ret = 0" to just before for_each_child_of_node(i2c_node, node)
---
 MAINTAINERS                      |   8 ++
 drivers/i2c/Makefile             |   1 +
 drivers/i2c/i2c-core-of-prober.c | 195 +++++++++++++++++++++++++++++++
 include/linux/i2c-of-prober.h    |  73 ++++++++++++
 4 files changed, 277 insertions(+)
 create mode 100644 drivers/i2c/i2c-core-of-prober.c
 create mode 100644 include/linux/i2c-of-prober.h

diff --git a/MAINTAINERS b/MAINTAINERS
index 927f81c12543..d88646380786 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -10645,6 +10645,14 @@ S:	Maintained
 F:	Documentation/devicetree/bindings/i2c/marvell,mv64xxx-i2c.yaml
 F:	drivers/i2c/busses/i2c-mv64xxx.c
 
+I2C OF COMPONENT PROBER
+M:	Chen-Yu Tsai <wenst@chromium.org>
+L:	linux-i2c@vger.kernel.org
+L:	devicetree@vger.kernel.org
+S:	Maintained
+F:	drivers/i2c/i2c-core-of-prober.c
+F:	include/linux-i2c-of-prober.h
+
 I2C OVER PARALLEL PORT
 M:	Jean Delvare <jdelvare@suse.com>
 L:	linux-i2c@vger.kernel.org
diff --git a/drivers/i2c/Makefile b/drivers/i2c/Makefile
index f12d6b10a85e..c539cdc1e305 100644
--- a/drivers/i2c/Makefile
+++ b/drivers/i2c/Makefile
@@ -9,6 +9,7 @@ i2c-core-objs			:= i2c-core-base.o i2c-core-smbus.o
 i2c-core-$(CONFIG_ACPI)		+= i2c-core-acpi.o
 i2c-core-$(CONFIG_I2C_SLAVE)	+= i2c-core-slave.o
 i2c-core-$(CONFIG_OF)		+= i2c-core-of.o
+i2c-core-$(CONFIG_OF_DYNAMIC)	+= i2c-core-of-prober.o
 
 obj-$(CONFIG_I2C_SMBUS)		+= i2c-smbus.o
 obj-$(CONFIG_I2C_CHARDEV)	+= i2c-dev.o
diff --git a/drivers/i2c/i2c-core-of-prober.c b/drivers/i2c/i2c-core-of-prober.c
new file mode 100644
index 000000000000..62ff2f4b6177
--- /dev/null
+++ b/drivers/i2c/i2c-core-of-prober.c
@@ -0,0 +1,195 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * Linux I2C core OF component prober code
+ *
+ * Copyright (C) 2024 Google LLC
+ */
+
+#include <linux/cleanup.h>
+#include <linux/device.h>
+#include <linux/dev_printk.h>
+#include <linux/err.h>
+#include <linux/i2c.h>
+#include <linux/i2c-of-prober.h>
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/slab.h>
+
+/*
+ * Some devices, such as Google Hana Chromebooks, are produced by multiple
+ * vendors each using their preferred components. Such components are all
+ * in the device tree. Instead of having all of them enabled and having each
+ * driver separately try and probe its device while fighting over shared
+ * resources, they can be marked as "fail-needs-probe" and have a prober
+ * figure out which one is actually used beforehand.
+ *
+ * This prober assumes such drop-in parts are on the same I2C bus, have
+ * non-conflicting addresses, and can be directly probed by seeing which
+ * address responds.
+ *
+ * TODO:
+ * - Support handling common regulators.
+ * - Support handling common GPIOs.
+ * - Support I2C muxes
+ */
+
+static struct device_node *i2c_of_probe_get_i2c_node(struct device *dev, const char *type)
+{
+	struct device_node *node __free(device_node) = of_find_node_by_name(NULL, type);
+	if (!node)
+		return dev_err_ptr_probe(dev, -ENODEV, "Could not find %s device node\n", type);
+
+	struct device_node *i2c_node __free(device_node) = of_get_parent(node);
+	if (!of_node_name_eq(i2c_node, "i2c"))
+		return dev_err_ptr_probe(dev, -EINVAL, "%s device isn't on I2C bus\n", type);
+
+	if (!of_device_is_available(i2c_node))
+		return dev_err_ptr_probe(dev, -ENODEV, "I2C controller not available\n");
+
+	return no_free_ptr(i2c_node);
+}
+
+static int i2c_of_probe_enable_node(struct device *dev, struct device_node *node)
+{
+	int ret;
+
+	dev_info(dev, "Enabling %pOF\n", node);
+
+	struct of_changeset *ocs __free(kfree) = kzalloc(sizeof(*ocs), GFP_KERNEL);
+	if (!ocs)
+		return -ENOMEM;
+
+	of_changeset_init(ocs);
+	ret = of_changeset_update_prop_string(ocs, node, "status", "okay");
+	if (ret)
+		return ret;
+
+	ret = of_changeset_apply(ocs);
+	if (ret) {
+		/* ocs needs to be explicitly cleaned up before being freed. */
+		of_changeset_destroy(ocs);
+	} else {
+		/*
+		 * ocs is intentionally kept around as it needs to
+		 * exist as long as the change is applied.
+		 */
+		void *ptr __always_unused = no_free_ptr(ocs);
+	}
+
+	return ret;
+}
+
+static const struct i2c_of_probe_ops i2c_of_probe_dummy_ops;
+
+/**
+ * i2c_of_probe_component() - probe for devices of "type" on the same i2c bus
+ * @dev: Pointer to the &struct device of the caller, only used for dev_printk() messages.
+ * @cfg: Pointer to the &struct i2c_of_probe_cfg containing callbacks and other options
+ *       for the prober.
+ * @ctx: Context data for callbacks.
+ *
+ * Probe for possible I2C components of the same "type" (&i2c_of_probe_cfg->type)
+ * on the same I2C bus that have their status marked as "fail".
+ *
+ * Assumes that across the entire device tree the only instances of nodes
+ * prefixed with "type" are the ones that need handling for second source
+ * components. In other words, if "type" is "touchscreen", then all device
+ * nodes named "touchscreen*" are the ones that need probing. There cannot
+ * be another "touchscreen" node that is already enabled.
+ *
+ * Assumes that for each "type" of component, only one actually exists. In
+ * other words, only one matching and existing device will be enabled.
+ *
+ * Context: Process context only. Does non-atomic I2C transfers.
+ *          Should only be used from a driver probe function, as the function
+ *          can return -EPROBE_DEFER if the I2C adapter or other resources
+ *          are unavailable.
+ * Return: 0 on success or no-op, error code otherwise.
+ *         A no-op can happen when it seems like the device tree already
+ *         has components of the type to be probed already enabled. This
+ *         can happen when the device tree had not been updated to mark
+ *         the status of the to-be-probed components as "fail". Or this
+ *         function was already run with the same parameters and succeeded
+ *         in enabling a component. The latter could happen if the user
+ *         had multiple types of components to probe, and one of them down
+ *         the list caused a deferred probe. This is expected behavior.
+ */
+int i2c_of_probe_component(struct device *dev, const struct i2c_of_probe_cfg *cfg, void *ctx)
+{
+	const struct i2c_of_probe_ops *ops;
+	const char *type;
+	struct device_node *i2c_node;
+	struct i2c_adapter *i2c;
+	int ret;
+
+	if (!cfg)
+		return -EINVAL;
+
+	ops = cfg->ops ?: &i2c_of_probe_dummy_ops;
+	type = cfg->type;
+
+	i2c_node = i2c_of_probe_get_i2c_node(dev, type);
+	if (IS_ERR(i2c_node))
+		return PTR_ERR(i2c_node);
+
+	for_each_child_of_node_with_prefix(i2c_node, node, type) {
+		if (!of_device_is_available(node))
+			continue;
+
+		/*
+		 * Device tree has component already enabled. Either the
+		 * device tree isn't supported or we already probed once.
+		 */
+		ret = 0;
+		goto out_put_i2c_node;
+	}
+
+	i2c = of_get_i2c_adapter_by_node(i2c_node);
+	if (!i2c) {
+		ret = dev_err_probe(dev, -EPROBE_DEFER, "Couldn't get I2C adapter\n");
+		goto out_put_i2c_node;
+	}
+
+	/* Grab resources */
+	ret = 0;
+	if (ops->get_resources)
+		ret = ops->get_resources(dev, i2c_node, ctx);
+	if (ret)
+		goto out_put_i2c_adapter;
+
+	/* Enable resources */
+	if (ops->enable)
+		ret = ops->enable(dev, ctx);
+	if (ret)
+		goto out_release_resources;
+
+	ret = 0;
+	for_each_child_of_node_with_prefix(i2c_node, node, type) {
+		union i2c_smbus_data data;
+		u32 addr;
+
+		if (of_property_read_u32(node, "reg", &addr))
+			continue;
+		if (i2c_smbus_xfer(i2c, addr, 0, I2C_SMBUS_READ, 0, I2C_SMBUS_BYTE, &data) < 0)
+			continue;
+
+		/* Found a device that is responding */
+		if (ops->free_resources_early)
+			ops->free_resources_early(ctx);
+		ret = i2c_of_probe_enable_node(dev, node);
+		break;
+	}
+
+	if (ops->cleanup)
+		ops->cleanup(dev, ctx);
+out_release_resources:
+	if (ops->free_resources_late)
+		ops->free_resources_late(ctx);
+out_put_i2c_adapter:
+	i2c_put_adapter(i2c);
+out_put_i2c_node:
+	of_node_put(i2c_node);
+
+	return ret;
+}
+EXPORT_SYMBOL_NS_GPL(i2c_of_probe_component, I2C_OF_PROBER);
diff --git a/include/linux/i2c-of-prober.h b/include/linux/i2c-of-prober.h
new file mode 100644
index 000000000000..0f94e7c94310
--- /dev/null
+++ b/include/linux/i2c-of-prober.h
@@ -0,0 +1,73 @@
+/* SPDX-License-Identifier: GPL-2.0-or-later */
+/*
+ * i2c-of-prober.h - definitions for the Linux I2C OF component prober
+ *
+ * Copyright (C) 2024 Google LLC
+ */
+
+#ifndef _LINUX_I2C_OF_PROBER_H
+#define _LINUX_I2C_OF_PROBER_H
+
+#if IS_ENABLED(CONFIG_OF_DYNAMIC)
+
+struct device;
+struct device_node;
+
+/**
+ * struct i2c_of_probe_ops - I2C OF component prober callbacks
+ *
+ * A set of callbacks to be used by i2c_of_probe_component().
+ *
+ * All callbacks are optional. Callbacks are called only once per run, and are
+ * used in the order they are defined in this structure.
+ *
+ * All callbacks that have return values shall return %0 on success,
+ * or a negative error number on failure.
+ *
+ * The @dev parameter passed to the callbacks is the same as @dev passed to
+ * i2c_of_probe_component(). It should only be used for dev_printk() calls
+ * and nothing else, especially not managed device resource (devres) APIs.
+ */
+struct i2c_of_probe_ops {
+	/** @get_resources: Retrieve resources for components. */
+	int (*get_resources)(struct device *dev, struct device_node *bus_node, void *data);
+
+	/** @free_resources_early: Release exclusive resources prior to enabling component. */
+	void (*free_resources_early)(void *data);
+
+	/**
+	 * @enable: Enable resources so that the components respond to probes.
+	 *
+	 * Resources should be reverted to their initial state before returning if this fails.
+	 */
+	int (*enable)(struct device *dev, void *data);
+
+	/**
+	 * @cleanup: Opposite of @enable to balance refcounts after probing.
+	 *
+	 * Can not operate on resources already freed in @free_resources_early.
+	 */
+	int (*cleanup)(struct device *dev, void *data);
+
+	/**
+	 * @free_resources_late: Release all resources, including those that would have
+	 *                       been released by @free_resources_early.
+	 */
+	void (*free_resources_late)(void *data);
+};
+
+/**
+ * struct i2c_of_probe_cfg - I2C OF component prober configuration
+ * @ops: Callbacks for the prober to use.
+ * @type: A string to match the device node name prefix to probe for.
+ */
+struct i2c_of_probe_cfg {
+	const struct i2c_of_probe_ops *ops;
+	const char *type;
+};
+
+int i2c_of_probe_component(struct device *dev, const struct i2c_of_probe_cfg *cfg, void *ctx);
+
+#endif /* IS_ENABLED(CONFIG_OF_DYNAMIC) */
+
+#endif /* _LINUX_I2C_OF_PROBER_H */
-- 
2.46.0.598.g6f2099f65c-goog



^ permalink raw reply related	[flat|nested] 37+ messages in thread

* [PATCH v7 07/10] i2c: of-prober: Add simple helpers for regulator support
  2024-09-11  7:27 [PATCH v7 00/10] platform/chrome: Introduce DT hardware prober Chen-Yu Tsai
                   ` (5 preceding siblings ...)
  2024-09-11  7:27 ` [PATCH v7 06/10] i2c: Introduce OF component probe function Chen-Yu Tsai
@ 2024-09-11  7:27 ` Chen-Yu Tsai
  2024-09-13 10:46   ` Andy Shevchenko
  2024-09-13 23:43   ` Doug Anderson
  2024-09-11  7:27 ` [PATCH v7 08/10] i2c: of-prober: Add GPIO support to simple helpers Chen-Yu Tsai
                   ` (3 subsequent siblings)
  10 siblings, 2 replies; 37+ messages in thread
From: Chen-Yu Tsai @ 2024-09-11  7:27 UTC (permalink / raw)
  To: Rob Herring, Saravana Kannan, Matthias Brugger,
	AngeloGioacchino Del Regno, Wolfram Sang, Benson Leung,
	Tzung-Bi Shih, Mark Brown, Liam Girdwood
  Cc: Chen-Yu Tsai, chrome-platform, devicetree, linux-arm-kernel,
	linux-mediatek, linux-kernel, Douglas Anderson, Johan Hovold,
	Jiri Kosina, Andy Shevchenko, linux-i2c

Add helpers to do regulator management for 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.
GPIOs will be handled in the next patch.

The assumption is that the same class of components to be probed are
always connected in the same fashion with the same regulator supply
and GPIO. The names may vary due to binding differences, but the
physical layout does not change.

This set of helpers supports at most one regulator supply. The user
must specify the node from which the supply is retrieved. The supply
name and the amount of time to wait after the supply is enabled are
also given by the user.

Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
---
Changes since v6:
- Moved change of of_get_next_child_scoped() to
  of_get_next_child_with_prefix() to previous patch
- Restructured into helpers for the I2C OF component prober
- Reduced to only handle one regulator
- Commit message updated

Changes since v5:
- Split of_regulator_bulk_get_all() return value check and explain
  "ret == 0" case
- Switched to of_get_next_child_with_prefix_scoped() where applicable
- Used krealloc_array() instead of directly calculating size
- copy whole regulator array in one memcpy() call
- Drop "0" from struct zeroing initializer
- Split out regulator helper from i2c_of_probe_enable_res() to keep
  code cleaner when combined with the next patch
- Added options for customizing power sequencing delay
- Rename i2c_of_probe_get_regulator() to i2c_of_probe_get_regulators()
- Add i2c_of_probe_free_regulator() helper

Changes since v4:
- Split out GPIO handling to separate patch
- Rewrote using of_regulator_bulk_get_all()
- Replaced "regulators" with "regulator supplies" in debug messages

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 | 169 ++++++++++++++++++++++++++++++-
 include/linux/i2c-of-prober.h    |  48 +++++++++
 2 files changed, 216 insertions(+), 1 deletion(-)

diff --git a/drivers/i2c/i2c-core-of-prober.c b/drivers/i2c/i2c-core-of-prober.c
index 62ff2f4b6177..1371ea565556 100644
--- a/drivers/i2c/i2c-core-of-prober.c
+++ b/drivers/i2c/i2c-core-of-prober.c
@@ -6,6 +6,7 @@
  */
 
 #include <linux/cleanup.h>
+#include <linux/delay.h>
 #include <linux/device.h>
 #include <linux/dev_printk.h>
 #include <linux/err.h>
@@ -13,6 +14,7 @@
 #include <linux/i2c-of-prober.h>
 #include <linux/module.h>
 #include <linux/of.h>
+#include <linux/regulator/consumer.h>
 #include <linux/slab.h>
 
 /*
@@ -28,7 +30,6 @@
  * address responds.
  *
  * TODO:
- * - Support handling common regulators.
  * - Support handling common GPIOs.
  * - Support I2C muxes
  */
@@ -193,3 +194,169 @@ int i2c_of_probe_component(struct device *dev, const struct i2c_of_probe_cfg *cf
 	return ret;
 }
 EXPORT_SYMBOL_NS_GPL(i2c_of_probe_component, I2C_OF_PROBER);
+
+static int i2c_of_probe_simple_get_supply(struct device *dev, struct device_node *node,
+					  struct i2c_of_probe_simple_ctx *ctx)
+{
+	const char *supply_name;
+	struct regulator *supply;
+
+	/*
+	 * It's entirely possible for the component's device node to not have regulator
+	 * supplies. While it does not make sense from a hardware perspective, the
+	 * supplies could be always on or otherwise not modeled in the device tree, but
+	 * the device would still work.
+	 */
+	supply_name = ctx->opts->supply_name;
+	if (!supply_name)
+		return 0;
+
+	supply = of_regulator_get_optional(dev, node, supply_name);
+	if (IS_ERR(supply)) {
+		return dev_err_probe(dev, PTR_ERR(supply),
+				     "Failed to get regulator supply \"%s\" from %pOF\n",
+				     supply_name, node);
+	}
+
+	ctx->supply = supply;
+
+	return 0;
+}
+
+static void i2c_of_probe_simple_put_supply(struct i2c_of_probe_simple_ctx *ctx)
+{
+	regulator_put(ctx->supply);
+	ctx->supply = NULL;
+}
+
+static int i2c_of_probe_simple_enable_regulator(struct device *dev, struct i2c_of_probe_simple_ctx *ctx)
+{
+	int ret;
+
+	if (!ctx->supply)
+		return 0;
+
+	dev_dbg(dev, "Enabling regulator supply \"%s\"\n", ctx->opts->supply_name);
+
+	ret = regulator_enable(ctx->supply);
+	if (ret)
+		return ret;
+
+	msleep(ctx->opts->post_power_on_delay_ms);
+
+	return 0;
+}
+
+static void i2c_of_probe_simple_disable_regulator(struct device *dev, struct i2c_of_probe_simple_ctx *ctx)
+{
+	if (!ctx->supply)
+		return;
+
+	dev_dbg(dev, "Disabling regulator supply \"%s\"\n", ctx->opts->supply_name);
+
+	regulator_disable(ctx->supply);
+}
+
+/**
+ * i2c_of_probe_simple_get_res - Simple helper for I2C OF prober to get resources
+ * @dev: Pointer to the &struct device of the caller, only used for dev_printk() messages
+ * @bus_node: Pointer to the &struct device_node of the I2C adapter.
+ * @data: Pointer to &struct i2c_of_probe_simple_ctx helper context.
+ *
+ * If &i2c_of_probe_simple_opts->supply_name is given, request the named regulator supply.
+ *
+ * Return: %0 on success or no-op, or a negative error number on failure.
+ */
+int i2c_of_probe_simple_get_res(struct device *dev, struct device_node *bus_node, void *data)
+{
+	struct i2c_of_probe_simple_ctx *ctx = data;
+	struct device_node *node;
+	const char *compat;
+	int ret;
+
+	dev_dbg(dev, "Requesting resources for components under I2C bus %pOF\n", bus_node);
+
+	if (!ctx || !ctx->opts)
+		return -EINVAL;
+
+	compat = ctx->opts->res_node_compatible;
+	if (!compat)
+		return -EINVAL;
+
+	node = of_get_compatible_child(bus_node, compat);
+	if (!node)
+		return dev_err_probe(dev, -ENODEV, "No device compatible with \"%s\" found\n",
+				     compat);
+
+	ret = i2c_of_probe_simple_get_supply(dev, node, ctx);
+	if (ret)
+		goto out_put_node;
+
+	return 0;
+
+out_put_node:
+	of_node_put(node);
+	return ret;
+}
+EXPORT_SYMBOL_NS_GPL(i2c_of_probe_simple_get_res, I2C_OF_PROBER);
+
+/**
+ * i2c_of_probe_simple_free_res_late - Simple helper for I2C OF prober to release all resources.
+ * @data: Pointer to &struct i2c_of_probe_simple_ctx helper context.
+ */
+void i2c_of_probe_simple_free_res_late(void *data)
+{
+	struct i2c_of_probe_simple_ctx *ctx = data;
+
+	i2c_of_probe_simple_put_supply(ctx);
+}
+EXPORT_SYMBOL_NS_GPL(i2c_of_probe_simple_free_res_late, I2C_OF_PROBER);
+
+/**
+ * i2c_of_probe_simple_enable - Enable resources for I2C OF prober simple helpers
+ * @dev: Pointer to the &struct device of the caller, only used for dev_printk() messages
+ * @data: Pointer to &struct i2c_of_probe_simple_ctx helper context.
+ *
+ * If a regulator supply was found, enable that regulator.
+ *
+ * Return: %0 on success or no-op, or a negative error number on failure.
+ */
+int i2c_of_probe_simple_enable(struct device *dev, void *data)
+{
+	struct i2c_of_probe_simple_ctx *ctx = data;
+	int ret;
+
+	ret = i2c_of_probe_simple_enable_regulator(dev, ctx);
+	if (ret)
+		return ret;
+
+	return 0;
+}
+EXPORT_SYMBOL_NS_GPL(i2c_of_probe_simple_enable, I2C_OF_PROBER);
+
+/**
+ * i2c_of_probe_simple_cleanup - Clean up resources for I2C OF prober simple helpers
+ * @dev: Pointer to the &struct device of the caller, only used for dev_printk() messages
+ * @data: Pointer to &struct i2c_of_probe_simple_ctx helper context.
+ *
+ * If a regulator supply was found, disable that regulator.
+ *
+ * Return: %0 on success or no-op, or a negative error number on failure.
+ */
+int i2c_of_probe_simple_cleanup(struct device *dev, void *data)
+{
+	struct i2c_of_probe_simple_ctx *ctx = data;
+
+	i2c_of_probe_simple_disable_regulator(dev, ctx);
+
+	return 0;
+}
+EXPORT_SYMBOL_NS_GPL(i2c_of_probe_simple_cleanup, I2C_OF_PROBER);
+
+struct i2c_of_probe_ops i2c_of_probe_simple_ops = {
+	.get_resources = i2c_of_probe_simple_get_res,
+	.enable = i2c_of_probe_simple_enable,
+	.cleanup = i2c_of_probe_simple_cleanup,
+	.free_resources_late = i2c_of_probe_simple_free_res_late,
+};
+EXPORT_SYMBOL_NS_GPL(i2c_of_probe_simple_ops, I2C_OF_PROBER);
diff --git a/include/linux/i2c-of-prober.h b/include/linux/i2c-of-prober.h
index 0f94e7c94310..541451fbf58d 100644
--- a/include/linux/i2c-of-prober.h
+++ b/include/linux/i2c-of-prober.h
@@ -68,6 +68,54 @@ struct i2c_of_probe_cfg {
 
 int i2c_of_probe_component(struct device *dev, const struct i2c_of_probe_cfg *cfg, void *ctx);
 
+/**
+ * DOC: I2C OF component prober simple helpers
+ *
+ * Components such as trackpads are commonly connected to a devices baseboard
+ * with a 6-pin ribbon cable. That gives at most one voltage supply and one
+ * GPIO besides the I2C bus, interrupt pin, and common ground. Touchscreens,
+ * while integrated into the display panel's connection, typically have the
+ * same set of connections.
+ *
+ * A simple set of helpers are provided here for use with the I2C OF component
+ * prober. This implementation targets such components, allowing for at most
+ * one regulator supply.
+ *
+ * The following helpers are provided:
+ * * i2c_of_probe_simple_get_res()
+ * * i2c_of_probe_simple_free_res_late()
+ * * i2c_of_probe_simple_enable()
+ * * i2c_of_probe_simple_cleanup()
+ */
+
+/**
+ * struct i2c_of_probe_simple_opts - Options for simple I2C component prober callbacks
+ * @res_node_compatible: Compatible string of device node to retrieve resources from.
+ * @supply_name: Name of regulator supply.
+ * @post_power_on_delay_ms: Delay in ms after regulators are powered on. Passed to msleep().
+ */
+struct i2c_of_probe_simple_opts {
+	const char *res_node_compatible;
+	const char *supply_name;
+	unsigned int post_power_on_delay_ms;
+};
+
+struct regulator;
+
+struct i2c_of_probe_simple_ctx {
+	/* public: provided by user before helpers are used. */
+	const struct i2c_of_probe_simple_opts *opts;
+	/* private: internal fields for helpers. */
+	struct regulator *supply;
+};
+
+int i2c_of_probe_simple_get_res(struct device *dev, struct device_node *bus_node, void *data);
+void i2c_of_probe_simple_free_res_late(void *data);
+int i2c_of_probe_simple_enable(struct device *dev, void *data);
+int i2c_of_probe_simple_cleanup(struct device *dev, void *data);
+
+extern struct i2c_of_probe_ops i2c_of_probe_simple_ops;
+
 #endif /* IS_ENABLED(CONFIG_OF_DYNAMIC) */
 
 #endif /* _LINUX_I2C_OF_PROBER_H */
-- 
2.46.0.598.g6f2099f65c-goog



^ permalink raw reply related	[flat|nested] 37+ messages in thread

* [PATCH v7 08/10] i2c: of-prober: Add GPIO support to simple helpers
  2024-09-11  7:27 [PATCH v7 00/10] platform/chrome: Introduce DT hardware prober Chen-Yu Tsai
                   ` (6 preceding siblings ...)
  2024-09-11  7:27 ` [PATCH v7 07/10] i2c: of-prober: Add simple helpers for regulator support Chen-Yu Tsai
@ 2024-09-11  7:27 ` Chen-Yu Tsai
  2024-09-13 10:52   ` Andy Shevchenko
                     ` (2 more replies)
  2024-09-11  7:27 ` [PATCH v7 09/10] platform/chrome: Introduce device tree hardware prober Chen-Yu Tsai
                   ` (2 subsequent siblings)
  10 siblings, 3 replies; 37+ messages in thread
From: Chen-Yu Tsai @ 2024-09-11  7:27 UTC (permalink / raw)
  To: Rob Herring, Saravana Kannan, Matthias Brugger,
	AngeloGioacchino Del Regno, Wolfram Sang, Benson Leung,
	Tzung-Bi Shih, Mark Brown, Liam Girdwood
  Cc: Chen-Yu Tsai, chrome-platform, devicetree, linux-arm-kernel,
	linux-mediatek, linux-kernel, Douglas Anderson, Johan Hovold,
	Jiri Kosina, Andy Shevchenko, linux-i2c

Add GPIO support to the simple helpers for 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.
Regulator supplies were handled in the previous patch.

The assumption is that the same class of components to be probed are
always connected in the same fashion with the same regulator supply
and GPIO. The names may vary due to binding differences, but the
physical layout does not change.

This supports at most one GPIO pin. The user must specify the GPIO name,
the polarity, and the amount of time to wait after the GPIO is toggled.
Devices with more than one GPIO pin likely require specific power
sequencing beyond what generic code can easily support.

Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>

---
Changes since v6:
- Restructured into helpers for the I2C OF component prober
- Reduced to only handle one GPIO
- Set GPIO to input on (failure) cleanup
- Updated commit message

Changes since v5:
- Renamed "con" to "propname" in i2c_of_probe_get_gpiod()
- Copy string first and check return value of strscpy() for overflow in
  i2c_of_probe_get_gpiod()
- Add parenthesis around "enable" and "reset" GPIO names in comments
- Split resource count debug message into two separate lines
- Split out GPIO helper from i2c_of_probe_enable_res() to keep code
  cleaner following the previous patch
- Adopted options for customizing power sequencing delay following
  previous patch

Changes since v4:
- Split out from previous patch
- Moved GPIO property name check to common function in gpiolib.c in new
  patch
- Moved i2c_of_probe_free_gpios() into for_each_child_of_node_scoped()
- Rewrote in gpiod_*_array-esque fashion
---
 drivers/i2c/i2c-core-of-prober.c | 95 +++++++++++++++++++++++++++++++-
 include/linux/i2c-of-prober.h    | 10 ++++
 2 files changed, 104 insertions(+), 1 deletion(-)

diff --git a/drivers/i2c/i2c-core-of-prober.c b/drivers/i2c/i2c-core-of-prober.c
index 1371ea565556..6794ec749882 100644
--- a/drivers/i2c/i2c-core-of-prober.c
+++ b/drivers/i2c/i2c-core-of-prober.c
@@ -10,6 +10,7 @@
 #include <linux/device.h>
 #include <linux/dev_printk.h>
 #include <linux/err.h>
+#include <linux/gpio/consumer.h>
 #include <linux/i2c.h>
 #include <linux/i2c-of-prober.h>
 #include <linux/module.h>
@@ -30,7 +31,6 @@
  * address responds.
  *
  * TODO:
- * - Support handling common GPIOs.
  * - Support I2C muxes
  */
 
@@ -257,6 +257,64 @@ static void i2c_of_probe_simple_disable_regulator(struct device *dev, struct i2c
 	regulator_disable(ctx->supply);
 }
 
+static int i2c_of_probe_simple_get_gpiod(struct device *dev, struct device_node *node,
+					 struct i2c_of_probe_simple_ctx *ctx)
+{
+	struct fwnode_handle *fwnode = of_fwnode_handle(node);
+	struct gpio_desc *gpiod;
+	const char *con_id = NULL;
+
+	/* NULL signals no GPIO needed */
+	if (!ctx->opts->gpio_name)
+		return 0;
+
+	/* An empty string signals an unnamed GPIO */
+	if (strlen(ctx->opts->gpio_name))
+		con_id = ctx->opts->gpio_name;
+
+	gpiod = fwnode_gpiod_get_index(fwnode, con_id, 0, GPIOD_ASIS, "i2c-of-prober");
+	if (IS_ERR(gpiod))
+		return PTR_ERR(gpiod);
+
+	ctx->gpiod = gpiod;
+
+	return 0;
+}
+
+static void i2c_of_probe_simple_put_gpiod(struct i2c_of_probe_simple_ctx *ctx)
+{
+	gpiod_put(ctx->gpiod);
+	ctx->gpiod = NULL;
+}
+
+static int i2c_of_probe_simple_set_gpio(struct device *dev, struct i2c_of_probe_simple_ctx *ctx)
+{
+	int ret;
+
+	if (!ctx->gpiod)
+		return 0;
+
+	dev_dbg(dev, "Setting GPIO\n");
+
+	ret = gpiod_direction_output_raw(ctx->gpiod, ctx->opts->gpio_high_to_enable ? 1 : 0);
+	if (ret)
+		return ret;
+
+	msleep(ctx->opts->post_reset_deassert_delay_ms);
+
+	return 0;
+}
+
+static void i2c_of_probe_simple_disable_gpio(struct device *dev, struct i2c_of_probe_simple_ctx *ctx)
+{
+	if (!ctx->gpiod)
+		return;
+
+	dev_dbg(dev, "Setting GPIO to input\n");
+
+	gpiod_direction_input(ctx->gpiod);
+}
+
 /**
  * i2c_of_probe_simple_get_res - Simple helper for I2C OF prober to get resources
  * @dev: Pointer to the &struct device of the caller, only used for dev_printk() messages
@@ -264,6 +322,8 @@ static void i2c_of_probe_simple_disable_regulator(struct device *dev, struct i2c
  * @data: Pointer to &struct i2c_of_probe_simple_ctx helper context.
  *
  * If &i2c_of_probe_simple_opts->supply_name is given, request the named regulator supply.
+ * If &i2c_of_probe_simple_opts->gpio_name is given, request the named GPIO. Or if it is
+ * the empty string, request the unnamed GPIO.
  *
  * Return: %0 on success or no-op, or a negative error number on failure.
  */
@@ -292,14 +352,36 @@ int i2c_of_probe_simple_get_res(struct device *dev, struct device_node *bus_node
 	if (ret)
 		goto out_put_node;
 
+	ret = i2c_of_probe_simple_get_gpiod(dev, node, ctx);
+	if (ret)
+		goto out_put_supply;
+
 	return 0;
 
+out_put_supply:
+	i2c_of_probe_simple_put_supply(ctx);
 out_put_node:
 	of_node_put(node);
 	return ret;
 }
 EXPORT_SYMBOL_NS_GPL(i2c_of_probe_simple_get_res, I2C_OF_PROBER);
 
+/**
+ * i2c_of_probe_simple_free_res_early - \
+ *	Simple helper for I2C OF prober to release GPIOs before component is enabled
+ * @data: Pointer to &struct i2c_of_probe_simple_ctx helper context.
+ *
+ * GPIO descriptors are exclusive and have to be released before the
+ * actual driver probes so that the latter can acquire them.
+ */
+void i2c_of_probe_simple_free_res_early(void *data)
+{
+	struct i2c_of_probe_simple_ctx *ctx = data;
+
+	i2c_of_probe_simple_put_gpiod(ctx);
+}
+EXPORT_SYMBOL_NS_GPL(i2c_of_probe_simple_free_res_early, I2C_OF_PROBER);
+
 /**
  * i2c_of_probe_simple_free_res_late - Simple helper for I2C OF prober to release all resources.
  * @data: Pointer to &struct i2c_of_probe_simple_ctx helper context.
@@ -308,6 +390,7 @@ void i2c_of_probe_simple_free_res_late(void *data)
 {
 	struct i2c_of_probe_simple_ctx *ctx = data;
 
+	i2c_of_probe_simple_put_gpiod(ctx);
 	i2c_of_probe_simple_put_supply(ctx);
 }
 EXPORT_SYMBOL_NS_GPL(i2c_of_probe_simple_free_res_late, I2C_OF_PROBER);
@@ -330,7 +413,15 @@ int i2c_of_probe_simple_enable(struct device *dev, void *data)
 	if (ret)
 		return ret;
 
+	ret = i2c_of_probe_simple_set_gpio(dev, ctx);
+	if (ret)
+		goto err;
+
 	return 0;
+
+err:
+	i2c_of_probe_simple_disable_regulator(dev, ctx);
+	return ret;
 }
 EXPORT_SYMBOL_NS_GPL(i2c_of_probe_simple_enable, I2C_OF_PROBER);
 
@@ -347,6 +438,7 @@ int i2c_of_probe_simple_cleanup(struct device *dev, void *data)
 {
 	struct i2c_of_probe_simple_ctx *ctx = data;
 
+	i2c_of_probe_simple_disable_gpio(dev, ctx);
 	i2c_of_probe_simple_disable_regulator(dev, ctx);
 
 	return 0;
@@ -355,6 +447,7 @@ EXPORT_SYMBOL_NS_GPL(i2c_of_probe_simple_cleanup, I2C_OF_PROBER);
 
 struct i2c_of_probe_ops i2c_of_probe_simple_ops = {
 	.get_resources = i2c_of_probe_simple_get_res,
+	.free_resources_early = i2c_of_probe_simple_free_res_early,
 	.enable = i2c_of_probe_simple_enable,
 	.cleanup = i2c_of_probe_simple_cleanup,
 	.free_resources_late = i2c_of_probe_simple_free_res_late,
diff --git a/include/linux/i2c-of-prober.h b/include/linux/i2c-of-prober.h
index 541451fbf58d..c5e241163c94 100644
--- a/include/linux/i2c-of-prober.h
+++ b/include/linux/i2c-of-prober.h
@@ -83,6 +83,7 @@ int i2c_of_probe_component(struct device *dev, const struct i2c_of_probe_cfg *cf
  *
  * The following helpers are provided:
  * * i2c_of_probe_simple_get_res()
+ * * i2c_of_probe_simple_free_res_early()
  * * i2c_of_probe_simple_free_res_late()
  * * i2c_of_probe_simple_enable()
  * * i2c_of_probe_simple_cleanup()
@@ -92,24 +93,33 @@ int i2c_of_probe_component(struct device *dev, const struct i2c_of_probe_cfg *cf
  * struct i2c_of_probe_simple_opts - Options for simple I2C component prober callbacks
  * @res_node_compatible: Compatible string of device node to retrieve resources from.
  * @supply_name: Name of regulator supply.
+ * @gpio_name: Name of GPIO.
  * @post_power_on_delay_ms: Delay in ms after regulators are powered on. Passed to msleep().
+ * @post_reset_deassert_delay_ms: Delay in ms after GPIOs are set. Passed to msleep().
+ * @gpio_high_to_enable: %true if GPIO should be set to electrical high to enable component.
  */
 struct i2c_of_probe_simple_opts {
 	const char *res_node_compatible;
 	const char *supply_name;
+	const char *gpio_name;
 	unsigned int post_power_on_delay_ms;
+	unsigned int post_reset_deassert_delay_ms;
+	bool gpio_high_to_enable;
 };
 
 struct regulator;
+struct gpio_desc;
 
 struct i2c_of_probe_simple_ctx {
 	/* public: provided by user before helpers are used. */
 	const struct i2c_of_probe_simple_opts *opts;
 	/* private: internal fields for helpers. */
 	struct regulator *supply;
+	struct gpio_desc *gpiod;
 };
 
 int i2c_of_probe_simple_get_res(struct device *dev, struct device_node *bus_node, void *data);
+void i2c_of_probe_simple_free_res_early(void *data);
 void i2c_of_probe_simple_free_res_late(void *data);
 int i2c_of_probe_simple_enable(struct device *dev, void *data);
 int i2c_of_probe_simple_cleanup(struct device *dev, void *data);
-- 
2.46.0.598.g6f2099f65c-goog



^ permalink raw reply related	[flat|nested] 37+ messages in thread

* [PATCH v7 09/10] platform/chrome: Introduce device tree hardware prober
  2024-09-11  7:27 [PATCH v7 00/10] platform/chrome: Introduce DT hardware prober Chen-Yu Tsai
                   ` (7 preceding siblings ...)
  2024-09-11  7:27 ` [PATCH v7 08/10] i2c: of-prober: Add GPIO support to simple helpers Chen-Yu Tsai
@ 2024-09-11  7:27 ` Chen-Yu Tsai
  2024-09-13 23:43   ` Doug Anderson
  2024-09-11  7:27 ` [PATCH v7 10/10] arm64: dts: mediatek: mt8173-elm-hana: Mark touchscreens and trackpads as fail Chen-Yu Tsai
  2024-09-13 18:08 ` (subset) [PATCH v7 00/10] platform/chrome: Introduce DT hardware prober Mark Brown
  10 siblings, 1 reply; 37+ messages in thread
From: Chen-Yu Tsai @ 2024-09-11  7:27 UTC (permalink / raw)
  To: Rob Herring, Saravana Kannan, Matthias Brugger,
	AngeloGioacchino Del Regno, Wolfram Sang, Benson Leung,
	Tzung-Bi Shih, Mark Brown, Liam Girdwood
  Cc: Chen-Yu Tsai, chrome-platform, devicetree, linux-arm-kernel,
	linux-mediatek, linux-kernel, Douglas Anderson, Johan Hovold,
	Jiri Kosina, Andy Shevchenko, linux-i2c

Some devices are designed and manufactured with some components having
multiple drop-in replacement options. These components are often
connected to the mainboard via ribbon cables, having the same signals
and pin assignments across all options. These may include the display
panel and touchscreen on laptops and tablets, and the trackpad on
laptops. Sometimes which component option is used in a particular device
can be detected by some firmware provided identifier, other times that
information is not available, and the kernel has to try to probe each
device.

This change attempts to make the "probe each device" case cleaner. The
current approach is to have all options added and enabled in the device
tree. The kernel would then bind each device and run each driver's probe
function. This works, but has been broken before due to the introduction
of asynchronous probing, causing multiple instances requesting "shared"
resources, such as pinmuxes, GPIO pins, interrupt lines, at the same
time, with only one instance succeeding. Work arounds for these include
moving the pinmux to the parent I2C controller, using GPIO hogs or
pinmux settings to keep the GPIO pins in some fixed configuration, and
requesting the interrupt line very late. Such configurations can be seen
on the MT8183 Krane Chromebook tablets, and the Qualcomm sc8280xp-based
Lenovo Thinkpad 13S.

Instead of this delicate dance between drivers and device tree quirks,
this change introduces a simple I2C component prober. For any given
class of devices on the same I2C bus, it will go through all of them,
doing a simple I2C read transfer and see which one of them responds.
It will then enable the device that responds.

This requires some minor modifications in the existing device tree.
The status for all the device nodes for the component options must be
set to "failed-needs-probe". This makes it clear that some mechanism is
needed to enable one of them, and also prevents the prober and device
drivers running at the same time.

Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
Acked-by: Tzung-Bi Shih <tzungbi@kernel.org>
---
Changes since v6:
- Adapted to new I2C OF prober interface
- Collected Acked-by

Changes since v5:
- Adapt to new i2c_of_probe_component() parameters

Changes since v4:
- Fix Kconfig dependency
- Update copyright year
- Drop "linux/of.h" header
- Include "linux/errno.h"
- Move |int ret| declaration to top of block
- Return -ENODEV on no match instead of 0
- Unregister platform driver and device unconditionally after previous
  change

Changes since v3:
- Include linux/init.h
- Rewrite for loop in driver probe function as suggested by Andy
- Make prober driver buildable as module
- Ignore prober errors other than probe deferral

Changes since v2:
- Addressed Rob's comments
  - Move remaining driver code to drivers/platform/chrome/
  - Depend on rather than select CONFIG_I2C
  - Copy machine check to driver init function
- Addressed Andy's comments
  - Explicitly mention "device tree" or OF in driver name, description
    and Kconfig symbol
  - Drop filename from inside the file
  - Switch to passing "struct device *" to shorten lines
  - Move "ret = 0" to just before for_each_child_of_node(i2c_node, node)
  - Make loop variable size_t (instead of unsigned int as Andy asked)
  - Use PLATFORM_DEVID_NONE instead of raw -1
  - Use standard goto error path pattern in hw_prober_driver_init()

- Changes since v1:
  - New patch
---
 drivers/platform/chrome/Kconfig               |  11 ++
 drivers/platform/chrome/Makefile              |   1 +
 .../platform/chrome/chromeos_of_hw_prober.c   | 125 ++++++++++++++++++
 3 files changed, 137 insertions(+)
 create mode 100644 drivers/platform/chrome/chromeos_of_hw_prober.c

diff --git a/drivers/platform/chrome/Kconfig b/drivers/platform/chrome/Kconfig
index 7dbeb786352a..b7dbaf77b6db 100644
--- a/drivers/platform/chrome/Kconfig
+++ b/drivers/platform/chrome/Kconfig
@@ -61,6 +61,17 @@ config CHROMEOS_TBMC
 	  To compile this driver as a module, choose M here: the
 	  module will be called chromeos_tbmc.
 
+config CHROMEOS_OF_HW_PROBER
+	tristate "ChromeOS Device Tree Hardware Prober"
+	depends on OF
+	depends on I2C
+	select OF_DYNAMIC
+	default OF
+	help
+	  This option enables the device tree hardware prober for ChromeOS
+	  devices. The driver will probe the correct component variant in
+	  devices that have multiple drop-in options for one component.
+
 config CROS_EC
 	tristate "ChromeOS Embedded Controller"
 	select CROS_EC_PROTO
diff --git a/drivers/platform/chrome/Makefile b/drivers/platform/chrome/Makefile
index 2dcc6ccc2302..21a9d5047053 100644
--- a/drivers/platform/chrome/Makefile
+++ b/drivers/platform/chrome/Makefile
@@ -8,6 +8,7 @@ obj-$(CONFIG_CHROMEOS_ACPI)		+= chromeos_acpi.o
 obj-$(CONFIG_CHROMEOS_LAPTOP)		+= chromeos_laptop.o
 obj-$(CONFIG_CHROMEOS_PRIVACY_SCREEN)	+= chromeos_privacy_screen.o
 obj-$(CONFIG_CHROMEOS_PSTORE)		+= chromeos_pstore.o
+obj-$(CONFIG_CHROMEOS_OF_HW_PROBER)	+= chromeos_of_hw_prober.o
 obj-$(CONFIG_CHROMEOS_TBMC)		+= chromeos_tbmc.o
 obj-$(CONFIG_CROS_EC)			+= cros_ec.o
 obj-$(CONFIG_CROS_EC_I2C)		+= cros_ec_i2c.o
diff --git a/drivers/platform/chrome/chromeos_of_hw_prober.c b/drivers/platform/chrome/chromeos_of_hw_prober.c
new file mode 100644
index 000000000000..6d9667c40cc7
--- /dev/null
+++ b/drivers/platform/chrome/chromeos_of_hw_prober.c
@@ -0,0 +1,125 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * ChromeOS Device Tree Hardware Prober
+ *
+ * Copyright (c) 2024 Google LLC
+ */
+
+#include <linux/array_size.h>
+#include <linux/errno.h>
+#include <linux/i2c-of-prober.h>
+#include <linux/module.h>
+#include <linux/platform_device.h>
+
+#define DRV_NAME	"chromeos_of_hw_prober"
+
+/**
+ * struct hw_prober_entry - Holds an entry for the hardware prober
+ *
+ * @compatible:	compatible string to match against the machine
+ * @prober:	prober function to call when machine matches
+ * @data:	extra data for the prober function
+ */
+struct hw_prober_entry {
+	const char *compatible;
+	int (*prober)(struct device *dev, const void *data);
+	const void *data;
+};
+
+struct chromeos_i2c_probe_data {
+	const struct i2c_of_probe_cfg *cfg;
+	const struct i2c_of_probe_simple_opts *opts;
+};
+
+static int chromeos_i2c_component_prober(struct device *dev, const void *_data)
+{
+	const struct chromeos_i2c_probe_data *data = _data;
+	struct i2c_of_probe_simple_ctx ctx = {
+		.opts = data->opts
+	};
+
+	return i2c_of_probe_component(dev, data->cfg, &ctx);
+}
+
+static const struct chromeos_i2c_probe_data chromeos_i2c_probe_dumb_touchscreen = {
+	.cfg = &(const struct i2c_of_probe_cfg) {
+		.type = "touchscreen"
+	}
+};
+
+static const struct chromeos_i2c_probe_data chromeos_i2c_probe_dumb_trackpad = {
+	.cfg = &(const struct i2c_of_probe_cfg) {
+		.type = "trackpad"
+	}
+};
+
+static const struct hw_prober_entry hw_prober_platforms[] = {
+	{ .compatible = "google,hana", .prober = chromeos_i2c_component_prober, .data = &chromeos_i2c_probe_dumb_touchscreen },
+	{ .compatible = "google,hana", .prober = chromeos_i2c_component_prober, .data = &chromeos_i2c_probe_dumb_trackpad },
+};
+
+static int chromeos_of_hw_prober_probe(struct platform_device *pdev)
+{
+	for (size_t i = 0; i < ARRAY_SIZE(hw_prober_platforms); i++) {
+		int ret;
+
+		if (!of_machine_is_compatible(hw_prober_platforms[i].compatible))
+			continue;
+
+		ret = hw_prober_platforms[i].prober(&pdev->dev, hw_prober_platforms[i].data);
+		/* Ignore unrecoverable errors and keep going through other probers */
+		if (ret == -EPROBE_DEFER)
+			return ret;
+	}
+
+	return 0;
+}
+
+static struct platform_driver chromeos_of_hw_prober_driver = {
+	.probe	= chromeos_of_hw_prober_probe,
+	.driver	= {
+		.name = DRV_NAME,
+	},
+};
+
+static struct platform_device *chromeos_of_hw_prober_pdev;
+
+static int chromeos_of_hw_prober_driver_init(void)
+{
+	size_t i;
+	int ret;
+
+	for (i = 0; i < ARRAY_SIZE(hw_prober_platforms); i++)
+		if (of_machine_is_compatible(hw_prober_platforms[i].compatible))
+			break;
+	if (i == ARRAY_SIZE(hw_prober_platforms))
+		return -ENODEV;
+
+	ret = platform_driver_register(&chromeos_of_hw_prober_driver);
+	if (ret)
+		return ret;
+
+	chromeos_of_hw_prober_pdev =
+			platform_device_register_simple(DRV_NAME, PLATFORM_DEVID_NONE, NULL, 0);
+	if (IS_ERR(chromeos_of_hw_prober_pdev))
+		goto err;
+
+	return 0;
+
+err:
+	platform_driver_unregister(&chromeos_of_hw_prober_driver);
+
+	return PTR_ERR(chromeos_of_hw_prober_pdev);
+}
+module_init(chromeos_of_hw_prober_driver_init);
+
+static void chromeos_of_hw_prober_driver_exit(void)
+{
+	platform_device_unregister(chromeos_of_hw_prober_pdev);
+	platform_driver_unregister(&chromeos_of_hw_prober_driver);
+}
+module_exit(chromeos_of_hw_prober_driver_exit);
+
+MODULE_LICENSE("GPL");
+MODULE_DESCRIPTION("ChromeOS device tree hardware prober");
+MODULE_IMPORT_NS(I2C_OF_PROBER);
-- 
2.46.0.598.g6f2099f65c-goog



^ permalink raw reply related	[flat|nested] 37+ messages in thread

* [PATCH v7 10/10] arm64: dts: mediatek: mt8173-elm-hana: Mark touchscreens and trackpads as fail
  2024-09-11  7:27 [PATCH v7 00/10] platform/chrome: Introduce DT hardware prober Chen-Yu Tsai
                   ` (8 preceding siblings ...)
  2024-09-11  7:27 ` [PATCH v7 09/10] platform/chrome: Introduce device tree hardware prober Chen-Yu Tsai
@ 2024-09-11  7:27 ` Chen-Yu Tsai
  2024-09-13 18:08 ` (subset) [PATCH v7 00/10] platform/chrome: Introduce DT hardware prober Mark Brown
  10 siblings, 0 replies; 37+ messages in thread
From: Chen-Yu Tsai @ 2024-09-11  7:27 UTC (permalink / raw)
  To: Rob Herring, Saravana Kannan, Matthias Brugger,
	AngeloGioacchino Del Regno, Wolfram Sang, Benson Leung,
	Tzung-Bi Shih, Mark Brown, Liam Girdwood
  Cc: Chen-Yu Tsai, chrome-platform, devicetree, linux-arm-kernel,
	linux-mediatek, linux-kernel, Douglas Anderson, Johan Hovold,
	Jiri Kosina, Andy Shevchenko, linux-i2c

Instead of having them all available, mark them all as "fail-needs-probe"
and have the implementation try to probe which one is present.

Also remove the shared resource workaround by moving the pinctrl entry
for the trackpad interrupt line back into the individual trackpad nodes.

Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
---
Changes since v6:
None.

Changes since v5:
None.

Changes since v4:
- Rebased

Changes since v3:
- Also remove second source workaround, i.e. move the interrupt line
  pinctrl entry from the i2c node back to the components.

Changes since v2:
- Drop class from status
---
 arch/arm64/boot/dts/mediatek/mt8173-elm-hana.dtsi | 13 +++++++++++++
 arch/arm64/boot/dts/mediatek/mt8173-elm.dtsi      |  4 ++--
 2 files changed, 15 insertions(+), 2 deletions(-)

diff --git a/arch/arm64/boot/dts/mediatek/mt8173-elm-hana.dtsi b/arch/arm64/boot/dts/mediatek/mt8173-elm-hana.dtsi
index 8d1cbc92bce3..251e084bf7de 100644
--- a/arch/arm64/boot/dts/mediatek/mt8173-elm-hana.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8173-elm-hana.dtsi
@@ -14,6 +14,7 @@ touchscreen2: touchscreen@34 {
 		compatible = "melfas,mip4_ts";
 		reg = <0x34>;
 		interrupts-extended = <&pio 88 IRQ_TYPE_LEVEL_LOW>;
+		status = "fail-needs-probe";
 	};
 
 	/*
@@ -26,6 +27,7 @@ touchscreen3: touchscreen@20 {
 		reg = <0x20>;
 		hid-descr-addr = <0x0020>;
 		interrupts-extended = <&pio 88 IRQ_TYPE_LEVEL_LOW>;
+		status = "fail-needs-probe";
 	};
 
 	/* Lenovo Ideapad C330 uses G2Touch touchscreen as a 2nd source touchscreen */
@@ -47,9 +49,12 @@ &i2c4 {
 	trackpad2: trackpad@2c {
 		compatible = "hid-over-i2c";
 		interrupts-extended = <&pio 117 IRQ_TYPE_LEVEL_LOW>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&trackpad_irq>;
 		reg = <0x2c>;
 		hid-descr-addr = <0x0020>;
 		wakeup-source;
+		status = "fail-needs-probe";
 	};
 };
 
@@ -74,3 +79,11 @@ pins_wp {
 		};
 	};
 };
+
+&touchscreen {
+	status = "fail-needs-probe";
+};
+
+&trackpad {
+	status = "fail-needs-probe";
+};
diff --git a/arch/arm64/boot/dts/mediatek/mt8173-elm.dtsi b/arch/arm64/boot/dts/mediatek/mt8173-elm.dtsi
index b4d85147b77b..eee64461421f 100644
--- a/arch/arm64/boot/dts/mediatek/mt8173-elm.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8173-elm.dtsi
@@ -358,12 +358,12 @@ touchscreen: touchscreen@10 {
 &i2c4 {
 	clock-frequency = <400000>;
 	status = "okay";
-	pinctrl-names = "default";
-	pinctrl-0 = <&trackpad_irq>;
 
 	trackpad: trackpad@15 {
 		compatible = "elan,ekth3000";
 		interrupts-extended = <&pio 117 IRQ_TYPE_LEVEL_LOW>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&trackpad_irq>;
 		reg = <0x15>;
 		vcc-supply = <&mt6397_vgp6_reg>;
 		wakeup-source;
-- 
2.46.0.598.g6f2099f65c-goog



^ permalink raw reply related	[flat|nested] 37+ messages in thread

* Re: [PATCH v7 02/10] of: base: Add for_each_child_of_node_with_prefix()
  2024-09-11  7:27 ` [PATCH v7 02/10] of: base: Add for_each_child_of_node_with_prefix() Chen-Yu Tsai
@ 2024-09-12 20:31   ` Rob Herring (Arm)
  0 siblings, 0 replies; 37+ messages in thread
From: Rob Herring (Arm) @ 2024-09-12 20:31 UTC (permalink / raw)
  To: Chen-Yu Tsai
  Cc: Saravana Kannan, chrome-platform, linux-kernel, Andy Shevchenko,
	AngeloGioacchino Del Regno, Johan Hovold, devicetree, Mark Brown,
	Tzung-Bi Shih, Matthias Brugger, Benson Leung, Liam Girdwood,
	linux-arm-kernel, Wolfram Sang, Jiri Kosina, linux-i2c,
	Douglas Anderson, linux-mediatek


On Wed, 11 Sep 2024 15:27:40 +0800, Chen-Yu Tsai wrote:
> There are cases where drivers would go through child device nodes and
> operate on only the ones whose node name starts with a given prefix.
> 
> Provide a helper for these users. This will mainly be used in a
> subsequent patch that implements a hardware component prober for I2C
> busses.
> 
> Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
> ---
> Changes since v6:
> - Changed helper name to "for_each_child_of_node_with_prefix()"
> Changes since v5:
> - New patch
> ---
>  drivers/of/base.c  | 35 +++++++++++++++++++++++++++++++++++
>  include/linux/of.h |  9 +++++++++
>  2 files changed, 44 insertions(+)
> 

Reviewed-by: Rob Herring (Arm) <robh@kernel.org>



^ permalink raw reply	[flat|nested] 37+ messages in thread

* Re: [PATCH v7 06/10] i2c: Introduce OF component probe function
  2024-09-11  7:27 ` [PATCH v7 06/10] i2c: Introduce OF component probe function Chen-Yu Tsai
@ 2024-09-13 10:25   ` Andy Shevchenko
  2024-09-15 10:44     ` Chen-Yu Tsai
  2024-09-13 23:43   ` Doug Anderson
  2024-09-15 10:09   ` Andrey Skvortsov
  2 siblings, 1 reply; 37+ messages in thread
From: Andy Shevchenko @ 2024-09-13 10:25 UTC (permalink / raw)
  To: Chen-Yu Tsai
  Cc: Rob Herring, Saravana Kannan, Matthias Brugger,
	AngeloGioacchino Del Regno, Wolfram Sang, Benson Leung,
	Tzung-Bi Shih, Mark Brown, Liam Girdwood, chrome-platform,
	devicetree, linux-arm-kernel, linux-mediatek, linux-kernel,
	Douglas Anderson, Johan Hovold, Jiri Kosina, linux-i2c

On Wed, Sep 11, 2024 at 03:27:44PM +0800, Chen-Yu Tsai wrote:
> Some devices are designed and manufactured with some components having
> multiple drop-in replacement options. These components are often
> connected to the mainboard via ribbon cables, having the same signals
> and pin assignments across all options. These may include the display
> panel and touchscreen on laptops and tablets, and the trackpad on
> laptops. Sometimes which component option is used in a particular device
> can be detected by some firmware provided identifier, other times that
> information is not available, and the kernel has to try to probe each
> device.
> 
> This change attempts to make the "probe each device" case cleaner. The
> current approach is to have all options added and enabled in the device
> tree. The kernel would then bind each device and run each driver's probe
> function. This works, but has been broken before due to the introduction
> of asynchronous probing, causing multiple instances requesting "shared"
> resources, such as pinmuxes, GPIO pins, interrupt lines, at the same
> time, with only one instance succeeding. Work arounds for these include
> moving the pinmux to the parent I2C controller, using GPIO hogs or
> pinmux settings to keep the GPIO pins in some fixed configuration, and
> requesting the interrupt line very late. Such configurations can be seen
> on the MT8183 Krane Chromebook tablets, and the Qualcomm sc8280xp-based
> Lenovo Thinkpad 13S.
> 
> Instead of this delicate dance between drivers and device tree quirks,
> this change introduces a simple I2C component probe. function For a
> given class of devices on the same I2C bus, it will go through all of
> them, doing a simple I2C read transfer and see which one of them responds.
> It will then enable the device that responds.
> 
> This requires some minor modifications in the existing device tree. The
> status for all the device nodes for the component options must be set
> to "failed-needs-probe". This makes it clear that some mechanism is
> needed to enable one of them, and also prevents the prober and device
> drivers running at the same time.

...

> +static int i2c_of_probe_enable_node(struct device *dev, struct device_node *node)
> +{
> +	int ret;

> +	dev_info(dev, "Enabling %pOF\n", node);

Is it important to be on INFO level?

> +	struct of_changeset *ocs __free(kfree) = kzalloc(sizeof(*ocs), GFP_KERNEL);
> +	if (!ocs)
> +		return -ENOMEM;
> +
> +	of_changeset_init(ocs);
> +	ret = of_changeset_update_prop_string(ocs, node, "status", "okay");
> +	if (ret)
> +		return ret;
> +
> +	ret = of_changeset_apply(ocs);
> +	if (ret) {
> +		/* ocs needs to be explicitly cleaned up before being freed. */
> +		of_changeset_destroy(ocs);
> +	} else {
> +		/*
> +		 * ocs is intentionally kept around as it needs to
> +		 * exist as long as the change is applied.
> +		 */
> +		void *ptr __always_unused = no_free_ptr(ocs);
> +	}
> +
> +	return ret;
> +}

...

> +int i2c_of_probe_component(struct device *dev, const struct i2c_of_probe_cfg *cfg, void *ctx)
> +{
> +	const struct i2c_of_probe_ops *ops;
> +	const char *type;
> +	struct device_node *i2c_node;
> +	struct i2c_adapter *i2c;
> +	int ret;
> +
> +	if (!cfg)
> +		return -EINVAL;
> +
> +	ops = cfg->ops ?: &i2c_of_probe_dummy_ops;
> +	type = cfg->type;
> +
> +	i2c_node = i2c_of_probe_get_i2c_node(dev, type);


	struct device_node *i2c_node __free(of_node_put) =
		i2c_...;

> +	if (IS_ERR(i2c_node))
> +		return PTR_ERR(i2c_node);
> +
> +	for_each_child_of_node_with_prefix(i2c_node, node, type) {
> +		if (!of_device_is_available(node))
> +			continue;
> +
> +		/*
> +		 * Device tree has component already enabled. Either the
> +		 * device tree isn't supported or we already probed once.
> +		 */
> +		ret = 0;

Shouldn't you drop reference count for "node"? (See also below)

> +		goto out_put_i2c_node;
> +	}
> +
> +	i2c = of_get_i2c_adapter_by_node(i2c_node);
> +	if (!i2c) {
> +		ret = dev_err_probe(dev, -EPROBE_DEFER, "Couldn't get I2C adapter\n");
> +		goto out_put_i2c_node;
> +	}
> +
> +	/* Grab resources */
> +	ret = 0;
> +	if (ops->get_resources)
> +		ret = ops->get_resources(dev, i2c_node, ctx);
> +	if (ret)
> +		goto out_put_i2c_adapter;
> +
> +	/* Enable resources */
> +	if (ops->enable)
> +		ret = ops->enable(dev, ctx);
> +	if (ret)
> +		goto out_release_resources;
> +
> +	ret = 0;
> +	for_each_child_of_node_with_prefix(i2c_node, node, type) {
> +		union i2c_smbus_data data;
> +		u32 addr;
> +
> +		if (of_property_read_u32(node, "reg", &addr))
> +			continue;
> +		if (i2c_smbus_xfer(i2c, addr, 0, I2C_SMBUS_READ, 0, I2C_SMBUS_BYTE, &data) < 0)
> +			continue;
> +
> +		/* Found a device that is responding */
> +		if (ops->free_resources_early)
> +			ops->free_resources_early(ctx);
> +		ret = i2c_of_probe_enable_node(dev, node);

Hmm... Is "node" reference count left bumped up for a reason?

> +		break;
> +	}
> +
> +	if (ops->cleanup)
> +		ops->cleanup(dev, ctx);
> +out_release_resources:
> +	if (ops->free_resources_late)
> +		ops->free_resources_late(ctx);
> +out_put_i2c_adapter:
> +	i2c_put_adapter(i2c);
> +out_put_i2c_node:
> +	of_node_put(i2c_node);
> +
> +	return ret;
> +}

...

> +/*
> + * i2c-of-prober.h - definitions for the Linux I2C OF component prober

Please avoid putting filenames inside files. In the possible future event of
file renaming this may become a burden and sometimes even forgotten.

> + * Copyright (C) 2024 Google LLC
> + */
> +
> +#ifndef _LINUX_I2C_OF_PROBER_H
> +#define _LINUX_I2C_OF_PROBER_H

> +#if IS_ENABLED(CONFIG_OF_DYNAMIC)

Do you really need to hide data types with this? Wouldn't be enough to hide
APIs only?

> +struct device;
> +struct device_node;
> +
> +/**
> + * struct i2c_of_probe_ops - I2C OF component prober callbacks
> + *
> + * A set of callbacks to be used by i2c_of_probe_component().
> + *
> + * All callbacks are optional. Callbacks are called only once per run, and are
> + * used in the order they are defined in this structure.
> + *
> + * All callbacks that have return values shall return %0 on success,
> + * or a negative error number on failure.
> + *
> + * The @dev parameter passed to the callbacks is the same as @dev passed to
> + * i2c_of_probe_component(). It should only be used for dev_printk() calls
> + * and nothing else, especially not managed device resource (devres) APIs.
> + */
> +struct i2c_of_probe_ops {
> +	/** @get_resources: Retrieve resources for components. */
> +	int (*get_resources)(struct device *dev, struct device_node *bus_node, void *data);
> +
> +	/** @free_resources_early: Release exclusive resources prior to enabling component. */
> +	void (*free_resources_early)(void *data);
> +
> +	/**
> +	 * @enable: Enable resources so that the components respond to probes.
> +	 *
> +	 * Resources should be reverted to their initial state before returning if this fails.
> +	 */
> +	int (*enable)(struct device *dev, void *data);
> +
> +	/**
> +	 * @cleanup: Opposite of @enable to balance refcounts after probing.
> +	 *
> +	 * Can not operate on resources already freed in @free_resources_early.
> +	 */
> +	int (*cleanup)(struct device *dev, void *data);
> +
> +	/**
> +	 * @free_resources_late: Release all resources, including those that would have
> +	 *                       been released by @free_resources_early.
> +	 */
> +	void (*free_resources_late)(void *data);
> +};
> +
> +/**
> + * struct i2c_of_probe_cfg - I2C OF component prober configuration
> + * @ops: Callbacks for the prober to use.
> + * @type: A string to match the device node name prefix to probe for.
> + */
> +struct i2c_of_probe_cfg {
> +	const struct i2c_of_probe_ops *ops;
> +	const char *type;
> +};
> +
> +int i2c_of_probe_component(struct device *dev, const struct i2c_of_probe_cfg *cfg, void *ctx);
> +
> +#endif /* IS_ENABLED(CONFIG_OF_DYNAMIC) */
> +
> +#endif /* _LINUX_I2C_OF_PROBER_H */

-- 
With Best Regards,
Andy Shevchenko




^ permalink raw reply	[flat|nested] 37+ messages in thread

* Re: [PATCH v7 03/10] regulator: Split up _regulator_get()
  2024-09-11  7:27 ` [PATCH v7 03/10] regulator: Split up _regulator_get() Chen-Yu Tsai
@ 2024-09-13 10:27   ` Andy Shevchenko
  0 siblings, 0 replies; 37+ messages in thread
From: Andy Shevchenko @ 2024-09-13 10:27 UTC (permalink / raw)
  To: Chen-Yu Tsai
  Cc: Rob Herring, Saravana Kannan, Matthias Brugger,
	AngeloGioacchino Del Regno, Wolfram Sang, Benson Leung,
	Tzung-Bi Shih, Mark Brown, Liam Girdwood, chrome-platform,
	devicetree, linux-arm-kernel, linux-mediatek, linux-kernel,
	Douglas Anderson, Johan Hovold, Jiri Kosina, linux-i2c

On Wed, Sep 11, 2024 at 03:27:41PM +0800, Chen-Yu Tsai wrote:
> _regulator_get() contains a lot of common code doing checks prior to the
> regulator lookup and housekeeping work after the lookup. Almost all the
> code could be shared with a OF-specific variant of _regulator_get().
> 
> Split out the common parts so that they can be reused. The OF-specific
> version of _regulator_get() will be added in a subsequent patch.
> No functional changes were made.

I think this patch makes sense on its own, but it of course up to Mark.
FWIW,
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>

-- 
With Best Regards,
Andy Shevchenko




^ permalink raw reply	[flat|nested] 37+ messages in thread

* Re: [PATCH v7 07/10] i2c: of-prober: Add simple helpers for regulator support
  2024-09-11  7:27 ` [PATCH v7 07/10] i2c: of-prober: Add simple helpers for regulator support Chen-Yu Tsai
@ 2024-09-13 10:46   ` Andy Shevchenko
  2024-09-13 23:43   ` Doug Anderson
  1 sibling, 0 replies; 37+ messages in thread
From: Andy Shevchenko @ 2024-09-13 10:46 UTC (permalink / raw)
  To: Chen-Yu Tsai
  Cc: Rob Herring, Saravana Kannan, Matthias Brugger,
	AngeloGioacchino Del Regno, Wolfram Sang, Benson Leung,
	Tzung-Bi Shih, Mark Brown, Liam Girdwood, chrome-platform,
	devicetree, linux-arm-kernel, linux-mediatek, linux-kernel,
	Douglas Anderson, Johan Hovold, Jiri Kosina, linux-i2c

On Wed, Sep 11, 2024 at 03:27:45PM +0800, Chen-Yu Tsai wrote:
> Add helpers to do regulator management for 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.
> GPIOs will be handled in the next patch.
> 
> The assumption is that the same class of components to be probed are
> always connected in the same fashion with the same regulator supply
> and GPIO. The names may vary due to binding differences, but the
> physical layout does not change.
> 
> This set of helpers supports at most one regulator supply. The user
> must specify the node from which the supply is retrieved. The supply
> name and the amount of time to wait after the supply is enabled are
> also given by the user.

...

> +static int i2c_of_probe_simple_get_supply(struct device *dev, struct device_node *node,
> +					  struct i2c_of_probe_simple_ctx *ctx)
> +{
> +	const char *supply_name;
> +	struct regulator *supply;
> +
> +	/*
> +	 * It's entirely possible for the component's device node to not have regulator
> +	 * supplies. While it does not make sense from a hardware perspective, the
> +	 * supplies could be always on or otherwise not modeled in the device tree, but
> +	 * the device would still work.
> +	 */

I would reformat as

	/*
	 * It's entirely possible for the component's device node to not have the
	 * regulator supplies. While it does not make sense from a hardware perspective,
	 * the supplies could be always on or otherwise not modeled in the device tree,
	 * but the device would still work.
	 */

> +	supply_name = ctx->opts->supply_name;
> +	if (!supply_name)
> +		return 0;
> +
> +	supply = of_regulator_get_optional(dev, node, supply_name);
> +	if (IS_ERR(supply)) {
> +		return dev_err_probe(dev, PTR_ERR(supply),
> +				     "Failed to get regulator supply \"%s\" from %pOF\n",
> +				     supply_name, node);
> +	}
> +
> +	ctx->supply = supply;
> +
> +	return 0;
> +}

...

> +int i2c_of_probe_simple_get_res(struct device *dev, struct device_node *bus_node, void *data)
> +{
> +	struct i2c_of_probe_simple_ctx *ctx = data;
> +	struct device_node *node;
> +	const char *compat;
> +	int ret;
> +
> +	dev_dbg(dev, "Requesting resources for components under I2C bus %pOF\n", bus_node);
> +
> +	if (!ctx || !ctx->opts)
> +		return -EINVAL;
> +
> +	compat = ctx->opts->res_node_compatible;
> +	if (!compat)
> +		return -EINVAL;

> +	node = of_get_compatible_child(bus_node, compat);

	__free(of_node_put) ?

> +	if (!node)
> +		return dev_err_probe(dev, -ENODEV, "No device compatible with \"%s\" found\n",
> +				     compat);
> +
> +	ret = i2c_of_probe_simple_get_supply(dev, node, ctx);
> +	if (ret)
> +		goto out_put_node;
> +
> +	return 0;
> +
> +out_put_node:
> +	of_node_put(node);
> +	return ret;
> +}

...

> + * @post_power_on_delay_ms: Delay in ms after regulators are powered on. Passed to msleep().

No need to duplicate the units as it's obvious from the variable name and msleep().

 * @post_power_on_delay_ms: Delay after regulators are powered on. Passed to msleep().

-- 
With Best Regards,
Andy Shevchenko




^ permalink raw reply	[flat|nested] 37+ messages in thread

* Re: [PATCH v7 08/10] i2c: of-prober: Add GPIO support to simple helpers
  2024-09-11  7:27 ` [PATCH v7 08/10] i2c: of-prober: Add GPIO support to simple helpers Chen-Yu Tsai
@ 2024-09-13 10:52   ` Andy Shevchenko
  2024-09-13 23:43   ` Doug Anderson
  2024-09-15  9:46   ` Andrey Skvortsov
  2 siblings, 0 replies; 37+ messages in thread
From: Andy Shevchenko @ 2024-09-13 10:52 UTC (permalink / raw)
  To: Chen-Yu Tsai
  Cc: Rob Herring, Saravana Kannan, Matthias Brugger,
	AngeloGioacchino Del Regno, Wolfram Sang, Benson Leung,
	Tzung-Bi Shih, Mark Brown, Liam Girdwood, chrome-platform,
	devicetree, linux-arm-kernel, linux-mediatek, linux-kernel,
	Douglas Anderson, Johan Hovold, Jiri Kosina, linux-i2c

On Wed, Sep 11, 2024 at 03:27:46PM +0800, Chen-Yu Tsai wrote:
> Add GPIO support to the simple helpers for 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.
> Regulator supplies were handled in the previous patch.
> 
> The assumption is that the same class of components to be probed are
> always connected in the same fashion with the same regulator supply
> and GPIO. The names may vary due to binding differences, but the
> physical layout does not change.
> 
> This supports at most one GPIO pin. The user must specify the GPIO name,
> the polarity, and the amount of time to wait after the GPIO is toggled.
> Devices with more than one GPIO pin likely require specific power
> sequencing beyond what generic code can easily support.

...

> +static int i2c_of_probe_simple_get_gpiod(struct device *dev, struct device_node *node,
> +					 struct i2c_of_probe_simple_ctx *ctx)
> +{
> +	struct fwnode_handle *fwnode = of_fwnode_handle(node);
> +	struct gpio_desc *gpiod;
> +	const char *con_id = NULL;
> +
> +	/* NULL signals no GPIO needed */
> +	if (!ctx->opts->gpio_name)
> +		return 0;
> +
> +	/* An empty string signals an unnamed GPIO */
> +	if (strlen(ctx->opts->gpio_name))

You run for entire string in order to check the first byte only?

	if (ctx->opts->gpio_name[0] == '\0')
		con_id = NULL;
	else

> +		con_id = ctx->opts->gpio_name;

Also note, that comment is given in inverted condition to what you actually do
in the code. With my suggestion it looks better.

> +	gpiod = fwnode_gpiod_get_index(fwnode, con_id, 0, GPIOD_ASIS, "i2c-of-prober");
> +	if (IS_ERR(gpiod))
> +		return PTR_ERR(gpiod);
> +
> +	ctx->gpiod = gpiod;
> +
> +	return 0;
> +}

...

> +static int i2c_of_probe_simple_set_gpio(struct device *dev, struct i2c_of_probe_simple_ctx *ctx)
> +{
> +	int ret;
> +
> +	if (!ctx->gpiod)
> +		return 0;

> +	dev_dbg(dev, "Setting GPIO\n");

> +	ret = gpiod_direction_output_raw(ctx->gpiod, ctx->opts->gpio_high_to_enable ? 1 : 0);

Hmm... _raw() in use... Perhaps it's on a territory of Bart and Linus to review
and comment on this.

> +	if (ret)
> +		return ret;
> +
> +	msleep(ctx->opts->post_reset_deassert_delay_ms);
> +
> +	return 0;
> +}

-- 
With Best Regards,
Andy Shevchenko




^ permalink raw reply	[flat|nested] 37+ messages in thread

* Re: [PATCH v7 05/10] i2c: core: Remove extra space in Makefile
  2024-09-11  7:27 ` [PATCH v7 05/10] i2c: core: Remove extra space in Makefile Chen-Yu Tsai
@ 2024-09-13 14:59   ` Andi Shyti
  0 siblings, 0 replies; 37+ messages in thread
From: Andi Shyti @ 2024-09-13 14:59 UTC (permalink / raw)
  To: Chen-Yu Tsai
  Cc: Rob Herring, Saravana Kannan, Matthias Brugger,
	AngeloGioacchino Del Regno, Wolfram Sang, Benson Leung,
	Tzung-Bi Shih, Mark Brown, Liam Girdwood, chrome-platform,
	devicetree, linux-arm-kernel, linux-mediatek, linux-kernel,
	Douglas Anderson, Johan Hovold, Jiri Kosina, Andy Shevchenko,
	linux-i2c

Hi Chen-Yu,

On Wed, Sep 11, 2024 at 03:27:43PM GMT, Chen-Yu Tsai wrote:
> Some lines in the Makefile have a space before tabs. Remove those.
> 
> Reported-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
> Closes: https://lore.kernel.org/all/ZsdE0PxKnGRjzChl@smile.fi.intel.com/
> Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>

Reviewed-by: Andi Shyti <andi.shyti@kernel.org>

Thanks,
Andi


^ permalink raw reply	[flat|nested] 37+ messages in thread

* Re: (subset) [PATCH v7 00/10] platform/chrome: Introduce DT hardware prober
  2024-09-11  7:27 [PATCH v7 00/10] platform/chrome: Introduce DT hardware prober Chen-Yu Tsai
                   ` (9 preceding siblings ...)
  2024-09-11  7:27 ` [PATCH v7 10/10] arm64: dts: mediatek: mt8173-elm-hana: Mark touchscreens and trackpads as fail Chen-Yu Tsai
@ 2024-09-13 18:08 ` Mark Brown
  10 siblings, 0 replies; 37+ messages in thread
From: Mark Brown @ 2024-09-13 18:08 UTC (permalink / raw)
  To: Rob Herring, Saravana Kannan, Matthias Brugger,
	AngeloGioacchino Del Regno, Wolfram Sang, Benson Leung,
	Tzung-Bi Shih, Liam Girdwood, Chen-Yu Tsai
  Cc: chrome-platform, devicetree, linux-arm-kernel, linux-mediatek,
	linux-kernel, Douglas Anderson, Johan Hovold, Jiri Kosina,
	Andy Shevchenko, linux-i2c

On Wed, 11 Sep 2024 15:27:38 +0800, Chen-Yu Tsai wrote:
> This is v7 of my "of: Introduce hardware prober driver" [1] series.
> v7 mainly refactors the code into a series of helpers. The scope of
> supported components is also reduced to those with at most one regulator
> supply and one GPIO pin. Also the helpers expect these to be named and
> so the "bulk get" API changes have been dropped.
> 
> Also, a pull request to document the "fail-needs-probe" status has been
> sent: https://github.com/devicetree-org/dt-schema/pull/141
> 
> [...]

Applied to

   https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git for-next

Thanks!

[03/10] regulator: Split up _regulator_get()
        commit: 2a1de5678944147c2a41b6006127d2d0b618e83b

All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.

You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.

If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.

Please add any relevant lists and maintainers to the CCs when replying
to this mail.

Thanks,
Mark



^ permalink raw reply	[flat|nested] 37+ messages in thread

* Re: [PATCH v7 06/10] i2c: Introduce OF component probe function
  2024-09-11  7:27 ` [PATCH v7 06/10] i2c: Introduce OF component probe function Chen-Yu Tsai
  2024-09-13 10:25   ` Andy Shevchenko
@ 2024-09-13 23:43   ` Doug Anderson
  2024-09-15 11:32     ` Chen-Yu Tsai
  2024-09-16 10:13     ` Andy Shevchenko
  2024-09-15 10:09   ` Andrey Skvortsov
  2 siblings, 2 replies; 37+ messages in thread
From: Doug Anderson @ 2024-09-13 23:43 UTC (permalink / raw)
  To: Chen-Yu Tsai
  Cc: Rob Herring, Saravana Kannan, Matthias Brugger,
	AngeloGioacchino Del Regno, Wolfram Sang, Benson Leung,
	Tzung-Bi Shih, Mark Brown, Liam Girdwood, chrome-platform,
	devicetree, linux-arm-kernel, linux-mediatek, linux-kernel,
	Johan Hovold, Jiri Kosina, Andy Shevchenko, linux-i2c

Hi,

On Wed, Sep 11, 2024 at 12:28 AM Chen-Yu Tsai <wenst@chromium.org> wrote:
>
> Some devices are designed and manufactured with some components having
> multiple drop-in replacement options. These components are often
> connected to the mainboard via ribbon cables, having the same signals
> and pin assignments across all options. These may include the display
> panel and touchscreen on laptops and tablets, and the trackpad on
> laptops. Sometimes which component option is used in a particular device
> can be detected by some firmware provided identifier, other times that
> information is not available, and the kernel has to try to probe each
> device.
>
> This change attempts to make the "probe each device" case cleaner. The
> current approach is to have all options added and enabled in the device
> tree. The kernel would then bind each device and run each driver's probe
> function. This works, but has been broken before due to the introduction
> of asynchronous probing, causing multiple instances requesting "shared"
> resources, such as pinmuxes, GPIO pins, interrupt lines, at the same
> time, with only one instance succeeding. Work arounds for these include
> moving the pinmux to the parent I2C controller, using GPIO hogs or
> pinmux settings to keep the GPIO pins in some fixed configuration, and
> requesting the interrupt line very late. Such configurations can be seen
> on the MT8183 Krane Chromebook tablets, and the Qualcomm sc8280xp-based
> Lenovo Thinkpad 13S.
>
> Instead of this delicate dance between drivers and device tree quirks,
> this change introduces a simple I2C component probe. function For a

s/probe. function/probe function./


> +static int i2c_of_probe_enable_node(struct device *dev, struct device_node *node)
> +{
> +       int ret;
> +
> +       dev_info(dev, "Enabling %pOF\n", node);
> +
> +       struct of_changeset *ocs __free(kfree) = kzalloc(sizeof(*ocs), GFP_KERNEL);
> +       if (!ocs)
> +               return -ENOMEM;

I guess the kernel lets you mix code and declarations now? I'm still
used to all declarations being together but maybe I'm old school... I
would have put the "dev_info" below the allocation...


> +/**
> + * i2c_of_probe_component() - probe for devices of "type" on the same i2c bus
> + * @dev: Pointer to the &struct device of the caller, only used for dev_printk() messages.
> + * @cfg: Pointer to the &struct i2c_of_probe_cfg containing callbacks and other options
> + *       for the prober.
> + * @ctx: Context data for callbacks.
> + *
> + * Probe for possible I2C components of the same "type" (&i2c_of_probe_cfg->type)
> + * on the same I2C bus that have their status marked as "fail".

I may have missed it, but originally this was ones marked
"fail-needs-probe", right? Now it tries all types of fail?


> + * Assumes that across the entire device tree the only instances of nodes
> + * prefixed with "type" are the ones that need handling for second source
> + * components. In other words, if "type" is "touchscreen", then all device
> + * nodes named "touchscreen*" are the ones that need probing. There cannot

"touchscreen*" implies that it can have an arbitrary suffix. Can it?
...or can it just have a unit address?


> + * be another "touchscreen" node that is already enabled.
> + *
> + * Assumes that for each "type" of component, only one actually exists. In
> + * other words, only one matching and existing device will be enabled.
> + *
> + * Context: Process context only. Does non-atomic I2C transfers.
> + *          Should only be used from a driver probe function, as the function
> + *          can return -EPROBE_DEFER if the I2C adapter or other resources
> + *          are unavailable.
> + * Return: 0 on success or no-op, error code otherwise.
> + *         A no-op can happen when it seems like the device tree already
> + *         has components of the type to be probed already enabled. This
> + *         can happen when the device tree had not been updated to mark
> + *         the status of the to-be-probed components as "fail". Or this
> + *         function was already run with the same parameters and succeeded
> + *         in enabling a component. The latter could happen if the user

s/latter/later

> + *         had multiple types of components to probe, and one of them down
> + *         the list caused a deferred probe. This is expected behavior.
> + */
> +int i2c_of_probe_component(struct device *dev, const struct i2c_of_probe_cfg *cfg, void *ctx)
> +{
> +       const struct i2c_of_probe_ops *ops;
> +       const char *type;
> +       struct device_node *i2c_node;
> +       struct i2c_adapter *i2c;
> +       int ret;
> +
> +       if (!cfg)
> +               return -EINVAL;

Drop extra check of "!cfg". In general kernel conventions don't check
for NULL pointers passed by caller unless it's an expected case. You
don't check for a NULL "dev" and you shouldn't need to check for a
NULL "cfg". They are both simply required parameters.

There are a few other places in the patch series where it feels like
there are extra arg checks that aren't really needed...


> +       ops = cfg->ops ?: &i2c_of_probe_dummy_ops;
> +       type = cfg->type;
> +
> +       i2c_node = i2c_of_probe_get_i2c_node(dev, type);
> +       if (IS_ERR(i2c_node))
> +               return PTR_ERR(i2c_node);
> +
> +       for_each_child_of_node_with_prefix(i2c_node, node, type) {

I wouldn't object to a comment before this for loop:

/* If any devices of this type are already enabled then the function
is a noop */

...or it could be a helper function.


> +               if (!of_device_is_available(node))
> +                       continue;
> +
> +               /*
> +                * Device tree has component already enabled. Either the
> +                * device tree isn't supported or we already probed once.
> +                */
> +               ret = 0;
> +               goto out_put_i2c_node;
> +       }
> +
> +       i2c = of_get_i2c_adapter_by_node(i2c_node);
> +       if (!i2c) {
> +               ret = dev_err_probe(dev, -EPROBE_DEFER, "Couldn't get I2C adapter\n");
> +               goto out_put_i2c_node;
> +       }
> +
> +       /* Grab resources */
> +       ret = 0;
> +       if (ops->get_resources)
> +               ret = ops->get_resources(dev, i2c_node, ctx);
> +       if (ret)
> +               goto out_put_i2c_adapter;
> +
> +       /* Enable resources */
> +       if (ops->enable)
> +               ret = ops->enable(dev, ctx);
> +       if (ret)
> +               goto out_release_resources;

I won't insist, but a part of me wonders whether we should just
combine "get_resources" and "enable" and then combine "cleanup" and
"free_resources_late". They are always paired one after another and
I'm having a hard time seeing why they need to be separate. It's not
like you'll ever get the resources and then enable/disable multiple
times.


> +/**
> + * struct i2c_of_probe_ops - I2C OF component prober callbacks
> + *
> + * A set of callbacks to be used by i2c_of_probe_component().
> + *
> + * All callbacks are optional. Callbacks are called only once per run, and are
> + * used in the order they are defined in this structure.
> + *
> + * All callbacks that have return values shall return %0 on success,
> + * or a negative error number on failure.
> + *
> + * The @dev parameter passed to the callbacks is the same as @dev passed to
> + * i2c_of_probe_component(). It should only be used for dev_printk() calls
> + * and nothing else, especially not managed device resource (devres) APIs.
> + */
> +struct i2c_of_probe_ops {
> +       /** @get_resources: Retrieve resources for components. */
> +       int (*get_resources)(struct device *dev, struct device_node *bus_node, void *data);
> +
> +       /** @free_resources_early: Release exclusive resources prior to enabling component. */
> +       void (*free_resources_early)(void *data);

It would be good if the doc here mentioned what happened if no
components were found and thus nothing was enabled. Is the function
still called? It looks like "no" and "cleanup" is in charge of
cleaning in this case. Feels like the docs need to be more explicit.


^ permalink raw reply	[flat|nested] 37+ messages in thread

* Re: [PATCH v7 07/10] i2c: of-prober: Add simple helpers for regulator support
  2024-09-11  7:27 ` [PATCH v7 07/10] i2c: of-prober: Add simple helpers for regulator support Chen-Yu Tsai
  2024-09-13 10:46   ` Andy Shevchenko
@ 2024-09-13 23:43   ` Doug Anderson
  1 sibling, 0 replies; 37+ messages in thread
From: Doug Anderson @ 2024-09-13 23:43 UTC (permalink / raw)
  To: Chen-Yu Tsai
  Cc: Rob Herring, Saravana Kannan, Matthias Brugger,
	AngeloGioacchino Del Regno, Wolfram Sang, Benson Leung,
	Tzung-Bi Shih, Mark Brown, Liam Girdwood, chrome-platform,
	devicetree, linux-arm-kernel, linux-mediatek, linux-kernel,
	Johan Hovold, Jiri Kosina, Andy Shevchenko, linux-i2c

Hi,

On Wed, Sep 11, 2024 at 12:28 AM Chen-Yu Tsai <wenst@chromium.org> wrote:
>
> +static int i2c_of_probe_simple_enable_regulator(struct device *dev, struct i2c_of_probe_simple_ctx *ctx)
> +{
> +       int ret;
> +
> +       if (!ctx->supply)
> +               return 0;
> +
> +       dev_dbg(dev, "Enabling regulator supply \"%s\"\n", ctx->opts->supply_name);
> +
> +       ret = regulator_enable(ctx->supply);
> +       if (ret)
> +               return ret;
> +
> +       msleep(ctx->opts->post_power_on_delay_ms);

Presumably you want an "if (ctx->opts->post_power_on_delay_ms)" before
the call to msleep() since it doesn't check that for you.


> +/**
> + * i2c_of_probe_simple_enable - Enable resources for I2C OF prober simple helpers
> + * @dev: Pointer to the &struct device of the caller, only used for dev_printk() messages
> + * @data: Pointer to &struct i2c_of_probe_simple_ctx helper context.
> + *
> + * If a regulator supply was found, enable that regulator.
> + *
> + * Return: %0 on success or no-op, or a negative error number on failure.
> + */
> +int i2c_of_probe_simple_enable(struct device *dev, void *data)
> +{
> +       struct i2c_of_probe_simple_ctx *ctx = data;
> +       int ret;
> +
> +       ret = i2c_of_probe_simple_enable_regulator(dev, ctx);
> +       if (ret)
> +               return ret;
> +
> +       return 0;

Instead of the above, just:

return i2c_of_probe_simple_enable_regulator(dev, ctx);

I guess maybe you'd have to undo it in the next patch, but it does
make this patch stand by itself better..

Although I'd also say that if it were me I might just get rid of the
helpers and inline the stuff. The helpers don't _really_ add too much.
3 of the 4 callers are just simple wrappers of the helper and I don't
think it would be terrible to inline the last one. I guess with the
next patch when you add GPIOs it maybe makes more sense, but even then
it feels like a stretch to me. Anyway, feel free to ignore if you
want.

> +/**
> + * DOC: I2C OF component prober simple helpers
> + *
> + * Components such as trackpads are commonly connected to a devices baseboard
> + * with a 6-pin ribbon cable. That gives at most one voltage supply and one
> + * GPIO besides the I2C bus, interrupt pin, and common ground. Touchscreens,

Maybe speculate here that the GPIO is often an enable or reset line?
Otherwise you leave the reader wondering what this mysterious GPIO is
for.


^ permalink raw reply	[flat|nested] 37+ messages in thread

* Re: [PATCH v7 08/10] i2c: of-prober: Add GPIO support to simple helpers
  2024-09-11  7:27 ` [PATCH v7 08/10] i2c: of-prober: Add GPIO support to simple helpers Chen-Yu Tsai
  2024-09-13 10:52   ` Andy Shevchenko
@ 2024-09-13 23:43   ` Doug Anderson
  2024-09-17 12:41     ` Chen-Yu Tsai
  2024-09-15  9:46   ` Andrey Skvortsov
  2 siblings, 1 reply; 37+ messages in thread
From: Doug Anderson @ 2024-09-13 23:43 UTC (permalink / raw)
  To: Chen-Yu Tsai
  Cc: Rob Herring, Saravana Kannan, Matthias Brugger,
	AngeloGioacchino Del Regno, Wolfram Sang, Benson Leung,
	Tzung-Bi Shih, Mark Brown, Liam Girdwood, chrome-platform,
	devicetree, linux-arm-kernel, linux-mediatek, linux-kernel,
	Johan Hovold, Jiri Kosina, Andy Shevchenko, linux-i2c

Hi,

On Wed, Sep 11, 2024 at 12:29 AM Chen-Yu Tsai <wenst@chromium.org> wrote:
>
> +static int i2c_of_probe_simple_set_gpio(struct device *dev, struct i2c_of_probe_simple_ctx *ctx)
> +{
> +       int ret;
> +
> +       if (!ctx->gpiod)
> +               return 0;
> +
> +       dev_dbg(dev, "Setting GPIO\n");
> +
> +       ret = gpiod_direction_output_raw(ctx->gpiod, ctx->opts->gpio_high_to_enable ? 1 : 0);
> +       if (ret)
> +               return ret;
> +
> +       msleep(ctx->opts->post_reset_deassert_delay_ms);

Like in the previous patch, you need an "if
(ctx->opts->post_reset_deassert_delay_ms)" before the msleep().


> +static void i2c_of_probe_simple_disable_gpio(struct device *dev, struct i2c_of_probe_simple_ctx *ctx)
> +{
> +       if (!ctx->gpiod)
> +               return;
> +
> +       dev_dbg(dev, "Setting GPIO to input\n");
> +
> +       gpiod_direction_input(ctx->gpiod);

This is weird. Why set it to input?


> @@ -347,6 +438,7 @@ int i2c_of_probe_simple_cleanup(struct device *dev, void *data)
>  {
>         struct i2c_of_probe_simple_ctx *ctx = data;
>
> +       i2c_of_probe_simple_disable_gpio(dev, ctx);

Maybe add a comment before the GPIO call that it's a noop if we found
something and i2c_of_probe_simple_free_res_early() was already called?
Otherwise you need to read into the function to understand why this
doesn't crash if the early call was made. To me, that makes the
abstraction add confusion instead of simplifying things.


> @@ -92,24 +93,33 @@ int i2c_of_probe_component(struct device *dev, const struct i2c_of_probe_cfg *cf
>   * struct i2c_of_probe_simple_opts - Options for simple I2C component prober callbacks
>   * @res_node_compatible: Compatible string of device node to retrieve resources from.
>   * @supply_name: Name of regulator supply.
> + * @gpio_name: Name of GPIO.

Talk about the fact that gpio_name can be NULL or an empty string and
that they mean different things.


>   * @post_power_on_delay_ms: Delay in ms after regulators are powered on. Passed to msleep().
> + * @post_reset_deassert_delay_ms: Delay in ms after GPIOs are set. Passed to msleep().
> + * @gpio_high_to_enable: %true if GPIO should be set to electrical high to enable component.

Now that you've added the GPIOs and more delays, the description of
this structure needs to list exactly what the power sequence your
simple functions assume.

I would also say: given that you're providing a parameter anyway and
you're giving the GPIO name, can you please move away from the "raw"
values and move to "logical" values?


^ permalink raw reply	[flat|nested] 37+ messages in thread

* Re: [PATCH v7 09/10] platform/chrome: Introduce device tree hardware prober
  2024-09-11  7:27 ` [PATCH v7 09/10] platform/chrome: Introduce device tree hardware prober Chen-Yu Tsai
@ 2024-09-13 23:43   ` Doug Anderson
  2024-09-16 14:58     ` Chen-Yu Tsai
  0 siblings, 1 reply; 37+ messages in thread
From: Doug Anderson @ 2024-09-13 23:43 UTC (permalink / raw)
  To: Chen-Yu Tsai
  Cc: Rob Herring, Saravana Kannan, Matthias Brugger,
	AngeloGioacchino Del Regno, Wolfram Sang, Benson Leung,
	Tzung-Bi Shih, Mark Brown, Liam Girdwood, chrome-platform,
	devicetree, linux-arm-kernel, linux-mediatek, linux-kernel,
	Johan Hovold, Jiri Kosina, Andy Shevchenko, linux-i2c

Hi,

On Wed, Sep 11, 2024 at 12:29 AM Chen-Yu Tsai <wenst@chromium.org> wrote:
>
> @@ -8,6 +8,7 @@ obj-$(CONFIG_CHROMEOS_ACPI)             += chromeos_acpi.o
>  obj-$(CONFIG_CHROMEOS_LAPTOP)          += chromeos_laptop.o
>  obj-$(CONFIG_CHROMEOS_PRIVACY_SCREEN)  += chromeos_privacy_screen.o
>  obj-$(CONFIG_CHROMEOS_PSTORE)          += chromeos_pstore.o
> +obj-$(CONFIG_CHROMEOS_OF_HW_PROBER)    += chromeos_of_hw_prober.o

"o" sorts before "p" so "of" should sort before "privacy"?

I guess it's not exactly all sorted, but this small section is. Since
it's arbitrary you could preserve the existing sorting. :-P


> +static const struct hw_prober_entry hw_prober_platforms[] = {
> +       { .compatible = "google,hana", .prober = chromeos_i2c_component_prober, .data = &chromeos_i2c_probe_dumb_touchscreen },
> +       { .compatible = "google,hana", .prober = chromeos_i2c_component_prober, .data = &chromeos_i2c_probe_dumb_trackpad },

The fact that the example is only using "dumb" probers doesn't make it
quite as a compelling proof that the code will scale up. Any chance
you could add something that requires a bit more oomph? ;-)


> +static int chromeos_of_hw_prober_driver_init(void)
> +{
> +       size_t i;
> +       int ret;
> +
> +       for (i = 0; i < ARRAY_SIZE(hw_prober_platforms); i++)
> +               if (of_machine_is_compatible(hw_prober_platforms[i].compatible))
> +                       break;
> +       if (i == ARRAY_SIZE(hw_prober_platforms))
> +               return -ENODEV;
> +
> +       ret = platform_driver_register(&chromeos_of_hw_prober_driver);
> +       if (ret)
> +               return ret;
> +
> +       chromeos_of_hw_prober_pdev =
> +                       platform_device_register_simple(DRV_NAME, PLATFORM_DEVID_NONE, NULL, 0);
> +       if (IS_ERR(chromeos_of_hw_prober_pdev))
> +               goto err;

FWIW if you didn't want to see your prober called over and over again
if one of the devices deferred you could just register one device per
type, right? Then each device would be able to defer separately. Dunno
if it's worth it but figured I'd mention it...


Also: as a high level comment, this all looks much nicer to me now
that it's parameterized. :-)


^ permalink raw reply	[flat|nested] 37+ messages in thread

* Re: [PATCH v7 08/10] i2c: of-prober: Add GPIO support to simple helpers
  2024-09-11  7:27 ` [PATCH v7 08/10] i2c: of-prober: Add GPIO support to simple helpers Chen-Yu Tsai
  2024-09-13 10:52   ` Andy Shevchenko
  2024-09-13 23:43   ` Doug Anderson
@ 2024-09-15  9:46   ` Andrey Skvortsov
  2 siblings, 0 replies; 37+ messages in thread
From: Andrey Skvortsov @ 2024-09-15  9:46 UTC (permalink / raw)
  To: Chen-Yu Tsai
  Cc: Rob Herring, Saravana Kannan, Matthias Brugger,
	AngeloGioacchino Del Regno, Wolfram Sang, Benson Leung,
	Tzung-Bi Shih, Mark Brown, Liam Girdwood, chrome-platform,
	devicetree, linux-arm-kernel, linux-mediatek, linux-kernel,
	Douglas Anderson, Johan Hovold, Jiri Kosina, Andy Shevchenko,
	linux-i2c

Hi,

On 24-09-11 15:27, Chen-Yu Tsai wrote:
> Add GPIO support to the simple helpers for 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.
> Regulator supplies were handled in the previous patch.
> 
> The assumption is that the same class of components to be probed are
> always connected in the same fashion with the same regulator supply
> and GPIO. The names may vary due to binding differences, but the
> physical layout does not change.
> 
> This supports at most one GPIO pin. The user must specify the GPIO name,
> the polarity, and the amount of time to wait after the GPIO is toggled.
> Devices with more than one GPIO pin likely require specific power
> sequencing beyond what generic code can easily support.
> 
> Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>

> diff --git a/include/linux/i2c-of-prober.h b/include/linux/i2c-of-prober.h
> index 541451fbf58d..c5e241163c94 100644
> --- a/include/linux/i2c-of-prober.h
> +++ b/include/linux/i2c-of-prober.h
> @@ -83,6 +83,7 @@ int i2c_of_probe_component(struct device *dev, const struct i2c_of_probe_cfg *cf
>   *
>   * The following helpers are provided:
>   * * i2c_of_probe_simple_get_res()
> + * * i2c_of_probe_simple_free_res_early()
>   * * i2c_of_probe_simple_free_res_late()
>   * * i2c_of_probe_simple_enable()
>   * * i2c_of_probe_simple_cleanup()
> @@ -92,24 +93,33 @@ int i2c_of_probe_component(struct device *dev, const struct i2c_of_probe_cfg *cf
>   * struct i2c_of_probe_simple_opts - Options for simple I2C component prober callbacks
>   * @res_node_compatible: Compatible string of device node to retrieve resources from.
>   * @supply_name: Name of regulator supply.
> + * @gpio_name: Name of GPIO.
>   * @post_power_on_delay_ms: Delay in ms after regulators are powered on. Passed to msleep().
> + * @post_reset_deassert_delay_ms: Delay in ms after GPIOs are set. Passed to msleep().
> + * @gpio_high_to_enable: %true if GPIO should be set to electrical high to enable component.
>   */
>  struct i2c_of_probe_simple_opts {
>  	const char *res_node_compatible;
>  	const char *supply_name;
> +	const char *gpio_name;
>  	unsigned int post_power_on_delay_ms;
> +	unsigned int post_reset_deassert_delay_ms;
> +	bool gpio_high_to_enable;

Missing '#include <linux/types.h>', otherwise compiler complains
about unknown bool type, when 'i2c-of-prober.h' included without any
previous includes.

-- 
Best regards,
Andrey Skvortsov


^ permalink raw reply	[flat|nested] 37+ messages in thread

* Re: [PATCH v7 06/10] i2c: Introduce OF component probe function
  2024-09-11  7:27 ` [PATCH v7 06/10] i2c: Introduce OF component probe function Chen-Yu Tsai
  2024-09-13 10:25   ` Andy Shevchenko
  2024-09-13 23:43   ` Doug Anderson
@ 2024-09-15 10:09   ` Andrey Skvortsov
  2 siblings, 0 replies; 37+ messages in thread
From: Andrey Skvortsov @ 2024-09-15 10:09 UTC (permalink / raw)
  To: Chen-Yu Tsai
  Cc: Rob Herring, Saravana Kannan, Matthias Brugger,
	AngeloGioacchino Del Regno, Wolfram Sang, Benson Leung,
	Tzung-Bi Shih, Mark Brown, Liam Girdwood, chrome-platform,
	devicetree, linux-arm-kernel, linux-mediatek, linux-kernel,
	Douglas Anderson, Johan Hovold, Jiri Kosina, Andy Shevchenko,
	linux-i2c

On 24-09-11 15:27, Chen-Yu Tsai wrote:
> Some devices are designed and manufactured with some components having
> multiple drop-in replacement options. These components are often
> connected to the mainboard via ribbon cables, having the same signals
> and pin assignments across all options. These may include the display
> panel and touchscreen on laptops and tablets, and the trackpad on
> laptops. Sometimes which component option is used in a particular device
> can be detected by some firmware provided identifier, other times that
> information is not available, and the kernel has to try to probe each
> device.
> 
> This change attempts to make the "probe each device" case cleaner. The
> current approach is to have all options added and enabled in the device
> tree. The kernel would then bind each device and run each driver's probe
> function. This works, but has been broken before due to the introduction
> of asynchronous probing, causing multiple instances requesting "shared"
> resources, such as pinmuxes, GPIO pins, interrupt lines, at the same
> time, with only one instance succeeding. Work arounds for these include
> moving the pinmux to the parent I2C controller, using GPIO hogs or
> pinmux settings to keep the GPIO pins in some fixed configuration, and
> requesting the interrupt line very late. Such configurations can be seen
> on the MT8183 Krane Chromebook tablets, and the Qualcomm sc8280xp-based
> Lenovo Thinkpad 13S.
> 
> Instead of this delicate dance between drivers and device tree quirks,
> this change introduces a simple I2C component probe. function For a
> given class of devices on the same I2C bus, it will go through all of
> them, doing a simple I2C read transfer and see which one of them responds.
> It will then enable the device that responds.
> 
> This requires some minor modifications in the existing device tree. The
> status for all the device nodes for the component options must be set
> to "failed-needs-probe". This makes it clear that some mechanism is

Wrong status name ("failed-needs-probe"), "fail-needs-probe". This is
minor, but it confused me as I went through patchset first time, since
there are different name in different patches.

> needed to enable one of them, and also prevents the prober and device
> drivers running at the same time.
> 
> Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>

-- 
Best regards,
Andrey Skvortsov


^ permalink raw reply	[flat|nested] 37+ messages in thread

* Re: [PATCH v7 06/10] i2c: Introduce OF component probe function
  2024-09-13 10:25   ` Andy Shevchenko
@ 2024-09-15 10:44     ` Chen-Yu Tsai
  2024-09-16 10:36       ` Andy Shevchenko
  0 siblings, 1 reply; 37+ messages in thread
From: Chen-Yu Tsai @ 2024-09-15 10:44 UTC (permalink / raw)
  To: Andy Shevchenko
  Cc: Rob Herring, Saravana Kannan, Matthias Brugger,
	AngeloGioacchino Del Regno, Wolfram Sang, Benson Leung,
	Tzung-Bi Shih, Mark Brown, Liam Girdwood, chrome-platform,
	devicetree, linux-arm-kernel, linux-mediatek, linux-kernel,
	Douglas Anderson, Johan Hovold, Jiri Kosina, linux-i2c

On Fri, Sep 13, 2024 at 12:25 PM Andy Shevchenko
<andriy.shevchenko@linux.intel.com> wrote:
>
> On Wed, Sep 11, 2024 at 03:27:44PM +0800, Chen-Yu Tsai wrote:
> > Some devices are designed and manufactured with some components having
> > multiple drop-in replacement options. These components are often
> > connected to the mainboard via ribbon cables, having the same signals
> > and pin assignments across all options. These may include the display
> > panel and touchscreen on laptops and tablets, and the trackpad on
> > laptops. Sometimes which component option is used in a particular device
> > can be detected by some firmware provided identifier, other times that
> > information is not available, and the kernel has to try to probe each
> > device.
> >
> > This change attempts to make the "probe each device" case cleaner. The
> > current approach is to have all options added and enabled in the device
> > tree. The kernel would then bind each device and run each driver's probe
> > function. This works, but has been broken before due to the introduction
> > of asynchronous probing, causing multiple instances requesting "shared"
> > resources, such as pinmuxes, GPIO pins, interrupt lines, at the same
> > time, with only one instance succeeding. Work arounds for these include
> > moving the pinmux to the parent I2C controller, using GPIO hogs or
> > pinmux settings to keep the GPIO pins in some fixed configuration, and
> > requesting the interrupt line very late. Such configurations can be seen
> > on the MT8183 Krane Chromebook tablets, and the Qualcomm sc8280xp-based
> > Lenovo Thinkpad 13S.
> >
> > Instead of this delicate dance between drivers and device tree quirks,
> > this change introduces a simple I2C component probe. function For a
> > given class of devices on the same I2C bus, it will go through all of
> > them, doing a simple I2C read transfer and see which one of them responds.
> > It will then enable the device that responds.
> >
> > This requires some minor modifications in the existing device tree. The
> > status for all the device nodes for the component options must be set
> > to "failed-needs-probe". This makes it clear that some mechanism is
> > needed to enable one of them, and also prevents the prober and device
> > drivers running at the same time.
>
> ...
>
> > +static int i2c_of_probe_enable_node(struct device *dev, struct device_node *node)
> > +{
> > +     int ret;
>
> > +     dev_info(dev, "Enabling %pOF\n", node);
>
> Is it important to be on INFO level?

Not really.

> > +     struct of_changeset *ocs __free(kfree) = kzalloc(sizeof(*ocs), GFP_KERNEL);
> > +     if (!ocs)
> > +             return -ENOMEM;
> > +
> > +     of_changeset_init(ocs);
> > +     ret = of_changeset_update_prop_string(ocs, node, "status", "okay");
> > +     if (ret)
> > +             return ret;
> > +
> > +     ret = of_changeset_apply(ocs);
> > +     if (ret) {
> > +             /* ocs needs to be explicitly cleaned up before being freed. */
> > +             of_changeset_destroy(ocs);
> > +     } else {
> > +             /*
> > +              * ocs is intentionally kept around as it needs to
> > +              * exist as long as the change is applied.
> > +              */
> > +             void *ptr __always_unused = no_free_ptr(ocs);
> > +     }
> > +
> > +     return ret;
> > +}
>
> ...
>
> > +int i2c_of_probe_component(struct device *dev, const struct i2c_of_probe_cfg *cfg, void *ctx)
> > +{
> > +     const struct i2c_of_probe_ops *ops;
> > +     const char *type;
> > +     struct device_node *i2c_node;
> > +     struct i2c_adapter *i2c;
> > +     int ret;
> > +
> > +     if (!cfg)
> > +             return -EINVAL;
> > +
> > +     ops = cfg->ops ?: &i2c_of_probe_dummy_ops;
> > +     type = cfg->type;
> > +
> > +     i2c_node = i2c_of_probe_get_i2c_node(dev, type);
>
>
>         struct device_node *i2c_node __free(of_node_put) =
>                 i2c_...;

cleanup.h says to not mix the two styles (scoped vs goto). I was trying
to follow that, though I realize now that with the scoped loops it
probably doesn't help.

I'll revert back to having __free().

> > +     if (IS_ERR(i2c_node))
> > +             return PTR_ERR(i2c_node);
> > +
> > +     for_each_child_of_node_with_prefix(i2c_node, node, type) {
> > +             if (!of_device_is_available(node))
> > +                     continue;
> > +
> > +             /*
> > +              * Device tree has component already enabled. Either the
> > +              * device tree isn't supported or we already probed once.
> > +              */
> > +             ret = 0;
>
> Shouldn't you drop reference count for "node"? (See also below)

This for-each loop the "scoped". It just doesn't have the prefix anymore.
I believe you asked if the prefix could be dropped and then Rob agreed.

> > +             goto out_put_i2c_node;
> > +     }
> > +
> > +     i2c = of_get_i2c_adapter_by_node(i2c_node);
> > +     if (!i2c) {
> > +             ret = dev_err_probe(dev, -EPROBE_DEFER, "Couldn't get I2C adapter\n");
> > +             goto out_put_i2c_node;
> > +     }
> > +
> > +     /* Grab resources */
> > +     ret = 0;
> > +     if (ops->get_resources)
> > +             ret = ops->get_resources(dev, i2c_node, ctx);
> > +     if (ret)
> > +             goto out_put_i2c_adapter;
> > +
> > +     /* Enable resources */
> > +     if (ops->enable)
> > +             ret = ops->enable(dev, ctx);
> > +     if (ret)
> > +             goto out_release_resources;
> > +
> > +     ret = 0;
> > +     for_each_child_of_node_with_prefix(i2c_node, node, type) {
> > +             union i2c_smbus_data data;
> > +             u32 addr;
> > +
> > +             if (of_property_read_u32(node, "reg", &addr))
> > +                     continue;
> > +             if (i2c_smbus_xfer(i2c, addr, 0, I2C_SMBUS_READ, 0, I2C_SMBUS_BYTE, &data) < 0)
> > +                     continue;
> > +
> > +             /* Found a device that is responding */
> > +             if (ops->free_resources_early)
> > +                     ops->free_resources_early(ctx);
> > +             ret = i2c_of_probe_enable_node(dev, node);
>
> Hmm... Is "node" reference count left bumped up for a reason?

Same as above.

> > +             break;
> > +     }
> > +
> > +     if (ops->cleanup)
> > +             ops->cleanup(dev, ctx);
> > +out_release_resources:
> > +     if (ops->free_resources_late)
> > +             ops->free_resources_late(ctx);
> > +out_put_i2c_adapter:
> > +     i2c_put_adapter(i2c);
> > +out_put_i2c_node:
> > +     of_node_put(i2c_node);
> > +
> > +     return ret;
> > +}
>
> ...
>
> > +/*
> > + * i2c-of-prober.h - definitions for the Linux I2C OF component prober
>
> Please avoid putting filenames inside files. In the possible future event of
> file renaming this may become a burden and sometimes even forgotten.

Ack.

> > + * Copyright (C) 2024 Google LLC
> > + */
> > +
> > +#ifndef _LINUX_I2C_OF_PROBER_H
> > +#define _LINUX_I2C_OF_PROBER_H
>
> > +#if IS_ENABLED(CONFIG_OF_DYNAMIC)
>
> Do you really need to hide data types with this? Wouldn't be enough to hide
> APIs only?

Ack. Will move the data types outside.


Thanks
ChenYu


> > +struct device;
> > +struct device_node;
> > +
> > +/**
> > + * struct i2c_of_probe_ops - I2C OF component prober callbacks
> > + *
> > + * A set of callbacks to be used by i2c_of_probe_component().
> > + *
> > + * All callbacks are optional. Callbacks are called only once per run, and are
> > + * used in the order they are defined in this structure.
> > + *
> > + * All callbacks that have return values shall return %0 on success,
> > + * or a negative error number on failure.
> > + *
> > + * The @dev parameter passed to the callbacks is the same as @dev passed to
> > + * i2c_of_probe_component(). It should only be used for dev_printk() calls
> > + * and nothing else, especially not managed device resource (devres) APIs.
> > + */
> > +struct i2c_of_probe_ops {
> > +     /** @get_resources: Retrieve resources for components. */
> > +     int (*get_resources)(struct device *dev, struct device_node *bus_node, void *data);
> > +
> > +     /** @free_resources_early: Release exclusive resources prior to enabling component. */
> > +     void (*free_resources_early)(void *data);
> > +
> > +     /**
> > +      * @enable: Enable resources so that the components respond to probes.
> > +      *
> > +      * Resources should be reverted to their initial state before returning if this fails.
> > +      */
> > +     int (*enable)(struct device *dev, void *data);
> > +
> > +     /**
> > +      * @cleanup: Opposite of @enable to balance refcounts after probing.
> > +      *
> > +      * Can not operate on resources already freed in @free_resources_early.
> > +      */
> > +     int (*cleanup)(struct device *dev, void *data);
> > +
> > +     /**
> > +      * @free_resources_late: Release all resources, including those that would have
> > +      *                       been released by @free_resources_early.
> > +      */
> > +     void (*free_resources_late)(void *data);
> > +};
> > +
> > +/**
> > + * struct i2c_of_probe_cfg - I2C OF component prober configuration
> > + * @ops: Callbacks for the prober to use.
> > + * @type: A string to match the device node name prefix to probe for.
> > + */
> > +struct i2c_of_probe_cfg {
> > +     const struct i2c_of_probe_ops *ops;
> > +     const char *type;
> > +};
> > +
> > +int i2c_of_probe_component(struct device *dev, const struct i2c_of_probe_cfg *cfg, void *ctx);
> > +
> > +#endif /* IS_ENABLED(CONFIG_OF_DYNAMIC) */
> > +
> > +#endif /* _LINUX_I2C_OF_PROBER_H */
>
> --
> With Best Regards,
> Andy Shevchenko
>
>


^ permalink raw reply	[flat|nested] 37+ messages in thread

* Re: [PATCH v7 06/10] i2c: Introduce OF component probe function
  2024-09-13 23:43   ` Doug Anderson
@ 2024-09-15 11:32     ` Chen-Yu Tsai
  2024-09-16 14:15       ` Doug Anderson
  2024-09-16 10:13     ` Andy Shevchenko
  1 sibling, 1 reply; 37+ messages in thread
From: Chen-Yu Tsai @ 2024-09-15 11:32 UTC (permalink / raw)
  To: Doug Anderson
  Cc: Rob Herring, Saravana Kannan, Matthias Brugger,
	AngeloGioacchino Del Regno, Wolfram Sang, Benson Leung,
	Tzung-Bi Shih, Mark Brown, Liam Girdwood, chrome-platform,
	devicetree, linux-arm-kernel, linux-mediatek, linux-kernel,
	Johan Hovold, Jiri Kosina, Andy Shevchenko, linux-i2c

On Sat, Sep 14, 2024 at 1:44 AM Doug Anderson <dianders@chromium.org> wrote:
>
> Hi,
>
> On Wed, Sep 11, 2024 at 12:28 AM Chen-Yu Tsai <wenst@chromium.org> wrote:
> >
> > Some devices are designed and manufactured with some components having
> > multiple drop-in replacement options. These components are often
> > connected to the mainboard via ribbon cables, having the same signals
> > and pin assignments across all options. These may include the display
> > panel and touchscreen on laptops and tablets, and the trackpad on
> > laptops. Sometimes which component option is used in a particular device
> > can be detected by some firmware provided identifier, other times that
> > information is not available, and the kernel has to try to probe each
> > device.
> >
> > This change attempts to make the "probe each device" case cleaner. The
> > current approach is to have all options added and enabled in the device
> > tree. The kernel would then bind each device and run each driver's probe
> > function. This works, but has been broken before due to the introduction
> > of asynchronous probing, causing multiple instances requesting "shared"
> > resources, such as pinmuxes, GPIO pins, interrupt lines, at the same
> > time, with only one instance succeeding. Work arounds for these include
> > moving the pinmux to the parent I2C controller, using GPIO hogs or
> > pinmux settings to keep the GPIO pins in some fixed configuration, and
> > requesting the interrupt line very late. Such configurations can be seen
> > on the MT8183 Krane Chromebook tablets, and the Qualcomm sc8280xp-based
> > Lenovo Thinkpad 13S.
> >
> > Instead of this delicate dance between drivers and device tree quirks,
> > this change introduces a simple I2C component probe. function For a
>
> s/probe. function/probe function./

Ack.

> > +static int i2c_of_probe_enable_node(struct device *dev, struct device_node *node)
> > +{
> > +       int ret;
> > +
> > +       dev_info(dev, "Enabling %pOF\n", node);
> > +
> > +       struct of_changeset *ocs __free(kfree) = kzalloc(sizeof(*ocs), GFP_KERNEL);
> > +       if (!ocs)
> > +               return -ENOMEM;
>
> I guess the kernel lets you mix code and declarations now? I'm still
> used to all declarations being together but maybe I'm old school... I
> would have put the "dev_info" below the allocation...

AFAIK this is an exception. Excerpt from include/linux/cleanup.h:

    When the unwind order matters it requires that variables be defined
    mid-function scope rather than at the top of the file.

and

    Given that the "__free(...) = NULL" pattern for variables defined at
    the top of the function poses this potential interdependency problem
    the recommendation is to always define and assign variables in one
    statement and not group variable definitions at the top of the
    function when __free() is used.


>
> > +/**
> > + * i2c_of_probe_component() - probe for devices of "type" on the same i2c bus
> > + * @dev: Pointer to the &struct device of the caller, only used for dev_printk() messages.
> > + * @cfg: Pointer to the &struct i2c_of_probe_cfg containing callbacks and other options
> > + *       for the prober.
> > + * @ctx: Context data for callbacks.
> > + *
> > + * Probe for possible I2C components of the same "type" (&i2c_of_probe_cfg->type)
> > + * on the same I2C bus that have their status marked as "fail".
>
> I may have missed it, but originally this was ones marked
> "fail-needs-probe", right? Now it tries all types of fail?
>
>
> > + * Assumes that across the entire device tree the only instances of nodes
> > + * prefixed with "type" are the ones that need handling for second source
> > + * components. In other words, if "type" is "touchscreen", then all device
> > + * nodes named "touchscreen*" are the ones that need probing. There cannot
>
> "touchscreen*" implies that it can have an arbitrary suffix. Can it?

That is the idea. The use case is for components that have conflicting
addresses and need special probing. Such device nodes obviously can't
have the same node name. This is planned but not implemented in this
series.

> ...or can it just have a unit address?

IIUC in DT jargon the "node name" does not include the address. The name
including the address is the "full name".

> > + * be another "touchscreen" node that is already enabled.
> > + *
> > + * Assumes that for each "type" of component, only one actually exists. In
> > + * other words, only one matching and existing device will be enabled.
> > + *
> > + * Context: Process context only. Does non-atomic I2C transfers.
> > + *          Should only be used from a driver probe function, as the function
> > + *          can return -EPROBE_DEFER if the I2C adapter or other resources
> > + *          are unavailable.
> > + * Return: 0 on success or no-op, error code otherwise.
> > + *         A no-op can happen when it seems like the device tree already
> > + *         has components of the type to be probed already enabled. This
> > + *         can happen when the device tree had not been updated to mark
> > + *         the status of the to-be-probed components as "fail". Or this
> > + *         function was already run with the same parameters and succeeded
> > + *         in enabling a component. The latter could happen if the user
>
> s/latter/later

Are you sure?

> > + *         had multiple types of components to probe, and one of them down
> > + *         the list caused a deferred probe. This is expected behavior.
> > + */
> > +int i2c_of_probe_component(struct device *dev, const struct i2c_of_probe_cfg *cfg, void *ctx)
> > +{
> > +       const struct i2c_of_probe_ops *ops;
> > +       const char *type;
> > +       struct device_node *i2c_node;
> > +       struct i2c_adapter *i2c;
> > +       int ret;
> > +
> > +       if (!cfg)
> > +               return -EINVAL;
>
> Drop extra check of "!cfg". In general kernel conventions don't check
> for NULL pointers passed by caller unless it's an expected case. You
> don't check for a NULL "dev" and you shouldn't need to check for a
> NULL "cfg". They are both simply required parameters.

"dev" is only passed to dev_printk(), and that can handle "dev" being
NULL. Same can't be said for "cfg".

I don't know what the preference is though. Crashing is probably not the
nicest thing, even if it only happens to developers.

> There are a few other places in the patch series where it feels like
> there are extra arg checks that aren't really needed...
>
>
> > +       ops = cfg->ops ?: &i2c_of_probe_dummy_ops;
> > +       type = cfg->type;
> > +
> > +       i2c_node = i2c_of_probe_get_i2c_node(dev, type);
> > +       if (IS_ERR(i2c_node))
> > +               return PTR_ERR(i2c_node);
> > +
> > +       for_each_child_of_node_with_prefix(i2c_node, node, type) {
>
> I wouldn't object to a comment before this for loop:
>
> /* If any devices of this type are already enabled then the function
> is a noop */
>
> ...or it could be a helper function.

That is what the commeet within the loop is trying to say. I'll move
it before the loop and incorporate your words. The loop can then be
rewritten to return early.

> > +               if (!of_device_is_available(node))
> > +                       continue;
> > +
> > +               /*
> > +                * Device tree has component already enabled. Either the
> > +                * device tree isn't supported or we already probed once.
> > +                */
> > +               ret = 0;
> > +               goto out_put_i2c_node;
> > +       }
> > +
> > +       i2c = of_get_i2c_adapter_by_node(i2c_node);
> > +       if (!i2c) {
> > +               ret = dev_err_probe(dev, -EPROBE_DEFER, "Couldn't get I2C adapter\n");
> > +               goto out_put_i2c_node;
> > +       }
> > +
> > +       /* Grab resources */
> > +       ret = 0;
> > +       if (ops->get_resources)
> > +               ret = ops->get_resources(dev, i2c_node, ctx);
> > +       if (ret)
> > +               goto out_put_i2c_adapter;
> > +
> > +       /* Enable resources */
> > +       if (ops->enable)
> > +               ret = ops->enable(dev, ctx);
> > +       if (ret)
> > +               goto out_release_resources;
>
> I won't insist, but a part of me wonders whether we should just
> combine "get_resources" and "enable" and then combine "cleanup" and
> "free_resources_late". They are always paired one after another and
> I'm having a hard time seeing why they need to be separate. It's not
> like you'll ever get the resources and then enable/disable multiple
> times.

Maybe. The structure was carried over from the original non-callback
version. I think it's easier to reason about if they are kept separate,
especially since the outgoing path is slightly different when no working
component is found and one of the callbacks ends up not getting called.

> > +/**
> > + * struct i2c_of_probe_ops - I2C OF component prober callbacks
> > + *
> > + * A set of callbacks to be used by i2c_of_probe_component().
> > + *
> > + * All callbacks are optional. Callbacks are called only once per run, and are
> > + * used in the order they are defined in this structure.
> > + *
> > + * All callbacks that have return values shall return %0 on success,
> > + * or a negative error number on failure.
> > + *
> > + * The @dev parameter passed to the callbacks is the same as @dev passed to
> > + * i2c_of_probe_component(). It should only be used for dev_printk() calls
> > + * and nothing else, especially not managed device resource (devres) APIs.
> > + */
> > +struct i2c_of_probe_ops {
> > +       /** @get_resources: Retrieve resources for components. */
> > +       int (*get_resources)(struct device *dev, struct device_node *bus_node, void *data);
> > +
> > +       /** @free_resources_early: Release exclusive resources prior to enabling component. */
> > +       void (*free_resources_early)(void *data);
>
> It would be good if the doc here mentioned what happened if no
> components were found and thus nothing was enabled. Is the function
> still called? It looks like "no" and "cleanup" is in charge of
> cleaning in this case. Feels like the docs need to be more explicit.

Ack.


Thanks
ChenYu


^ permalink raw reply	[flat|nested] 37+ messages in thread

* Re: [PATCH v7 06/10] i2c: Introduce OF component probe function
  2024-09-13 23:43   ` Doug Anderson
  2024-09-15 11:32     ` Chen-Yu Tsai
@ 2024-09-16 10:13     ` Andy Shevchenko
  1 sibling, 0 replies; 37+ messages in thread
From: Andy Shevchenko @ 2024-09-16 10:13 UTC (permalink / raw)
  To: Doug Anderson
  Cc: Chen-Yu Tsai, Rob Herring, Saravana Kannan, Matthias Brugger,
	AngeloGioacchino Del Regno, Wolfram Sang, Benson Leung,
	Tzung-Bi Shih, Mark Brown, Liam Girdwood, chrome-platform,
	devicetree, linux-arm-kernel, linux-mediatek, linux-kernel,
	Johan Hovold, Jiri Kosina, linux-i2c

On Fri, Sep 13, 2024 at 04:43:04PM -0700, Doug Anderson wrote:
> On Wed, Sep 11, 2024 at 12:28 AM Chen-Yu Tsai <wenst@chromium.org> wrote:

...

> > +static int i2c_of_probe_enable_node(struct device *dev, struct device_node *node)
> > +{
> > +       int ret;
> > +
> > +       dev_info(dev, "Enabling %pOF\n", node);
> > +
> > +       struct of_changeset *ocs __free(kfree) = kzalloc(sizeof(*ocs), GFP_KERNEL);
> > +       if (!ocs)
> > +               return -ENOMEM;
> 
> I guess the kernel lets you mix code and declarations now? I'm still
> used to all declarations being together but maybe I'm old school... I
> would have put the "dev_info" below the allocation...

In general yes, but we don't allow it everywhere for everything,
we have two exceptions:
1) for-loops;
2) __free() RAII.


-- 
With Best Regards,
Andy Shevchenko




^ permalink raw reply	[flat|nested] 37+ messages in thread

* Re: [PATCH v7 06/10] i2c: Introduce OF component probe function
  2024-09-15 10:44     ` Chen-Yu Tsai
@ 2024-09-16 10:36       ` Andy Shevchenko
  2024-09-16 10:55         ` Jonathan Cameron
  2024-09-16 14:59         ` Chen-Yu Tsai
  0 siblings, 2 replies; 37+ messages in thread
From: Andy Shevchenko @ 2024-09-16 10:36 UTC (permalink / raw)
  To: Chen-Yu Tsai
  Cc: Rob Herring, Saravana Kannan, Matthias Brugger,
	AngeloGioacchino Del Regno, Wolfram Sang, Benson Leung,
	Tzung-Bi Shih, Mark Brown, Liam Girdwood, chrome-platform,
	devicetree, linux-arm-kernel, linux-mediatek, linux-kernel,
	Douglas Anderson, Johan Hovold, Jiri Kosina, linux-i2c

On Sun, Sep 15, 2024 at 12:44:13PM +0200, Chen-Yu Tsai wrote:
> On Fri, Sep 13, 2024 at 12:25 PM Andy Shevchenko
> <andriy.shevchenko@linux.intel.com> wrote:
> > On Wed, Sep 11, 2024 at 03:27:44PM +0800, Chen-Yu Tsai wrote:

...

> > > +int i2c_of_probe_component(struct device *dev, const struct i2c_of_probe_cfg *cfg, void *ctx)
> > > +{
> > > +     const struct i2c_of_probe_ops *ops;
> > > +     const char *type;
> > > +     struct device_node *i2c_node;
> > > +     struct i2c_adapter *i2c;
> > > +     int ret;
> > > +
> > > +     if (!cfg)
> > > +             return -EINVAL;
> > > +
> > > +     ops = cfg->ops ?: &i2c_of_probe_dummy_ops;
> > > +     type = cfg->type;
> > > +
> > > +     i2c_node = i2c_of_probe_get_i2c_node(dev, type);
> >
> >
> >         struct device_node *i2c_node __free(of_node_put) =
> >                 i2c_...;
> 
> cleanup.h says to not mix the two styles (scoped vs goto). I was trying
> to follow that, though I realize now that with the scoped loops it
> probably doesn't help.
> 
> I'll revert back to having __free().
> 
> > > +     if (IS_ERR(i2c_node))
> > > +             return PTR_ERR(i2c_node);
> > > +
> > > +     for_each_child_of_node_with_prefix(i2c_node, node, type) {
> > > +             if (!of_device_is_available(node))
> > > +                     continue;
> > > +
> > > +             /*
> > > +              * Device tree has component already enabled. Either the
> > > +              * device tree isn't supported or we already probed once.
> > > +              */
> > > +             ret = 0;
> >
> > Shouldn't you drop reference count for "node"? (See also below)
> 
> This for-each loop the "scoped". It just doesn't have the prefix anymore.
> I believe you asked if the prefix could be dropped and then Rob agreed.

Hmm... I have looked into the implementation and I haven't found the evidence
that this is anyhow scoped. Can you point out what I have missed?

> > > +             goto out_put_i2c_node;
> > > +     }
> > > +
> > > +     i2c = of_get_i2c_adapter_by_node(i2c_node);
> > > +     if (!i2c) {
> > > +             ret = dev_err_probe(dev, -EPROBE_DEFER, "Couldn't get I2C adapter\n");
> > > +             goto out_put_i2c_node;
> > > +     }
> > > +
> > > +     /* Grab resources */
> > > +     ret = 0;
> > > +     if (ops->get_resources)
> > > +             ret = ops->get_resources(dev, i2c_node, ctx);
> > > +     if (ret)
> > > +             goto out_put_i2c_adapter;
> > > +
> > > +     /* Enable resources */
> > > +     if (ops->enable)
> > > +             ret = ops->enable(dev, ctx);
> > > +     if (ret)
> > > +             goto out_release_resources;
> > > +
> > > +     ret = 0;
> > > +     for_each_child_of_node_with_prefix(i2c_node, node, type) {
> > > +             union i2c_smbus_data data;
> > > +             u32 addr;
> > > +
> > > +             if (of_property_read_u32(node, "reg", &addr))
> > > +                     continue;
> > > +             if (i2c_smbus_xfer(i2c, addr, 0, I2C_SMBUS_READ, 0, I2C_SMBUS_BYTE, &data) < 0)
> > > +                     continue;
> > > +
> > > +             /* Found a device that is responding */
> > > +             if (ops->free_resources_early)
> > > +                     ops->free_resources_early(ctx);
> > > +             ret = i2c_of_probe_enable_node(dev, node);
> >
> > Hmm... Is "node" reference count left bumped up for a reason?
> 
> Same as above.

Same as above.

> > > +             break;
> > > +     }
> > > +
> > > +     if (ops->cleanup)
> > > +             ops->cleanup(dev, ctx);
> > > +out_release_resources:
> > > +     if (ops->free_resources_late)
> > > +             ops->free_resources_late(ctx);
> > > +out_put_i2c_adapter:
> > > +     i2c_put_adapter(i2c);
> > > +out_put_i2c_node:
> > > +     of_node_put(i2c_node);
> > > +
> > > +     return ret;
> > > +}

-- 
With Best Regards,
Andy Shevchenko




^ permalink raw reply	[flat|nested] 37+ messages in thread

* Re: [PATCH v7 06/10] i2c: Introduce OF component probe function
  2024-09-16 10:36       ` Andy Shevchenko
@ 2024-09-16 10:55         ` Jonathan Cameron
  2024-09-16 14:59         ` Chen-Yu Tsai
  1 sibling, 0 replies; 37+ messages in thread
From: Jonathan Cameron @ 2024-09-16 10:55 UTC (permalink / raw)
  To: Andy Shevchenko
  Cc: Chen-Yu Tsai, Rob Herring, Saravana Kannan, Matthias Brugger,
	AngeloGioacchino Del Regno, Wolfram Sang, Benson Leung,
	Tzung-Bi Shih, Mark Brown, Liam Girdwood, chrome-platform,
	devicetree, linux-arm-kernel, linux-mediatek, linux-kernel,
	Douglas Anderson, Johan Hovold, Jiri Kosina, linux-i2c

On Mon, 16 Sep 2024 13:36:14 +0300
Andy Shevchenko <andriy.shevchenko@linux.intel.com> wrote:

> On Sun, Sep 15, 2024 at 12:44:13PM +0200, Chen-Yu Tsai wrote:
> > On Fri, Sep 13, 2024 at 12:25 PM Andy Shevchenko
> > <andriy.shevchenko@linux.intel.com> wrote:  
> > > On Wed, Sep 11, 2024 at 03:27:44PM +0800, Chen-Yu Tsai wrote:  
> 
> ...
> 
> > > > +int i2c_of_probe_component(struct device *dev, const struct i2c_of_probe_cfg *cfg, void *ctx)
> > > > +{
> > > > +     const struct i2c_of_probe_ops *ops;
> > > > +     const char *type;
> > > > +     struct device_node *i2c_node;
> > > > +     struct i2c_adapter *i2c;
> > > > +     int ret;
> > > > +
> > > > +     if (!cfg)
> > > > +             return -EINVAL;
> > > > +
> > > > +     ops = cfg->ops ?: &i2c_of_probe_dummy_ops;
> > > > +     type = cfg->type;
> > > > +
> > > > +     i2c_node = i2c_of_probe_get_i2c_node(dev, type);  
> > >
> > >
> > >         struct device_node *i2c_node __free(of_node_put) =
> > >                 i2c_...;  
> > 
> > cleanup.h says to not mix the two styles (scoped vs goto). I was trying
> > to follow that, though I realize now that with the scoped loops it
> > probably doesn't help.

The problem pattern is (IIUC)

	if (x)
		goto bob;

	struct device_node *i2c_node __free(of_node_put) = i2c_....


bob:
	return ret;


So a goto that jumps over registration of a cleanup function.

Jonathan

> > 
> > I'll revert back to having __free().
> >   
> > > > +     if (IS_ERR(i2c_node))
> > > > +             return PTR_ERR(i2c_node);
> > > > +
> > > > +     for_each_child_of_node_with_prefix(i2c_node, node, type) {
> > > > +             if (!of_device_is_available(node))
> > > > +                     continue;
> > > > +
> > > > +             /*
> > > > +              * Device tree has component already enabled. Either the
> > > > +              * device tree isn't supported or we already probed once.
> > > > +              */
> > > > +             ret = 0;  
> > >
> > > Shouldn't you drop reference count for "node"? (See also below)  
> > 
> > This for-each loop the "scoped". It just doesn't have the prefix anymore.
> > I believe you asked if the prefix could be dropped and then Rob agreed.  
> 
> Hmm... I have looked into the implementation and I haven't found the evidence
> that this is anyhow scoped. Can you point out what I have missed?
> 
> > > > +             goto out_put_i2c_node;
> > > > +     }
> > > > +
> > > > +     i2c = of_get_i2c_adapter_by_node(i2c_node);
> > > > +     if (!i2c) {
> > > > +             ret = dev_err_probe(dev, -EPROBE_DEFER, "Couldn't get I2C adapter\n");
> > > > +             goto out_put_i2c_node;
> > > > +     }
> > > > +
> > > > +     /* Grab resources */
> > > > +     ret = 0;
> > > > +     if (ops->get_resources)
> > > > +             ret = ops->get_resources(dev, i2c_node, ctx);
> > > > +     if (ret)
> > > > +             goto out_put_i2c_adapter;
> > > > +
> > > > +     /* Enable resources */
> > > > +     if (ops->enable)
> > > > +             ret = ops->enable(dev, ctx);
> > > > +     if (ret)
> > > > +             goto out_release_resources;
> > > > +
> > > > +     ret = 0;
> > > > +     for_each_child_of_node_with_prefix(i2c_node, node, type) {
> > > > +             union i2c_smbus_data data;
> > > > +             u32 addr;
> > > > +
> > > > +             if (of_property_read_u32(node, "reg", &addr))
> > > > +                     continue;
> > > > +             if (i2c_smbus_xfer(i2c, addr, 0, I2C_SMBUS_READ, 0, I2C_SMBUS_BYTE, &data) < 0)
> > > > +                     continue;
> > > > +
> > > > +             /* Found a device that is responding */
> > > > +             if (ops->free_resources_early)
> > > > +                     ops->free_resources_early(ctx);
> > > > +             ret = i2c_of_probe_enable_node(dev, node);  
> > >
> > > Hmm... Is "node" reference count left bumped up for a reason?  
> > 
> > Same as above.  
> 
> Same as above.
> 
> > > > +             break;
> > > > +     }
> > > > +
> > > > +     if (ops->cleanup)
> > > > +             ops->cleanup(dev, ctx);
> > > > +out_release_resources:
> > > > +     if (ops->free_resources_late)
> > > > +             ops->free_resources_late(ctx);
> > > > +out_put_i2c_adapter:
> > > > +     i2c_put_adapter(i2c);
> > > > +out_put_i2c_node:
> > > > +     of_node_put(i2c_node);
> > > > +
> > > > +     return ret;
> > > > +}  
> 



^ permalink raw reply	[flat|nested] 37+ messages in thread

* Re: [PATCH v7 06/10] i2c: Introduce OF component probe function
  2024-09-15 11:32     ` Chen-Yu Tsai
@ 2024-09-16 14:15       ` Doug Anderson
  2024-09-16 14:31         ` Chen-Yu Tsai
  0 siblings, 1 reply; 37+ messages in thread
From: Doug Anderson @ 2024-09-16 14:15 UTC (permalink / raw)
  To: Chen-Yu Tsai
  Cc: Rob Herring, Saravana Kannan, Matthias Brugger,
	AngeloGioacchino Del Regno, Wolfram Sang, Benson Leung,
	Tzung-Bi Shih, Mark Brown, Liam Girdwood, chrome-platform,
	devicetree, linux-arm-kernel, linux-mediatek, linux-kernel,
	Johan Hovold, Jiri Kosina, Andy Shevchenko, linux-i2c

Hi,

On Sun, Sep 15, 2024 at 4:32 AM Chen-Yu Tsai <wenst@chromium.org> wrote:
>
> > > + * Assumes that across the entire device tree the only instances of nodes
> > > + * prefixed with "type" are the ones that need handling for second source
> > > + * components. In other words, if "type" is "touchscreen", then all device
> > > + * nodes named "touchscreen*" are the ones that need probing. There cannot
> >
> > "touchscreen*" implies that it can have an arbitrary suffix. Can it?
>
> That is the idea. The use case is for components that have conflicting
> addresses and need special probing. Such device nodes obviously can't
> have the same node name. This is planned but not implemented in this
> series.

Maybe "touchscreen@*" instead of "touchscreen*" if I'm understanding correctly.


> > > + * be another "touchscreen" node that is already enabled.
> > > + *
> > > + * Assumes that for each "type" of component, only one actually exists. In
> > > + * other words, only one matching and existing device will be enabled.
> > > + *
> > > + * Context: Process context only. Does non-atomic I2C transfers.
> > > + *          Should only be used from a driver probe function, as the function
> > > + *          can return -EPROBE_DEFER if the I2C adapter or other resources
> > > + *          are unavailable.
> > > + * Return: 0 on success or no-op, error code otherwise.
> > > + *         A no-op can happen when it seems like the device tree already
> > > + *         has components of the type to be probed already enabled. This
> > > + *         can happen when the device tree had not been updated to mark
> > > + *         the status of the to-be-probed components as "fail". Or this
> > > + *         function was already run with the same parameters and succeeded
> > > + *         in enabling a component. The latter could happen if the user
> >
> > s/latter/later
>
> Are you sure?

No. latter looked weird to me and I searched quickly and thought I was
right. With a more full search looks like you're right.


> > > +int i2c_of_probe_component(struct device *dev, const struct i2c_of_probe_cfg *cfg, void *ctx)
> > > +{
> > > +       const struct i2c_of_probe_ops *ops;
> > > +       const char *type;
> > > +       struct device_node *i2c_node;
> > > +       struct i2c_adapter *i2c;
> > > +       int ret;
> > > +
> > > +       if (!cfg)
> > > +               return -EINVAL;
> >
> > Drop extra check of "!cfg". In general kernel conventions don't check
> > for NULL pointers passed by caller unless it's an expected case. You
> > don't check for a NULL "dev" and you shouldn't need to check for a
> > NULL "cfg". They are both simply required parameters.
>
> "dev" is only passed to dev_printk(), and that can handle "dev" being
> NULL. Same can't be said for "cfg".
>
> I don't know what the preference is though. Crashing is probably not the
> nicest thing, even if it only happens to developers.

Honestly as a developer I'd prefer the crash. It points out the exact
line where I had an invalid NULL. Returning an error code means I've
got to compile/boot several more times to track down where the error
code is coming from.

I'm fairly certain that the kernel convention is to only check things
for NULL if it's part of the API to accept NULL or if the value can be
NULL due to untrusted data. If the only way it can be NULL is due to
buggy code elsewhere in the kernel then you should omit the error
checks.

> > > +               if (!of_device_is_available(node))
> > > +                       continue;
> > > +
> > > +               /*
> > > +                * Device tree has component already enabled. Either the
> > > +                * device tree isn't supported or we already probed once.
> > > +                */
> > > +               ret = 0;
> > > +               goto out_put_i2c_node;
> > > +       }
> > > +
> > > +       i2c = of_get_i2c_adapter_by_node(i2c_node);
> > > +       if (!i2c) {
> > > +               ret = dev_err_probe(dev, -EPROBE_DEFER, "Couldn't get I2C adapter\n");
> > > +               goto out_put_i2c_node;
> > > +       }
> > > +
> > > +       /* Grab resources */
> > > +       ret = 0;
> > > +       if (ops->get_resources)
> > > +               ret = ops->get_resources(dev, i2c_node, ctx);
> > > +       if (ret)
> > > +               goto out_put_i2c_adapter;
> > > +
> > > +       /* Enable resources */
> > > +       if (ops->enable)
> > > +               ret = ops->enable(dev, ctx);
> > > +       if (ret)
> > > +               goto out_release_resources;
> >
> > I won't insist, but a part of me wonders whether we should just
> > combine "get_resources" and "enable" and then combine "cleanup" and
> > "free_resources_late". They are always paired one after another and
> > I'm having a hard time seeing why they need to be separate. It's not
> > like you'll ever get the resources and then enable/disable multiple
> > times.
>
> Maybe. The structure was carried over from the original non-callback
> version. I think it's easier to reason about if they are kept separate,
> especially since the outgoing path is slightly different when no working
> component is found and one of the callbacks ends up not getting called.

Actually, both of the outgoing callbacks are always called. It's only
the 3rd callback (the "early" one) that's called sometimes.

I won't insist on combining them, but I still feel like combining them
would be better. I'd be interested in other opinions, though.


-Doug


^ permalink raw reply	[flat|nested] 37+ messages in thread

* Re: [PATCH v7 06/10] i2c: Introduce OF component probe function
  2024-09-16 14:15       ` Doug Anderson
@ 2024-09-16 14:31         ` Chen-Yu Tsai
  0 siblings, 0 replies; 37+ messages in thread
From: Chen-Yu Tsai @ 2024-09-16 14:31 UTC (permalink / raw)
  To: Doug Anderson
  Cc: Rob Herring, Saravana Kannan, Matthias Brugger,
	AngeloGioacchino Del Regno, Wolfram Sang, Benson Leung,
	Tzung-Bi Shih, Mark Brown, Liam Girdwood, chrome-platform,
	devicetree, linux-arm-kernel, linux-mediatek, linux-kernel,
	Johan Hovold, Jiri Kosina, Andy Shevchenko, linux-i2c

On Mon, Sep 16, 2024 at 4:16 PM Doug Anderson <dianders@chromium.org> wrote:
>
> Hi,
>
> On Sun, Sep 15, 2024 at 4:32 AM Chen-Yu Tsai <wenst@chromium.org> wrote:
> >
> > > > + * Assumes that across the entire device tree the only instances of nodes
> > > > + * prefixed with "type" are the ones that need handling for second source
> > > > + * components. In other words, if "type" is "touchscreen", then all device
> > > > + * nodes named "touchscreen*" are the ones that need probing. There cannot
> > >
> > > "touchscreen*" implies that it can have an arbitrary suffix. Can it?
> >
> > That is the idea. The use case is for components that have conflicting
> > addresses and need special probing. Such device nodes obviously can't
> > have the same node name. This is planned but not implemented in this
> > series.
>
> Maybe "touchscreen@*" instead of "touchscreen*" if I'm understanding correctly.

Then it would be "touchscreen*@*".

> > > > + * be another "touchscreen" node that is already enabled.
> > > > + *
> > > > + * Assumes that for each "type" of component, only one actually exists. In
> > > > + * other words, only one matching and existing device will be enabled.
> > > > + *
> > > > + * Context: Process context only. Does non-atomic I2C transfers.
> > > > + *          Should only be used from a driver probe function, as the function
> > > > + *          can return -EPROBE_DEFER if the I2C adapter or other resources
> > > > + *          are unavailable.
> > > > + * Return: 0 on success or no-op, error code otherwise.
> > > > + *         A no-op can happen when it seems like the device tree already
> > > > + *         has components of the type to be probed already enabled. This
> > > > + *         can happen when the device tree had not been updated to mark
> > > > + *         the status of the to-be-probed components as "fail". Or this
> > > > + *         function was already run with the same parameters and succeeded
> > > > + *         in enabling a component. The latter could happen if the user
> > >
> > > s/latter/later
> >
> > Are you sure?
>
> No. latter looked weird to me and I searched quickly and thought I was
> right. With a more full search looks like you're right.
>
>
> > > > +int i2c_of_probe_component(struct device *dev, const struct i2c_of_probe_cfg *cfg, void *ctx)
> > > > +{
> > > > +       const struct i2c_of_probe_ops *ops;
> > > > +       const char *type;
> > > > +       struct device_node *i2c_node;
> > > > +       struct i2c_adapter *i2c;
> > > > +       int ret;
> > > > +
> > > > +       if (!cfg)
> > > > +               return -EINVAL;
> > >
> > > Drop extra check of "!cfg". In general kernel conventions don't check
> > > for NULL pointers passed by caller unless it's an expected case. You
> > > don't check for a NULL "dev" and you shouldn't need to check for a
> > > NULL "cfg". They are both simply required parameters.
> >
> > "dev" is only passed to dev_printk(), and that can handle "dev" being
> > NULL. Same can't be said for "cfg".
> >
> > I don't know what the preference is though. Crashing is probably not the
> > nicest thing, even if it only happens to developers.
>
> Honestly as a developer I'd prefer the crash. It points out the exact
> line where I had an invalid NULL. Returning an error code means I've
> got to compile/boot several more times to track down where the error
> code is coming from.
>
> I'm fairly certain that the kernel convention is to only check things
> for NULL if it's part of the API to accept NULL or if the value can be
> NULL due to untrusted data. If the only way it can be NULL is due to
> buggy code elsewhere in the kernel then you should omit the error
> checks.

Make sense.

> > > > +               if (!of_device_is_available(node))
> > > > +                       continue;
> > > > +
> > > > +               /*
> > > > +                * Device tree has component already enabled. Either the
> > > > +                * device tree isn't supported or we already probed once.
> > > > +                */
> > > > +               ret = 0;
> > > > +               goto out_put_i2c_node;
> > > > +       }
> > > > +
> > > > +       i2c = of_get_i2c_adapter_by_node(i2c_node);
> > > > +       if (!i2c) {
> > > > +               ret = dev_err_probe(dev, -EPROBE_DEFER, "Couldn't get I2C adapter\n");
> > > > +               goto out_put_i2c_node;
> > > > +       }
> > > > +
> > > > +       /* Grab resources */
> > > > +       ret = 0;
> > > > +       if (ops->get_resources)
> > > > +               ret = ops->get_resources(dev, i2c_node, ctx);
> > > > +       if (ret)
> > > > +               goto out_put_i2c_adapter;
> > > > +
> > > > +       /* Enable resources */
> > > > +       if (ops->enable)
> > > > +               ret = ops->enable(dev, ctx);
> > > > +       if (ret)
> > > > +               goto out_release_resources;
> > >
> > > I won't insist, but a part of me wonders whether we should just
> > > combine "get_resources" and "enable" and then combine "cleanup" and
> > > "free_resources_late". They are always paired one after another and
> > > I'm having a hard time seeing why they need to be separate. It's not
> > > like you'll ever get the resources and then enable/disable multiple
> > > times.
> >
> > Maybe. The structure was carried over from the original non-callback
> > version. I think it's easier to reason about if they are kept separate,
> > especially since the outgoing path is slightly different when no working
> > component is found and one of the callbacks ends up not getting called.
>
> Actually, both of the outgoing callbacks are always called. It's only
> the 3rd callback (the "early" one) that's called sometimes.

So IIRC do "get + enable" and "cleanup + release_late", and leave
"release_early" alone?

ChenYu

> I won't insist on combining them, but I still feel like combining them
> would be better. I'd be interested in other opinions, though.
>
>
> -Doug
>


^ permalink raw reply	[flat|nested] 37+ messages in thread

* Re: [PATCH v7 09/10] platform/chrome: Introduce device tree hardware prober
  2024-09-13 23:43   ` Doug Anderson
@ 2024-09-16 14:58     ` Chen-Yu Tsai
  2024-09-16 15:23       ` Andy Shevchenko
  0 siblings, 1 reply; 37+ messages in thread
From: Chen-Yu Tsai @ 2024-09-16 14:58 UTC (permalink / raw)
  To: Doug Anderson
  Cc: Rob Herring, Saravana Kannan, Matthias Brugger,
	AngeloGioacchino Del Regno, Wolfram Sang, Benson Leung,
	Tzung-Bi Shih, Mark Brown, Liam Girdwood, chrome-platform,
	devicetree, linux-arm-kernel, linux-mediatek, linux-kernel,
	Johan Hovold, Jiri Kosina, Andy Shevchenko, linux-i2c

On Sat, Sep 14, 2024 at 1:43 AM Doug Anderson <dianders@chromium.org> wrote:
>
> Hi,
>
> On Wed, Sep 11, 2024 at 12:29 AM Chen-Yu Tsai <wenst@chromium.org> wrote:
> >
> > @@ -8,6 +8,7 @@ obj-$(CONFIG_CHROMEOS_ACPI)             += chromeos_acpi.o
> >  obj-$(CONFIG_CHROMEOS_LAPTOP)          += chromeos_laptop.o
> >  obj-$(CONFIG_CHROMEOS_PRIVACY_SCREEN)  += chromeos_privacy_screen.o
> >  obj-$(CONFIG_CHROMEOS_PSTORE)          += chromeos_pstore.o
> > +obj-$(CONFIG_CHROMEOS_OF_HW_PROBER)    += chromeos_of_hw_prober.o
>
> "o" sorts before "p" so "of" should sort before "privacy"?
>
> I guess it's not exactly all sorted, but this small section is. Since
> it's arbitrary you could preserve the existing sorting. :-P

To me it seemed more like they are just sorted in the order they were
added.

> > +static const struct hw_prober_entry hw_prober_platforms[] = {
> > +       { .compatible = "google,hana", .prober = chromeos_i2c_component_prober, .data = &chromeos_i2c_probe_dumb_touchscreen },
> > +       { .compatible = "google,hana", .prober = chromeos_i2c_component_prober, .data = &chromeos_i2c_probe_dumb_trackpad },
>
> The fact that the example is only using "dumb" probers doesn't make it
> quite as a compelling proof that the code will scale up. Any chance
> you could add something that requires a bit more oomph? ;-)

I only have a hacked up thing right now.

This is the one I'm using to test things:
http://git.kernel.org/wens/c/5c2c920429167a15b990a7cf8427705eec321134

About this one, it seems we can at least merge the device trees of
each product into just one. The touchscreen or trackpad (or lack thereof)
is probed by the kernel.


This one I only started looking into:
http://git.kernel.org/wens/c/42c21929aeb3c7ca7b0ce9cacb1d0ff915d3c783

About the second one, AFAIK the device tree descriptions are incomplete.
Only one of the trackpad options has the regulator supply described.
The regulator itself is marked as always on, so things currently work.
Some work will need to be put in to research the schematics and test
whether things do work correctly.

> > +static int chromeos_of_hw_prober_driver_init(void)
> > +{
> > +       size_t i;
> > +       int ret;
> > +
> > +       for (i = 0; i < ARRAY_SIZE(hw_prober_platforms); i++)
> > +               if (of_machine_is_compatible(hw_prober_platforms[i].compatible))
> > +                       break;
> > +       if (i == ARRAY_SIZE(hw_prober_platforms))
> > +               return -ENODEV;
> > +
> > +       ret = platform_driver_register(&chromeos_of_hw_prober_driver);
> > +       if (ret)
> > +               return ret;
> > +
> > +       chromeos_of_hw_prober_pdev =
> > +                       platform_device_register_simple(DRV_NAME, PLATFORM_DEVID_NONE, NULL, 0);
> > +       if (IS_ERR(chromeos_of_hw_prober_pdev))
> > +               goto err;
>
> FWIW if you didn't want to see your prober called over and over again
> if one of the devices deferred you could just register one device per
> type, right? Then each device would be able to defer separately. Dunno
> if it's worth it but figured I'd mention it...

I think that adds some unnecessary complexity, and more lingering devices
in the system. These platform devices are not removed.

> Also: as a high level comment, this all looks much nicer to me now
> that it's parameterized. :-)

Thanks!

ChenYu


^ permalink raw reply	[flat|nested] 37+ messages in thread

* Re: [PATCH v7 06/10] i2c: Introduce OF component probe function
  2024-09-16 10:36       ` Andy Shevchenko
  2024-09-16 10:55         ` Jonathan Cameron
@ 2024-09-16 14:59         ` Chen-Yu Tsai
  2024-09-16 15:22           ` Andy Shevchenko
  1 sibling, 1 reply; 37+ messages in thread
From: Chen-Yu Tsai @ 2024-09-16 14:59 UTC (permalink / raw)
  To: Andy Shevchenko
  Cc: Rob Herring, Saravana Kannan, Matthias Brugger,
	AngeloGioacchino Del Regno, Wolfram Sang, Benson Leung,
	Tzung-Bi Shih, Mark Brown, Liam Girdwood, chrome-platform,
	devicetree, linux-arm-kernel, linux-mediatek, linux-kernel,
	Douglas Anderson, Johan Hovold, Jiri Kosina, linux-i2c

On Mon, Sep 16, 2024 at 12:36 PM Andy Shevchenko
<andriy.shevchenko@linux.intel.com> wrote:
>
> On Sun, Sep 15, 2024 at 12:44:13PM +0200, Chen-Yu Tsai wrote:
> > On Fri, Sep 13, 2024 at 12:25 PM Andy Shevchenko
> > <andriy.shevchenko@linux.intel.com> wrote:
> > > On Wed, Sep 11, 2024 at 03:27:44PM +0800, Chen-Yu Tsai wrote:
>
> ...
>
> > > > +int i2c_of_probe_component(struct device *dev, const struct i2c_of_probe_cfg *cfg, void *ctx)
> > > > +{
> > > > +     const struct i2c_of_probe_ops *ops;
> > > > +     const char *type;
> > > > +     struct device_node *i2c_node;
> > > > +     struct i2c_adapter *i2c;
> > > > +     int ret;
> > > > +
> > > > +     if (!cfg)
> > > > +             return -EINVAL;
> > > > +
> > > > +     ops = cfg->ops ?: &i2c_of_probe_dummy_ops;
> > > > +     type = cfg->type;
> > > > +
> > > > +     i2c_node = i2c_of_probe_get_i2c_node(dev, type);
> > >
> > >
> > >         struct device_node *i2c_node __free(of_node_put) =
> > >                 i2c_...;
> >
> > cleanup.h says to not mix the two styles (scoped vs goto). I was trying
> > to follow that, though I realize now that with the scoped loops it
> > probably doesn't help.
> >
> > I'll revert back to having __free().
> >
> > > > +     if (IS_ERR(i2c_node))
> > > > +             return PTR_ERR(i2c_node);
> > > > +
> > > > +     for_each_child_of_node_with_prefix(i2c_node, node, type) {
> > > > +             if (!of_device_is_available(node))
> > > > +                     continue;
> > > > +
> > > > +             /*
> > > > +              * Device tree has component already enabled. Either the
> > > > +              * device tree isn't supported or we already probed once.
> > > > +              */
> > > > +             ret = 0;
> > >
> > > Shouldn't you drop reference count for "node"? (See also below)
> >
> > This for-each loop the "scoped". It just doesn't have the prefix anymore.
> > I believe you asked if the prefix could be dropped and then Rob agreed.
>
> Hmm... I have looked into the implementation and I haven't found the evidence
> that this is anyhow scoped. Can you point out what I have missed?

From patch 2:

+#define for_each_child_of_node_with_prefix(parent, child, prefix)      \
+       for (struct device_node *child __free(device_node) =            \

                                 ^^^^^^^^^^^^^^^^^^^^^^^^^ scoped here

+            of_get_next_child_with_prefix(parent, NULL, prefix);       \
+            child != NULL;                                             \
+            child = of_get_next_child_with_prefix(parent, child, prefix))
+

"node", or "child" in this snippet is scoped within the for loop.


ChenYu

> > > > +             goto out_put_i2c_node;
> > > > +     }
> > > > +
> > > > +     i2c = of_get_i2c_adapter_by_node(i2c_node);
> > > > +     if (!i2c) {
> > > > +             ret = dev_err_probe(dev, -EPROBE_DEFER, "Couldn't get I2C adapter\n");
> > > > +             goto out_put_i2c_node;
> > > > +     }
> > > > +
> > > > +     /* Grab resources */
> > > > +     ret = 0;
> > > > +     if (ops->get_resources)
> > > > +             ret = ops->get_resources(dev, i2c_node, ctx);
> > > > +     if (ret)
> > > > +             goto out_put_i2c_adapter;
> > > > +
> > > > +     /* Enable resources */
> > > > +     if (ops->enable)
> > > > +             ret = ops->enable(dev, ctx);
> > > > +     if (ret)
> > > > +             goto out_release_resources;
> > > > +
> > > > +     ret = 0;
> > > > +     for_each_child_of_node_with_prefix(i2c_node, node, type) {
> > > > +             union i2c_smbus_data data;
> > > > +             u32 addr;
> > > > +
> > > > +             if (of_property_read_u32(node, "reg", &addr))
> > > > +                     continue;
> > > > +             if (i2c_smbus_xfer(i2c, addr, 0, I2C_SMBUS_READ, 0, I2C_SMBUS_BYTE, &data) < 0)
> > > > +                     continue;
> > > > +
> > > > +             /* Found a device that is responding */
> > > > +             if (ops->free_resources_early)
> > > > +                     ops->free_resources_early(ctx);
> > > > +             ret = i2c_of_probe_enable_node(dev, node);
> > >
> > > Hmm... Is "node" reference count left bumped up for a reason?
> >
> > Same as above.
>
> Same as above.
>
> > > > +             break;
> > > > +     }
> > > > +
> > > > +     if (ops->cleanup)
> > > > +             ops->cleanup(dev, ctx);
> > > > +out_release_resources:
> > > > +     if (ops->free_resources_late)
> > > > +             ops->free_resources_late(ctx);
> > > > +out_put_i2c_adapter:
> > > > +     i2c_put_adapter(i2c);
> > > > +out_put_i2c_node:
> > > > +     of_node_put(i2c_node);
> > > > +
> > > > +     return ret;
> > > > +}
>
> --
> With Best Regards,
> Andy Shevchenko
>
>


^ permalink raw reply	[flat|nested] 37+ messages in thread

* Re: [PATCH v7 06/10] i2c: Introduce OF component probe function
  2024-09-16 14:59         ` Chen-Yu Tsai
@ 2024-09-16 15:22           ` Andy Shevchenko
  0 siblings, 0 replies; 37+ messages in thread
From: Andy Shevchenko @ 2024-09-16 15:22 UTC (permalink / raw)
  To: Chen-Yu Tsai
  Cc: Rob Herring, Saravana Kannan, Matthias Brugger,
	AngeloGioacchino Del Regno, Wolfram Sang, Benson Leung,
	Tzung-Bi Shih, Mark Brown, Liam Girdwood, chrome-platform,
	devicetree, linux-arm-kernel, linux-mediatek, linux-kernel,
	Douglas Anderson, Johan Hovold, Jiri Kosina, linux-i2c

On Mon, Sep 16, 2024 at 04:59:59PM +0200, Chen-Yu Tsai wrote:
> On Mon, Sep 16, 2024 at 12:36 PM Andy Shevchenko
> <andriy.shevchenko@linux.intel.com> wrote:
> > On Sun, Sep 15, 2024 at 12:44:13PM +0200, Chen-Yu Tsai wrote:

...

> > Hmm... I have looked into the implementation and I haven't found the evidence
> > that this is anyhow scoped. Can you point out what I have missed?
> 
> From patch 2:
> 
> +#define for_each_child_of_node_with_prefix(parent, child, prefix)      \
> +       for (struct device_node *child __free(device_node) =            \
> 
>                                  ^^^^^^^^^^^^^^^^^^^^^^^^^ scoped here
> 
> +            of_get_next_child_with_prefix(parent, NULL, prefix);       \
> +            child != NULL;                                             \
> +            child = of_get_next_child_with_prefix(parent, child, prefix))
> +
> 
> "node", or "child" in this snippet is scoped within the for loop.

Ah, nice, that's what I missed, thanks!

-- 
With Best Regards,
Andy Shevchenko




^ permalink raw reply	[flat|nested] 37+ messages in thread

* Re: [PATCH v7 09/10] platform/chrome: Introduce device tree hardware prober
  2024-09-16 14:58     ` Chen-Yu Tsai
@ 2024-09-16 15:23       ` Andy Shevchenko
  0 siblings, 0 replies; 37+ messages in thread
From: Andy Shevchenko @ 2024-09-16 15:23 UTC (permalink / raw)
  To: Chen-Yu Tsai
  Cc: Doug Anderson, Rob Herring, Saravana Kannan, Matthias Brugger,
	AngeloGioacchino Del Regno, Wolfram Sang, Benson Leung,
	Tzung-Bi Shih, Mark Brown, Liam Girdwood, chrome-platform,
	devicetree, linux-arm-kernel, linux-mediatek, linux-kernel,
	Johan Hovold, Jiri Kosina, linux-i2c

On Mon, Sep 16, 2024 at 04:58:51PM +0200, Chen-Yu Tsai wrote:
> On Sat, Sep 14, 2024 at 1:43 AM Doug Anderson <dianders@chromium.org> wrote:
> > On Wed, Sep 11, 2024 at 12:29 AM Chen-Yu Tsai <wenst@chromium.org> wrote:

...

> > >  obj-$(CONFIG_CHROMEOS_LAPTOP)          += chromeos_laptop.o
> > >  obj-$(CONFIG_CHROMEOS_PRIVACY_SCREEN)  += chromeos_privacy_screen.o
> > >  obj-$(CONFIG_CHROMEOS_PSTORE)          += chromeos_pstore.o
> > > +obj-$(CONFIG_CHROMEOS_OF_HW_PROBER)    += chromeos_of_hw_prober.o
> >
> > "o" sorts before "p" so "of" should sort before "privacy"?
> >
> > I guess it's not exactly all sorted, but this small section is. Since
> > it's arbitrary you could preserve the existing sorting. :-P
> 
> To me it seemed more like they are just sorted in the order they were
> added.

If we can make it more ordered I'm for it.

Just my 2c.

-- 
With Best Regards,
Andy Shevchenko




^ permalink raw reply	[flat|nested] 37+ messages in thread

* Re: [PATCH v7 08/10] i2c: of-prober: Add GPIO support to simple helpers
  2024-09-13 23:43   ` Doug Anderson
@ 2024-09-17 12:41     ` Chen-Yu Tsai
  2024-09-23 19:11       ` Doug Anderson
  0 siblings, 1 reply; 37+ messages in thread
From: Chen-Yu Tsai @ 2024-09-17 12:41 UTC (permalink / raw)
  To: Doug Anderson
  Cc: Rob Herring, Saravana Kannan, Matthias Brugger,
	AngeloGioacchino Del Regno, Wolfram Sang, Benson Leung,
	Tzung-Bi Shih, Mark Brown, Liam Girdwood, chrome-platform,
	devicetree, linux-arm-kernel, linux-mediatek, linux-kernel,
	Johan Hovold, Jiri Kosina, Andy Shevchenko, linux-i2c

On Sat, Sep 14, 2024 at 1:49 AM Doug Anderson <dianders@chromium.org> wrote:
>
> Hi,
>
> On Wed, Sep 11, 2024 at 12:29 AM Chen-Yu Tsai <wenst@chromium.org> wrote:
> >
> > +static int i2c_of_probe_simple_set_gpio(struct device *dev, struct i2c_of_probe_simple_ctx *ctx)
> > +{
> > +       int ret;
> > +
> > +       if (!ctx->gpiod)
> > +               return 0;
> > +
> > +       dev_dbg(dev, "Setting GPIO\n");
> > +
> > +       ret = gpiod_direction_output_raw(ctx->gpiod, ctx->opts->gpio_high_to_enable ? 1 : 0);
> > +       if (ret)
> > +               return ret;
> > +
> > +       msleep(ctx->opts->post_reset_deassert_delay_ms);
>
> Like in the previous patch, you need an "if
> (ctx->opts->post_reset_deassert_delay_ms)" before the msleep().

Ack.

> > +static void i2c_of_probe_simple_disable_gpio(struct device *dev, struct i2c_of_probe_simple_ctx *ctx)
> > +{
> > +       if (!ctx->gpiod)
> > +               return;
> > +
> > +       dev_dbg(dev, "Setting GPIO to input\n");
> > +
> > +       gpiod_direction_input(ctx->gpiod);
>
> This is weird. Why set it to input?

It seemed to me this would be more like the initial state, without knowing
the actual initial state.

> > @@ -347,6 +438,7 @@ int i2c_of_probe_simple_cleanup(struct device *dev, void *data)
> >  {
> >         struct i2c_of_probe_simple_ctx *ctx = data;
> >
> > +       i2c_of_probe_simple_disable_gpio(dev, ctx);
>
> Maybe add a comment before the GPIO call that it's a noop if we found
> something and i2c_of_probe_simple_free_res_early() was already called?
> Otherwise you need to read into the function to understand why this
> doesn't crash if the early call was made. To me, that makes the
> abstraction add confusion instead of simplifying things.

Ack.

> > @@ -92,24 +93,33 @@ int i2c_of_probe_component(struct device *dev, const struct i2c_of_probe_cfg *cf
> >   * struct i2c_of_probe_simple_opts - Options for simple I2C component prober callbacks
> >   * @res_node_compatible: Compatible string of device node to retrieve resources from.
> >   * @supply_name: Name of regulator supply.
> > + * @gpio_name: Name of GPIO.
>
> Talk about the fact that gpio_name can be NULL or an empty string and
> that they mean different things.

Ack.

> >   * @post_power_on_delay_ms: Delay in ms after regulators are powered on. Passed to msleep().
> > + * @post_reset_deassert_delay_ms: Delay in ms after GPIOs are set. Passed to msleep().
> > + * @gpio_high_to_enable: %true if GPIO should be set to electrical high to enable component.
>
> Now that you've added the GPIOs and more delays, the description of
> this structure needs to list exactly what the power sequence your
> simple functions assume.

Ack.

> I would also say: given that you're providing a parameter anyway and
> you're giving the GPIO name, can you please move away from the "raw"
> values and move to "logical" values?

I disagree. When hardware engineers design for swappable components, they
likely look at the electrical compatibility of them. In this case, an
active-high "enable" pin is electrically compatible with an active-low
"reset" pin. If we use the logical value here, then we would need more
logic to know when the logical polarity has to be reversed.

Note that this doesn't work for components that are electrically
incompatible. But in that case a lot more board dependent code would be
needed anyway.


ChenYu


^ permalink raw reply	[flat|nested] 37+ messages in thread

* Re: [PATCH v7 08/10] i2c: of-prober: Add GPIO support to simple helpers
  2024-09-17 12:41     ` Chen-Yu Tsai
@ 2024-09-23 19:11       ` Doug Anderson
  0 siblings, 0 replies; 37+ messages in thread
From: Doug Anderson @ 2024-09-23 19:11 UTC (permalink / raw)
  To: Chen-Yu Tsai
  Cc: Rob Herring, Saravana Kannan, Matthias Brugger,
	AngeloGioacchino Del Regno, Wolfram Sang, Benson Leung,
	Tzung-Bi Shih, Mark Brown, Liam Girdwood, chrome-platform,
	devicetree, linux-arm-kernel, linux-mediatek, linux-kernel,
	Johan Hovold, Jiri Kosina, Andy Shevchenko, linux-i2c

Hi,

On Tue, Sep 17, 2024 at 5:41 AM Chen-Yu Tsai <wenst@chromium.org> wrote:
>
> > > +static void i2c_of_probe_simple_disable_gpio(struct device *dev, struct i2c_of_probe_simple_ctx *ctx)
> > > +{
> > > +       if (!ctx->gpiod)
> > > +               return;
> > > +
> > > +       dev_dbg(dev, "Setting GPIO to input\n");
> > > +
> > > +       gpiod_direction_input(ctx->gpiod);
> >
> > This is weird. Why set it to input?
>
> It seemed to me this would be more like the initial state, without knowing
> the actual initial state.

In this case, though, you're trying to turn off the resource, not
trying to get back to the initial state. IMO deasserting the GPIO is
the way to do this. If the output needs to make it an input in this
case then it can use some type of open drain mode.


> > I would also say: given that you're providing a parameter anyway and
> > you're giving the GPIO name, can you please move away from the "raw"
> > values and move to "logical" values?
>
> I disagree. When hardware engineers design for swappable components, they
> likely look at the electrical compatibility of them. In this case, an
> active-high "enable" pin is electrically compatible with an active-low
> "reset" pin. If we use the logical value here, then we would need more
> logic to know when the logical polarity has to be reversed.
>
> Note that this doesn't work for components that are electrically
> incompatible. But in that case a lot more board dependent code would be
> needed anyway.

As we talked about in person, that made sense in the previous version
of the patch where you were looking for all GPIOs willy-nilly. Now
you'll be specifically asking for a GPIO by name and we should honor
the "active high" or "active low" nature of it.

-Doug


^ permalink raw reply	[flat|nested] 37+ messages in thread

end of thread, other threads:[~2024-09-23 19:13 UTC | newest]

Thread overview: 37+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2024-09-11  7:27 [PATCH v7 00/10] platform/chrome: Introduce DT hardware prober Chen-Yu Tsai
2024-09-11  7:27 ` [PATCH v7 01/10] of: dynamic: Add of_changeset_update_prop_string Chen-Yu Tsai
2024-09-11  7:27 ` [PATCH v7 02/10] of: base: Add for_each_child_of_node_with_prefix() Chen-Yu Tsai
2024-09-12 20:31   ` Rob Herring (Arm)
2024-09-11  7:27 ` [PATCH v7 03/10] regulator: Split up _regulator_get() Chen-Yu Tsai
2024-09-13 10:27   ` Andy Shevchenko
2024-09-11  7:27 ` [PATCH v7 04/10] regulator: Add of_regulator_get_optional() for pure DT regulator lookup Chen-Yu Tsai
2024-09-11  7:27 ` [PATCH v7 05/10] i2c: core: Remove extra space in Makefile Chen-Yu Tsai
2024-09-13 14:59   ` Andi Shyti
2024-09-11  7:27 ` [PATCH v7 06/10] i2c: Introduce OF component probe function Chen-Yu Tsai
2024-09-13 10:25   ` Andy Shevchenko
2024-09-15 10:44     ` Chen-Yu Tsai
2024-09-16 10:36       ` Andy Shevchenko
2024-09-16 10:55         ` Jonathan Cameron
2024-09-16 14:59         ` Chen-Yu Tsai
2024-09-16 15:22           ` Andy Shevchenko
2024-09-13 23:43   ` Doug Anderson
2024-09-15 11:32     ` Chen-Yu Tsai
2024-09-16 14:15       ` Doug Anderson
2024-09-16 14:31         ` Chen-Yu Tsai
2024-09-16 10:13     ` Andy Shevchenko
2024-09-15 10:09   ` Andrey Skvortsov
2024-09-11  7:27 ` [PATCH v7 07/10] i2c: of-prober: Add simple helpers for regulator support Chen-Yu Tsai
2024-09-13 10:46   ` Andy Shevchenko
2024-09-13 23:43   ` Doug Anderson
2024-09-11  7:27 ` [PATCH v7 08/10] i2c: of-prober: Add GPIO support to simple helpers Chen-Yu Tsai
2024-09-13 10:52   ` Andy Shevchenko
2024-09-13 23:43   ` Doug Anderson
2024-09-17 12:41     ` Chen-Yu Tsai
2024-09-23 19:11       ` Doug Anderson
2024-09-15  9:46   ` Andrey Skvortsov
2024-09-11  7:27 ` [PATCH v7 09/10] platform/chrome: Introduce device tree hardware prober Chen-Yu Tsai
2024-09-13 23:43   ` Doug Anderson
2024-09-16 14:58     ` Chen-Yu Tsai
2024-09-16 15:23       ` Andy Shevchenko
2024-09-11  7:27 ` [PATCH v7 10/10] arm64: dts: mediatek: mt8173-elm-hana: Mark touchscreens and trackpads as fail Chen-Yu Tsai
2024-09-13 18:08 ` (subset) [PATCH v7 00/10] platform/chrome: Introduce DT hardware prober Mark Brown

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).