[PATCH 2/3] RDMA/hfi1, rdmavt: open-code rvt_set_ibdev_name()

[PATCH 2/3] RDMA/hfi1, rdmavt: open-code rvt_set_ibdev_name()

[Arnd Bergmann]

From: Arnd Bergmann <arnd@arndb.de>

clang warns about a function missing a printf attribute:

include/rdma/rdma_vt.h:457:47: error: diagnostic behavior may be improved by adding the 'format(printf, 2, 3)' attribute to the declaration of 'rvt_set_ibdev_name' [-Werror,-Wmissing-format-attribute]
  447 | static inline void rvt_set_ibdev_name(struct rvt_dev_info *rdi,
      | __attribute__((format(printf, 2, 3)))
  448 |                                       const char *fmt, const char *name,
  449 |                                       const int unit)

The helper was originally added as an abstraction for the hfi1 and
qib drivers needing the same thing, but now qib is gone, and hfi1
is the only remaining user of rdma_vt.

Avoid the warning and allow the compiler to check the format string by
open-coding the helper and directly assigning the device name.

Fixes: 5084c8ff21f2 ("IB/{rdmavt, hfi1, qib}: Self determine driver name")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
 drivers/infiniband/hw/hfi1/init.c | 13 ++++++++++++-
 include/rdma/rdma_vt.h            | 20 --------------------
 2 files changed, 12 insertions(+), 21 deletions(-)

diff --git a/drivers/infiniband/hw/hfi1/init.c b/drivers/infiniband/hw/hfi1/init.c
index 8b5a5b32b0fa..fb0a8325a43d 100644
--- a/drivers/infiniband/hw/hfi1/init.c
+++ b/drivers/infiniband/hw/hfi1/init.c
@@ -1206,6 +1206,7 @@ static struct hfi1_devdata *hfi1_alloc_devdata(struct pci_dev *pdev,
 					       size_t extra)
 {
 	struct hfi1_devdata *dd;
+	struct ib_device *ibdev;
 	int ret, nports;
 
 	/* extra is * number of ports */
@@ -1227,7 +1228,17 @@ static struct hfi1_devdata *hfi1_alloc_devdata(struct pci_dev *pdev,
 			"Could not allocate unit ID: error %d\n", -ret);
 		goto bail;
 	}
-	rvt_set_ibdev_name(&dd->verbs_dev.rdi, "%s_%d", class_name(), dd->unit);
+
+	/*
+	 * FIXME: rvt and its users want to touch the ibdev before
+	 * registration and have things like the name work. We don't have the
+	 * infrastructure in the core to support this directly today, hack it
+	 * to work by setting the name manually here.
+	 */
+	ibdev = &dd->verbs_dev.rdi.ibdev;
+	dev_set_name(&ibdev->dev, "%s_%d", class_name(), dd->unit);
+	strscpy(&ibdev->name, dev_name(&ibdev->dev), IB_DEVICE_NAME_MAX);
+
 	/*
 	 * If the BIOS does not have the NUMA node information set, select
 	 * NUMA 0 so we get consistent performance.
diff --git a/include/rdma/rdma_vt.h b/include/rdma/rdma_vt.h
index 7d8de561f71b..7ffc83262a01 100644
--- a/include/rdma/rdma_vt.h
+++ b/include/rdma/rdma_vt.h
@@ -438,26 +438,6 @@ struct rvt_dev_info {
 	struct rvt_wss *wss;
 };
 
-/**
- * rvt_set_ibdev_name - Craft an IB device name from client info
- * @rdi: pointer to the client rvt_dev_info structure
- * @name: client specific name
- * @unit: client specific unit number.
- */
-static inline void rvt_set_ibdev_name(struct rvt_dev_info *rdi,
-				      const char *fmt, const char *name,
-				      const int unit)
-{
-	/*
-	 * FIXME: rvt and its users want to touch the ibdev before
-	 * registration and have things like the name work. We don't have the
-	 * infrastructure in the core to support this directly today, hack it
-	 * to work by setting the name manually here.
-	 */
-	dev_set_name(&rdi->ibdev.dev, fmt, name, unit);
-	strscpy(rdi->ibdev.name, dev_name(&rdi->ibdev.dev), IB_DEVICE_NAME_MAX);
-}
-
 /**
  * rvt_get_ibdev_name - return the IB name
  * @rdi: rdmavt device
-- 
2.39.5

Re: [PATCH 2/3] RDMA/hfi1, rdmavt: open-code rvt_set_ibdev_name()

[Arnd Bergmann]

On Fri, Mar 20, 2026, at 16:12, Arnd Bergmann wrote:

> +	 */
> +	ibdev = &dd->verbs_dev.rdi.ibdev;
> +	dev_set_name(&ibdev->dev, "%s_%d", class_name(), dd->unit);
> +	strscpy(&ibdev->name, dev_name(&ibdev->dev), IB_DEVICE_NAME_MAX);
> +

I messed this up during a rebase, that should have been 

       strscpy(ibdev->name, dev_name(&ibdev->dev), IB_DEVICE_NAME_MAX);

(without the extra &). I'll wait for comments before resending.

       Arnd

Re: [PATCH 2/3] RDMA/hfi1, rdmavt: open-code rvt_set_ibdev_name()

[Leon Romanovsky]

On Fri, Mar 20, 2026 at 04:53:04PM +0100, Arnd Bergmann wrote:
> On Fri, Mar 20, 2026, at 16:12, Arnd Bergmann wrote:
> 
> > +	 */
> > +	ibdev = &dd->verbs_dev.rdi.ibdev;
> > +	dev_set_name(&ibdev->dev, "%s_%d", class_name(), dd->unit);
> > +	strscpy(&ibdev->name, dev_name(&ibdev->dev), IB_DEVICE_NAME_MAX);
> > +
> 
> I messed this up during a rebase, that should have been 
> 
>        strscpy(ibdev->name, dev_name(&ibdev->dev), IB_DEVICE_NAME_MAX);
> 
> (without the extra &). I'll wait for comments before resending.

The hfi1 driver is scheduled for removal. Dennis has already posted the
hfi2 driver, which serves as its replacement.

Thanks

> 
>        Arnd
> 

Re: [PATCH 2/3] RDMA/hfi1, rdmavt: open-code rvt_set_ibdev_name()

[Arnd Bergmann]

On Mon, Mar 23, 2026, at 09:08, Leon Romanovsky wrote:
> On Fri, Mar 20, 2026 at 04:53:04PM +0100, Arnd Bergmann wrote:
>> On Fri, Mar 20, 2026, at 16:12, Arnd Bergmann wrote:
>> 
>> > +	 */
>> > +	ibdev = &dd->verbs_dev.rdi.ibdev;
>> > +	dev_set_name(&ibdev->dev, "%s_%d", class_name(), dd->unit);
>> > +	strscpy(&ibdev->name, dev_name(&ibdev->dev), IB_DEVICE_NAME_MAX);
>> > +
>> 
>> I messed this up during a rebase, that should have been 
>> 
>>        strscpy(ibdev->name, dev_name(&ibdev->dev), IB_DEVICE_NAME_MAX);
>> 
>> (without the extra &). I'll wait for comments before resending.
>
> The hfi1 driver is scheduled for removal. Dennis has already posted the
> hfi2 driver, which serves as its replacement.

Ok, that does sound like a sensible decision, and I'll just drop
patches 1 and 3 then, which are just cleanups.

The cover letter at [1] suggests that the two drivers will still
coexist for a bit though, so I think we'd still want patch 2/3
in order to get a clean 'allmodconfig' build when the 
-Wmissing-format-attribute is enabled by defaultt. I have a couple
of patches in flight.

I took a quick look at the hfi2 driver, and noticed a few things
that that may be worth addressing before it gets merged, mostly
stuff copied from hfi1:

- A few global functions with questionable namespacing:
  user_event_ack, ctxt_reset, iowait_init, register_pinning_interface,
  sc_{alloc,free,enable,disable}, pio_copy, acquire_hw_mutex,
  load_firmware, cap_mask.
  It would make sense to prefix all global identifiers with 'hfi2_',
  both out of principle, and to allow building hfi1 and hfi2 into
  an allyesconfig kernel without link failures.

- The use of INFINIBAND_RDMAVT seems unnecessary: right now
  this is only used by hfi1, now shared with hfi2 but later to
  be exclusive to the latter. Since it is unlikely to ever
  be used by another driver again, this may be a good time
  to drop the abstraction again and integrate it all into
  hfi2, with the old version getting dropped along with hfi1.

- The pio_copy() function is particularly slow since it uses
  the full-barrier version of writeq() in a tight loop,
  this should probably use __iowrite64_copy() etc to make it
  work better on arm64 and other architectures

- The use of bitfields in drivers/infiniband/hw/hfi2/cport.h
  makes the structures nonportable especially for big-endian
  targets, if those describe device interfaces. Similarly
  the use of __packed attributes in the same file seems
  arbitrary and inconsistent, to the point where it
  is likely to cause more harm than it can help. E.g.
  in

+struct ib_cc_table_entry_shadow {
+	u16 entry; /* shift:2, multiplier:14 */
+};
+
>
+struct ib_cc_table_attr_shadow {
+	u16 ccti_limit; /* max CCTI for cc table */
+	struct ib_cc_table_entry_shadow ccti_entries[IB_CCT_ENTRIES];
+} __packed;

  the outer structure is unaligned while the inner one requires
  alignment.


     Arnd

[1] https://lore.kernel.org/all/177325138778.57064.8330693913074464417.stgit@awdrv-04.cornelisnetworks.com/

Re: [PATCH 2/3] RDMA/hfi1, rdmavt: open-code rvt_set_ibdev_name()

[Leon Romanovsky]

On Mon, Mar 23, 2026 at 09:48:59AM +0100, Arnd Bergmann wrote:
> On Mon, Mar 23, 2026, at 09:08, Leon Romanovsky wrote:
> > On Fri, Mar 20, 2026 at 04:53:04PM +0100, Arnd Bergmann wrote:
> >> On Fri, Mar 20, 2026, at 16:12, Arnd Bergmann wrote:
> >> 
> >> > +	 */
> >> > +	ibdev = &dd->verbs_dev.rdi.ibdev;
> >> > +	dev_set_name(&ibdev->dev, "%s_%d", class_name(), dd->unit);
> >> > +	strscpy(&ibdev->name, dev_name(&ibdev->dev), IB_DEVICE_NAME_MAX);
> >> > +
> >> 
> >> I messed this up during a rebase, that should have been 
> >> 
> >>        strscpy(ibdev->name, dev_name(&ibdev->dev), IB_DEVICE_NAME_MAX);
> >> 
> >> (without the extra &). I'll wait for comments before resending.
> >
> > The hfi1 driver is scheduled for removal. Dennis has already posted the
> > hfi2 driver, which serves as its replacement.
> 
> Ok, that does sound like a sensible decision, and I'll just drop
> patches 1 and 3 then, which are just cleanups.
> 
> The cover letter at [1] suggests that the two drivers will still
> coexist for a bit though, so I think we'd still want patch 2/3
> in order to get a clean 'allmodconfig' build when the 
> -Wmissing-format-attribute is enabled by defaultt. I have a couple
> of patches in flight.

Sure, builds need to be fixed.

> 
> I took a quick look at the hfi2 driver, and noticed a few things
> that that may be worth addressing before it gets merged, mostly
> stuff copied from hfi1:
> 
> - A few global functions with questionable namespacing:
>   user_event_ack, ctxt_reset, iowait_init, register_pinning_interface,
>   sc_{alloc,free,enable,disable}, pio_copy, acquire_hw_mutex,
>   load_firmware, cap_mask.
>   It would make sense to prefix all global identifiers with 'hfi2_',
>   both out of principle, and to allow building hfi1 and hfi2 into
>   an allyesconfig kernel without link failures.
> 
> - The use of INFINIBAND_RDMAVT seems unnecessary: right now
>   this is only used by hfi1, now shared with hfi2 but later to
>   be exclusive to the latter. Since it is unlikely to ever
>   be used by another driver again, this may be a good time
>   to drop the abstraction again and integrate it all into
>   hfi2, with the old version getting dropped along with hfi1.

The best approach is to drop rdmavt as well, since hfi2 is expected to
align with the other drivers in drivers/infiniband/hw.

Dennis, is this feasible?

Thanks

Re: [PATCH 2/3] RDMA/hfi1, rdmavt: open-code rvt_set_ibdev_name()

[Dennis Dalessandro]

On 3/23/26 7:01 AM, Leon Romanovsky wrote:
> On Mon, Mar 23, 2026 at 09:48:59AM +0100, Arnd Bergmann wrote:
>> On Mon, Mar 23, 2026, at 09:08, Leon Romanovsky wrote:
>>> On Fri, Mar 20, 2026 at 04:53:04PM +0100, Arnd Bergmann wrote:
>>>> On Fri, Mar 20, 2026, at 16:12, Arnd Bergmann wrote:
>>>>
>>>>> +	 */
>>>>> +	ibdev = &dd->verbs_dev.rdi.ibdev;
>>>>> +	dev_set_name(&ibdev->dev, "%s_%d", class_name(), dd->unit);
>>>>> +	strscpy(&ibdev->name, dev_name(&ibdev->dev), IB_DEVICE_NAME_MAX);
>>>>> +
>>>>
>>>> I messed this up during a rebase, that should have been
>>>>
>>>>         strscpy(ibdev->name, dev_name(&ibdev->dev), IB_DEVICE_NAME_MAX);
>>>>
>>>> (without the extra &). I'll wait for comments before resending.
>>>
>>> The hfi1 driver is scheduled for removal. Dennis has already posted the
>>> hfi2 driver, which serves as its replacement.
>>
>> Ok, that does sound like a sensible decision, and I'll just drop
>> patches 1 and 3 then, which are just cleanups.
>>
>> The cover letter at [1] suggests that the two drivers will still
>> coexist for a bit though, so I think we'd still want patch 2/3
>> in order to get a clean 'allmodconfig' build when the
>> -Wmissing-format-attribute is enabled by defaultt. I have a couple
>> of patches in flight.
> 
> Sure, builds need to be fixed.
> 
>>
>> I took a quick look at the hfi2 driver, and noticed a few things
>> that that may be worth addressing before it gets merged, mostly
>> stuff copied from hfi1:
>>
>> - A few global functions with questionable namespacing:
>>    user_event_ack, ctxt_reset, iowait_init, register_pinning_interface,
>>    sc_{alloc,free,enable,disable}, pio_copy, acquire_hw_mutex,
>>    load_firmware, cap_mask.
>>    It would make sense to prefix all global identifiers with 'hfi2_',
>>    both out of principle, and to allow building hfi1 and hfi2 into
>>    an allyesconfig kernel without link failures.
>>
>> - The use of INFINIBAND_RDMAVT seems unnecessary: right now
>>    this is only used by hfi1, now shared with hfi2 but later to
>>    be exclusive to the latter. Since it is unlikely to ever
>>    be used by another driver again, this may be a good time
>>    to drop the abstraction again and integrate it all into
>>    hfi2, with the old version getting dropped along with hfi1.
> 
> The best approach is to drop rdmavt as well, since hfi2 is expected to
> align with the other drivers in drivers/infiniband/hw.
> 
> Dennis, is this feasible?

Feasible yes. I'd like to get hfi2 crossed off the list and in the tree 
first though. Then come back and do that. I'd like to do more than just 
plop rdmavt inside hfi2 and call it a day. There is a lot of code 
cleanup/simplification that we can do.

-Denny

Re: [PATCH 2/3] RDMA/hfi1, rdmavt: open-code rvt_set_ibdev_name()

[Arnd Bergmann]

On Mon, Mar 23, 2026, at 22:47, Dennis Dalessandro wrote:
> On 3/23/26 7:01 AM, Leon Romanovsky wrote:
>> On Mon, Mar 23, 2026 at 09:48:59AM +0100, Arnd Bergmann wrote:
>>> - The use of INFINIBAND_RDMAVT seems unnecessary: right now
>>>    this is only used by hfi1, now shared with hfi2 but later to
>>>    be exclusive to the latter. Since it is unlikely to ever
>>>    be used by another driver again, this may be a good time
>>>    to drop the abstraction again and integrate it all into
>>>    hfi2, with the old version getting dropped along with hfi1.
>> 
>> The best approach is to drop rdmavt as well, since hfi2 is expected to
>> align with the other drivers in drivers/infiniband/hw.
>> 
>> Dennis, is this feasible?
>
> Feasible yes. I'd like to get hfi2 crossed off the list and in the tree 
> first though. Then come back and do that. I'd like to do more than just 
> plop rdmavt inside hfi2 and call it a day. There is a lot of code 
> cleanup/simplification that we can do.

Does rdmavt have its own user-space ABI? If there is anything that
you'd want to change, this might be the one chance to do it, otherwise
I see nothing wrong with integrating it only after hfi1 is gone.

      Arnd

Re: [PATCH 2/3] RDMA/hfi1, rdmavt: open-code rvt_set_ibdev_name()

[Leon Romanovsky]

On Tue, Mar 24, 2026 at 08:27:45AM +0100, Arnd Bergmann wrote:
> On Mon, Mar 23, 2026, at 22:47, Dennis Dalessandro wrote:
> > On 3/23/26 7:01 AM, Leon Romanovsky wrote:
> >> On Mon, Mar 23, 2026 at 09:48:59AM +0100, Arnd Bergmann wrote:
> >>> - The use of INFINIBAND_RDMAVT seems unnecessary: right now
> >>>    this is only used by hfi1, now shared with hfi2 but later to
> >>>    be exclusive to the latter. Since it is unlikely to ever
> >>>    be used by another driver again, this may be a good time
> >>>    to drop the abstraction again and integrate it all into
> >>>    hfi2, with the old version getting dropped along with hfi1.
> >> 
> >> The best approach is to drop rdmavt as well, since hfi2 is expected to
> >> align with the other drivers in drivers/infiniband/hw.
> >> 
> >> Dennis, is this feasible?
> >
> > Feasible yes. I'd like to get hfi2 crossed off the list and in the tree 
> > first though. Then come back and do that. I'd like to do more than just 
> > plop rdmavt inside hfi2 and call it a day. There is a lot of code 
> > cleanup/simplification that we can do.
> 
> Does rdmavt have its own user-space ABI? If there is anything that
> you'd want to change, this might be the one chance to do it, otherwise
> I see nothing wrong with integrating it only after hfi1 is gone.

rdmavt has no user‑space exposure. It is a leftover from an old and never
fully realized idea to provide a shim and common layer for RDMA drivers
that require software handling in their data path.

Thanks

> 
>       Arnd

Re: [PATCH 2/3] RDMA/hfi1, rdmavt: open-code rvt_set_ibdev_name()

[Leon Romanovsky]

On Mon, Mar 23, 2026 at 05:47:43PM -0400, Dennis Dalessandro wrote:
> 
> 
> On 3/23/26 7:01 AM, Leon Romanovsky wrote:
> > On Mon, Mar 23, 2026 at 09:48:59AM +0100, Arnd Bergmann wrote:
> > > On Mon, Mar 23, 2026, at 09:08, Leon Romanovsky wrote:
> > > > On Fri, Mar 20, 2026 at 04:53:04PM +0100, Arnd Bergmann wrote:
> > > > > On Fri, Mar 20, 2026, at 16:12, Arnd Bergmann wrote:
> > > > > 
> > > > > > +	 */
> > > > > > +	ibdev = &dd->verbs_dev.rdi.ibdev;
> > > > > > +	dev_set_name(&ibdev->dev, "%s_%d", class_name(), dd->unit);
> > > > > > +	strscpy(&ibdev->name, dev_name(&ibdev->dev), IB_DEVICE_NAME_MAX);
> > > > > > +
> > > > > 
> > > > > I messed this up during a rebase, that should have been
> > > > > 
> > > > >         strscpy(ibdev->name, dev_name(&ibdev->dev), IB_DEVICE_NAME_MAX);
> > > > > 
> > > > > (without the extra &). I'll wait for comments before resending.
> > > > 
> > > > The hfi1 driver is scheduled for removal. Dennis has already posted the
> > > > hfi2 driver, which serves as its replacement.
> > > 
> > > Ok, that does sound like a sensible decision, and I'll just drop
> > > patches 1 and 3 then, which are just cleanups.
> > > 
> > > The cover letter at [1] suggests that the two drivers will still
> > > coexist for a bit though, so I think we'd still want patch 2/3
> > > in order to get a clean 'allmodconfig' build when the
> > > -Wmissing-format-attribute is enabled by defaultt. I have a couple
> > > of patches in flight.
> > 
> > Sure, builds need to be fixed.
> > 
> > > 
> > > I took a quick look at the hfi2 driver, and noticed a few things
> > > that that may be worth addressing before it gets merged, mostly
> > > stuff copied from hfi1:
> > > 
> > > - A few global functions with questionable namespacing:
> > >    user_event_ack, ctxt_reset, iowait_init, register_pinning_interface,
> > >    sc_{alloc,free,enable,disable}, pio_copy, acquire_hw_mutex,
> > >    load_firmware, cap_mask.
> > >    It would make sense to prefix all global identifiers with 'hfi2_',
> > >    both out of principle, and to allow building hfi1 and hfi2 into
> > >    an allyesconfig kernel without link failures.
> > > 
> > > - The use of INFINIBAND_RDMAVT seems unnecessary: right now
> > >    this is only used by hfi1, now shared with hfi2 but later to
> > >    be exclusive to the latter. Since it is unlikely to ever
> > >    be used by another driver again, this may be a good time
> > >    to drop the abstraction again and integrate it all into
> > >    hfi2, with the old version getting dropped along with hfi1.
> > 
> > The best approach is to drop rdmavt as well, since hfi2 is expected to
> > align with the other drivers in drivers/infiniband/hw.
> > 
> > Dennis, is this feasible?
> 
> Feasible yes. I'd like to get hfi2 crossed off the list and in the tree
> first though. Then come back and do that. I'd like to do more than just plop
> rdmavt inside hfi2 and call it a day. There is a lot of code
> cleanup/simplification that we can do.

So let's add a TODO file under drivers/infiniband/hw/hfi2 to track these
future improvements.

Thanks

> 
> -Denny
> 

Re: [PATCH 2/3] RDMA/hfi1, rdmavt: open-code rvt_set_ibdev_name()

[Dennis Dalessandro]

On 3/23/26 4:48 AM, Arnd Bergmann wrote:
> I took a quick look at the hfi2 driver, and noticed a few things
> that that may be worth addressing before it gets merged, mostly
> stuff copied from hfi1:
> 
> - A few global functions with questionable namespacing:
>    user_event_ack, ctxt_reset, iowait_init, register_pinning_interface,
>    sc_{alloc,free,enable,disable}, pio_copy, acquire_hw_mutex,
>    load_firmware, cap_mask.
>    It would make sense to prefix all global identifiers with 'hfi2_',
>    both out of principle, and to allow building hfi1 and hfi2 into
>    an allyesconfig kernel without link failures.

Will address that stuff.

> - The use of INFINIBAND_RDMAVT seems unnecessary: right now
>    this is only used by hfi1, now shared with hfi2 but later to
>    be exclusive to the latter. Since it is unlikely to ever
>    be used by another driver again, this may be a good time
>    to drop the abstraction again and integrate it all into
>    hfi2, with the old version getting dropped along with hfi1.

Replied about RDMAVT stuff separately. Perhaps when we target removal of 
hfi1 that would be the time to get RDMAVT re-incorporated into the main 
hfi (hfi2) driver.

> 
> - The pio_copy() function is particularly slow since it uses
>    the full-barrier version of writeq() in a tight loop,
>    this should probably use __iowrite64_copy() etc to make it
>    work better on arm64 and other architectures

Will certainly look into this. Thanks for pointing it out.


> - The use of bitfields in drivers/infiniband/hw/hfi2/cport.h
>    makes the structures nonportable especially for big-endian
>    targets, if those describe device interfaces. Similarly
>    the use of __packed attributes in the same file seems
>    arbitrary and inconsistent, to the point where it
>    is likely to cause more harm than it can help. E.g.
>    in

Actually have a patch that addresses some of that. It's coming. We had 
previously only built on x86_64 but have plans to change that.


> +struct ib_cc_table_entry_shadow {
> +	u16 entry; /* shift:2, multiplier:14 */
> +};
> +
>>
> +struct ib_cc_table_attr_shadow {
> +	u16 ccti_limit; /* max CCTI for cc table */
> +	struct ib_cc_table_entry_shadow ccti_entries[IB_CCT_ENTRIES];
> +} __packed;
> 
>    the outer structure is unaligned while the inner one requires
>    alignment.
> 

Will take care of that one too.


-Denny

Re: [PATCH 2/3] RDMA/hfi1, rdmavt: open-code rvt_set_ibdev_name()

[kernel test robot]

Hi Arnd,

kernel test robot noticed the following build errors:

[auto build test ERROR on rdma/for-next]
[also build test ERROR on soc/for-next linus/master v7.0-rc4 next-20260320]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]

url:    https://github.com/intel-lab-lkp/linux/commits/Arnd-Bergmann/RDMA-hfi1-rdmavt-open-code-rvt_set_ibdev_name/20260322-190924
base:   https://git.kernel.org/pub/scm/linux/kernel/git/rdma/rdma.git for-next
patch link:    https://lore.kernel.org/r/20260320151511.3420818-2-arnd%40kernel.org
patch subject: [PATCH 2/3] RDMA/hfi1, rdmavt: open-code rvt_set_ibdev_name()
config: x86_64-rhel-9.4-ltp (https://download.01.org/0day-ci/archive/20260322/202603221954.LIO9WBor-lkp@intel.com/config)
compiler: gcc-14 (Debian 14.2.0-19) 14.2.0
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20260322/202603221954.LIO9WBor-lkp@intel.com/reproduce)

If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202603221954.LIO9WBor-lkp@intel.com/

All errors (new ones prefixed by >>):

   In file included from include/linux/uuid.h:11,
                    from include/linux/mod_devicetable.h:14,
                    from include/linux/pci.h:27,
                    from drivers/infiniband/hw/hfi1/init.c:7:
   drivers/infiniband/hw/hfi1/init.c: In function 'hfi1_alloc_devdata':
>> drivers/infiniband/hw/hfi1/init.c:1240:17: error: passing argument 1 of 'sized_strscpy' from incompatible pointer type [-Wincompatible-pointer-types]
    1240 |         strscpy(&ibdev->name, dev_name(&ibdev->dev), IB_DEVICE_NAME_MAX);
         |                 ^~~~~~~~~~~~
         |                 |
         |                 char (*)[64]
   include/linux/string.h:83:23: note: in definition of macro '__strscpy1'
      83 |         sized_strscpy(dst, src, size + __must_be_cstr(dst) + __must_be_cstr(src))
         |                       ^~~
   drivers/infiniband/hw/hfi1/init.c:1240:9: note: in expansion of macro 'strscpy'
    1240 |         strscpy(&ibdev->name, dev_name(&ibdev->dev), IB_DEVICE_NAME_MAX);
         |         ^~~~~~~
   In file included from include/linux/string.h:386:
   include/linux/fortify-string.h:275:57: note: expected 'char *' but argument is of type 'char (*)[64]'
     275 | __FORTIFY_INLINE ssize_t sized_strscpy(char * const POS p, const char * const POS q, size_t size)
         |                                        ~~~~~~~~~~~~~~~~~^


vim +/sized_strscpy +1240 drivers/infiniband/hw/hfi1/init.c

  1195	
  1196	/**
  1197	 * hfi1_alloc_devdata - Allocate our primary per-unit data structure.
  1198	 * @pdev: Valid PCI device
  1199	 * @extra: How many bytes to alloc past the default
  1200	 *
  1201	 * Must be done via verbs allocator, because the verbs cleanup process
  1202	 * both does cleanup and free of the data structure.
  1203	 * "extra" is for chip-specific data.
  1204	 */
  1205	static struct hfi1_devdata *hfi1_alloc_devdata(struct pci_dev *pdev,
  1206						       size_t extra)
  1207	{
  1208		struct hfi1_devdata *dd;
  1209		struct ib_device *ibdev;
  1210		int ret, nports;
  1211	
  1212		/* extra is * number of ports */
  1213		nports = extra / sizeof(struct hfi1_pportdata);
  1214	
  1215		dd = (struct hfi1_devdata *)rvt_alloc_device(sizeof(*dd) + extra,
  1216							     nports);
  1217		if (!dd)
  1218			return ERR_PTR(-ENOMEM);
  1219		dd->num_pports = nports;
  1220		dd->pport = (struct hfi1_pportdata *)(dd + 1);
  1221		dd->pcidev = pdev;
  1222		pci_set_drvdata(pdev, dd);
  1223	
  1224		ret = xa_alloc_irq(&hfi1_dev_table, &dd->unit, dd, xa_limit_32b,
  1225				GFP_KERNEL);
  1226		if (ret < 0) {
  1227			dev_err(&pdev->dev,
  1228				"Could not allocate unit ID: error %d\n", -ret);
  1229			goto bail;
  1230		}
  1231	
  1232		/*
  1233		 * FIXME: rvt and its users want to touch the ibdev before
  1234		 * registration and have things like the name work. We don't have the
  1235		 * infrastructure in the core to support this directly today, hack it
  1236		 * to work by setting the name manually here.
  1237		 */
  1238		ibdev = &dd->verbs_dev.rdi.ibdev;
  1239		dev_set_name(&ibdev->dev, "%s_%d", class_name(), dd->unit);
> 1240		strscpy(&ibdev->name, dev_name(&ibdev->dev), IB_DEVICE_NAME_MAX);
  1241	
  1242		/*
  1243		 * If the BIOS does not have the NUMA node information set, select
  1244		 * NUMA 0 so we get consistent performance.
  1245		 */
  1246		dd->node = pcibus_to_node(pdev->bus);
  1247		if (dd->node == NUMA_NO_NODE) {
  1248			dd_dev_err(dd, "Invalid PCI NUMA node. Performance may be affected\n");
  1249			dd->node = 0;
  1250		}
  1251	
  1252		/*
  1253		 * Initialize all locks for the device. This needs to be as early as
  1254		 * possible so locks are usable.
  1255		 */
  1256		spin_lock_init(&dd->sc_lock);
  1257		spin_lock_init(&dd->sendctrl_lock);
  1258		spin_lock_init(&dd->rcvctrl_lock);
  1259		spin_lock_init(&dd->uctxt_lock);
  1260		spin_lock_init(&dd->hfi1_diag_trans_lock);
  1261		spin_lock_init(&dd->sc_init_lock);
  1262		spin_lock_init(&dd->dc8051_memlock);
  1263		seqlock_init(&dd->sc2vl_lock);
  1264		spin_lock_init(&dd->sde_map_lock);
  1265		spin_lock_init(&dd->pio_map_lock);
  1266		mutex_init(&dd->dc8051_lock);
  1267		init_waitqueue_head(&dd->event_queue);
  1268		spin_lock_init(&dd->irq_src_lock);
  1269	
  1270		dd->int_counter = alloc_percpu(u64);
  1271		if (!dd->int_counter) {
  1272			ret = -ENOMEM;
  1273			goto bail;
  1274		}
  1275	
  1276		dd->rcv_limit = alloc_percpu(u64);
  1277		if (!dd->rcv_limit) {
  1278			ret = -ENOMEM;
  1279			goto bail;
  1280		}
  1281	
  1282		dd->send_schedule = alloc_percpu(u64);
  1283		if (!dd->send_schedule) {
  1284			ret = -ENOMEM;
  1285			goto bail;
  1286		}
  1287	
  1288		dd->tx_opstats = alloc_percpu(struct hfi1_opcode_stats_perctx);
  1289		if (!dd->tx_opstats) {
  1290			ret = -ENOMEM;
  1291			goto bail;
  1292		}
  1293	
  1294		dd->comp_vect = kzalloc_obj(*dd->comp_vect);
  1295		if (!dd->comp_vect) {
  1296			ret = -ENOMEM;
  1297			goto bail;
  1298		}
  1299	
  1300		/* allocate dummy tail memory for all receive contexts */
  1301		dd->rcvhdrtail_dummy_kvaddr =
  1302			dma_alloc_coherent(&dd->pcidev->dev, sizeof(u64),
  1303					   &dd->rcvhdrtail_dummy_dma, GFP_KERNEL);
  1304		if (!dd->rcvhdrtail_dummy_kvaddr) {
  1305			ret = -ENOMEM;
  1306			goto bail;
  1307		}
  1308	
  1309		atomic_set(&dd->ipoib_rsm_usr_num, 0);
  1310		return dd;
  1311	
  1312	bail:
  1313		hfi1_free_devdata(dd);
  1314		return ERR_PTR(ret);
  1315	}
  1316	

-- 
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki

Re: [PATCH 2/3] RDMA/hfi1, rdmavt: open-code rvt_set_ibdev_name()

[kernel test robot]

Hi Arnd,

kernel test robot noticed the following build errors:

[auto build test ERROR on rdma/for-next]
[also build test ERROR on soc/for-next linus/master v7.0-rc4 next-20260320]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]

url:    https://github.com/intel-lab-lkp/linux/commits/Arnd-Bergmann/RDMA-hfi1-rdmavt-open-code-rvt_set_ibdev_name/20260322-190924
base:   https://git.kernel.org/pub/scm/linux/kernel/git/rdma/rdma.git for-next
patch link:    https://lore.kernel.org/r/20260320151511.3420818-2-arnd%40kernel.org
patch subject: [PATCH 2/3] RDMA/hfi1, rdmavt: open-code rvt_set_ibdev_name()
config: x86_64-rhel-9.4-ltp (https://download.01.org/0day-ci/archive/20260323/202603230416.xS2fE21S-lkp@intel.com/config)
compiler: gcc-14 (Debian 14.2.0-19) 14.2.0
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20260323/202603230416.xS2fE21S-lkp@intel.com/reproduce)

If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202603230416.xS2fE21S-lkp@intel.com/

All errors (new ones prefixed by >>):

   In file included from include/linux/uuid.h:11,
                    from include/linux/mod_devicetable.h:14,
                    from include/linux/pci.h:27,
                    from drivers/infiniband/hw/hfi1/init.c:7:
   drivers/infiniband/hw/hfi1/init.c: In function 'hfi1_alloc_devdata':
>> drivers/infiniband/hw/hfi1/init.c:1240:17: error: passing argument 1 of 'sized_strscpy' from incompatible pointer type [-Wincompatible-pointer-types]
    1240 |         strscpy(&ibdev->name, dev_name(&ibdev->dev), IB_DEVICE_NAME_MAX);
         |                 ^~~~~~~~~~~~
         |                 |
         |                 char (*)[64]
   include/linux/string.h:83:23: note: in definition of macro '__strscpy1'
      83 |         sized_strscpy(dst, src, size + __must_be_cstr(dst) + __must_be_cstr(src))
         |                       ^~~
   drivers/infiniband/hw/hfi1/init.c:1240:9: note: in expansion of macro 'strscpy'
    1240 |         strscpy(&ibdev->name, dev_name(&ibdev->dev), IB_DEVICE_NAME_MAX);
         |         ^~~~~~~
   In file included from include/linux/string.h:386:
   include/linux/fortify-string.h:275:57: note: expected 'char *' but argument is of type 'char (*)[64]'
     275 | __FORTIFY_INLINE ssize_t sized_strscpy(char * const POS p, const char * const POS q, size_t size)
         |                                        ~~~~~~~~~~~~~~~~~^


vim +/sized_strscpy +1240 drivers/infiniband/hw/hfi1/init.c

  1195	
  1196	/**
  1197	 * hfi1_alloc_devdata - Allocate our primary per-unit data structure.
  1198	 * @pdev: Valid PCI device
  1199	 * @extra: How many bytes to alloc past the default
  1200	 *
  1201	 * Must be done via verbs allocator, because the verbs cleanup process
  1202	 * both does cleanup and free of the data structure.
  1203	 * "extra" is for chip-specific data.
  1204	 */
  1205	static struct hfi1_devdata *hfi1_alloc_devdata(struct pci_dev *pdev,
  1206						       size_t extra)
  1207	{
  1208		struct hfi1_devdata *dd;
  1209		struct ib_device *ibdev;
  1210		int ret, nports;
  1211	
  1212		/* extra is * number of ports */
  1213		nports = extra / sizeof(struct hfi1_pportdata);
  1214	
  1215		dd = (struct hfi1_devdata *)rvt_alloc_device(sizeof(*dd) + extra,
  1216							     nports);
  1217		if (!dd)
  1218			return ERR_PTR(-ENOMEM);
  1219		dd->num_pports = nports;
  1220		dd->pport = (struct hfi1_pportdata *)(dd + 1);
  1221		dd->pcidev = pdev;
  1222		pci_set_drvdata(pdev, dd);
  1223	
  1224		ret = xa_alloc_irq(&hfi1_dev_table, &dd->unit, dd, xa_limit_32b,
  1225				GFP_KERNEL);
  1226		if (ret < 0) {
  1227			dev_err(&pdev->dev,
  1228				"Could not allocate unit ID: error %d\n", -ret);
  1229			goto bail;
  1230		}
  1231	
  1232		/*
  1233		 * FIXME: rvt and its users want to touch the ibdev before
  1234		 * registration and have things like the name work. We don't have the
  1235		 * infrastructure in the core to support this directly today, hack it
  1236		 * to work by setting the name manually here.
  1237		 */
  1238		ibdev = &dd->verbs_dev.rdi.ibdev;
  1239		dev_set_name(&ibdev->dev, "%s_%d", class_name(), dd->unit);
> 1240		strscpy(&ibdev->name, dev_name(&ibdev->dev), IB_DEVICE_NAME_MAX);
  1241	
  1242		/*
  1243		 * If the BIOS does not have the NUMA node information set, select
  1244		 * NUMA 0 so we get consistent performance.
  1245		 */
  1246		dd->node = pcibus_to_node(pdev->bus);
  1247		if (dd->node == NUMA_NO_NODE) {
  1248			dd_dev_err(dd, "Invalid PCI NUMA node. Performance may be affected\n");
  1249			dd->node = 0;
  1250		}
  1251	
  1252		/*
  1253		 * Initialize all locks for the device. This needs to be as early as
  1254		 * possible so locks are usable.
  1255		 */
  1256		spin_lock_init(&dd->sc_lock);
  1257		spin_lock_init(&dd->sendctrl_lock);
  1258		spin_lock_init(&dd->rcvctrl_lock);
  1259		spin_lock_init(&dd->uctxt_lock);
  1260		spin_lock_init(&dd->hfi1_diag_trans_lock);
  1261		spin_lock_init(&dd->sc_init_lock);
  1262		spin_lock_init(&dd->dc8051_memlock);
  1263		seqlock_init(&dd->sc2vl_lock);
  1264		spin_lock_init(&dd->sde_map_lock);
  1265		spin_lock_init(&dd->pio_map_lock);
  1266		mutex_init(&dd->dc8051_lock);
  1267		init_waitqueue_head(&dd->event_queue);
  1268		spin_lock_init(&dd->irq_src_lock);
  1269	
  1270		dd->int_counter = alloc_percpu(u64);
  1271		if (!dd->int_counter) {
  1272			ret = -ENOMEM;
  1273			goto bail;
  1274		}
  1275	
  1276		dd->rcv_limit = alloc_percpu(u64);
  1277		if (!dd->rcv_limit) {
  1278			ret = -ENOMEM;
  1279			goto bail;
  1280		}
  1281	
  1282		dd->send_schedule = alloc_percpu(u64);
  1283		if (!dd->send_schedule) {
  1284			ret = -ENOMEM;
  1285			goto bail;
  1286		}
  1287	
  1288		dd->tx_opstats = alloc_percpu(struct hfi1_opcode_stats_perctx);
  1289		if (!dd->tx_opstats) {
  1290			ret = -ENOMEM;
  1291			goto bail;
  1292		}
  1293	
  1294		dd->comp_vect = kzalloc_obj(*dd->comp_vect);
  1295		if (!dd->comp_vect) {
  1296			ret = -ENOMEM;
  1297			goto bail;
  1298		}
  1299	
  1300		/* allocate dummy tail memory for all receive contexts */
  1301		dd->rcvhdrtail_dummy_kvaddr =
  1302			dma_alloc_coherent(&dd->pcidev->dev, sizeof(u64),
  1303					   &dd->rcvhdrtail_dummy_dma, GFP_KERNEL);
  1304		if (!dd->rcvhdrtail_dummy_kvaddr) {
  1305			ret = -ENOMEM;
  1306			goto bail;
  1307		}
  1308	
  1309		atomic_set(&dd->ipoib_rsm_usr_num, 0);
  1310		return dd;
  1311	
  1312	bail:
  1313		hfi1_free_devdata(dd);
  1314		return ERR_PTR(ret);
  1315	}
  1316	

-- 
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki

Re: [PATCH 2/3] RDMA/hfi1, rdmavt: open-code rvt_set_ibdev_name()

[kernel test robot]

Hi Arnd,

kernel test robot noticed the following build errors:

[auto build test ERROR on rdma/for-next]
[also build test ERROR on soc/for-next linus/master v7.0-rc5 next-20260323]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]

url:    https://github.com/intel-lab-lkp/linux/commits/Arnd-Bergmann/RDMA-hfi1-rdmavt-open-code-rvt_set_ibdev_name/20260322-190924
base:   https://git.kernel.org/pub/scm/linux/kernel/git/rdma/rdma.git for-next
patch link:    https://lore.kernel.org/r/20260320151511.3420818-2-arnd%40kernel.org
patch subject: [PATCH 2/3] RDMA/hfi1, rdmavt: open-code rvt_set_ibdev_name()
config: x86_64-rhel-9.4-rust (https://download.01.org/0day-ci/archive/20260324/202603240950.t4UIpBJh-lkp@intel.com/config)
compiler: clang version 20.1.8 (https://github.com/llvm/llvm-project 87f0227cb60147a26a1eeb4fb06e3b505e9c7261)
rustc: rustc 1.88.0 (6b00bc388 2025-06-23)
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20260324/202603240950.t4UIpBJh-lkp@intel.com/reproduce)

If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202603240950.t4UIpBJh-lkp@intel.com/

All errors (new ones prefixed by >>):

>> drivers/infiniband/hw/hfi1/init.c:1240:10: error: incompatible pointer types passing 'char (*)[64]' to parameter of type 'char *' [-Werror,-Wincompatible-pointer-types]
    1240 |         strscpy(&ibdev->name, dev_name(&ibdev->dev), IB_DEVICE_NAME_MAX);
         |                 ^~~~~~~~~~~~
   include/linux/string.h:114:50: note: expanded from macro 'strscpy'
     114 |         CONCATENATE(__strscpy, COUNT_ARGS(__VA_ARGS__))(dst, src, __VA_ARGS__)
         |                                                         ^~~
   include/linux/string.h:83:16: note: expanded from macro '__strscpy1'
      83 |         sized_strscpy(dst, src, size + __must_be_cstr(dst) + __must_be_cstr(src))
         |                       ^~~
   include/linux/fortify-string.h:275:57: note: passing argument to parameter 'p' here
     275 | __FORTIFY_INLINE ssize_t sized_strscpy(char * const POS p, const char * const POS q, size_t size)
         |                                                         ^
   1 error generated.


vim +1240 drivers/infiniband/hw/hfi1/init.c

  1195	
  1196	/**
  1197	 * hfi1_alloc_devdata - Allocate our primary per-unit data structure.
  1198	 * @pdev: Valid PCI device
  1199	 * @extra: How many bytes to alloc past the default
  1200	 *
  1201	 * Must be done via verbs allocator, because the verbs cleanup process
  1202	 * both does cleanup and free of the data structure.
  1203	 * "extra" is for chip-specific data.
  1204	 */
  1205	static struct hfi1_devdata *hfi1_alloc_devdata(struct pci_dev *pdev,
  1206						       size_t extra)
  1207	{
  1208		struct hfi1_devdata *dd;
  1209		struct ib_device *ibdev;
  1210		int ret, nports;
  1211	
  1212		/* extra is * number of ports */
  1213		nports = extra / sizeof(struct hfi1_pportdata);
  1214	
  1215		dd = (struct hfi1_devdata *)rvt_alloc_device(sizeof(*dd) + extra,
  1216							     nports);
  1217		if (!dd)
  1218			return ERR_PTR(-ENOMEM);
  1219		dd->num_pports = nports;
  1220		dd->pport = (struct hfi1_pportdata *)(dd + 1);
  1221		dd->pcidev = pdev;
  1222		pci_set_drvdata(pdev, dd);
  1223	
  1224		ret = xa_alloc_irq(&hfi1_dev_table, &dd->unit, dd, xa_limit_32b,
  1225				GFP_KERNEL);
  1226		if (ret < 0) {
  1227			dev_err(&pdev->dev,
  1228				"Could not allocate unit ID: error %d\n", -ret);
  1229			goto bail;
  1230		}
  1231	
  1232		/*
  1233		 * FIXME: rvt and its users want to touch the ibdev before
  1234		 * registration and have things like the name work. We don't have the
  1235		 * infrastructure in the core to support this directly today, hack it
  1236		 * to work by setting the name manually here.
  1237		 */
  1238		ibdev = &dd->verbs_dev.rdi.ibdev;
  1239		dev_set_name(&ibdev->dev, "%s_%d", class_name(), dd->unit);
> 1240		strscpy(&ibdev->name, dev_name(&ibdev->dev), IB_DEVICE_NAME_MAX);
  1241	
  1242		/*
  1243		 * If the BIOS does not have the NUMA node information set, select
  1244		 * NUMA 0 so we get consistent performance.
  1245		 */
  1246		dd->node = pcibus_to_node(pdev->bus);
  1247		if (dd->node == NUMA_NO_NODE) {
  1248			dd_dev_err(dd, "Invalid PCI NUMA node. Performance may be affected\n");
  1249			dd->node = 0;
  1250		}
  1251	
  1252		/*
  1253		 * Initialize all locks for the device. This needs to be as early as
  1254		 * possible so locks are usable.
  1255		 */
  1256		spin_lock_init(&dd->sc_lock);
  1257		spin_lock_init(&dd->sendctrl_lock);
  1258		spin_lock_init(&dd->rcvctrl_lock);
  1259		spin_lock_init(&dd->uctxt_lock);
  1260		spin_lock_init(&dd->hfi1_diag_trans_lock);
  1261		spin_lock_init(&dd->sc_init_lock);
  1262		spin_lock_init(&dd->dc8051_memlock);
  1263		seqlock_init(&dd->sc2vl_lock);
  1264		spin_lock_init(&dd->sde_map_lock);
  1265		spin_lock_init(&dd->pio_map_lock);
  1266		mutex_init(&dd->dc8051_lock);
  1267		init_waitqueue_head(&dd->event_queue);
  1268		spin_lock_init(&dd->irq_src_lock);
  1269	
  1270		dd->int_counter = alloc_percpu(u64);
  1271		if (!dd->int_counter) {
  1272			ret = -ENOMEM;
  1273			goto bail;
  1274		}
  1275	
  1276		dd->rcv_limit = alloc_percpu(u64);
  1277		if (!dd->rcv_limit) {
  1278			ret = -ENOMEM;
  1279			goto bail;
  1280		}
  1281	
  1282		dd->send_schedule = alloc_percpu(u64);
  1283		if (!dd->send_schedule) {
  1284			ret = -ENOMEM;
  1285			goto bail;
  1286		}
  1287	
  1288		dd->tx_opstats = alloc_percpu(struct hfi1_opcode_stats_perctx);
  1289		if (!dd->tx_opstats) {
  1290			ret = -ENOMEM;
  1291			goto bail;
  1292		}
  1293	
  1294		dd->comp_vect = kzalloc_obj(*dd->comp_vect);
  1295		if (!dd->comp_vect) {
  1296			ret = -ENOMEM;
  1297			goto bail;
  1298		}
  1299	
  1300		/* allocate dummy tail memory for all receive contexts */
  1301		dd->rcvhdrtail_dummy_kvaddr =
  1302			dma_alloc_coherent(&dd->pcidev->dev, sizeof(u64),
  1303					   &dd->rcvhdrtail_dummy_dma, GFP_KERNEL);
  1304		if (!dd->rcvhdrtail_dummy_kvaddr) {
  1305			ret = -ENOMEM;
  1306			goto bail;
  1307		}
  1308	
  1309		atomic_set(&dd->ipoib_rsm_usr_num, 0);
  1310		return dd;
  1311	
  1312	bail:
  1313		hfi1_free_devdata(dd);
  1314		return ERR_PTR(ret);
  1315	}
  1316	

-- 
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki