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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <aBH5s7p2RxLGjTQD@gaggiata.pivistrello.it>
Date: Wed, 30 Apr 2025 12:21:39 +0200
From: Francesco Dolcini <francesco@...cini.it>
To: Francesco Dolcini <francesco@...cini.it>
Cc: Andreas Kemnade <andreas@...nade.info>,
	Jerome Neanne <jneanne@...libre.com>,
	Shree Ramamoorthy <s-ramamoorthy@...com>,
	Mark Brown <broonie@...nel.org>, Nishanth Menon <nm@...com>,
	Vignesh Raghavendra <vigneshr@...com>,
	Tero Kristo <kristo@...nel.org>,
	Aaro Koskinen <aaro.koskinen@....fi>,
	Kevin Hilman <khilman@...libre.com>,
	Roger Quadros <rogerq@...nel.org>, Tony Lindgren <tony@...mide.com>,
	Liam Girdwood <lgirdwood@...il.com>, linux-omap@...r.kernel.org,
	linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org
Subject: Re: tps65219/am62p kernel oops

On Wed, Apr 30, 2025 at 10:01:14AM +0200, Francesco Dolcini wrote:
> On Tue, Apr 29, 2025 at 06:52:40PM +0200, Andreas Kemnade wrote:
> > Am Tue, 29 Apr 2025 15:21:19 +0200
> > schrieb Francesco Dolcini <francesco@...cini.it>:
> > 
> > > Hello all,
> > > while working on adding support in mainline for a new board based on TI
> > > AM62P SoC I noticed the following Kernel Oops.
> > > 
> > > This oops was reproduced running current Linux
> > > master, 6.15.0-rc4+, ca91b9500108d4cf083a635c2e11c884d5dd20ea, but I was able
> > > to reproduce the same with 6.14.4.
> > > 
> > 
> > [...]
> > > [  +0.000022] Call trace:
> > > [  +0.000011]  regulator_notifier_call_chain+0x20/0xa4 (P)
> > > [  +0.000018]  tps65219_regulator_irq_handler+0x34/0x80
> > 
> > wild guessing: maybe because irqdata->rdev is not initalized in
> > _probe()? At least I do not see where it would be initialized.
> 
> your wild guess seems correct, I'll send a proper patch with your
> suggested-by after doing a couple of more tests, thanks.

so, the bug is clear, however the fix is not an obvious one liner as I was
wishing.

we would need to add a link from each of the interrupts to the specific
regulator. as of now such a connection is not existing in the code.

I would not have the time to fix the code in the next few days, if someone is
able to pick this up before, just let me know ...

Francesco



Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ