From: Jason Gunthorpe <jgg@nvidia.com>
To: Tzung-Bi Shih <tzungbi@kernel.org>
Cc: Arnd Bergmann <arnd@arndb.de>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Bartosz Golaszewski <brgl@kernel.org>,
Linus Walleij <linusw@kernel.org>,
Benson Leung <bleung@chromium.org>,
linux-kernel@vger.kernel.org, chrome-platform@lists.linux.dev,
driver-core@lists.linux.dev, linux-doc@vger.kernel.org,
linux-gpio@vger.kernel.org,
"Rafael J. Wysocki" <rafael@kernel.org>,
Danilo Krummrich <dakr@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>,
Johan Hovold <johan@kernel.org>,
"Paul E . McKenney" <paulmck@kernel.org>
Subject: Re: [PATCH v11 4/5] platform/chrome: Protect cros_ec_device lifecycle with revocable
Date: Thu, 14 May 2026 13:00:43 -0300 [thread overview]
Message-ID: <20260514160043.GG787748@nvidia.com> (raw)
In-Reply-To: <agVCtBbqT6aZL0mx@google.com>
On Thu, May 14, 2026 at 03:34:12AM +0000, Tzung-Bi Shih wrote:
> To help me understand, could you elaborate on why the revocable mechanism
> isn't suitable here?
Stay within one driver. Create the revokable is probe, consume it
within that drivers fops/etc, destroy it on remove. Do not randomly
pass it to other drivers.
> I'm wondering because if this piece of code were to transition to
> Rust in the future, would the concerns you have also apply to using
> Revocable[1] in the Rust context for this driver?
Yes, even in rust driver local revocable objects should not be
spaghetti coded through different layers.
Jason
next prev parent reply other threads:[~2026-05-14 16:00 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-13 9:10 [PATCH v11 0/5] drivers/base: Introduce revocable Tzung-Bi Shih
2026-05-13 9:10 ` [PATCH v11 1/5] revocable: Revocable resource management Tzung-Bi Shih
2026-05-13 9:10 ` [PATCH v11 2/5] revocable: Add KUnit test cases Tzung-Bi Shih
2026-05-13 9:10 ` [PATCH v11 3/5] gpio: Leverage revocable for accessing struct gpio_chip Tzung-Bi Shih
2026-05-13 9:10 ` [PATCH v11 4/5] platform/chrome: Protect cros_ec_device lifecycle with revocable Tzung-Bi Shih
2026-05-13 11:51 ` Jason Gunthorpe
2026-05-14 3:34 ` Tzung-Bi Shih
2026-05-14 16:00 ` Jason Gunthorpe [this message]
2026-05-13 9:10 ` [PATCH v11 5/5] platform/chrome: cros_ec_chardev: Consume cros_ec_device via revocable Tzung-Bi Shih
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=20260514160043.GG787748@nvidia.com \
--to=jgg@nvidia.com \
--cc=arnd@arndb.de \
--cc=bleung@chromium.org \
--cc=brgl@kernel.org \
--cc=chrome-platform@lists.linux.dev \
--cc=corbet@lwn.net \
--cc=dakr@kernel.org \
--cc=driver-core@lists.linux.dev \
--cc=gregkh@linuxfoundation.org \
--cc=johan@kernel.org \
--cc=laurent.pinchart@ideasonboard.com \
--cc=linusw@kernel.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-gpio@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=paulmck@kernel.org \
--cc=rafael@kernel.org \
--cc=shuah@kernel.org \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.