| Message ID | 20180220205638.1959033-1-arnd@arndb.de (mailing list archive) |
|---|---|
| State | Accepted |
| Delegated to: | Jason Gunthorpe |
| Headers | show |
On Tue, Feb 20, 2018 at 09:56:26PM +0100, Arnd Bergmann wrote: > Building for a 32-bit target results in a couple of warnings from casting between > a 32-bit pointer and a 64-bit integer: > > drivers/infiniband/hw/bnxt_re/qplib_fp.c: In function 'bnxt_qplib_service_nq': > drivers/infiniband/hw/bnxt_re/qplib_fp.c:333:23: error: cast to pointer from integer of different size [-Werror=int-to-pointer-cast] > bnxt_qplib_arm_srq((struct bnxt_qplib_srq *)q_handle, > ^ > drivers/infiniband/hw/bnxt_re/qplib_fp.c:336:12: error: cast to pointer from integer of different size [-Werror=int-to-pointer-cast] > (struct bnxt_qplib_srq *)q_handle, > ^ > In file included from include/linux/byteorder/little_endian.h:5, > from arch/arm/include/uapi/asm/byteorder.h:22, > from include/asm-generic/bitops/le.h:6, > from arch/arm/include/asm/bitops.h:342, > from include/linux/bitops.h:38, > from include/linux/kernel.h:11, > from include/linux/interrupt.h:6, > from drivers/infiniband/hw/bnxt_re/qplib_fp.c:39: > drivers/infiniband/hw/bnxt_re/qplib_fp.c: In function 'bnxt_qplib_create_srq': > include/uapi/linux/byteorder/little_endian.h:31:43: error: cast from pointer to integer of different size [-Werror=pointer-to-int-cast] > #define __cpu_to_le64(x) ((__force __le64)(__u64)(x)) > ^ > include/linux/byteorder/generic.h:86:21: note: in expansion of macro '__cpu_to_le64' > #define cpu_to_le64 __cpu_to_le64 > ^~~~~~~~~~~~~ > drivers/infiniband/hw/bnxt_re/qplib_fp.c:569:19: note: in expansion of macro 'cpu_to_le64' > req.srq_handle = cpu_to_le64(srq); > > Using a uintptr_t as an intermediate works on all architectures. > > Fixes: 37cb11acf1f7 ("RDMA/bnxt_re: Add SRQ support for Broadcom adapters") > Signed-off-by: Arnd Bergmann <arnd@arndb.de> > drivers/infiniband/hw/bnxt_re/qplib_fp.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) I applied the series to for-next, thanks Jason -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wed, Feb 28, 2018 at 10:15 PM, Jason Gunthorpe <jgg@ziepe.ca> wrote: > On Tue, Feb 20, 2018 at 09:56:26PM +0100, Arnd Bergmann wrote: >> Building for a 32-bit target results in a couple of warnings from casting between >> a 32-bit pointer and a 64-bit integer: >> >> drivers/infiniband/hw/bnxt_re/qplib_fp.c: In function 'bnxt_qplib_service_nq': >> drivers/infiniband/hw/bnxt_re/qplib_fp.c:333:23: error: cast to pointer from integer of different size [-Werror=int-to-pointer-cast] >> bnxt_qplib_arm_srq((struct bnxt_qplib_srq *)q_handle, >> ^ >> drivers/infiniband/hw/bnxt_re/qplib_fp.c:336:12: error: cast to pointer from integer of different size [-Werror=int-to-pointer-cast] >> (struct bnxt_qplib_srq *)q_handle, >> ^ >> In file included from include/linux/byteorder/little_endian.h:5, >> from arch/arm/include/uapi/asm/byteorder.h:22, >> from include/asm-generic/bitops/le.h:6, >> from arch/arm/include/asm/bitops.h:342, >> from include/linux/bitops.h:38, >> from include/linux/kernel.h:11, >> from include/linux/interrupt.h:6, >> from drivers/infiniband/hw/bnxt_re/qplib_fp.c:39: >> drivers/infiniband/hw/bnxt_re/qplib_fp.c: In function 'bnxt_qplib_create_srq': >> include/uapi/linux/byteorder/little_endian.h:31:43: error: cast from pointer to integer of different size [-Werror=pointer-to-int-cast] >> #define __cpu_to_le64(x) ((__force __le64)(__u64)(x)) >> ^ >> include/linux/byteorder/generic.h:86:21: note: in expansion of macro '__cpu_to_le64' >> #define cpu_to_le64 __cpu_to_le64 >> ^~~~~~~~~~~~~ >> drivers/infiniband/hw/bnxt_re/qplib_fp.c:569:19: note: in expansion of macro 'cpu_to_le64' >> req.srq_handle = cpu_to_le64(srq); >> >> Using a uintptr_t as an intermediate works on all architectures. >> >> Fixes: 37cb11acf1f7 ("RDMA/bnxt_re: Add SRQ support for Broadcom adapters") >> Signed-off-by: Arnd Bergmann <arnd@arndb.de> >> drivers/infiniband/hw/bnxt_re/qplib_fp.c | 4 ++-- >> 1 file changed, 2 insertions(+), 2 deletions(-) > > I applied the series to for-next, thanks Hi Jason, kernelci still reports the warning for v4.16-rc, any chance you can also send it as a bugfix for the current release? Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wed, Mar 07, 2018 at 12:25:14AM +0100, Arnd Bergmann wrote: > On Wed, Feb 28, 2018 at 10:15 PM, Jason Gunthorpe <jgg@ziepe.ca> wrote: > > On Tue, Feb 20, 2018 at 09:56:26PM +0100, Arnd Bergmann wrote: > >> Building for a 32-bit target results in a couple of warnings from casting between > >> a 32-bit pointer and a 64-bit integer: > >> > >> drivers/infiniband/hw/bnxt_re/qplib_fp.c: In function 'bnxt_qplib_service_nq': > >> drivers/infiniband/hw/bnxt_re/qplib_fp.c:333:23: error: cast to pointer from integer of different size [-Werror=int-to-pointer-cast] > >> bnxt_qplib_arm_srq((struct bnxt_qplib_srq *)q_handle, > >> ^ > >> drivers/infiniband/hw/bnxt_re/qplib_fp.c:336:12: error: cast to pointer from integer of different size [-Werror=int-to-pointer-cast] > >> (struct bnxt_qplib_srq *)q_handle, > >> ^ > >> In file included from include/linux/byteorder/little_endian.h:5, > >> from arch/arm/include/uapi/asm/byteorder.h:22, > >> from include/asm-generic/bitops/le.h:6, > >> from arch/arm/include/asm/bitops.h:342, > >> from include/linux/bitops.h:38, > >> from include/linux/kernel.h:11, > >> from include/linux/interrupt.h:6, > >> from drivers/infiniband/hw/bnxt_re/qplib_fp.c:39: > >> drivers/infiniband/hw/bnxt_re/qplib_fp.c: In function 'bnxt_qplib_create_srq': > >> include/uapi/linux/byteorder/little_endian.h:31:43: error: cast from pointer to integer of different size [-Werror=pointer-to-int-cast] > >> #define __cpu_to_le64(x) ((__force __le64)(__u64)(x)) > >> ^ > >> include/linux/byteorder/generic.h:86:21: note: in expansion of macro '__cpu_to_le64' > >> #define cpu_to_le64 __cpu_to_le64 > >> ^~~~~~~~~~~~~ > >> drivers/infiniband/hw/bnxt_re/qplib_fp.c:569:19: note: in expansion of macro 'cpu_to_le64' > >> req.srq_handle = cpu_to_le64(srq); > >> > >> Using a uintptr_t as an intermediate works on all architectures. > >> > >> Fixes: 37cb11acf1f7 ("RDMA/bnxt_re: Add SRQ support for Broadcom adapters") > >> Signed-off-by: Arnd Bergmann <arnd@arndb.de> > >> drivers/infiniband/hw/bnxt_re/qplib_fp.c | 4 ++-- > >> 1 file changed, 2 insertions(+), 2 deletions(-) > > > > I applied the series to for-next, thanks > > Hi Jason, > > kernelci still reports the warning for v4.16-rc, any chance you can also send it > as a bugfix for the current release? As a general rule we haven't been sending sparse cleanups like this to -rc which is why it went to -next.. Can you talk about why this is important to kernelci? I'm not familiar at all with it. I'm a little leary to duplicate a commit in both our branches without a good reason?? Jason -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wed, Mar 7, 2018 at 12:45 AM, Jason Gunthorpe <jgg@ziepe.ca> wrote: > On Wed, Mar 07, 2018 at 12:25:14AM +0100, Arnd Bergmann wrote: >> On Wed, Feb 28, 2018 at 10:15 PM, Jason Gunthorpe <jgg@ziepe.ca> wrote: >> > On Tue, Feb 20, 2018 at 09:56:26PM +0100, Arnd Bergmann wrote: >> >> Building for a 32-bit target results in a couple of warnings from casting between >> >> a 32-bit pointer and a 64-bit integer: >> >> >> >> drivers/infiniband/hw/bnxt_re/qplib_fp.c: In function 'bnxt_qplib_service_nq': >> >> drivers/infiniband/hw/bnxt_re/qplib_fp.c:333:23: error: cast to pointer from integer of different size [-Werror=int-to-pointer-cast] >> >> bnxt_qplib_arm_srq((struct bnxt_qplib_srq *)q_handle, >> >> ^ >> >> drivers/infiniband/hw/bnxt_re/qplib_fp.c:336:12: error: cast to pointer from integer of different size [-Werror=int-to-pointer-cast] >> >> (struct bnxt_qplib_srq *)q_handle, >> >> ^ >> >> In file included from include/linux/byteorder/little_endian.h:5, >> >> from arch/arm/include/uapi/asm/byteorder.h:22, >> >> from include/asm-generic/bitops/le.h:6, >> >> from arch/arm/include/asm/bitops.h:342, >> >> from include/linux/bitops.h:38, >> >> from include/linux/kernel.h:11, >> >> from include/linux/interrupt.h:6, >> >> from drivers/infiniband/hw/bnxt_re/qplib_fp.c:39: >> >> drivers/infiniband/hw/bnxt_re/qplib_fp.c: In function 'bnxt_qplib_create_srq': >> >> include/uapi/linux/byteorder/little_endian.h:31:43: error: cast from pointer to integer of different size [-Werror=pointer-to-int-cast] >> >> #define __cpu_to_le64(x) ((__force __le64)(__u64)(x)) >> >> ^ >> >> include/linux/byteorder/generic.h:86:21: note: in expansion of macro '__cpu_to_le64' >> >> #define cpu_to_le64 __cpu_to_le64 >> >> ^~~~~~~~~~~~~ >> >> drivers/infiniband/hw/bnxt_re/qplib_fp.c:569:19: note: in expansion of macro 'cpu_to_le64' >> >> req.srq_handle = cpu_to_le64(srq); >> >> >> >> Using a uintptr_t as an intermediate works on all architectures. >> >> >> >> Fixes: 37cb11acf1f7 ("RDMA/bnxt_re: Add SRQ support for Broadcom adapters") >> >> Signed-off-by: Arnd Bergmann <arnd@arndb.de> >> >> drivers/infiniband/hw/bnxt_re/qplib_fp.c | 4 ++-- >> >> 1 file changed, 2 insertions(+), 2 deletions(-) >> > >> > I applied the series to for-next, thanks >> >> Hi Jason, >> >> kernelci still reports the warning for v4.16-rc, any chance you can also send it >> as a bugfix for the current release? > > As a general rule we haven't been sending sparse cleanups like this to > -rc which is why it went to -next.. > > Can you talk about why this is important to kernelci? I'm not familiar > at all with it. > > I'm a little leary to duplicate a commit in both our branches without > a good reason?? I agree that we shouldn't do this for sparse warnings, but the one I'm interested in is a compiler warning in the allmodconfig build, as found by kernelci.org. This is one of only three remaining warnings that it reports for any of the default builds, see [1] for the overall build reports on mainline kernels, and [2] for the detailed log of the arm64 allmodconfig build that shows it. A small complication is that I wrote the changelog for the build warning on 32-bit architectures, which is more elaborate. kernelci.org for some reasons currently skips the allmodconfig build on all 32-bit architectures (I should ask the kernelci maintainers to change that), but the same patch I sent also addresses a warning on bit-endian 64-bit architectures: ../drivers/infiniband/hw/bnxt_re/qplib_fp.c: In function 'bnxt_qplib_create_srq': ../include/uapi/linux/byteorder/big_endian.h:31:52: warning: passing argument 1 of '__fswab64' makes integer from pointer without a cast [-Wint-conversion] #define __cpu_to_le64(x) ((__force __le64)__swab64((x))) ^ ../include/uapi/linux/swab.h:132:12: note: in definition of macro '__swab64' __fswab64(x)) ^ ../include/linux/byteorder/generic.h:86:21: note: in expansion of macro '__cpu_to_le64' #define cpu_to_le64 __cpu_to_le64 ^ ../drivers/infiniband/hw/bnxt_re/qplib_fp.c:569:19: note: in expansion of macro 'cpu_to_le64' req.srq_handle = cpu_to_le64(srq); ^ ../include/uapi/linux/swab.h:65:41: note: expected '__u64 {aka long long unsigned int}' but argument is of type 'struct bnxt_qplib_srq *' static inline __attribute_const__ __u64 __fswab64(__u64 val) On x86 and on the arm64 defconfig build, the __cpu_to_le64() is defined in include/uapi/linux/byteorder/little_endian.h and degrades into a __force cast that happens to avoid this warning, but on arm64 allmodconfig, we use include/uapi/linux/byteorder/big_endian.h, which passes the pointer into __swab64() first, and that warns about the type mismatch. Arnd [1] https://kernelci.org/build/mainline/branch/master/kernel/v4.16-rc4-123-g86f84779d8e9/ [2] https://storage.kernelci.org/mainline/master/v4.16-rc4-123-g86f84779d8e9/arm64/allmodconfig/build.log -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wed, Mar 7, 2018 at 10:05 AM, Arnd Bergmann <arnd@arndb.de> wrote: > A small complication is that I wrote the changelog for the build warning > on 32-bit architectures, which is more elaborate. kernelci.org for > some reasons currently skips the allmodconfig build on all 32-bit > architectures (I should ask the kernelci maintainers to change that), I see that Olof's build bot does have build results for arm32 allmodconfig, which is also big-endian, and reports the same errors that I described in the patch changelog. See http://arm-soc.lixom.net/buildlogs/arm-soc/v4.16-rc4-25-g41c42fe/ http://arm-soc.lixom.net/buildlogs/arm-soc/v4.16-rc4-25-g41c42fe/buildall.arm.allmodconfig.log.passed for today's results. This bot reports one other warning for arm32, but it's specific to the toolchain version used on that bot. I have a fix for that one as well, but there was some discussion on what the best approach would be. Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wed, Mar 7, 2018 at 11:12 AM, Arnd Bergmann <arnd@arndb.de> wrote: > On Wed, Mar 7, 2018 at 10:05 AM, Arnd Bergmann <arnd@arndb.de> wrote: > >> A small complication is that I wrote the changelog for the build warning >> on 32-bit architectures, which is more elaborate. kernelci.org for >> some reasons currently skips the allmodconfig build on all 32-bit >> architectures (I should ask the kernelci maintainers to change that), > > I see that Olof's build bot does have build results for arm32 > allmodconfig, which is also big-endian, and reports the same > errors that I described in the patch changelog. > > See > > http://arm-soc.lixom.net/buildlogs/arm-soc/v4.16-rc4-25-g41c42fe/ > http://arm-soc.lixom.net/buildlogs/arm-soc/v4.16-rc4-25-g41c42fe/buildall.arm.allmodconfig.log.passed > > for today's results. > > This bot reports one other warning for arm32, but it's > specific to the toolchain version used on that bot. > I have a fix for that one as well, but there was some > discussion on what the best approach would be. Any update on this? This is now the only remaining gcc warning we get on allmodconfig builds for arm (both 32-bit and 64-bit) in linux-4.16-rc. Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tue, 2018-03-13 at 09:50 +0100, Arnd Bergmann wrote: > On Wed, Mar 7, 2018 at 11:12 AM, Arnd Bergmann <arnd@arndb.de> wrote: > > On Wed, Mar 7, 2018 at 10:05 AM, Arnd Bergmann <arnd@arndb.de> wrote: > > > > > A small complication is that I wrote the changelog for the build warning > > > on 32-bit architectures, which is more elaborate. kernelci.org for > > > some reasons currently skips the allmodconfig build on all 32-bit > > > architectures (I should ask the kernelci maintainers to change that), > > > > I see that Olof's build bot does have build results for arm32 > > allmodconfig, which is also big-endian, and reports the same > > errors that I described in the patch changelog. > > > > See > > > > http://arm-soc.lixom.net/buildlogs/arm-soc/v4.16-rc4-25-g41c42fe/ > > http://arm-soc.lixom.net/buildlogs/arm-soc/v4.16-rc4-25-g41c42fe/buildall.arm.allmodconfig.log.passed > > > > for today's results. > > > > This bot reports one other warning for arm32, but it's > > specific to the toolchain version used on that bot. > > I have a fix for that one as well, but there was some > > discussion on what the best approach would be. > > Any update on this? This is now the only remaining gcc warning we get on > allmodconfig builds for arm (both 32-bit and 64-bit) in linux-4.16-rc. > > > Arnd Do you need the full series to fix this (it looked that way to me)?
On Wed, Mar 14, 2018 at 9:03 PM, Doug Ledford <dledford@redhat.com> wrote: > On Tue, 2018-03-13 at 09:50 +0100, Arnd Bergmann wrote: >> On Wed, Mar 7, 2018 at 11:12 AM, Arnd Bergmann <arnd@arndb.de> wrote: >> > On Wed, Mar 7, 2018 at 10:05 AM, Arnd Bergmann <arnd@arndb.de> wrote: >> > >> > > A small complication is that I wrote the changelog for the build warning >> > > on 32-bit architectures, which is more elaborate. kernelci.org for >> > > some reasons currently skips the allmodconfig build on all 32-bit >> > > architectures (I should ask the kernelci maintainers to change that), >> > >> > I see that Olof's build bot does have build results for arm32 >> > allmodconfig, which is also big-endian, and reports the same >> > errors that I described in the patch changelog. >> > >> > See >> > >> > http://arm-soc.lixom.net/buildlogs/arm-soc/v4.16-rc4-25-g41c42fe/ >> > http://arm-soc.lixom.net/buildlogs/arm-soc/v4.16-rc4-25-g41c42fe/buildall.arm.allmodconfig.log.passed >> > >> > for today's results. >> > >> > This bot reports one other warning for arm32, but it's >> > specific to the toolchain version used on that bot. >> > I have a fix for that one as well, but there was some >> > discussion on what the best approach would be. >> >> Any update on this? This is now the only remaining gcc warning we get on >> allmodconfig builds for arm (both 32-bit and 64-bit) in linux-4.16-rc. >> > > Do you need the full series to fix this (it looked that way to me)? I just double-checked, as I thought only the first one was needed, but indeed we do need both. Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wed, 2018-03-14 at 21:16 +0100, Arnd Bergmann wrote: > On Wed, Mar 14, 2018 at 9:03 PM, Doug Ledford <dledford@redhat.com> wrote: > > On Tue, 2018-03-13 at 09:50 +0100, Arnd Bergmann wrote: > > > On Wed, Mar 7, 2018 at 11:12 AM, Arnd Bergmann <arnd@arndb.de> wrote: > > > > On Wed, Mar 7, 2018 at 10:05 AM, Arnd Bergmann <arnd@arndb.de> wrote: > > > > > > > > > A small complication is that I wrote the changelog for the build warning > > > > > on 32-bit architectures, which is more elaborate. kernelci.org for > > > > > some reasons currently skips the allmodconfig build on all 32-bit > > > > > architectures (I should ask the kernelci maintainers to change that), > > > > > > > > I see that Olof's build bot does have build results for arm32 > > > > allmodconfig, which is also big-endian, and reports the same > > > > errors that I described in the patch changelog. > > > > > > > > See > > > > > > > > http://arm-soc.lixom.net/buildlogs/arm-soc/v4.16-rc4-25-g41c42fe/ > > > > http://arm-soc.lixom.net/buildlogs/arm-soc/v4.16-rc4-25-g41c42fe/buildall.arm.allmodconfig.log.passed > > > > > > > > for today's results. > > > > > > > > This bot reports one other warning for arm32, but it's > > > > specific to the toolchain version used on that bot. > > > > I have a fix for that one as well, but there was some > > > > discussion on what the best approach would be. > > > > > > Any update on this? This is now the only remaining gcc warning we get on > > > allmodconfig builds for arm (both 32-bit and 64-bit) in linux-4.16-rc. > > > > > > > Do you need the full series to fix this (it looked that way to me)? > > I just double-checked, as I thought only the first one was needed, but > indeed we do need both. Hi Linus, Arnd sent in a two patch series and it got put into our for-next branch. But, the two patches are the *only* two remaining issues for the arm builds on the kernelci system. They would like to get this into for-rc so that the build failures stop. Are you OK with me just cherry-picking them from for-next to for-rc so I can send them to you? They'll show as duplicates in the next merge window, but should drop silently.
On Wed, Mar 14, 2018 at 1:28 PM, Doug Ledford <dledford@redhat.com> wrote: > > Arnd sent in a two patch series and it got put into our for-next branch. > But, the two patches are the *only* two remaining issues for the arm > builds on the kernelci system. They would like to get this into for-rc > so that the build failures stop. Are you OK with me just cherry-picking > them from for-next to for-rc so I can send them to you? They'll show as > duplicates in the next merge window, but should drop silently. Go ahead, assuming there are no other planned changes around them that would cause potential pointless merge problems.. Linus -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wed, 2018-03-14 at 13:31 -0700, Linus Torvalds wrote: > On Wed, Mar 14, 2018 at 1:28 PM, Doug Ledford <dledford@redhat.com> wrote: > > > > Arnd sent in a two patch series and it got put into our for-next branch. > > But, the two patches are the *only* two remaining issues for the arm > > builds on the kernelci system. They would like to get this into for-rc > > so that the build failures stop. Are you OK with me just cherry-picking > > them from for-next to for-rc so I can send them to you? They'll show as > > duplicates in the next merge window, but should drop silently. > > Go ahead, assuming there are no other planned changes around them that > would cause potential pointless merge problems.. These two patches will be fine in that regard. They aren't in the area where all the syzkaller bugs have been getting fixed. But I need to merge for-rc into for-next because of all of the syzkaller bugs being fixed. We are running into a situation where code updates that were planned are in areas where syzkaller bugs have been fixed and there would be significant merge conflicts if I didn't. So, the plan as it stands is: get the needed patches in for-rc, merge for-rc to for-next, then cherry pick from for-next to for-rc just the two patches here (since I have no idea how cherry picking to for-rc and then merging for- rc to for-next would play out, I'm just not gonna try it). It's a bit convoluted, but as long as I don't use my standard git request pull macro when generating the pull request (it will pick the wrong merge base every time whenever you've merged for-rc into for-next, you have to manually find the alternate merge base and use the right one for git request pull) it comes out nicely in the end.
diff --git a/drivers/infiniband/hw/bnxt_re/qplib_fp.c b/drivers/infiniband/hw/bnxt_re/qplib_fp.c index 1b0e94697fe3..9885d7d428e3 100644 --- a/drivers/infiniband/hw/bnxt_re/qplib_fp.c +++ b/drivers/infiniband/hw/bnxt_re/qplib_fp.c @@ -283,7 +283,7 @@ static void bnxt_qplib_service_nq(unsigned long data) u32 sw_cons, raw_cons; u16 type; int budget = nq->budget; - u64 q_handle; + uintptr_t q_handle; /* Service the NQ until empty */ raw_cons = hwq->cons; @@ -566,7 +566,7 @@ int bnxt_qplib_create_srq(struct bnxt_qplib_res *res, /* Configure the request */ req.dpi = cpu_to_le32(srq->dpi->dpi); - req.srq_handle = cpu_to_le64(srq); + req.srq_handle = cpu_to_le64((uintptr_t)srq); req.srq_size = cpu_to_le16((u16)srq->hwq.max_elements); pbl = &srq->hwq.pbl[PBL_LVL_0];
Building for a 32-bit target results in a couple of warnings from casting between a 32-bit pointer and a 64-bit integer: drivers/infiniband/hw/bnxt_re/qplib_fp.c: In function 'bnxt_qplib_service_nq': drivers/infiniband/hw/bnxt_re/qplib_fp.c:333:23: error: cast to pointer from integer of different size [-Werror=int-to-pointer-cast] bnxt_qplib_arm_srq((struct bnxt_qplib_srq *)q_handle, ^ drivers/infiniband/hw/bnxt_re/qplib_fp.c:336:12: error: cast to pointer from integer of different size [-Werror=int-to-pointer-cast] (struct bnxt_qplib_srq *)q_handle, ^ In file included from include/linux/byteorder/little_endian.h:5, from arch/arm/include/uapi/asm/byteorder.h:22, from include/asm-generic/bitops/le.h:6, from arch/arm/include/asm/bitops.h:342, from include/linux/bitops.h:38, from include/linux/kernel.h:11, from include/linux/interrupt.h:6, from drivers/infiniband/hw/bnxt_re/qplib_fp.c:39: drivers/infiniband/hw/bnxt_re/qplib_fp.c: In function 'bnxt_qplib_create_srq': include/uapi/linux/byteorder/little_endian.h:31:43: error: cast from pointer to integer of different size [-Werror=pointer-to-int-cast] #define __cpu_to_le64(x) ((__force __le64)(__u64)(x)) ^ include/linux/byteorder/generic.h:86:21: note: in expansion of macro '__cpu_to_le64' #define cpu_to_le64 __cpu_to_le64 ^~~~~~~~~~~~~ drivers/infiniband/hw/bnxt_re/qplib_fp.c:569:19: note: in expansion of macro 'cpu_to_le64' req.srq_handle = cpu_to_le64(srq); Using a uintptr_t as an intermediate works on all architectures. Fixes: 37cb11acf1f7 ("RDMA/bnxt_re: Add SRQ support for Broadcom adapters") Signed-off-by: Arnd Bergmann <arnd@arndb.de> --- drivers/infiniband/hw/bnxt_re/qplib_fp.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)