Re: [PATCH 1/1] uas: leave can_queue as MAX_CMNDS if device reports larger qdepth

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



I don't quite get what you mean. Are you saying that it is impossible
that UAS devices would report inappropriately high qdepth, because of
this?
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/usb/storage/uas.c?h=v4.6#n908

In that case should I send another patch that simply has `.can_queue =
MAX_CMNDS` in the host template removed?

On 24 May 2016 at 01:27, James Bottomley
<James.Bottomley@xxxxxxxxxxxxxxxxxxxxx> wrote:
> On Tue, 2016-05-24 at 01:23 +0800, Tom Yan wrote:
>> 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...")
>
> OK, so try this as an exercise: Why would this not be the right thing
> to do after the host is prepared:  It has to do with the streams
> resources the driver has already created.
>
> James
>
>
--
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



[Index of Archives]     [Linux Kernel]     [Kernel Development Newbies]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite Hiking]     [Linux Kernel]     [Linux SCSI]