[PATCH 2/2 update] ieee1394: sbp2: enable auto spin-up for all SBP-2devices

[Stefan Richter]

This is a follow-up to patch "ieee1394: sbp2: enable auto spin-up for
Maxtor disks".  When I 'ejected' an OXUF922 based HDD from a Mac OS X
box, it was spun down by the Mac and did not spin up by itself when
attached to a Linux box right after that.  The first SCSI command that
required the bridge to access the drive ended in
sda:<6>sd 18:0:0:0: Device not ready: <6>: Current: sense key: Not Ready
    Additional sense: Logical unit not ready, initializing cmd. required

Therefore the flag which instructs scsi_mod to send START STOP UNIT with
START=1 ("make medium ready") after such a condition is now enabled
unconditionally for all FireWire storage devices.

Signed-off-by: Stefan Richter <stefanr@xxxxxxxxxxxxxxxxx>
---
Patch updated (refreshed) to be applicable without the obsolete patch
"ieee1394: sbp2: workaround for write protect bit of Initio firmware".

Intendend to be dropped into the same place in -mm's order of patches as
before. It's not hard to resolve it manually though.

Index: linux/drivers/ieee1394/sbp2.c
===================================================================
--- linux.orig/drivers/ieee1394/sbp2.c	2006-09-06 23:43:34.000000000 +0200
+++ linux/drivers/ieee1394/sbp2.c	2006-09-06 23:46:47.000000000 +0200
@@ -2441,6 +2441,7 @@ static int sbp2scsi_slave_alloc(struct s
 		(struct scsi_id_instance_data *)sdev->host->hostdata[0];
 
 	scsi_id->sdev = sdev;
+	sdev->allow_restart = 1;
 
 	if (scsi_id->workarounds & SBP2_WORKAROUND_INQUIRY_36)
 		sdev->inquiry_len = 36;
@@ -2461,9 +2462,6 @@ static int sbp2scsi_slave_configure(stru
 		sdev->skip_ms_page_8 = 1;
 	if (scsi_id->workarounds & SBP2_WORKAROUND_FIX_CAPACITY)
 		sdev->fix_capacity = 1;
-	if (scsi_id->ne->guid_vendor_id == 0x0010b9 && /* Maxtor's OUI */
-	    (sdev->type == TYPE_DISK || sdev->type == TYPE_RBC))
-		sdev->allow_restart = 1;
 	return 0;
 }
 


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/