On Fri, Dec 22, 2017 at 08:46:00AM -0800, Dennis Dalessandro wrote:
> From: Don Hiatt <don.hiatt@xxxxxxxxx>
>
> Change the slid arg to ingress_pkey_table_fail() to a full
> 32Bits and do not convert to 16Bits in caller. This is so we
> can keep everything 32bit in the kernel and only change to
> 16bit at the uapi boundary.
>
> Signed-off-by: Don Hiatt <don.hiatt@xxxxxxxxx>
> Signed-off-by: Dennis Dalessandro <dennis.dalessandro@xxxxxxxxx>
> drivers/infiniband/hw/hfi1/hfi.h | 2 +-
> drivers/infiniband/hw/hfi1/mad.c | 6 +-----
> 2 files changed, 2 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/infiniband/hw/hfi1/hfi.h b/drivers/infiniband/hw/hfi1/hfi.h
> index 869c2bf..dc5b133 100644
> +++ b/drivers/infiniband/hw/hfi1/hfi.h
> @@ -1627,7 +1627,7 @@ static int ingress_pkey_table_search(struct hfi1_pportdata *ppd, u16 pkey)
> * the 'error info' for this failure.
> */
> static void ingress_pkey_table_fail(struct hfi1_pportdata *ppd, u16 pkey,
> - u16 slid)
> + u32 slid)
> {
> struct hfi1_devdata *dd = ppd->dd;
>
> diff --git a/drivers/infiniband/hw/hfi1/mad.c b/drivers/infiniband/hw/hfi1/mad.c
> index cf8dba3..34547a4 100644
> +++ b/drivers/infiniband/hw/hfi1/mad.c
> @@ -4348,11 +4348,7 @@ static int opa_local_smp_check(struct hfi1_ibport *ibp,
> */
> if (pkey == LIM_MGMT_P_KEY || pkey == FULL_MGMT_P_KEY)
> return 0;
> - /*
> - * On OPA devices it is okay to lose the upper 16 bits of LID as this
> - * information is obtained elsewhere. Mask off the upper 16 bits.
> - */
> - ingress_pkey_table_fail(ppd, pkey, ib_lid_cpu16(0xFFFF & in_wc->slid));
> + ingress_pkey_table_fail(ppd, pkey, in_wc->slid);
> return 1;
> }
I'm confused by this patch.
It seems to totally revert the -stable patch
4988be5813ff2afdc0d8bfa315ef34a577d3efbf, with the exception that
ingress_pkey_table_fail now accepts a u32.
Is this saying the correct version of
4988be5813ff2afdc0d8bfa315ef34a577d3efbf was to just change that one
type??
Jason
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
