From: Stefan Richter <stefanr@s5r6.in-berlin.de>
To: Christoph Hellwig <hch@infradead.org>
Cc: Linus Torvalds <torvalds@osdl.org>,
Ben Collins <bcollins@ubuntu.com>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 2.6.18-rc4 1/5] ieee1394: sbp2: workaround for write protect bit of Initio firmware
Date: Mon, 28 Aug 2006 13:44:15 +0200 [thread overview]
Message-ID: <44F2D70F.30102@s5r6.in-berlin.de> (raw)
In-Reply-To: <20060828092429.GA8980@infradead.org>
Christoph Hellwig wrote:
> On Sun, Aug 27, 2006 at 01:17:31PM -0700, Linus Torvalds wrote:
>> Why does sbp2scsi_slave_configure() set "use_10_for_ms" in the first
>> place?
Good question...
All I can say about it is that older versions of sbp2 enforced the usage
of MODE SENSE(10). If the SCSI stack passed down an MS(6), sbp2
converted it to MS(10) and converted returned data back into MS(6)
format. It did so for RBC disks, SBC disks, and CD-ROMs.
http://lxr.free-electrons.com/source/drivers/ieee1394/sbp2.c?v=2.4.32#2292
Some months ago all of these command conversions in sbp2 were removed
and the use_10_for_ms flag was switched on.
It would be a non-issue if devices simply returned "illegal request"
status on a wrong version of MODE SENSE. But these Initio INIC-1530
bridges return "good" status after either MODE SENSE(6) or (10) but
bogus data after the latter.
> I suspect that's because the typical command set for ieee1394 devices is
> RBC which only specifies the 10-byte commands.
RBC actually lists only MODE SENSE(6), not (10). This makes sbp2's old
behaviour even more questionable. Nevertheless, INIC-1530 is the very
first device that became known to break on MS(10). Everything else
seemed to work fine with MS(10) so far. Switching unconditionally to try
MS(6) before MS(10) could break any other devices.
I suppose I should set up an SBP-2 target (Oracle has a GPL'd userspace
implementation; somebody recently mentioned an as yet unpublished
kernelspace implementation) and use this to log which version of MODE
SENSE Windows and Mac OS prefer. Firmware coders certainly test their
works of art with some variants of these OSs.
PS: Initio's published data sheet mentions RBC support. But their
inquiry data indicate a peripheral device type of 0, which is associated
with SBC.
PPS: This patch here is not strictly needed. The INIC-1530 can be
corrected if the user directly asks Initio for a corrected firmware and
firmware uploader (they don't have it on their website) and has access
to a Windows PC to run the firmware uploader. But I think Linux users
are better served if our driver handles these devices out of the box.
--
Stefan Richter
-=====-=-==- =--- ==--=
http://arcgraph.de/sr/
next prev parent reply other threads:[~2006-08-28 11:48 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-08-27 11:25 [PATCH 2.6.18-rc4 0/5] drivers/ieee1394/sbp2: fixes for 2.6.18-rc Stefan Richter
2006-08-27 11:26 ` [PATCH 2.6.18-rc4 1/5] ieee1394: sbp2: workaround for write protect bit of Initio firmware Stefan Richter
2006-08-27 20:17 ` Linus Torvalds
2006-08-28 1:19 ` Jeff Garzik
2006-08-28 9:24 ` Christoph Hellwig
2006-08-28 11:44 ` Stefan Richter [this message]
[not found] ` <44FC8AAC.10609@s5r6.in-berlin.de>
2006-09-04 20:52 ` Linus Torvalds
2006-09-04 21:26 ` Stefan Richter
2006-08-27 11:27 ` [PATCH 2.6.18-rc4 2/5] ieee1394: sbp2: safer agent reset in error handlers Stefan Richter
2006-08-27 11:28 ` [PATCH 2.6.18-rc4 3/5] ieee1394: sbp2: safer last_orb and next_ORB handling Stefan Richter
2006-08-27 11:29 ` [PATCH 2.6.18-rc4 4/5] ieee1394: sbp2: discard return value of sbp2_link_orb_command Stefan Richter
2006-08-27 11:31 ` [PATCH 2.6.18-rc4 5/5] ieee1394: sbp2: handle "sbp2util_node_write_no_wait failed" Stefan Richter
2006-08-27 11:34 ` [PATCH 2.6.18-rc4 3/5] ieee1394: sbp2: safer last_orb and next_ORB handling Stefan Richter
2006-08-27 11:34 ` [PATCH 2.6.18-rc4 4/5] ieee1394: sbp2: discard return value of sbp2_link_orb_command Stefan Richter
2006-08-27 11:35 ` [PATCH 2.6.18-rc4 5/5] ieee1394: sbp2: handle "sbp2util_node_write_no_wait failed" Stefan Richter
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=44F2D70F.30102@s5r6.in-berlin.de \
--to=stefanr@s5r6.in-berlin.de \
--cc=bcollins@ubuntu.com \
--cc=hch@infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=torvalds@osdl.org \
/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