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
