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]

Message-ID: <0a1618c4-b808-56bd-e89f-560b0423191d@collabora.com>
Date:   Tue, 27 Sep 2022 12:39:41 +0200
From:   AngeloGioacchino Del Regno 
        <angelogioacchino.delregno@...labora.com>
To:     Chen-Yu Tsai <wenst@...omium.org>,
        Michael Turquette <mturquette@...libre.com>,
        Stephen Boyd <sboyd@...nel.org>
Cc:     Matthias Brugger <matthias.bgg@...il.com>,
        Miles Chen <miles.chen@...iatek.com>,
        linux-clk@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
        linux-mediatek@...ts.infradead.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 3/6] clk: mediatek: mt8192: Do not re-register
 top_early_divs in probe function

Il 26/09/22 12:25, Chen-Yu Tsai ha scritto:
> 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".

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