Il 19/05/22 10:45, Chen-Yu Tsai ha scritto:
On Thu, May 19, 2022 at 4:26 PM AngeloGioacchino Del Regno
<angelogioacchino.delregno@xxxxxxxxxxxxx> wrote:
Il 19/05/22 10:15, Chen-Yu Tsai ha scritto:
On Thu, May 19, 2022 at 4:05 PM AngeloGioacchino Del Regno
<angelogioacchino.delregno@xxxxxxxxxxxxx> wrote:
Il 19/05/22 06:41, Miles Chen ha scritto:
Hi Angelo,
In order to compile the clock drivers for various MediaTek SoCs as
modules, it is necessary to export a few functions from the MediaTek
specific clocks (and reset) libraries.
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@xxxxxxxxxxxxx>
---
drivers/clk/mediatek/clk-apmixed.c | 1 +
drivers/clk/mediatek/clk-cpumux.c | 2 ++
drivers/clk/mediatek/clk-mtk.c | 2 ++
drivers/clk/mediatek/reset.c | 1 +
4 files changed, 6 insertions(+)
diff --git a/drivers/clk/mediatek/clk-apmixed.c b/drivers/clk/mediatek/clk-apmixed.c
index 6b0ab0a346e8..f126da693a7f 100644
--- a/drivers/clk/mediatek/clk-apmixed.c
+++ b/drivers/clk/mediatek/clk-apmixed.c
@@ -98,5 +98,6 @@ struct clk_hw *mtk_clk_register_ref2usb_tx(const char *name,
return &tx->hw;
}
+EXPORT_SYMBOL_GPL(mtk_clk_register_ref2usb_tx);
MODULE_LICENSE("GPL");
diff --git a/drivers/clk/mediatek/clk-cpumux.c b/drivers/clk/mediatek/clk-cpumux.c
index 2b5d48591738..25618eff6f2a 100644
--- a/drivers/clk/mediatek/clk-cpumux.c
+++ b/drivers/clk/mediatek/clk-cpumux.c
@@ -150,6 +150,7 @@ int mtk_clk_register_cpumuxes(struct device_node *node,
return PTR_ERR(hw);
}
+EXPORT_SYMBOL_GPL(mtk_clk_register_cpumuxes);
void mtk_clk_unregister_cpumuxes(const struct mtk_composite *clks, int num,
struct clk_hw_onecell_data *clk_data)
@@ -166,5 +167,6 @@ void mtk_clk_unregister_cpumuxes(const struct mtk_composite *clks, int num,
clk_data->hws[mux->id] = ERR_PTR(-ENOENT);
}
}
+EXPORT_SYMBOL_GPL(mtk_clk_unregister_cpumuxes);
MODULE_LICENSE("GPL");
diff --git a/drivers/clk/mediatek/clk-mtk.c b/drivers/clk/mediatek/clk-mtk.c
index 05a188c62119..41e60a7e8ff9 100644
--- a/drivers/clk/mediatek/clk-mtk.c
+++ b/drivers/clk/mediatek/clk-mtk.c
@@ -459,6 +459,7 @@ int mtk_clk_simple_probe(struct platform_device *pdev)
mtk_free_clk_data(clk_data);
return r;
}
+EXPORT_SYMBOL_GPL(mtk_clk_simple_probe);
int mtk_clk_simple_remove(struct platform_device *pdev)
{
@@ -472,5 +473,6 @@ int mtk_clk_simple_remove(struct platform_device *pdev)
return 0;
}
+EXPORT_SYMBOL_GPL(mtk_clk_simple_remove);
Thanks, I need this too. I am preparing a patch to use mtk_clk_simple_remove/mtk_clk_simple_probe
for MT6779 clks first and maybe I can apply this to all MediaTek clk drivers.
Reviewed-by: Miles Chen <miles.chen@xxxxxxxxxxxx>
Hello Miles,
thanks for telling me, because my next step would have been exactly what
you're doing, for all MediaTek clk drivers... otherwise we'd be doing
redundant work going afterwards.
Should we consider using symbol namespaces (EXPORT_SYMBOL_NS)?
I don't think we should... I don't know if any module in the common clock
framework is doing that, but if we want some symbol namespace separation,
we would want that "at least" on the entire MediaTek framework, right? :-)
The sunxi-ng clk driver recently started doing this. See:
http://git.kernel.org/torvalds/c/551b62b1e4cb64d3b42da0fbfdcd26a5fcd684be
That's good. And...that's one of the examples for which using "a trick" is
shorter and enhances maintainability!
And it's being done for all kinds of common driver libraries.
I agree that it would be done for the entire MediaTek framework.
In that case, we can simply keep using EXPORT_SYMBOL_GPL() and change the
Makefile in this directory to add:
ccflags-y += -DDEFAULT_SYMBOL_NAMESPACE=COMMON_CLK_MEDIATEK
Oh, I didn't know of this trick. Nice. :D
I think we still need to add MODULE_IMPORT_NS() statements, right?
I haven't experimented with the IMPORT, but I believe if that's relative to
files in the same Makefile, we won't need to add that... let's make some
experiments :-)
...but that's surely out of scope for this specific patch series.
What do you think?
It's definitely out of scope, but nice to have, to reduce the size of the
default symbol table, and limit the usage of the symbols the driver exports.
Agreed.
Regards
ChenYu
