Yes, I am aware of that as Mark pointed
it out to me last week. He sent me a note with some suggestions on how
it should be handled. I plan on putting a fix into my 06-451 proposal.
"T10 Reflector" <t10@t10.org>,
George Penokie/Rochester/IBM@IBMUS
cc
Subject
SAS-2: Notify Power Loss
Section 7.2.5.10.3 states:
"If a SAS target device supports NOTIFY (POWER LOSS EXPECTED) and
receives NOTIFY (POWER LOSS
EXPECTED) on an SSP target port, then each SAS phy within the target device
shall:
a) if there is an SSP connection, then transmit a BREAK on that connection;
and
b) respond to SSP connection requests with OPEN_REJECT (RETRY) until the
power loss timeout
timer expires or power is lost.
If any frames are received by the SAS target device after receiving NOTIFY
(POWER LOSS EXPECTED)
before a connection is closed, then the SAS target device shall discard
the received frames."
Since it is the CC state machine that transmits BREAK primitives, I looked
to that state machine to see where and how this is accomplished.
There is no inputs to that state machine indicating the reception of a
NOTIFY (POWER LOSS EXPECTED).
That being the case, I thought maybe the SSP state machine had an input
for the NOTIFY (POWER LOSS EXPECTED) and, in turn, would issue a Request
Break to the CC state machine.
SURPRISE! SURPRISE!
The SSP state machine doesn't have such an input either. And there
is no input to the SSP state machine from higher levels that can generate
a BREAK.
SO, how are NOTIFY (POWER LOSS EXPECTED) supposed to be handled?
I think we need state machine changes in the Link Layer to handle the requirements
above, or we need to remove the requirements.