[9195] in linux-scsi channel archive
RE: Feature in ncr53c8xx/sym53c8xx driver
daemon@ATHENA.MIT.EDU (Kenn Humborg)
Fri Jul 14 06:40:16 2000
From: "Kenn Humborg" <kenn@bluetree.ie>
To: "Falkinder, David" <davidf@bri.hp.com>,
"=?iso-8859-1?Q?'G=E9rard_Roudier'?=" <groudier@club-internet.fr>
Cc: <linux-scsi@vger.rutgers.edu>
Date: Fri, 14 Jul 2000 11:38:15 +0100
Message-ID: <NBBBIGEGHIGMPCNKHCECAEGBDLAA.kenn@bluetree.ie>
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
In-Reply-To: <13037D3EF290D211B95F00A0C9EBECC4AF71E6@tungsten.bri.hp.com>
> I had a talk with my firmware buddies, and the solution we
> eventually implemented was to ignore those LUN bits for Inquiry
> and Request
> Sense commands only, all other commands will check condition as before. I
> disagree about ignoring reserved fields, not checking reserved fields is
> definitely a bad way to go from the firmware's perspective.
[Disclaimer: The following is from a general protocol definition viewpoint.
I don't know for fact if this applies to SCSI or to this
particular field in SCSI. I could be very wrong.]
No. No. No. The whole point of reserved fields is to allow
for future expansion. Any device that sends a reserved field
should fill it with some well-defined value (almost always
zero). Any device that received a reserved field should
ignore it.
Later, if newer devices need to use this field, the sender will
fill it with a non-zero value. Older devices will still ignore
it. Newer devices will check it, see the non-zero value and
act accordingly.
> As you
> recommended, it's probably prudent to deviate from the spec in
> order to be a
> good bus device.
Does the spec actually say "the receiver should check
that reserved bits are zero?"
Later,
Kenn
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@vger.rutgers.edu
