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-bugsm=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
Hi, On Mon, 15 Sep 2014 11:01:33 -0400 (EDT) Alan Stern st...@rowland.harvard.edu 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 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
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. 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: 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? 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 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-bugsm=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 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
