On Wed, 4 Nov 2015, Felipe Balbi wrote:
> USB3 devices, because they are much newer, have much
> less chance of having issues with larger transfers.
>
> We still keep a limit because anything above 2048
> sectors really rendered negligible speed
> improvements, so we will simply ignore
> that. Transferring 1MiB should already give us
> pretty good performance.
>
> Signed-off-by: Felipe Balbi <balbi@xxxxxx>
> ---
> drivers/usb/storage/scsiglue.c | 16 +++++++++++-----
> drivers/usb/storage/usb.c | 4 ++++
> include/linux/usb_usual.h | 2 ++
> 3 files changed, 17 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/usb/storage/scsiglue.c b/drivers/usb/storage/scsiglue.c
> index 00aadf3a3857..bda2b3c9ae42 100644
> --- a/drivers/usb/storage/scsiglue.c
> +++ b/drivers/usb/storage/scsiglue.c
> @@ -115,13 +115,19 @@ static int slave_configure(struct scsi_device *sdev)
> {
> struct us_data *us = host_to_us(sdev->host);
>
> - /* Many devices have trouble transferring more than 32KB at a time,
> - * while others have trouble with more than 64K. At this time we
> - * are limiting both to 32K (64 sectores).
> - */
> - if (us->fflags & (US_FL_MAX_SECTORS_64 | US_FL_MAX_SECTORS_MIN)) {
> + if (us->fflags & US_FL_USB3) {
...
> --- a/include/linux/usb_usual.h
> +++ b/include/linux/usb_usual.h
> @@ -79,6 +79,8 @@
> /* Cannot handle MI_REPORT_SUPPORTED_OPERATION_CODES */ \
> US_FLAG(MAX_SECTORS_240, 0x08000000) \
> /* Sets max_sectors to 240 */ \
> + US_FLAG(USB3, 0x10000000) \
> + /* This is a USB3 Storage Device */ \
This doesn't need to be stored as one of the usb-storage flags. And
since we are close to running out of flag bits (on 32-bit
architectures), it would be better not to use one of them for this.
The test above can be rewritten as:
if (us->pusb_dev->speed >= USB_SPEED_SUPER)
Since it gets used in only this one place and it's not on a hot path,
this is how it should be done
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
