Alan Stern <st...@rowland.harvard.edu> writes:
> On Thu, 14 Apr 2016, Felipe Balbi wrote:
>
>> >> --- a/drivers/usb/storage/scsiglue.c
>> >> +++ b/drivers/usb/storage/scsiglue.c
>> >> @@ -127,6 +127,11 @@ static int slave_configure(struct scsi_device *sdev)
>> >>           if (queue_max_hw_sectors(sdev->request_queue) > max_sectors)
>> >>                   blk_queue_max_hw_sectors(sdev->request_queue,
>> >>                                         max_sectors);
>> >> + } else if (us->pusb_dev->speed >= USB_SPEED_SUPER) {
>> >> +         /* USB3 devices will be limited to 2048 sectors. This gives us
>> >> +          * better throughput on most devices.
>> >> +          */
>> >> +         blk_queue_max_hw_sectors(sdev->request_queue, 2048);
>> >>   } else if (sdev->type == TYPE_TAPE) {
>> >>           /* Tapes need much higher max_sector limits, so just
>> >>            * raise it to the maximum possible (4 GB / 512) and
>> >
>> > Argh!  This has the same kind of problem as before.  What will happen
>> > when somebody has a USB-3 tape drive?
>> 
>> I didn't know that was even plausible :-) Anyway, I'll update, but while
>> at that, so I use for bcdUSB instead of speed as Oliver suggested ? I
>> mean, a USB3 stick running on high-speed can also support 2048 max
>> sectors, right ?
>> 
>> let me know
>
> To tell the truth, I have no idea.  There probably aren't enough USB-3 
> products in existence yet to tell -- not to mention that with the 
> existing code, we wouldn't detect any exceptions.
>
> It sounds reasonable...  But won't a USB-3 device running at high speed
> provide a device descriptor that has bcdUSB set to 0x0210?  (See the
> second paragraph of section 9.6.1 in the USB-3.1 spec.)

right, but an HS USB 2.1 device is also recent enough that it's likely
to work similarly, no ?

-- 
balbi

Attachment: signature.asc
Description: PGP signature

Reply via email to