Skip to contentSkip to conversation

Add SATA support to libsas

PATCH In review Darrick J. Wong 6 participants 6 messages Aug 11, 2006 – Aug 25, 2006

Subsystems (2)
lore
Share & tools
lore
#0 lore raw

PATCH 1/2 Add SATA support to libsas

Hook the scsi_host_template functions in libsas to delegate functionality to libata when appropriate.

drivers/scsi/libsas/sas_discover.c +18 -2
index b0705ee..76bbb9f 100644
@@ -255,6 +255,7 @@ static int sas_get_port_device(struct as
 
 	switch (dev->dev_type) {
 	case SAS_END_DEV:
+	case SATA_DEV:
 		rphy = sas_end_device_alloc(port->port);
 		break;
 	case EDGE_DEV:
@@ -265,7 +266,6 @@ static int sas_get_port_device(struct as
 		rphy = sas_expander_alloc(port->port,
 					  SAS_FANOUT_EXPANDER_DEVICE);
 		break;
-	case SATA_DEV:
 	default:
 		printk("ERROR: Unidentified device type %d\n", dev->dev_type);
 		rphy = NULL;
@@ -398,6 +398,15 @@ static void sas_sata_propagate_sas_addr(
 	spin_unlock_irqrestore(&port->phy_list_lock, flags);
 }
 
+static inline void sas_mark_dev_sata(struct domain_device *dev)
+{
+	dev->rphy->identify = dev->port->phy->identify;
+	dev->rphy->identify.initiator_port_protocols = SAS_PROTOCOL_SATA;
+	dev->rphy->identify.target_port_protocols = SAS_PROTOCOL_SATA;
+	dev->rphy->identify.device_type = SAS_END_DEVICE;
+	memcpy(&dev->rphy->identify.sas_address, dev->sas_addr, SAS_ADDR_SIZE);
+}
+
 #define ATA_IDENTIFY_DEV         0xEC
 #define ATA_IDENTIFY_PACKET_DEV  0xA1
 #define ATA_SET_FEATURES         0xEF
@@ -480,7 +489,14 @@ cont1:
 	   present.
 	sas_satl_register_dev(dev);
 	*/
-	return 0;
+	
+	sas_mark_dev_sata(dev);
+
+	res = sas_rphy_add(dev->rphy);
+	if (res)
+		goto out_err;
+
+	return res;
 out_err:
 	dev->sata_dev.identify_packet_device = NULL;
 	dev->sata_dev.identify_device = NULL;
drivers/scsi/libsas/sas_scsi_host.c +350 -1

405 lines not on this page · raw message

include/scsi/libsas.h +12 -0
index b109fe5..0aaac5c 100644
@@ -30,6 +30,7 @@
 #include <linux/timer.h>
 #include <linux/pci.h>
 #include <scsi/sas.h>
+#include <linux/libata.h>
 #include <linux/list.h>
 #include <asm/semaphore.h>
 #include <scsi/scsi_device.h>
@@ -164,6 +165,13 @@ struct sata_device {
 
         u8     port_no;        /* port number, if this is a PM (Port) */
         struct list_head children; /* PM Ports if this is a PM */
+
+	struct ata_port *ap;
+	struct ata_host_set ata_host_set;
+	struct ata_taskfile tf;
+	u32 sstatus;
+	u32 serror;
+	u32 scontrol;
 };
 
 /* ---------- Domain device ---------- */
@@ -626,4 +634,8 @@ void sas_unregister_devices(struct sas_h
 
 void sas_init_dev(struct domain_device *);
 
+extern void sas_target_destroy(struct scsi_target *);
+extern int sas_slave_alloc(struct scsi_device *);
+extern int sas_ioctl(struct scsi_device *sdev, int cmd, void __user *arg);
+
 #endif /* _SASLIB_H_ */
#1 lore raw
Quoted 4 lines · Darrick J. Wong

Hook the scsi_host_template functions in libsas to delegate functionality to libata when appropriate.

One piece that seems to be distinctly absent is controlling the SATA phy, rather than faking it...

Jeff

#2 lore raw
Quoted 2 lines · Jeff Garzik

One piece that seems to be distinctly absent is controlling the SATA phy, rather than faking it...

Could you elaborate a bit more? You mean this faking of the SATA Control Registers? If so, this is a bit problematic ... SAS HBAs don't seem to come with SATA Control Registers (and certainly not when the device is remote over SAT). We do, however, have reasonable control of the phys via the transport class. Probably the best solution is to expand the ata transport class to abstract this phy control out into knobs users can twiddle and then put this back down to libata/libsas via callbacks they can each interpret.

James

maintainer
#3 lore raw
In reply to Darrick J. Wong
Quoted 10 lines · Darrick J. Wong
(quoted diff) +4 -0
+static inline void sas_mark_dev_sata(struct domain_device *dev)
+{
+       dev->rphy->identify = dev->port->phy->identify;
+       dev->rphy->identify.initiator_port_protocols =

SAS_PROTOCOL_SATA;

(quoted diff) +3 -0
+       dev->rphy->identify.target_port_protocols = SAS_PROTOCOL_SATA;
+       dev->rphy->identify.device_type = SAS_END_DEVICE;
+       memcpy(&dev->rphy->identify.sas_address, dev->sas_addr,

SAS_ADDR_SIZE);
+}

Actually, this is wrong: you can't memcpy from dev->sas_addr to identify.sas_addr the former is a big endian u8[8] and the latter is a u64. However, the function is unnecessary anyway. We already have a sas_fill_in_rphy that does all of this.

James

drivers/scsi/libsas/sas_discover.c +1 -10
Index: BUILD-2.6/drivers/scsi/libsas/sas_discover.c
===================================================================
@@ -398,15 +398,6 @@
 	spin_unlock_irqrestore(&port->phy_list_lock, flags);
 }
 
-static inline void sas_mark_dev_sata(struct domain_device *dev)
-{
-	dev->rphy->identify = dev->port->phy->identify;
-	dev->rphy->identify.initiator_port_protocols = SAS_PROTOCOL_SATA;
-	dev->rphy->identify.target_port_protocols = SAS_PROTOCOL_SATA;
-	dev->rphy->identify.device_type = SAS_END_DEVICE;
-	memcpy(&dev->rphy->identify.sas_address, dev->sas_addr, SAS_ADDR_SIZE);
-}
-
 #define ATA_IDENTIFY_DEV         0xEC
 #define ATA_IDENTIFY_PACKET_DEV  0xA1
 #define ATA_SET_FEATURES         0xEF
@@ -490,7 +481,7 @@
 	sas_satl_register_dev(dev);
 	*/
 	
-	sas_mark_dev_sata(dev);
+	sas_fill_in_rphy(dev, dev->rphy);
 
 	res = sas_rphy_add(dev->rphy);
 	if (res)
#4 lore raw
In reply to Darrick J. Wong
Quoted 9 lines · Darrick J. Wong

Hook the scsi_host_template functions in libsas to delegate functionality to libata when appropriate.

drivers/scsi/libsas/sas_discover.c +0 -0
index b0705ee..76bbb9f 100644

(...)

drivers/scsi/libsas/sas_discover.c void sas_unregister_devices(struct sas_h · line 640

Quoted 9 lines

/* ---------- Domain device ---------- */

drivers/scsi/libsas/sas_discover.c +4 -0
@@ -626,4 +634,8 @@ void sas_unregister_devices(struct sas_h
 
 void sas_init_dev(struct domain_device *);
 
+extern void sas_target_destroy(struct scsi_target *);
+extern int sas_slave_alloc(struct scsi_device *);
+extern int sas_ioctl(struct scsi_device *sdev, int cmd, void __user *arg);
+

Those should not be 'extern' otherwise the EXPORT_SYMBOL functions won't be found when the aic94xx is built as a module.

#5 lore raw
Quoted 18 lines · Konrad Rzeszutek
Quoted 9 lines · Darrick J. Wong

Hook the scsi_host_template functions in libsas to delegate functionality to libata when appropriate.

drivers/scsi/libsas/sas_discover.c +0 -0
index b0705ee..76bbb9f 100644

(...)

Quoted 5 lines

/* ---------- Domain device ---------- */

drivers/scsi/libsas/sas_discover.c +0 -0
@@ -626,4 +634,8 @@ void sas_unregister_devices(struct sas_h
 
 void sas_init_dev(struct domain_device *);
 
Quoted 7 lines

drivers/scsi/libsas/sas_discover.c void sas_unregister_devices(struct sas_h · line 640

Quoted 4 lines
drivers/scsi/libsas/sas_discover.c +4 -0
+extern void sas_target_destroy(struct scsi_target *);
+extern int sas_slave_alloc(struct scsi_device *);
+extern int sas_ioctl(struct scsi_device *sdev, int cmd, void __user *arg);
+

Those should not be 'extern' otherwise the EXPORT_SYMBOL functions won't be found when the aic94xx is built as a module.

The "extern"s can be dropped since they don't have any effect, but I don't see what problem you are thinking of.

cu
Adrian

Signature · 6 lines
    Gentoo kernels are 42 times more popular than SUSE kernels among
    KLive users  (a service by SUSE contractor Andrea Arcangeli that
    gathers data about kernels from many users worldwide).

       There are three kinds of lies: Lies, Damn Lies, and Statistics.
                                                    Benjamin Disraeli