[Skiboot] [PATCH] platform/mihawk: support dynamic PCIe slot table

[Joy_Chu at wistron.com]

Hi Oliver,

Sorry to bother you. For the timeout, do you have any other idea?
We plan to release a pnor with this dynamic pcie slot table feature next Wednesday.
I really hope this feature can be on time.


Best Regards,
Joy Chu

-----Original Message-----
From: Joy Chu/WHQ/Wistron 
Sent: Wednesday, March 25, 2020 5:37 PM
To: 'Oliver O'Halloran' <oohall at gmail.com>
Cc: skiboot list <skiboot at lists.ozlabs.org>; chhank at tw.ibm.com
Subject: RE: [Skiboot] [PATCH] platform/mihawk: support dynamic PCIe slot table

Hi Oliver,

In our case, we want to setup the timeout to prevent from the wait forever. When it hit the timeout, I need to keep the skiboot process going. We will setup a default setting if we can't get the response from BMC in time. At that time, we could free the ipmi msg from the queue (oh, I forget to handle this in my patch). Then, we will use the default setting and continue the mihawk_init process.


Best Regards,
Joy Chu


-----Original Message-----
From: Oliver O'Halloran <oohall at gmail.com>
Sent: Wednesday, March 25, 2020 6:28 AM
To: Joy Chu/WHQ/Wistron <Joy_Chu at wistron.com>
Cc: skiboot list <skiboot at lists.ozlabs.org>; chhank at tw.ibm.com
Subject: Re: [Skiboot] [PATCH] platform/mihawk: support dynamic PCIe slot table

On Thu, Mar 12, 2020 at 8:05 PM Joy Chu/WHQ/Wistron <Joy_Chu at wistron.com> wrote:
>
> Hi Oliver,
>
> As in your previous comment:
> ""Can you use ipmi_queue_msg_sync() instead of the callback and 
> open-coded delay loop? The only problem I can see is that if the BMC 
> doesn't respond we'd hit the timeout in the current code while
> ipmi_queue_msg_sync() will wait forever. We could always add a timeout to the _sync version though.""
>
> I still have no idea about how to add the timeout when using ipmi_queue_msg_sync().
> Would you please give us some hints?

Hi Joy,

Sorry about the delay. I thought I sent a reply the other day, but it looks like it didn't actually send.

Anyway, currently there is no code to implement a synchronous message with a timeout. What I was thinking was that rather than having the platform code implement one by hand we should provide it as a part of the core API. That said, I'm a bit iffy about the concept. If we have a message that times out what should we be doing with the message on the skiboot side? If the BMC doesn't respond we can't just leave the message sitting on the IPMI queue. What is happening on the BMC side that prevents it sending a timely response?

Oliver