lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Thu, 19 May 2022 10:53:29 +0200
From:   AngeloGioacchino Del Regno 
        <angelogioacchino.delregno@...labora.com>
To:     Chen-Yu Tsai <wenst@...omium.org>
Cc:     Miles Chen <miles.chen@...iatek.com>, bgolaszewski@...libre.com,
        chun-jie.chen@...iatek.com, ck.hu@...iatek.com,
        devicetree@...r.kernel.org, fparent@...libre.com,
        ikjn@...omium.org, jason-jh.lin@...iatek.com, kernel@...labora.com,
        konrad.dybcio@...ainline.org, krzysztof.kozlowski+dt@...aro.org,
        linux-arm-kernel@...ts.infradead.org, linux-clk@...r.kernel.org,
        linux-kernel@...r.kernel.org, linux-mediatek@...ts.infradead.org,
        marijn.suijten@...ainline.org, martin.botka@...ainline.org,
        matthias.bgg@...il.com, mturquette@...libre.com,
        p.zabel@...gutronix.de, paul.bouchara@...ainline.org,
        phone-devel@...r.kernel.org, rex-bc.chen@...iatek.com,
        robh+dt@...nel.org, sam.shih@...iatek.com, sboyd@...nel.org,
        tinghan.shen@...iatek.com, weiyi.lu@...iatek.com,
        y.oudjana@...tonmail.com, ~postmarketos/upstreaming@...ts.sr.ht
Subject: Re: [PATCH v2 6/7] clk: mediatek: Export required symbols to compile
 clk drivers as module

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@...labora.com> 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@...labora.com> 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@...labora.com>
>>>>>> ---
>>>>>> 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@...iatek.com>
>>>>
>>>> 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



Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ