From a33f32244d8550da8b4a26e277ce07d5c6d158b5 Mon Sep 17 00:00:00 2001 From: Francis Galiegue Date: Fri, 23 Apr 2010 00:08:02 +0200 Subject: Documentation/: it's -> its where appropriate Fix obvious cases of "it's" being used when "its" was meant. Signed-off-by: Francis Galiegue Acked-by: Randy Dunlap Signed-off-by: Jiri Kosina --- Documentation/scsi/scsi_fc_transport.txt | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) (limited to 'Documentation/scsi/scsi_fc_transport.txt') diff --git a/Documentation/scsi/scsi_fc_transport.txt b/Documentation/scsi/scsi_fc_transport.txt index aec6549ab097..e00192de4d1c 100644 --- a/Documentation/scsi/scsi_fc_transport.txt +++ b/Documentation/scsi/scsi_fc_transport.txt @@ -70,7 +70,7 @@ Overview: up to an administrative entity controlling the vport. For example, if vports are to be associated with virtual machines, a XEN mgmt utility would be responsible for creating wwpn/wwnn's for the vport, - using it's own naming authority and OUI. (Note: it already does this + using its own naming authority and OUI. (Note: it already does this for virtual MAC addresses). @@ -81,7 +81,7 @@ Device Trees and Vport Objects: with rports and scsi target objects underneath it. Currently the FC transport creates the vport object and places it under the scsi_host object corresponding to the physical adapter. The LLDD will allocate - a new scsi_host for the vport and link it's object under the vport. + a new scsi_host for the vport and link its object under the vport. The remainder of the tree under the vports scsi_host is the same as the non-NPIV case. The transport is written currently to easily allow the parent of the vport to be something other than the scsi_host. -- cgit