Skip to contentSkip to conversation

UAS driver

PATCH In review Matthew Wilcox 4 participants 8 messages Sep 28, 2010 3 messages not in the archive

Subsystems (4)
lore
Share & tools
lore
#0 lore raw

PATCH 1/1 UAS driver

Per Greg's request, here is the current UAS driver. It works quite well, and the remaining bugs can be fixed in-tree.

MAINTAINERS +8 -0
index 02f75fc..1257b49 100644
@@ -5783,6 +5783,14 @@ S:	Maintained
 F:	Documentation/usb/acm.txt
 F:	drivers/usb/class/cdc-acm.*
 
+USB ATTACHED SCSI
+M:	Matthew Wilcox <[email protected]>
+M:	Sarah Sharp <[email protected]>
+L:	[email protected]
+L:	[email protected]
+S:	Supported
+F:	drivers/usb/storage/uas.c
+
 USB BLOCK DRIVER (UB ub)
 M:	Pete Zaitcev <[email protected]>
 L:	[email protected]
drivers/usb/storage/Kconfig +13 -0
index 8a372ba..32a9513 100644
@@ -172,6 +172,19 @@ config USB_STORAGE_CYPRESS_ATACB
 
 	  If this driver is compiled as a module, it will be named ums-cypress.
 
+config USB_UAS
+	tristate "USB Attached SCSI"
+	depends on USB && SCSI
+	help
+	  The USB Attached SCSI protocol is supported by some USB
+	  storage devices.  It permits higher performance by supporting
+	  multiple outstanding commands.
+
+	  If you don't know whether you have a UAS device, it is safe to
+	  say 'Y' or 'M' here and the kernel will use the right driver.
+
+	  If you compile this driver as a module, it will be named uas.
+
 config USB_LIBUSUAL
 	bool "The shared table of common (or usual) storage devices"
 	depends on USB
drivers/usb/storage/Makefile +1 -0
index ef7e5a8..0332aa5 100644
@@ -7,6 +7,7 @@
 
 EXTRA_CFLAGS	:= -Idrivers/scsi
 
+obj-$(CONFIG_USB_UAS)		+= uas.o
 obj-$(CONFIG_USB_STORAGE)	+= usb-storage.o
 
 usb-storage-obj-$(CONFIG_USB_STORAGE_DEBUG)	+= debug.o
drivers/usb/storage/uas.c new file +749 -0

749 lines not on this page · raw message

A message that is not in the archive (sent off-list or not yet received): 20100928050733.GB3799-VuQAYsv1563Yd54FQh9/[email protected]

#2 lore raw

drivers/usb/storage/uas.c line 576

Quoted 5 lines · Matthew Wilcox
drivers/usb/storage/uas.c new file +5 -0
+static struct usb_device_id uas_usb_ids[] = {
+	{ USB_INTERFACE_INFO(8, 6, 0x50) },
+	{ USB_INTERFACE_INFO(8, 6, 0x62) },
+	{ USB_INTERFACE_INFO(8, 6, 0xaa) }, /* A prototype */
+	{ }

Don't we have the proper #defines in the usb/ch9.h file that you can use here? If not, please add them so that we don't have "magic" numbers.

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html

#3 lore raw
Quoted 9 lines · Greg KH

drivers/usb/storage/uas.c line 576

Quoted 5 lines · Matthew Wilcox
drivers/usb/storage/uas.c new file +5 -0
+static struct usb_device_id uas_usb_ids[] = {
+	{ USB_INTERFACE_INFO(8, 6, 0x50) },
+	{ USB_INTERFACE_INFO(8, 6, 0x62) },
+	{ USB_INTERFACE_INFO(8, 6, 0xaa) }, /* A prototype */
+	{ }

Don't we have the proper #defines in the usb/ch9.h file that you can use here? If not, please add them so that we don't have "magic" numbers.

We've got
#define USB_CLASS_MASS_STORAGE 8
in usb/ch9.h, which I can use.

The other numbers are in include/linux/usb_usual.h, which is actually a pain to include (I haven't figured out everything I need to do to include it).

What I'd like to do is pull the subclasses and protocols out into a new include file, include/linux/usb/storage.h to match audio.h. Would you be likely to accept such a patch?

I don't intend to add 0xaa to a header file ... I see its inclusion in this driver as a temporary thing, and I'd rather remove support for it than add it to a header.

A message that is not in the archive (sent off-list or not yet received): 20100928064549.GD3799-VuQAYsv1563Yd54FQh9/[email protected]

#5 lore raw
Quoted 11 lines · Matthew Wilcox
Quoted 9 lines · Greg KH

drivers/usb/storage/uas.c line 576

Quoted 5 lines · Matthew Wilcox
drivers/usb/storage/uas.c new file +5 -0
+static struct usb_device_id uas_usb_ids[] = {
+	{ USB_INTERFACE_INFO(8, 6, 0x50) },
+	{ USB_INTERFACE_INFO(8, 6, 0x62) },
+	{ USB_INTERFACE_INFO(8, 6, 0xaa) }, /* A prototype */
+	{ }

Don't we have the proper #defines in the usb/ch9.h file that you can use here? If not, please add them so that we don't have "magic" numbers.

Quoted 3 lines

We've got
#define USB_CLASS_MASS_STORAGE 8
in usb/ch9.h, which I can use.

Good.

Quoted 6 lines

The other numbers are in include/linux/usb_usual.h, which is actually a pain to include (I haven't figured out everything I need to do to include it).

What I'd like to do is pull the subclasses and protocols out into a new include file, include/linux/usb/storage.h to match audio.h. Would you be likely to accept such a patch?

Sure, that would make sense.

Quoted 3 lines

I don't intend to add 0xaa to a header file ... I see its inclusion in this driver as a temporary thing, and I'd rather remove support for it than add it to a header.

I'm afraid to ask what the 0xaa is, but here goes, what is it?

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html

A message that is not in the archive (sent off-list or not yet received): [email protected]

#7 lore raw
Quoted 5 lines · Greg KH
Quoted 3 lines

I don't intend to add 0xaa to a header file ... I see its inclusion in this driver as a temporary thing, and I'd rather remove support for it than add it to a header.

I'm afraid to ask what the 0xaa is, but here goes, what is it?

It's a prototype device that has the wrong protocol ID. Eventually I'll just drop support for it from the driver, but it's a useful device to keep testing with for the moment (it supports some aspects of the protocol that other devices I have access to don't).

Since nobody else is likely to have one, I'd rather take the line out of the in-tree driver and patch it back in locally, than I would add it to the header file.
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html

#8 lore raw
Quoted 7 lines · Matthew Wilcox
Quoted 5 lines · Greg KH
Quoted 3 lines

I don't intend to add 0xaa to a header file ... I see its inclusion in this driver as a temporary thing, and I'd rather remove support for it than add it to a header.

I'm afraid to ask what the 0xaa is, but here goes, what is it?

Quoted 8 lines

It's a prototype device that has the wrong protocol ID. Eventually I'll just drop support for it from the driver, but it's a useful device to keep testing with for the moment (it supports some aspects of the protocol that other devices I have access to don't).

Since nobody else is likely to have one, I'd rather take the line out of the in-tree driver and patch it back in locally, than I would add it to the header file.

Ok, that sounds good to me.

thanks,

greg k-h

#9 lore raw
Quoted 13 lines · Greg KH
Quoted 12 lines · Matthew Wilcox
Quoted 5 lines · Greg KH
Quoted 3 lines

I don't intend to add 0xaa to a header file ... I see its inclusion in this driver as a temporary thing, and I'd rather remove support for it than add it to a header.

I'm afraid to ask what the 0xaa is, but here goes, what is it?

It's a prototype device that has the wrong protocol ID. Eventually I'll just drop support for it from the driver, but it's a useful device to keep testing with for the moment (it supports some aspects of the protocol that other devices I have access to don't).

Quoted 5 lines
Quoted 3 lines

Since nobody else is likely to have one, I'd rather take the line out of the in-tree driver and patch it back in locally, than I would add it to the header file.

Ok, that sounds good to me.

Sorry, bad jetlag. You can leave it as-is for now and send me patches afterward.

thanks,

greg k-h