On 9/12/25 4:54 PM, Laurent Pinchart wrote: > On Fri, Sep 12, 2025 at 04:44:56PM +0200, Bartosz Golaszewski wrote: >> On Fri, Sep 12, 2025 at 4:40 PM Greg Kroah-Hartman >> <gre...@linuxfoundation.org> wrote: >>> Either way, I think this patch series stands on its own, it doesn't >>> require cdev to implement it, drivers can use it to wrap a cdev if they >>> want to. We have other structures that want to do this type of thing >>> today as is proof with the rust implementation for the devm api. >> >> Yeah, I'm not against this going upstream. If more development is >> needed for this to be usable in other parts of the kernel, that can be >> done gradually. Literally no subsystem ever was perfect on day 1. > > To be clear, I'm not against the API being merged for the use cases that > would benefit from it, but I don't want to see drivers using it to > protect from the cdev/unregistration race.
I mean, revocable is really a synchronization primitive in the end that "revokes" access to some resource in a race free way. So, technically, it probably belongs into lib/. I think the reason it ended up in drivers/base/ is that one common use case is to revoke a device resource from a driver when the device is unbound from this driver; or in other words devres is an obvious user. So, I think that any other API (cdev, devres, etc.) should be built on top of it. This is also what we do in Rust, Revocable is just a common synchronization primitive and the (only) user it has is currently Devres building on top of it.
