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 <[email protected]> > >>> --- > >>> 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
signature.asc
Description: PGP signature
