On Tue, 2013-07-30 at 00:35 +0530, Santosh Y wrote: > From: Sujit Reddy Thumma <sthumma@xxxxxxxxxxxxxx> > > As part of device initialization sequence, sending NOP OUT UPIU and > waiting for NOP IN UPIU response is mandatory. This confirms that the > device UFS Transport (UTP) layer is functional and the host can configure > the device with further commands. Add support for sending NOP OUT UPIU to > check the device connection path and test whether the UTP layer on the > device side is functional during initialization. > > A tag is acquired from the SCSI tag map space in order to send the device > management command. When the tag is acquired by internal command the scsi > command is rejected with host busy flag in order to requeue the request. > To avoid frequent collisions between internal commands and scsi commands > the device management command tag is allocated in the opposite direction > w.r.t block layer tag allocation. > > Signed-off-by: Sujit Reddy Thumma <sthumma@xxxxxxxxxxxxxx> > Signed-off-by: Dolev Raviv <draviv@xxxxxxxxxxxxxx> > Signed-off-by: Santosh Y <santoshsy@xxxxxxxxx> This signoff chain looks wrong to me. The patch has quite a long history. Originally, it was sent in by Sujit, then later resent by Dolev with his signoff, then Sujit did a V2 which incorrectly seemed to include Dolev's signoff (that's not correct: signoffs should follow the chain of transmission, so a new patch wouldn't have a previous transmission signoff). Then we got a V3 which was tested by Maya Erez, and finally a v4 which looks to have no testers. In your last submission, you picked up this signoff, so I've changed it to a reviewed-by which seems to be the most appropriate (although I'm not entirely sure Dolev did review the v4 patch). If this is wrong and Dolev did rewrite the patch (so is one of the authors, which would explain the signoff chain) let me know and I'll edit it in the tree (rebasing is acceptable to get the correct history). James -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
