Re: [PATCH 0/3] Revert "revocable: Revocable resource management"

[Greg Kroah-Hartman <gregkh@linuxfoundation.org>]

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