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

[Luben Tuikov <luben_tuikov@adaptec.com>]

On 10/20/05 10:11, Christoph Hellwig wrote:
> On Wed, Oct 19, 2005 at 05:00:03PM -0400, Luben Tuikov wrote:
> 
>>On 10/19/05 16:08, Moore, Eric Dean wrote:
>>
>>>Luben:  He is adding support for linkerrors and link/phy reset;
>>>these for for CSMI/SDI API.
>>>
>>>Can you in your driver retreive link errors for the links on the expanders?
>>
>>Yes. (offloaded to user space)
>>
>>You use the user space program called "expander_conf.c" to
>>send SMP requests and receive SMP responses.
> 
> 
> Yes, exactly.  On the other hand we don't have standard
> hardware-indepent ways of doing that for the PHYs of the HBA because
> the programming interfaces are to different and need to abstract it away
> in the kernel.

The _protocol_ way is SMP.  And LSI does implement SMP passthrough.

You have two scenarios: local phys and SMP.

Note that your task as wanted by HP/LSI/etc (all who use Fusion MPT)
is to implement SDI/CSMI, see http://www.t10.org/drafts.htm#sdi- .

If you implement this, as say, drivers/scsi/sdi.c, then I'd
be more than happy to register with it so as to export
SDI/CSMI functionality.

E.g. if you look at SDI_GET_PHY_INFO you will notice
that this is only for phys of the Host Adapter, NOT all
phys on the domain (which is a _crazy_ concept).

Most of the code has been written right in the SDI spec
sdi-r00.pdf.  You can start from there.  And most of the concepts
have been implemented in say LSI's FW and in my code, the SAS
Transport Layer.

E.g. you can see how "port identifier is u8" which is exactly
what, I'm sure, LSI's fw uses (or can fit in), and as you can see
in my code that I use (I actually use "int").

Now, _registration_ of SDI by different entities would be common,
say, sdi_register_provider(struct ...); Also the _mechanism_
to access that facility would be common*.  But _dispatching_
would be implementation dependent as you can see LSI would
do it differently and Adaptec would do it differently and
XYZ would do it differently, etc.

* I say common because you can use sg, in which case the
IOCTLs described in the spec are directly translated into
"headers" to be issued down sg.

Your task is clearly defined by a spec (sdi-r00.pdf).
Most of the functions defined therein are direct SAS concepts
and, as you can see, translate to an SMP function, or to a TMF,
since this is where they were taken from to begin with.

There is no need for translation layers upon translation
layers.  The task is clearly defined: LSI wants SDI/CSMI.
You have a CSMI spec.  Implement it.  This would make
everyone's job so much easier without destroying already
existing _good_ code.

>  That's why I need the local_attached flag as an internal
> helper - it's not actually exposed to userland so the implementation

1) LSI does have SMP pass through.
2) You absolutely do not need to represent all phys on the domain,
which is, as I said, a completely _crazy_ idea.  Look, even SDI doesn't
want you to do that.  What SDI wants you to do is issue SMP out.
LSI does have SMP pass through in FW so use that.
3) All you care about is SDI, and SDI has a _spec_.  Your job is
twofold:
	- implement drivers/scsi/sdi.c so we can all use it,
	- implement the implementation/hw dependent way to
	access SDI functionality for Fusion as described above
	where I mention that this would be implementation dependent
	(dispatching to).

	Luben
-- 
http://linux.adaptec.com/sas/
http://www.adaptec.com/sas/