I split it into two patches:
1. bump hw_max_sectors to 2048 for SS UAS drives and do the clamping
for all UAS drives
2. make sure there's a "fallback" hw_max_sectors "change" so that the
clamping on the SCSI side is invalidated.
If anyone can help fix the dma_dev, the second one can be omitted
(better make the clamping on the USB side to use shost->dev->dma_dev
though).
On Wed, 2 Sep 2020 at 08:09, Tom Yan <tom.ty89@xxxxxxxxx> wrote:
>
> When the scsi request queue is initialized/allocated, the scsi driver clamps
> hw_max_sectors against the dma max mapping size of sdev->host->dma_dev. The
> device is currently inappriorate to use for USB drives.
>
> Therefore, always (re)set hw_max_sectors in the usb drivers to invalidate the
> clamping.
>
> Signed-off-by: Tom Yan <tom.ty89@xxxxxxxxx>
> ---
> drivers/usb/storage/scsiglue.c | 37 ++++++++++++++++------------------
> drivers/usb/storage/uas.c | 2 ++
> 2 files changed, 19 insertions(+), 20 deletions(-)
>
> diff --git a/drivers/usb/storage/scsiglue.c b/drivers/usb/storage/scsiglue.c
> index e5a971b83e3f..1f60d777a7e8 100644
> --- a/drivers/usb/storage/scsiglue.c
> +++ b/drivers/usb/storage/scsiglue.c
> @@ -120,6 +120,23 @@ static int slave_configure(struct scsi_device *sdev)
> * better throughput on most devices.
> */
> blk_queue_max_hw_sectors(sdev->request_queue, 2048);
> + } else {
> + /*
> + * Some devices are known to choke with anything larger. It seems like
> + * the problem stems from the fact that original IDE controllers had
> + * only an 8-bit register to hold the number of sectors in one transfer
> + * and even those couldn't handle a full 256 sectors.
> + *
> + * Because we want to make sure we interoperate with as many devices as
> + * possible, we will maintain a 240 sector transfer size limit for USB
> + * Mass Storage devices.
> + *
> + * Tests show that other operating have similar limits with Microsoft
> + * Windows 7 limiting transfers to 128 sectors for both USB2 and USB3
> + * and Apple Mac OS X 10.11 limiting transfers to 256 sectors for USB2
> + * and 2048 for USB3 devices.
> + */
> + blk_queue_max_hw_sectors(sdev->request_queue, 240);
> }
>
> /*
> @@ -626,26 +643,6 @@ static const struct scsi_host_template usb_stor_host_template = {
> /* lots of sg segments can be handled */
> .sg_tablesize = SG_MAX_SEGMENTS,
>
> -
> - /*
> - * Limit the total size of a transfer to 120 KB.
> - *
> - * Some devices are known to choke with anything larger. It seems like
> - * the problem stems from the fact that original IDE controllers had
> - * only an 8-bit register to hold the number of sectors in one transfer
> - * and even those couldn't handle a full 256 sectors.
> - *
> - * Because we want to make sure we interoperate with as many devices as
> - * possible, we will maintain a 240 sector transfer size limit for USB
> - * Mass Storage devices.
> - *
> - * Tests show that other operating have similar limits with Microsoft
> - * Windows 7 limiting transfers to 128 sectors for both USB2 and USB3
> - * and Apple Mac OS X 10.11 limiting transfers to 256 sectors for USB2
> - * and 2048 for USB3 devices.
> - */
> - .max_sectors = 240,
> -
> /* emulated HBA */
> .emulated = 1,
>
> diff --git a/drivers/usb/storage/uas.c b/drivers/usb/storage/uas.c
> index 813c49914b9a..592e1358822e 100644
> --- a/drivers/usb/storage/uas.c
> +++ b/drivers/usb/storage/uas.c
> @@ -843,6 +843,8 @@ static int uas_slave_configure(struct scsi_device *sdev)
> blk_queue_max_hw_sectors(sdev->request_queue, 240);
> else if (us->pusb_dev->speed >= USB_SPEED_SUPER)
> blk_queue_max_hw_sectors(sdev->request_queue, 2048);
> + else
> + blk_queue_max_hw_sectors(sdev->request_queue, SCSI_DEFAULT_MAX_SECTORS);
>
> blk_queue_max_hw_sectors(sdev->request_queue,
> min_t(size_t, queue_max_hw_sectors(sdev->request_queue),
> --
> 2.28.0
>
