Re: [RFC PATCH 2/4] rust: usb: add usb host interface and endpoint abstractions

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

On Tue Jul 14, 2026 at 11:26 AM CEST, Oliver Neukum wrote:
> You can see that there is no way a configuration and thereby its interfaces
> can last longer than its device.

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.

But the relevant question is whether this always holds. In a previous discussion
[1] Alan explained that it currently doesn't hold.

Note that I'm not looking at this from a USB topology perspective, but from a
driver model perspective. All I'm saying is that usb::Device<Bound> from the
driver model side means "it is guaranteed that the usb_device is bound to a
usb_device_driver" and therefore can implement functions that rely on this
invariant.

Analogously, usb::Interface<Bound> means that the usb_interface is bound to a
usb_driver. So, if we want to be able to derive usb::Device<Bound> from
usb::Interface<Bound> it must always be guaranteed that this holds, not just in
the most common case.

As for the question whether it should be

	let dev = intf.device();
	dev.bulk_recv();

or

	intf.bulk_recv();

the former does not work if we can't uphold the guarantee that
usb::Device<Bound> follows from usb::Interface<Bound>; at least not without an
additional type state wrapper.

However, I don't see why we don't want to have the helper regardless. A
usb_driver primarily deals with the usb_interface device, so that makes perfect
sense from a driver model perspective: The "device" a usb_driver deals with is
the usb_interface.

I think our main disconnect comes from the fact that you see this from a USB
stack topology point of view, whereas I see it from a driver model topology
point of view.

From the driver core perspective a usb_interface is just another device that
happens to have a usb_device parent. Lifecycle wise any device resources
requested by a usb_driver are tied to the lifetime of the usb_interface being
bound to the usb_driver.

The semantic relationship of a usb_interface and a usb_device is a USB subsystem
implementation detail, but it doesn't change the core lifecycle and ownership
rules as far as the driver model is concerned.

That said, the question of having or not having those helpers is "bikeshedding"
about USB topology vs. driver model perspective and either seems reasonable
IMHO. However, it has a correctness implication, as giving out
usb::Device<Bound> from usb::Interface<Bound> would currently be unsound as by
[1]; deriving usb::Device<Core> from usb::Interface<Core> is never correct, as
it implies being in the scope of a device lock protected bus callback.

> There simply is no data structure equivalent to the binding of a driver and an
> interface,

I don't know what you mean by this.

> hence we cannot just give interfaces a state.

Of course we can, and we have to. As mentioned above, from a driver core
perspective a usb_interface is just another device, with an own struct device it
embedds, its own device lock and its own driver structure (struct usb_driver) it
can be bound to.

The device types states match exactly this. For instance the 'Core' context
represents a device that is given out in a bus callback while the device lock is
held, such that we can restrict methods that require this scope to this context.

The same goes for the 'Bound' device context state. In the case of usb_interface
it means that the usb_interface is bound to the usb_driver.

[1] https://lore.kernel.org/all/0ff2a825-1115-426a-a6f9-df544cd0c5fc@rowland.harvard.edu/