USB: usb-storage: don't clear-halt when Get-Max-LUN stalls

This patch (as1032) removes the Clear-Halt calls in
usb_stor_Bulk_max_lun().  Evidently some devices (such as the Oracom
MP3 player) really don't like to receive these requests when their
bulk endpoints aren't halted.

The only reason for adding them originally was to get an ancient
ZIP-100 drive to work.  But since this device has only a single LUN,
we don't need to send it a Get-Max-LUN request at all.  Adding an
unusual_devs entry for the ZIP-100 with the SINGLE_LUN flag set will
cause this step to be skipped.

Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

1 files changed, 0 insertions, 11 deletions

diff --git a/drivers/usb/storage/transport.c b/drivers/usb/storage/transport.c
index d9f4912f873d..5780ed15f1ad 100644
--- a/drivers/usb/storage/transport.c
+++ b/drivers/usb/storage/transport.c
@@ -891,17 +891,6 @@ int usb_stor_Bulk_max_lun(struct us_data *us)
 	if (result > 0)
 		return us->iobuf[0];
 
-	/* 
-	 * Some devices (i.e. Iomega Zip100) need this -- apparently
-	 * the bulk pipes get STALLed when the GetMaxLUN request is
-	 * processed.   This is, in theory, harmless to all other devices
-	 * (regardless of if they stall or not).
-	 */
-	if (result == -EPIPE) {
-		usb_stor_clear_halt(us, us->recv_bulk_pipe);
-		usb_stor_clear_halt(us, us->send_bulk_pipe);
-	}
-
 	/*
 	 * Some devices don't like GetMaxLUN.  They may STALL the control
 	 * pipe, they may return a zero-length result, they may do nothing at