> -----Original Message----- > From: James Bottomley [mailto:James.Bottomley@xxxxxxxxxxxxxxxxxxxxx] > Sent: Sunday, March 04, 2012 9:20 AM > To: KY Srinivasan > Cc: gregkh@xxxxxxxxxxxxxxxxxxx; linux-kernel@xxxxxxxxxxxxxxx; > devel@xxxxxxxxxxxxxxxxxxxxxx; ohering@xxxxxxxx; hch@xxxxxxxxxxxxx; linux- > scsi@xxxxxxxxxxxxxxx; Haiyang Zhang > Subject: Re: [PATCH 1/1] Drivers: scsi: storvsc: Don't pass ATA_16 command to > the host > > On Fri, 2012-03-02 at 12:49 -0800, K. Y. Srinivasan wrote: > > Windows hosts don't handle the ATA_16 command; don't pass it to the host. > > What do you mean by this? Most SCSI devices don't handle ATA_16 because > it's only useful if the device is actually an ATA device behind a > bridge. > > As a general rule, you shouldn't filter in the driver commands you think > the host won't want to see, you should let the host reply with an error > code. You should *only* filter commands that cause an actual bug in the > host. Is the latter the case for this command (if so that needs to be > explained)? As I explained in my email to Christoph, the Windows host returns error codes that I cannot properly decode as being "unsupported opcode". Let me investigate a little more and see if I can properly analyze the failure and return the correct error code up. If the error code I get back from Windows is such that I cannot deduce the cause of the failure, then apart from filtering the commands in the outgoing path, I am not sure what my options are. > > > Signed-off-by: K. Y. Srinivasan <kys@xxxxxxxxxxxxx> > > Signed-off-by: Haiyang Zhang <haiyangz@xxxxxxxxxxxxx> > > This signoff chain doesn't make sense, since you're sending me the patch > and apparently you authored it. Good point. Since I came to MSFT, this has been the practice here - all the patches were reviewed and "signed-off" by all the relevant developers independent of the authorship and Greg seemed ok with it and has been ascribing ownership based on the person sending the patch who is always the author of the patch. How would you recommend we change this practice. Regards, K. Y _______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
