Thread (10 messages) 10 messages, 3 authors, 2016-03-29

Re: [PATCH V2 2/2] pseries/eeh: Handle RTAS delay requests in configure_bridge

From: Russell Currey <hidden>
Date: 2016-03-29 21:58:46

On Tue, 2016-03-29 at 08:51 -0700, Tyrel Datwyler wrote:
On 03/28/2016 07:51 PM, Russell Currey wrote:
quoted
+		/*
+		 * RTAS can return a delay value of up to 10^5
milliseconds
+		 * (RTAS_EXTENDED_DELAY_MAX), which is too long.  Only
respect
+		 * the delay if it's 100ms or less.
+		 */
Your changelog says the delay is capped at 0.2s. However, your comment
in the code mentions the full 10^5ms based on the 9900-9905 codes. It
would probably be best to expand you comment to mention in the code that
you are only handling 9900-9902 to eliminate the confusion of looking at
the above comment vs below implementation.

Further, despite PAPRs software note that the long busy should be
limited to 9900-9902 you might want to add a catch to your switch to log
any unexpected 9903-9905 or just treat them as max 0.2s delay. Firmware
has been know to do things on occasion that the spec says it shouldn't,
and it might not be obvious at first should you receive one of the
longer delay codes why we are going down the error path.

-Tyrel
Good to know, thanks.  I'll respin.

- Russell
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help