usb: umass: add SCSIEJECT quirk and fix RTW8821CU_CD (USB mode switch)

[bz]

Summary

Several Realtek (and lots other) USB dongles present themselves as
CDROM device first. Upon eject they do a mode switch and suddenly
are a different kind of device (sometimes even with different IDs),
e.g., a wireless dongle.

In order to avoid the CDROM stage and rather than adding the quirk
handling to more drivers, add support to umass and if enabled
automatically eject the "CDROM" to make it the real device.

Longer-term some other drivers could stop using their hand-rolled
support for this. It is unclear as-to how much we need the list of
(eject) quirks from u3g here, or if these are very specific to that
kind of devices.

Sponsored by: The FreeBSD Foundation
Fixes: b3b6a959c85a, 9c0cce328363

[bz]

One of my many USB sticks is not happy with this (I have multiple plugged in currently)

Root mount waiting for: usbus0
ugen0.4: <Realtek DISK> at usbus0
umass0 on uhub1
umass0: <Realtek DISK, class 0/0, rev 2.00/2.00, addr 3> on usbus0
umass0:  SCSI over Bulk-Only; quirks = 0x10000<EJECT_SCSIEJECT>
umass0: at uhub1, port 2, addr 3 (disconnected)
umass0: device in attaching state! Deferring detach.
panic: usb_detach_device_sub: A USB driver would not detach

cpuid = 3
time = 4
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe00b09a49e0
vpanic() at vpanic+0x136/frame 0xfffffe00b09a4b10
panic() at panic+0x43/frame 0xfffffe00b09a4b70
usb_detach_device() at usb_detach_device+0x1d8/frame 0xfffffe00b09a4bb0
bbb_attach() at bbb_attach+0x33/frame 0xfffffe00b09a4c10
usb_msc_eject() at usb_msc_eject+0x17/frame 0xfffffe00b09a4c40
umass_attach() at umass_attach+0x22c/frame 0xfffffe00b09a4cb0
device_attach() at device_attach+0x45b/frame 0xfffffe00b09a4d00
usb_probe_and_attach() at usb_probe_and_attach+0x2cf/frame 0xfffffe00b09a4da0
uhub_explore() at uhub_explore+0xa45/frame 0xfffffe00b09a4e20
uhub_explore() at uhub_explore+0xa75/frame 0xfffffe00b09a4ea0
usb_bus_explore() at usb_bus_explore+0x119/frame 0xfffffe00b09a4ec0
usb_process() at usb_process+0xf0/frame 0xfffffe00b09a4ef0
fork_exit() at fork_exit+0x82/frame 0xfffffe00b09a4f30
fork_trampoline() at fork_trampoline+0xe/frame 0xfffffe00b09a4f30
--- trap 0, rip = 0, rsp = 0, rbp = 0 ---
KDB: enter: panic
[ thread pid 14 tid 100080 ]
Stopped at      kdb_enter+0x33: movq    $0,0x11e4402(%rip)

[bz]

Switch to using the DRIVER_MODULE evh to hook up the usb_dev_configured event handler in order to avoid problems of detaching while attaching and follow-up panics in USB.

[bz]

Add eventhandelr.h so non-vimage kernels compile as well.

[imp]

I don't think this will work... I'll write more later

[bz]

In D54901#1257140, @imp wrote:

I don't think this will work... I'll write more later

I am curious.

I know for the once I tested, working it does.

I even plugged an mtw(4) device in on top which is one of the devices which has its own routine for this and it still worked. run(4) ins another one.
My u3g is builtin and doesn't seem to need a quirk so couldn't test with the full set there but at least it also attached properly still.

If there are side effects with the USB stack then that may be a problem and I'd love to hear them but then those other drivers likely have a similar issue as they all use the same eventhandler.

[bz]

@imp any chances to see about this? Should I wait for you?