On Mon, Aug 15, 2005 at 11:13:30AM -0400, Luben Tuikov wrote:
> > +void sas_add_target(struct sas_port *port, struct sas_identify *attached,
> > + uint channel, uint target)
> > +{
> > + if (attached->target_port_protocols &
> > + (SAS_PROTOCOL_SSP|SAS_PROTOCOL_STP|SAS_PROTOCOL_SATA))
> > + scsi_scan_target(&port->dev, channel, target, ~0, 0, attached);
> > +}
>
> I've a few questions:
>
> 1. What kind of device does the Fusion driver export?
> Is this a true end device, or is this the LU in the SSP end device?
> I.e. since the Fusion card firmware does everything about SAS there is,
> is also LU discovery done in the firmware, or does the firmware export
> only the SSP end devices and leave LU discovery to SCSI Core
> (as the code suggests)?
It seems to give notification for the actual LU, but doing an LU scan
works if you use the target ID from those reports. Given that I prefer
to do as much as possible in the transport class to have the same
behaviour for different HBAs I'd prefer to not rely on the firmware's
LU scan.
> 2. Since I saw that (end) devices bind to ports, what is the maximum
> number of ports that the Fusion firmware export?
right now it reports the number of physical ports, that's four or eight
for the cards I have. But again I don't have the actual documentation
yet.
> 3. Will control of SATA and STP devices be given to libata or will
> the Fision firmware make those look like SCSI devices?
Fusion makes them look like SCSI devices. As I mentioned I tested this
patch only with SATA disks. But as the command translation for cards
not doing thi in firmware would happen in the ->queuecommand path I
don't think the transport class should be involved with it.
-
: 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
