[PATCH] allow a transport to pre-initialize starget_data

[PATCH] allow a transport to pre-initialize starget_data

[Christoph Hellwig]

Add a new void *transport_data argument to scsi_scan_target so that a
transport-class can fill in known information before actually scanning
the target.  This is needed by the upcoming SAS transport class patch.


Signed-off-by: Christoph Hellwig <hch@lst.de>

Index: scsi-misc-2.6/drivers/scsi/scsi_scan.c
===================================================================
--- scsi-misc-2.6.orig/drivers/scsi/scsi_scan.c	2005-08-13 13:53:54.000000000 +0200
+++ scsi-misc-2.6/drivers/scsi/scsi_scan.c	2005-08-15 15:32:57.000000000 +0200
@@ -329,7 +329,8 @@
 }
 
 static struct scsi_target *scsi_alloc_target(struct device *parent,
-					     int channel, uint id)
+					     int channel, uint id,
+					     void *transport_data)
 {
 	struct Scsi_Host *shost = dev_to_shost(parent);
 	struct device *dev = NULL;
@@ -344,6 +345,12 @@
 		return NULL;
 	}
 	memset(starget, 0, size);
+
+	if (transport_data) {
+		memcpy((char *)starget->starget_data, transport_data,
+				shost->transportt->target_size);
+	}
+
 	dev = &starget->dev;
 	device_initialize(dev);
 	starget->reap_ref = 1;
@@ -1244,8 +1251,9 @@
 	struct scsi_device *sdev;
 	struct device *parent = &shost->shost_gendev;
 	int res;
-	struct scsi_target *starget = scsi_alloc_target(parent, channel, id);
+	struct scsi_target *starget;
 
+	starget = scsi_alloc_target(parent, channel, id, NULL);
 	if (!starget)
 		return ERR_PTR(-ENOMEM);
 
@@ -1301,7 +1309,8 @@
  *     sequential scan of LUNs on the target id.
  **/
 void scsi_scan_target(struct device *parent, unsigned int channel,
-		      unsigned int id, unsigned int lun, int rescan)
+		      unsigned int id, unsigned int lun, int rescan,
+		      void *transport_data)
 {
 	struct Scsi_Host *shost = dev_to_shost(parent);
 	int bflags = 0;
@@ -1316,8 +1325,7 @@
 		return;
 
 
-	starget = scsi_alloc_target(parent, channel, id);
-
+	starget = scsi_alloc_target(parent, channel, id, transport_data);
 	if (!starget)
 		return;
 
@@ -1388,10 +1396,12 @@
 				order_id = shost->max_id - id - 1;
 			else
 				order_id = id;
-			scsi_scan_target(&shost->shost_gendev, channel, order_id, lun, rescan);
+			scsi_scan_target(&shost->shost_gendev, channel,
+					 order_id, lun, rescan, NULL);
 		}
 	else
-		scsi_scan_target(&shost->shost_gendev, channel, id, lun, rescan);
+		scsi_scan_target(&shost->shost_gendev, channel,
+				 id, lun, rescan, NULL);
 }
 
 int scsi_scan_host_selected(struct Scsi_Host *shost, unsigned int channel,
@@ -1492,7 +1502,8 @@
 	struct scsi_device *sdev;
 	struct scsi_target *starget;
 
-	starget = scsi_alloc_target(&shost->shost_gendev, 0, shost->this_id);
+	starget = scsi_alloc_target(&shost->shost_gendev, 0,
+				    shost->this_id, NULL);
 	if (!starget)
 		return NULL;
 
Index: scsi-misc-2.6/drivers/scsi/scsi_transport_fc.c
===================================================================
--- scsi-misc-2.6.orig/drivers/scsi/scsi_transport_fc.c	2005-08-13 13:53:54.000000000 +0200
+++ scsi-misc-2.6/drivers/scsi/scsi_transport_fc.c	2005-08-15 15:32:42.000000000 +0200
@@ -1653,7 +1653,7 @@
 	struct fc_rport *rport = (struct fc_rport *)data;
 
 	scsi_scan_target(&rport->dev, rport->channel, rport->scsi_target_id,
-			SCAN_WILD_CARD, 1);
+			SCAN_WILD_CARD, 1, NULL);
 }
 
 
Index: scsi-misc-2.6/include/scsi/scsi_device.h
===================================================================
--- scsi-misc-2.6.orig/include/scsi/scsi_device.h	2005-08-13 13:54:07.000000000 +0200
+++ scsi-misc-2.6/include/scsi/scsi_device.h	2005-08-15 15:32:42.000000000 +0200
@@ -238,7 +238,8 @@
 extern void scsi_target_quiesce(struct scsi_target *);
 extern void scsi_target_resume(struct scsi_target *);
 extern void scsi_scan_target(struct device *parent, unsigned int channel,
-			     unsigned int id, unsigned int lun, int rescan);
+			     unsigned int id, unsigned int lun, int rescan,
+			     void *transport_data);
 extern void scsi_target_reap(struct scsi_target *);
 extern void scsi_target_block(struct device *);
 extern void scsi_target_unblock(struct device *);

Re: [PATCH] allow a transport to pre-initialize starget_data

[James Bottomley]

On Mon, 2005-08-15 at 15:42 +0200, Christoph Hellwig wrote:
> Add a new void *transport_data argument to scsi_scan_target so that a
> transport-class can fill in known information before actually scanning
> the target.  This is needed by the upcoming SAS transport class patch.

Given that you're testing fusion, I'm surprised you missed this.

James

diff --git a/drivers/message/fusion/mptspi.c b/drivers/message/fusion/mptspi.c
--- a/drivers/message/fusion/mptspi.c
+++ b/drivers/message/fusion/mptspi.c
@@ -564,7 +564,7 @@ static void mpt_work_wrapper(void *data)
 	mpt_read_ioc_pg_3(hd->ioc);
 	dev_printk(KERN_INFO, &hd->ioc->sh->shost_gendev,
 		   "Integrated RAID detects new device %d\n", disk);
-	scsi_scan_target(&hd->ioc->sh->shost_gendev, 1, disk, 0, 1);
+	scsi_scan_target(&hd->ioc->sh->shost_gendev, 1, disk, 0, 1, NULL);
 }
 
 

Re: [PATCH] allow a transport to pre-initialize starget_data

[Luben Tuikov]

On 08/15/05 09:42, Christoph Hellwig wrote:
> Add a new void *transport_data argument to scsi_scan_target so that a
> transport-class can fill in known information before actually scanning
> the target.  This is needed by the upcoming SAS transport class patch.

Hmm, yes, this has been due for 5 years now.

While you're at it, rip out the extremely broken "channel" and "id",
and leave only the opaque token.

	Luben

> 
> 
> Signed-off-by: Christoph Hellwig <hch@lst.de>
> 
> Index: scsi-misc-2.6/drivers/scsi/scsi_scan.c
> ===================================================================
> --- scsi-misc-2.6.orig/drivers/scsi/scsi_scan.c	2005-08-13 13:53:54.000000000 +0200
> +++ scsi-misc-2.6/drivers/scsi/scsi_scan.c	2005-08-15 15:32:57.000000000 +0200
> @@ -329,7 +329,8 @@
>  }
>  
>  static struct scsi_target *scsi_alloc_target(struct device *parent,
> -					     int channel, uint id)
> +					     int channel, uint id,
> +					     void *transport_data)
>  {
>  	struct Scsi_Host *shost = dev_to_shost(parent);
>  	struct device *dev = NULL;
> @@ -344,6 +345,12 @@
>  		return NULL;
>  	}
>  	memset(starget, 0, size);
> +
> +	if (transport_data) {
> +		memcpy((char *)starget->starget_data, transport_data,
> +				shost->transportt->target_size);
> +	}
> +
>  	dev = &starget->dev;
>  	device_initialize(dev);
>  	starget->reap_ref = 1;
> @@ -1244,8 +1251,9 @@
>  	struct scsi_device *sdev;
>  	struct device *parent = &shost->shost_gendev;
>  	int res;
> -	struct scsi_target *starget = scsi_alloc_target(parent, channel, id);
> +	struct scsi_target *starget;
>  
> +	starget = scsi_alloc_target(parent, channel, id, NULL);
>  	if (!starget)
>  		return ERR_PTR(-ENOMEM);
>  
> @@ -1301,7 +1309,8 @@
>   *     sequential scan of LUNs on the target id.
>   **/
>  void scsi_scan_target(struct device *parent, unsigned int channel,
> -		      unsigned int id, unsigned int lun, int rescan)
> +		      unsigned int id, unsigned int lun, int rescan,
> +		      void *transport_data)
>  {
>  	struct Scsi_Host *shost = dev_to_shost(parent);
>  	int bflags = 0;
> @@ -1316,8 +1325,7 @@
>  		return;
>  
>  
> -	starget = scsi_alloc_target(parent, channel, id);
> -
> +	starget = scsi_alloc_target(parent, channel, id, transport_data);
>  	if (!starget)
>  		return;
>  
> @@ -1388,10 +1396,12 @@
>  				order_id = shost->max_id - id - 1;
>  			else
>  				order_id = id;
> -			scsi_scan_target(&shost->shost_gendev, channel, order_id, lun, rescan);
> +			scsi_scan_target(&shost->shost_gendev, channel,
> +					 order_id, lun, rescan, NULL);
>  		}
>  	else
> -		scsi_scan_target(&shost->shost_gendev, channel, id, lun, rescan);
> +		scsi_scan_target(&shost->shost_gendev, channel,
> +				 id, lun, rescan, NULL);
>  }
>  
>  int scsi_scan_host_selected(struct Scsi_Host *shost, unsigned int channel,
> @@ -1492,7 +1502,8 @@
>  	struct scsi_device *sdev;
>  	struct scsi_target *starget;
>  
> -	starget = scsi_alloc_target(&shost->shost_gendev, 0, shost->this_id);
> +	starget = scsi_alloc_target(&shost->shost_gendev, 0,
> +				    shost->this_id, NULL);
>  	if (!starget)
>  		return NULL;
>  
> Index: scsi-misc-2.6/drivers/scsi/scsi_transport_fc.c
> ===================================================================
> --- scsi-misc-2.6.orig/drivers/scsi/scsi_transport_fc.c	2005-08-13 13:53:54.000000000 +0200
> +++ scsi-misc-2.6/drivers/scsi/scsi_transport_fc.c	2005-08-15 15:32:42.000000000 +0200
> @@ -1653,7 +1653,7 @@
>  	struct fc_rport *rport = (struct fc_rport *)data;
>  
>  	scsi_scan_target(&rport->dev, rport->channel, rport->scsi_target_id,
> -			SCAN_WILD_CARD, 1);
> +			SCAN_WILD_CARD, 1, NULL);
>  }
>  
>  
> Index: scsi-misc-2.6/include/scsi/scsi_device.h
> ===================================================================
> --- scsi-misc-2.6.orig/include/scsi/scsi_device.h	2005-08-13 13:54:07.000000000 +0200
> +++ scsi-misc-2.6/include/scsi/scsi_device.h	2005-08-15 15:32:42.000000000 +0200
> @@ -238,7 +238,8 @@
>  extern void scsi_target_quiesce(struct scsi_target *);
>  extern void scsi_target_resume(struct scsi_target *);
>  extern void scsi_scan_target(struct device *parent, unsigned int channel,
> -			     unsigned int id, unsigned int lun, int rescan);
> +			     unsigned int id, unsigned int lun, int rescan,
> +			     void *transport_data);
>  extern void scsi_target_reap(struct scsi_target *);
>  extern void scsi_target_block(struct device *);
>  extern void scsi_target_unblock(struct device *);
> -
> To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

Re: [PATCH] allow a transport to pre-initialize starget_data

[James Bottomley]

On Mon, 2005-08-15 at 11:18 -0400, Luben Tuikov wrote:
> While you're at it, rip out the extremely broken "channel" and "id",
> and leave only the opaque token.

Unfortunately, I just found an actual use for channel (exposing
underlying physical discs of raid devices) and, unfortunately, we're
still not yet at the point where we can use an opaque token for ID, but
if someone wants to look into what it would take to convert the rest of
SCSI ...

James

Re: [PATCH] allow a transport to pre-initialize starget_data

[Christoph Hellwig]

On Mon, Aug 15, 2005 at 11:18:10AM -0400, Luben Tuikov wrote:
> On 08/15/05 09:42, Christoph Hellwig wrote:
> > Add a new void *transport_data argument to scsi_scan_target so that a
> > transport-class can fill in known information before actually scanning
> > the target.  This is needed by the upcoming SAS transport class patch.
> 
> Hmm, yes, this has been due for 5 years now.
> 
> While you're at it, rip out the extremely broken "channel" and "id",
> and leave only the opaque token.

Well, it's not a token but pre-initialized data.  The problem with
ripping out channel and id is that userland would break all over,
else we'd have done it already.

Re: [PATCH] allow a transport to pre-initialize starget_data

[Luben Tuikov]

Hi guys, :-)

That's a lot of email. :-)

On 08/15/05 11:23, James Bottomley wrote:
> On Mon, 2005-08-15 at 11:18 -0400, Luben Tuikov wrote:
> 
>>While you're at it, rip out the extremely broken "channel" and "id",
>>and leave only the opaque token.
> 
> 
> Unfortunately, I just found an actual use for channel (exposing
> underlying physical discs of raid devices) and, unfortunately, we're
> still not yet at the point where we can use an opaque token for ID, but
> if someone wants to look into what it would take to convert the rest of
> SCSI ...

Hmm, you've 
    "found an actual use for channel (exposing underlying physical discs
     of raid devices)".

I'm completely befuddled James.

What if we didn't have "channel" (SPI leftover) in the first place?
Or, if an LU is implemented as a RAID device, how do you find out its
individual disks?

Is there a spec or standard that you're following in doing this?

On 08/15/05 11:25, Christoph Hellwig wrote:
> On Mon, Aug 15, 2005 at 11:18:10AM -0400, Luben Tuikov wrote:
> 
>>On 08/15/05 09:42, Christoph Hellwig wrote:
>>
>>>Add a new void *transport_data argument to scsi_scan_target so that a
>>>transport-class can fill in known information before actually scanning
>>>the target.  This is needed by the upcoming SAS transport class patch.
>>
>>Hmm, yes, this has been due for 5 years now.
>>
>>While you're at it, rip out the extremely broken "channel" and "id",
>>and leave only the opaque token.
> 
> Well, it's not a token but pre-initialized data.  The problem with
> ripping out channel and id is that userland would break all over,
> else we'd have done it already.

Ah, ok.

Is it possible to figure out which parts of userland rely on
HCIL tuples, as opposed to "scsi device I can send commands to"?

Than we can fix those userland programs and we can move into
the future.

	Luben

Re: [PATCH] allow a transport to pre-initialize starget_data

[James Bottomley]

On Mon, 2005-08-15 at 11:41 -0400, Luben Tuikov wrote:
> Hmm, you've 
>     "found an actual use for channel (exposing underlying physical discs
>      of raid devices)".
> 
> I'm completely befuddled James.

For RAID cards in the SCSI subsystem that export RAID devices as SCSI
devices, there's a need of a standard way to get at the underlying
devices (for DV, parameter setting or configuration).  The idea is to
expose these devices on a non zero channel.

> What if we didn't have "channel" (SPI leftover) in the first place?
> Or, if an LU is implemented as a RAID device, how do you find out its
> individual disks?

It's not a SPI leftover.  It's used by HBA's that have two channels that
genuinely share resources.  Although most modern SCSI cards simply have
two chips (and hence two separate HBAs) per channel, there are a few, of
which the qlogic fc card is one, that still have this one chip per two
channels model.

> Is there a spec or standard that you're following in doing this?

It's an OS abstraction, so no.

James

Re: [PATCH] allow a transport to pre-initialize starget_data

[Luben Tuikov]

On 08/15/05 11:53, James Bottomley wrote:
> On Mon, 2005-08-15 at 11:41 -0400, Luben Tuikov wrote:
> 
>>Hmm, you've 
>>    "found an actual use for channel (exposing underlying physical discs
>>     of raid devices)".
>>
>>I'm completely befuddled James.
> 
> 
> For RAID cards in the SCSI subsystem that export RAID devices as SCSI
> devices, there's a need of a standard way to get at the underlying
> devices (for DV, parameter setting or configuration).  The idea is to
> expose these devices on a non zero channel.

Isn't DV an SPI paradigm?

If the whole point of the LLDD+controller is to _give_ you this,
"an LU which is actually RAID", abstraction, why does SCSI Core
need to get to the underlying devices?

What will SCSI Core do with the RAID members?  Why is SCSI Core
concerned with this information?  What kind of parameters will
it have to set, without the RAID device server knowing about it
(which is implemented on the chip if HW RAID)?

>>What if we didn't have "channel" (SPI leftover) in the first place?
>>Or, if an LU is implemented as a RAID device, how do you find out its
>>individual disks?
> 
> It's not a SPI leftover.  It's used by HBA's that have two channels that
> genuinely share resources.  Although most modern SCSI cards simply have
> two chips (and hence two separate HBAs) per channel, there are a few, of
> which the qlogic fc card is one, that still have this one chip per two
> channels model.

Ah, I see.

Please help me understand this:

You say that "channel" is not an SPI leftover but it is used
by SCSI Core because 

	"HBA's that have two channels that genuinely share resources".

Why is SCSI Core concerned with how HBAs are _built_?  Isn't this
the LLDD's job?

Is "channel" in SCSI Core used to _address_ SCSI devices?
How many of those "channel" will we need?

>>Is there a spec or standard that you're following in doing this?
> 
> It's an OS abstraction, so no.

Ah, ok.  So I cannot find any printed media describing
the "OS abstraction" which you're implementing?  Not even in
an Operating System book then, possibly storage related?

	Luben

Re: [PATCH] allow a transport to pre-initialize starget_data

[James Bottomley]

On Mon, 2005-08-15 at 12:10 -0400, Luben Tuikov wrote:
> Isn't DV an SPI paradigm?

Yes, but that's only one of the reasons to expose the underlying device.

> If the whole point of the LLDD+controller is to _give_ you this,
> "an LU which is actually RAID", abstraction, why does SCSI Core
> need to get to the underlying devices?

Because lots of the RAID drivers have internal code that performs
actions, like DV, on their underlying physical discs.

> What will SCSI Core do with the RAID members?  Why is SCSI Core
> concerned with this information?  What kind of parameters will
> it have to set, without the RAID device server knowing about it
> (which is implemented on the chip if HW RAID)?

Nothing except expose them ... that's the idea.  The parameters are set
from user level after that.  This elimiates need for the pass through
ioctl that all of these drivers have.

> > It's not a SPI leftover.  It's used by HBA's that have two channels that
> > genuinely share resources.  Although most modern SCSI cards simply have
> > two chips (and hence two separate HBAs) per channel, there are a few, of
> > which the qlogic fc card is one, that still have this one chip per two
> > channels model.
> 
> Ah, I see.
> 
> Please help me understand this:
> 
> You say that "channel" is not an SPI leftover but it is used
> by SCSI Core because 
> 
> 	"HBA's that have two channels that genuinely share resources".
> 
> Why is SCSI Core concerned with how HBAs are _built_?  Isn't this
> the LLDD's job?

Because resource management belongs in the mid-layer.  In particular
available commands per host.

> Is "channel" in SCSI Core used to _address_ SCSI devices?
> How many of those "channel" will we need?

On the wire? No.  In the mid-layer, not really, since devices are
addressed by struct scsi_device.  The channel makes a useful
discriminator for the LLD in the scsi device, however.

James

Re: [PATCH] allow a transport to pre-initialize starget_data

[Luben Tuikov]

On 08/15/05 12:32, James Bottomley wrote:
>>What will SCSI Core do with the RAID members?  Why is SCSI Core
>>concerned with this information?  What kind of parameters will
>>it have to set, without the RAID device server knowing about it
>>(which is implemented on the chip if HW RAID)?
> 
> 
> Nothing except expose them ... that's the idea.  The parameters are set
> from user level after that.  This elimiates need for the pass through
> ioctl that all of these drivers have.

Ah, ok.  It is this ioctl thing.  Really it never crossed my mind.

Thanks,
	Luben

RE: [PATCH] allow a transport to pre-initialize starget_data

[James.Smart]

I don't agree with the need for this patch.

See http://marc.theaimsgroup.com/?l=linux-scsi&m=112437379823295&w=2

I think it's also a wart to add this to the scan logic, and error prone.
The error (or inconsistency) exists when the scan is not initiated by
the transport, and the target doesn't exist. Consider the scenario
where a manual remove of the target and sdevs is performed, followed
by a manual scan request.

-- james


> -----Original Message-----
> From: linux-scsi-owner@vger.kernel.org
> [mailto:linux-scsi-owner@vger.kernel.org]On Behalf Of 
> Christoph Hellwig
> Sent: Monday, August 15, 2005 9:42 AM
> To: jejb@steeleye.com
> Cc: linux-scsi@vger.kernel.org
> Subject: [PATCH] allow a transport to pre-initialize starget_data
> 
> 
> Add a new void *transport_data argument to scsi_scan_target so that a
> transport-class can fill in known information before actually scanning
> the target.  This is needed by the upcoming SAS transport class patch.
> 
> 
> Signed-off-by: Christoph Hellwig <hch@lst.de>
> 
> Index: scsi-misc-2.6/drivers/scsi/scsi_scan.c
> ===================================================================
> --- scsi-misc-2.6.orig/drivers/scsi/scsi_scan.c	
> 2005-08-13 13:53:54.000000000 +0200
> +++ scsi-misc-2.6/drivers/scsi/scsi_scan.c	2005-08-15 
> 15:32:57.000000000 +0200
> @@ -329,7 +329,8 @@
>  }
>  
>  static struct scsi_target *scsi_alloc_target(struct device *parent,
> -					     int channel, uint id)
> +					     int channel, uint id,
> +					     void *transport_data)
>  {
>  	struct Scsi_Host *shost = dev_to_shost(parent);
>  	struct device *dev = NULL;
> @@ -344,6 +345,12 @@
>  		return NULL;
>  	}
>  	memset(starget, 0, size);
> +
> +	if (transport_data) {
> +		memcpy((char *)starget->starget_data, transport_data,
> +				shost->transportt->target_size);
> +	}
> +
>  	dev = &starget->dev;
>  	device_initialize(dev);
>  	starget->reap_ref = 1;
> @@ -1244,8 +1251,9 @@
>  	struct scsi_device *sdev;
>  	struct device *parent = &shost->shost_gendev;
>  	int res;
> -	struct scsi_target *starget = scsi_alloc_target(parent, 
> channel, id);
> +	struct scsi_target *starget;
>  
> +	starget = scsi_alloc_target(parent, channel, id, NULL);
>  	if (!starget)
>  		return ERR_PTR(-ENOMEM);
>  
> @@ -1301,7 +1309,8 @@
>   *     sequential scan of LUNs on the target id.
>   **/
>  void scsi_scan_target(struct device *parent, unsigned int channel,
> -		      unsigned int id, unsigned int lun, int rescan)
> +		      unsigned int id, unsigned int lun, int rescan,
> +		      void *transport_data)
>  {
>  	struct Scsi_Host *shost = dev_to_shost(parent);
>  	int bflags = 0;
> @@ -1316,8 +1325,7 @@
>  		return;
>  
>  
> -	starget = scsi_alloc_target(parent, channel, id);
> -
> +	starget = scsi_alloc_target(parent, channel, id, 
> transport_data);
>  	if (!starget)
>  		return;
>  
> @@ -1388,10 +1396,12 @@
>  				order_id = shost->max_id - id - 1;
>  			else
>  				order_id = id;
> -			scsi_scan_target(&shost->shost_gendev, 
> channel, order_id, lun, rescan);
> +			scsi_scan_target(&shost->shost_gendev, channel,
> +					 order_id, lun, rescan, NULL);
>  		}
>  	else
> -		scsi_scan_target(&shost->shost_gendev, channel, 
> id, lun, rescan);
> +		scsi_scan_target(&shost->shost_gendev, channel,
> +				 id, lun, rescan, NULL);
>  }
>  
>  int scsi_scan_host_selected(struct Scsi_Host *shost, 
> unsigned int channel,
> @@ -1492,7 +1502,8 @@
>  	struct scsi_device *sdev;
>  	struct scsi_target *starget;
>  
> -	starget = scsi_alloc_target(&shost->shost_gendev, 0, 
> shost->this_id);
> +	starget = scsi_alloc_target(&shost->shost_gendev, 0,
> +				    shost->this_id, NULL);
>  	if (!starget)
>  		return NULL;
>  
> Index: scsi-misc-2.6/drivers/scsi/scsi_transport_fc.c
> ===================================================================
> --- scsi-misc-2.6.orig/drivers/scsi/scsi_transport_fc.c	
> 2005-08-13 13:53:54.000000000 +0200
> +++ scsi-misc-2.6/drivers/scsi/scsi_transport_fc.c	
> 2005-08-15 15:32:42.000000000 +0200
> @@ -1653,7 +1653,7 @@
>  	struct fc_rport *rport = (struct fc_rport *)data;
>  
>  	scsi_scan_target(&rport->dev, rport->channel, 
> rport->scsi_target_id,
> -			SCAN_WILD_CARD, 1);
> +			SCAN_WILD_CARD, 1, NULL);
>  }
>  
>  
> Index: scsi-misc-2.6/include/scsi/scsi_device.h
> ===================================================================
> --- scsi-misc-2.6.orig/include/scsi/scsi_device.h	
> 2005-08-13 13:54:07.000000000 +0200
> +++ scsi-misc-2.6/include/scsi/scsi_device.h	2005-08-15 
> 15:32:42.000000000 +0200
> @@ -238,7 +238,8 @@
>  extern void scsi_target_quiesce(struct scsi_target *);
>  extern void scsi_target_resume(struct scsi_target *);
>  extern void scsi_scan_target(struct device *parent, unsigned 
> int channel,
> -			     unsigned int id, unsigned int lun, 
> int rescan);
> +			     unsigned int id, unsigned int lun, 
> int rescan,
> +			     void *transport_data);
>  extern void scsi_target_reap(struct scsi_target *);
>  extern void scsi_target_block(struct device *);
>  extern void scsi_target_unblock(struct device *);
> -
> To unsubscribe from this list: send the line "unsubscribe 
> linux-scsi" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>