[Skiboot] [RFC PATCH] fsp/ipmi: Add the in-band IPMI support for FSP systems

[Neelesh Gupta]

Hi,

On 07/01/2015 12:43 PM, Alistair Popple wrote:
> Hi,
>
> On Wed, 1 Jul 2015 12:30:19 Neelesh Gupta wrote:
>> Hi Alistair,
>>
>> Thanks for the review.
>>
>> On 07/01/2015 12:02 PM, Alistair Popple wrote:
>>> Hi Neelesh,
>>>
>>> A few comments below. The main question I have is do we even need to
> implement
>>> a queue in this driver, given the FSP already has a message queue?
>> 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.
> 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.

But that's more on the IPMI implementation on the FSP-side, so not sure
about their implementation... FSP is just a pass-through here.

>
>> 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.
> So the FSP driver can't cope with multiple messages of the same type being
> queued?

This part is on the OPAL side, so the fsp driver is able to cope with 
multiple
messages of the same type to the extend of receiving the 'response' from
the FSP for the 'request message', but 'response message' for the request
is still awaited.  Note: for a given request.. first comes the response 
of the
request.. followed by the 'response message' with actual data. The flow is:

1) HV -> FSP (message)
2) FSP -> HV (response of the (1) request)
3) FSP -> HV (message, with IPMI response data)
4) HV -> FSP (response, an ack)

So, if there are multiple ipmi requests, then fsp driver will queue the 
next request
after receiving the response (i.e., step 2) above) .. but the 
transaction is not
complete until step 4) ... and in my understanding fsp mbox will not 
like it if we
send the next request before 4).
Further, the step 3) & 4) is the fsp-ipmi driver scope, so the fsp-ipmi 
should
maintain a queue to handle it.

Regards,
Neelesh.

>
>> Thanks,
>> Neelesh.
>>
>>> Regards,
>>>
>>> Alistair
>>>
>>> On Wed, 24 Jun 2015 22:46:20 Neelesh Gupta wrote:
>>>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ozlabs.org/pipermail/skiboot/attachments/20150701/0e327675/attachment-0001.html>