Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Message-ID: <26ca8837-6cdd-2523-014d-8651ba48862a@collabora.com>
Date:   Mon, 3 Oct 2022 13:28:53 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.2.0
Subject: Re: [PATCH v3] reset: mediatek: Move mediatek system clock reset to
 reset folder
To:     Stephen Boyd <sboyd@kernel.org>,
        Bo-Chen Chen <rex-bc.chen@mediatek.com>,
        matthias.bgg@gmail.com, mturquette@baylibre.com,
        p.zabel@pengutronix.de
Cc:     runyang.chen@mediatek.com, miles.chen@mediatek.com,
        wenst@chromium.org, nfraprado@collabora.com,
        linux-kernel@vger.kernel.org, linux-clk@vger.kernel.org,
        linux-arm-kernel@lists.infradead.org,
        linux-mediatek@lists.infradead.org,
        Project_Global_Chrome_Upstream_Group@mediatek.com
References: <20220929121031.17523-1-rex-bc.chen@mediatek.com>
 <17c5cc9c-50ea-aeac-04e0-20b6c093c7ec@collabora.com>
 <20220930185953.41810C433C1@smtp.kernel.org>
Content-Language: en-US
From:   AngeloGioacchino Del Regno 
        <angelogioacchino.delregno@collabora.com>
In-Reply-To: <20220930185953.41810C433C1@smtp.kernel.org>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk

Il 30/09/22 20:59, Stephen Boyd ha scritto:
> 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?

With this solution, my concerns are practically solved.

Regards,
Angelo