Re: Ability to specify SCM_MULT_TARG quirk on command line
On Tue, 16 Sep 2014, Mark wrote: > > 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 You could use the UNUSUAL_VENDOR_INTF macro. That will match entries based on the vendor ID and the interface class, subclass, and protocol. (Presumably the LUA-TX doesn't have an interface claiming to belong to the Mass-Storage class.) But the macro doesn't take the product ID into account. Alan Stern -- 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
Re: Ability to specify SCM_MULT_TARG quirk on command line
On Tue, 16 Sep 2014 15:36:42 -0400 (EDT) Alan Stern wrote: > On Tue, 16 Sep 2014, Mark wrote: > > > On Tue, 16 Sep 2014 11:40:03 -0400 (EDT) > > Alan Stern 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
Re: Ability to specify SCM_MULT_TARG quirk on command line
On Tue, 16 Sep 2014, Mark wrote: > On Tue, 16 Sep 2014 11:40:03 -0400 (EDT) > Alan Stern 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? Alan Stern -- 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
Re: Ability to specify SCM_MULT_TARG quirk on command line
On Tue, 16 Sep 2014 11:40:03 -0400 (EDT) Alan Stern 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. 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? I guess it would be necessary to blacklist the pegasus module in order to use a Buffalo USB-SCSI cable (with or without quirk). usb 2-1: new full speed USB device using uhci_hcd and address 4 usb 2-1: configuration #1 chosen from 1 choice Initializing USB Mass Storage driver... scsi0 : SCSI emulation for USB Mass Storage devices usbcore: registered new driver usb-storage USB Mass Storage support registered. usb-storage: device found at 4 usb-storage: waiting for device to settle before scanning pegasus: v0.6.13 (2005/11/13), Pegasus/Pegasus II USB Ethernet driver usbcore: registered new driver pegasus usb 2-1: reset full speed USB device using uhci_hcd and address 4 usb 2-1: reset full speed USB device using uhci_hcd and address 4 usb 2-1: reset full speed USB device using uhci_hcd and address 4 usb 2-1: reset full speed USB device using uhci_hcd and address 4 usb-storage: device scan complete 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 ... 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
Re: Ability to specify SCM_MULT_TARG quirk on command line
On Tue, 16 Sep 2014, Mark wrote: > > It's probably better just to rely on entries to the unusual_devs.h > > file. Those are automatically be available to anyone with an > > up-to-date kernel, with no need for messing around with module > > parameters. > > The trouble is though, that requires the user compile their own kernel. > Which may not be practical due to lack of knowledge or e.g. booting from a > live CD. This arises only if somebody has a device with multi-target capability that isn't already listed in unusual_devs.h. Since such devices are so rare, we shouldn't have to worry about this possibility. > I can submit patches for devices I don't own to cover more (hopefully > almost all) SCM-based devices, e.g. the USBConnect 2000 patch I submitted > recently. But I wasn't sure what values to use for bcdDeviceMin and > bcdDeviceMax. 0 and 0x would probably be best, so I'll repost the patch > with that change. > > 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. Alan Stern -- 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
Re: Ability to specify SCM_MULT_TARG quirk on command line
Hi, On Mon, 15 Sep 2014 11:01:33 -0400 (EDT) Alan Stern wrote: > On Sun, 14 Sep 2014, Mark wrote: > > > Shuttle Technology/SCM Microsystems was the OEM manufacturer of SCSI-USB > > converter cables sold by various companies including Adaptec [untested > > patch posted recently], Ariston Technologies, Belkin [*], Buffalo, > > Entrega/Xircom [patch posted recently], Microtech [*], Newer Technology > > [*], Olympus[*] > > *: quirk already in unusual-devs.h > > > > The ability to specify the SCM_MULT_TARG quirk on the command line could > > be useful. At least the Ariston and Buffalo products don't have entries in > > unusual-devs.h. I hope to write a patch, but would like some advice on the > > best approach. > > Devices with this capability are so rare, it didn't seem worthwhile > adding it to the list of recognized quirks for the module parameter. > > > ... > > Is one of those options preferable? Or maybe something else? > > It's probably better just to rely on entries to the unusual_devs.h > file. Those are automatically be available to anyone with an > up-to-date kernel, with no need for messing around with module > parameters. The trouble is though, that requires the user compile their own kernel. Which may not be practical due to lack of knowledge or e.g. booting from a live CD. I can submit patches for devices I don't own to cover more (hopefully almost all) SCM-based devices, e.g. the USBConnect 2000 patch I submitted recently. But I wasn't sure what values to use for bcdDeviceMin and bcdDeviceMax. 0 and 0x would probably be best, so I'll repost the patch with that change. 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? 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
Re: Ability to specify SCM_MULT_TARG quirk on command line
On Sun, 14 Sep 2014, Mark wrote:
> Hi,
>
> Shuttle Technology/SCM Microsystems was the OEM manufacturer of SCSI-USB
> converter cables sold by various companies including Adaptec [untested
> patch posted recently], Ariston Technologies, Belkin [*], Buffalo,
> Entrega/Xircom [patch posted recently], Microtech [*], Newer Technology
> [*], Olympus[*]
> *: quirk already in unusual-devs.h
>
> The ability to specify the SCM_MULT_TARG quirk on the command line could
> be useful. At least the Ariston and Buffalo products don't have entries in
> unusual-devs.h. I hope to write a patch, but would like some advice on the
> best approach.
Devices with this capability are so rare, it didn't seem worthwhile
adding it to the list of recognized quirks for the module parameter.
> The letter "t" is free; should I use that to signify the SCM_MULT_TARG
> quirk? In usb_stor_adjust_quirks() I'd add
> case 't':
> f |= US_FL_SCM_MULT_TARG;
> break;
>
> usb_stor_euscsi_init is the initFunction for all SCM_MULT_TARG quirks. In
> get_device_info(), after the call to usb_stor_adjust_quirks() I could add
> code like
> if (us->fflags & US_FL_SCM_MULT_TARG) {
> unusual_dev->initFunction = usb_stor_euscsi_init;
> }
>
> Alternatively, similar code could be added before the call to initFunction
> in usb_stor_acquire_resources():
> if (us->fflags & US_FL_SCM_MULT_TARG) {
> us->unusual_dev->initFunction = usb_stor_euscsi_init;
> }
>
> /* Just before we start our control thread, initialize
>* the device if it needs initialization */
> if (us->unusual_dev->initFunction) {
> p = us->unusual_dev->initFunction(us);
> ...
>
> Is one of those options preferable? Or maybe something else?
It's probably better just to rely on entries to the unusual_devs.h
file. Those are automatically be available to anyone with an
up-to-date kernel, with no need for messing around with module
parameters.
Alan Stern
--
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
Ability to specify SCM_MULT_TARG quirk on command line
Hi,
Shuttle Technology/SCM Microsystems was the OEM manufacturer of SCSI-USB
converter cables sold by various companies including Adaptec [untested
patch posted recently], Ariston Technologies, Belkin [*], Buffalo,
Entrega/Xircom [patch posted recently], Microtech [*], Newer Technology
[*], Olympus[*]
*: quirk already in unusual-devs.h
The ability to specify the SCM_MULT_TARG quirk on the command line could
be useful. At least the Ariston and Buffalo products don't have entries in
unusual-devs.h. I hope to write a patch, but would like some advice on the
best approach.
The letter "t" is free; should I use that to signify the SCM_MULT_TARG
quirk? In usb_stor_adjust_quirks() I'd add
case 't':
f |= US_FL_SCM_MULT_TARG;
break;
usb_stor_euscsi_init is the initFunction for all SCM_MULT_TARG quirks. In
get_device_info(), after the call to usb_stor_adjust_quirks() I could add
code like
if (us->fflags & US_FL_SCM_MULT_TARG) {
unusual_dev->initFunction = usb_stor_euscsi_init;
}
Alternatively, similar code could be added before the call to initFunction
in usb_stor_acquire_resources():
if (us->fflags & US_FL_SCM_MULT_TARG) {
us->unusual_dev->initFunction = usb_stor_euscsi_init;
}
/* Just before we start our control thread, initialize
* the device if it needs initialization */
if (us->unusual_dev->initFunction) {
p = us->unusual_dev->initFunction(us);
...
Is one of those options preferable? Or maybe something else?
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
