Hi, On 11/15/2013 04:35 PM, David Laight wrote:
From: Hans de GoedeCopy the sg alignment trick from the usb-storage driver, without this I'm seeing intermittent errors when using uas devices with an ehci controller. Signed-off-by: Hans de Goede <hdego...@redhat.com> --- drivers/usb/storage/uas.c | 18 ++++++++++++++++++ 1 file changed, 18 insertions(+) diff --git a/drivers/usb/storage/uas.c b/drivers/usb/storage/uas.c index 3c4cf1e..2b946dd 100644 --- a/drivers/usb/storage/uas.c +++ b/drivers/usb/storage/uas.c @@ -928,6 +928,24 @@ static int uas_eh_bus_reset_handler(struct scsi_cmnd *cmnd) static int uas_slave_alloc(struct scsi_device *sdev) { sdev->hostdata = (void *)sdev->host->hostdata; + + /* USB has unusual DMA-alignment requirements: Although the + * starting address of each scatter-gather element doesn't matter, + * the length of each element except the last must be divisible + * by the Bulk maxpacket value. There's currently no way to + * express this by block-layer constraints, so we'll cop out + * and simply require addresses to be aligned at 512-byte + * boundaries. This is okay since most block I/O involves + * hardware sectors that are multiples of 512 bytes in length, + * and since host controllers up through USB 2.0 have maxpacket + * values no larger than 512. + * + * But it doesn't suffice for Wireless USB, where Bulk maxpacket + * values can be as large as 2048. To make that work properly + * will require changes to the block layer. + */ + blk_queue_update_dma_alignment(sdev->request_queue, (512 - 1));The comment isn't true for anything connected to xhci. Pragmatically the solution might be reasonable though.
The comment was copy pasted from the usb-storage driver, I don't know about the exact requirements for xhci, but forcing 512 bytes alignment certainly does not hurt the xhci code-path, where as not doing so causes real world problems for uas devices attached to an ehci controller. Regards, Hans -- 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
