I was surprised to learn that the revocable functionality was merged the other
week given the community feedback on list and at LPC, but not least since there
are no users of it, which we are supposed to require to be able to evaluate it
properly.

The chromeos ec driver issue which motivated this work turned out not to need
it as was found during review. And the example gpiolib conversion was posted
the very same morning that this was merged which hardly provides enough time
for evaluation (even if Bartosz quickly reported a performance regression).

Turns out there are correctness issues with both the gpiolib conversion and
the revocable design itself that can lead to use-after-free and hung tasks (see
[1] and [2]).

And as was pointed out repeatedly during review, and again at the day of the
merge, this does not look like the right interface for the chardev unplug
issue.

Despite the last-minute attempt at addressing the issues mentioned above
incrementally, the revocable design is still fundamentally flawed (see patch
3/3).

We have processes like requiring a user before merging a new interface so that
issues like these can be identified and the soundness of an API be evaluated.
They also give a sense of when things are expected to happen, which allows our
scarce reviewers to manage their time (e.g. to not be forced to drop everything
else they are doing when things are merged prematurely).

There really is no reason to exempt any new interface from this regardless of
whether one likes the underlying concept or not.

Revert the revocable implementation until a redesign has been proposed and
evaluated properly.

Johan


[1] https://lore.kernel.org/all/aXT45B6vLf9R3Pbf@hovoldconsulting.com/
[2] https://lore.kernel.org/all/20260124170535.11756-4-johan@kernel.org/


Changes in v2:
 - revert also the incremental changes in driver-core-next
 - explain why the latest revocable design is still fundamentally broken


Johan Hovold (3):
  Revert "selftests: revocable: Add kselftest cases"
  Revert "revocable: Add Kunit test cases"
  Revert "revocable: Revocable resource management"

 .../driver-api/driver-model/index.rst         |   1 -
 .../driver-api/driver-model/revocable.rst     | 149 ---------
 MAINTAINERS                                   |   9 -
 drivers/base/Kconfig                          |   8 -
 drivers/base/Makefile                         |   3 -
 drivers/base/revocable.c                      | 225 --------------
 drivers/base/revocable_test.c                 | 284 ------------------
 include/linux/revocable.h                     |  89 ------
 .../selftests/drivers/base/revocable/Makefile |   7 -
 .../drivers/base/revocable/revocable_test.c   | 136 ---------
 .../drivers/base/revocable/test-revocable.sh  |  39 ---
 .../base/revocable/test_modules/Makefile      |  10 -
 .../revocable/test_modules/revocable_test.c   | 187 ------------
 13 files changed, 1147 deletions(-)
 delete mode 100644 Documentation/driver-api/driver-model/revocable.rst
 delete mode 100644 drivers/base/revocable.c
 delete mode 100644 drivers/base/revocable_test.c
 delete mode 100644 include/linux/revocable.h
 delete mode 100644 tools/testing/selftests/drivers/base/revocable/Makefile
 delete mode 100644 tools/testing/selftests/drivers/base/revocable/revocable_test.c
 delete mode 100755 tools/testing/selftests/drivers/base/revocable/test-revocable.sh
 delete mode 100644 tools/testing/selftests/drivers/base/revocable/test_modules/Makefile
 delete mode 100644 tools/testing/selftests/drivers/base/revocable/test_modules/revocable_test.c

-- 
2.52.0

On Wed, Feb 04, 2026 at 03:28:46PM +0100, Johan Hovold wrote:
> I was surprised to learn that the revocable functionality was merged the other
> week given the community feedback on list and at LPC, but not least since there
> are no users of it, which we are supposed to require to be able to evaluate it
> properly.
> 
> The chromeos ec driver issue which motivated this work turned out not to need
> it as was found during review. And the example gpiolib conversion was posted
> the very same morning that this was merged which hardly provides enough time
> for evaluation (even if Bartosz quickly reported a performance regression).
> 
> Turns out there are correctness issues with both the gpiolib conversion and
> the revocable design itself that can lead to use-after-free and hung tasks (see
> [1] and [2]).
> 
> And as was pointed out repeatedly during review, and again at the day of the
> merge, this does not look like the right interface for the chardev unplug
> issue.
> 
> Despite the last-minute attempt at addressing the issues mentioned above
> incrementally, the revocable design is still fundamentally flawed (see patch
> 3/3).
> 
> We have processes like requiring a user before merging a new interface so that
> issues like these can be identified and the soundness of an API be evaluated.
> They also give a sense of when things are expected to happen, which allows our
> scarce reviewers to manage their time (e.g. to not be forced to drop everything
> else they are doing when things are merged prematurely).
> 
> There really is no reason to exempt any new interface from this regardless of
> whether one likes the underlying concept or not.
> 
> Revert the revocable implementation until a redesign has been proposed and
> evaluated properly.

After thinking about this a lot, and talking it over with Danilo a bit,
I've applied this series that reverts these changes.

Kernel developers / maintainers are only "allowed" one major argument /
fight a year, and I really don't want to burn my 2026 usage so early in
the year :)

Tzung-Bi, can you take the feedback here, and what you have learned from
the gpio patch series, and rework this into a "clean" patch series for
us to review and comment on for future releases?  That should give us
all a baseline on which to work off of, without having to worry about
the different versions/fixes floating around at the moment.

thanks,

greg k-h