* [PATCH] ACPI / IPMI: change warning to debug on timeout @ 2017-03-23 15:32 ` Sinan Kaya 0 siblings, 0 replies; 14+ messages in thread From: Sinan Kaya @ 2017-03-23 15:32 UTC (permalink / raw) To: linux-acpi, timur Cc: linux-arm-msm, linux-arm-kernel, Sinan Kaya, Rafael J. Wysocki, Len Brown, linux-kernel 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 ^ permalink raw reply related [flat|nested] 14+ messages in thread
* [PATCH] ACPI / IPMI: change warning to debug on timeout @ 2017-03-23 15:32 ` Sinan Kaya 0 siblings, 0 replies; 14+ messages in thread From: Sinan Kaya @ 2017-03-23 15:32 UTC (permalink / raw) To: linux-arm-kernel 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 ^ permalink raw reply related [flat|nested] 14+ messages in thread
* Re: [PATCH] ACPI / IPMI: change warning to debug on timeout 2017-03-23 15:32 ` Sinan Kaya @ 2017-03-25 2:55 ` Corey Minyard -1 siblings, 0 replies; 14+ messages in thread From: Corey Minyard @ 2017-03-25 2:55 UTC (permalink / raw) To: Sinan Kaya, linux-acpi, timur Cc: linux-arm-msm, linux-arm-kernel, Rafael J. Wysocki, Len Brown, linux-kernel 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; ^ permalink raw reply [flat|nested] 14+ messages in thread
* [PATCH] ACPI / IPMI: change warning to debug on timeout @ 2017-03-25 2:55 ` Corey Minyard 0 siblings, 0 replies; 14+ messages in thread From: Corey Minyard @ 2017-03-25 2:55 UTC (permalink / raw) To: linux-arm-kernel 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; ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH] ACPI / IPMI: change warning to debug on timeout 2017-03-25 2:55 ` Corey Minyard @ 2017-03-25 14:08 ` Sinan Kaya -1 siblings, 0 replies; 14+ messages in thread From: Sinan Kaya @ 2017-03-25 14:08 UTC (permalink / raw) To: minyard, linux-acpi, timur Cc: linux-arm-msm, linux-arm-kernel, Rafael J. Wysocki, Len Brown, linux-kernel 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. ^ permalink raw reply [flat|nested] 14+ messages in thread
* [PATCH] ACPI / IPMI: change warning to debug on timeout @ 2017-03-25 14:08 ` Sinan Kaya 0 siblings, 0 replies; 14+ messages in thread From: Sinan Kaya @ 2017-03-25 14:08 UTC (permalink / raw) To: linux-arm-kernel 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. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH] ACPI / IPMI: change warning to debug on timeout 2017-03-25 14:08 ` Sinan Kaya @ 2017-03-28 20:01 ` Corey Minyard -1 siblings, 0 replies; 14+ messages in thread From: Corey Minyard @ 2017-03-28 20:01 UTC (permalink / raw) To: Sinan Kaya, linux-acpi, timur Cc: linux-arm-msm, linux-arm-kernel, Rafael J. Wysocki, Len Brown, linux-kernel, Zheng, Lv 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; >> >> > ^ permalink raw reply [flat|nested] 14+ messages in thread
* [PATCH] ACPI / IPMI: change warning to debug on timeout @ 2017-03-28 20:01 ` Corey Minyard 0 siblings, 0 replies; 14+ messages in thread From: Corey Minyard @ 2017-03-28 20:01 UTC (permalink / raw) To: linux-arm-kernel 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; >> >> > ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH] ACPI / IPMI: change warning to debug on timeout 2017-03-28 20:01 ` Corey Minyard (?) @ 2017-03-28 22:06 ` Rafael J. Wysocki -1 siblings, 0 replies; 14+ messages in thread From: Rafael J. Wysocki @ 2017-03-28 22:06 UTC (permalink / raw) To: Corey Minyard Cc: Sinan Kaya, ACPI Devel Maling List, Timur Tabi, linux-arm-msm, linux-arm-kernel, Rafael J. Wysocki, Len Brown, Linux Kernel Mailing List, Zheng, Lv 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* [PATCH] ACPI / IPMI: change warning to debug on timeout @ 2017-03-28 22:06 ` Rafael J. Wysocki 0 siblings, 0 replies; 14+ messages in thread From: Rafael J. Wysocki @ 2017-03-28 22:06 UTC (permalink / raw) To: linux-arm-kernel 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH] ACPI / IPMI: change warning to debug on timeout @ 2017-03-28 22:06 ` Rafael J. Wysocki 0 siblings, 0 replies; 14+ messages in thread From: Rafael J. Wysocki @ 2017-03-28 22:06 UTC (permalink / raw) To: Corey Minyard Cc: Sinan Kaya, ACPI Devel Maling List, Timur Tabi, linux-arm-msm, linux-arm-kernel, Rafael J. Wysocki, Len Brown, Linux Kernel Mailing List, Zheng, Lv 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH] ACPI / IPMI: change warning to debug on timeout 2017-03-28 22:06 ` Rafael J. Wysocki (?) @ 2017-03-28 22:45 ` Corey Minyard -1 siblings, 0 replies; 14+ messages in thread From: Corey Minyard @ 2017-03-28 22:45 UTC (permalink / raw) To: Rafael J. Wysocki Cc: Sinan Kaya, ACPI Devel Maling List, Timur Tabi, linux-arm-msm, linux-arm-kernel, Rafael J. Wysocki, Len Brown, Linux Kernel Mailing List, Zheng, Lv 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* [PATCH] ACPI / IPMI: change warning to debug on timeout @ 2017-03-28 22:45 ` Corey Minyard 0 siblings, 0 replies; 14+ messages in thread From: Corey Minyard @ 2017-03-28 22:45 UTC (permalink / raw) To: linux-arm-kernel 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH] ACPI / IPMI: change warning to debug on timeout @ 2017-03-28 22:45 ` Corey Minyard 0 siblings, 0 replies; 14+ messages in thread From: Corey Minyard @ 2017-03-28 22:45 UTC (permalink / raw) To: Rafael J. Wysocki Cc: Sinan Kaya, ACPI Devel Maling List, Timur Tabi, linux-arm-msm, linux-arm-kernel, Rafael J. Wysocki, Len Brown, Linux Kernel Mailing List, Zheng, Lv 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
end of thread, other threads:[~2017-03-28 22:45 UTC | newest] Thread overview: 14+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2017-03-23 15:32 [PATCH] ACPI / IPMI: change warning to debug on timeout Sinan Kaya 2017-03-23 15:32 ` Sinan Kaya 2017-03-25 2:55 ` Corey Minyard 2017-03-25 2:55 ` Corey Minyard 2017-03-25 14:08 ` Sinan Kaya 2017-03-25 14:08 ` Sinan Kaya 2017-03-28 20:01 ` Corey Minyard 2017-03-28 20:01 ` Corey Minyard 2017-03-28 22:06 ` Rafael J. Wysocki 2017-03-28 22:06 ` Rafael J. Wysocki 2017-03-28 22:06 ` Rafael J. Wysocki 2017-03-28 22:45 ` Corey Minyard 2017-03-28 22:45 ` Corey Minyard 2017-03-28 22:45 ` Corey Minyard
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.