Re: [PATCH] ar9170usb: add mode-switching for AVM Fritz!WLAN USB N devices in cdrom mode

[Dan Williams <dcbw@redhat.com>]

On Mon, 2009-11-02 at 13:11 -0800, Matthew Dharm wrote:
> On Mon, Nov 02, 2009 at 12:18:35PM -0800, Dan Williams wrote:
> > Devices with fake driver CDs and how they are handled currently:
> > 
> > Zydas WLAN   - kernel
> > Huawei 3G    - kernel  (unusual_devs entry)
> > Sierra 3G    - kernel  (drivers/usb/serial/sierra.c)
> > Option 3G    - udev rules, 'rezero', or usb_modeswitch
> > ZTE 3G       - udev rules, simple 'eject'
> 
> It's worth noting that for some of these which are handled in-kernel, it
> had to be done that way because their storage-emulation was so poor that
> the normal 'eject' WOULD NOT work properly.

Half of them don't use eject at all, because of course on Windows the
vendor driver owns the device and can do whatever it wants.  Huawei uses
a custom sequence, Option uses a custom sequence, and so does Sierra.
ZTE is the only one that I've seen that you can actually just "eject"
and make it work.

In userspace, usb_modeswitch is the place to put all this logic.  Then
you tie it together with udev rules using some bubble-gum and duct-tape,
and maybe it works.  Of course, there's massive duplication of data
between usb_modeswitch and the kernel drivers, because the there's
simply no communication between the two.

The kernel drivers know which devices are supported and how to drive
them.  But because the eject code isn't in kernelspace, all that device
selection logic has to be duplicated in userspace with usb_modeswitch.
Pretty dumb.

Maybe we can get the kernel drivers to expose the information we need
(maybe even an 'eject' attribute in sysfs or something) and then we just
have to write udev rules instead of having a whole bunch of libusb junk
in userspace?  Would that preserve the policy-always-in-userspace
requirement yet keep the code to drive the hardware in kernel space
where it really belongs?

Dan