Message-ID: <2026020315-twins-probe-d988@gregkh>
Date: Tue, 3 Feb 2026 13:26:58 +0100
From: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To: Johan Hovold <johan@...nel.org>
Cc: Danilo Krummrich <dakr@...nel.org>,
	"Rafael J . Wysocki" <rafael@...nel.org>,
	Tzung-Bi Shih <tzungbi@...nel.org>,
	Bartosz Golaszewski <bartosz.golaszewski@....qualcomm.com>,
	Linus Walleij <linusw@...nel.org>, Jonathan Corbet <corbet@....net>,
	Shuah Khan <shuah@...nel.org>,
	Laurent Pinchart <laurent.pinchart@...asonboard.com>,
	Wolfram Sang <wsa+renesas@...g-engineering.com>,
	Simona Vetter <simona.vetter@...ll.ch>,
	Dan Williams <dan.j.williams@...el.com>,
	Jason Gunthorpe <jgg@...dia.com>, linux-doc@...r.kernel.org,
	linux-kselftest@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 0/3] Revert "revocable: Revocable resource management"

On Tue, Feb 03, 2026 at 01:15:50PM +0100, Johan Hovold wrote:
> Hi Greg,
> 
> On Mon, Jan 26, 2026 at 02:50:05PM +0100, Johan Hovold wrote:
> > On Sun, Jan 25, 2026 at 01:47:14PM +0100, Greg Kroah-Hartman wrote:
> 
> > > True, but we do need something.  I took these patches without a real
> > > user as a base for us to start working off of.  The rust implementation
> > > has shown that the design-pattern is a good solution for the problem,
> > > and so I feel we should work with it and try to get this working
> > > properly.  We've been sitting and talking about it for years now, and
> > > here is the first real code submission that is getting us closer to fix
> > > the problem properly.  It might not be perfict, but let's evolve it from
> > > here for what is found not to work correctly.
> > 
> > It's a design pattern that's perhaps needed for rust, but not
> > necessarily elsewhere. But either way there is no need to rush this. If
> > it turns out to be usable, it can be merged along with a future user.
> > 
> > Dropping the revocable_provider and revocable abstraction split should
> > even make it more palatable.
> > 
> > And with a new interface and a non-trivial user we can see what the
> > end-result looks like and decide where to go from there. 
> > 
> > > So I don't want to take these reverts, let's try this out, by putting
> > > this into the driver core now, we have the base to experiment with in a
> > > "safe" way in lots of different driver subsytems at the same time.  If
> > > it doesn't work out, worst case we revert it in a release or two because
> > > it didn't get used.
> > 
> > Please reconsider. Perhaps I didn't stress the point enough that the
> > current API needs to be reworked completely since there's no longer any
> > need for the two revocable abstractions.
> 
> I noticed that you picked up the proposed incremental fixes to the
> issues I reported without anyone even having reviewed them. The fixes
> being incremental makes it a lot harder to review, but based on a quick
> look it seems there needs to be further changes.
> 
> And again, what is the rush? Anyone wanting to experiment with this
> functionality only needs to apply a single patch. And exposing the API
> before it is stable is just going to be a mess as subsystems may start
> using it from day one.
> 
> So please, just drop it for 6.20. You can still merge this for the next
> cycle when the basic functionality has been fixed.

The fixes seemed correct on my review, what was wrong with them?  And
having the code fixed for known issues is a good thing here, it gives
the gpio people a base to test their work on.

As no one is currently using this, I will disable this from the build,
but keeping the code in the tree right now is a good thing as I do feel
this is the right way forward, and others can work off of it easier this
way.

thanks,

greg k-h

Powered by blists - more mailing lists