* [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