Linux USB
 help / color / mirror / Atom feed
From: "Danilo Krummrich" <dakr@kernel.org>
To: "Mike Lothian" <mike@fireburn.co.uk>
Cc: linux-usb@vger.kernel.org, "Miguel Ojeda" <ojeda@kernel.org>,
	"Boqun Feng" <boqun@kernel.org>, "Gary Guo" <gary@garyguo.net>,
	"Björn Roy Baron" <bjorn3_gh@protonmail.com>,
	"Benno Lossin" <lossin@kernel.org>,
	"Andreas Hindborg" <a.hindborg@kernel.org>,
	"Alice Ryhl" <aliceryhl@google.com>,
	"Trevor Gross" <tmgross@umich.edu>,
	"Daniel Almeida" <daniel.almeida@collabora.com>,
	"Tamir Duberstein" <tamird@kernel.org>,
	"Alexandre Courbot" <acourbot@nvidia.com>,
	"Onur Özkan" <work@onurozkan.dev>,
	"Greg Kroah-Hartman" <gregkh@linuxfoundation.org>,
	"Colin Braun" <colinbrauncl@gmail.com>,
	rust-for-linux@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v3 1/5] rust: usb: add revocable typed interface I/O
Date: Wed, 26 Aug 2026 20:59:47 +0200	[thread overview]
Message-ID: <DKZ3UPVXL5C5.37DDI6DQKS3MS@kernel.org> (raw)
In-Reply-To: <20260826163101.4168-2-mike@fireburn.co.uk>

On Wed Aug 26, 2026 at 6:30 PM CEST, Mike Lothian wrote:
> +    /// Asks the driver core to unbind whatever driver is currently bound to this interface.

What is this needed for? Where do you use it?

> +    /// This is the narrow, reviewed replacement for handing out a raw `struct device` pointer: it
> +    /// performs exactly one operation (`device_release_driver()`) on this interface's own device,
> +    /// and cannot be used to reach the device-wide state of a composite peer.
> +    ///
> +    /// It is intended for a driver-provided "release my devices" control (e.g. a sysfs attribute),
> +    /// and must not be called from the driver's own `probe()` or `disconnect()` callback: the
> +    /// driver core already holds the device lock across those.

IOW, it must not be available for Interface<Core>, which due to the deref chain
is not that trivial to model. So, if this is really needed I think this needs a
an abstraction where you get a different device newtype from the scope where
this *should* be called from that allows you to do this and can never leave the
scope.

> +    pub fn release_driver(&self) {
> +        // SAFETY: `self.as_raw()` is a valid `struct usb_interface` by the type invariant, so the
> +        // address of its embedded `dev` is a valid `struct device`. `device_release_driver()`
> +        // takes the device lock itself and tolerates a device with no driver bound.
> +        unsafe { bindings::device_release_driver(&raw mut (*self.as_raw()).dev) };
> +    }

[...]

> +/// A revocable window during which USB I/O is permitted on an interface.
> +///
> +/// A driver-`Bound` interface is *not* on its own proof that a transfer may be issued: the USB
> +/// core forbids I/O outside the window that opens after a successful `probe()`/resume/reset-resume
> +/// and must be closed again before `disconnect()`, `suspend()` or `pre_reset()` returns. This type
> +/// represents exactly that narrower state.

How is this different or narrower than the device's Bound type state represents?
Also, this seems to reinvent Devres, which we superseded with Rust native
lifetimes and higher-ranked types. Please use that instead.

  reply	other threads:[~2026-08-26 18:59 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-26 16:30 [PATCH v3 0/5] rust: usb: host-side abstractions for a bulk-endpoint driver Mike Lothian
2026-08-26 16:30 ` [PATCH v3 1/5] rust: usb: add revocable typed interface I/O Mike Lothian
2026-08-26 18:59   ` Danilo Krummrich [this message]
2026-08-26 16:30 ` [PATCH v3 2/5] rust: usb: add reusable URBs and persistent bulk queues Mike Lothian
2026-08-26 16:30 ` [PATCH v3 3/5] rust: usb: expose device descriptor fields and queue readiness Mike Lothian
2026-08-26 16:30 ` [PATCH v3 4/5] rust: usb: add a vendor-and-interface-info device id constructor Mike Lothian
2026-08-26 16:30 ` [PATCH v3 5/5] rust: usb: let a driver keep its interface usable while unbinding Mike Lothian
2026-08-26 18:25 ` [PATCH v3 0/5] rust: usb: host-side abstractions for a bulk-endpoint driver 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=DKZ3UPVXL5C5.37DDI6DQKS3MS@kernel.org \
    --to=dakr@kernel.org \
    --cc=a.hindborg@kernel.org \
    --cc=acourbot@nvidia.com \
    --cc=aliceryhl@google.com \
    --cc=bjorn3_gh@protonmail.com \
    --cc=boqun@kernel.org \
    --cc=colinbrauncl@gmail.com \
    --cc=daniel.almeida@collabora.com \
    --cc=gary@garyguo.net \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=lossin@kernel.org \
    --cc=mike@fireburn.co.uk \
    --cc=ojeda@kernel.org \
    --cc=rust-for-linux@vger.kernel.org \
    --cc=tamird@kernel.org \
    --cc=tmgross@umich.edu \
    --cc=work@onurozkan.dev \
    /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