| Message ID | 20150818141542.4127.90517.stgit@phlsvslse11.ph.intel.com (mailing list archive) |
|---|---|
| State | Not Applicable |
| Headers | show |
On Tue, Aug 18, 2015 at 10:15:42AM -0400, Mike Marciniszyn wrote: > The move from infiniband to staging requires a temporary > PCI dependency to fix 0-day build issues. The > drivers/infiniband/hw/Kconfig gratuitously added it for all drivers. > > Signed-off-by: Mike Marciniszyn <mike.marciniszyn@intel.com> > --- > drivers/staging/hfi1/Kconfig | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) Why are these drivers not in drivers/staging/infiniband/ ? Why do they all need their own drivers/staging/ directory? Anyway, either way, I can't take this patch as it's only in the rdma trees at the moment, not in mine. thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
> Subject: Re: [PATCH] Kconfig: add temporary PCI dependency > > On Tue, Aug 18, 2015 at 10:15:42AM -0400, Mike Marciniszyn wrote: > > The move from infiniband to staging requires a temporary PCI > > dependency to fix 0-day build issues. The > > drivers/infiniband/hw/Kconfig gratuitously added it for all drivers. > > > > Signed-off-by: Mike Marciniszyn <mike.marciniszyn@intel.com> > > --- > > drivers/staging/hfi1/Kconfig | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > Why are these drivers not in drivers/staging/infiniband/ ? Why do they all > need their own drivers/staging/ directory? > Greg, what is the path name convention for adding a driver to staging when its eventual destination is part of a subsystem? Perhaps it should be drivers/staging/hw/hfi1? Doug, can you get this patch so that linux-next is fixed? Mike -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tue, Aug 18, 2015 at 04:29:50PM +0000, Marciniszyn, Mike wrote: > > Subject: Re: [PATCH] Kconfig: add temporary PCI dependency > > > > On Tue, Aug 18, 2015 at 10:15:42AM -0400, Mike Marciniszyn wrote: > > > The move from infiniband to staging requires a temporary PCI > > > dependency to fix 0-day build issues. The > > > drivers/infiniband/hw/Kconfig gratuitously added it for all drivers. > > > > > > Signed-off-by: Mike Marciniszyn <mike.marciniszyn@intel.com> > > > --- > > > drivers/staging/hfi1/Kconfig | 2 +- > > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > Why are these drivers not in drivers/staging/infiniband/ ? Why do they all > > need their own drivers/staging/ directory? > > > > Greg, what is the path name convention for adding a driver to staging > when its eventual destination is part of a subsystem? Perhaps it > should be drivers/staging/hw/hfi1? As I have no idea what this driver is, or what it is for, or why it is in staging, I can't answer this... greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
> On Aug 18, 2015, at 9:50 AM, Greg KH <greg@kroah.com> wrote: > > On Tue, Aug 18, 2015 at 04:29:50PM +0000, Marciniszyn, Mike wrote: >>> Subject: Re: [PATCH] Kconfig: add temporary PCI dependency >>> >>> On Tue, Aug 18, 2015 at 10:15:42AM -0400, Mike Marciniszyn wrote: >>>> The move from infiniband to staging requires a temporary PCI >>>> dependency to fix 0-day build issues. The >>>> drivers/infiniband/hw/Kconfig gratuitously added it for all drivers. >>>> >>>> Signed-off-by: Mike Marciniszyn <mike.marciniszyn@intel.com> >>>> --- >>>> drivers/staging/hfi1/Kconfig | 2 +- >>>> 1 file changed, 1 insertion(+), 1 deletion(-) >>> >>> Why are these drivers not in drivers/staging/infiniband/ ? Why do they all >>> need their own drivers/staging/ directory? >>> >> >> Greg, what is the path name convention for adding a driver to staging >> when its eventual destination is part of a subsystem? Perhaps it >> should be drivers/staging/hw/hfi1? > > As I have no idea what this driver is, or what it is for, It’s a driver for Intel’s newest RDMA capable fabric interface. It’s not InfiniBand, but Intel’s answer to InfiniBand and will eventually live in the drivers/infiniband/hw tree with the other RDMA capable device drivers. > or why it is > in staging, I can't answer this… I put it in staging in my tree because it’s >50,000 lines of code, so repeated patch submissions to the mailing list were absolutely painful, but it has work that needs done as a result of review comments, and one item of work in particular (converting it to use an RDMA transfer engine library) will take a lot of work, so putting it in staging and requiring that to be complete before putting it in the regular tree is a decent carrot for getting that large bit of work done. — Doug Ledford <dledford@redhat.com> GPG Key ID: 0E572FDD
On 08/18/15 10:00, Doug Ledford wrote: > >> On Aug 18, 2015, at 9:50 AM, Greg KH <greg@kroah.com> wrote: >> >> On Tue, Aug 18, 2015 at 04:29:50PM +0000, Marciniszyn, Mike wrote: >>>> Subject: Re: [PATCH] Kconfig: add temporary PCI dependency >>>> >>>> On Tue, Aug 18, 2015 at 10:15:42AM -0400, Mike Marciniszyn wrote: >>>>> The move from infiniband to staging requires a temporary PCI >>>>> dependency to fix 0-day build issues. The >>>>> drivers/infiniband/hw/Kconfig gratuitously added it for all drivers. >>>>> >>>>> Signed-off-by: Mike Marciniszyn <mike.marciniszyn@intel.com> >>>>> --- >>>>> drivers/staging/hfi1/Kconfig | 2 +- >>>>> 1 file changed, 1 insertion(+), 1 deletion(-) >>>> >>>> Why are these drivers not in drivers/staging/infiniband/ ? Why do they all >>>> need their own drivers/staging/ directory? >>>> >>> >>> Greg, what is the path name convention for adding a driver to staging >>> when its eventual destination is part of a subsystem? Perhaps it >>> should be drivers/staging/hw/hfi1? >> >> As I have no idea what this driver is, or what it is for, > > It’s a driver for Intel’s newest RDMA capable fabric interface. It’s not InfiniBand, but Intel’s answer to InfiniBand and will eventually live in the drivers/infiniband/hw tree with the other RDMA capable device drivers. Apparently it also needs to depend on INFINIBAND: (from today's linux-next) drivers/built-in.o: In function `ipath_remove_one': ipath_driver.c:(.text+0x7591cb): undefined reference to `ib_wq' drivers/built-in.o: In function `handle_e_ibstatuschanged.isra.10': ipath_intr.c:(.text+0x768e13): undefined reference to `ib_dispatch_event' ipath_intr.c:(.text+0x768ee7): undefined reference to `ib_dispatch_event' ipath_intr.c:(.text+0x768f4b): undefined reference to `ib_dispatch_event' drivers/built-in.o: In function `signal_ib_event': (.text+0x76af44): undefined reference to `ib_dispatch_event' drivers/built-in.o: In function `ipath_process_mad': (.text+0x76e684): undefined reference to `ib_dispatch_event' drivers/built-in.o:(.text+0x76ee0b): more undefined references to `ib_dispatch_event' follow drivers/built-in.o: In function `ipath_modify_qp': (.text+0x770bb1): undefined reference to `ib_modify_qp_is_ok' drivers/built-in.o: In function `ipath_release_user_pages_on_close': (.text+0x782900): undefined reference to `ib_wq' drivers/built-in.o: In function `ipath_register_ib_device': (.text+0x788fcf): undefined reference to `ib_alloc_device' drivers/built-in.o: In function `ipath_register_ib_device': (.text+0x789063): undefined reference to `ib_dealloc_device' drivers/built-in.o: In function `ipath_register_ib_device': (.text+0x78971d): undefined reference to `ib_register_device' drivers/built-in.o: In function `ipath_register_ib_device': (.text+0x789921): undefined reference to `ib_unregister_device' drivers/built-in.o: In function `ipath_unregister_ib_device': (.text+0x7899b2): undefined reference to `ib_unregister_device' drivers/built-in.o: In function `ipath_unregister_ib_device': (.text+0x789cc7): undefined reference to `ib_dealloc_device' drivers/built-in.o: In function `set_link_state': (.text+0x79aca2): undefined reference to `ib_dispatch_event' drivers/built-in.o: In function `hfi1_free_devdata': (.text+0x7b2a54): undefined reference to `ib_dealloc_device' drivers/built-in.o: In function `remove_one': init.c:(.text+0x7b2ec0): undefined reference to `ib_wq' drivers/built-in.o: In function `hfi1_alloc_devdata': (.text+0x7b2f20): undefined reference to `ib_alloc_device' drivers/built-in.o: In function `hfi1_alloc_devdata': (.text+0x7b307b): undefined reference to `ib_dealloc_device' drivers/built-in.o: In function `init_one': init.c:(.text+0x7b49af): undefined reference to `ib_wq' drivers/built-in.o: In function `handle_linkup_change': (.text+0x7b4da1): undefined reference to `ib_dispatch_event' drivers/built-in.o: In function `send_handler': mad.c:(.text+0x7b5f3d): undefined reference to `ib_free_send_mad' drivers/built-in.o: In function `send_trap.constprop.29': mad.c:(.text+0x7b76ab): undefined reference to `ib_create_send_mad' mad.c:(.text+0x7b77d0): undefined reference to `ib_free_send_mad' mad.c:(.text+0x7b77fe): undefined reference to `ib_post_send_mad' drivers/built-in.o: In function `subn_set_opa_sma': mad.c:(.text+0x7bad4f): undefined reference to `ib_dispatch_event' mad.c:(.text+0x7baf72): undefined reference to `ib_dispatch_event' mad.c:(.text+0x7bc016): undefined reference to `ib_dispatch_event' mad.c:(.text+0x7bc062): undefined reference to `ib_dispatch_event' drivers/built-in.o: In function `hfi1_create_agents': (.text+0x7beb07): undefined reference to `ib_register_mad_agent' drivers/built-in.o: In function `hfi1_create_agents': (.text+0x7beb9d): undefined reference to `ib_unregister_mad_agent' drivers/built-in.o: In function `hfi1_free_agents': (.text+0x7bec6a): undefined reference to `ib_unregister_mad_agent' drivers/built-in.o: In function `hfi1_free_agents': (.text+0x7bec71): undefined reference to `ib_destroy_ah' drivers/built-in.o: In function `hfi1_modify_qp': (.text+0x7c7446): undefined reference to `ib_modify_qp_is_ok' drivers/built-in.o: In function `hfi1_modify_qp': (.text+0x7c7c47): undefined reference to `ib_rate_to_mbps' drivers/built-in.o: In function `hfi1_make_ud_req': (.text+0x7e9311): undefined reference to `ib_rate_to_mbps' drivers/built-in.o: In function `hfi1_check_ah': (.text+0x7f3e55): undefined reference to `ib_rate_to_mbps' drivers/built-in.o: In function `hfi1_create_qp0_ah': (.text+0x7f43d4): undefined reference to `ib_create_ah' drivers/built-in.o: In function `hfi1_register_ib_device': (.text+0x7f4bbe): undefined reference to `ib_register_device' drivers/built-in.o: In function `hfi1_register_ib_device': (.text+0x7f4d0e): undefined reference to `ib_unregister_device' drivers/built-in.o: In function `hfi1_unregister_ib_device': (.text+0x7f4d4e): undefined reference to `ib_unregister_device'
On Tue, Aug 18, 2015 at 10:00:39AM -0700, Doug Ledford wrote: > > > On Aug 18, 2015, at 9:50 AM, Greg KH <greg@kroah.com> wrote: > > > > On Tue, Aug 18, 2015 at 04:29:50PM +0000, Marciniszyn, Mike wrote: > >>> Subject: Re: [PATCH] Kconfig: add temporary PCI dependency > >>> > >>> On Tue, Aug 18, 2015 at 10:15:42AM -0400, Mike Marciniszyn wrote: > >>>> The move from infiniband to staging requires a temporary PCI > >>>> dependency to fix 0-day build issues. The > >>>> drivers/infiniband/hw/Kconfig gratuitously added it for all drivers. > >>>> > >>>> Signed-off-by: Mike Marciniszyn <mike.marciniszyn@intel.com> > >>>> --- > >>>> drivers/staging/hfi1/Kconfig | 2 +- > >>>> 1 file changed, 1 insertion(+), 1 deletion(-) > >>> > >>> Why are these drivers not in drivers/staging/infiniband/ ? Why do they all > >>> need their own drivers/staging/ directory? > >>> > >> > >> Greg, what is the path name convention for adding a driver to staging > >> when its eventual destination is part of a subsystem? Perhaps it > >> should be drivers/staging/hw/hfi1? > > > > As I have no idea what this driver is, or what it is for, > > It’s a driver for Intel’s newest RDMA capable fabric interface. It’s > not InfiniBand, but Intel’s answer to InfiniBand and will eventually > live in the drivers/infiniband/hw tree with the other RDMA capable > device drivers. > > > or why it is > > in staging, I can't answer this… > > I put it in staging in my tree because it’s >50,000 lines of code, so > repeated patch submissions to the mailing list were absolutely > painful, but it has work that needs done as a result of review > comments, and one item of work in particular (converting it to use an > RDMA transfer engine library) will take a lot of work, so putting it > in staging and requiring that to be complete before putting it in the > regular tree is a decent carrot for getting that large bit of work > done. Does it have a TODO file that lists what needs to be done with it? Are you going to be responsible for all of the patches sent to it and you just want me to ignore them, or will you send patches to me for me to apply? thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
> On Aug 18, 2015, at 4:11 PM, Greg KH <greg@kroah.com> wrote: > > On Tue, Aug 18, 2015 at 10:00:39AM -0700, Doug Ledford wrote: >> >>> On Aug 18, 2015, at 9:50 AM, Greg KH <greg@kroah.com> wrote: >>> >>> On Tue, Aug 18, 2015 at 04:29:50PM +0000, Marciniszyn, Mike wrote: >>>>> Subject: Re: [PATCH] Kconfig: add temporary PCI dependency >>>>> >>>>> On Tue, Aug 18, 2015 at 10:15:42AM -0400, Mike Marciniszyn wrote: >>>>>> The move from infiniband to staging requires a temporary PCI >>>>>> dependency to fix 0-day build issues. The >>>>>> drivers/infiniband/hw/Kconfig gratuitously added it for all drivers. >>>>>> >>>>>> Signed-off-by: Mike Marciniszyn <mike.marciniszyn@intel.com> >>>>>> --- >>>>>> drivers/staging/hfi1/Kconfig | 2 +- >>>>>> 1 file changed, 1 insertion(+), 1 deletion(-) >>>>> >>>>> Why are these drivers not in drivers/staging/infiniband/ ? Why do they all >>>>> need their own drivers/staging/ directory? >>>>> >>>> >>>> Greg, what is the path name convention for adding a driver to staging >>>> when its eventual destination is part of a subsystem? Perhaps it >>>> should be drivers/staging/hw/hfi1? >>> >>> As I have no idea what this driver is, or what it is for, >> >> It’s a driver for Intel’s newest RDMA capable fabric interface. It’s >> not InfiniBand, but Intel’s answer to InfiniBand and will eventually >> live in the drivers/infiniband/hw tree with the other RDMA capable >> device drivers. >> >>> or why it is >>> in staging, I can't answer this… >> >> I put it in staging in my tree because it’s >50,000 lines of code, so >> repeated patch submissions to the mailing list were absolutely >> painful, but it has work that needs done as a result of review >> comments, and one item of work in particular (converting it to use an >> RDMA transfer engine library) will take a lot of work, so putting it >> in staging and requiring that to be complete before putting it in the >> regular tree is a decent carrot for getting that large bit of work >> done. > > Does it have a TODO file that lists what needs to be done with it? Yes. > Are > you going to be responsible for all of the patches sent to it and you > just want me to ignore them, or will you send patches to me for me to > apply? I expect the patch load to be significant due to the required TODO item of making it use a transfer engine library. I wouldn’t want to sign you up for that load. If you are OK with me processing the patches, then I’m happy to do so. If you would prefer the other way around, then I’ll defer to your wishes. — Doug Ledford <dledford@redhat.com> GPG Key ID: 0E572FDD
On Tue, Aug 18, 2015 at 06:24:40PM -0700, Doug Ledford wrote: > > > On Aug 18, 2015, at 4:11 PM, Greg KH <greg@kroah.com> wrote: > > > > On Tue, Aug 18, 2015 at 10:00:39AM -0700, Doug Ledford wrote: > >> > >>> On Aug 18, 2015, at 9:50 AM, Greg KH <greg@kroah.com> wrote: > >>> > >>> On Tue, Aug 18, 2015 at 04:29:50PM +0000, Marciniszyn, Mike wrote: > >>>>> Subject: Re: [PATCH] Kconfig: add temporary PCI dependency > >>>>> > >>>>> On Tue, Aug 18, 2015 at 10:15:42AM -0400, Mike Marciniszyn wrote: > >>>>>> The move from infiniband to staging requires a temporary PCI > >>>>>> dependency to fix 0-day build issues. The > >>>>>> drivers/infiniband/hw/Kconfig gratuitously added it for all drivers. > >>>>>> > >>>>>> Signed-off-by: Mike Marciniszyn <mike.marciniszyn@intel.com> > >>>>>> --- > >>>>>> drivers/staging/hfi1/Kconfig | 2 +- > >>>>>> 1 file changed, 1 insertion(+), 1 deletion(-) > >>>>> > >>>>> Why are these drivers not in drivers/staging/infiniband/ ? Why do they all > >>>>> need their own drivers/staging/ directory? > >>>>> > >>>> > >>>> Greg, what is the path name convention for adding a driver to staging > >>>> when its eventual destination is part of a subsystem? Perhaps it > >>>> should be drivers/staging/hw/hfi1? > >>> > >>> As I have no idea what this driver is, or what it is for, > >> > >> It’s a driver for Intel’s newest RDMA capable fabric interface. It’s > >> not InfiniBand, but Intel’s answer to InfiniBand and will eventually > >> live in the drivers/infiniband/hw tree with the other RDMA capable > >> device drivers. > >> > >>> or why it is > >>> in staging, I can't answer this… > >> > >> I put it in staging in my tree because it’s >50,000 lines of code, so > >> repeated patch submissions to the mailing list were absolutely > >> painful, but it has work that needs done as a result of review > >> comments, and one item of work in particular (converting it to use an > >> RDMA transfer engine library) will take a lot of work, so putting it > >> in staging and requiring that to be complete before putting it in the > >> regular tree is a decent carrot for getting that large bit of work > >> done. > > > > Does it have a TODO file that lists what needs to be done with it? > > Yes. > > > Are > > you going to be responsible for all of the patches sent to it and you > > just want me to ignore them, or will you send patches to me for me to > > apply? > > I expect the patch load to be significant due to the required TODO > item of making it use a transfer engine library. I wouldn’t want to > sign you up for that load. If you are OK with me processing the > patches, then I’m happy to do so. If you would prefer the other way > around, then I’ll defer to your wishes. What is "significant"? I'm kind of used to handling a lot of patches :) How are you going to handle all of the coding style fixups that will end up coming in from people? Want me to just let you handle all of them as well? If so, please remove me from the MAINTAINERS entry for this subdirectory so that I, and the driverdevel mailing list do not get the emails. Otherwise, feel free to just send me patches, I can easily handle them. thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
> On Aug 18, 2015, at 7:49 PM, Greg KH <greg@kroah.com> wrote: > > On Tue, Aug 18, 2015 at 06:24:40PM -0700, Doug Ledford wrote: >> >> >>> Are >>> you going to be responsible for all of the patches sent to it and you >>> just want me to ignore them, or will you send patches to me for me to >>> apply? >> >> I expect the patch load to be significant due to the required TODO >> item of making it use a transfer engine library. I wouldn’t want to >> sign you up for that load. If you are OK with me processing the >> patches, then I’m happy to do so. If you would prefer the other way >> around, then I’ll defer to your wishes. > > What is "significant"? I'm kind of used to handling a lot of patches :) I have no doubt of that. > How are you going to handle all of the coding style fixups that will end > up coming in from people? Want me to just let you handle all of them as > well? If so, please remove me from the MAINTAINERS entry for this > subdirectory so that I, and the driverdevel mailing list do not get the > emails. > > Otherwise, feel free to just send me patches, I can easily handle them. Given the amount of stuff I have on the radar for going through the staging tree (two deprecated drivers to be removed entirely, plan is move to staging in 4.3, delete from tree in 4.6, this driver and one other as-of-yet-to-be-submitted driver to be added to tree, both drivers have the same major TODO item, which is to be converted to use a library for their transfer engine, which also requires writing said library), I’m wondering if it isn’t worthwhile to create a staging/infiniband directory, remove your name and driverdevel from the maintainer entry for the directory and redirect it to linux-rdma, and delete it when this work has passed. — Doug Ledford <dledford@redhat.com> GPG Key ID: 0E572FDD
On Tue, Aug 18, 2015 at 08:11:26PM -0700, Doug Ledford wrote: > > > On Aug 18, 2015, at 7:49 PM, Greg KH <greg@kroah.com> wrote: > > > > On Tue, Aug 18, 2015 at 06:24:40PM -0700, Doug Ledford wrote: > >> > >> > >>> Are > >>> you going to be responsible for all of the patches sent to it and you > >>> just want me to ignore them, or will you send patches to me for me to > >>> apply? > >> > >> I expect the patch load to be significant due to the required TODO > >> item of making it use a transfer engine library. I wouldn’t want to > >> sign you up for that load. If you are OK with me processing the > >> patches, then I’m happy to do so. If you would prefer the other way > >> around, then I’ll defer to your wishes. > > > > What is "significant"? I'm kind of used to handling a lot of patches :) > > I have no doubt of that. > > > How are you going to handle all of the coding style fixups that will end > > up coming in from people? Want me to just let you handle all of them as > > well? If so, please remove me from the MAINTAINERS entry for this > > subdirectory so that I, and the driverdevel mailing list do not get the > > emails. > > > > Otherwise, feel free to just send me patches, I can easily handle them. > > Given the amount of stuff I have on the radar for going through the > staging tree (two deprecated drivers to be removed entirely, plan is > move to staging in 4.3, delete from tree in 4.6, this driver and one > other as-of-yet-to-be-submitted driver to be added to tree, both > drivers have the same major TODO item, which is to be converted to use > a library for their transfer engine, which also requires writing said > library), I’m wondering if it isn’t worthwhile to create a > staging/infiniband directory, remove your name and driverdevel from > the maintainer entry for the directory and redirect it to linux-rdma, > and delete it when this work has passed. That sounds like a good plan to me. thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
> On Aug 18, 2015, at 9:10 PM, Greg KH <greg@kroah.com> wrote: > >> >> a library for their transfer engine, which also requires writing said >> library), I’m wondering if it isn’t worthwhile to create a >> staging/infiniband directory, remove your name and driverdevel from >> the maintainer entry for the directory and redirect it to linux-rdma, >> and delete it when this work has passed. > > That sounds like a good plan to me. I’ll rebase my tree and fix it up. — Doug Ledford <dledford@redhat.com> GPG Key ID: 0E572FDD
On 08/18/2015 10:15 AM, Mike Marciniszyn wrote: > The move from infiniband to staging requires a temporary > PCI dependency to fix 0-day build issues. The > drivers/infiniband/hw/Kconfig gratuitously added it for all drivers. This was no longer needed after I created drivers/staging/rdma and moved all the drivers into subdirectories of that directory. > Signed-off-by: Mike Marciniszyn <mike.marciniszyn@intel.com> > --- > drivers/staging/hfi1/Kconfig | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/staging/hfi1/Kconfig b/drivers/staging/hfi1/Kconfig > index 78bc89e..8a079ba 100644 > --- a/drivers/staging/hfi1/Kconfig > +++ b/drivers/staging/hfi1/Kconfig > @@ -1,6 +1,6 @@ > config INFINIBAND_HFI1 > tristate "Intel OPA Gen1 support" > - depends on X86_64 && INFINIBAND > + depends on X86_64 && INFINIBAND && PCI > default m > ---help--- > This is a low-level driver for Intel OPA Gen1 adapter. >
diff --git a/drivers/staging/hfi1/Kconfig b/drivers/staging/hfi1/Kconfig index 78bc89e..8a079ba 100644 --- a/drivers/staging/hfi1/Kconfig +++ b/drivers/staging/hfi1/Kconfig @@ -1,6 +1,6 @@ config INFINIBAND_HFI1 tristate "Intel OPA Gen1 support" - depends on X86_64 && INFINIBAND + depends on X86_64 && INFINIBAND && PCI default m ---help--- This is a low-level driver for Intel OPA Gen1 adapter.
The move from infiniband to staging requires a temporary PCI dependency to fix 0-day build issues. The drivers/infiniband/hw/Kconfig gratuitously added it for all drivers. Signed-off-by: Mike Marciniszyn <mike.marciniszyn@intel.com> --- drivers/staging/hfi1/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html