Re: [PATCH v3 0/5] rust: usb: host-side abstractions for a bulk-endpoint driver

["Danilo Krummrich" <dakr@kernel.org>]

(Cc: Greg, Oliver, Alan)

On Wed Aug 26, 2026 at 6:30 PM CEST, Mike Lothian wrote:
>   v2 10/11, "keep usb::Device private and gate ...", is dropped entirely.
>     Oliver Neukum was right that it was conceptually wrong: USB does device
>     level operations, and hiding that behind an interface is a layering
>     violation. Device stays public

On an abstract level a USB interface is a device that is operated by some
driver, which is why from a driver core topology point of view, a struct
usb_interface *is* a struct device. And there is no layering violation in
shortening:

	intf.device().bulk_send();

to

	intf.bulk_send();

Now, I get that this might read a bit odd from a pure USB topology perspective,
but what this shortcut gives you is that it allows you to not create types with
incorrect type states intermediately.

If USB folks really want the API to have an indirection, so it matches the USB
topology reading a bit better, just create an abstract a new type, e.g.:

	struct IoDevice<'a> {
	    intf: &'a usb::Interface<Bound>,
	}

which only provides the corresponding I/O methods, but does not give you access
to a "real" usb::Device<Bound>. This way you can still write:

	intf.device().bulk_send();

if that's preferrable.

Interestingly, looking at your series, it already does something like this, but
it's called IoWindow and oddly reimplements the lifecycle constraints the Rust
driver core infrastructure already provides.

> Alan Stern's lifecycle point is what makes device access from an interface
> sound, and is worth restating because the whole shape depends on it: an
> unconfigured device has no interfaces, so an interface that exists implies a
> configured device

Well, Alan also said this:

"At first I thought that we ought to have such a guarantee.  But in fact we
don't, because the user can at any time write to a USB device's
bConfigurationValue sysfs attribute even if the device isn't bound to a driver.
This can create interfaces which may then be bound to drivers."

This was a reply to me asking:

"So, what you're saying is that, in the generic case, there is a guarantee that
if a usb_interface is bound to a usb_driver, then the usb_interface's parent
usb_device is also bound to a usb_device_driver."