[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <1203264186.3082.33.camel@localhost.localdomain>
Date: Sun, 17 Feb 2008 10:03:05 -0600
From: James Bottomley <James.Bottomley@...senPartnership.com>
To: Stefan Richter <stefanr@...6.in-berlin.de>
Cc: linux1394-devel@...ts.sourceforge.net,
linux-kernel@...r.kernel.org, linux-scsi@...r.kernel.org
Subject: Re: [PATCH] ieee1394: sbp2: fix rescan-scsi-bus
On Sun, 2008-02-17 at 14:57 +0100, Stefan Richter wrote:
> rescan-scsi-bus used to add SBP-2 targets which weren't there.
>
> Signed-off-by: Stefan Richter <stefanr@...6.in-berlin.de>
> ---
> drivers/ieee1394/sbp2.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> Index: linux/drivers/ieee1394/sbp2.c
> ===================================================================
> --- linux.orig/drivers/ieee1394/sbp2.c
> +++ linux/drivers/ieee1394/sbp2.c
> @@ -1974,6 +1974,9 @@ static int sbp2scsi_slave_alloc(struct s
> {
> struct sbp2_lu *lu = (struct sbp2_lu *)sdev->host->hostdata[0];
>
> + if (sdev->lun != 0 || sdev->id != lu->ud->id || sdev->channel != 0)
> + return -ENODEV;
> +
It's hard to know what to say about this. The infrastructure for
scanning did move to separate scanned (old parallel and a few other)
busses from hotplug ones (which is what sbp2 is). You really need to
look at the scan_finished and user_scan callbacks. Unfortunately the
latter is a transport class function and how all the modern busses (FC,
SAS and the like do this).
James
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists