Nothing wrong. It's just .can_queue = MAX_CMNDS in the host template
is no longer neceesary, since with his patch, uas will set can_queue
again later (to devinfo->qdepth - 2).
Originally I thought .can_queue = MAX_CMNDS can hence be removed; but
after a second thought, I think it might probably be better if we
leave it there and make use of it, in case certain device somehow
inapproriately reports an enormous qdepth (i.e. larger than
MAX_CMNDS). (According to the commit message of 55ff8cfbc4e1 ("USB:
uas: Reduce can_queue to MAX_CMNDS"), "The uas driver can never queue
more then MAX_CMNDS...")
On 24 May 2016 at 01:00, Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx> wrote:
> On Tue, May 24, 2016 at 12:02:43AM +0800, tom.ty89@xxxxxxxxx wrote:
>> From: Tom Yan <tom.ty89@xxxxxxxxx>
>>
>> Commit 198de51dbc34 ("USB: uas: Limit qdepth at the scsi-host level") made
>> qdepth limit set in host template (`.can_queue = MAX_CMNDS`) useless.
>>
>> Instead of removing the template limit, now we only change limit according
>> to the qdepth reported by the device if it is smaller than MAX_CMNDS.
>>
>> Signed-off-by: Tom Yan <tom.ty89@xxxxxxxxx>
>>
>> diff --git a/drivers/usb/storage/uas.c b/drivers/usb/storage/uas.c
>> index 4d49fce..d7790e6 100644
>> --- a/drivers/usb/storage/uas.c
>> +++ b/drivers/usb/storage/uas.c
>> @@ -972,7 +972,8 @@ static int uas_probe(struct usb_interface *intf, const struct usb_device_id *id)
>> * 1 tag is reserved for untagged commands +
>> * 1 tag to avoid off by one errors in some bridge firmwares
>> */
>> - shost->can_queue = devinfo->qdepth - 2;
>> + if (devinfo->qdepth - 2 < MAX_CMNDS)
>> + shost->can_queue = devinfo->qdepth - 2;
>
> What's wrong with Hans's patch for this issue instead?
>
--
To unsubscribe from this list: send the line "unsubscribe stable" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html