linux-kernel - Re: [PATCH v3] reset: mediatek: Move mediatek system clock reset to reset folder

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: <20220930185953.41810C433C1@smtp.kernel.org>
Date:   Fri, 30 Sep 2022 11:59:51 -0700
From:   Stephen Boyd <sboyd@...nel.org>
To:     AngeloGioacchino Del Regno 
        <angelogioacchino.delregno@...labora.com>,
        Bo-Chen Chen <rex-bc.chen@...iatek.com>,
        matthias.bgg@...il.com, mturquette@...libre.com,
        p.zabel@...gutronix.de
Cc:     runyang.chen@...iatek.com, miles.chen@...iatek.com,
        wenst@...omium.org, nfraprado@...labora.com,
        linux-kernel@...r.kernel.org, linux-clk@...r.kernel.org,
        linux-arm-kernel@...ts.infradead.org,
        linux-mediatek@...ts.infradead.org,
        Project_Global_Chrome_Upstream_Group@...iatek.com
Subject: Re: [PATCH v3] reset: mediatek: Move mediatek system clock reset to reset folder

Quoting AngeloGioacchino Del Regno (2022-09-29 05:50:38)
> I've just analyzed this idea a bit more, and there's the outcome.
> 
> This driver would be fine, if some MediaTek SoCs weren't shipped with
> a bootloader that supports only very small kernels... because then, if
> the reset controller is not available at boot time, it's unlikely that
> you can probe the eMMC or the uSD, so it won't be possible to actually
> compile this driver as a module and load it afterwards.
> 
> Please don't misunderstand me: I like the idea of having the MediaTek
> SoC sysclk reset controller as a ... reset controller driver but, to
> make that work, one fundamental issue must be solved...
> 
> If the kernel is configured for, let's say, MT2701 and MT2712, we're
> always building in reset controller support for MT7622, 7629, 8135, 8173,
> 8183, 8186, 8192, 8195 - and this list will grow with MT8188, and others.
> 
> Obviously, it's useless to have support for, say, MT7622, if the MT7622
> system clock controllers aren't built-in, nor modules.
> 
> So, to make this idea to work, we have to find a way to:
> 1. Build in support only for the required SoC(s)

Use Kconfig

> 2. Put the reset index mapping arrays in SoC-specific files, or this
>     single file driver will see an exponential growth.

Split the reset driver into different files compiled for different SoCs
based on the SoC Kconfig made in step 1.

> 
> Wrapping it up - as the driver is right now - we're losing flexibility:
> we need to maintain the current flexibility while keeping the improvements
> that are made with this proposal.
> 
> Ideas?
> 

It should work and your concerns are alleviated?