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: <rm7jkvwbgp7pl5ercks22wgazxtz6l6y5laadgby6zeriiesco@heuzcp7kg3qf>
Date: Wed, 14 Jan 2026 14:00:28 +0200
From: Ioana Ciornei <ioana.ciornei@....com>
To: Alexander Stein <alexander.stein@...tq-group.com>, 
	Thomas Gleixner <tglx@...nel.org>
Cc: Vladimir Oltean <olteanv@...il.com>, 
	Ulf Hansson <ulf.hansson@...aro.org>, Geert Uytterhoeven <geert+renesas@...der.be>, 
	Johan Hovold <johan+linaro@...nel.org>, "Rafael J. Wysocki" <rafael@...nel.org>, 
	"Rob Herring (Arm)" <robh@...nel.org>, Greg Kroah-Hartman <gregkh@...uxfoundation.org>, 
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 0/2] irqchip: convert ls-extirq to a platform driver

On Tue, Jan 13, 2026 at 09:20:02PM +0100, Thomas Gleixner wrote:
> On Tue, Jan 13 2026 at 20:43, Vladimir Oltean wrote:
> > On Tue, Jan 13, 2026 at 07:36:48PM +0100, Thomas Gleixner wrote:
> >> Yes. I've marked it "wait for update" and that's the state since
> >> Dec. 5th.
> >
> > Thanks for the response. I've since looked at the code, and Alexander's
> > cleanups are more than "nice", they are required, because when you
> > convert a driver from IRQCHIP_DECLARE() to platform_driver, you
> > introduce the possibility for it to be unbound from the device, and when
> > you do that, the memory that ls_extirq_probe() has allocated needs to be
> > freed.
> 
> Oh, didn't look in that detail. Thanks for catching it!
> 
> > Ioana, Alexander, could you please start a discussion to see who can
> > submit the follow up to this thread?
> 
> Yes please.

What I propose is for me to submit a v3 which squashes Alexander's 3/3
patch (the managed resource changes) into this 2/2 patch.

The alternative would be to extend this 2/2 patch by adding a .remove()
callback only for it to be removed in the next patch which does the
conversion to devres. I don't think that is necessary or even desired.

Alexander, please let me know if you have any objections to this
approach.

Ioana

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ