On Tue, 16 Sep 2014 15:36:42 -0400 (EDT)
Alan Stern <st...@rowland.harvard.edu> wrote:

> On Tue, 16 Sep 2014, Mark wrote:
> 
> > On Tue, 16 Sep 2014 11:40:03 -0400 (EDT)
> > Alan Stern <st...@rowland.harvard.edu> 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@suse.com/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 majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to