linux-kernel - Re: [RFC PATCH 0/7] clk: mediatek: Move to struct clk

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Tue, 19 Apr 2022 17:08:16 +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>,
        Chun-Jie Chen <chun-jie.chen@...iatek.com>,
        Miles Chen <miles.chen@...iatek.com>,
        Rex-BC Chen <rex-bc.chen@...iatek.com>
Cc:     Matthias Brugger <matthias.bgg@...il.com>,
        linux-clk@...r.kernel.org, linux-mediatek@...ts.infradead.org,
        linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org
Subject: Re: [RFC PATCH 0/7] clk: mediatek: Move to struct clk_hw provider
 APIs

Il 19/04/22 10:12, Chen-Yu Tsai ha scritto:
> Hi everyone,
> 
> This is part 2 of my proposed MediaTek clk driver cleanup work [1].
> 

..snip..

> 
> The next phase of the cleanup/improvement shall be to introduce some
> variant of `struct clk_parent_data` to describe clk relationships
> efficiently.
> 
> Please have a look.
> 

Hello Chen-Yu,

I am grateful to see this series, as the MediaTek clock drivers are getting
a bit old, despite new platforms being implemented practically as we speak.

With this, you surely get that I completely agree with the proposed cleanup
and modernization of the entire MediaTek clocks infrastructure, but I think
that introducing a `struct clk_parent_data` for these drivers is, at this
point, a must, that not only fully justifies these patches, but also "makes
the point" - as the effect of that would be a performance improvement as we
would *at least* avoid lots of clk_cpy_name() in case of parent_hws, or in
case or parent_data where no .fw_name is provided (which would be the case
for most of the clocks).

That said, my advice would be to add that conversion to declaring clocks
with .hw.init.parent_data and/or .hw.init.parent_hws to this series as to
really make it complete.

Of course, if you have concerns about old platforms that you cannot test,
or for which this kind of conversion would require a huge amount of effort,
then I would go for converting as many as possible as a first step and then
leave the others for later.

I would envision MT8183, 8186, 8192, 8195 to be a good amount of first
candidates for this great effort.

Cheers,
Angelo