On Sun, 12 Oct 2014, Mark Knibbs wrote:
> --- linux-3.17/drivers/usb/storage/transport.c.orig 2014-10-05
> 20:12:36.000000000 +0100
> +++ linux-3.17/drivers/usb/storage/transport.c 2014-10-12
> 13:11:38.000000000 +0100
> @@ -1035,9 +1035,20 @@ int usb_stor_Bulk_max_lun(struct us_data
> usb_stor_dbg(us, "GetMaxLUN command result is %d, data is %d\n",
> result, us->iobuf[0]);
>
> - /* if we have a successful request, return the result */
> - if (result > 0)
> - return us->iobuf[0];
> + /*
> + * If we have a successful request, return the result if valid. The
> + * CBW LUN field is 4 bits wide, so the value reported by the device
> + * should fit into that.
> + */
> + if (result > 0) {
> + if (!(us->iobuf[0] & 0xf0)) {
Since the Max-LUN value is just a plain old number (with no special
interpretations for the individual bits), it is easier to understand if
the code treats it that way. Simply say:
if (us->iobuf[0] < 16) {
> + return us->iobuf[0];
> + } else {
> + dev_info(&us->pusb_intf->dev,
> + "Max LUN %d is not valid, using 0 instead",
> + us->iobuf[0]);
> + }
> + }
>
> /*
> * Some devices don't like GetMaxLUN. They may STALL the control
Apart from that minor issue,
Acked-by: Alan Stern <st...@rowland.harvard.edu>
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
