From: Johan Hovold <johan@kernel.org>
To: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Danilo Krummrich <dakr@kernel.org>,
"Rafael J . Wysocki" <rafael@kernel.org>,
Tzung-Bi Shih <tzungbi@kernel.org>,
Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>,
Linus Walleij <linusw@kernel.org>,
Jonathan Corbet <corbet@lwn.net>, Shuah Khan <shuah@kernel.org>,
Laurent Pinchart <laurent.pinchart@ideasonboard.com>,
Wolfram Sang <wsa+renesas@sang-engineering.com>,
Simona Vetter <simona.vetter@ffwll.ch>,
Dan Williams <dan.j.williams@intel.com>,
Jason Gunthorpe <jgg@nvidia.com>,
linux-doc@vger.kernel.org, linux-kselftest@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 0/3] Revert "revocable: Revocable resource management"
Date: Tue, 3 Feb 2026 13:15:50 +0100 [thread overview]
Message-ID: <aYHm9pr0e7myeqS3@hovoldconsulting.com> (raw)
In-Reply-To: <aXdxDBXdyqLFfKKI@hovoldconsulting.com>
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.
Johan
next prev parent reply other threads:[~2026-02-03 12:15 UTC|newest]
Thread overview: 70+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-01-24 17:05 [PATCH 0/3] Revert "revocable: Revocable resource management" Johan Hovold
2026-01-24 17:05 ` [PATCH 1/3] Revert "selftests: revocable: Add kselftest cases" Johan Hovold
2026-01-24 17:05 ` [PATCH 2/3] Revert "revocable: Add Kunit test cases" Johan Hovold
2026-01-24 17:05 ` [PATCH 3/3] Revert "revocable: Revocable resource management" Johan Hovold
2026-01-24 17:37 ` Johan Hovold
2026-01-24 17:46 ` Danilo Krummrich
2026-01-26 13:20 ` Johan Hovold
2026-01-27 15:57 ` Tzung-Bi Shih
2026-01-24 18:42 ` [PATCH 0/3] " Laurent Pinchart
2026-01-24 19:08 ` Danilo Krummrich
2026-01-25 12:47 ` Greg Kroah-Hartman
2026-01-25 13:22 ` Laurent Pinchart
2026-01-25 14:07 ` Danilo Krummrich
2026-01-29 1:09 ` Laurent Pinchart
2026-01-25 13:24 ` Laurent Pinchart
2026-01-25 17:53 ` Danilo Krummrich
2026-01-26 0:07 ` Jason Gunthorpe
2026-01-26 16:08 ` Danilo Krummrich
2026-01-26 17:07 ` Jason Gunthorpe
2026-01-26 22:36 ` Danilo Krummrich
2026-01-28 23:40 ` Laurent Pinchart
2026-01-26 13:50 ` Johan Hovold
2026-01-27 21:18 ` Bartosz Golaszewski
2026-01-27 23:52 ` Jason Gunthorpe
2026-01-28 9:40 ` Bartosz Golaszewski
2026-01-28 10:01 ` Wolfram Sang
2026-01-28 15:05 ` Jason Gunthorpe
2026-01-28 15:20 ` Bartosz Golaszewski
2026-01-28 16:01 ` Jason Gunthorpe
2026-01-30 11:27 ` Bartosz Golaszewski
2026-01-28 16:58 ` Wolfram Sang
2026-01-29 1:08 ` Laurent Pinchart
2026-01-29 1:23 ` Jason Gunthorpe
2026-01-29 3:42 ` dan.j.williams
2026-01-29 9:56 ` Danilo Krummrich
2026-01-29 10:43 ` Laurent Pinchart
2026-01-30 0:36 ` dan.j.williams
2026-01-29 10:38 ` Laurent Pinchart
2026-01-29 13:34 ` Jason Gunthorpe
2026-01-29 14:52 ` Laurent Pinchart
2026-01-29 22:29 ` Danilo Krummrich
2026-01-30 9:10 ` Laurent Pinchart
2026-02-03 9:10 ` Maxime Ripard
2026-02-03 13:59 ` Laurent Pinchart
2026-01-28 15:48 ` Johan Hovold
2026-01-29 9:11 ` Bartosz Golaszewski
2026-01-29 10:56 ` Laurent Pinchart
2026-01-29 13:50 ` Bartosz Golaszewski
2026-01-29 14:28 ` Jason Gunthorpe
2026-01-29 14:45 ` Laurent Pinchart
2026-01-29 14:49 ` Laurent Pinchart
2026-01-29 22:00 ` Danilo Krummrich
2026-01-30 11:19 ` Bartosz Golaszewski
2026-01-29 13:27 ` Linus Walleij
2026-02-03 12:15 ` Johan Hovold [this message]
2026-02-03 12:26 ` Greg Kroah-Hartman
2026-02-03 12:30 ` [PATCH] driver core: disable revocable code from build Greg Kroah-Hartman
2026-02-03 13:20 ` Danilo Krummrich
2026-02-04 2:14 ` Tzung-Bi Shih
2026-02-04 5:28 ` [PATCH] selftests: Disable " Tzung-Bi Shih
2026-02-04 8:21 ` Greg Kroah-Hartman
2026-02-03 13:57 ` [PATCH 0/3] Revert "revocable: Revocable resource management" Laurent Pinchart
2026-02-03 15:44 ` Greg Kroah-Hartman
2026-02-04 14:36 ` Johan Hovold
2026-01-27 15:57 ` Tzung-Bi Shih
2026-01-28 14:23 ` Johan Hovold
2026-01-28 23:28 ` Laurent Pinchart
2026-01-29 15:01 ` Tzung-Bi Shih
2026-01-30 9:12 ` Laurent Pinchart
2026-01-30 17:41 ` Danilo Krummrich
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=aYHm9pr0e7myeqS3@hovoldconsulting.com \
--to=johan@kernel.org \
--cc=bartosz.golaszewski@oss.qualcomm.com \
--cc=corbet@lwn.net \
--cc=dakr@kernel.org \
--cc=dan.j.williams@intel.com \
--cc=gregkh@linuxfoundation.org \
--cc=jgg@nvidia.com \
--cc=laurent.pinchart@ideasonboard.com \
--cc=linusw@kernel.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=rafael@kernel.org \
--cc=shuah@kernel.org \
--cc=simona.vetter@ffwll.ch \
--cc=tzungbi@kernel.org \
--cc=wsa+renesas@sang-engineering.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox