Re: [PATCH v3 1/5] rust: usb: add revocable typed interface I/O

["Gary Guo" <gary@garyguo.net>]

On Mon Aug 31, 2026 at 6:04 PM BST, Mike Lothian wrote:
> On Wed, 26 Aug 2026, Danilo Krummrich 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?
>
> Nothing in this posting uses it. It's a leftover from something I
> removed, and I'm not sure it should have stayed removed.
>
> It backed a write-only sysfs file, /sys/devices/vino/remove_all, which
> walked the driver's list of held interfaces and called
> device_release_driver() on each. evdi has had the same file since 2015
> as /sys/devices/evdi/remove_all, so it's a name people with DisplayLink
> hardware already know.
>
> I added it because unloading the module used to be unsafe. disconnect()
> could deadlock against usb_hub_wq, DRM references were held past unbind
> so every replug leaked a card minor, and one unload took the machine
> down. Having one write that unbound everything from process context,
> with each disconnect running somewhere I could watch it, made those a
> lot easier to find.
>
> They're all fixed now, modprobe -r is reliable, and the sysfs file got
> cut from the series along with the rest of the development scaffolding.
> The binding method survived the cut without its caller.
>
> I'll drop it for v4 either way. The bit I'd like your opinion on is
> whether it should come back later with the user attached. Against:
> /sys/bus/usb/drivers/vino/unbind already does this, and all remove_all
> saves you is knowing which interfaces the driver kept. For: a dock is
> the kind of device where someone wants to hand the hardware back without
> knowing that, and evdi has shipped the file for ten years.

EVDI is not an upstream driver, so the fact that it supports something isn't
really a justification of adding a new API interface that is already covered by
sysfs unbind.

Best,
Gary