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:34 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).