[PATCH] ACPI / IPMI: change warning to debug on timeout

[PATCH] ACPI / IPMI: change warning to debug on timeout

[Sinan Kaya]

Getting timeout message from BMC when trying to read from a non-existent
FRU. This is expected but warning is not.

Let's reduce the warning to debug.

Signed-off-by: Sinan Kaya <okaya@codeaurora.org>
---
 drivers/acpi/acpi_ipmi.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/acpi/acpi_ipmi.c b/drivers/acpi/acpi_ipmi.c
index 747c2ba..1b64419 100644
--- a/drivers/acpi/acpi_ipmi.c
+++ b/drivers/acpi/acpi_ipmi.c
@@ -429,8 +429,7 @@ static void ipmi_msg_handler(struct ipmi_recv_msg *msg, void *user_msg_data)
 	if (msg->recv_type == IPMI_RESPONSE_RECV_TYPE &&
 	    msg->msg.data_len == 1) {
 		if (msg->msg.data[0] == IPMI_TIMEOUT_COMPLETION_CODE) {
-			dev_WARN_ONCE(dev, true,
-				      "Unexpected response (timeout).\n");
+			dev_dbg_once(dev, "Unexpected response (timeout).\n");
 			tx_msg->msg_done = ACPI_IPMI_TIMEOUT;
 		}
 		goto out_comp;
-- 
1.9.1

[PATCH] ACPI / IPMI: change warning to debug on timeout

[Sinan Kaya]

Getting timeout message from BMC when trying to read from a non-existent
FRU. This is expected but warning is not.

Let's reduce the warning to debug.

Signed-off-by: Sinan Kaya <okaya@codeaurora.org>
---
 drivers/acpi/acpi_ipmi.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/acpi/acpi_ipmi.c b/drivers/acpi/acpi_ipmi.c
index 747c2ba..1b64419 100644
--- a/drivers/acpi/acpi_ipmi.c
+++ b/drivers/acpi/acpi_ipmi.c
@@ -429,8 +429,7 @@ static void ipmi_msg_handler(struct ipmi_recv_msg *msg, void *user_msg_data)
 	if (msg->recv_type == IPMI_RESPONSE_RECV_TYPE &&
 	    msg->msg.data_len == 1) {
 		if (msg->msg.data[0] == IPMI_TIMEOUT_COMPLETION_CODE) {
-			dev_WARN_ONCE(dev, true,
-				      "Unexpected response (timeout).\n");
+			dev_dbg_once(dev, "Unexpected response (timeout).\n");
 			tx_msg->msg_done = ACPI_IPMI_TIMEOUT;
 		}
 		goto out_comp;
-- 
1.9.1

Re: [PATCH] ACPI / IPMI: change warning to debug on timeout

[Corey Minyard]

Why would a timeout for a message be expected?  The BMC should
at least respond with an error for an incorrect message.

-corey

On 03/23/2017 10:32 AM, Sinan Kaya wrote:
> Getting timeout message from BMC when trying to read from a non-existent
> FRU. This is expected but warning is not.
>
> Let's reduce the warning to debug.
>
> Signed-off-by: Sinan Kaya <okaya@codeaurora.org>
> ---
>   drivers/acpi/acpi_ipmi.c | 3 +--
>   1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/drivers/acpi/acpi_ipmi.c b/drivers/acpi/acpi_ipmi.c
> index 747c2ba..1b64419 100644
> --- a/drivers/acpi/acpi_ipmi.c
> +++ b/drivers/acpi/acpi_ipmi.c
> @@ -429,8 +429,7 @@ static void ipmi_msg_handler(struct ipmi_recv_msg *msg, void *user_msg_data)
>   	if (msg->recv_type == IPMI_RESPONSE_RECV_TYPE &&
>   	    msg->msg.data_len == 1) {
>   		if (msg->msg.data[0] == IPMI_TIMEOUT_COMPLETION_CODE) {
> -			dev_WARN_ONCE(dev, true,
> -				      "Unexpected response (timeout).\n");
> +			dev_dbg_once(dev, "Unexpected response (timeout).\n");
>   			tx_msg->msg_done = ACPI_IPMI_TIMEOUT;
>   		}
>   		goto out_comp;

[PATCH] ACPI / IPMI: change warning to debug on timeout

[Corey Minyard]

Why would a timeout for a message be expected?  The BMC should
at least respond with an error for an incorrect message.

-corey

On 03/23/2017 10:32 AM, Sinan Kaya wrote:
> Getting timeout message from BMC when trying to read from a non-existent
> FRU. This is expected but warning is not.
>
> Let's reduce the warning to debug.
>
> Signed-off-by: Sinan Kaya <okaya@codeaurora.org>
> ---
>   drivers/acpi/acpi_ipmi.c | 3 +--
>   1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/drivers/acpi/acpi_ipmi.c b/drivers/acpi/acpi_ipmi.c
> index 747c2ba..1b64419 100644
> --- a/drivers/acpi/acpi_ipmi.c
> +++ b/drivers/acpi/acpi_ipmi.c
> @@ -429,8 +429,7 @@ static void ipmi_msg_handler(struct ipmi_recv_msg *msg, void *user_msg_data)
>   	if (msg->recv_type == IPMI_RESPONSE_RECV_TYPE &&
>   	    msg->msg.data_len == 1) {
>   		if (msg->msg.data[0] == IPMI_TIMEOUT_COMPLETION_CODE) {
> -			dev_WARN_ONCE(dev, true,
> -				      "Unexpected response (timeout).\n");
> +			dev_dbg_once(dev, "Unexpected response (timeout).\n");
>   			tx_msg->msg_done = ACPI_IPMI_TIMEOUT;
>   		}
>   		goto out_comp;

Re: [PATCH] ACPI / IPMI: change warning to debug on timeout

[Sinan Kaya]

On 3/24/2017 10:55 PM, Corey Minyard wrote:
> Why would a timeout for a message be expected?  The BMC should
> at least respond with an error for an incorrect message.

Let me add some more context...

In this particular case, the FRU ID that I was trying to access was
correct. 

Platform supports PCIe hotplug. The FRU is embedded into the HW that
is being removed. That's what I mean by non-existent.

When the device is ejected and a FRU command is executed, BMC times out
reaching to the FRU on the device. 

When the device is inserted, everything works as expected.

> 
> -corey
> 
> On 03/23/2017 10:32 AM, Sinan Kaya wrote:
>> Getting timeout message from BMC when trying to read from a non-existent
>> FRU. This is expected but warning is not.
>>
>> Let's reduce the warning to debug.
>>
>> Signed-off-by: Sinan Kaya <okaya@codeaurora.org>
>> ---
>>   drivers/acpi/acpi_ipmi.c | 3 +--
>>   1 file changed, 1 insertion(+), 2 deletions(-)
>>
>> diff --git a/drivers/acpi/acpi_ipmi.c b/drivers/acpi/acpi_ipmi.c
>> index 747c2ba..1b64419 100644
>> --- a/drivers/acpi/acpi_ipmi.c
>> +++ b/drivers/acpi/acpi_ipmi.c
>> @@ -429,8 +429,7 @@ static void ipmi_msg_handler(struct ipmi_recv_msg *msg, void *user_msg_data)
>>       if (msg->recv_type == IPMI_RESPONSE_RECV_TYPE &&
>>           msg->msg.data_len == 1) {
>>           if (msg->msg.data[0] == IPMI_TIMEOUT_COMPLETION_CODE) {
>> -            dev_WARN_ONCE(dev, true,
>> -                      "Unexpected response (timeout).\n");
>> +            dev_dbg_once(dev, "Unexpected response (timeout).\n");
>>               tx_msg->msg_done = ACPI_IPMI_TIMEOUT;
>>           }
>>           goto out_comp;
> 
> 
> 


-- 
Sinan Kaya
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.

[PATCH] ACPI / IPMI: change warning to debug on timeout

[Sinan Kaya]

On 3/24/2017 10:55 PM, Corey Minyard wrote:
> Why would a timeout for a message be expected?  The BMC should
> at least respond with an error for an incorrect message.

Let me add some more context...

In this particular case, the FRU ID that I was trying to access was
correct. 

Platform supports PCIe hotplug. The FRU is embedded into the HW that
is being removed. That's what I mean by non-existent.

When the device is ejected and a FRU command is executed, BMC times out
reaching to the FRU on the device. 

When the device is inserted, everything works as expected.

> 
> -corey
> 
> On 03/23/2017 10:32 AM, Sinan Kaya wrote:
>> Getting timeout message from BMC when trying to read from a non-existent
>> FRU. This is expected but warning is not.
>>
>> Let's reduce the warning to debug.
>>
>> Signed-off-by: Sinan Kaya <okaya@codeaurora.org>
>> ---
>>   drivers/acpi/acpi_ipmi.c | 3 +--
>>   1 file changed, 1 insertion(+), 2 deletions(-)
>>
>> diff --git a/drivers/acpi/acpi_ipmi.c b/drivers/acpi/acpi_ipmi.c
>> index 747c2ba..1b64419 100644
>> --- a/drivers/acpi/acpi_ipmi.c
>> +++ b/drivers/acpi/acpi_ipmi.c
>> @@ -429,8 +429,7 @@ static void ipmi_msg_handler(struct ipmi_recv_msg *msg, void *user_msg_data)
>>       if (msg->recv_type == IPMI_RESPONSE_RECV_TYPE &&
>>           msg->msg.data_len == 1) {
>>           if (msg->msg.data[0] == IPMI_TIMEOUT_COMPLETION_CODE) {
>> -            dev_WARN_ONCE(dev, true,
>> -                      "Unexpected response (timeout).\n");
>> +            dev_dbg_once(dev, "Unexpected response (timeout).\n");
>>               tx_msg->msg_done = ACPI_IPMI_TIMEOUT;
>>           }
>>           goto out_comp;
> 
> 
> 


-- 
Sinan Kaya
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.

Re: [PATCH] ACPI / IPMI: change warning to debug on timeout

[Corey Minyard]

On 03/25/2017 09:08 AM, Sinan Kaya wrote:
> On 3/24/2017 10:55 PM, Corey Minyard wrote:
>> Why would a timeout for a message be expected?  The BMC should
>> at least respond with an error for an incorrect message.
> Let me add some more context...
>
> In this particular case, the FRU ID that I was trying to access was
> correct.
>
> Platform supports PCIe hotplug. The FRU is embedded into the HW that
> is being removed. That's what I mean by non-existent.
>
> When the device is ejected and a FRU command is executed, BMC times out
> reaching to the FRU on the device.
>
> When the device is inserted, everything works as expected.

I haven't added this yet.  Someone who knows more about the ACPI side of 
IPMI
should probably comment.  So I've added Lv Zheng.

This is ok with me, though.  If you remove a management controller, a 
timeout is
expected.  However, if the management controller is still present, a 
timeout is
probably not the best error code, "destination unavailable" is probably 
a better
choice.

So:

Acked-by: Corey Minyard <cminyard@mvista.com>

-corey

>
>> -corey
>>
>> On 03/23/2017 10:32 AM, Sinan Kaya wrote:
>>> Getting timeout message from BMC when trying to read from a non-existent
>>> FRU. This is expected but warning is not.
>>>
>>> Let's reduce the warning to debug.
>>>
>>> Signed-off-by: Sinan Kaya <okaya@codeaurora.org>
>>> ---
>>>    drivers/acpi/acpi_ipmi.c | 3 +--
>>>    1 file changed, 1 insertion(+), 2 deletions(-)
>>>
>>> diff --git a/drivers/acpi/acpi_ipmi.c b/drivers/acpi/acpi_ipmi.c
>>> index 747c2ba..1b64419 100644
>>> --- a/drivers/acpi/acpi_ipmi.c
>>> +++ b/drivers/acpi/acpi_ipmi.c
>>> @@ -429,8 +429,7 @@ static void ipmi_msg_handler(struct ipmi_recv_msg *msg, void *user_msg_data)
>>>        if (msg->recv_type == IPMI_RESPONSE_RECV_TYPE &&
>>>            msg->msg.data_len == 1) {
>>>            if (msg->msg.data[0] == IPMI_TIMEOUT_COMPLETION_CODE) {
>>> -            dev_WARN_ONCE(dev, true,
>>> -                      "Unexpected response (timeout).\n");
>>> +            dev_dbg_once(dev, "Unexpected response (timeout).\n");
>>>                tx_msg->msg_done = ACPI_IPMI_TIMEOUT;
>>>            }
>>>            goto out_comp;
>>
>>
>

[PATCH] ACPI / IPMI: change warning to debug on timeout

[Corey Minyard]

On 03/25/2017 09:08 AM, Sinan Kaya wrote:
> On 3/24/2017 10:55 PM, Corey Minyard wrote:
>> Why would a timeout for a message be expected?  The BMC should
>> at least respond with an error for an incorrect message.
> Let me add some more context...
>
> In this particular case, the FRU ID that I was trying to access was
> correct.
>
> Platform supports PCIe hotplug. The FRU is embedded into the HW that
> is being removed. That's what I mean by non-existent.
>
> When the device is ejected and a FRU command is executed, BMC times out
> reaching to the FRU on the device.
>
> When the device is inserted, everything works as expected.

I haven't added this yet.  Someone who knows more about the ACPI side of 
IPMI
should probably comment.  So I've added Lv Zheng.

This is ok with me, though.  If you remove a management controller, a 
timeout is
expected.  However, if the management controller is still present, a 
timeout is
probably not the best error code, "destination unavailable" is probably 
a better
choice.

So:

Acked-by: Corey Minyard <cminyard@mvista.com>

-corey

>
>> -corey
>>
>> On 03/23/2017 10:32 AM, Sinan Kaya wrote:
>>> Getting timeout message from BMC when trying to read from a non-existent
>>> FRU. This is expected but warning is not.
>>>
>>> Let's reduce the warning to debug.
>>>
>>> Signed-off-by: Sinan Kaya <okaya@codeaurora.org>
>>> ---
>>>    drivers/acpi/acpi_ipmi.c | 3 +--
>>>    1 file changed, 1 insertion(+), 2 deletions(-)
>>>
>>> diff --git a/drivers/acpi/acpi_ipmi.c b/drivers/acpi/acpi_ipmi.c
>>> index 747c2ba..1b64419 100644
>>> --- a/drivers/acpi/acpi_ipmi.c
>>> +++ b/drivers/acpi/acpi_ipmi.c
>>> @@ -429,8 +429,7 @@ static void ipmi_msg_handler(struct ipmi_recv_msg *msg, void *user_msg_data)
>>>        if (msg->recv_type == IPMI_RESPONSE_RECV_TYPE &&
>>>            msg->msg.data_len == 1) {
>>>            if (msg->msg.data[0] == IPMI_TIMEOUT_COMPLETION_CODE) {
>>> -            dev_WARN_ONCE(dev, true,
>>> -                      "Unexpected response (timeout).\n");
>>> +            dev_dbg_once(dev, "Unexpected response (timeout).\n");
>>>                tx_msg->msg_done = ACPI_IPMI_TIMEOUT;
>>>            }
>>>            goto out_comp;
>>
>>
>

Re: [PATCH] ACPI / IPMI: change warning to debug on timeout

[Rafael J. Wysocki]

On Tue, Mar 28, 2017 at 10:01 PM, Corey Minyard <minyard@acm.org> wrote:
> On 03/25/2017 09:08 AM, Sinan Kaya wrote:
>>
>> On 3/24/2017 10:55 PM, Corey Minyard wrote:
>>>
>>> Why would a timeout for a message be expected?  The BMC should
>>> at least respond with an error for an incorrect message.
>>
>> Let me add some more context...
>>
>> In this particular case, the FRU ID that I was trying to access was
>> correct.
>>
>> Platform supports PCIe hotplug. The FRU is embedded into the HW that
>> is being removed. That's what I mean by non-existent.
>>
>> When the device is ejected and a FRU command is executed, BMC times out
>> reaching to the FRU on the device.
>>
>> When the device is inserted, everything works as expected.
>
>
> I haven't added this yet.  Someone who knows more about the ACPI side of
> IPMI
> should probably comment.  So I've added Lv Zheng.
>
> This is ok with me, though.  If you remove a management controller, a
> timeout is
> expected.  However, if the management controller is still present, a timeout
> is
> probably not the best error code, "destination unavailable" is probably a
> better
> choice.
>
> So:
>
> Acked-by: Corey Minyard <cminyard@mvista.com>
>
> -corey

FWIW, this change is fine by me, so please feel free to route this
through the IPMI tree along with the other patch from Sinan.

Thanks,
Rafael

Re: [PATCH] ACPI / IPMI: change warning to debug on timeout

[Rafael J. Wysocki]

On Tue, Mar 28, 2017 at 10:01 PM, Corey Minyard <minyard@acm.org> wrote:
> On 03/25/2017 09:08 AM, Sinan Kaya wrote:
>>
>> On 3/24/2017 10:55 PM, Corey Minyard wrote:
>>>
>>> Why would a timeout for a message be expected?  The BMC should
>>> at least respond with an error for an incorrect message.
>>
>> Let me add some more context...
>>
>> In this particular case, the FRU ID that I was trying to access was
>> correct.
>>
>> Platform supports PCIe hotplug. The FRU is embedded into the HW that
>> is being removed. That's what I mean by non-existent.
>>
>> When the device is ejected and a FRU command is executed, BMC times out
>> reaching to the FRU on the device.
>>
>> When the device is inserted, everything works as expected.
>
>
> I haven't added this yet.  Someone who knows more about the ACPI side of
> IPMI
> should probably comment.  So I've added Lv Zheng.
>
> This is ok with me, though.  If you remove a management controller, a
> timeout is
> expected.  However, if the management controller is still present, a timeout
> is
> probably not the best error code, "destination unavailable" is probably a
> better
> choice.
>
> So:
>
> Acked-by: Corey Minyard <cminyard@mvista.com>
>
> -corey

FWIW, this change is fine by me, so please feel free to route this
through the IPMI tree along with the other patch from Sinan.

Thanks,
Rafael

[PATCH] ACPI / IPMI: change warning to debug on timeout

[Rafael J. Wysocki]

On Tue, Mar 28, 2017 at 10:01 PM, Corey Minyard <minyard@acm.org> wrote:
> On 03/25/2017 09:08 AM, Sinan Kaya wrote:
>>
>> On 3/24/2017 10:55 PM, Corey Minyard wrote:
>>>
>>> Why would a timeout for a message be expected?  The BMC should
>>> at least respond with an error for an incorrect message.
>>
>> Let me add some more context...
>>
>> In this particular case, the FRU ID that I was trying to access was
>> correct.
>>
>> Platform supports PCIe hotplug. The FRU is embedded into the HW that
>> is being removed. That's what I mean by non-existent.
>>
>> When the device is ejected and a FRU command is executed, BMC times out
>> reaching to the FRU on the device.
>>
>> When the device is inserted, everything works as expected.
>
>
> I haven't added this yet.  Someone who knows more about the ACPI side of
> IPMI
> should probably comment.  So I've added Lv Zheng.
>
> This is ok with me, though.  If you remove a management controller, a
> timeout is
> expected.  However, if the management controller is still present, a timeout
> is
> probably not the best error code, "destination unavailable" is probably a
> better
> choice.
>
> So:
>
> Acked-by: Corey Minyard <cminyard@mvista.com>
>
> -corey

FWIW, this change is fine by me, so please feel free to route this
through the IPMI tree along with the other patch from Sinan.

Thanks,
Rafael

Re: [PATCH] ACPI / IPMI: change warning to debug on timeout

[Corey Minyard]

On 03/28/2017 05:06 PM, Rafael J. Wysocki wrote:
> On Tue, Mar 28, 2017 at 10:01 PM, Corey Minyard <minyard@acm.org> wrote:
>> On 03/25/2017 09:08 AM, Sinan Kaya wrote:
>>> On 3/24/2017 10:55 PM, Corey Minyard wrote:
>>>> Why would a timeout for a message be expected?  The BMC should
>>>> at least respond with an error for an incorrect message.
>>> Let me add some more context...
>>>
>>> In this particular case, the FRU ID that I was trying to access was
>>> correct.
>>>
>>> Platform supports PCIe hotplug. The FRU is embedded into the HW that
>>> is being removed. That's what I mean by non-existent.
>>>
>>> When the device is ejected and a FRU command is executed, BMC times out
>>> reaching to the FRU on the device.
>>>
>>> When the device is inserted, everything works as expected.
>>
>> I haven't added this yet.  Someone who knows more about the ACPI side of
>> IPMI
>> should probably comment.  So I've added Lv Zheng.
>>
>> This is ok with me, though.  If you remove a management controller, a
>> timeout is
>> expected.  However, if the management controller is still present, a timeout
>> is
>> probably not the best error code, "destination unavailable" is probably a
>> better
>> choice.
>>
>> So:
>>
>> Acked-by: Corey Minyard <cminyard@mvista.com>
>>
>> -corey
> FWIW, this change is fine by me, so please feel free to route this
> through the IPMI tree along with the other patch from Sinan.

Ok, done, with your ack added.

Thanks,

-corey

> Thanks,
> Rafael

Re: [PATCH] ACPI / IPMI: change warning to debug on timeout

[Corey Minyard]

On 03/28/2017 05:06 PM, Rafael J. Wysocki wrote:
> On Tue, Mar 28, 2017 at 10:01 PM, Corey Minyard <minyard@acm.org> wrote:
>> On 03/25/2017 09:08 AM, Sinan Kaya wrote:
>>> On 3/24/2017 10:55 PM, Corey Minyard wrote:
>>>> Why would a timeout for a message be expected?  The BMC should
>>>> at least respond with an error for an incorrect message.
>>> Let me add some more context...
>>>
>>> In this particular case, the FRU ID that I was trying to access was
>>> correct.
>>>
>>> Platform supports PCIe hotplug. The FRU is embedded into the HW that
>>> is being removed. That's what I mean by non-existent.
>>>
>>> When the device is ejected and a FRU command is executed, BMC times out
>>> reaching to the FRU on the device.
>>>
>>> When the device is inserted, everything works as expected.
>>
>> I haven't added this yet.  Someone who knows more about the ACPI side of
>> IPMI
>> should probably comment.  So I've added Lv Zheng.
>>
>> This is ok with me, though.  If you remove a management controller, a
>> timeout is
>> expected.  However, if the management controller is still present, a timeout
>> is
>> probably not the best error code, "destination unavailable" is probably a
>> better
>> choice.
>>
>> So:
>>
>> Acked-by: Corey Minyard <cminyard@mvista.com>
>>
>> -corey
> FWIW, this change is fine by me, so please feel free to route this
> through the IPMI tree along with the other patch from Sinan.

Ok, done, with your ack added.

Thanks,

-corey

> Thanks,
> Rafael

[PATCH] ACPI / IPMI: change warning to debug on timeout

[Corey Minyard]

On 03/28/2017 05:06 PM, Rafael J. Wysocki wrote:
> On Tue, Mar 28, 2017 at 10:01 PM, Corey Minyard <minyard@acm.org> wrote:
>> On 03/25/2017 09:08 AM, Sinan Kaya wrote:
>>> On 3/24/2017 10:55 PM, Corey Minyard wrote:
>>>> Why would a timeout for a message be expected?  The BMC should
>>>> at least respond with an error for an incorrect message.
>>> Let me add some more context...
>>>
>>> In this particular case, the FRU ID that I was trying to access was
>>> correct.
>>>
>>> Platform supports PCIe hotplug. The FRU is embedded into the HW that
>>> is being removed. That's what I mean by non-existent.
>>>
>>> When the device is ejected and a FRU command is executed, BMC times out
>>> reaching to the FRU on the device.
>>>
>>> When the device is inserted, everything works as expected.
>>
>> I haven't added this yet.  Someone who knows more about the ACPI side of
>> IPMI
>> should probably comment.  So I've added Lv Zheng.
>>
>> This is ok with me, though.  If you remove a management controller, a
>> timeout is
>> expected.  However, if the management controller is still present, a timeout
>> is
>> probably not the best error code, "destination unavailable" is probably a
>> better
>> choice.
>>
>> So:
>>
>> Acked-by: Corey Minyard <cminyard@mvista.com>
>>
>> -corey
> FWIW, this change is fine by me, so please feel free to route this
> through the IPMI tree along with the other patch from Sinan.

Ok, done, with your ack added.

Thanks,

-corey

> Thanks,
> Rafael