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

Alistair Popple alistair at popple.id.au
Wed Jul 1 19:22:00 AEST 2015


Hi,

On Wed, 1 Jul 2015 14:21:58 Neelesh Gupta wrote:
> 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)

OK, I'm not too familiar with FSP so thanks for explaining. It appears the FSP 
layer isn't as smart as I thought it was (I assumed these details may have 
been hidden from clients), in which case you will have to maintain a separate 
queue for the IPMI messages as you have done. I will review your v1 patch 
shortly.

- Alistair

> 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:
> >>>
> 



More information about the Skiboot mailing list