[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <DFQ4H9T3QMLK.3TNZF7ID6EJB6@kernel.org>
Date: Fri, 16 Jan 2026 16:35:23 +0100
From: "Danilo Krummrich" <dakr@...nel.org>
To: "Bartosz Golaszewski" <brgl@...nel.org>
Cc: "Tzung-Bi Shih" <tzungbi@...nel.org>, "Benson Leung"
<bleung@...omium.org>, "Greg Kroah-Hartman" <gregkh@...uxfoundation.org>,
"Rafael J . Wysocki" <rafael@...nel.org>, "Linus Walleij"
<linusw@...nel.org>, "Jonathan Corbet" <corbet@....net>, "Shuah Khan"
<shuah@...nel.org>, <linux-doc@...r.kernel.org>,
<linux-kernel@...r.kernel.org>, <chrome-platform@...ts.linux.dev>,
<linux-kselftest@...r.kernel.org>, "Laurent Pinchart"
<laurent.pinchart@...asonboard.com>, "Wolfram Sang"
<wsa+renesas@...g-engineering.com>, "Simona Vetter"
<simona.vetter@...ll.ch>, "Dan Williams" <dan.j.williams@...el.com>, "Jason
Gunthorpe" <jgg@...dia.com>, <linux-gpio@...r.kernel.org>
Subject: Re: [PATCH v7 1/3] revocable: Revocable resource management
On Fri Jan 16, 2026 at 4:27 PM CET, Bartosz Golaszewski wrote:
> On Fri, Jan 16, 2026 at 4:20 PM Danilo Krummrich <dakr@...nel.org> wrote:
>>
>> On Fri Jan 16, 2026 at 9:02 AM CET, Tzung-Bi Shih wrote:
>> > diff --git a/MAINTAINERS b/MAINTAINERS
>> > index a671e3d4e8be..fd683c62012a 100644
>> > --- a/MAINTAINERS
>> > +++ b/MAINTAINERS
>> > @@ -22517,6 +22517,13 @@ F: include/uapi/linux/rseq.h
>> > F: kernel/rseq.c
>> > F: tools/testing/selftests/rseq/
>> >
>> > +REVOCABLE RESOURCE MANAGEMENT
>> > +M: Tzung-Bi Shih <tzungbi@...nel.org>
>> > +L: linux-kernel@...r.kernel.org
>> > +S: Maintained
>> > +F: drivers/base/revocable.c
>> > +F: include/linux/revocable.h
>>
>> NIT: I think we should add this include to the DRIVER CORE entry as well.
>
> FWIW: I'm not even sure drivers/base/ is the right place for this.
> Except for a few devm_ helpers, nothing here is inherently tied into
> the driver model This could be useful outside of device drivers and I
> would suggest to put it under lib/ with devres factored out into a
> separate source file.
It is indeed correct that in the end revocable is more of a generic
synchronization primitve.
In fact, the Revocable type in Rust is not listed under driver core
infrastructure either. However, it was introduced for use with Devres (which is
still the only user).
I think the, by far, most common use-case where a resource is revoked from an
entity are device resources revoked by devres.
So, I'd say let's factor it out once we see interest by more users?
Powered by blists - more mailing lists