[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