[PATCH v3 1/6] clk: mediatek: mt8189: add some VLP clocks

[Tom Rini]

On Mon, Mar 23, 2026 at 03:59:09PM -0500, David Lechner wrote:
> On 3/23/26 3:33 PM, Tom Rini wrote:
> > On Mon, Mar 23, 2026 at 02:23:58PM -0600, Tom Rini wrote:
> >> On Mon, Mar 23, 2026 at 03:16:52PM -0500, David Lechner wrote:
> >>
> >>> Add some VLP clocks needed by the PMIC on MT8189 and similar SoCs.
> >>>
> >>> Signed-off-by: David Lechner <dlechner at baylibre.com>
> >>> ---
> >>>  drivers/clk/mediatek/clk-mt8189.c | 289 ++++++++++++++++++++++++++++++++++++++
> >>>  1 file changed, 289 insertions(+)
> >>
> >> I'm working on a series now to fix this globally, and it's not a
> >> MediaTek only problem, but:
> >>
> >>> @@ -1733,6 +2012,16 @@ U_BOOT_DRIVER(mtk_clk_topckgen) = {
> >>>  	.flags = DM_FLAG_PRE_RELOC,
> >>>  };
> >>>  
> >>> +U_BOOT_DRIVER(mtk_clk_vlpckgen) = {
> >>
> >> This is a bad name to use. I bet in other parts of the series you re-use
> >> it. These names need to be unique within a binary, and while today they
> >> will be I bet (since all the other examples are fine), someday we'd like
> >> to be able to compile test (and so static analyize) more code, and it
> >> will clash and fail to link. A better one would be
> >> "mt8189_clk_vlpckgen".
> > 
> > Ugh, and I just hit the build problem where I see these re-used names
> > are important. So, thinking about things harder now.
> > 
> 
> I assume you are referring to the use in mtk_find_parent_rate() and
> a few of the mtk_common_clk_*_init() functions.

Yes, exactly.

> FYI, I would like to get away from that usage eventually. It seems
> pretty fragile. And now you've give another reason to motivate that
> change as well. I have so many other MediaTek clock refactor patches
> that I'm juggling right now, it will take a while to get around to it
> though.
> 
> As it happens, mtk_clk_vlpckgen is actually globally unique, so I will
> just keep it to be consistent for now and work towards unique naming
> for all of the MediaTek clocks later.

Sounds good. I do feel like given a lot of the feedback over the last
6-9 months around clock stuff means we need to take a harder look at how
we're doing things today and there's some foundational / structural
issues that need to be addressed.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20260323/b339d34b/attachment.sig>