summaryrefslogtreecommitdiffstats
path: root/drivers/pci/pci.h
diff options
context:
space:
mode:
authorEddie Wai <eddie.wai@broadcom.com>2017-06-29 12:28:13 -0700
committerDoug Ledford <dledford@redhat.com>2017-07-20 11:20:50 -0400
commita25d112fe9c8e8817cde1df17a82aee472c55993 (patch)
tree644616f02fe039323fa385d82835b213bb4e42a4 /drivers/pci/pci.h
parent58d4a671d0eac45db1c7f27c8684c277249ac127 (diff)
downloadlinux-stable-a25d112fe9c8e8817cde1df17a82aee472c55993.tar.gz
linux-stable-a25d112fe9c8e8817cde1df17a82aee472c55993.tar.bz2
linux-stable-a25d112fe9c8e8817cde1df17a82aee472c55993.zip
RDMA/bnxt_re: Fixed the max_rd_atomic support for initiator and destination QP
There's a couple of bugs in the support of max_rd_atomic and max_dest_rd_atomic. In the modify_qp, if the requested max_rd_atomic, which is the ORRQ size, is greater than what the chip can support, then we have to cap the request to chip max as we can't have the HW overflow the ORRQ. Capping the max_rd_atomic support internally is okay to do as the remaining read/atomic WRs will still be sitting in the SQ. However, for the max_dest_rd_atomic, the driver has to error out as this dictates the IRRQ size and we can't control what the remote side sends. Signed-off-by: Eddie Wai <eddie.wai@broadcom.com> Signed-off-by: Selvin Xavier <selvin.xavier@broadcom.com> Signed-off-by: Doug Ledford <dledford@redhat.com>
Diffstat (limited to 'drivers/pci/pci.h')
0 files changed, 0 insertions, 0 deletions