2012-06-08 16:03:37 +02:00
|
|
|
/*
|
|
|
|
* UAS (USB Attached SCSI) emulation
|
|
|
|
*
|
|
|
|
* Copyright Red Hat, Inc. 2012
|
|
|
|
*
|
|
|
|
* Author: Gerd Hoffmann <kraxel@redhat.com>
|
|
|
|
*
|
|
|
|
* This work is licensed under the terms of the GNU GPL, version 2 or later.
|
|
|
|
* See the COPYING file in the top-level directory.
|
|
|
|
*/
|
|
|
|
|
|
|
|
#include "qemu-common.h"
|
2012-12-17 18:20:00 +01:00
|
|
|
#include "qemu/option.h"
|
|
|
|
#include "qemu/config-file.h"
|
2012-06-08 16:03:37 +02:00
|
|
|
#include "trace.h"
|
|
|
|
|
|
|
|
#include "hw/usb.h"
|
|
|
|
#include "hw/usb/desc.h"
|
2013-02-05 17:06:20 +01:00
|
|
|
#include "hw/scsi/scsi.h"
|
|
|
|
#include "block/scsi.h"
|
2012-06-08 16:03:37 +02:00
|
|
|
|
|
|
|
/* --------------------------------------------------------------------- */
|
|
|
|
|
|
|
|
#define UAS_UI_COMMAND 0x01
|
|
|
|
#define UAS_UI_SENSE 0x03
|
|
|
|
#define UAS_UI_RESPONSE 0x04
|
|
|
|
#define UAS_UI_TASK_MGMT 0x05
|
|
|
|
#define UAS_UI_READ_READY 0x06
|
|
|
|
#define UAS_UI_WRITE_READY 0x07
|
|
|
|
|
|
|
|
#define UAS_RC_TMF_COMPLETE 0x00
|
|
|
|
#define UAS_RC_INVALID_INFO_UNIT 0x02
|
|
|
|
#define UAS_RC_TMF_NOT_SUPPORTED 0x04
|
|
|
|
#define UAS_RC_TMF_FAILED 0x05
|
|
|
|
#define UAS_RC_TMF_SUCCEEDED 0x08
|
|
|
|
#define UAS_RC_INCORRECT_LUN 0x09
|
|
|
|
#define UAS_RC_OVERLAPPED_TAG 0x0a
|
|
|
|
|
|
|
|
#define UAS_TMF_ABORT_TASK 0x01
|
|
|
|
#define UAS_TMF_ABORT_TASK_SET 0x02
|
|
|
|
#define UAS_TMF_CLEAR_TASK_SET 0x04
|
|
|
|
#define UAS_TMF_LOGICAL_UNIT_RESET 0x08
|
|
|
|
#define UAS_TMF_I_T_NEXUS_RESET 0x10
|
|
|
|
#define UAS_TMF_CLEAR_ACA 0x40
|
|
|
|
#define UAS_TMF_QUERY_TASK 0x80
|
|
|
|
#define UAS_TMF_QUERY_TASK_SET 0x81
|
|
|
|
#define UAS_TMF_QUERY_ASYNC_EVENT 0x82
|
|
|
|
|
|
|
|
#define UAS_PIPE_ID_COMMAND 0x01
|
|
|
|
#define UAS_PIPE_ID_STATUS 0x02
|
|
|
|
#define UAS_PIPE_ID_DATA_IN 0x03
|
|
|
|
#define UAS_PIPE_ID_DATA_OUT 0x04
|
|
|
|
|
|
|
|
typedef struct {
|
|
|
|
uint8_t id;
|
|
|
|
uint8_t reserved;
|
|
|
|
uint16_t tag;
|
2013-11-19 14:37:04 +01:00
|
|
|
} QEMU_PACKED uas_iu_header;
|
2012-06-08 16:03:37 +02:00
|
|
|
|
|
|
|
typedef struct {
|
|
|
|
uint8_t prio_taskattr; /* 6:3 priority, 2:0 task attribute */
|
|
|
|
uint8_t reserved_1;
|
|
|
|
uint8_t add_cdb_length; /* 7:2 additional adb length (dwords) */
|
|
|
|
uint8_t reserved_2;
|
|
|
|
uint64_t lun;
|
|
|
|
uint8_t cdb[16];
|
|
|
|
uint8_t add_cdb[];
|
2013-11-19 14:37:04 +01:00
|
|
|
} QEMU_PACKED uas_iu_command;
|
2012-06-08 16:03:37 +02:00
|
|
|
|
|
|
|
typedef struct {
|
|
|
|
uint16_t status_qualifier;
|
|
|
|
uint8_t status;
|
|
|
|
uint8_t reserved[7];
|
|
|
|
uint16_t sense_length;
|
|
|
|
uint8_t sense_data[18];
|
2013-11-19 14:37:04 +01:00
|
|
|
} QEMU_PACKED uas_iu_sense;
|
2012-06-08 16:03:37 +02:00
|
|
|
|
|
|
|
typedef struct {
|
uas: Fix response iu struct definition
This patch mirrors a patch to the Linux uas kernel driver which I've just
submitted. It looks like the qemu uas struct definitions were taken from
the Linux kernel driver, and have inherited the same mistake.
Besides fixing the response iu struct, the patch also drops the add_info
parameter from the usb_uas_queue_response() function, it is always 0 anyways,
and expressing 3 zero-bytes as a function argument is a bit hard.
Below is the long explanation for this change taken from the kernel commit:
The response iu struct before this patch has a size of 7 bytes, which is weird
since all other iu-s are explictly padded to a multiple of 4 bytes.
Submitting a 7 byte bulk transfer to the status endpoint of a real uasp device
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.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2013-10-31 10:35:31 +01:00
|
|
|
uint8_t add_response_info[3];
|
2012-06-08 16:03:37 +02:00
|
|
|
uint8_t response_code;
|
2013-11-19 14:37:04 +01:00
|
|
|
} QEMU_PACKED uas_iu_response;
|
2012-06-08 16:03:37 +02:00
|
|
|
|
|
|
|
typedef struct {
|
|
|
|
uint8_t function;
|
|
|
|
uint8_t reserved;
|
|
|
|
uint16_t task_tag;
|
|
|
|
uint64_t lun;
|
2013-11-19 14:37:04 +01:00
|
|
|
} QEMU_PACKED uas_iu_task_mgmt;
|
2012-06-08 16:03:37 +02:00
|
|
|
|
|
|
|
typedef struct {
|
2013-11-19 14:37:04 +01:00
|
|
|
uas_iu_header hdr;
|
2012-06-08 16:03:37 +02:00
|
|
|
union {
|
2013-11-19 14:37:04 +01:00
|
|
|
uas_iu_command command;
|
|
|
|
uas_iu_sense sense;
|
|
|
|
uas_iu_task_mgmt task;
|
|
|
|
uas_iu_response response;
|
2012-06-08 16:03:37 +02:00
|
|
|
};
|
2013-11-19 14:37:04 +01:00
|
|
|
} QEMU_PACKED uas_iu;
|
2012-06-08 16:03:37 +02:00
|
|
|
|
|
|
|
/* --------------------------------------------------------------------- */
|
|
|
|
|
2013-01-25 17:38:59 +01:00
|
|
|
#define UAS_STREAM_BM_ATTR 4
|
|
|
|
#define UAS_MAX_STREAMS (1 << UAS_STREAM_BM_ATTR)
|
|
|
|
|
2012-06-08 16:03:37 +02:00
|
|
|
typedef struct UASDevice UASDevice;
|
|
|
|
typedef struct UASRequest UASRequest;
|
|
|
|
typedef struct UASStatus UASStatus;
|
|
|
|
|
|
|
|
struct UASDevice {
|
|
|
|
USBDevice dev;
|
|
|
|
SCSIBus bus;
|
|
|
|
QEMUBH *status_bh;
|
|
|
|
QTAILQ_HEAD(, UASStatus) results;
|
|
|
|
QTAILQ_HEAD(, UASRequest) requests;
|
2013-01-25 17:38:59 +01:00
|
|
|
|
2013-08-27 14:54:44 +02:00
|
|
|
/* properties */
|
|
|
|
uint32_t requestlog;
|
|
|
|
|
2013-01-25 17:38:59 +01:00
|
|
|
/* usb 2.0 only */
|
|
|
|
USBPacket *status2;
|
|
|
|
UASRequest *datain2;
|
|
|
|
UASRequest *dataout2;
|
|
|
|
|
|
|
|
/* usb 3.0 only */
|
2013-10-24 19:15:52 +02:00
|
|
|
USBPacket *data3[UAS_MAX_STREAMS + 1];
|
|
|
|
USBPacket *status3[UAS_MAX_STREAMS + 1];
|
2012-06-08 16:03:37 +02:00
|
|
|
};
|
|
|
|
|
|
|
|
struct UASRequest {
|
|
|
|
uint16_t tag;
|
|
|
|
uint64_t lun;
|
|
|
|
UASDevice *uas;
|
|
|
|
SCSIDevice *dev;
|
|
|
|
SCSIRequest *req;
|
|
|
|
USBPacket *data;
|
|
|
|
bool data_async;
|
|
|
|
bool active;
|
|
|
|
bool complete;
|
|
|
|
uint32_t buf_off;
|
|
|
|
uint32_t buf_size;
|
|
|
|
uint32_t data_off;
|
|
|
|
uint32_t data_size;
|
|
|
|
QTAILQ_ENTRY(UASRequest) next;
|
|
|
|
};
|
|
|
|
|
|
|
|
struct UASStatus {
|
2013-01-25 17:38:59 +01:00
|
|
|
uint32_t stream;
|
2013-11-19 14:37:04 +01:00
|
|
|
uas_iu status;
|
2012-06-08 16:03:37 +02:00
|
|
|
uint32_t length;
|
|
|
|
QTAILQ_ENTRY(UASStatus) next;
|
|
|
|
};
|
|
|
|
|
|
|
|
/* --------------------------------------------------------------------- */
|
|
|
|
|
|
|
|
enum {
|
|
|
|
STR_MANUFACTURER = 1,
|
|
|
|
STR_PRODUCT,
|
|
|
|
STR_SERIALNUMBER,
|
|
|
|
STR_CONFIG_HIGH,
|
2013-01-25 17:38:59 +01:00
|
|
|
STR_CONFIG_SUPER,
|
2012-06-08 16:03:37 +02:00
|
|
|
};
|
|
|
|
|
|
|
|
static const USBDescStrings desc_strings = {
|
|
|
|
[STR_MANUFACTURER] = "QEMU",
|
|
|
|
[STR_PRODUCT] = "USB Attached SCSI HBA",
|
|
|
|
[STR_SERIALNUMBER] = "27842",
|
|
|
|
[STR_CONFIG_HIGH] = "High speed config (usb 2.0)",
|
2013-01-25 17:38:59 +01:00
|
|
|
[STR_CONFIG_SUPER] = "Super speed config (usb 3.0)",
|
2012-06-08 16:03:37 +02:00
|
|
|
};
|
|
|
|
|
|
|
|
static const USBDescIface desc_iface_high = {
|
|
|
|
.bInterfaceNumber = 0,
|
|
|
|
.bNumEndpoints = 4,
|
|
|
|
.bInterfaceClass = USB_CLASS_MASS_STORAGE,
|
|
|
|
.bInterfaceSubClass = 0x06, /* SCSI */
|
|
|
|
.bInterfaceProtocol = 0x62, /* UAS */
|
|
|
|
.eps = (USBDescEndpoint[]) {
|
|
|
|
{
|
|
|
|
.bEndpointAddress = USB_DIR_OUT | UAS_PIPE_ID_COMMAND,
|
|
|
|
.bmAttributes = USB_ENDPOINT_XFER_BULK,
|
|
|
|
.wMaxPacketSize = 512,
|
|
|
|
.extra = (uint8_t[]) {
|
|
|
|
0x04, /* u8 bLength */
|
|
|
|
0x24, /* u8 bDescriptorType */
|
|
|
|
UAS_PIPE_ID_COMMAND,
|
|
|
|
0x00, /* u8 bReserved */
|
|
|
|
},
|
|
|
|
},{
|
|
|
|
.bEndpointAddress = USB_DIR_IN | UAS_PIPE_ID_STATUS,
|
|
|
|
.bmAttributes = USB_ENDPOINT_XFER_BULK,
|
|
|
|
.wMaxPacketSize = 512,
|
|
|
|
.extra = (uint8_t[]) {
|
|
|
|
0x04, /* u8 bLength */
|
|
|
|
0x24, /* u8 bDescriptorType */
|
|
|
|
UAS_PIPE_ID_STATUS,
|
|
|
|
0x00, /* u8 bReserved */
|
|
|
|
},
|
|
|
|
},{
|
|
|
|
.bEndpointAddress = USB_DIR_IN | UAS_PIPE_ID_DATA_IN,
|
|
|
|
.bmAttributes = USB_ENDPOINT_XFER_BULK,
|
|
|
|
.wMaxPacketSize = 512,
|
|
|
|
.extra = (uint8_t[]) {
|
|
|
|
0x04, /* u8 bLength */
|
|
|
|
0x24, /* u8 bDescriptorType */
|
|
|
|
UAS_PIPE_ID_DATA_IN,
|
|
|
|
0x00, /* u8 bReserved */
|
|
|
|
},
|
|
|
|
},{
|
|
|
|
.bEndpointAddress = USB_DIR_OUT | UAS_PIPE_ID_DATA_OUT,
|
|
|
|
.bmAttributes = USB_ENDPOINT_XFER_BULK,
|
|
|
|
.wMaxPacketSize = 512,
|
|
|
|
.extra = (uint8_t[]) {
|
|
|
|
0x04, /* u8 bLength */
|
|
|
|
0x24, /* u8 bDescriptorType */
|
|
|
|
UAS_PIPE_ID_DATA_OUT,
|
|
|
|
0x00, /* u8 bReserved */
|
|
|
|
},
|
|
|
|
},
|
|
|
|
}
|
|
|
|
};
|
|
|
|
|
2013-01-25 17:38:59 +01:00
|
|
|
static const USBDescIface desc_iface_super = {
|
|
|
|
.bInterfaceNumber = 0,
|
|
|
|
.bNumEndpoints = 4,
|
|
|
|
.bInterfaceClass = USB_CLASS_MASS_STORAGE,
|
|
|
|
.bInterfaceSubClass = 0x06, /* SCSI */
|
|
|
|
.bInterfaceProtocol = 0x62, /* UAS */
|
|
|
|
.eps = (USBDescEndpoint[]) {
|
|
|
|
{
|
|
|
|
.bEndpointAddress = USB_DIR_OUT | UAS_PIPE_ID_COMMAND,
|
|
|
|
.bmAttributes = USB_ENDPOINT_XFER_BULK,
|
|
|
|
.wMaxPacketSize = 1024,
|
|
|
|
.bMaxBurst = 15,
|
|
|
|
.extra = (uint8_t[]) {
|
|
|
|
0x04, /* u8 bLength */
|
|
|
|
0x24, /* u8 bDescriptorType */
|
|
|
|
UAS_PIPE_ID_COMMAND,
|
|
|
|
0x00, /* u8 bReserved */
|
|
|
|
},
|
|
|
|
},{
|
|
|
|
.bEndpointAddress = USB_DIR_IN | UAS_PIPE_ID_STATUS,
|
|
|
|
.bmAttributes = USB_ENDPOINT_XFER_BULK,
|
|
|
|
.wMaxPacketSize = 1024,
|
|
|
|
.bMaxBurst = 15,
|
|
|
|
.bmAttributes_super = UAS_STREAM_BM_ATTR,
|
|
|
|
.extra = (uint8_t[]) {
|
|
|
|
0x04, /* u8 bLength */
|
|
|
|
0x24, /* u8 bDescriptorType */
|
|
|
|
UAS_PIPE_ID_STATUS,
|
|
|
|
0x00, /* u8 bReserved */
|
|
|
|
},
|
|
|
|
},{
|
|
|
|
.bEndpointAddress = USB_DIR_IN | UAS_PIPE_ID_DATA_IN,
|
|
|
|
.bmAttributes = USB_ENDPOINT_XFER_BULK,
|
|
|
|
.wMaxPacketSize = 1024,
|
|
|
|
.bMaxBurst = 15,
|
|
|
|
.bmAttributes_super = UAS_STREAM_BM_ATTR,
|
|
|
|
.extra = (uint8_t[]) {
|
|
|
|
0x04, /* u8 bLength */
|
|
|
|
0x24, /* u8 bDescriptorType */
|
|
|
|
UAS_PIPE_ID_DATA_IN,
|
|
|
|
0x00, /* u8 bReserved */
|
|
|
|
},
|
|
|
|
},{
|
|
|
|
.bEndpointAddress = USB_DIR_OUT | UAS_PIPE_ID_DATA_OUT,
|
|
|
|
.bmAttributes = USB_ENDPOINT_XFER_BULK,
|
|
|
|
.wMaxPacketSize = 1024,
|
|
|
|
.bMaxBurst = 15,
|
|
|
|
.bmAttributes_super = UAS_STREAM_BM_ATTR,
|
|
|
|
.extra = (uint8_t[]) {
|
|
|
|
0x04, /* u8 bLength */
|
|
|
|
0x24, /* u8 bDescriptorType */
|
|
|
|
UAS_PIPE_ID_DATA_OUT,
|
|
|
|
0x00, /* u8 bReserved */
|
|
|
|
},
|
|
|
|
},
|
|
|
|
}
|
|
|
|
};
|
|
|
|
|
2012-06-08 16:03:37 +02:00
|
|
|
static const USBDescDevice desc_device_high = {
|
|
|
|
.bcdUSB = 0x0200,
|
|
|
|
.bMaxPacketSize0 = 64,
|
|
|
|
.bNumConfigurations = 1,
|
|
|
|
.confs = (USBDescConfig[]) {
|
|
|
|
{
|
|
|
|
.bNumInterfaces = 1,
|
|
|
|
.bConfigurationValue = 1,
|
|
|
|
.iConfiguration = STR_CONFIG_HIGH,
|
|
|
|
.bmAttributes = 0xc0,
|
|
|
|
.nif = 1,
|
|
|
|
.ifs = &desc_iface_high,
|
|
|
|
},
|
|
|
|
},
|
|
|
|
};
|
|
|
|
|
2013-01-25 17:38:59 +01:00
|
|
|
static const USBDescDevice desc_device_super = {
|
|
|
|
.bcdUSB = 0x0300,
|
|
|
|
.bMaxPacketSize0 = 64,
|
|
|
|
.bNumConfigurations = 1,
|
|
|
|
.confs = (USBDescConfig[]) {
|
|
|
|
{
|
|
|
|
.bNumInterfaces = 1,
|
|
|
|
.bConfigurationValue = 1,
|
|
|
|
.iConfiguration = STR_CONFIG_SUPER,
|
|
|
|
.bmAttributes = 0xc0,
|
|
|
|
.nif = 1,
|
|
|
|
.ifs = &desc_iface_super,
|
|
|
|
},
|
|
|
|
},
|
|
|
|
};
|
|
|
|
|
2012-06-08 16:03:37 +02:00
|
|
|
static const USBDesc desc = {
|
|
|
|
.id = {
|
|
|
|
.idVendor = 0x46f4, /* CRC16() of "QEMU" */
|
2012-08-10 13:06:05 +02:00
|
|
|
.idProduct = 0x0003,
|
2012-06-08 16:03:37 +02:00
|
|
|
.bcdDevice = 0,
|
|
|
|
.iManufacturer = STR_MANUFACTURER,
|
|
|
|
.iProduct = STR_PRODUCT,
|
|
|
|
.iSerialNumber = STR_SERIALNUMBER,
|
|
|
|
},
|
2013-01-25 17:38:59 +01:00
|
|
|
.high = &desc_device_high,
|
|
|
|
.super = &desc_device_super,
|
|
|
|
.str = desc_strings,
|
2012-06-08 16:03:37 +02:00
|
|
|
};
|
|
|
|
|
|
|
|
/* --------------------------------------------------------------------- */
|
|
|
|
|
2013-01-25 17:38:59 +01:00
|
|
|
static bool uas_using_streams(UASDevice *uas)
|
|
|
|
{
|
|
|
|
return uas->dev.speed == USB_SPEED_SUPER;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* --------------------------------------------------------------------- */
|
|
|
|
|
|
|
|
static UASStatus *usb_uas_alloc_status(UASDevice *uas, uint8_t id, uint16_t tag)
|
2012-06-08 16:03:37 +02:00
|
|
|
{
|
|
|
|
UASStatus *st = g_new0(UASStatus, 1);
|
|
|
|
|
|
|
|
st->status.hdr.id = id;
|
|
|
|
st->status.hdr.tag = cpu_to_be16(tag);
|
2013-11-19 14:37:04 +01:00
|
|
|
st->length = sizeof(uas_iu_header);
|
2013-01-25 17:38:59 +01:00
|
|
|
if (uas_using_streams(uas)) {
|
|
|
|
st->stream = tag;
|
|
|
|
}
|
2012-06-08 16:03:37 +02:00
|
|
|
return st;
|
|
|
|
}
|
|
|
|
|
|
|
|
static void usb_uas_send_status_bh(void *opaque)
|
|
|
|
{
|
|
|
|
UASDevice *uas = opaque;
|
2013-01-25 17:38:59 +01:00
|
|
|
UASStatus *st;
|
|
|
|
USBPacket *p;
|
2012-06-08 16:03:37 +02:00
|
|
|
|
2013-01-25 17:38:59 +01:00
|
|
|
while ((st = QTAILQ_FIRST(&uas->results)) != NULL) {
|
|
|
|
if (uas_using_streams(uas)) {
|
|
|
|
p = uas->status3[st->stream];
|
|
|
|
uas->status3[st->stream] = NULL;
|
|
|
|
} else {
|
|
|
|
p = uas->status2;
|
|
|
|
uas->status2 = NULL;
|
|
|
|
}
|
|
|
|
if (p == NULL) {
|
|
|
|
break;
|
|
|
|
}
|
2012-06-08 16:03:37 +02:00
|
|
|
|
2013-01-25 17:38:59 +01:00
|
|
|
usb_packet_copy(p, &st->status, st->length);
|
|
|
|
QTAILQ_REMOVE(&uas->results, st, next);
|
|
|
|
g_free(st);
|
2012-06-08 16:03:37 +02:00
|
|
|
|
2013-01-25 17:38:59 +01:00
|
|
|
p->status = USB_RET_SUCCESS; /* Clear previous ASYNC status */
|
|
|
|
usb_packet_complete(&uas->dev, p);
|
|
|
|
}
|
2012-06-08 16:03:37 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
static void usb_uas_queue_status(UASDevice *uas, UASStatus *st, int length)
|
|
|
|
{
|
2013-01-25 17:38:59 +01:00
|
|
|
USBPacket *p = uas_using_streams(uas) ?
|
|
|
|
uas->status3[st->stream] : uas->status2;
|
|
|
|
|
2012-06-08 16:03:37 +02:00
|
|
|
st->length += length;
|
|
|
|
QTAILQ_INSERT_TAIL(&uas->results, st, next);
|
2013-01-25 17:38:59 +01:00
|
|
|
if (p) {
|
2012-06-08 16:03:37 +02:00
|
|
|
/*
|
|
|
|
* Just schedule bh make sure any in-flight data transaction
|
|
|
|
* is finished before completing (sending) the status packet.
|
|
|
|
*/
|
|
|
|
qemu_bh_schedule(uas->status_bh);
|
|
|
|
} else {
|
|
|
|
USBEndpoint *ep = usb_ep_get(&uas->dev, USB_TOKEN_IN,
|
|
|
|
UAS_PIPE_ID_STATUS);
|
2013-01-25 17:38:59 +01:00
|
|
|
usb_wakeup(ep, st->stream);
|
2012-06-08 16:03:37 +02:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
uas: Fix response iu struct definition
This patch mirrors a patch to the Linux uas kernel driver which I've just
submitted. It looks like the qemu uas struct definitions were taken from
the Linux kernel driver, and have inherited the same mistake.
Besides fixing the response iu struct, the patch also drops the add_info
parameter from the usb_uas_queue_response() function, it is always 0 anyways,
and expressing 3 zero-bytes as a function argument is a bit hard.
Below is the long explanation for this change taken from the kernel commit:
The response iu struct before this patch has a size of 7 bytes, which is weird
since all other iu-s are explictly padded to a multiple of 4 bytes.
Submitting a 7 byte bulk transfer to the status endpoint of a real uasp device
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.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2013-10-31 10:35:31 +01:00
|
|
|
static void usb_uas_queue_response(UASDevice *uas, uint16_t tag, uint8_t code)
|
2012-06-08 16:03:37 +02:00
|
|
|
{
|
2013-01-25 17:38:59 +01:00
|
|
|
UASStatus *st = usb_uas_alloc_status(uas, UAS_UI_RESPONSE, tag);
|
2012-06-08 16:03:37 +02:00
|
|
|
|
|
|
|
trace_usb_uas_response(uas->dev.addr, tag, code);
|
|
|
|
st->status.response.response_code = code;
|
2013-11-19 14:37:04 +01:00
|
|
|
usb_uas_queue_status(uas, st, sizeof(uas_iu_response));
|
2012-06-08 16:03:37 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
static void usb_uas_queue_sense(UASRequest *req, uint8_t status)
|
|
|
|
{
|
2013-01-25 17:38:59 +01:00
|
|
|
UASStatus *st = usb_uas_alloc_status(req->uas, UAS_UI_SENSE, req->tag);
|
2012-06-08 16:03:37 +02:00
|
|
|
int len, slen = 0;
|
|
|
|
|
|
|
|
trace_usb_uas_sense(req->uas->dev.addr, req->tag, status);
|
|
|
|
st->status.sense.status = status;
|
|
|
|
st->status.sense.status_qualifier = cpu_to_be16(0);
|
|
|
|
if (status != GOOD) {
|
|
|
|
slen = scsi_req_get_sense(req->req, st->status.sense.sense_data,
|
|
|
|
sizeof(st->status.sense.sense_data));
|
|
|
|
st->status.sense.sense_length = cpu_to_be16(slen);
|
|
|
|
}
|
2013-11-19 14:37:04 +01:00
|
|
|
len = sizeof(uas_iu_sense) - sizeof(st->status.sense.sense_data) + slen;
|
2012-06-08 16:03:37 +02:00
|
|
|
usb_uas_queue_status(req->uas, st, len);
|
|
|
|
}
|
|
|
|
|
2013-10-24 19:15:50 +02:00
|
|
|
static void usb_uas_queue_fake_sense(UASDevice *uas, uint16_t tag,
|
|
|
|
struct SCSISense sense)
|
|
|
|
{
|
|
|
|
UASStatus *st = usb_uas_alloc_status(uas, UAS_UI_SENSE, tag);
|
|
|
|
int len, slen = 0;
|
|
|
|
|
|
|
|
st->status.sense.status = CHECK_CONDITION;
|
|
|
|
st->status.sense.status_qualifier = cpu_to_be16(0);
|
|
|
|
st->status.sense.sense_data[0] = 0x70;
|
|
|
|
st->status.sense.sense_data[2] = sense.key;
|
|
|
|
st->status.sense.sense_data[7] = 10;
|
|
|
|
st->status.sense.sense_data[12] = sense.asc;
|
|
|
|
st->status.sense.sense_data[13] = sense.ascq;
|
|
|
|
slen = 18;
|
2013-11-19 14:37:04 +01:00
|
|
|
len = sizeof(uas_iu_sense) - sizeof(st->status.sense.sense_data) + slen;
|
2013-10-24 19:15:50 +02:00
|
|
|
usb_uas_queue_status(uas, st, len);
|
|
|
|
}
|
|
|
|
|
2012-06-08 16:03:37 +02:00
|
|
|
static void usb_uas_queue_read_ready(UASRequest *req)
|
|
|
|
{
|
2013-01-25 17:38:59 +01:00
|
|
|
UASStatus *st = usb_uas_alloc_status(req->uas, UAS_UI_READ_READY,
|
|
|
|
req->tag);
|
2012-06-08 16:03:37 +02:00
|
|
|
|
|
|
|
trace_usb_uas_read_ready(req->uas->dev.addr, req->tag);
|
|
|
|
usb_uas_queue_status(req->uas, st, 0);
|
|
|
|
}
|
|
|
|
|
|
|
|
static void usb_uas_queue_write_ready(UASRequest *req)
|
|
|
|
{
|
2013-01-25 17:38:59 +01:00
|
|
|
UASStatus *st = usb_uas_alloc_status(req->uas, UAS_UI_WRITE_READY,
|
|
|
|
req->tag);
|
2012-06-08 16:03:37 +02:00
|
|
|
|
|
|
|
trace_usb_uas_write_ready(req->uas->dev.addr, req->tag);
|
|
|
|
usb_uas_queue_status(req->uas, st, 0);
|
|
|
|
}
|
|
|
|
|
|
|
|
/* --------------------------------------------------------------------- */
|
|
|
|
|
|
|
|
static int usb_uas_get_lun(uint64_t lun64)
|
|
|
|
{
|
|
|
|
return (lun64 >> 48) & 0xff;
|
|
|
|
}
|
|
|
|
|
|
|
|
static SCSIDevice *usb_uas_get_dev(UASDevice *uas, uint64_t lun64)
|
|
|
|
{
|
|
|
|
if ((lun64 >> 56) != 0x00) {
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
return scsi_device_find(&uas->bus, 0, 0, usb_uas_get_lun(lun64));
|
|
|
|
}
|
|
|
|
|
|
|
|
static void usb_uas_complete_data_packet(UASRequest *req)
|
|
|
|
{
|
|
|
|
USBPacket *p;
|
|
|
|
|
|
|
|
if (!req->data_async) {
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
p = req->data;
|
|
|
|
req->data = NULL;
|
|
|
|
req->data_async = false;
|
usb: split packet result into actual_length + status
Since with the ehci and xhci controllers a single packet can be larger
then maxpacketsize, it is possible for the result of a single packet
to be both having transferred some data as well as the transfer to have
an error.
An example would be an input transfer from a bulk endpoint successfully
receiving 1 or more maxpacketsize packets from the device, followed
by a packet signalling halt.
While already touching all the devices and controllers handle_packet /
handle_data / handle_control code, also change the return type of
these functions to void, solely storing the status in the packet. To
make the code paths for regular versus async packet handling more
uniform.
This patch unfortunately is somewhat invasive, since makeing the qemu
usb core deal with this requires changes everywhere. This patch only
prepares the usb core for this, all the hcd / device changes are done
in such a way that there are no functional changes.
This patch has been tested with uhci and ehci hcds, together with usb-audio,
usb-hid and usb-storage devices, as well as with usb-redir redirection
with a wide variety of real devices.
Note that there is usually no need to directly set packet->actual_length
form devices handle_data callback, as that is done by usb_packet_copy()
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2012-11-01 17:15:01 +01:00
|
|
|
p->status = USB_RET_SUCCESS; /* Clear previous ASYNC status */
|
2012-06-08 16:03:37 +02:00
|
|
|
usb_packet_complete(&req->uas->dev, p);
|
|
|
|
}
|
|
|
|
|
|
|
|
static void usb_uas_copy_data(UASRequest *req)
|
|
|
|
{
|
|
|
|
uint32_t length;
|
|
|
|
|
|
|
|
length = MIN(req->buf_size - req->buf_off,
|
usb: split packet result into actual_length + status
Since with the ehci and xhci controllers a single packet can be larger
then maxpacketsize, it is possible for the result of a single packet
to be both having transferred some data as well as the transfer to have
an error.
An example would be an input transfer from a bulk endpoint successfully
receiving 1 or more maxpacketsize packets from the device, followed
by a packet signalling halt.
While already touching all the devices and controllers handle_packet /
handle_data / handle_control code, also change the return type of
these functions to void, solely storing the status in the packet. To
make the code paths for regular versus async packet handling more
uniform.
This patch unfortunately is somewhat invasive, since makeing the qemu
usb core deal with this requires changes everywhere. This patch only
prepares the usb core for this, all the hcd / device changes are done
in such a way that there are no functional changes.
This patch has been tested with uhci and ehci hcds, together with usb-audio,
usb-hid and usb-storage devices, as well as with usb-redir redirection
with a wide variety of real devices.
Note that there is usually no need to directly set packet->actual_length
form devices handle_data callback, as that is done by usb_packet_copy()
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2012-11-01 17:15:01 +01:00
|
|
|
req->data->iov.size - req->data->actual_length);
|
2012-06-08 16:03:37 +02:00
|
|
|
trace_usb_uas_xfer_data(req->uas->dev.addr, req->tag, length,
|
usb: split packet result into actual_length + status
Since with the ehci and xhci controllers a single packet can be larger
then maxpacketsize, it is possible for the result of a single packet
to be both having transferred some data as well as the transfer to have
an error.
An example would be an input transfer from a bulk endpoint successfully
receiving 1 or more maxpacketsize packets from the device, followed
by a packet signalling halt.
While already touching all the devices and controllers handle_packet /
handle_data / handle_control code, also change the return type of
these functions to void, solely storing the status in the packet. To
make the code paths for regular versus async packet handling more
uniform.
This patch unfortunately is somewhat invasive, since makeing the qemu
usb core deal with this requires changes everywhere. This patch only
prepares the usb core for this, all the hcd / device changes are done
in such a way that there are no functional changes.
This patch has been tested with uhci and ehci hcds, together with usb-audio,
usb-hid and usb-storage devices, as well as with usb-redir redirection
with a wide variety of real devices.
Note that there is usually no need to directly set packet->actual_length
form devices handle_data callback, as that is done by usb_packet_copy()
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2012-11-01 17:15:01 +01:00
|
|
|
req->data->actual_length, req->data->iov.size,
|
2012-06-08 16:03:37 +02:00
|
|
|
req->buf_off, req->buf_size);
|
|
|
|
usb_packet_copy(req->data, scsi_req_get_buf(req->req) + req->buf_off,
|
|
|
|
length);
|
|
|
|
req->buf_off += length;
|
|
|
|
req->data_off += length;
|
|
|
|
|
usb: split packet result into actual_length + status
Since with the ehci and xhci controllers a single packet can be larger
then maxpacketsize, it is possible for the result of a single packet
to be both having transferred some data as well as the transfer to have
an error.
An example would be an input transfer from a bulk endpoint successfully
receiving 1 or more maxpacketsize packets from the device, followed
by a packet signalling halt.
While already touching all the devices and controllers handle_packet /
handle_data / handle_control code, also change the return type of
these functions to void, solely storing the status in the packet. To
make the code paths for regular versus async packet handling more
uniform.
This patch unfortunately is somewhat invasive, since makeing the qemu
usb core deal with this requires changes everywhere. This patch only
prepares the usb core for this, all the hcd / device changes are done
in such a way that there are no functional changes.
This patch has been tested with uhci and ehci hcds, together with usb-audio,
usb-hid and usb-storage devices, as well as with usb-redir redirection
with a wide variety of real devices.
Note that there is usually no need to directly set packet->actual_length
form devices handle_data callback, as that is done by usb_packet_copy()
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2012-11-01 17:15:01 +01:00
|
|
|
if (req->data->actual_length == req->data->iov.size) {
|
2012-06-08 16:03:37 +02:00
|
|
|
usb_uas_complete_data_packet(req);
|
|
|
|
}
|
|
|
|
if (req->buf_size && req->buf_off == req->buf_size) {
|
|
|
|
req->buf_off = 0;
|
|
|
|
req->buf_size = 0;
|
|
|
|
scsi_req_continue(req->req);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
static void usb_uas_start_next_transfer(UASDevice *uas)
|
|
|
|
{
|
|
|
|
UASRequest *req;
|
|
|
|
|
2013-01-25 17:38:59 +01:00
|
|
|
if (uas_using_streams(uas)) {
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2012-06-08 16:03:37 +02:00
|
|
|
QTAILQ_FOREACH(req, &uas->requests, next) {
|
|
|
|
if (req->active || req->complete) {
|
|
|
|
continue;
|
|
|
|
}
|
2013-01-25 17:38:59 +01:00
|
|
|
if (req->req->cmd.mode == SCSI_XFER_FROM_DEV && uas->datain2 == NULL) {
|
|
|
|
uas->datain2 = req;
|
2012-06-08 16:03:37 +02:00
|
|
|
usb_uas_queue_read_ready(req);
|
|
|
|
req->active = true;
|
|
|
|
return;
|
|
|
|
}
|
2013-01-25 17:38:59 +01:00
|
|
|
if (req->req->cmd.mode == SCSI_XFER_TO_DEV && uas->dataout2 == NULL) {
|
|
|
|
uas->dataout2 = req;
|
2012-06-08 16:03:37 +02:00
|
|
|
usb_uas_queue_write_ready(req);
|
|
|
|
req->active = true;
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2013-11-19 14:37:04 +01:00
|
|
|
static UASRequest *usb_uas_alloc_request(UASDevice *uas, uas_iu *iu)
|
2012-06-08 16:03:37 +02:00
|
|
|
{
|
|
|
|
UASRequest *req;
|
|
|
|
|
|
|
|
req = g_new0(UASRequest, 1);
|
|
|
|
req->uas = uas;
|
2013-11-19 14:37:04 +01:00
|
|
|
req->tag = be16_to_cpu(iu->hdr.tag);
|
|
|
|
req->lun = be64_to_cpu(iu->command.lun);
|
2012-06-08 16:03:37 +02:00
|
|
|
req->dev = usb_uas_get_dev(req->uas, req->lun);
|
|
|
|
return req;
|
|
|
|
}
|
|
|
|
|
|
|
|
static void usb_uas_scsi_free_request(SCSIBus *bus, void *priv)
|
|
|
|
{
|
|
|
|
UASRequest *req = priv;
|
|
|
|
UASDevice *uas = req->uas;
|
|
|
|
|
2013-01-25 17:38:59 +01:00
|
|
|
if (req == uas->datain2) {
|
|
|
|
uas->datain2 = NULL;
|
2012-06-08 16:03:37 +02:00
|
|
|
}
|
2013-01-25 17:38:59 +01:00
|
|
|
if (req == uas->dataout2) {
|
|
|
|
uas->dataout2 = NULL;
|
2012-06-08 16:03:37 +02:00
|
|
|
}
|
|
|
|
QTAILQ_REMOVE(&uas->requests, req, next);
|
|
|
|
g_free(req);
|
2012-08-31 14:34:19 +02:00
|
|
|
usb_uas_start_next_transfer(uas);
|
2012-06-08 16:03:37 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
static UASRequest *usb_uas_find_request(UASDevice *uas, uint16_t tag)
|
|
|
|
{
|
|
|
|
UASRequest *req;
|
|
|
|
|
|
|
|
QTAILQ_FOREACH(req, &uas->requests, next) {
|
|
|
|
if (req->tag == tag) {
|
|
|
|
return req;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
|
|
|
static void usb_uas_scsi_transfer_data(SCSIRequest *r, uint32_t len)
|
|
|
|
{
|
|
|
|
UASRequest *req = r->hba_private;
|
|
|
|
|
|
|
|
trace_usb_uas_scsi_data(req->uas->dev.addr, req->tag, len);
|
|
|
|
req->buf_off = 0;
|
|
|
|
req->buf_size = len;
|
|
|
|
if (req->data) {
|
|
|
|
usb_uas_copy_data(req);
|
|
|
|
} else {
|
|
|
|
usb_uas_start_next_transfer(req->uas);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
static void usb_uas_scsi_command_complete(SCSIRequest *r,
|
|
|
|
uint32_t status, size_t resid)
|
|
|
|
{
|
|
|
|
UASRequest *req = r->hba_private;
|
|
|
|
|
|
|
|
trace_usb_uas_scsi_complete(req->uas->dev.addr, req->tag, status, resid);
|
|
|
|
req->complete = true;
|
|
|
|
if (req->data) {
|
|
|
|
usb_uas_complete_data_packet(req);
|
|
|
|
}
|
|
|
|
usb_uas_queue_sense(req, status);
|
|
|
|
scsi_req_unref(req->req);
|
|
|
|
}
|
|
|
|
|
|
|
|
static void usb_uas_scsi_request_cancelled(SCSIRequest *r)
|
|
|
|
{
|
|
|
|
UASRequest *req = r->hba_private;
|
|
|
|
|
|
|
|
/* FIXME: queue notification to status pipe? */
|
|
|
|
scsi_req_unref(req->req);
|
|
|
|
}
|
|
|
|
|
|
|
|
static const struct SCSIBusInfo usb_uas_scsi_info = {
|
|
|
|
.tcq = true,
|
|
|
|
.max_target = 0,
|
|
|
|
.max_lun = 255,
|
|
|
|
|
|
|
|
.transfer_data = usb_uas_scsi_transfer_data,
|
|
|
|
.complete = usb_uas_scsi_command_complete,
|
|
|
|
.cancel = usb_uas_scsi_request_cancelled,
|
|
|
|
.free_request = usb_uas_scsi_free_request,
|
|
|
|
};
|
|
|
|
|
|
|
|
/* --------------------------------------------------------------------- */
|
|
|
|
|
|
|
|
static void usb_uas_handle_reset(USBDevice *dev)
|
|
|
|
{
|
|
|
|
UASDevice *uas = DO_UPCAST(UASDevice, dev, dev);
|
|
|
|
UASRequest *req, *nreq;
|
|
|
|
UASStatus *st, *nst;
|
|
|
|
|
|
|
|
trace_usb_uas_reset(dev->addr);
|
|
|
|
QTAILQ_FOREACH_SAFE(req, &uas->requests, next, nreq) {
|
|
|
|
scsi_req_cancel(req->req);
|
|
|
|
}
|
|
|
|
QTAILQ_FOREACH_SAFE(st, &uas->results, next, nst) {
|
|
|
|
QTAILQ_REMOVE(&uas->results, st, next);
|
|
|
|
g_free(st);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
usb: split packet result into actual_length + status
Since with the ehci and xhci controllers a single packet can be larger
then maxpacketsize, it is possible for the result of a single packet
to be both having transferred some data as well as the transfer to have
an error.
An example would be an input transfer from a bulk endpoint successfully
receiving 1 or more maxpacketsize packets from the device, followed
by a packet signalling halt.
While already touching all the devices and controllers handle_packet /
handle_data / handle_control code, also change the return type of
these functions to void, solely storing the status in the packet. To
make the code paths for regular versus async packet handling more
uniform.
This patch unfortunately is somewhat invasive, since makeing the qemu
usb core deal with this requires changes everywhere. This patch only
prepares the usb core for this, all the hcd / device changes are done
in such a way that there are no functional changes.
This patch has been tested with uhci and ehci hcds, together with usb-audio,
usb-hid and usb-storage devices, as well as with usb-redir redirection
with a wide variety of real devices.
Note that there is usually no need to directly set packet->actual_length
form devices handle_data callback, as that is done by usb_packet_copy()
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2012-11-01 17:15:01 +01:00
|
|
|
static void usb_uas_handle_control(USBDevice *dev, USBPacket *p,
|
2012-06-08 16:03:37 +02:00
|
|
|
int request, int value, int index, int length, uint8_t *data)
|
|
|
|
{
|
|
|
|
int ret;
|
|
|
|
|
|
|
|
ret = usb_desc_handle_control(dev, p, request, value, index, length, data);
|
|
|
|
if (ret >= 0) {
|
usb: split packet result into actual_length + status
Since with the ehci and xhci controllers a single packet can be larger
then maxpacketsize, it is possible for the result of a single packet
to be both having transferred some data as well as the transfer to have
an error.
An example would be an input transfer from a bulk endpoint successfully
receiving 1 or more maxpacketsize packets from the device, followed
by a packet signalling halt.
While already touching all the devices and controllers handle_packet /
handle_data / handle_control code, also change the return type of
these functions to void, solely storing the status in the packet. To
make the code paths for regular versus async packet handling more
uniform.
This patch unfortunately is somewhat invasive, since makeing the qemu
usb core deal with this requires changes everywhere. This patch only
prepares the usb core for this, all the hcd / device changes are done
in such a way that there are no functional changes.
This patch has been tested with uhci and ehci hcds, together with usb-audio,
usb-hid and usb-storage devices, as well as with usb-redir redirection
with a wide variety of real devices.
Note that there is usually no need to directly set packet->actual_length
form devices handle_data callback, as that is done by usb_packet_copy()
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2012-11-01 17:15:01 +01:00
|
|
|
return;
|
2012-06-08 16:03:37 +02:00
|
|
|
}
|
|
|
|
fprintf(stderr, "%s: unhandled control request\n", __func__);
|
usb: split packet result into actual_length + status
Since with the ehci and xhci controllers a single packet can be larger
then maxpacketsize, it is possible for the result of a single packet
to be both having transferred some data as well as the transfer to have
an error.
An example would be an input transfer from a bulk endpoint successfully
receiving 1 or more maxpacketsize packets from the device, followed
by a packet signalling halt.
While already touching all the devices and controllers handle_packet /
handle_data / handle_control code, also change the return type of
these functions to void, solely storing the status in the packet. To
make the code paths for regular versus async packet handling more
uniform.
This patch unfortunately is somewhat invasive, since makeing the qemu
usb core deal with this requires changes everywhere. This patch only
prepares the usb core for this, all the hcd / device changes are done
in such a way that there are no functional changes.
This patch has been tested with uhci and ehci hcds, together with usb-audio,
usb-hid and usb-storage devices, as well as with usb-redir redirection
with a wide variety of real devices.
Note that there is usually no need to directly set packet->actual_length
form devices handle_data callback, as that is done by usb_packet_copy()
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2012-11-01 17:15:01 +01:00
|
|
|
p->status = USB_RET_STALL;
|
2012-06-08 16:03:37 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
static void usb_uas_cancel_io(USBDevice *dev, USBPacket *p)
|
|
|
|
{
|
|
|
|
UASDevice *uas = DO_UPCAST(UASDevice, dev, dev);
|
|
|
|
UASRequest *req, *nreq;
|
2013-01-25 17:38:59 +01:00
|
|
|
int i;
|
2012-06-08 16:03:37 +02:00
|
|
|
|
2013-01-25 17:38:59 +01:00
|
|
|
if (uas->status2 == p) {
|
|
|
|
uas->status2 = NULL;
|
2012-06-08 16:03:37 +02:00
|
|
|
qemu_bh_cancel(uas->status_bh);
|
|
|
|
return;
|
|
|
|
}
|
2013-01-25 17:38:59 +01:00
|
|
|
if (uas_using_streams(uas)) {
|
2013-10-24 19:15:52 +02:00
|
|
|
for (i = 0; i <= UAS_MAX_STREAMS; i++) {
|
2013-01-25 17:38:59 +01:00
|
|
|
if (uas->status3[i] == p) {
|
|
|
|
uas->status3[i] = NULL;
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
if (uas->data3[i] == p) {
|
|
|
|
uas->data3[i] = NULL;
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
2012-06-08 16:03:37 +02:00
|
|
|
QTAILQ_FOREACH_SAFE(req, &uas->requests, next, nreq) {
|
|
|
|
if (req->data == p) {
|
|
|
|
req->data = NULL;
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
assert(!"canceled usb packet not found");
|
|
|
|
}
|
|
|
|
|
2013-11-19 14:37:04 +01:00
|
|
|
static void usb_uas_command(UASDevice *uas, uas_iu *iu)
|
2012-06-08 16:03:37 +02:00
|
|
|
{
|
|
|
|
UASRequest *req;
|
|
|
|
uint32_t len;
|
2013-11-19 14:37:04 +01:00
|
|
|
uint16_t tag = be16_to_cpu(iu->hdr.tag);
|
2012-06-08 16:03:37 +02:00
|
|
|
|
2013-10-24 19:15:53 +02:00
|
|
|
if (uas_using_streams(uas) && tag > UAS_MAX_STREAMS) {
|
|
|
|
goto invalid_tag;
|
|
|
|
}
|
2013-10-24 19:15:50 +02:00
|
|
|
req = usb_uas_find_request(uas, tag);
|
2012-06-08 16:03:37 +02:00
|
|
|
if (req) {
|
|
|
|
goto overlapped_tag;
|
|
|
|
}
|
2013-11-19 14:37:04 +01:00
|
|
|
req = usb_uas_alloc_request(uas, iu);
|
2012-06-08 16:03:37 +02:00
|
|
|
if (req->dev == NULL) {
|
|
|
|
goto bad_target;
|
|
|
|
}
|
|
|
|
|
|
|
|
trace_usb_uas_command(uas->dev.addr, req->tag,
|
|
|
|
usb_uas_get_lun(req->lun),
|
|
|
|
req->lun >> 32, req->lun & 0xffffffff);
|
|
|
|
QTAILQ_INSERT_TAIL(&uas->requests, req, next);
|
2013-01-25 17:38:59 +01:00
|
|
|
if (uas_using_streams(uas) && uas->data3[req->tag] != NULL) {
|
|
|
|
req->data = uas->data3[req->tag];
|
|
|
|
req->data_async = true;
|
|
|
|
uas->data3[req->tag] = NULL;
|
|
|
|
}
|
|
|
|
|
2012-06-08 16:03:37 +02:00
|
|
|
req->req = scsi_req_new(req->dev, req->tag,
|
|
|
|
usb_uas_get_lun(req->lun),
|
2013-11-19 14:37:04 +01:00
|
|
|
iu->command.cdb, req);
|
2013-08-27 14:54:44 +02:00
|
|
|
if (uas->requestlog) {
|
|
|
|
scsi_req_print(req->req);
|
|
|
|
}
|
2012-06-08 16:03:37 +02:00
|
|
|
len = scsi_req_enqueue(req->req);
|
|
|
|
if (len) {
|
|
|
|
req->data_size = len;
|
|
|
|
scsi_req_continue(req->req);
|
|
|
|
}
|
|
|
|
return;
|
|
|
|
|
2013-10-24 19:15:53 +02:00
|
|
|
invalid_tag:
|
|
|
|
usb_uas_queue_fake_sense(uas, tag, sense_code_INVALID_TAG);
|
|
|
|
return;
|
|
|
|
|
2012-06-08 16:03:37 +02:00
|
|
|
overlapped_tag:
|
2013-10-24 19:15:50 +02:00
|
|
|
usb_uas_queue_fake_sense(uas, tag, sense_code_OVERLAPPED_COMMANDS);
|
2012-06-08 16:03:37 +02:00
|
|
|
return;
|
|
|
|
|
|
|
|
bad_target:
|
2013-10-24 19:15:50 +02:00
|
|
|
usb_uas_queue_fake_sense(uas, tag, sense_code_LUN_NOT_SUPPORTED);
|
2012-06-08 16:03:37 +02:00
|
|
|
g_free(req);
|
|
|
|
}
|
|
|
|
|
2013-11-19 14:37:04 +01:00
|
|
|
static void usb_uas_task(UASDevice *uas, uas_iu *iu)
|
2012-06-08 16:03:37 +02:00
|
|
|
{
|
2013-11-19 14:37:04 +01:00
|
|
|
uint16_t tag = be16_to_cpu(iu->hdr.tag);
|
|
|
|
uint64_t lun64 = be64_to_cpu(iu->task.lun);
|
2012-06-08 16:03:37 +02:00
|
|
|
SCSIDevice *dev = usb_uas_get_dev(uas, lun64);
|
|
|
|
int lun = usb_uas_get_lun(lun64);
|
|
|
|
UASRequest *req;
|
|
|
|
uint16_t task_tag;
|
|
|
|
|
2013-10-24 19:15:53 +02:00
|
|
|
if (uas_using_streams(uas) && tag > UAS_MAX_STREAMS) {
|
|
|
|
goto invalid_tag;
|
|
|
|
}
|
2013-11-19 14:37:04 +01:00
|
|
|
req = usb_uas_find_request(uas, be16_to_cpu(iu->hdr.tag));
|
2012-06-08 16:03:37 +02:00
|
|
|
if (req) {
|
|
|
|
goto overlapped_tag;
|
|
|
|
}
|
2013-10-24 19:15:51 +02:00
|
|
|
if (dev == NULL) {
|
|
|
|
goto incorrect_lun;
|
|
|
|
}
|
2012-06-08 16:03:37 +02:00
|
|
|
|
2013-11-19 14:37:04 +01:00
|
|
|
switch (iu->task.function) {
|
2012-06-08 16:03:37 +02:00
|
|
|
case UAS_TMF_ABORT_TASK:
|
2013-11-19 14:37:04 +01:00
|
|
|
task_tag = be16_to_cpu(iu->task.task_tag);
|
2012-06-08 16:03:37 +02:00
|
|
|
trace_usb_uas_tmf_abort_task(uas->dev.addr, tag, task_tag);
|
|
|
|
req = usb_uas_find_request(uas, task_tag);
|
|
|
|
if (req && req->dev == dev) {
|
|
|
|
scsi_req_cancel(req->req);
|
|
|
|
}
|
uas: Fix response iu struct definition
This patch mirrors a patch to the Linux uas kernel driver which I've just
submitted. It looks like the qemu uas struct definitions were taken from
the Linux kernel driver, and have inherited the same mistake.
Besides fixing the response iu struct, the patch also drops the add_info
parameter from the usb_uas_queue_response() function, it is always 0 anyways,
and expressing 3 zero-bytes as a function argument is a bit hard.
Below is the long explanation for this change taken from the kernel commit:
The response iu struct before this patch has a size of 7 bytes, which is weird
since all other iu-s are explictly padded to a multiple of 4 bytes.
Submitting a 7 byte bulk transfer to the status endpoint of a real uasp device
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.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2013-10-31 10:35:31 +01:00
|
|
|
usb_uas_queue_response(uas, tag, UAS_RC_TMF_COMPLETE);
|
2012-06-08 16:03:37 +02:00
|
|
|
break;
|
|
|
|
|
|
|
|
case UAS_TMF_LOGICAL_UNIT_RESET:
|
|
|
|
trace_usb_uas_tmf_logical_unit_reset(uas->dev.addr, tag, lun);
|
|
|
|
qdev_reset_all(&dev->qdev);
|
uas: Fix response iu struct definition
This patch mirrors a patch to the Linux uas kernel driver which I've just
submitted. It looks like the qemu uas struct definitions were taken from
the Linux kernel driver, and have inherited the same mistake.
Besides fixing the response iu struct, the patch also drops the add_info
parameter from the usb_uas_queue_response() function, it is always 0 anyways,
and expressing 3 zero-bytes as a function argument is a bit hard.
Below is the long explanation for this change taken from the kernel commit:
The response iu struct before this patch has a size of 7 bytes, which is weird
since all other iu-s are explictly padded to a multiple of 4 bytes.
Submitting a 7 byte bulk transfer to the status endpoint of a real uasp device
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.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2013-10-31 10:35:31 +01:00
|
|
|
usb_uas_queue_response(uas, tag, UAS_RC_TMF_COMPLETE);
|
2012-06-08 16:03:37 +02:00
|
|
|
break;
|
|
|
|
|
|
|
|
default:
|
2013-11-19 14:37:04 +01:00
|
|
|
trace_usb_uas_tmf_unsupported(uas->dev.addr, tag, iu->task.function);
|
uas: Fix response iu struct definition
This patch mirrors a patch to the Linux uas kernel driver which I've just
submitted. It looks like the qemu uas struct definitions were taken from
the Linux kernel driver, and have inherited the same mistake.
Besides fixing the response iu struct, the patch also drops the add_info
parameter from the usb_uas_queue_response() function, it is always 0 anyways,
and expressing 3 zero-bytes as a function argument is a bit hard.
Below is the long explanation for this change taken from the kernel commit:
The response iu struct before this patch has a size of 7 bytes, which is weird
since all other iu-s are explictly padded to a multiple of 4 bytes.
Submitting a 7 byte bulk transfer to the status endpoint of a real uasp device
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.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2013-10-31 10:35:31 +01:00
|
|
|
usb_uas_queue_response(uas, tag, UAS_RC_TMF_NOT_SUPPORTED);
|
2012-06-08 16:03:37 +02:00
|
|
|
break;
|
|
|
|
}
|
|
|
|
return;
|
|
|
|
|
2013-10-24 19:15:53 +02:00
|
|
|
invalid_tag:
|
uas: Fix response iu struct definition
This patch mirrors a patch to the Linux uas kernel driver which I've just
submitted. It looks like the qemu uas struct definitions were taken from
the Linux kernel driver, and have inherited the same mistake.
Besides fixing the response iu struct, the patch also drops the add_info
parameter from the usb_uas_queue_response() function, it is always 0 anyways,
and expressing 3 zero-bytes as a function argument is a bit hard.
Below is the long explanation for this change taken from the kernel commit:
The response iu struct before this patch has a size of 7 bytes, which is weird
since all other iu-s are explictly padded to a multiple of 4 bytes.
Submitting a 7 byte bulk transfer to the status endpoint of a real uasp device
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.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2013-10-31 10:35:31 +01:00
|
|
|
usb_uas_queue_response(uas, tag, UAS_RC_INVALID_INFO_UNIT);
|
2013-10-24 19:15:53 +02:00
|
|
|
return;
|
|
|
|
|
2012-06-08 16:03:37 +02:00
|
|
|
overlapped_tag:
|
uas: Fix response iu struct definition
This patch mirrors a patch to the Linux uas kernel driver which I've just
submitted. It looks like the qemu uas struct definitions were taken from
the Linux kernel driver, and have inherited the same mistake.
Besides fixing the response iu struct, the patch also drops the add_info
parameter from the usb_uas_queue_response() function, it is always 0 anyways,
and expressing 3 zero-bytes as a function argument is a bit hard.
Below is the long explanation for this change taken from the kernel commit:
The response iu struct before this patch has a size of 7 bytes, which is weird
since all other iu-s are explictly padded to a multiple of 4 bytes.
Submitting a 7 byte bulk transfer to the status endpoint of a real uasp device
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.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2013-10-31 10:35:31 +01:00
|
|
|
usb_uas_queue_response(uas, req->tag, UAS_RC_OVERLAPPED_TAG);
|
2012-06-08 16:03:37 +02:00
|
|
|
return;
|
|
|
|
|
|
|
|
incorrect_lun:
|
uas: Fix response iu struct definition
This patch mirrors a patch to the Linux uas kernel driver which I've just
submitted. It looks like the qemu uas struct definitions were taken from
the Linux kernel driver, and have inherited the same mistake.
Besides fixing the response iu struct, the patch also drops the add_info
parameter from the usb_uas_queue_response() function, it is always 0 anyways,
and expressing 3 zero-bytes as a function argument is a bit hard.
Below is the long explanation for this change taken from the kernel commit:
The response iu struct before this patch has a size of 7 bytes, which is weird
since all other iu-s are explictly padded to a multiple of 4 bytes.
Submitting a 7 byte bulk transfer to the status endpoint of a real uasp device
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.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2013-10-31 10:35:31 +01:00
|
|
|
usb_uas_queue_response(uas, tag, UAS_RC_INCORRECT_LUN);
|
2012-06-08 16:03:37 +02:00
|
|
|
}
|
|
|
|
|
usb: split packet result into actual_length + status
Since with the ehci and xhci controllers a single packet can be larger
then maxpacketsize, it is possible for the result of a single packet
to be both having transferred some data as well as the transfer to have
an error.
An example would be an input transfer from a bulk endpoint successfully
receiving 1 or more maxpacketsize packets from the device, followed
by a packet signalling halt.
While already touching all the devices and controllers handle_packet /
handle_data / handle_control code, also change the return type of
these functions to void, solely storing the status in the packet. To
make the code paths for regular versus async packet handling more
uniform.
This patch unfortunately is somewhat invasive, since makeing the qemu
usb core deal with this requires changes everywhere. This patch only
prepares the usb core for this, all the hcd / device changes are done
in such a way that there are no functional changes.
This patch has been tested with uhci and ehci hcds, together with usb-audio,
usb-hid and usb-storage devices, as well as with usb-redir redirection
with a wide variety of real devices.
Note that there is usually no need to directly set packet->actual_length
form devices handle_data callback, as that is done by usb_packet_copy()
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2012-11-01 17:15:01 +01:00
|
|
|
static void usb_uas_handle_data(USBDevice *dev, USBPacket *p)
|
2012-06-08 16:03:37 +02:00
|
|
|
{
|
|
|
|
UASDevice *uas = DO_UPCAST(UASDevice, dev, dev);
|
2013-11-19 14:37:04 +01:00
|
|
|
uas_iu iu;
|
2012-06-08 16:03:37 +02:00
|
|
|
UASStatus *st;
|
|
|
|
UASRequest *req;
|
usb: split packet result into actual_length + status
Since with the ehci and xhci controllers a single packet can be larger
then maxpacketsize, it is possible for the result of a single packet
to be both having transferred some data as well as the transfer to have
an error.
An example would be an input transfer from a bulk endpoint successfully
receiving 1 or more maxpacketsize packets from the device, followed
by a packet signalling halt.
While already touching all the devices and controllers handle_packet /
handle_data / handle_control code, also change the return type of
these functions to void, solely storing the status in the packet. To
make the code paths for regular versus async packet handling more
uniform.
This patch unfortunately is somewhat invasive, since makeing the qemu
usb core deal with this requires changes everywhere. This patch only
prepares the usb core for this, all the hcd / device changes are done
in such a way that there are no functional changes.
This patch has been tested with uhci and ehci hcds, together with usb-audio,
usb-hid and usb-storage devices, as well as with usb-redir redirection
with a wide variety of real devices.
Note that there is usually no need to directly set packet->actual_length
form devices handle_data callback, as that is done by usb_packet_copy()
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2012-11-01 17:15:01 +01:00
|
|
|
int length;
|
2012-06-08 16:03:37 +02:00
|
|
|
|
|
|
|
switch (p->ep->nr) {
|
|
|
|
case UAS_PIPE_ID_COMMAND:
|
2013-11-19 14:37:04 +01:00
|
|
|
length = MIN(sizeof(iu), p->iov.size);
|
|
|
|
usb_packet_copy(p, &iu, length);
|
|
|
|
switch (iu.hdr.id) {
|
2012-06-08 16:03:37 +02:00
|
|
|
case UAS_UI_COMMAND:
|
2013-11-19 14:37:04 +01:00
|
|
|
usb_uas_command(uas, &iu);
|
2012-06-08 16:03:37 +02:00
|
|
|
break;
|
|
|
|
case UAS_UI_TASK_MGMT:
|
2013-11-19 14:37:04 +01:00
|
|
|
usb_uas_task(uas, &iu);
|
2012-06-08 16:03:37 +02:00
|
|
|
break;
|
|
|
|
default:
|
2013-11-19 14:37:04 +01:00
|
|
|
fprintf(stderr, "%s: unknown command iu: id 0x%x\n",
|
|
|
|
__func__, iu.hdr.id);
|
usb: split packet result into actual_length + status
Since with the ehci and xhci controllers a single packet can be larger
then maxpacketsize, it is possible for the result of a single packet
to be both having transferred some data as well as the transfer to have
an error.
An example would be an input transfer from a bulk endpoint successfully
receiving 1 or more maxpacketsize packets from the device, followed
by a packet signalling halt.
While already touching all the devices and controllers handle_packet /
handle_data / handle_control code, also change the return type of
these functions to void, solely storing the status in the packet. To
make the code paths for regular versus async packet handling more
uniform.
This patch unfortunately is somewhat invasive, since makeing the qemu
usb core deal with this requires changes everywhere. This patch only
prepares the usb core for this, all the hcd / device changes are done
in such a way that there are no functional changes.
This patch has been tested with uhci and ehci hcds, together with usb-audio,
usb-hid and usb-storage devices, as well as with usb-redir redirection
with a wide variety of real devices.
Note that there is usually no need to directly set packet->actual_length
form devices handle_data callback, as that is done by usb_packet_copy()
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2012-11-01 17:15:01 +01:00
|
|
|
p->status = USB_RET_STALL;
|
2012-06-08 16:03:37 +02:00
|
|
|
break;
|
|
|
|
}
|
|
|
|
break;
|
|
|
|
case UAS_PIPE_ID_STATUS:
|
2013-01-25 17:38:59 +01:00
|
|
|
if (p->stream) {
|
|
|
|
QTAILQ_FOREACH(st, &uas->results, next) {
|
|
|
|
if (st->stream == p->stream) {
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
if (st == NULL) {
|
|
|
|
assert(uas->status3[p->stream] == NULL);
|
|
|
|
uas->status3[p->stream] = p;
|
|
|
|
p->status = USB_RET_ASYNC;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
} else {
|
|
|
|
st = QTAILQ_FIRST(&uas->results);
|
|
|
|
if (st == NULL) {
|
|
|
|
assert(uas->status2 == NULL);
|
|
|
|
uas->status2 = p;
|
|
|
|
p->status = USB_RET_ASYNC;
|
|
|
|
break;
|
|
|
|
}
|
2012-06-08 16:03:37 +02:00
|
|
|
}
|
|
|
|
usb_packet_copy(p, &st->status, st->length);
|
|
|
|
QTAILQ_REMOVE(&uas->results, st, next);
|
|
|
|
g_free(st);
|
|
|
|
break;
|
|
|
|
case UAS_PIPE_ID_DATA_IN:
|
|
|
|
case UAS_PIPE_ID_DATA_OUT:
|
2013-01-25 17:38:59 +01:00
|
|
|
if (p->stream) {
|
|
|
|
req = usb_uas_find_request(uas, p->stream);
|
|
|
|
} else {
|
|
|
|
req = (p->ep->nr == UAS_PIPE_ID_DATA_IN)
|
|
|
|
? uas->datain2 : uas->dataout2;
|
|
|
|
}
|
2012-06-08 16:03:37 +02:00
|
|
|
if (req == NULL) {
|
2013-01-25 17:38:59 +01:00
|
|
|
if (p->stream) {
|
|
|
|
assert(uas->data3[p->stream] == NULL);
|
|
|
|
uas->data3[p->stream] = p;
|
|
|
|
p->status = USB_RET_ASYNC;
|
|
|
|
break;
|
|
|
|
} else {
|
|
|
|
fprintf(stderr, "%s: no inflight request\n", __func__);
|
|
|
|
p->status = USB_RET_STALL;
|
|
|
|
break;
|
|
|
|
}
|
2012-06-08 16:03:37 +02:00
|
|
|
}
|
|
|
|
scsi_req_ref(req->req);
|
|
|
|
req->data = p;
|
|
|
|
usb_uas_copy_data(req);
|
usb: split packet result into actual_length + status
Since with the ehci and xhci controllers a single packet can be larger
then maxpacketsize, it is possible for the result of a single packet
to be both having transferred some data as well as the transfer to have
an error.
An example would be an input transfer from a bulk endpoint successfully
receiving 1 or more maxpacketsize packets from the device, followed
by a packet signalling halt.
While already touching all the devices and controllers handle_packet /
handle_data / handle_control code, also change the return type of
these functions to void, solely storing the status in the packet. To
make the code paths for regular versus async packet handling more
uniform.
This patch unfortunately is somewhat invasive, since makeing the qemu
usb core deal with this requires changes everywhere. This patch only
prepares the usb core for this, all the hcd / device changes are done
in such a way that there are no functional changes.
This patch has been tested with uhci and ehci hcds, together with usb-audio,
usb-hid and usb-storage devices, as well as with usb-redir redirection
with a wide variety of real devices.
Note that there is usually no need to directly set packet->actual_length
form devices handle_data callback, as that is done by usb_packet_copy()
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2012-11-01 17:15:01 +01:00
|
|
|
if (p->actual_length == p->iov.size || req->complete) {
|
2012-06-08 16:03:37 +02:00
|
|
|
req->data = NULL;
|
|
|
|
} else {
|
|
|
|
req->data_async = true;
|
usb: split packet result into actual_length + status
Since with the ehci and xhci controllers a single packet can be larger
then maxpacketsize, it is possible for the result of a single packet
to be both having transferred some data as well as the transfer to have
an error.
An example would be an input transfer from a bulk endpoint successfully
receiving 1 or more maxpacketsize packets from the device, followed
by a packet signalling halt.
While already touching all the devices and controllers handle_packet /
handle_data / handle_control code, also change the return type of
these functions to void, solely storing the status in the packet. To
make the code paths for regular versus async packet handling more
uniform.
This patch unfortunately is somewhat invasive, since makeing the qemu
usb core deal with this requires changes everywhere. This patch only
prepares the usb core for this, all the hcd / device changes are done
in such a way that there are no functional changes.
This patch has been tested with uhci and ehci hcds, together with usb-audio,
usb-hid and usb-storage devices, as well as with usb-redir redirection
with a wide variety of real devices.
Note that there is usually no need to directly set packet->actual_length
form devices handle_data callback, as that is done by usb_packet_copy()
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2012-11-01 17:15:01 +01:00
|
|
|
p->status = USB_RET_ASYNC;
|
2012-06-08 16:03:37 +02:00
|
|
|
}
|
|
|
|
scsi_req_unref(req->req);
|
|
|
|
usb_uas_start_next_transfer(uas);
|
|
|
|
break;
|
|
|
|
default:
|
|
|
|
fprintf(stderr, "%s: invalid endpoint %d\n", __func__, p->ep->nr);
|
usb: split packet result into actual_length + status
Since with the ehci and xhci controllers a single packet can be larger
then maxpacketsize, it is possible for the result of a single packet
to be both having transferred some data as well as the transfer to have
an error.
An example would be an input transfer from a bulk endpoint successfully
receiving 1 or more maxpacketsize packets from the device, followed
by a packet signalling halt.
While already touching all the devices and controllers handle_packet /
handle_data / handle_control code, also change the return type of
these functions to void, solely storing the status in the packet. To
make the code paths for regular versus async packet handling more
uniform.
This patch unfortunately is somewhat invasive, since makeing the qemu
usb core deal with this requires changes everywhere. This patch only
prepares the usb core for this, all the hcd / device changes are done
in such a way that there are no functional changes.
This patch has been tested with uhci and ehci hcds, together with usb-audio,
usb-hid and usb-storage devices, as well as with usb-redir redirection
with a wide variety of real devices.
Note that there is usually no need to directly set packet->actual_length
form devices handle_data callback, as that is done by usb_packet_copy()
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2012-11-01 17:15:01 +01:00
|
|
|
p->status = USB_RET_STALL;
|
2012-06-08 16:03:37 +02:00
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
static void usb_uas_handle_destroy(USBDevice *dev)
|
|
|
|
{
|
|
|
|
UASDevice *uas = DO_UPCAST(UASDevice, dev, dev);
|
|
|
|
|
|
|
|
qemu_bh_delete(uas->status_bh);
|
|
|
|
}
|
|
|
|
|
|
|
|
static int usb_uas_init(USBDevice *dev)
|
|
|
|
{
|
|
|
|
UASDevice *uas = DO_UPCAST(UASDevice, dev, dev);
|
|
|
|
|
|
|
|
usb_desc_create_serial(dev);
|
|
|
|
usb_desc_init(dev);
|
|
|
|
|
|
|
|
QTAILQ_INIT(&uas->results);
|
|
|
|
QTAILQ_INIT(&uas->requests);
|
|
|
|
uas->status_bh = qemu_bh_new(usb_uas_send_status_bh, uas);
|
|
|
|
|
2013-08-23 20:30:03 +02:00
|
|
|
scsi_bus_new(&uas->bus, sizeof(uas->bus), DEVICE(dev),
|
|
|
|
&usb_uas_scsi_info, NULL);
|
2012-06-08 16:03:37 +02:00
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static const VMStateDescription vmstate_usb_uas = {
|
|
|
|
.name = "usb-uas",
|
|
|
|
.unmigratable = 1,
|
|
|
|
.fields = (VMStateField[]) {
|
|
|
|
VMSTATE_USB_DEVICE(dev, UASDevice),
|
|
|
|
VMSTATE_END_OF_LIST()
|
|
|
|
}
|
|
|
|
};
|
|
|
|
|
2013-08-27 14:54:44 +02:00
|
|
|
static Property uas_properties[] = {
|
|
|
|
DEFINE_PROP_UINT32("log-scsi-req", UASDevice, requestlog, 0),
|
|
|
|
DEFINE_PROP_END_OF_LIST(),
|
|
|
|
};
|
|
|
|
|
2012-06-08 16:03:37 +02:00
|
|
|
static void usb_uas_class_initfn(ObjectClass *klass, void *data)
|
|
|
|
{
|
|
|
|
DeviceClass *dc = DEVICE_CLASS(klass);
|
|
|
|
USBDeviceClass *uc = USB_DEVICE_CLASS(klass);
|
|
|
|
|
|
|
|
uc->init = usb_uas_init;
|
|
|
|
uc->product_desc = desc_strings[STR_PRODUCT];
|
|
|
|
uc->usb_desc = &desc;
|
|
|
|
uc->cancel_packet = usb_uas_cancel_io;
|
|
|
|
uc->handle_attach = usb_desc_attach;
|
|
|
|
uc->handle_reset = usb_uas_handle_reset;
|
|
|
|
uc->handle_control = usb_uas_handle_control;
|
|
|
|
uc->handle_data = usb_uas_handle_data;
|
|
|
|
uc->handle_destroy = usb_uas_handle_destroy;
|
2013-07-29 16:17:45 +02:00
|
|
|
set_bit(DEVICE_CATEGORY_STORAGE, dc->categories);
|
2012-06-08 16:03:37 +02:00
|
|
|
dc->fw_name = "storage";
|
|
|
|
dc->vmsd = &vmstate_usb_uas;
|
2013-08-27 14:54:44 +02:00
|
|
|
dc->props = uas_properties;
|
2012-06-08 16:03:37 +02:00
|
|
|
}
|
|
|
|
|
2013-01-10 16:19:07 +01:00
|
|
|
static const TypeInfo uas_info = {
|
2012-06-08 16:03:37 +02:00
|
|
|
.name = "usb-uas",
|
|
|
|
.parent = TYPE_USB_DEVICE,
|
|
|
|
.instance_size = sizeof(UASDevice),
|
|
|
|
.class_init = usb_uas_class_initfn,
|
|
|
|
};
|
|
|
|
|
|
|
|
static void usb_uas_register_types(void)
|
|
|
|
{
|
|
|
|
type_register_static(&uas_info);
|
|
|
|
}
|
|
|
|
|
|
|
|
type_init(usb_uas_register_types)
|