[PATCH for-next 0/6] IB: 2nd batch of fixes for 3.5

[PATCH for-next 0/6] IB: 2nd batch of fixes for 3.5

[Or Gerlitz]

Hi Roland,

This is a 2nd batch of fixes for 3.5, mostly to the mlx4 (core and ib) driver:

[PATCH for-next V1 1/6] net/mlx4_core: Change bitmap allocator to work in round-robin fashion
[PATCH for-next 2/6] IB/core: fix mismatch between locked and pinned pages
[PATCH for-next 3/6] IB/mlx4: Fix parameter checking in create_cq
[PATCH for-next 4/6] IB/core: Fix IB_SA_COMP_MASK macro
[PATCH for-next 5/6] net/mlx4: Adjust initial value of vl_cap in mlx4_SET_PORT
[PATCH for-next 6/6] IB/mlx4: bug fix for mlx4_ib_add error flow

The first patch is V1 to the change in the bitmap allocator, where your feedback was applied. 

The second patch is fix from Yishai Hadas to wrong setting done in umem.c, the bug
was introduced in 3.2, so its not regression from 3.4-rc1, sounds like it fits -stable

Next is a fix from Eli to create_cq and following that three fixes 
which came up during Jack's work to prepare the SRIOV patches.

BTW - this series should get along fine before the TSS/RSS one, and vise versa

Or.

Eli Cohen (1):
  IB/mlx4: Fix parameter checking in create_cq

Jack Morgenstein (3):
  net/mlx4_core: Change bitmap allocator to work in round-robin fashion
  IB/core: Fix IB_SA_COMP_MASK macro
  IB/mlx4: bug fix for mlx4_ib_add error flow

Or Gerlitz (1):
  net/mlx4: Adjust initial value of vl_cap in mlx4_SET_PORT

Yishai Hadas (1):
  IB/core: fix mismatch between locked and pinned pages

 drivers/infiniband/core/umem.c             |    2 +-
 drivers/infiniband/hw/mlx4/cq.c            |    2 +-
 drivers/infiniband/hw/mlx4/main.c          |    6 +++---
 drivers/net/ethernet/mellanox/mlx4/alloc.c |    3 ---
 drivers/net/ethernet/mellanox/mlx4/port.c  |   12 +++++++++++-
 include/rdma/ib_mad.h                      |    2 +-
 6 files changed, 17 insertions(+), 10 deletions(-)

--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH for-next V1 1/6] net/mlx4_core: Change bitmap allocator to work in round-robin fashion

[Or Gerlitz]

From: Jack Morgenstein <jackm-LDSdmyG8hGV8YrgS2mwiifqBs+8SCbDb@public.gmane.org>

Under most circumstances, the bitmap allocator does not allocate the
same full 24-bit qp-number immediately after a qp is destroyed.

This operates by using the upper bits of a 24-bit qp number, beyond the
number of QPs that are actually available in the low level driver.
For example, say that the HCA is willing to allocate a maximum of 64K qps.
We use the bits 23..16 as a "counter" which is incremented by 1 at each
allocation so that even if the same physical QP is re-allocated, it will
not receive the same 24-bit QP number.

However, we have seen the following scenario:
1. Allocate, say, 255 QPs in succession.  This will cause a wrap of the "counter".
2. Destroy the first QP allocated, then allocate a new QP.  The new QP,
   because of the counter wraparound, will get the same FULL QP number as
   the QP just destroyed!

This is a problem, because packets in transit can be erroneously delivered to
the new QP when they were meant for the old (destroyed) QP, because the full QP
number of the new QP is identical to the destroyed QP. (The "counter" mechanism
is meant to prevent this by having the full 24-bit QP numbers differ even if
the physical QP on the HCA is the same. As we see above, however, this mechanism
does not always work).

The best fix for this problem is to allocate QPs in round-robin mode,
so that the physical QP numbers are not immediately re-used.

Per feedback from Roland Dreier, deleted the bitmap->top update as well from
mlx4_bitmap_free_range. He pointed out that the "top" update was unnecessary if
bitmap->last only increases until the bitmap wraparound (so there is no chance of
immediately re-allocating a just-released resource).

Found-by:  Matthew Finlay <matt-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
Signed-off-by: Jack Morgenstein <jackm-LDSdmyG8hGV8YrgS2mwiifqBs+8SCbDb@public.gmane.org>
---

changes from V0:

Applied the feedback from Roland to delete the bitmap->top update as well from
mlx4_bitmap_free_range. 

 drivers/net/ethernet/mellanox/mlx4/alloc.c |    3 ---
 1 files changed, 0 insertions(+), 3 deletions(-)

diff --git a/drivers/net/ethernet/mellanox/mlx4/alloc.c b/drivers/net/ethernet/mellanox/mlx4/alloc.c
index 8be20e7..06fef5b 100644
--- a/drivers/net/ethernet/mellanox/mlx4/alloc.c
+++ b/drivers/net/ethernet/mellanox/mlx4/alloc.c
@@ -124,9 +124,6 @@ void mlx4_bitmap_free_range(struct mlx4_bitmap *bitmap, u32 obj, int cnt)
 
 	spin_lock(&bitmap->lock);
 	bitmap_clear(bitmap->table, obj, cnt);
-	bitmap->last = min(bitmap->last, obj);
-	bitmap->top = (bitmap->top + bitmap->max + bitmap->reserved_top)
-			& bitmap->mask;
 	bitmap->avail += cnt;
 	spin_unlock(&bitmap->lock);
 }
-- 
1.7.1

--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH for-next V1 1/6] net/mlx4_core: Change bitmap allocator to work in round-robin fashion

[Roland Dreier]

thanks, applied
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH for-next 2/6] IB/core: fix mismatch between locked and pinned pages

[Or Gerlitz]

From: Yishai Hadas <yishaih-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>

Commit bc3e53f68 "mm: distinguish between mlocked and pinned pages"
introduced a separate counter for pinned pages and used it over
the IB stack. Specifically, in ib_umem_get the pinned counter
is incremented, but ib_umem_release wrongly decrements the
locked counter, fix that.

Cc: Christoph Lameter <cl-vYTEC60ixJUAvxtiuMwx3w@public.gmane.org>
Signed-off-by: Yishai Hadas <yishaih-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
---
 drivers/infiniband/core/umem.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/infiniband/core/umem.c b/drivers/infiniband/core/umem.c
index 71f0c0f..a841123 100644
--- a/drivers/infiniband/core/umem.c
+++ b/drivers/infiniband/core/umem.c
@@ -269,7 +269,7 @@ void ib_umem_release(struct ib_umem *umem)
 	} else
 		down_write(&mm->mmap_sem);
 
-	current->mm->locked_vm -= diff;
+	current->mm->pinned_vm -= diff;
 	up_write(&mm->mmap_sem);
 	mmput(mm);
 	kfree(umem);
-- 
1.7.1

--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH for-next 2/6] IB/core: fix mismatch between locked and pinned pages

[Christoph Lameter]

On Thu, 10 May 2012, Or Gerlitz wrote:

> Commit bc3e53f68 "mm: distinguish between mlocked and pinned pages"
> introduced a separate counter for pinned pages and used it over
> the IB stack. Specifically, in ib_umem_get the pinned counter
> is incremented, but ib_umem_release wrongly decrements the
> locked counter, fix that.

Reviewed-by: Christoph Lameter <cl-vYTEC60ixJUAvxtiuMwx3w@public.gmane.org>
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH for-next 2/6] IB/core: fix mismatch between locked and pinned pages

[Christoph Lameter]

On Thu, 10 May 2012, Or Gerlitz wrote:

> Commit bc3e53f68 "mm: distinguish between mlocked and pinned pages"
> introduced a separate counter for pinned pages and used it over
> the IB stack. Specifically, in ib_umem_get the pinned counter
> is incremented, but ib_umem_release wrongly decrements the
> locked counter, fix that.

This looks like a stable fix or at least something that should be merged
upstream asap. Patch is missing my reviewed-by tag.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH for-next 2/6] IB/core: fix mismatch between locked and pinned pages

[Roland Dreier]

applied, with Christoph's reviewed-by and a Cc: stable tag.  Thanks everyone.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH for-next 2/6] IB/core: fix mismatch between locked and pinned pages

[Or Gerlitz]

On 5/11/2012 9:38 PM, Roland Dreier wrote:
> applied, with Christoph's reviewed-by and a Cc: stable tag.  Thanks everyone.

Hi Roland,

Okay, thanks, I see that you still haven't pushed these updates to the 
infiniband tree, will be helpful if you can do that soon, such that 
we'll be able to work directly against your tree with the patches 
accepted so far applied.

Now... with 3.4-rc7 being out, the 3.5 merge window is coming really 
soon, any chance you'll have time to look on the new QP group verbs, 
IPoIB TSS/RSS code in the coming days?

Or.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH for-next 3/6] IB/mlx4: Fix parameter checking in create_cq

[Or Gerlitz]

From: Eli Cohen <eli-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>

Round up the number of entries before checking against the device's
capabilities and not after that.

Signed-off-by: Eli Cohen <eli-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
---
 drivers/infiniband/hw/mlx4/cq.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/infiniband/hw/mlx4/cq.c b/drivers/infiniband/hw/mlx4/cq.c
index f69ccd2..222a06c 100644
--- a/drivers/infiniband/hw/mlx4/cq.c
+++ b/drivers/infiniband/hw/mlx4/cq.c
@@ -172,6 +172,7 @@ struct ib_cq *mlx4_ib_create_cq(struct ib_device *ibdev, int entries, int vector
 	struct mlx4_uar *uar;
 	int err;
 
+	entries      = roundup_pow_of_two(entries + 1);
 	if (entries < 1 || entries > dev->dev->caps.max_cqes)
 		return ERR_PTR(-EINVAL);
 
@@ -179,7 +180,6 @@ struct ib_cq *mlx4_ib_create_cq(struct ib_device *ibdev, int entries, int vector
 	if (!cq)
 		return ERR_PTR(-ENOMEM);
 
-	entries      = roundup_pow_of_two(entries + 1);
 	cq->ibcq.cqe = entries - 1;
 	mutex_init(&cq->resize_mutex);
 	spin_lock_init(&cq->lock);
-- 
1.7.1

--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH for-next 3/6] IB/mlx4: Fix parameter checking in create_cq

[sebastien dugue]

Hi,

On Thu, 10 May 2012 23:28:06 +0300
Or Gerlitz <ogerlitz-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org> wrote:

> From: Eli Cohen <eli-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
> 
> Round up the number of entries before checking against the device's
> capabilities and not after that.
> 
> Signed-off-by: Eli Cohen <eli-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
> ---
>  drivers/infiniband/hw/mlx4/cq.c |    2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
> 
> diff --git a/drivers/infiniband/hw/mlx4/cq.c b/drivers/infiniband/hw/mlx4/cq.c
> index f69ccd2..222a06c 100644
> --- a/drivers/infiniband/hw/mlx4/cq.c
> +++ b/drivers/infiniband/hw/mlx4/cq.c
> @@ -172,6 +172,7 @@ struct ib_cq *mlx4_ib_create_cq(struct ib_device *ibdev, int entries, int vector
>  	struct mlx4_uar *uar;
>  	int err;
>  
> +	entries      = roundup_pow_of_two(entries + 1);
>  	if (entries < 1 || entries > dev->dev->caps.max_cqes)

  Is the first check still needed here then?


  Sébastien.


>  		return ERR_PTR(-EINVAL);
>  
> @@ -179,7 +180,6 @@ struct ib_cq *mlx4_ib_create_cq(struct ib_device *ibdev, int entries, int vector
>  	if (!cq)
>  		return ERR_PTR(-ENOMEM);
>  
> -	entries      = roundup_pow_of_two(entries + 1);
>  	cq->ibcq.cqe = entries - 1;
>  	mutex_init(&cq->resize_mutex);
>  	spin_lock_init(&cq->lock);
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH for-next 3/6] IB/mlx4: Fix parameter checking in create_cq

[Or Gerlitz]

sebastien dugue <sebastien.dugue-6ktuUTfB/bM@public.gmane.org> wrote:
> > @@ -172,6 +172,7 @@ struct ib_cq *mlx4_ib_create_cq(struct ib_device
> > *ibdev, int entries, int vector
> >       struct mlx4_uar *uar;
> >       int err;
> >
> > +     entries      = roundup_pow_of_two(entries + 1);
> >       if (entries < 1 || entries > dev->dev->caps.max_cqes)
>
>  Is the first check still needed here then?

not really, good catch - unless we need to protect here from negative
values coming
e.g from user space, I'll look this up,  thanks

Or.

Or.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH for-next 3/6] IB/mlx4: Fix parameter checking in create_cq

[sebastien dugue]

On Fri, 11 May 2012 10:39:12 +0300
Or Gerlitz <or.gerlitz-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:

> sebastien dugue <sebastien.dugue-6ktuUTfB/bM@public.gmane.org> wrote:
> > > @@ -172,6 +172,7 @@ struct ib_cq *mlx4_ib_create_cq(struct ib_device
> > > *ibdev, int entries, int vector
> > >       struct mlx4_uar *uar;
> > >       int err;
> > >
> > > +     entries      = roundup_pow_of_two(entries + 1);
> > >       if (entries < 1 || entries > dev->dev->caps.max_cqes)
> >
> >  Is the first check still needed here then?
> 
> not really, good catch - unless we need to protect here from negative
> values coming
> e.g from user space, I'll look this up,  thanks
> 
> Or.
> 
> Or.


  A small test shows that for n < 2, we have roundup_pow_of_two(n) == 1. But
this is with the current implementation and on x86_64, so maybe on other
architectures the test may still be needed after all.


  Sébastien.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH for-next 4/6] IB/core: Fix IB_SA_COMP_MASK macro

[Or Gerlitz]

From: Jack Morgenstein <jackm-LDSdmyG8hGV8YrgS2mwiifqBs+8SCbDb@public.gmane.org>

It needs parentheses around the argument, so that it can
be used with complex arguments (e.g., n+5 say).

Signed-off-by: Jack Morgenstein <jackm-LDSdmyG8hGV8YrgS2mwiifqBs+8SCbDb@public.gmane.org>
---
 include/rdma/ib_mad.h |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/include/rdma/ib_mad.h b/include/rdma/ib_mad.h
index b513f57..3d81b90 100644
--- a/include/rdma/ib_mad.h
+++ b/include/rdma/ib_mad.h
@@ -160,7 +160,7 @@ struct ib_rmpp_hdr {
 
 typedef u64 __bitwise ib_sa_comp_mask;
 
-#define IB_SA_COMP_MASK(n) ((__force ib_sa_comp_mask) cpu_to_be64(1ull << n))
+#define IB_SA_COMP_MASK(n) ((__force ib_sa_comp_mask) cpu_to_be64(1ull << (n)))
 
 /*
  * ib_sa_hdr and ib_sa_mad structures must be packed because they have
-- 
1.7.1

--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH for-next 4/6] IB/core: Fix IB_SA_COMP_MASK macro

[Roland Dreier]

thanks, applied.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH for-next 5/6] net/mlx4: Adjust initial value of vl_cap in mlx4_SET_PORT

[Or Gerlitz]

Adjust the initial value of vl_cap in mlx4_SET_PORT such that only for CX3
devices we start with 8 VLs, in an attempt to avoid errors such as:

 mlx4_core 0000:06:00.0: command 0xc failed: fw status = 0x40
 mlx4_core 0000:06:00.0: vhcr command:0xc slave:0 failed with error:0, status -12

to appear in the system log.

Signed-off-by: Or Gerlitz <ogerlitz-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
Signed-off-by: Aviad Yehezkel <aviadye-VPRAkNaXOzVS1MOuV/RT9w@public.gmane.org>
Signed-off-by: Jack Morgenstein <jackm-LDSdmyG8hGV8YrgS2mwiifqBs+8SCbDb@public.gmane.org>
---
 drivers/net/ethernet/mellanox/mlx4/port.c |   12 +++++++++++-
 1 files changed, 11 insertions(+), 1 deletions(-)

diff --git a/drivers/net/ethernet/mellanox/mlx4/port.c b/drivers/net/ethernet/mellanox/mlx4/port.c
index 77535ff..53aa531 100644
--- a/drivers/net/ethernet/mellanox/mlx4/port.c
+++ b/drivers/net/ethernet/mellanox/mlx4/port.c
@@ -731,6 +731,16 @@ enum {
 	MLX4_CHANGE_PORT_MTU_CAP = 22,
 };
 
+#define CX3_PPF_DEV_ID	0x1003
+
+static int vl_cap_start(struct mlx4_dev *dev)
+{
+	/* for non CX3 devices, start with 4 VLs to avoid errors in syslog */
+	if (dev->pdev->device != CX3_PPF_DEV_ID)
+		return 4;
+	return 8;
+}
+
 int mlx4_SET_PORT(struct mlx4_dev *dev, u8 port)
 {
 	struct mlx4_cmd_mailbox *mailbox;
@@ -748,7 +758,7 @@ int mlx4_SET_PORT(struct mlx4_dev *dev, u8 port)
 	((__be32 *) mailbox->buf)[1] = dev->caps.ib_port_def_cap[port];
 
 	/* IB VL CAP enum isn't used by the firmware, just numerical values */
-	for (vl_cap = 8; vl_cap >= 1; vl_cap >>= 1) {
+	for (vl_cap = vl_cap_start(dev); vl_cap >= 1; vl_cap >>= 1) {
 		((__be32 *) mailbox->buf)[0] = cpu_to_be32(
 			(1 << MLX4_CHANGE_PORT_MTU_CAP) |
 			(1 << MLX4_CHANGE_PORT_VL_CAP)  |
-- 
1.7.1

--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH for-next 5/6] net/mlx4: Adjust initial value of vl_cap in mlx4_SET_PORT

[Roland Dreier]

> +#define CX3_PPF_DEV_ID 0x1003
> +
> +static int vl_cap_start(struct mlx4_dev *dev)
> +{
> +       /* for non CX3 devices, start with 4 VLs to avoid errors in syslog */
> +       if (dev->pdev->device != CX3_PPF_DEV_ID)
> +               return 4;
> +       return 8;
> +}

This really doesn't look maintainable as different devices with
different limits come along.

How ugly is it to pass some sort of "no warn" flag down into
the command to suppress the messages?
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH for-next 5/6] net/mlx4: Adjust initial value of vl_cap in mlx4_SET_PORT

[Or Gerlitz]

On 5/19/2012 3:40 AM, Roland Dreier wrote:
>> +#define CX3_PPF_DEV_ID 0x1003
>> +static int vl_cap_start(struct mlx4_dev *dev)
>> +{
>> +       /* for non CX3 devices, start with 4 VLs to avoid errors in syslog */
>> +       if (dev->pdev->device != CX3_PPF_DEV_ID)
>> +               return 4;
>> +       return 8;
>> +}
>
> This really doesn't look maintainable as different devices with different limits come along.

Yep, I considered this patch to be a bit of ugly, but decided to send it 
since the potential damage without
something done here e.g wrong support calls as of false negatives prints 
seemed to justify that..  BTW I noticed
that today there IS some CX3 special code in mlx4_core/main.c

> 282-    /* Sense port always allowed on supported devices for 
> ConnectX1 and 2 */
> 283:    if (dev->pdev->device != 0x1003)
> 284-            dev->caps.flags |= MLX4_DEV_CAP_FLAG_SENSE_SUPPORT;

anyway,

>
> How ugly is it to pass some sort of "no warn" flag down into the command to suppress the messages?

We will check the feasibility of doing so.

Or.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH for-next 5/6] net/mlx4: Adjust initial value of vl_cap in mlx4_SET_PORT

[Roland Dreier]

>  BTW I noticed
> that today there IS some CX3 special code in mlx4_core/main.c
>
>> 282-    /* Sense port always allowed on supported devices for ConnectX1
>> and 2 */
>> 283:    if (dev->pdev->device != 0x1003)
>> 284-            dev->caps.flags |= MLX4_DEV_CAP_FLAG_SENSE_SUPPORT;

Yeah, I think this has similar maintainability problems.  Looks like it
went through the net tree ... and davem doesn't alway review driver
changes in depth.

 - R.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH for-next 5/6] net/mlx4: Adjust initial value of vl_cap in mlx4_SET_PORT

[Or Gerlitz]

On 5/19/2012 3:40 AM, Roland Dreier wrote:
> This really doesn't look maintainable as different devices with 
> different limits come along.

okay, so lets hold off with this patch for a while until we find 
something which is more maintainable

Or.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH for-next 6/6] IB/mlx4: bug fix for mlx4_ib_add error flow

[Or Gerlitz]

From: Jack Morgenstein <jackm-LDSdmyG8hGV8YrgS2mwiifqBs+8SCbDb@public.gmane.org>

Need to use a different looping index for mlx4_counter_alloc()
and for device_create_file() iterations: the mlx4_counter_alloc()
loop index is used in the error flow to de-allocate counters.

If the same loop index is used for device_create_file() and, say,
the device_create_file() loop fails on the first iteration,
the allocated counters will not be de-allocated.

Signed-off-by: Jack Morgenstein <jackm-LDSdmyG8hGV8YrgS2mwiifqBs+8SCbDb@public.gmane.org>
---
 drivers/infiniband/hw/mlx4/main.c |    6 +++---
 1 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/infiniband/hw/mlx4/main.c b/drivers/infiniband/hw/mlx4/main.c
index bdf7691..c02c75c 100644
--- a/drivers/infiniband/hw/mlx4/main.c
+++ b/drivers/infiniband/hw/mlx4/main.c
@@ -1161,7 +1161,7 @@ static void *mlx4_ib_add(struct mlx4_dev *dev)
 {
 	struct mlx4_ib_dev *ibdev;
 	int num_ports = 0;
-	int i;
+	int i, j;
 	int err;
 	struct mlx4_ib_iboe *iboe;
 
@@ -1324,9 +1324,9 @@ static void *mlx4_ib_add(struct mlx4_dev *dev)
 			goto err_reg;
 	}
 
-	for (i = 0; i < ARRAY_SIZE(mlx4_class_attributes); ++i) {
+	for (j = 0; j < ARRAY_SIZE(mlx4_class_attributes); ++j) {
 		if (device_create_file(&ibdev->ib_dev.dev,
-				       mlx4_class_attributes[i]))
+				       mlx4_class_attributes[j]))
 			goto err_notif;
 	}
 
-- 
1.7.1

--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH for-next 6/6] IB/mlx4: bug fix for mlx4_ib_add error flow

[Roland Dreier]

thanks, applied
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html