Questions on proposal 08-015

Day, Brian Brian.Day at lsi.com
Wed Dec 3 13:12:53 PST 2008


* From the T10 Reflector (t10 at t10.org), posted by:
* "Day, Brian" <Brian.Day at lsi.com>
*
Hi Gerry....
Please see below with BD>>
Brian Day
LSI Corp.
-----Original Message-----
From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of
Gerry.Houlder at seagate.com
Sent: Tuesday, December 02, 2008 3:37 PM
To: t10 at t10.org
Subject: Questions on proposal 08-015
* From the T10 Reflector (t10 at t10.org), posted by:
* Gerry.Houlder at seagate.com
*
I have some questions on which I need advice of expander folks.
(1) 08-015r5 currently uses byte 13, bits 5 and 4, of the DISCOVER response
to report the Phy PS Condition field. It has been pointed out that is area of
the DISCOVER response is intended to line up with related fields in the
IDENTIFY address frame and should not be used for things that are not in the
IDENTIFY address frame. However we are adding capability bit(s) (there is an
outstanding question of whether we need one or two bits here) to the IDENTIFY
address frame.
BD>> This area isn't intended to exactly line up byte-for-byte with the
received IDENTIFY frame, so having the current power mode of the phy reported
here similar to the NEGOTIATED LINK RATE seems appropriate.  This also allows
the short format for DISCOVER LIST response to work the same (re question 1c
and 1d below).
(1a) If we add two bits for "capability" in the IDENTIFY address frame,
should those capability bits be reflected in the DISCOVER response?
BD>> The expander capabilities reporting have already been proposed and
discussed some at Nov meeting for proposal 08-420.  A take-away from that
discussion was that Brad will be adding the "attached" version of the
cababilities bits of the received IDENTIFY frame.
(1b) Can we use the related two bit field for reporting Phy PS Condition
instead of the capability bits? Is there a need to report both the capability
bit field(s) in DISCOVER response as well as the actual Phy Condition field?
BD>>  We want capable, enabled, and current state.  Should we just
incorporate the current power condition reporting into 08-420, and remove
|from 08-15?  That might be nice to keep all the SMP changes in one proposal.
(1c) Presuming I have to move the two bit Phy Condition field elsewhere, is
it important that the field also show up in the short format DISCOVER
response? Most of those fields overlap with the fields intended to overlap
with IDENTIFY address frame usage, so if this is important we may have to
break that overlap rule.
(1d) I am expecting to move the two bit Phy Condition field either to byte
34 bits 7 & 6 or byte 6 bits 7 & 6. Any preference on these?
(2) There is a need to create two bits to enable use of partial and slumber
on expander phys. The most obvious choice is the CONFIGURE GENERAL request.
Would byte 8 of CONFIGURE GENERAL be a good choice?
BD>> 08-420 has already proposed PHY CONTROL... since we need to control each
phy individually.
(3) It has been suggested that the Protocol Specific Port mode page is not
the right choice for controlling the target device. It has been suggested
that the two enable bits for slumber and partial phy power conditions should
be in the Enhanced Phy Control mode page (page 19h, subpage 3). I think the
best place is byte 19 bits 2 & 1. Any disagreement with this?
Please post opinions to me or to the reflector on these options by Dec. 12.
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org



More information about the T10 mailing list