On Tue, 16 Sep 2014 15:36:42 -0400 (EDT) Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote: > On Tue, 16 Sep 2014, Mark wrote: > > > On Tue, 16 Sep 2014 11:40:03 -0400 (EDT) > > Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote: > > > > > On Tue, 16 Sep 2014, Mark wrote: > > > > ... > > > > Another issue relates to manufacturer USB ID screw-ups. The Buffalo > > > > USB-SCSI cable is a good example. According to the Windows INF file > > > > available from > > > > http://buffalo.jp/download/driver/hd/mos-s640usb.html > > > > its USB ID is 0411:0001. > > > > > > > > However, according to the INF file from > > > > http://buffalo.jp/download/driver/lan/lua-tx.html > > > > the LUA-TX USB-Ethernet adapter can have ID 0411:0005 or 0411:0001... sigh. > > > > > > > > Given that, would it be possible/advisable to have an unusual-devs.h entry > > > > for the Buffalo USB-SCSI cable? > > > > > > It would be nice to get confirmation first from somebody who has one of > > > those cables. > > > > Someone reported an issue related to that in 2006 on the Japanese > > debian-users list: > > http://lists.debian.or.jp/debian-users/200608/msg00010.html > > > > They were using a Debian kernel based on 2.6.17, and based on the dmesg > > output both usb-storage and pegasus drivers try to claim the device. I'll > > paste some excerpts below. > > Was the device a USB-SCSI cable or a USB-Ethernet adapter? If it was > an ethernet adapter then we don't want to include it in unusual_devs.h. > If it was a SCSI cable then we do. > > > Since a quirk entry in unusual-devs.h would only apply to usb-storage, it > > should not cause additional problems for a USB-Ethernet device with the > > same ID, right? > > It would, because it would cause usb-storage to try to bind to the > ethernet device, thereby preventing the pegasus driver from binding. > > > I guess it would be necessary to blacklist the pegasus module in order to > > use a Buffalo USB-SCSI cable (with or without quirk). > > Yes, apparently so. > > > lsusb reported > > Bus 002 Device 010: ID 0411:0001 MelCo., Inc. LUA-TX Ethernet [pegasus] > > (because that's what's in the usb.ids list for product 0411:0001) > > > > From /proc/bus/usb/devices > > > > T: Bus=02 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 10 Spd=12 MxCh= 0 > > D: Ver= 1.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1 > > P: Vendor=0411 ProdID=0001 Rev= 1.00 > > S: Manufacturer=Shuttle Technology Inc. > > S: Product=eUSCSI Bridge Ver 1.11 > > S: SerialNumber=07 > > Okay, so it was a SCSI cable. In that case, go ahead and add it to > unusual_devs.h. > > Do you know what product ID the ethernet adapter actually uses? Sadly, I think versions exist with *both* IDs 0411:0001 and 0411:0005, and the Windows INF file mentions both. Some searching gave related results... Post to linux-usb on 2000-04-02, "About MELCO LUA-TX USB LAN ADAPTOR": https://www.mail-archive.com/linux-usb@xxxxxxxx/msg00569.html That's a patch to add support to the pegasus driver for Buffalo LUA-TX with ID 0411:0001. Post to freebsd-bugs on 2000-12-12, "kern/11711: USB Ethernet LUA-TX product ID": http://marc.info/?l=netbsd-bugs&m=97665695908785 The poster has an LUA-TX with ID 0411:0005. Is it possible to add an entry to unusual-devs.h, but have usb-storage only bind to the device if it reports itself as being a USB mass storage device? Or maybe to match the manufacturer or product string? Otherwise, if I add an entry for the Buffalo USB-SCSI cable, anyone who still uses an 0411:0001 LUA-TX would have to blacklist usb-storage (or disable the quirk on the kernel command line??). Mark -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
