| Message ID | 20180220205638.1959033-1-arnd@arndb.de |
|---|---|
| State | Accepted |
| Commit | 5388a508479d8b7e6d24fe5ca2645806d8e3d0f1 |
| Headers | show |
| Series | [1/2] infiniband: qplib_fp: fix pointer cast | expand |
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
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
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
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
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
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
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)? -- Doug Ledford <dledford@redhat.com> GPG KeyID: B826A3330E572FDD Key fingerprint = AE6B 1BDA 122B 23B4 265B 1274 B826 A333 0E57 2FDD
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
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. -- Doug Ledford <dledford@redhat.com> GPG KeyID: B826A3330E572FDD Key fingerprint = AE6B 1BDA 122B 23B4 265B 1274 B826 A333 0E57 2FDD
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
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. -- Doug Ledford <dledford@redhat.com> GPG KeyID: B826A3330E572FDD Key fingerprint = AE6B 1BDA 122B 23B4 265B 1274 B826 A333 0E57 2FDD
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(-) -- 2.9.0