Re: [PATCH] Kconfig: add temporary PCI dependency

[Greg KH <greg-U8xfFu+wG4EAvxtiuMwx3w@public.gmane.org>]

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