On Tue, Feb 03, 2026 at 03:57:11PM +0200, Laurent Pinchart wrote: > On Tue, Feb 03, 2026 at 01:26:58PM +0100, Greg KH wrote: > > On Tue, Feb 03, 2026 at 01:15:50PM +0100, Johan Hovold wrote: > > > 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. > > The reason why I (and others) would like to see this series reverted is > because be believe it is *not* the right way forward. There's no > consensus on that topic. While having code in mainline can improve > collaboration and accelerate development, we don't traditionally do that > when a large portion of the parties involved believe the approach is > wrong, and no user should be added until a consensus on the API is > found.
Ah, but I do think this is the way forward, given that the pattern/idea works in the rust side of the kernel, and it's exactly what I've been asking for for years now :) But yes, without a real user, it's hard for me to justify it. But, I want it present in the tree now so that lots of others can play with it easily. If it turns out it is not correct, and does not work properly, then great, we will delete the files entirely. But I'm not so sure that we are there yet. thanks, greg "we all want more hours in a day" k-h
