On Fri, Feb 6, 2026 at 4:17 PM Greg Kroah-Hartman
[off-list ref] wrote:

On Wed, Feb 04, 2026 at 03:28:46PM +0100, Johan Hovold wrote:

quoted

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.

I think it's a good decision. I definitely want to see it upstream but
it needs a serious rework and I think it should go upstream together
with the first user. I'm fine with it being the GPIO subsystem and
happy to help with reviewing and development.

Bartosz