[PATCH] Kconfig: add temporary PCI dependency

[Doug Ledford]

> On Aug 18, 2015, at 4:11 PM, Greg KH <greg at 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 at 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 at 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 at redhat.com>
	GPG Key ID: 0E572FDD





-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://driverdev.linuxdriverproject.org/pipermail/driverdev-devel/attachments/20150818/05799283/attachment.asc>