[PATCH] Kconfig: add temporary PCI dependency

[PATCH] Kconfig: add temporary PCI dependency

[Mike Marciniszyn]

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-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
---
 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.

--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] Kconfig: add temporary PCI dependency

[Greg KH]

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-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
> ---
>  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-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [PATCH] Kconfig: add temporary PCI dependency

[Marciniszyn, Mike]

> 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-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
> > ---
> >  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-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] Kconfig: add temporary PCI dependency

[Greg KH]

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-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
> > > ---
> > >  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-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] Kconfig: add temporary PCI dependency

[Doug Ledford]

[-- Attachment #1.1: Type: text/plain, Size: 1895 bytes --]


> 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






[-- Attachment #1.2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 842 bytes --]

[-- Attachment #2: Type: text/plain, Size: 169 bytes --]

_______________________________________________
devel mailing list
devel@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH] Kconfig: add temporary PCI dependency

[Randy Dunlap]

On 08/18/15 10:00, Doug Ledford wrote:
> 
>> On Aug 18, 2015, at 9:50 AM, Greg KH <greg-U8xfFu+wG4EAvxtiuMwx3w@public.gmane.org> 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-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
>>>>> ---
>>>>> 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'



-- 
~Randy
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] Kconfig: add temporary PCI dependency

[Greg KH]

On Tue, Aug 18, 2015 at 10:00:39AM -0700, Doug Ledford wrote:
> 
> > On Aug 18, 2015, at 9:50 AM, Greg KH <greg-U8xfFu+wG4EAvxtiuMwx3w@public.gmane.org> 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-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
> >>>> ---
> >>>> 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-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] Kconfig: add temporary PCI dependency

[Doug Ledford]

[-- Attachment #1: Type: text/plain, Size: 2826 bytes --]


> On Aug 18, 2015, at 4:11 PM, Greg KH <greg-U8xfFu+wG4EAvxtiuMwx3w@public.gmane.org> 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-U8xfFu+wG4EAvxtiuMwx3w@public.gmane.org> 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-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
>>>>>> ---
>>>>>> 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-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
	GPG Key ID: 0E572FDD






[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 842 bytes --]

Re: [PATCH] Kconfig: add temporary PCI dependency

[Greg KH]

On Tue, Aug 18, 2015 at 06:24:40PM -0700, Doug Ledford wrote:
> 
> > On Aug 18, 2015, at 4:11 PM, Greg KH <greg-U8xfFu+wG4EAvxtiuMwx3w@public.gmane.org> 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-U8xfFu+wG4EAvxtiuMwx3w@public.gmane.org> 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-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
> >>>>>> ---
> >>>>>> 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-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] Kconfig: add temporary PCI dependency

[Doug Ledford]

[-- Attachment #1: Type: text/plain, Size: 1946 bytes --]


> On Aug 18, 2015, at 7:49 PM, Greg KH <greg-U8xfFu+wG4EAvxtiuMwx3w@public.gmane.org> 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-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
	GPG Key ID: 0E572FDD






[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 842 bytes --]

Re: [PATCH] Kconfig: add temporary PCI dependency

[Greg KH]

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
_______________________________________________
devel mailing list
devel@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH] Kconfig: add temporary PCI dependency

[Doug Ledford]

[-- Attachment #1: Type: text/plain, Size: 625 bytes --]


> On Aug 18, 2015, at 9:10 PM, Greg KH <greg-U8xfFu+wG4EAvxtiuMwx3w@public.gmane.org> 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-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
	GPG Key ID: 0E572FDD






[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 842 bytes --]

Re: [PATCH] Kconfig: add temporary PCI dependency

[Doug Ledford]

[-- Attachment #1: Type: text/plain, Size: 1122 bytes --]

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-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
> ---
>  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.
> 


-- 
Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
              GPG KeyID: 0E572FDD



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 884 bytes --]