Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
From:   Jiasheng Jiang <jiasheng@iscas.ac.cn>
To:     justinkb@gmail.com
Cc:     frank-w@public-files.de, broonie@kernel.org,
        gregkh@linuxfoundation.org, lgirdwood@gmail.com,
        linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org,
        linux-mediatek@lists.infradead.org, matthias.bgg@gmail.com,
        Jiasheng Jiang <jiasheng@iscas.ac.cn>
Subject: Re: BUG: [PATCH v2] isoc: mediatek: Check for error clk pointer
Date:   Sun, 30 Jan 2022 10:43:35 +0800
Message-Id: <20220130024335.114461-1-jiasheng@iscas.ac.cn>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Precedence: bulk

On Fri, Jan 28, 2022 at 10:26:51PM +0800, Paul Mulders wrote:
> I guess this breaks all MT7622 SoCs since it'll prematurely exit
> init_clks (and subsequently init_scp) completely once devm_clk_get
> fails to get a reference to the mm clock producer (which happens to be
> the first one tried). This is because MT7623 has a GPU (so no mm
> clock) and MT7622 doesn't, and as a result the other clock producer
> pointers never get initialized (and other stuff in init_scp after
> returning from the error never happens).
>
> The patch seems fundamentally flawed, I guess it was either not tested
> at all, or only tested on a MT7623. The initialization functions seem
> designed with the idea that it's ok if some clocks aren't present, so
> stopping the initialization when one of them isn't present seems
> wrong. (For example, there is also a MT7622B variant of the MT7622
> which probably also lacks some clocks MT7622(A) does have).

I don't think the patch for init_clks() is flawed.
At most it is incompleted.
What it did is like fixing a potential error in the tool platform
providing service for the upper application, like what you said,
MT7623 and MT7622.
We should not keep the error in the platform because of the upper
application.
And it seems like it is MT7622 that is flawed.
The better way is to fix both the bug in init_clks() and its caller,
MT7622.

Sincerely thanks,
Jiang