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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




> -----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


[Index of Archives]     [Linux Driver Backports]     [DMA Engine]     [Linux GPIO]     [Linux SPI]     [Video for Linux]     [Linux USB Devel]     [Linux Coverity]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Yosemite Backpacking]
  Powered by Linux