* Re: [PATCH 2/3] RDMA/hfi1, rdmavt: open-code rvt_set_ibdev_name()
2026-03-20 15:12 ` [PATCH 2/3] RDMA/hfi1, rdmavt: open-code rvt_set_ibdev_name() Arnd Bergmann
@ 2026-03-20 15:53 ` Arnd Bergmann
2026-03-23 8:08 ` Leon Romanovsky
2026-03-22 18:29 ` kernel test robot
` (2 subsequent siblings)
3 siblings, 1 reply; 17+ messages in thread
From: Arnd Bergmann @ 2026-03-20 15:53 UTC (permalink / raw)
To: Arnd Bergmann, Dennis Dalessandro, Jason Gunthorpe,
Leon Romanovsky, Nathan Chancellor, Mike Marciniszyn,
Michael J. Ruhl, Doug Ledford
Cc: Nick Desaulniers, Bill Wendling, Justin Stitt, Marco Crivellari,
Ingo Molnar, linux-rdma, linux-kernel, llvm
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
^ permalink raw reply [flat|nested] 17+ messages in thread* Re: [PATCH 2/3] RDMA/hfi1, rdmavt: open-code rvt_set_ibdev_name()
2026-03-20 15:53 ` Arnd Bergmann
@ 2026-03-23 8:08 ` Leon Romanovsky
2026-03-23 8:48 ` Arnd Bergmann
0 siblings, 1 reply; 17+ messages in thread
From: Leon Romanovsky @ 2026-03-23 8:08 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Arnd Bergmann, Dennis Dalessandro, Jason Gunthorpe,
Nathan Chancellor, Mike Marciniszyn, Michael J. Ruhl,
Doug Ledford, Nick Desaulniers, Bill Wendling, Justin Stitt,
Marco Crivellari, Ingo Molnar, linux-rdma, linux-kernel, llvm
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
>
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH 2/3] RDMA/hfi1, rdmavt: open-code rvt_set_ibdev_name()
2026-03-23 8:08 ` Leon Romanovsky
@ 2026-03-23 8:48 ` Arnd Bergmann
2026-03-23 11:01 ` Leon Romanovsky
2026-03-23 21:54 ` Dennis Dalessandro
0 siblings, 2 replies; 17+ messages in thread
From: Arnd Bergmann @ 2026-03-23 8:48 UTC (permalink / raw)
To: Leon Romanovsky
Cc: Arnd Bergmann, Dennis Dalessandro, Jason Gunthorpe,
Nathan Chancellor, Mike Marciniszyn, Michael J. Ruhl,
Doug Ledford, Nick Desaulniers, Bill Wendling, Justin Stitt,
Marco Crivellari, Ingo Molnar, linux-rdma, linux-kernel, llvm
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/
^ permalink raw reply [flat|nested] 17+ messages in thread* Re: [PATCH 2/3] RDMA/hfi1, rdmavt: open-code rvt_set_ibdev_name()
2026-03-23 8:48 ` Arnd Bergmann
@ 2026-03-23 11:01 ` Leon Romanovsky
2026-03-23 21:47 ` Dennis Dalessandro
2026-03-23 21:54 ` Dennis Dalessandro
1 sibling, 1 reply; 17+ messages in thread
From: Leon Romanovsky @ 2026-03-23 11:01 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Arnd Bergmann, Dennis Dalessandro, Jason Gunthorpe,
Nathan Chancellor, Mike Marciniszyn, Michael J. Ruhl,
Doug Ledford, Nick Desaulniers, Bill Wendling, Justin Stitt,
Marco Crivellari, Ingo Molnar, linux-rdma, linux-kernel, llvm
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
^ permalink raw reply [flat|nested] 17+ messages in thread* Re: [PATCH 2/3] RDMA/hfi1, rdmavt: open-code rvt_set_ibdev_name()
2026-03-23 11:01 ` Leon Romanovsky
@ 2026-03-23 21:47 ` Dennis Dalessandro
2026-03-24 7:27 ` Arnd Bergmann
2026-03-24 7:53 ` Leon Romanovsky
0 siblings, 2 replies; 17+ messages in thread
From: Dennis Dalessandro @ 2026-03-23 21:47 UTC (permalink / raw)
To: Leon Romanovsky, Arnd Bergmann
Cc: Arnd Bergmann, Jason Gunthorpe, Nathan Chancellor,
Mike Marciniszyn, Michael J. Ruhl, Doug Ledford, Nick Desaulniers,
Bill Wendling, Justin Stitt, Marco Crivellari, Ingo Molnar,
linux-rdma, linux-kernel, llvm
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
^ permalink raw reply [flat|nested] 17+ messages in thread* Re: [PATCH 2/3] RDMA/hfi1, rdmavt: open-code rvt_set_ibdev_name()
2026-03-23 21:47 ` Dennis Dalessandro
@ 2026-03-24 7:27 ` Arnd Bergmann
2026-03-24 7:51 ` Leon Romanovsky
2026-03-24 7:53 ` Leon Romanovsky
1 sibling, 1 reply; 17+ messages in thread
From: Arnd Bergmann @ 2026-03-24 7:27 UTC (permalink / raw)
To: Dennis Dalessandro, Leon Romanovsky
Cc: Arnd Bergmann, Jason Gunthorpe, Nathan Chancellor,
Mike Marciniszyn, Michael J. Ruhl, Doug Ledford, Nick Desaulniers,
Bill Wendling, Justin Stitt, Marco Crivellari, Ingo Molnar,
linux-rdma, linux-kernel, llvm
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
^ permalink raw reply [flat|nested] 17+ messages in thread* Re: [PATCH 2/3] RDMA/hfi1, rdmavt: open-code rvt_set_ibdev_name()
2026-03-24 7:27 ` Arnd Bergmann
@ 2026-03-24 7:51 ` Leon Romanovsky
0 siblings, 0 replies; 17+ messages in thread
From: Leon Romanovsky @ 2026-03-24 7:51 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Dennis Dalessandro, Arnd Bergmann, Jason Gunthorpe,
Nathan Chancellor, Mike Marciniszyn, Michael J. Ruhl,
Doug Ledford, Nick Desaulniers, Bill Wendling, Justin Stitt,
Marco Crivellari, Ingo Molnar, linux-rdma, linux-kernel, llvm
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
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH 2/3] RDMA/hfi1, rdmavt: open-code rvt_set_ibdev_name()
2026-03-23 21:47 ` Dennis Dalessandro
2026-03-24 7:27 ` Arnd Bergmann
@ 2026-03-24 7:53 ` Leon Romanovsky
1 sibling, 0 replies; 17+ messages in thread
From: Leon Romanovsky @ 2026-03-24 7:53 UTC (permalink / raw)
To: Dennis Dalessandro
Cc: Arnd Bergmann, Arnd Bergmann, Jason Gunthorpe, Nathan Chancellor,
Mike Marciniszyn, Michael J. Ruhl, Doug Ledford, Nick Desaulniers,
Bill Wendling, Justin Stitt, Marco Crivellari, Ingo Molnar,
linux-rdma, linux-kernel, llvm
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
>
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH 2/3] RDMA/hfi1, rdmavt: open-code rvt_set_ibdev_name()
2026-03-23 8:48 ` Arnd Bergmann
2026-03-23 11:01 ` Leon Romanovsky
@ 2026-03-23 21:54 ` Dennis Dalessandro
1 sibling, 0 replies; 17+ messages in thread
From: Dennis Dalessandro @ 2026-03-23 21:54 UTC (permalink / raw)
To: Arnd Bergmann, Leon Romanovsky
Cc: Arnd Bergmann, Jason Gunthorpe, Nathan Chancellor,
Mike Marciniszyn, Michael J. Ruhl, Doug Ledford, Nick Desaulniers,
Bill Wendling, Justin Stitt, Marco Crivellari, Ingo Molnar,
linux-rdma, linux-kernel, llvm
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
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH 2/3] RDMA/hfi1, rdmavt: open-code rvt_set_ibdev_name()
2026-03-20 15:12 ` [PATCH 2/3] RDMA/hfi1, rdmavt: open-code rvt_set_ibdev_name() Arnd Bergmann
2026-03-20 15:53 ` Arnd Bergmann
@ 2026-03-22 18:29 ` kernel test robot
2026-03-22 20:12 ` kernel test robot
2026-03-24 1:29 ` kernel test robot
3 siblings, 0 replies; 17+ messages in thread
From: kernel test robot @ 2026-03-22 18:29 UTC (permalink / raw)
To: Arnd Bergmann, Dennis Dalessandro, Jason Gunthorpe,
Leon Romanovsky, Nathan Chancellor, Mike Marciniszyn,
Michael J. Ruhl, Doug Ledford
Cc: oe-kbuild-all, Arnd Bergmann, Nick Desaulniers, Bill Wendling,
Justin Stitt, Marco Crivellari, Ingo Molnar, linux-rdma,
linux-kernel, llvm
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
^ permalink raw reply [flat|nested] 17+ messages in thread* Re: [PATCH 2/3] RDMA/hfi1, rdmavt: open-code rvt_set_ibdev_name()
2026-03-20 15:12 ` [PATCH 2/3] RDMA/hfi1, rdmavt: open-code rvt_set_ibdev_name() Arnd Bergmann
2026-03-20 15:53 ` Arnd Bergmann
2026-03-22 18:29 ` kernel test robot
@ 2026-03-22 20:12 ` kernel test robot
2026-03-24 1:29 ` kernel test robot
3 siblings, 0 replies; 17+ messages in thread
From: kernel test robot @ 2026-03-22 20:12 UTC (permalink / raw)
To: Arnd Bergmann, Dennis Dalessandro, Jason Gunthorpe,
Leon Romanovsky, Nathan Chancellor, Mike Marciniszyn,
Michael J. Ruhl, Doug Ledford
Cc: oe-kbuild-all, Arnd Bergmann, Nick Desaulniers, Bill Wendling,
Justin Stitt, Marco Crivellari, Ingo Molnar, linux-rdma,
linux-kernel, llvm
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
^ permalink raw reply [flat|nested] 17+ messages in thread* Re: [PATCH 2/3] RDMA/hfi1, rdmavt: open-code rvt_set_ibdev_name()
2026-03-20 15:12 ` [PATCH 2/3] RDMA/hfi1, rdmavt: open-code rvt_set_ibdev_name() Arnd Bergmann
` (2 preceding siblings ...)
2026-03-22 20:12 ` kernel test robot
@ 2026-03-24 1:29 ` kernel test robot
3 siblings, 0 replies; 17+ messages in thread
From: kernel test robot @ 2026-03-24 1:29 UTC (permalink / raw)
To: Arnd Bergmann, Dennis Dalessandro, Jason Gunthorpe,
Leon Romanovsky, Nathan Chancellor, Michael J. Ruhl, Doug Ledford
Cc: llvm, oe-kbuild-all, Arnd Bergmann, Nick Desaulniers,
Bill Wendling, Justin Stitt, Marco Crivellari, Ingo Molnar,
linux-rdma, linux-kernel
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
^ permalink raw reply [flat|nested] 17+ messages in thread