diff mbox

[dpdk-dev] fm10K: fix interrupt fault handling

Message ID 1437093202-30265-1-git-send-email-stephen@networkplumber.org (mailing list archive)
State Accepted, archived
Headers

Commit Message

Stephen Hemminger July 17, 2015, 12:33 a.m. UTC 
The fm10k driver was reading the interrupt cause register but then
using the interrupt mask register defines to look at the bits.
The result is that if a fault happens, the driver would never clear
the fault and would get into an infinite cycle of interrupts.

Note: I don't work for Intel or have the hardware manuals (probably
requires NDA anyway), but this looks logical and matches how the
known working Linux driver handles these bits.

Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
---
 drivers/net/fm10k/fm10k_ethdev.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

Comments

Chen, Jing D July 21, 2015, 7:15 a.m. UTC | #1 
Hi, Stephen,

> -----Original Message-----
> From: Stephen Hemminger [mailto:stephen@networkplumber.org]
> Sent: Friday, July 17, 2015 8:33 AM
> To: Qiu, Michael; Chen, Jing D
> Cc: dev@dpdk.org; Stephen Hemminger
> Subject: [PATCH] fm10K: fix interrupt fault handling
> 
> The fm10k driver was reading the interrupt cause register but then
> using the interrupt mask register defines to look at the bits.
> The result is that if a fault happens, the driver would never clear
> the fault and would get into an infinite cycle of interrupts.
> 
> Note: I don't work for Intel or have the hardware manuals (probably
> requires NDA anyway), but this looks logical and matches how the
> known working Linux driver handles these bits.
> 
> Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>

Good catch! Thanks!

Acked-by: Jing Chen <jing.d.chen@intel.com>
Thomas Monjalon July 22, 2015, 10:46 a.m. UTC | #2 
> > The fm10k driver was reading the interrupt cause register but then
> > using the interrupt mask register defines to look at the bits.
> > The result is that if a fault happens, the driver would never clear
> > the fault and would get into an infinite cycle of interrupts.
> > 
> > Note: I don't work for Intel or have the hardware manuals (probably
> > requires NDA anyway), but this looks logical and matches how the
> > known working Linux driver handles these bits.
> > 
> > Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
> 
> Good catch! Thanks!
> 
> Acked-by: Jing Chen <jing.d.chen@intel.com>

Applied, thanks
diff mbox

Patch

diff --git a/drivers/net/fm10k/fm10k_ethdev.c b/drivers/net/fm10k/fm10k_ethdev.c
index 493b6f9..665d852 100644
--- a/drivers/net/fm10k/fm10k_ethdev.c
+++ b/drivers/net/fm10k/fm10k_ethdev.c
@@ -1710,7 +1710,7 @@  fm10k_dev_handle_fault(struct fm10k_hw *hw, uint32_t eicr)
 	const char *estr = "Unknown error";
 
 	/* Process PCA fault */
-	if (eicr & FM10K_EIMR_PCA_FAULT) {
+	if (eicr & FM10K_EICR_PCA_FAULT) {
 		err = fm10k_get_fault(hw, FM10K_PCA_FAULT, &fault);
 		if (err)
 			goto error;
@@ -1738,7 +1738,7 @@  fm10k_dev_handle_fault(struct fm10k_hw *hw, uint32_t eicr)
 	}
 
 	/* Process THI fault */
-	if (eicr & FM10K_EIMR_THI_FAULT) {
+	if (eicr & FM10K_EICR_THI_FAULT) {
 		err = fm10k_get_fault(hw, FM10K_THI_FAULT, &fault);
 		if (err)
 			goto error;
@@ -1756,7 +1756,7 @@  fm10k_dev_handle_fault(struct fm10k_hw *hw, uint32_t eicr)
 	}
 
 	/* Process FUM fault */
-	if (eicr & FM10K_EIMR_FUM_FAULT) {
+	if (eicr & FM10K_EICR_FUM_FAULT) {
 		err = fm10k_get_fault(hw, FM10K_FUM_FAULT, &fault);
 		if (err)
 			goto error;