Hi Alistair,
Thanks for the review.
On 07/28/2015 11:21 PM, Alistair Popple wrote:
Hi Neelesh,
This fix looks reasonable to me, although Jeremy would be the best person to
comment if he has time. I wonder why we bother polling at all given that our
event interface should call opal_ipmi_recv()
Hi Neelesh,
This fix looks reasonable to me, although Jeremy would be the best person to
comment if he has time. I wonder why we bother polling at all given that our
event interface should call opal_ipmi_recv() whenever a message is ready?
Also the firmware fix you refer to and this fix are ind
Hi Corey,
On 07/16/2015 08:31 PM, Corey Minyard wrote:
Ok, this looks fine. A couple of question...
Do I need to send this upstream right now? How well has this been tested?
I would want either Jeremy or Alistair to review this patch before you
send this
upstream. There is also firmware pi
Ok, this looks fine. A couple of question...
Do I need to send this upstream right now? How well has this been tested?
Do you want this backported to 4.0 stable?
-corey
On 07/16/2015 06:16 AM, Neelesh Gupta wrote:
> If the OPAL call to receive the ipmi message fails, then we free up the
> smi
If the OPAL call to receive the ipmi message fails, then we free up the
smi message and return. But, the driver still holds the reference to
old smi message in the 'cur_msg' which can potentially be accessed later
and freed again leading to kernel oops. To fix it up,
The kernel driver should reset
