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 8:48 PM CEST, Oliver Neukum wrote:
> On 14.07.26 19:53, Danilo Krummrich wrote:
>
>> Many APIs rely on this, as in they only guarantee valid behavior when called
>> from a scope where the device is guaranteed to be bound to a driver, or IOW
>> where a driver can prove that it actually operates the device.
>> 
>> Drivers must only acquire device resources when they are actually bound to the
>> corresponding device, and must hand them back before the device is unbound. The
>> devres API, for instance, exists for this fundamental reason.
>> 
>> For instance, we can't have drivers manage IRQs, mess with I/O memory, program
>> IOMMU page tables (e.g. through DMA APIs), etc. for devices they are not bound
>> to and hence are not allowed to operate (anymore).
>> 
>> Those device resources all have a lifetime that is tied to the lifetime of the
>> device being bound to a driver.
>
> Understood. Unfortunately this does not map straightforwardly to the USB API.
> Usbcore tells a driver via corresponding opeations when IO has to cease
> (and other operations should be performed) and when it is allowed again.

Everything regarding other device resources, such as DMA mappings, IRQs, etc.
still applies.

Regarding USB I/O APIs, what you describe sounds like an additional constraint,
where the usbcore tells the driver when I/O operations are allowed within the
bigger window of the driver being bound.

This additional constraint can be modeled with additional USB specific types
that limit the scope to those specific operations.

For instance, it could be a new type around e.g. a usb::Interface<Bound> that
implements the corresponding accessors and is only given out with a lifetime
spanning those operations.