Building intel s2600wf image

[Wim Vervoorn]

Hello James,

Thanks for the patch.

This should solve a case where the SMS_ATN is asserted from the start. However I am wondering if this is the full solution for the issue.

The thing is that the SMS_ATN is set by the driver as well. Not only as a spurious occasion. According to the IPMI specification the SMS_ATN should be removed by the BMC once the condition handled. So basically SMS_ATN should cleared when all three event bits in the status are cleared. This can either be done by the Clear Message Flags or when e.g. a message has been read and the message que is empty. These situations are not addressed by this code.

Best regards,

Wim Vervoor



-----Original Message-----
From: James Feist [mailto:james.feist at linux.intel.com] 
Sent: Wednesday, February 20, 2019 8:02 PM
To: Wim Vervoorn <wvervoorn at eltan.com>; openbmc at lists.ozlabs.org
Cc: cheng.c.yang at linux.intel.com
Subject: Re: Building intel s2600wf image

On 2/20/19 5:34 AM, Wim Vervoorn wrote:
> Hello James,
> 
> We got the KCS interface working on the OpenBmc but we are running into an issue we think is a missing part in the OpenBmc implementation at this moment.
> 
> We are using the KCS interface and what we see is that the SMS_ATN is set by OpenBmc. This at itself isn't an issue but it isn't cleared.
> 
> I don't think the issue is in the KCS driver this correctly implements the set and clear SMS_ATN functions.
> 
>  From what I see the current implementation of ipmi-host doesn't issue a clear SMS_ATN call anywhere.
> 
> I guess this code was developed using the BT interface (in this case the host clears the SMS_ATN).
> 
> To solve this the SMS_ATN should be cleared when the message que is empty and when the SetMessageFlags clears all flags.
> 
> Is this code already available and nog yet checked in or should we implement this?

Hi Wim,

I just pushed the patch we are currently using downstream for this issue:

https://gerrit.openbmc-project.xyz/#/c/openbmc/phosphor-host-ipmid/+/18568/

It probably isn't ready to be merged in it's current state, but hopefully you'll find it useful.


Thanks,

James


> 
> Best regards,
> 
> Wim Vervoorn
>