Re: [PATCH] libsas: add SMP READ/WRTIE GPIO support

[James Bottomley <James.Bottomley@HansenPartnership.com>]

On Wed, 2011-08-03 at 15:02 -0500, James Bottomley wrote:
> On Wed, 2011-06-01 at 19:02 +0200, Artur Wojcik wrote:
> > On 06/01/2011 04:32 PM, Douglas Gilbert wrote:
> > > On 11-06-01 10:02 AM, Artur Wojcik wrote:
> > >> This patch enables the SMP READ/WRITE GPIO function interface in 
> > >> libsas SMP
> > >> host module. The interface is used to control the SGPIO initiator in 
> > >> the SAS
> > >> initiator. The implementation is SFF-8485 and SAS-2 compliant.
> > >>
> > >> There are two functions in transport class only responsible for 
> > >> reading and
> > >> writting GPIO registers. I decided to leave the decission about what 
> > >> type of
> > >> registers are supported to lldd.
> > >>
> > >> Now the user space application may issue SMP READ/WRITE GPIO frame to 
> > >> HBA in
> > >> order to read/write GPIO registers.
> > >
> > > Your code also accepts the somewhat mysterious READ GPIO
> > > REGISTER ENHANCED SMP function and its WRITE equivalent.
> > > Reference is made in sas2r16.pdf to SFF-8485 for those
> > > functions. However the most recent version of SFF-8485
> > > on the Seagate site is 0.7 dated February 2006, and it does
> > > not define those ENHANCED functions.
> > >
> > > Could you tell us what those ENHANCED versions do?
> > >
> > > Doug Gilbert
> > I have not found the description of ENHANCED frames in any publicly 
> > available specification related to SGPIO. I took SAS-2 as the major 
> > reference and it says SMP functions 02h (READ) and 82h (WRITE) are 
> > obsolete. My understanding is that for the moment the new functions are 
> > replacing the deprecated functions, but the frame format and registers 
> > set stay the same.
> 
> Then why change the function numbers?  I mean if you're keeping the call
> and return compatible, you can just reuse the now obsoleted functions.
> Usually you only change functions if you have to break compatibility
> somehow (like order or length of parameters).   Since the current
> implementation critically depends on this (because you break out the
> fields from the frame) I'd be very wary of putting this in only to have
> it broken again by a later revision of SFF-8485

OK, I got the answer.  It's buried deeply in the 14h ballot comment
resolutions:

http://www.t10.org/cgi-bin/ac.pl?t=d&f=08-212r8.pdf

SFF-8485 v 0.7 actually has an incorrect format for the frame because it
doesn't take into account the required request length/response length
fields which have to occupy bytes 2 and 3, so they're going to rev
SFF-8485 to conform to the SMP frame requirements.  That means all the
fields will shift and your patch will be wrong. We can guess, based on
this that the register fields will begin at offset 4.
 
James