On Thu, 2022-08-18 at 17:08 +0200, Greg Kroah-Hartman wrote: > On Tue, Aug 09, 2022 at 07:27:11PM +0200, Bastien Nocera wrote: > > On Tue, 2022-08-09 at 18:33 +0200, Greg Kroah-Hartman wrote: > > > On Tue, Aug 09, 2022 at 04:31:04PM +0200, Bastien Nocera wrote: > > > > On Tue, 2022-08-09 at 12:38 +0200, Greg Kroah-Hartman wrote: > > > > > Now if you really really want to disable a device from under > > > > > a > > > > > user, > > > > > without the file handle present, you can do that today, as > > > > > root, > > > > > by > > > > > doing the 'unbind' hack through userspace and sysfs. It's so > > > > > common > > > > > that this seems to be how virtual device managers handle > > > > > virtual > > > > > machines, so it should be well tested by now. > > > > > > > > The only thing I know that works that way is usbip, and it > > > > requires > > > > unbinding each of the interfaces: > > > > > > > > https://sourceforge.net/p/usbip/git-windows/ci/master/tree/trunk/userspace/src/bind-driver.c#l157 > > > > > > virtio devices also use the api from what I recall. > > > > I can't find any code that would reference > > /sys/bus/usb/drivers/usbfs/unbind or /sys/bus/usb/drivers/usbfs wrt > > virtio. Where's the host side code for that? > > I mean the virtio code uses bind/unbind for it's devices, nothing to > do > with USB other than the userspace interface involved. This is one big hammer that is really counterproductive in some fairly common use cases. It's fine for assigning a full USB device to a VM, it really isn't for gently removing "just that bit of interface" the user is using while leaving the rest running. If a USB device has 2 interfaces, and one of those interfaces is used by a kernel driver, or a system-wide application, then the whole USB device is made unavailable. For example: - a wireless headset, sound is handled by ALSA at the kernel-level, battery status is monitored through another interface by the user directly, unbinding the USB driver will disable both the sound driver and the battery monitor - a keyboard with RGB backlight, key presses are handled by the input subsystem in the kernel, RGB backlight through another interface as a normal user, unbinding the USB driver disconnects the keyboard completely making it lose lock keys status, amongst other things - a phone used for both network access and file access through MTP, unbinding the USB driver will boot the computer off the network as well as disconnecting the file access when we only wanted the latter to happen I'll explain those use cases in the commit message. For those who want to reproduce the problem, tested with USB wireless headset: $ lsusb Bus 001 Device 011: ID 1038:12b6 SteelSeries ApS SteelSeries Arctis 1 Wireless # Using the bus and device IDs $ grep -l 001/011 /sys/bus/usb/devices/*/uevent | sed 's,/sys/bus/usb/devices/,,' | sed 's,/uevent,,' 1-10 $ echo 1-10 > /sys/bus/usb/drivers/usb/unbind Both the ALSA device: Aug 30 16:19:07 classic pipewire[2061]: spa.alsa: hw:2: snd_pcm_drop No such device Aug 30 16:19:07 classic pipewire[2061]: spa.alsa: hw:2: close failed: No such device Aug 30 16:19:07 classic pipewire[2061]: spa.alsa: front:2: snd_pcm_drop No such device Aug 30 16:19:07 classic pipewire[2061]: spa.alsa: front:2: close failed: No such device and the battery script (https://github.com/Sapd/HeadsetControl/pull/230) are gone.
