On 10/20/05 11:25, Moore, Eric Dean wrote: > > I had a very good discussion with Luben over the > phone last night. > > Luben clarified this for me in regards to expanders: > > http://www.t10.org/drafts.htm#sas2 > The linkerrors can be done by issuing a SMP passthru > sending SMP_REPORT_ERROR_LOG. Section 10.4.3.6 Example of it being used is shown in this user space program drivers/scsi/sas/expanders_conf.c:343: static int report_phy_error_log(char *smp_portal_name, int phy_id) > The link/phy reset can be done by issuing a SMP passthru > sending SMP_PHY_CONTROL. Section 10.4.3.10 Example of it being use is shown in drivers/scsi/sas/sas_expander.c:484: static int smp_phy_control(struct domain_device *dev, int phy_id, enum phy_func phy_func) > The mpt fusion f/w supports smp passthru, and we could for > these attributes do SMP passthru if we wanted to return > this data for expanders. > Our f/w only provides a easy special > wrapper config page for hba phys. And this is correct in in line with SDI/SAS. This method can be used by drivers/scsi/sdi.c. And it fits both yours and our simplementation. Dispatching to your implementation would go to FW, whose interface you'll have to implement. Remember you have 2 tasks: drivers/scsi/sdi.c and the FW dependent way of dispatching this to the FW for LSI. As to ours, it would go to /* Phy management */ int (*lldd_control_phy)(struct sas_phy *, enum phy_func); function stub in the of the sas_ha_struct structure as I showed yesterday in this thread. > For expanders, we > are going to have to do smp passthru. Makes sense. > So Christoph what should we do in driver? Ignore returning > data for expanders? > > Luben suggestion(correct me if I'm wrong) is this should be > done thru user space, instead of exporting this in the > /sys/class/sas_phy attributes. Thus we need to export a > SMP_PASSTHRU mechanism. I believe there is discussion > by Christoph ( and I believe Luben backs this idea) of doing > all this thru the /dev/sg interface. sg would be a good choice if the ioctl headers can be "translated" easily into sg headers -- this would make the whole task so much easier and straightforward. Luben -- http://linux.adaptec.com/sas/ http://www.adaptec.com/sas/ - : 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
