> -----Original Message-----> From: James Bottomley [mailto:James.Bottomley@HansenPartnership.com]> Sent: Sunday, March 04, 2012 9:20 AM> To: KY Srinivasan> Cc: gregkh@linuxfoundation.org; linux-kernel@vger.kernel.org;> devel@linuxdriverproject.org; ohering@suse.com; hch@infradead.org; linux-> scsi@vger.kernel.org; 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 thatI cannot properly decode as being "unsupported opcode". Let me investigate a little moreand see if I can properly analyze the failure and return the correct error code up. If the error codeI get back from Windows is such that I cannot deduce the cause of the failure, then apart from filteringthe commands in the outgoing path, I am not sure what my options are.

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 developersindependent of the authorship and Greg seemed ok with it and has been ascribingownership based on the person sending the patch who is always the author of thepatch. How would you recommend we change this practice.