linux-kernel - Re: [linux-next, 1/1] clk: imx: imx8mm-anatop: probe only on i.MX8MM platforms

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

Message-ID: <1ca1fe0b-2337-4aa6-b36d-f4d11df7b0f5@sirena.org.uk>
Date: Mon, 19 May 2025 15:30:54 +0100
From: Mark Brown <broonie@...nel.org>
To: Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>
Cc: Peng Fan <peng.fan@....com>,
	Dario Binacchi <dario.binacchi@...rulasolutions.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-amarula@...rulasolutions.com" <linux-amarula@...rulasolutions.com>,
	Abel Vesa <abelvesa@...nel.org>, Fabio Estevam <festevam@...il.com>,
	Michael Turquette <mturquette@...libre.com>,
	Pengutronix Kernel Team <kernel@...gutronix.de>,
	Sascha Hauer <s.hauer@...gutronix.de>,
	Shawn Guo <shawnguo@...nel.org>, Stephen Boyd <sboyd@...nel.org>,
	"imx@...ts.linux.dev" <imx@...ts.linux.dev>,
	"linux-arm-kernel@...ts.infradead.org" <linux-arm-kernel@...ts.infradead.org>,
	"linux-clk@...r.kernel.org" <linux-clk@...r.kernel.org>
Subject: Re: [linux-next, 1/1] clk: imx: imx8mm-anatop: probe only on i.MX8MM
 platforms

On Mon, May 19, 2025 at 04:13:14PM +0200, Krzysztof Kozlowski wrote:

> You claim with this:

> 	compatible = "fsl,imx8mp-anatop", "fsl,imx8mm-anatop";

> That 8mp is fully compatible with 8mm, yet here you claim that 8mm is
> not handled. So it is both compatible and not compatible.

Note that binding for anatop and the above compatible list are in
mainline so this is a preexisting issue, whatever differences there are
in the versions in the two SoCs aren't triggering problems with the code
that's in mainline.  The series adding actual clock drivers triggers the
issue but the claim that the two were compatible wasn't introduced by
it.  Given this if people are shipping DTBs based on the existing kernel
we might need something like this patch to work around them, even if we
fix the existing binding and .dtsi files.

Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)