On Thu, Feb 07, 2019 at 01:31:21AM -0500, Devesh Sharma wrote:
> This is to enable RoCE on Broadcom's 57500 series of adapters.
> Patch 0001, 0002 and 0003 are handing the control path changes.
> Patch 0004 and 0005 are related to kernel space fast path.
> Patch 0006 handles the user-kernel ABI changes. Patch 0007 is
> to enable RoCE driver load on next gen chips.
>
> This patch series requires a patch from Linus git:
> commit 78793afbb0b9 ("bnxt_en: Increase context memory allocations on
> 57500 chips for RDMA.")
This is the wrong commit ID
> Changelog:
>
> V4->V5
> rebased the series to the tip of for-next.
> Patch 0002:
> - cleaned up the DB ring code to address muti-platform
> mmio-write compatibility issue.
> V3->V4
> rebased the series to the tip of for-next.
> Patch 0002:
> - dropped use of __iowrite64_copy, use writeq instead.
> Patch 0006:
> - use __aligned_u64 instead of __u64.
> - fix sizeof(resp) when copying response to user.
> V2->V3
> Patch 0006:
> - Implemented the comp_mask approach instead of changing the
> ABI version number.
> V1->V2
> Rebased the series to the tip of for-next and fixed widespread
> code alignment.
> Patch 0001:
> - Replace chip_ctx pointer with static member in bnxt_re_dev
> structure.
> Patch 0002:
> - Fixed kbuild error on i386 arch. Using "depends on 64BIT"
> - Removed wmb before calling writeq in db-ring functions
> Patch 0003:
> - Fixed typo in the commit message
> Patch 0004:
> - Removed endian-ness fix from feature series.
> Patch 0005:
> - Fixed code formatting issues
> Patch 0006:
> - Implemented ABI range check as suggested by Jason and Leon
>
> Devesh Sharma (7):
> RDMA/bnxt_re: Add chip context to identify 57500 series
> RDMA/bnxt_re: Add 64bit doorbells for 57500 series
> RDMA/bnxt_re: Skip backing store allocation for 57500 series
> RDMA/bnxt_re: Enable GSI QP support for 57500 series
> RDMA/bnxt_re: Add extended psn structure for 57500 adapters
> RDMA/bnxt_re: Update kernel user abi to pass chip context
> RDMA/bnxt_en: Enable RDMA driver support for 57500 chip
This seems fine now, applied to for-next
Thanks,
Jason
