linux-kernel - Re: [PATCH 3/6] clk: mediatek: mt8192: Do not re-register top_early

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:   Wed, 28 Sep 2022 09:55:07 +0800
From:   Miles Chen <miles.chen@...iatek.com>
To:     <angelogioacchino.delregno@...labora.com>
CC:     <linux-arm-kernel@...ts.infradead.org>,
        <linux-clk@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
        <linux-mediatek@...ts.infradead.org>, <matthias.bgg@...il.com>,
        <miles.chen@...iatek.com>, <mturquette@...libre.com>,
        <sboyd@...nel.org>, <wenst@...omium.org>
Subject: Re: [PATCH 3/6] clk: mediatek: mt8192: Do not re-register top_early_divs in probe function

>> top_early_divs are registered in the CLK_OF_DECLARE_DRIVER() half of the
>> topckgen clk driver. Don't try to register it again in the actual probe
>> function. This gets rid of the "Trying to register duplicate clock ..."
>> warning.
>> 
>> Signed-off-by: Chen-Yu Tsai <wenst@...omium.org>
>
>Can't we simply remove the CLK_OF_DECLARE_DRIVER() and top_init_early entirely,
>and transfer TOP_CSW_F26M_D2 to top_divs[] instead?
>I get that systimer concern and we have something similar in MT8195, where the
>TOP_CLK26M_D2 is registered "late".

Another reason for this:
Removing the CLK_OF_DECLARE_DRIVER() is good when we want to build our driver as
kernel modules because it does not work with kernel modules.

thanks,
Miles
>
>Getting back to MT8192, TOP_CSW_F26M_D2 seems to be used only for:
>1. systimer
>2. SPMI MST (registered "late").
>
>Being it a fixed factor clock, parented to another fixed clock, it doesn't
>even have any ON/OFF switch, so I think it would be actually possible to go
>for the proposed removal... which would further improve this cleanup.
>
>Regards,
>Angelo
>