Re: [PATCH 1/4] sas: add flag for locally attached PHYs

[Luben Tuikov <luben_tuikov@adaptec.com>]

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/