From: Daniel Golle <daniel@makrotopia.org>
To: Jiasheng Jiang <jiasheng@iscas.ac.cn>
Cc: justinkb@gmail.com, gregkh@linuxfoundation.org,
linux-kernel@vger.kernel.org, lgirdwood@gmail.com,
broonie@kernel.org, linux-mediatek@lists.infradead.org,
matthias.bgg@gmail.com, linux-arm-kernel@lists.infradead.org
Subject: Re: BUG: [PATCH v2] isoc: mediatek: Check for error clk pointer
Date: Tue, 1 Feb 2022 22:19:59 +0000 [thread overview]
Message-ID: <YfmyD7bmJS9f+e+m@makrotopia.org> (raw)
In-Reply-To: <20220130024335.114461-1-jiasheng@iscas.ac.cn>
On Sun, Jan 30, 2022 at 10:43:35AM +0800, Jiasheng Jiang wrote:
> 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.
I agree that further cleaning is needed here.
Yet the commit in it's current form very obviously breaks at least the
MT7622 platform if no further fixes are applied.
Imho the whole approach of this driver to hard-code the names of all
clocks it could try to grab in a string-array accompanied by an enum
is flawed.
The correct approach would likely be to add the clocks actually present
to the device tree of each SoC and then grab only those.
I can see that mt2701.dtsi and mt7623.dtsi both have some clocks
defined for scpsys, mt7622.dtsi however lacks them.
I didn't check other MediaTek SoCs which also use scpsys.
next prev parent reply other threads:[~2022-02-01 22:20 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-01-30 2:43 BUG: [PATCH v2] isoc: mediatek: Check for error clk pointer Jiasheng Jiang
2022-02-01 22:19 ` Daniel Golle [this message]
2022-02-02 8:09 ` Aw: " Frank Wunderlich
-- strict thread matches above, loose matches on Subject: below --
2022-01-28 14:31 Paul Mulders
2022-01-28 14:26 Paul Mulders
2021-12-22 1:51 Jiasheng Jiang
2022-01-28 9:51 ` BUG: " Frank Wunderlich
2022-02-06 17:37 ` Guenter Roeck
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=YfmyD7bmJS9f+e+m@makrotopia.org \
--to=daniel@makrotopia.org \
--cc=broonie@kernel.org \
--cc=gregkh@linuxfoundation.org \
--cc=jiasheng@iscas.ac.cn \
--cc=justinkb@gmail.com \
--cc=lgirdwood@gmail.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mediatek@lists.infradead.org \
--cc=matthias.bgg@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox