[PATCH 0/2] firmware: exynos-acpm: clients (PMIC, clocks, etc.) will become children

[PATCH 0/2] firmware: exynos-acpm: clients (PMIC, clocks, etc.) will become children

[André Draszik]

ACPM clients (PMIC, clocks, etc.) will be modeled as children of the
ACPM interface.

This necessitates two changes in this driver:
* child platform_devices from device tree need to be populated here
* child drivers will need to be able to get the ACPM handle via a
  struct device_node, not via a DT property name

This series implements these changes and is a prerequisite for v2 of
https://lore.kernel.org/all/20250323-s2mpg10-v1-0-d08943702707@linaro.org/

--- dependency note ---

To apply cleanly, patch 2 must be applied after
https://lore.kernel.org/all/20250319-acpm-fixes-v2-2-ac2c1bcf322b@linaro.org/
due to touching similar areas of the code.

I can merge that and this series into one if that is preferred instead,
please let me know if so.

--- dependency note end ---

Cheers,
Andre'

Signed-off-by: André Draszik <andre.draszik@linaro.org>
---
André Draszik (1):
      firmware: exynos-acpm: introduce devm_acpm_get_by_node()

Tudor Ambarus (1):
      firmware: exynos-acpm: populate devices from device tree data

 drivers/firmware/samsung/exynos-acpm.c             | 25 +++++++++-------------
 .../linux/firmware/samsung/exynos-acpm-protocol.h  |  6 ++++--
 2 files changed, 14 insertions(+), 17 deletions(-)
---
base-commit: cc024fd4c6640be5e2e0989cc98f2c68e31289d5
change-id: 20250327-acpm-children-70ceb0138d63

Best regards,
-- 
André Draszik <andre.draszik@linaro.org>

[PATCH 1/2] firmware: exynos-acpm: populate devices from device tree data

[André Draszik]

From: Tudor Ambarus <tudor.ambarus@linaro.org>

ACPM clients (PMIC, clocks, etc.) will be modeled as children of the
ACPM interface. Populate children platform_devices from device tree.

Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org>
Signed-off-by: André Draszik <andre.draszik@linaro.org>
---
 drivers/firmware/samsung/exynos-acpm.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/firmware/samsung/exynos-acpm.c b/drivers/firmware/samsung/exynos-acpm.c
index 04c73692383b17ace33e95ce9534101bc68f089e..7873cdda127e4f1b6b2febccd054ba27aeaf9b28 100644
--- a/drivers/firmware/samsung/exynos-acpm.c
+++ b/drivers/firmware/samsung/exynos-acpm.c
@@ -633,7 +633,7 @@ static int acpm_probe(struct platform_device *pdev)
 
 	platform_set_drvdata(pdev, acpm);
 
-	return 0;
+	return devm_of_platform_populate(dev);
 }
 
 /**

-- 
2.49.0.472.ge94155a9ec-goog

[PATCH 2/2] firmware: exynos-acpm: introduce devm_acpm_get_by_node()

[André Draszik]

To allow ACPM clients to simply be children of the ACPM node in DT,
they need to be able to get the ACPM handle based on that ACPM node
directly.

Add an API to allow them to do so, devm_acpm_get_by_node().

At the same time, the previous approach of acquiring the ACPM handle
via a DT phandle is now obsolete and we can remove
devm_acpm_get_by_phandle(), which was there to facilitate that. There
are no existing or anticipated upcoming users of that API, because all
clients should be children of the ACPM node going forward.

Note that no DTs have been merged that use the old approach, so doing
this API change in this driver now will not affect any existing DTs or
client drivers.

Signed-off-by: André Draszik <andre.draszik@linaro.org>

---
devm_acpm_get_by_node it is being exported to modules in this commit,
because there will be an immediate user of this API as of v2 of
https://lore.kernel.org/all/20250323-s2mpg10-v1-0-d08943702707@linaro.org/
---
 drivers/firmware/samsung/exynos-acpm.c             | 23 +++++++++-------------
 .../linux/firmware/samsung/exynos-acpm-protocol.h  |  6 ++++--
 2 files changed, 13 insertions(+), 16 deletions(-)

diff --git a/drivers/firmware/samsung/exynos-acpm.c b/drivers/firmware/samsung/exynos-acpm.c
index 7873cdda127e4f1b6b2febccd054ba27aeaf9b28..74f0ed9b5c0f73393932c46ab6341716745a0df4 100644
--- a/drivers/firmware/samsung/exynos-acpm.c
+++ b/drivers/firmware/samsung/exynos-acpm.c
@@ -667,20 +667,14 @@ static void devm_acpm_release(struct device *dev, void *res)
  *
  * Return: pointer to handle on success, ERR_PTR(-errno) otherwise.
  */
-static const struct acpm_handle *acpm_get_by_phandle(struct device *dev,
-						     const char *property)
+static const struct acpm_handle *acpm_get_by_node(struct device *dev,
+						  struct device_node *acpm_np)
 {
 	struct platform_device *pdev;
-	struct device_node *acpm_np;
 	struct device_link *link;
 	struct acpm_info *acpm;
 
-	acpm_np = of_parse_phandle(dev->of_node, property, 0);
-	if (!acpm_np)
-		return ERR_PTR(-ENODEV);
-
 	pdev = of_find_device_by_node(acpm_np);
-	of_node_put(acpm_np);
 	if (!pdev)
 		return ERR_PTR(-EPROBE_DEFER);
 
@@ -709,14 +703,14 @@ static const struct acpm_handle *acpm_get_by_phandle(struct device *dev,
 }
 
 /**
- * devm_acpm_get_by_phandle() - managed get handle using phandle.
- * @dev:        device pointer requesting ACPM handle.
- * @property:   property name containing phandle on ACPM node.
+ * devm_acpm_get_by_node() - managed get handle using node pointer.
+ * @dev: device pointer requesting ACPM handle.
+ * @np:  ACPM device tree node.
  *
  * Return: pointer to handle on success, ERR_PTR(-errno) otherwise.
  */
-const struct acpm_handle *devm_acpm_get_by_phandle(struct device *dev,
-						   const char *property)
+const struct acpm_handle *devm_acpm_get_by_node(struct device *dev,
+						struct device_node *np)
 {
 	const struct acpm_handle **ptr, *handle;
 
@@ -724,7 +718,7 @@ const struct acpm_handle *devm_acpm_get_by_phandle(struct device *dev,
 	if (!ptr)
 		return ERR_PTR(-ENOMEM);
 
-	handle = acpm_get_by_phandle(dev, property);
+	handle = acpm_get_by_node(dev, np);
 	if (!IS_ERR(handle)) {
 		*ptr = handle;
 		devres_add(dev, ptr);
@@ -734,6 +728,7 @@ const struct acpm_handle *devm_acpm_get_by_phandle(struct device *dev,
 
 	return handle;
 }
+EXPORT_SYMBOL_GPL(devm_acpm_get_by_node);
 
 static const struct acpm_match_data acpm_gs101 = {
 	.initdata_base = ACPM_GS101_INITDATA_BASE,
diff --git a/include/linux/firmware/samsung/exynos-acpm-protocol.h b/include/linux/firmware/samsung/exynos-acpm-protocol.h
index 76255b5d06b1228bb8579d32aaa478036a5c344e..f628bf1862c25fa018a2fe5e7e123bf05c5254b9 100644
--- a/include/linux/firmware/samsung/exynos-acpm-protocol.h
+++ b/include/linux/firmware/samsung/exynos-acpm-protocol.h
@@ -11,6 +11,7 @@
 #include <linux/types.h>
 
 struct acpm_handle;
+struct device_node;
 
 struct acpm_pmic_ops {
 	int (*read_reg)(const struct acpm_handle *handle,
@@ -44,6 +45,7 @@ struct acpm_handle {
 
 struct device;
 
-const struct acpm_handle *devm_acpm_get_by_phandle(struct device *dev,
-						   const char *property);
+const struct acpm_handle *devm_acpm_get_by_node(struct device *dev,
+						struct device_node *np);
+
 #endif /* __EXYNOS_ACPM_PROTOCOL_H */

-- 
2.49.0.472.ge94155a9ec-goog

Re: [PATCH 0/2] firmware: exynos-acpm: clients (PMIC, clocks, etc.) will become children

[Krzysztof Kozlowski]

On Thu, 27 Mar 2025 12:54:26 +0000, André Draszik wrote:
> ACPM clients (PMIC, clocks, etc.) will be modeled as children of the
> ACPM interface.
> 
> This necessitates two changes in this driver:
> * child platform_devices from device tree need to be populated here
> * child drivers will need to be able to get the ACPM handle via a
>   struct device_node, not via a DT property name
> 
> [...]

Applied, thanks!

[1/2] firmware: exynos-acpm: populate devices from device tree data
      https://git.kernel.org/krzk/linux/c/636baba9489a634c956d6f02076af6bc1725c132
[2/2] firmware: exynos-acpm: introduce devm_acpm_get_by_node()
      https://git.kernel.org/krzk/linux/c/a8dc26a0ec43fd416ca781a8030807e65f71cfc5

Best regards,
-- 
Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>

Re: [PATCH 0/2] firmware: exynos-acpm: clients (PMIC, clocks, etc.) will become children

[Lee Jones]

On Tue, 22 Apr 2025, Krzysztof Kozlowski wrote:

> 
> On Thu, 27 Mar 2025 12:54:26 +0000, André Draszik wrote:
> > ACPM clients (PMIC, clocks, etc.) will be modeled as children of the
> > ACPM interface.
> > 
> > This necessitates two changes in this driver:
> > * child platform_devices from device tree need to be populated here
> > * child drivers will need to be able to get the ACPM handle via a
> >   struct device_node, not via a DT property name
> > 
> > [...]
> 
> Applied, thanks!
> 
> [1/2] firmware: exynos-acpm: populate devices from device tree data
>       https://git.kernel.org/krzk/linux/c/636baba9489a634c956d6f02076af6bc1725c132
> [2/2] firmware: exynos-acpm: introduce devm_acpm_get_by_node()
>       https://git.kernel.org/krzk/linux/c/a8dc26a0ec43fd416ca781a8030807e65f71cfc5

Can this be made available for other subsystems to pull from please?

Without it MFD is currently broken.

Ref: https://lore.kernel.org/all/fd11ee67a3d51aef6305c477b140d911da0b2af4.camel@linaro.org/

-- 
Lee Jones [李琼斯]

Re: [PATCH 0/2] firmware: exynos-acpm: clients (PMIC, clocks, etc.) will become children

[Krzysztof Kozlowski]

On 01/05/2025 11:09, Lee Jones wrote:
> On Tue, 22 Apr 2025, Krzysztof Kozlowski wrote:
> 
>>
>> On Thu, 27 Mar 2025 12:54:26 +0000, André Draszik wrote:
>>> ACPM clients (PMIC, clocks, etc.) will be modeled as children of the
>>> ACPM interface.
>>>
>>> This necessitates two changes in this driver:
>>> * child platform_devices from device tree need to be populated here
>>> * child drivers will need to be able to get the ACPM handle via a
>>>   struct device_node, not via a DT property name
>>>
>>> [...]
>>
>> Applied, thanks!
>>
>> [1/2] firmware: exynos-acpm: populate devices from device tree data
>>       https://git.kernel.org/krzk/linux/c/636baba9489a634c956d6f02076af6bc1725c132
>> [2/2] firmware: exynos-acpm: introduce devm_acpm_get_by_node()
>>       https://git.kernel.org/krzk/linux/c/a8dc26a0ec43fd416ca781a8030807e65f71cfc5
> 
> Can this be made available for other subsystems to pull from please?
> 
> Without it MFD is currently broken.
> 
> Ref: https://lore.kernel.org/all/fd11ee67a3d51aef6305c477b140d911da0b2af4.camel@linaro.org/
> 

Yeah, I will prepare you a stable tag.

While this wasn't clearly expressed when sending the patch? There is
some "prerequisite" note in cover letter but what does that mean? What
does the contributor expect from maintainers?


Best regards,
Krzysztof