Re: 'usb' --> 'usbmisc' transition

[Bjørn Mork <bjorn mork no>]

Dan Williams <dcbw redhat com> writes:
> On Tue, 2012-08-21 at 11:44 +0200, Aleksander Morgado wrote:
>
>> I pushed some fixes to the 'qmi-support' branch of ModemManager trying
>> to cope with the 'usb'->'usbmisc' transition. Basically, I'm assuming
>> that either one or the other may appear, trying to avoid the need for a
>> runtime kernel version check. Could you test that in the newest kernels
>> with 'usbmisc'? It seems to work ok for the older ones with 'usb'.
>
> I tried searching for the usbmisc stuff but couldn't find much upstream.
> What's actually happening here and what devices are affected?  The code
> I found looked like drivers for mostly embedded stuff.

I completely missed the discussion and was as surprised as anyone else
when this changed.  It seems there was an RFC posted in April, with no
comments AFAICS: http://www.spinics.net/lists/linux-usb/msg62276.html

But I believe the commit message explains the reasons pretty well.
There seems to be an underlying idea of unifying the "class" and "bus"
abstraction in the future, and you cannot have two "usb" classes/buses.

I don't think the class name change matters much either.  cdc-wdm being
used by composite devices, and ModemManager needing to sort out which
device a port belongs to, are probably both unique here.

Userspace tools for other drivers could of course also look for the old
name, but I don't find that likely.  Such tools are probably more than
happy using /dev/whatever and not at all interested in sysfs.

The affected devices/drivers I found are:

./drivers/media/rc/imon.c:              ret = usb_register_dev(intf, &imon_lcd_class);
./drivers/media/rc/imon.c:              ret = usb_register_dev(intf, &imon_vfd_class);
./drivers/usb/class/usblp.c:    retval = usb_register_dev(intf, &usblp_class);
./drivers/usb/class/usbtmc.c:   retcode = usb_register_dev(intf, &usbtmc_class);
./drivers/usb/class/cdc-wdm.c:  rv = usb_register_dev(intf, &wdm_class);
./drivers/usb/misc/idmouse.c:   result = usb_register_dev(interface, &idmouse_class);
./drivers/usb/misc/ldusb.c:     retval = usb_register_dev(intf, &ld_usb_class);
./drivers/usb/misc/legousbtower.c:      retval = usb_register_dev (interface, &tower_class);
./drivers/usb/misc/yurex.c:     retval = usb_register_dev(interface, &yurex_class);
./drivers/usb/misc/ftdi-elan.c:                retval = usb_register_dev(interface, &ftdi_elan_jtag_class);
./drivers/usb/misc/usblcd.c:    retval = usb_register_dev(interface, &lcd_class);
./drivers/usb/misc/sisusbvga/sisusb.c:  if ((retval = usb_register_dev(intf, &usb_sisusb_class))) {
./drivers/usb/misc/rio500.c:    retval = usb_register_dev(intf, &usb_rio_class);
./drivers/usb/misc/adutux.c:    retval = usb_register_dev(interface, &adu_class);
./drivers/usb/misc/iowarrior.c: retval = usb_register_dev(interface, &iowarrior_class);
./drivers/usb/image/mdc800.c:   retval = usb_register_dev(intf, &mdc800_class);
./drivers/usb/usb-skeleton.c:   retval = usb_register_dev(interface, &skel_class);
./drivers/hid/usbhid/hiddev.c:  retval = usb_register_dev(usbhid->intf, &hiddev_class);
./drivers/staging/media/as102/as102_usb_drv.c:  ret = usb_register_dev(intf, &as102_usb_class_driver);
./drivers/staging/media/lirc/lirc_sasem.c:              if (usb_register_dev(interface, &sasem_class))
./drivers/staging/media/lirc/lirc_imon.c:               if (usb_register_dev(interface, &imon_class)) {
./drivers/staging/rts5139/rts51x.c:     retval = usb_register_dev(intf, &rts51x_class);
./drivers/staging/frontier/tranzport.c: retval = usb_register_dev(intf, &usb_tranzport_class);
./drivers/staging/frontier/alphatrack.c:        retval = usb_register_dev(intf, &usb_alphatrack_class);


So my (well, OK, the kids' :) LEGO Mindstorms USB tower is also
"affected": 

nemi:/tmp# ls -l /sys/class/usbmisc/
total 0
lrwxrwxrwx 1 root root 0 Aug 30 19:15 cdc-wdm0 -> ../../devices/pci0000:00/0000:00:1d.7/usb2/2-4/2-4:1.8/usbmisc/cdc-wdm0
lrwxrwxrwx 1 root root 0 Aug 30 19:15 cdc-wdm1 -> ../../devices/pci0000:00/0000:00:1d.7/usb2/2-4/2-4:1.19/usbmisc/cdc-wdm1
lrwxrwxrwx 1 root root 0 Aug 30 19:15 cdc-wdm2 -> ../../devices/pci0000:00/0000:00:1d.7/usb2/2-4/2-4:1.20/usbmisc/cdc-wdm2
lrwxrwxrwx 1 root root 0 Aug 30 19:15 legousbtower3 -> ../../devices/pci0000:00/0000:00:1d.0/usb6/6-2/6-2:1.0/usbmisc/legousbtower3

This does not cause any problem for any of the tools I know of (leJOS
and NQC).  They use a configured /dev/legousbtower3 device.  No sysfs
poking there.

BTW, hadn't thought of this before, but unrelated drivers may affect the
device naming as these drivers typically use the minor in the device
name.  Plugging in different order gives:

nemi:/tmp# ls -l /sys/class/usbmisc/
total 0
lrwxrwxrwx 1 root root 0 Aug 30 19:17 cdc-wdm1 -> ../../devices/pci0000:00/0000:00:1d.7/usb2/2-4/2-4:1.8/usbmisc/cdc-wdm1
lrwxrwxrwx 1 root root 0 Aug 30 19:17 cdc-wdm2 -> ../../devices/pci0000:00/0000:00:1d.7/usb2/2-4/2-4:1.19/usbmisc/cdc-wdm2
lrwxrwxrwx 1 root root 0 Aug 30 19:17 cdc-wdm3 -> ../../devices/pci0000:00/0000:00:1d.7/usb2/2-4/2-4:1.20/usbmisc/cdc-wdm3
lrwxrwxrwx 1 root root 0 Aug 30 19:17 legousbtower0 -> ../../devices/pci0000:00/0000:00:1d.0/usb6/6-1/6-1:1.0/usbmisc/legousbtower0

That's another reason why you must expect X != Y for wwanX and
/dev/cdc-wdmY



Bjørn