From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from bedivere.hansenpartnership.com ([66.63.167.143]:34770 "EHLO bedivere.hansenpartnership.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752102AbcEWR1l (ORCPT ); Mon, 23 May 2016 13:27:41 -0400 Message-ID: <1464024457.2331.10.camel@HansenPartnership.com> Subject: Re: [PATCH 1/1] uas: leave can_queue as MAX_CMNDS if device reports larger qdepth From: James Bottomley To: Tom Yan , Greg KH Cc: Gerd Hoffmann , Alan Stern , linux-usb@vger.kernel.org, linux-scsi@vger.kernel.org, stable@vger.kernel.org, hdegoede@redhat.com Date: Mon, 23 May 2016 10:27:37 -0700 In-Reply-To: References: <574329ae.c726620a.60f3.ffffd14b@mx.google.com> <20160523170025.GA3309@kroah.com> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: stable-owner@vger.kernel.org List-ID: 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