On 9/26/2024 3:56 PM, Margolin, Michael wrote:
On 9/24/2024 9:00 PM, Jason Gunthorpe wrote:
CAUTION: This email originated from outside of the organization. Do
not click links or open attachments unless you can confirm the sender
and know the content is safe.
On Tue, Sep 24, 2024 at 12:16:03PM +0000, Michael Margolin wrote:
The GUID is received in big-endian so align types accordingly to avoid
compiler warnings.
Closes:
https://lore.kernel.org/oe-kbuild-all/202409032113.bvyVfsNp-lkp@xxxxxxxxx/
Fixes: 04e36fd27a2a ("RDMA/efa: Add support for node guid")
Reported-by: kernel test robot <lkp@xxxxxxxxx>
Reviewed-by: Yehuda Yitschak <yehuday@xxxxxxxxxx>
Reviewed-by: Yonatan Nachum <ynachum@xxxxxxxxxx>
Signed-off-by: Michael Margolin <mrgolin@xxxxxxxxxx>
---
drivers/infiniband/hw/efa/efa_com_cmd.c | 2 +-
drivers/infiniband/hw/efa/efa_com_cmd.h | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/infiniband/hw/efa/efa_com_cmd.c
b/drivers/infiniband/hw/efa/efa_com_cmd.c
index 5a774925cdea..5754da4e6ff8 100644
--- a/drivers/infiniband/hw/efa/efa_com_cmd.c
+++ b/drivers/infiniband/hw/efa/efa_com_cmd.c
@@ -465,7 +465,7 @@ int efa_com_get_device_attr(struct efa_com_dev
*edev,
result->db_bar = resp.u.device_attr.db_bar;
result->max_rdma_size = resp.u.device_attr.max_rdma_size;
result->device_caps = resp.u.device_attr.device_caps;
- result->guid = resp.u.device_attr.guid;
+ result->guid = (__force __be64)resp.u.device_attr.guid;
That can't be right, use the proper conversion function, or the proper
type..
Jason
The current assumption in the driver is that data from the device
arrives in a correct byte order for the CPU, while the guid field is
in reversed order.
Would you suggest doing something like:
- result->guid = resp.u.device_attr.guid;
+ result->guid = __cpu_to_be64(__swab64(resp.u.device_attr.guid));
Michael
Actually that's wrong, the device always sets guid in BE order so no
swap is needed in the driver in any case.
