<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<small>Hi,</small><br>
<br>
<div class="moz-cite-prefix">On 07/01/2015 12:43 PM, Alistair Popple
wrote:<br>
</div>
<blockquote cite="mid:2876376.mAQeu0l1nD@mexican" type="cite">
<pre wrap="">Hi,
On Wed, 1 Jul 2015 12:30:19 Neelesh Gupta wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Hi Alistair,
Thanks for the review.
On 07/01/2015 12:02 PM, Alistair Popple wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Hi Neelesh,
A few comments below. The main question I have is do we even need to
</pre>
</blockquote>
</blockquote>
<pre wrap="">implement
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">a queue in this driver, given the FSP already has a message queue?
</pre>
</blockquote>
<pre wrap="">
Yes, FSP queues the messages, but will not be aware of when the response
received (it's asynchronous) so fsp-ipmi driver maintains the queue so that
it queues the next request only after the current completed.
</pre>
</blockquote>
<pre wrap="">
This doesn't matter for the IPMI layer - so long as the messages are sent in
the order they're queued I don't see the issue with having multiple requests
pending in the FSP layer.</pre>
</blockquote>
<br>
<small>But that's more on the IPMI implementation on the FSP-side,
so not sure<br>
about their implementation... FSP is just a pass-through here.<br>
</small><br>
<blockquote cite="mid:2876376.mAQeu0l1nD@mexican" type="cite">
<pre wrap="">
</pre>
<blockquote type="cite">
<pre wrap="">Without the list, we might send multiple IPMI mbox commands for different
requests which FSP hardware doesn't expect.
Going through your other comments, will respond/fix.
</pre>
</blockquote>
<pre wrap="">
So the FSP driver can't cope with multiple messages of the same type being
queued?</pre>
</blockquote>
<br>
<small>This part is on the OPAL side, so the fsp driver is able to
cope with multiple<br>
messages of the same type to the extend of receiving the
'response' from<br>
the FSP for the 'request message', but 'response message' for the
request<br>
is still awaited. Note: for a given request.. first comes the
response of the<br>
request.. followed by the 'response message' with actual data. The
flow is:<br>
<br>
1) HV -> FSP (message)<br>
2) FSP -> HV (response of the (1) request)<br>
3) FSP -> HV (message, with IPMI response data)<br>
4) HV -> FSP (response, an ack)<br>
<br>
So, if there are multiple ipmi requests, then fsp driver will
queue the next request<br>
after receiving the response (i.e., step 2) above) .. but the
transaction is not<br>
complete until step 4) ... and in my understanding fsp mbox will
not like it if we<br>
send the next request before 4).<br>
Further, the step 3) & 4) is the fsp-ipmi driver scope, so the
fsp-ipmi should<br>
maintain a queue to handle it.<br>
<br>
Regards,<br>
Neelesh.<br>
</small><br>
<blockquote cite="mid:2876376.mAQeu0l1nD@mexican" type="cite">
<pre wrap="">
</pre>
<blockquote type="cite">
<pre wrap="">Thanks,
Neelesh.
</pre>
<blockquote type="cite">
<pre wrap="">
Regards,
Alistair
On Wed, 24 Jun 2015 22:46:20 Neelesh Gupta wrote:
</pre>
</blockquote>
<pre wrap="">
</pre>
</blockquote>
<pre wrap="">
</pre>
</blockquote>
<br>
</body>
</html>