linux-kernel - Re: BUG: [PATCH v2] isoc: mediatek: Check for error clk pointer

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>] [day] [month] [year] [list]

Date:   Fri, 28 Jan 2022 15:26:51 +0100
From:   Paul Mulders <justinkb@...il.com>
To:     frank-w@...lic-files.de
Cc:     broonie@...nel.org, gregkh@...uxfoundation.org,
        jiasheng@...as.ac.cn, lgirdwood@...il.com,
        linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
        linux-mediatek@...ts.infradead.org, matthias.bgg@...il.com
Subject: Re: BUG: [PATCH v2] isoc: mediatek: Check for error clk pointer

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).