public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
* [PATCH 0/2] Improvements to the recent clock rework by marex.
@ 2026-01-15  3:11 chiffathefox
  2026-01-15  3:11 ` [PATCH 1/2] clk: clk_resolve_parent_clk(): resolve external clocks by id chiffathefox
  2026-01-15  3:11 ` [PATCH 2/2] clk: exynos: do not reparent requested clock chiffathefox
  0 siblings, 2 replies; 6+ messages in thread
From: chiffathefox @ 2026-01-15  3:11 UTC (permalink / raw)
  To: Marek Vasut
  Cc: chiffathefox, Andrew Goodbody, Christian Marangi,
	Kaustabh Chakraborty, Lukasz Majewski, Maksim Kiselev,
	Minkyu Kang, Miquel Raynal, Patrice Chotard, Patrick Delaunay,
	Sam Protsenko, Tom Rini, Ye Li, u-boot

Symptoms:
I ran into an issue with the generic ccf_clk_divider clock driver. ccf_clk_divider assumes that the pointer passed to clk_divider_recalc_rate() (https://github.com/u-boot/u-boot/blob/master/drivers/clk/clk-divider.c#L80) is the same that was kzalloc()'d during clock registration. This assumption was breaking when calling clk_get_rate() on a clock retrieved via clk_get_by_index(), since clk_get_by_index() returns a copy of `struct clk` rather than the original pointer. For example, in https://github.com/u-boot/u-boot/blob/master/drivers/serial/serial_s5p.c#L131 the serial driver retrieves a clock using clk_get_by_index(), and then indirectly passes a pointer to stack-allocated `struct clk` to clk_divider_recalc_rate(), which breaks the ccf_clk_divider driver.

Description:
The Clock API relies on the fact that you call it's functions with a pointer to the
kzalloc()'d `struct clk`, and not a copy of it. To ensure this, existing
clock drivers use ccf_clk_get_rate() and clk_get_by_id().
The clock rework path missed this fact, and instead was returning names
and pointers for the root device.

Testing:
I tested this on Samsung S10 (exynos9820 SoC) with a custom clock driver
and a device tree. Unfortunately, I don't own any other exynos devices
supported by u-boot.


chiffathefox (2):
  clk: clk_resolve_parent_clk(): resolve external clocks by id
  clk: exynos: do not reparent requested clock

 drivers/clk/clk-uclass.c | 7 ++++++-
 drivers/clk/exynos/clk.c | 1 -
 2 files changed, 6 insertions(+), 2 deletions(-)

-- 
2.34.1

base-commit: d503633a36767d756c7de28305cf0de79440cbc0
branch: clk-rework-improvements

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

* [PATCH 1/2] clk: clk_resolve_parent_clk(): resolve external clocks by id
  2026-01-15  3:11 [PATCH 0/2] Improvements to the recent clock rework by marex chiffathefox
@ 2026-01-15  3:11 ` chiffathefox
  2026-01-17  1:38   ` Marek Vasut
  2026-01-19 16:59   ` Kaustabh Chakraborty
  2026-01-15  3:11 ` [PATCH 2/2] clk: exynos: do not reparent requested clock chiffathefox
  1 sibling, 2 replies; 6+ messages in thread
From: chiffathefox @ 2026-01-15  3:11 UTC (permalink / raw)
  To: Marek Vasut
  Cc: chiffathefox, Andrew Goodbody, Christian Marangi,
	Kaustabh Chakraborty, Lukasz Majewski, Maksim Kiselev,
	Miquel Raynal, Patrice Chotard, Patrick Delaunay, Tom Rini, Ye Li,
	u-boot

When referencing clocks in DTS registered by another driver,
clk_resolve_parent_clk() is supposed to return the name
of the child device that provides the requested clock.
However, in reality, it returns the name of the parent DTB
node (e.g. clock-controller@1a240000). Such devices, for
instance the exynos7870-cmu-peri driver, do not store any
clock information in their dev->uclass_priv_ because they
expect you to call dev->ops->get_rate with the appropriate
clk->id. So when you try to resolve a clock that depends on
an externally referenced clock, the resolution fails on the
parent clock because it doesn't have a  dev->uclass_priv_.
With this change clk_resolve_parent_clk() will take an
extra step to actually resolve the child device.

Signed-off-by: chiffathefox <chiffathefoxx@gmail.com>
---

 drivers/clk/clk-uclass.c | 7 ++++++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/drivers/clk/clk-uclass.c b/drivers/clk/clk-uclass.c
index 0584429bed6..bea45fc396f 100644
--- a/drivers/clk/clk-uclass.c
+++ b/drivers/clk/clk-uclass.c
@@ -430,6 +430,7 @@ clk_resolve_parent_clk(struct udevice *dev, const char *name)
 {
 	struct udevice *parent;
 	struct clk clk;
+	struct clk *c;
 	int ret;
 
 	ret = uclass_get_device_by_name(UCLASS_CLK, name, &parent);
@@ -440,7 +441,11 @@ clk_resolve_parent_clk(struct udevice *dev, const char *name)
 	if (!clk.dev)
 		return name;
 
-	return clk.dev->name;
+	ret = clk_get_by_id(clk.id, &c);
+	if (ret)
+		return name;
+
+	return c->dev->name;
 }
 
 int clk_release_all(struct clk *clk, unsigned int count)
-- 
2.34.1


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

* [PATCH 2/2] clk: exynos: do not reparent requested clock
  2026-01-15  3:11 [PATCH 0/2] Improvements to the recent clock rework by marex chiffathefox
  2026-01-15  3:11 ` [PATCH 1/2] clk: clk_resolve_parent_clk(): resolve external clocks by id chiffathefox
@ 2026-01-15  3:11 ` chiffathefox
  2026-01-19 17:00   ` Kaustabh Chakraborty
  1 sibling, 1 reply; 6+ messages in thread
From: chiffathefox @ 2026-01-15  3:11 UTC (permalink / raw)
  To: Marek Vasut
  Cc: chiffathefox, Kaustabh Chakraborty, Lukasz Majewski, Minkyu Kang,
	Sam Protsenko, Tom Rini, u-boot

It would appear the original developer of this driver
reparented child clock devices to fix the issue described in
`clk: clk_resolve_parent_clk(): resolve external clocks by id`.
This hacky fix was the cause of invalid memory access when calling
clk_get_rate() on a clock retrieved via clk_get_by_index().
clk_get_by_index() returns a copy of the `struct clk` and
when passed to clk_get_rate() it may be forwarded to
clk_divider_recalc_rate(), which will cause the latter to
run container_of() on a pointer from caller's stack instead
of the pointer that was kzalloc()'d by the clk-divider driver.

Signed-off-by: chiffathefox <chiffathefoxx@gmail.com>
---

 drivers/clk/exynos/clk.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/clk/exynos/clk.c b/drivers/clk/exynos/clk.c
index a2c9f4851da..aa4d4112db7 100644
--- a/drivers/clk/exynos/clk.c
+++ b/drivers/clk/exynos/clk.c
@@ -19,7 +19,6 @@ int samsung_clk_request(struct clk *clk)
 	if (ret)
 		return ret;
 
-	clk->dev = c->dev;
 	return 0;
 }
 
-- 
2.34.1


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

* Re: [PATCH 1/2] clk: clk_resolve_parent_clk(): resolve external clocks by id
  2026-01-15  3:11 ` [PATCH 1/2] clk: clk_resolve_parent_clk(): resolve external clocks by id chiffathefox
@ 2026-01-17  1:38   ` Marek Vasut
  2026-01-19 16:59   ` Kaustabh Chakraborty
  1 sibling, 0 replies; 6+ messages in thread
From: Marek Vasut @ 2026-01-17  1:38 UTC (permalink / raw)
  To: chiffathefox, Peng Fan, Patrice CHOTARD
  Cc: Andrew Goodbody, Christian Marangi, Kaustabh Chakraborty,
	Lukasz Majewski, Maksim Kiselev, Miquel Raynal, Patrice Chotard,
	Patrick Delaunay, Tom Rini, Ye Li, u-boot

On 1/15/26 4:11 AM, chiffathefox wrote:
> When referencing clocks in DTS registered by another driver,
> clk_resolve_parent_clk() is supposed to return the name
> of the child device that provides the requested clock.
> However, in reality, it returns the name of the parent DTB
> node (e.g. clock-controller@1a240000). Such devices, for
> instance the exynos7870-cmu-peri driver, do not store any
> clock information in their dev->uclass_priv_ because they
> expect you to call dev->ops->get_rate with the appropriate
> clk->id. So when you try to resolve a clock that depends on
> an externally referenced clock, the resolution fails on the
> parent clock because it doesn't have a  dev->uclass_priv_.
> With this change clk_resolve_parent_clk() will take an
> extra step to actually resolve the child device.
> 
> Signed-off-by: chiffathefox <chiffathefoxx@gmail.com>
> ---
> 
>   drivers/clk/clk-uclass.c | 7 ++++++-
>   1 file changed, 6 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/clk/clk-uclass.c b/drivers/clk/clk-uclass.c
> index 0584429bed6..bea45fc396f 100644
> --- a/drivers/clk/clk-uclass.c
> +++ b/drivers/clk/clk-uclass.c
> @@ -430,6 +430,7 @@ clk_resolve_parent_clk(struct udevice *dev, const char *name)
>   {
>   	struct udevice *parent;
>   	struct clk clk;
> +	struct clk *c;
>   	int ret;
>   
>   	ret = uclass_get_device_by_name(UCLASS_CLK, name, &parent);
> @@ -440,7 +441,11 @@ clk_resolve_parent_clk(struct udevice *dev, const char *name)
>   	if (!clk.dev)
>   		return name;
>   
> -	return clk.dev->name;
> +	ret = clk_get_by_id(clk.id, &c);
> +	if (ret)
> +		return name;
> +
> +	return c->dev->name;
>   }
>   
>   int clk_release_all(struct clk *clk, unsigned int count)

The issue description looks very similar to what this commit fixes:

0e9055b1488f ("clk: scmi: Fix priv initialization in scmi_clk_gate()")

Is this related ?

Can you share an example / test which triggers the problem ? (ideally, 
use sandbox or sandbox64, that would make it reproducible for others too)

Thank you

+CC Peng/Patrice.

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

* Re: [PATCH 1/2] clk: clk_resolve_parent_clk(): resolve external clocks by id
  2026-01-15  3:11 ` [PATCH 1/2] clk: clk_resolve_parent_clk(): resolve external clocks by id chiffathefox
  2026-01-17  1:38   ` Marek Vasut
@ 2026-01-19 16:59   ` Kaustabh Chakraborty
  1 sibling, 0 replies; 6+ messages in thread
From: Kaustabh Chakraborty @ 2026-01-19 16:59 UTC (permalink / raw)
  To: chiffathefox, Marek Vasut
  Cc: Andrew Goodbody, Christian Marangi, Kaustabh Chakraborty,
	Lukasz Majewski, Maksim Kiselev, Miquel Raynal, Patrice Chotard,
	Patrick Delaunay, Tom Rini, Ye Li, u-boot

On 2026-01-15 05:11 +02:00, chiffathefox wrote:
> When referencing clocks in DTS registered by another driver,
> clk_resolve_parent_clk() is supposed to return the name
> of the child device that provides the requested clock.
> However, in reality, it returns the name of the parent DTB
> node (e.g. clock-controller@1a240000). Such devices, for
> instance the exynos7870-cmu-peri driver, do not store any
> clock information in their dev->uclass_priv_ because they
> expect you to call dev->ops->get_rate with the appropriate
> clk->id. So when you try to resolve a clock that depends on
> an externally referenced clock, the resolution fails on the
> parent clock because it doesn't have a  dev->uclass_priv_.
> With this change clk_resolve_parent_clk() will take an
> extra step to actually resolve the child device.
>
> Signed-off-by: chiffathefox <chiffathefoxx@gmail.com>

Tested-by: Kaustabh Chakraborty <kauschluss@disroot.org> # exynos-mobile/exynos7870

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

* Re: [PATCH 2/2] clk: exynos: do not reparent requested clock
  2026-01-15  3:11 ` [PATCH 2/2] clk: exynos: do not reparent requested clock chiffathefox
@ 2026-01-19 17:00   ` Kaustabh Chakraborty
  0 siblings, 0 replies; 6+ messages in thread
From: Kaustabh Chakraborty @ 2026-01-19 17:00 UTC (permalink / raw)
  To: chiffathefox, Marek Vasut
  Cc: Kaustabh Chakraborty, Lukasz Majewski, Minkyu Kang, Sam Protsenko,
	Tom Rini, u-boot

On 2026-01-15 05:11 +02:00, chiffathefox wrote:
> It would appear the original developer of this driver
> reparented child clock devices to fix the issue described in
> `clk: clk_resolve_parent_clk(): resolve external clocks by id`.
> This hacky fix was the cause of invalid memory access when calling
> clk_get_rate() on a clock retrieved via clk_get_by_index().
> clk_get_by_index() returns a copy of the `struct clk` and
> when passed to clk_get_rate() it may be forwarded to
> clk_divider_recalc_rate(), which will cause the latter to
> run container_of() on a pointer from caller's stack instead
> of the pointer that was kzalloc()'d by the clk-divider driver.
>
> Signed-off-by: chiffathefox <chiffathefoxx@gmail.com>

Tested-by: Kaustabh Chakraborty <kauschluss@disroot.org> # exynos-mobile/exynos7870

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

end of thread, other threads:[~2026-01-19 17:03 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2026-01-15  3:11 [PATCH 0/2] Improvements to the recent clock rework by marex chiffathefox
2026-01-15  3:11 ` [PATCH 1/2] clk: clk_resolve_parent_clk(): resolve external clocks by id chiffathefox
2026-01-17  1:38   ` Marek Vasut
2026-01-19 16:59   ` Kaustabh Chakraborty
2026-01-15  3:11 ` [PATCH 2/2] clk: exynos: do not reparent requested clock chiffathefox
2026-01-19 17:00   ` Kaustabh Chakraborty

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox