summaryrefslogtreecommitdiffstats
path: root/drivers/firewire
diff options
context:
space:
mode:
authorStefan Richter <stefanr@s5r6.in-berlin.de>2012-11-25 18:45:25 +0100
committerStefan Richter <stefanr@s5r6.in-berlin.de>2012-12-02 20:10:18 +0100
commitb0ea5f19d3d848008d87e455c8d9b6d9cae7101a (patch)
tree5c00ab224f675dbb30a8eba43dbba76440593e14 /drivers/firewire
parent6fa79bcaecdbb0eb417afbc7fb0a8fa204308b62 (diff)
downloadlinux-b0ea5f19d3d848008d87e455c8d9b6d9cae7101a.tar.bz2
firewire: sbp2: allow WRITE SAME and REPORT SUPPORTED OPERATION CODES
The commits 3c6bdaeab4fd "[SCSI] Add a report opcode helper" 5db44863b6eb "[SCSI] sd: Implement support for WRITE SAME" introduced in-kernel uses of the mentioned commands but cautiously blacklisted them for any IEEE 1394 (SBP-2/3) targets and some other transports. I looked through a range of SBP devices and found that the blacklist flags can be removed: The kernel never attempts these commands if the device's INQUIRY data claim a SCSI revision of less than 0x05. This is the case with all SBP devices that I checked, except for three more recent devices which claimed a revision of 0x05 i.e. conformance with SPC-3 (two devices based on the OXUF936QSE chip but having different firmwares, one based on OXUF934DSB.) I tried "sg_opcodes" from sg3_utils on several older and newer devices and did not encounter any apparent firmware bugs with it. All devices returned Illegal Request/ Invalid command operation code and carried on. I furthermore tried "sg_write_same -U" on the OXUF934DSB device with the same result. Alas I did not have a TRIM enabled SSD available for these tests. All of the bridges were correctly identified by the kernel as "fully provisioned", CD-ROM devices aside. The kernel won't issue WRITE SAME to fully provisioned devices, nor would it attempt REPORT SUPPORTED OPERATION CODES or WRITE SAME with UNMAP bit on devices which do not claim conformance to SPC-3 or later. Hence let's remove the no_report_opcodes and no_write_same blacklist flags so that these commands can be used on newer targets with respective capabilities. I guess the Linux sbp-target could be such a target. Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Diffstat (limited to 'drivers/firewire')
-rw-r--r--drivers/firewire/sbp2.c2
1 files changed, 0 insertions, 2 deletions
diff --git a/drivers/firewire/sbp2.c b/drivers/firewire/sbp2.c
index bb1b392f5cda..1162d6b3bf85 100644
--- a/drivers/firewire/sbp2.c
+++ b/drivers/firewire/sbp2.c
@@ -1546,8 +1546,6 @@ static int sbp2_scsi_slave_configure(struct scsi_device *sdev)
struct sbp2_logical_unit *lu = sdev->hostdata;
sdev->use_10_for_rw = 1;
- sdev->no_report_opcodes = 1;
- sdev->no_write_same = 1;
if (sbp2_param_exclusive_login)
sdev->manage_start_stop = 1;