From: Douglas Gilbert <dougg@torque.net>
To: James Bottomley <James.Bottomley@SteelEye.com>
Cc: Alan Stern <stern@rowland.harvard.edu>,
Patrick Mansfield <patmans@us.ibm.com>,
Matthew Dharm <mdharm-usb@one-eyed-alien.net>,
thomas schorpp <t.schorpp@gmx.de>,
USB Storage list <usb-storage@lists.one-eyed-alien.net>,
Timothy Thelin <Timothy.Thelin@wdc.com>,
Linux SCSI list <linux-scsi@vger.kernel.org>,
linux-ide@vger.kernel.org
Subject: [PATCH] writable scsi_level [was: [Merging ATA passthru] on integrating SMART/ATA-Security in usb-storage driver]
Date: Thu, 01 Dec 2005 21:35:41 +1000 [thread overview]
Message-ID: <438EE00D.1030108@torque.net> (raw)
In-Reply-To: <1131401153.3333.6.camel@mulgrave>
[-- Attachment #1: Type: text/plain, Size: 1692 bytes --]
James Bottomley wrote:
> On Mon, 2005-11-07 at 15:59 -0500, Alan Stern wrote:
>
>>>That is, is usb-storage forcing scsi-2 when the device tells us it is
>>>scsi-3 compliant, or is the hardware reporting devices are scsi-2, yet
>>>requiring non-LUN value in cdb[1]?
>>
>>I think we may have both. However I don't know how this Cypress chip
>>reports itself. A system log showing the INQUIRY data would be very
>>helpful.
>
>
> We were told in prior emails that it actually reports a level of zero
> (i.e. no compliance with any SCSI standard). My original proposal was
> just not to modify the CDB[1] for this case if we could get the INQUIRY
> passed through unmangled.
>
>
>>It's quite possible that usb-storage no longer needs to force the
>>scsi-level to 2. No one has recently tested what would happen without
>>it. Matt probably has the best selection of devices for testing...
>>
>>There is one problem we have with devices that report themselves as SCSI-3
>>or SCSI-4 but hang when they receive a REPORT LUNS command. That's easily
>>handled by making usb-storage set the NOREPORTLUN flag. Maybe that's all
>>we need to do.
This patch may add some flexibility. It allows
/sys/class/scsi_device/<hcil>/device/scsi_level
to be written. It won't help during scanning but
will indirectly allow people to get the functionality
of SG_FLAG_LUN_INHIBIT back (via writing a number
greater than 3 into scsi_level).
The patch is against lk 2.6.15-rc3
Changelog:
- make sysfs scsi_level attribute writable
- fix bug in sdev_rw_attr macro (but can't
use it because scsi_device::scsi_level is
a char)
Signed-off-by: Douglas Gilbert <dougg@torque.net>
Doug Gilbert
[-- Attachment #2: scsi_level_wr2615rc3.diff --]
[-- Type: text/x-patch, Size: 1482 bytes --]
--- linux/drivers/scsi/scsi_sysfs.c 2005-11-30 08:43:00.000000000 +1000
+++ linux/drivers/scsi/scsi_sysfs.c2615rc3sl 2005-12-01 21:04:40.000000000 +1000
@@ -322,7 +322,7 @@
{ \
struct scsi_device *sdev; \
sdev = to_scsi_device(dev); \
- snscanf (buf, 20, format_string, &sdev->field); \
+ sscanf (buf, format_string, &sdev->field); \
return count; \
} \
static DEVICE_ATTR(field, S_IRUGO | S_IWUSR, sdev_show_##field, sdev_store_##field);
@@ -375,12 +375,32 @@
sdev_rd_attr (device_blocked, "%d\n");
sdev_rd_attr (queue_depth, "%d\n");
sdev_rd_attr (type, "%d\n");
-sdev_rd_attr (scsi_level, "%d\n");
sdev_rd_attr (vendor, "%.8s\n");
sdev_rd_attr (model, "%.16s\n");
sdev_rd_attr (rev, "%.4s\n");
static ssize_t
+sdev_show_scsi_level (struct device *dev, struct device_attribute *attr, char *buf)
+{
+ struct scsi_device *sdev;
+ sdev = to_scsi_device(dev);
+ return snprintf (buf, 20, "%d\n", (int)sdev->scsi_level);
+}
+
+static ssize_t
+sdev_store_scsi_level (struct device *dev, struct device_attribute *attr,
+ const char *buf, size_t count)
+{
+ struct scsi_device *sdev;
+ int val;
+ sdev = to_scsi_device(dev);
+ sscanf (buf, "%d\n", &val);
+ sdev->scsi_level = val;
+ return count;
+}
+static DEVICE_ATTR(scsi_level, S_IRUGO | S_IWUSR, sdev_show_scsi_level, sdev_store_scsi_level);
+
+static ssize_t
sdev_show_timeout (struct device *dev, struct device_attribute *attr, char *buf)
{
struct scsi_device *sdev;
next prev parent reply other threads:[~2005-12-01 11:35 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-11-04 18:30 [usb-storage] [Merging ATA passthru] on integrating SMART/ATA-Security in usb-storage driver Timothy Thelin
2005-11-04 18:58 ` James Bottomley
2005-11-04 20:30 ` Matthew Dharm
2005-11-04 20:49 ` James Bottomley
2005-11-05 23:55 ` Matthew Dharm
2005-11-06 0:49 ` James Bottomley
2005-11-06 3:38 ` thomas schorpp
2005-11-06 21:58 ` Matthew Dharm
2005-11-06 22:28 ` thomas schorpp
2005-11-06 23:52 ` Patrick Mansfield
2005-11-07 16:59 ` Matthew Dharm
2005-11-07 17:05 ` Matthew Dharm
2005-11-07 17:24 ` Patrick Mansfield
2005-11-07 17:46 ` Alan Stern
2005-11-07 18:06 ` thomas schorpp
2005-11-07 19:33 ` Alan Stern
2005-11-07 20:07 ` thomas schorpp
2005-11-07 17:53 ` Christoph Hellwig
2005-11-07 17:54 ` thomas schorpp
2005-11-07 18:57 ` Patrick Mansfield
2005-11-07 19:53 ` Alan Stern
2005-11-07 20:47 ` Patrick Mansfield
2005-11-07 20:59 ` Alan Stern
2005-11-07 22:05 ` James Bottomley
2005-11-08 17:09 ` Alan Stern
2005-11-08 23:05 ` Mike Anderson
2005-11-09 15:35 ` Alan Stern
2005-12-01 11:35 ` Douglas Gilbert [this message]
2005-11-08 13:51 ` [usb-storage] [Merging ATA passthru] on integratingSMART/ATA-Security " Pat LaVarre
2005-11-06 23:15 ` [usb-storage] [Merging ATA passthru] on integrating SMART/ATA-Security " James Bottomley
2005-11-07 18:14 ` Patrick Mansfield
2005-11-04 23:56 ` Andries Brouwer
2005-11-04 23:46 ` Pete Zaitcev
2005-11-05 16:20 ` thomas schorpp
2005-11-05 18:01 ` [usb-storage] [Merging ATA passthru] on integratingSMART/ATA-Security " Pat LaVarre
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=438EE00D.1030108@torque.net \
--to=dougg@torque.net \
--cc=James.Bottomley@SteelEye.com \
--cc=Timothy.Thelin@wdc.com \
--cc=linux-ide@vger.kernel.org \
--cc=linux-scsi@vger.kernel.org \
--cc=mdharm-usb@one-eyed-alien.net \
--cc=patmans@us.ibm.com \
--cc=stern@rowland.harvard.edu \
--cc=t.schorpp@gmx.de \
--cc=usb-storage@lists.one-eyed-alien.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.