Re: [PATCH] mlx4_core: Fix fallback from MSI-X to INTx

2015-05-27 Thread Yishai Hadas

On 5/23/2015 2:12 AM, Benjamin Poirier wrote:

The test in mlx4_load_one() to remove MLX4_FLAG_MSI_X expects mlx4_NOP() to
fail with -EBUSY. It is also necessary to avoid the reset since the device
is not fully reinitialized before calling mlx4_start_hca() a second time.

Note that this will also affect mlx4_test_interrupts(), the only other user
of MLX4_CMD_NOP.

Fixes: f5aef5a ("net/mlx4_core: Activate reset flow upon fatal command cases")
Signed-off-by: Benjamin Poirier 
---
  drivers/net/ethernet/mellanox/mlx4/cmd.c | 9 +++--
  1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/drivers/net/ethernet/mellanox/mlx4/cmd.c 
b/drivers/net/ethernet/mellanox/mlx4/cmd.c
index 4f7dc04..529ef05 100644
--- a/drivers/net/ethernet/mellanox/mlx4/cmd.c
+++ b/drivers/net/ethernet/mellanox/mlx4/cmd.c
@@ -714,8 +714,13 @@ static int mlx4_cmd_wait(struct mlx4_dev *dev, u64 
in_param, u64 *out_param,
 msecs_to_jiffies(timeout))) {
mlx4_warn(dev, "command 0x%x timed out (go bit not cleared)\n",
  op);
-   err = -EIO;
-   goto out_reset;
+   if (op == MLX4_CMD_NOP) {
+   err = -EBUSY;
+   goto out;
+   } else {
+   err = -EIO;
+   goto out_reset;
+   }
}

err = context->result;



It looks fine, a private case that should not trigger the reset flow.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH] mlx4_core: Fix fallback from MSI-X to INTx

2015-05-27 Thread Yishai Hadas

On 5/23/2015 2:12 AM, Benjamin Poirier wrote:

The test in mlx4_load_one() to remove MLX4_FLAG_MSI_X expects mlx4_NOP() to
fail with -EBUSY. It is also necessary to avoid the reset since the device
is not fully reinitialized before calling mlx4_start_hca() a second time.

Note that this will also affect mlx4_test_interrupts(), the only other user
of MLX4_CMD_NOP.

Fixes: f5aef5a (net/mlx4_core: Activate reset flow upon fatal command cases)
Signed-off-by: Benjamin Poirier bpoir...@suse.de
---
  drivers/net/ethernet/mellanox/mlx4/cmd.c | 9 +++--
  1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/drivers/net/ethernet/mellanox/mlx4/cmd.c 
b/drivers/net/ethernet/mellanox/mlx4/cmd.c
index 4f7dc04..529ef05 100644
--- a/drivers/net/ethernet/mellanox/mlx4/cmd.c
+++ b/drivers/net/ethernet/mellanox/mlx4/cmd.c
@@ -714,8 +714,13 @@ static int mlx4_cmd_wait(struct mlx4_dev *dev, u64 
in_param, u64 *out_param,
 msecs_to_jiffies(timeout))) {
mlx4_warn(dev, command 0x%x timed out (go bit not cleared)\n,
  op);
-   err = -EIO;
-   goto out_reset;
+   if (op == MLX4_CMD_NOP) {
+   err = -EBUSY;
+   goto out;
+   } else {
+   err = -EIO;
+   goto out_reset;
+   }
}

err = context-result;



It looks fine, a private case that should not trigger the reset flow.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH] mlx4_core: Fix fallback from MSI-X to INTx

2015-05-22 Thread Benjamin Poirier
The test in mlx4_load_one() to remove MLX4_FLAG_MSI_X expects mlx4_NOP() to
fail with -EBUSY. It is also necessary to avoid the reset since the device
is not fully reinitialized before calling mlx4_start_hca() a second time.

Note that this will also affect mlx4_test_interrupts(), the only other user
of MLX4_CMD_NOP.

Fixes: f5aef5a ("net/mlx4_core: Activate reset flow upon fatal command cases")
Signed-off-by: Benjamin Poirier 
---
 drivers/net/ethernet/mellanox/mlx4/cmd.c | 9 +++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/drivers/net/ethernet/mellanox/mlx4/cmd.c 
b/drivers/net/ethernet/mellanox/mlx4/cmd.c
index 4f7dc04..529ef05 100644
--- a/drivers/net/ethernet/mellanox/mlx4/cmd.c
+++ b/drivers/net/ethernet/mellanox/mlx4/cmd.c
@@ -714,8 +714,13 @@ static int mlx4_cmd_wait(struct mlx4_dev *dev, u64 
in_param, u64 *out_param,
 msecs_to_jiffies(timeout))) {
mlx4_warn(dev, "command 0x%x timed out (go bit not cleared)\n",
  op);
-   err = -EIO;
-   goto out_reset;
+   if (op == MLX4_CMD_NOP) {
+   err = -EBUSY;
+   goto out;
+   } else {
+   err = -EIO;
+   goto out_reset;
+   }
}
 
err = context->result;
-- 
2.3.5

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH] mlx4_core: Fix fallback from MSI-X to INTx

2015-05-22 Thread Benjamin Poirier
The test in mlx4_load_one() to remove MLX4_FLAG_MSI_X expects mlx4_NOP() to
fail with -EBUSY. It is also necessary to avoid the reset since the device
is not fully reinitialized before calling mlx4_start_hca() a second time.

Note that this will also affect mlx4_test_interrupts(), the only other user
of MLX4_CMD_NOP.

Fixes: f5aef5a (net/mlx4_core: Activate reset flow upon fatal command cases)
Signed-off-by: Benjamin Poirier bpoir...@suse.de
---
 drivers/net/ethernet/mellanox/mlx4/cmd.c | 9 +++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/drivers/net/ethernet/mellanox/mlx4/cmd.c 
b/drivers/net/ethernet/mellanox/mlx4/cmd.c
index 4f7dc04..529ef05 100644
--- a/drivers/net/ethernet/mellanox/mlx4/cmd.c
+++ b/drivers/net/ethernet/mellanox/mlx4/cmd.c
@@ -714,8 +714,13 @@ static int mlx4_cmd_wait(struct mlx4_dev *dev, u64 
in_param, u64 *out_param,
 msecs_to_jiffies(timeout))) {
mlx4_warn(dev, command 0x%x timed out (go bit not cleared)\n,
  op);
-   err = -EIO;
-   goto out_reset;
+   if (op == MLX4_CMD_NOP) {
+   err = -EBUSY;
+   goto out;
+   } else {
+   err = -EIO;
+   goto out_reset;
+   }
}
 
err = context-result;
-- 
2.3.5

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/