Re: [Freeipmi-devel] KCS Driver SMS_ATN Register

2010-03-01 Thread Matt Jerdonek
wrote: From: Al Chu ch...@llnl.gov Subject: Re: [Freeipmi-devel] KCS Driver SMS_ATN Register To: Matt Jerdonek maj1...@yahoo.com Cc: Anand Babu Periasamy a...@gnu.org.in, freeipmi-devel@gnu.org Date: Thursday, February 25, 2010, 10:33 AM Hi Matt, I don't see it that way.  I could see someone

Re: [Freeipmi-devel] KCS Driver SMS_ATN Register

2010-03-01 Thread Al Chu
--- On Thu, 2/25/10, Al Chu ch...@llnl.gov wrote: From: Al Chu ch...@llnl.gov Subject: Re: [Freeipmi-devel] KCS Driver SMS_ATN Register To: Matt Jerdonek maj1...@yahoo.com Cc: Anand Babu Periasamy a...@gnu.org.in, freeipmi-devel@gnu.org

Re: [Freeipmi-devel] KCS Driver SMS_ATN Register

2010-02-25 Thread Matt Jerdonek
Sent: Wed, February 24, 2010 12:49:59 PM Subject: Re: [Freeipmi-devel] KCS Driver SMS_ATN Register Hey Matt, I noticed one or two minor nits, but I can fix em. I guess I am only perplexed by this design choice. It seems you want to have two threads. One thread does normal IPMI regularly

Re: [Freeipmi-devel] KCS Driver SMS_ATN Register

2010-02-24 Thread Al Chu
Hey Matt, I noticed one or two minor nits, but I can fix em. I guess I am only perplexed by this design choice. It seems you want to have two threads. One thread does normal IPMI regularly, and the other thread will wait for the SMS_ATN bit. It appears that _ipmi_kcs_get_status() is the only

Re: [Freeipmi-devel] KCS Driver SMS_ATN Register

2010-02-23 Thread Matt Jerdonek
Please give the attached patch a look. Since you two didn't like the idea of a callback, I created an API to wait for an event and a second API to cancel the wait. Basically the application will be responsible for creating a thread which invokes the API. The API will block the

Re: [Freeipmi-devel] KCS Driver SMS_ATN Register

2010-02-22 Thread Al Chu
Hey A.B., On Mon, 2010-02-22 at 01:16 -0800, Anand Babu Periasamy wrote: On Sun, Feb 21, 2010 at 8:38 AM, Al Chu ch...@llnl.gov wrote: Hey A.B, Al, Unfortunately SMS_ATN is KCS specific. So we can't create an abstracted API. There's no reason other drivers won't have interrupt

Re: [Freeipmi-devel] KCS Driver SMS_ATN Register

2010-02-21 Thread Matt Jerdonek
for all your comments, -Matt From: Al Chu ch...@llnl.gov To: Anand Babu Periasamy a...@gnu.org.in Cc: Matt Jerdonek maj1...@yahoo.com; freeipmi-devel@gnu.org Sent: Sun, February 21, 2010 9:38:27 AM Subject: Re: [Freeipmi-devel] KCS Driver SMS_ATN Register Hey

Re: [Freeipmi-devel] KCS Driver SMS_ATN Register

2010-02-18 Thread Anand Babu Periasamy
Matt Jerdonek wrote: Hello, The KCS driver appears to not use the SMS_ATN register. This register is useful for BMC-to-BMC communication to know when the remote BMC has responded. Are there any plans to monitor this register in future releases? If not, are the maintainers open to

Re: [Freeipmi-devel] KCS Driver SMS_ATN Register

2010-02-18 Thread Al Chu
Hi Matt, Definitely open to patches. Looking over the IPMI spec, I agree w/ A.B., it seems to be more useful for a higher level monitoring, w/ the Get Message Flags and similar commands. I can think of several patch ideas: 1) add a KCS driver flag for checking for SMS_ATN in addition to OBF

Re: [Freeipmi-devel] KCS Driver SMS_ATN Register

2010-02-18 Thread Matt Jerdonek
-devel@gnu.org Sent: Thu, February 18, 2010 10:58:06 AM Subject: Re: [Freeipmi-devel] KCS Driver SMS_ATN Register Hi Matt, Definitely open to patches. Looking over the IPMI spec, I agree w/ A.B., it seems to be more useful for a higher level monitoring, w/ the Get Message Flags and similar commands

Re: [Freeipmi-devel] KCS Driver SMS_ATN Register

2010-02-18 Thread Al Chu
: [Freeipmi-devel] KCS Driver SMS_ATN Register Hi Matt, Definitely open to patches. Looking over the IPMI spec, I agree w/ A.B., it seems to be more useful for a higher level monitoring, w/ the Get Message Flags and similar commands. I can think of several patch ideas: 1) add a KCS

[Freeipmi-devel] KCS Driver SMS_ATN Register

2010-02-17 Thread Matt Jerdonek
Hello, The KCS driver appears to not use the SMS_ATN register. This register is useful for BMC-to-BMC communication to know when the remote BMC has responded. Are there any plans to monitor this register in future releases? If not, are the maintainers open to including a patch? Thanks,