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.)
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
