This message is from the T13 list server.
T13, I guess I was thinking in validation or PU type situations. I cant remember for certain, but I think the BIOS' might even send a command or 2 to determine what is out there and an ABORT or no response is used to assist in autoconfiguring the motherboard. I dont think Nathan was indicating sending an "unsupported command" on a regular basis as part of a driver. I dont think that would be a real good thing. But then again...many many moons ago, someone used to send an IDC or something like that before every command as part of their driver. So you just never know what you might run into.... gkl ----- Original Message ----- From: "Jeff Garzik" <[EMAIL PROTECTED]> To: "Hale Landis" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Wednesday, May 26, 2004 1:18 PM Subject: Re: [t13] Feature Negotiation policy question > This message is from the T13 list server. > > > Hale Landis wrote: > > From: Nathan Obr > > > >>I have what I believe is the spirit of the law question. > >>If a device doesnt report that it supports a feature in its > >>IDENTIFY_DATA is it acceptable to send it commands from that > >>feature set anyway? > [...] > > No, there is nothing wrong with a host sending commands to see if > > the command is accepted. The host just needs to understand that > > tradition says that after receiving ERR=1 status the host should > > issue a "reset" before proceeding (this is just tradition, > > ATA/ATAPI does not require a reset following an error, in fact > > prohibits a reset following an UDMA ICEC error). > > > Vendor-specific commands make "just send it down" a very risky > proposition... > > Jeff > >
