[PATCH 1/1] Drivers: scsi: storvsc: Don't pass ATA_16 command to the host

KY Srinivasan kys at microsoft.com
Sun Mar 4 23:15:07 UTC 2012

> -----Original Message-----
> From: James Bottomley [mailto:James.Bottomley at HansenPartnership.com]
> Sent: Sunday, March 04, 2012 9:20 AM
> To: KY Srinivasan
> Cc: gregkh at linuxfoundation.org; linux-kernel at vger.kernel.org;
> devel at linuxdriverproject.org; ohering at suse.com; hch at infradead.org; linux-
> scsi at 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 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 at microsoft.com>
> > Signed-off-by: Haiyang Zhang <haiyangz at microsoft.com>
> 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. 


K. Y

More information about the devel mailing list