linux-kernel - Re: [PATCH v4 2/2] arm64: dts: freescale: add support for NXP i.MX93 FRDM

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: <aVQRCzq8-Q5FguTN@bywater>
Date: Tue, 30 Dec 2025 18:51:07 +0100
From: Francesco Valla <francesco@...la.it>
To: Thomas Petazzoni <thomas.petazzoni@...tlin.com>
Cc: Fabian Pflug <f.pflug@...gutronix.de>, Rob Herring <robh@...nel.org>,
	Krzysztof Kozlowski <krzk+dt@...nel.org>,
	Conor Dooley <conor+dt@...nel.org>, Shawn Guo <shawnguo@...nel.org>,
	Sascha Hauer <s.hauer@...gutronix.de>,
	Pengutronix Kernel Team <kernel@...gutronix.de>,
	Fabio Estevam <festevam@...il.com>, devicetree@...r.kernel.org,
	linux-kernel@...r.kernel.org, imx@...ts.linux.dev,
	linux-arm-kernel@...ts.infradead.org,
	Haidong Zheng <haidong.zheng@....com>,
	Danwei Luo <danwei.luo@....com>, Lei Xu <lei.xu@....com>
Subject: Re: [PATCH v4 2/2] arm64: dts: freescale: add support for NXP i.MX93
 FRDM

Hello Thomas,

On Tue, Dec 30, 2025 at 05:24:27PM +0100, Thomas Petazzoni wrote:
> Hello (again),
> 
> On Tue, 30 Dec 2025 17:15:48 +0100
> Thomas Petazzoni <thomas.petazzoni@...tlin.com> wrote:
> 
> > I see the PMIC interrupt and the RTC interrupts are routed to the I2C
> > GPIO expander at 1-0022, so I imagine either the PMIC or the RTC are
> > triggering an interrupt (left enabled by U-Boot), and the kernel isn't
> > compiled with the driver for either the PMIC or the RTC, and therefore
> > there's no IRQ handler?
> > 
> > (I confess I didn't investigate more than that at this point.)
> 
> Upon closer inspection, I in fact get thousands over IRQ #100 per
> seconds right after boot, until the point where it reaches 100000 IRQ
> events, and the splat appears, with the IRQ being subsequently
> disabled. So it's not just one interrupt, but a storm of it.
> 

This recalls the behaviour seen on i.MX91 FRDM [0], and the hardware is
indeed very similar: the GPIO expander and the TypeC port controller
(PTN5110) share the same IRQ line, and if the first gets enabled before
the second an interrupt storm will happen (because the PTN5110 is
triggering interrupts that nobody services).

I did not see this during my testing - but maybe the probe sequence is 
different. Any chance you are not loading the driver for the PTN5110?
I see from your defconfig it should be compiled as module, but maybe
you are not including it into the image or not loading it?

The NXP downstream BSP is masking interrupts for the TypeC port
controller as part of the U-Boot initialization, as they are enabled by
default at reset. While it somewhat breaks the required isolation
between the bootloader and the system it loads, I fear this is the only
sensible option here, given this hardware limitation; this was the path
that was chosen for the i.MX91 FRDM (which has been applied today [1]).

> Thomas
> -- 
> Thomas Petazzoni, co-owner and CEO, Bootlin
> Embedded Linux and Kernel engineering and training
> https://bootlin.com
> 

[0] https://lore.kernel.org/all/aTBFCc-8NzeS4MzT@bywater/
[1] https://lore.kernel.org/u-boot/CAOMZO5DsCi6GHrkvLEZTjsLy1D02A2e83YgMO36b3EMt8B6c5Q@mail.gmail.com/

Reagrds,
Francesco