From mboxrd@z Thu Jan 1 00:00:00 1970 From: Christoph Hellwig Subject: Re: [Bug 80711] [PATCH]SG_FLAG_LUN_INHIBIT is no longer implemented and there's not way to prevent the kernel from using the 2nd cdb byte for the LUN Date: Fri, 22 Aug 2014 08:05:08 -0700 Message-ID: <20140822150508.GA1321@infradead.org> References: <20140821215744.GA29651@infradead.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Content-Disposition: inline In-Reply-To: Sender: linux-usb-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: Alan Stern Cc: "Martin K. Petersen" , Douglas Gilbert , Tiziano Bacocco , bugzilla-daemon-590EEB7GvNiWaY/ihj7yzEB+6BGkLq7r@public.gmane.org, SCSI development list , USB list List-Id: linux-scsi@vger.kernel.org On Fri, Aug 22, 2014 at 10:53:42AM -0400, Alan Stern wrote: > Good idea. An enhanced patch is below. If I can get a Tested-By: from > Tiziano and one or two Acked-By: responses, I'll submit this for the > current and stable kernels. > > Sending the initial INQUIRY command to LUNs larger than 0 involves a > chicken-and-egg problem -- we don't know whether to fill in the LUN > bits in the command until we know the SCSI level, and we don't know the > SCSI level until the INQUIRY response is received. The solution we > have been using is to store the most recently discovered level in the > target structure, and use it as a default. If probing starts with LUN > 0, and if all the LUNs have similar levels, this ought to work. > > Except for one thing: The code does store the default level in the > scsi_target, but forgets to copy it back into each newly allocated > scsi_device! I added a line to do that into the patch. Looks good to me, Acked-by: Christoph Hellwig Do you want to queue this up in the USB tree? From the looks of what I have on my plate so far it seems like we could avoid conflicts with it in the SCSI tree. -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html