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 gregkh@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.