This message is from the T13 list server.
Hi Rob, I was reviewing your proposal (e06126r0) and have a serious issue (I won't go into the editorial issues I have with the proposal here). In the overview of your proposal you write, "However, since NOP with subcommand 00h returns the same result as an unsupported opcode, it doesn't matter if it is 'supported' or not." This isn't all NOP does. It DOES matter whether a device reports that the command is supported or not. You have to go back to what NOP was originally intended to do. The last place this is hinted at is in the description of NOP in ATA/ATAPI-4 rev 16, "This command enables a host, that only performs 16-bit register accesses, to check device status." It seems that Pete McLean removed this when he added in Tony Goodfellow's proposal for NOP auto poll (d97142r1) during A/A-4 letter ballot resolution. If you go back farther to earlier standards, you'll see that "...when a host performing 16-bit register accesses writes to the Drive Head Register, one byte contains the Command Register, so the drive sees a new command when the intended purpose is only to select a drive. Both drives may be Busy but not necessarily Ready i.e., Drive 0 may be ready, but not drive 1." So, there is a unique meaning to saying that a device supports NOP just as it is. This meaning can't be muddied by adding additional requirements. If you want additional requirements, you'll have to find a new bit in IDENTIFY DEVICE data. Regards, Mark Evans Maxtor Corporation 500 McCarthy Boulevard Milpitas, CA 95035 -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Elliott, Robert (Server Storage) Sent: Monday, April 03, 2006 11:37 AM To: [email protected] Subject: [t13] ATA8-ACS NOP proposals This message is from the T13 list server. Stemming from some SCSI to ATA Translation (SAT) letter ballot discussions on the behavior of the NOP command, I've prepared two proposals for T13 to discuss at the April meeting (posted on http://www.t13.org): e06125r0-ATA8-ACS_IDENTIFY_PACKET_DEVICE_supported_features.pdf IDENTIFY PACKET DEVICE must return specific values for feature sets/commands that are mandatory or prohibited in packet devices (e.g. NOP is mandatory). e06126r0-ATA8-ACS_NOP_clarifications.pdf Since NOP with subcommand 00h behaves the same as an unsupported command, there is no reason for IDENTIFY DEVICE to include NOP Supported/Enabled bits except for subcommands 01h-FFh. Those subcommands have different behavior for devices supporting the Overlapped and Queued feature sets. So, this proposal adds a sentence noting that, for devices supporting the Overlapped feature set, the IDENTIFY DEVICE data bits indicating NOP support also imply that NOP subcommands 01h-FFh are supported. Also, the NOP Auto Poll model discusses how host adapters might complete the command with ERR=0, which the NOP command description doesn't mention at all. Based on d97142r1, the proposal that added the feature, changes are suggested to mention this exception in the NOP command description. -- Rob Elliott, [EMAIL PROTECTED] Hewlett-Packard Industry Standard Server Storage Advanced Technology https://ecardfile.com/id/RobElliott
