From e52e031498cb51aff4f80a19a56700a127cf2a9a Mon Sep 17 00:00:00 2001 From: Hans de Goede Date: Wed, 23 Oct 2013 14:27:09 +0100 Subject: uas: s/response_ui/response_iu/ Signed-off-by: Hans de Goede Signed-off-by: Sarah Sharp --- include/linux/usb/uas.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'include/linux/usb') diff --git a/include/linux/usb/uas.h b/include/linux/usb/uas.h index 5499ab5c94bd..14041780fb6c 100644 --- a/include/linux/usb/uas.h +++ b/include/linux/usb/uas.h @@ -79,7 +79,7 @@ struct sense_iu { __u8 sense[SCSI_SENSE_BUFFERSIZE]; }; -struct response_ui { +struct response_iu { __u8 iu_id; __u8 rsvd1; __be16 tag; -- cgit v1.2.3 From 00d202cc12127fe9a9fa477a78cb37e32d7f4360 Mon Sep 17 00:00:00 2001 From: Hans de Goede Date: Thu, 31 Oct 2013 09:59:12 +0100 Subject: uas: Fix response iu struct definition MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit The response iu struct before this patch has a size of 7 bytes (discounting padding), which is weird since all other iu-s are explictly padded to a multiple of 4 bytes. More over submitting a 7 byte bulk transfer to the status endpoint when expecting a response iu results in an USB babble error, as the device actually sends 8 bytes. Up on closer reading of the UAS spec: http://www.t10.org/cgi-bin/ac.pl?t=f&f=uas2r00.pdf The reason for this becomes clear, the 2 entries in "Table 17 — RESPONSE IU" are numbered 4 and 6, looking at other iu definitions in the spec, esp. multi-byte fields, this indicates that the ADDITIONAL RESPONSE INFORMATION field is not a 2 byte field as one might assume at a first look, but is a multi-byte field containing 3 bytes. This also aligns with the SCSI Architecture Model 4 spec, which UAS is based on which states in paragraph "7.1 Task management function procedure calls" that the "Additional Response Information" output argument for a Task management function procedure call is 3 bytes. Last but not least I've verified this by sending a logical unit reset task management call with an invalid lun to an actual uasp device, and received back a response-iu with byte 6 being 0, and byte 7 being 9, which is the responce code for an invalid iu, which confirms that the response code is being reported in byte 7 of the response iu rather then in byte 6. Things were working before despite this error in the response iu struct definition because the additional response info field is normally filled with zeros, and 0 is the response code value for success. Signed-off-by: Hans de Goede Signed-off-by: Sarah Sharp --- include/linux/usb/uas.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'include/linux/usb') diff --git a/include/linux/usb/uas.h b/include/linux/usb/uas.h index 14041780fb6c..772b66bcdd7d 100644 --- a/include/linux/usb/uas.h +++ b/include/linux/usb/uas.h @@ -83,7 +83,7 @@ struct response_iu { __u8 iu_id; __u8 rsvd1; __be16 tag; - __be16 add_response_info; + __u8 add_response_info[3]; __u8 response_code; }; -- cgit v1.2.3 From d24354bbf78f9194ec21087130a69b84864e50df Mon Sep 17 00:00:00 2001 From: Hans de Goede Date: Mon, 21 Oct 2013 11:15:11 +0100 Subject: uas: Pack iu struct definitions The iu struct definitions are usb packet definitions, so no alignment should happen. Notice that assuming 32 bit alignment this does not make any difference at all. Signed-off-by: Hans de Goede Signed-off-by: Sarah Sharp --- include/linux/usb/uas.h | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) (limited to 'include/linux/usb') diff --git a/include/linux/usb/uas.h b/include/linux/usb/uas.h index 772b66bcdd7d..3fc8e8b9f043 100644 --- a/include/linux/usb/uas.h +++ b/include/linux/usb/uas.h @@ -9,7 +9,7 @@ struct iu { __u8 iu_id; __u8 rsvd1; __be16 tag; -}; +} __attribute__((__packed__)); enum { IU_ID_COMMAND = 0x01, @@ -52,7 +52,7 @@ struct command_iu { __u8 rsvd7; struct scsi_lun lun; __u8 cdb[16]; /* XXX: Overflow-checking tools may misunderstand */ -}; +} __attribute__((__packed__)); struct task_mgmt_iu { __u8 iu_id; @@ -62,7 +62,7 @@ struct task_mgmt_iu { __u8 rsvd2; __be16 task_tag; struct scsi_lun lun; -}; +} __attribute__((__packed__)); /* * Also used for the Read Ready and Write Ready IUs since they have the @@ -77,7 +77,7 @@ struct sense_iu { __u8 rsvd7[7]; __be16 len; __u8 sense[SCSI_SENSE_BUFFERSIZE]; -}; +} __attribute__((__packed__)); struct response_iu { __u8 iu_id; @@ -85,7 +85,7 @@ struct response_iu { __be16 tag; __u8 add_response_info[3]; __u8 response_code; -}; +} __attribute__((__packed__)); struct usb_pipe_usage_descriptor { __u8 bLength; -- cgit v1.2.3 From 14aec589327a6fc4035f5327d90ac5548f501c4c Mon Sep 17 00:00:00 2001 From: Oliver Neukum Date: Tue, 11 Feb 2014 20:36:04 +0100 Subject: storage: accept some UAS devices if streams are unavailable On some older XHCIs streams are not supported and the UAS driver will fail at probe time. For those devices storage should try to bind to UAS devices. This patch adds a flag for stream support to HCDs and evaluates it. [Note: Sarah fixed a bug where the USB 2.0 root hub, not USB 3.0 root hub would get marked as being able to support streams.] Signed-off-by: Oliver Neukum Signed-off-by: Sarah Sharp Acked-by: Hans de Goede --- include/linux/usb/hcd.h | 1 + 1 file changed, 1 insertion(+) (limited to 'include/linux/usb') diff --git a/include/linux/usb/hcd.h b/include/linux/usb/hcd.h index efe8d8a7c7ad..485cd5e2100c 100644 --- a/include/linux/usb/hcd.h +++ b/include/linux/usb/hcd.h @@ -143,6 +143,7 @@ struct usb_hcd { unsigned authorized_default:1; unsigned has_tt:1; /* Integrated TT in root hub */ unsigned amd_resume_bug:1; /* AMD remote wakeup quirk */ + unsigned can_do_streams:1; /* HC supports streams */ unsigned int irq; /* irq allocated */ void __iomem *regs; /* device memory/io */ -- cgit v1.2.3