Re: [RFC PATCH 00/15] staging/rdma/hfi1: Initial patches to add rdmavt support in HFI1

2016-01-05 Thread ira.weiny 
> > > > > 
> > > > > If Doug accepts the library changes, let me know that public git 
> > > > > commit
> > > > > and I can pull it into the staging-next branch and you can continue to
> > > > > send me staging patches that way.
> > > > 
> > > > Won't this cause a conflict during the merge window?
> > > 
> > > No, git is good :)
> > > 
> > > > How do we handle changes which affect both qib and hfi1?
> > > 
> > > I don't know, now this gets messy...
> > > 
> > 
> > Agreed and this is what we are worried about.
> > 
> > Can we do what Dan and Doug have proposed in the past and have Doug take 
> > over
> > the staging/rdma sub-tree?
> > 
> > http://driverdev.linuxdriverproject.org/pipermail/driverdev-devel/2015-November/081922.html
> > 
> > I think the upcoming merge window is a reasonable time for him to do that.
> 
> Ok, but keeping on top of all of the generic staging patches that come
> in is a tough thing to do, that's up to Doug, if he is ready for it...
> 

Greg,

Forgive me for not knowing how multiple maintainers deal with hand offs like
this.  I'm hoping you, and/or Doug, can answer some questions for me.

Am I correct in assuming the merge window will be open on Monday?  If so, when
will Linus pull the staging tree?  Then at what point will Doug get the hfi1
changes which have already been accepted?

Are you going to be able to review the outstanding patches for
staging/rdma/hfi1 before the merge window?  Or should we consider them dropped
and resubmit to Doug to apply after he has merged the latest hfi1 code from
Linus?


Doug,

At what point should we start submitting additional patches to you which we
have queued up but are not yet submitted to Greg?

So far we have been cross posting to linux-rdma for feedback and I see that the
patches have been dropped from patchworks.  I assume you dropped them from
patchworks because you knew that Greg was handling them?

Thanks,
Ira

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

Re: [RFC PATCH 00/15] staging/rdma/hfi1: Initial patches to add rdmavt support in HFI1

2015-12-24 Thread ira.weiny 
On Tue, Dec 22, 2015 at 06:27:57PM -0800, gre...@linuxfoundation.org wrote:
> On Tue, Dec 22, 2015 at 02:15:08PM -0500, ira.weiny wrote:
> > On Mon, Dec 21, 2015 at 05:01:48PM -0800, gre...@linuxfoundation.org wrote:

[snip]

> > > 
> > > No, git is good :)
> > > 
> > > > How do we handle changes which affect both qib and hfi1?
> > > 
> > > I don't know, now this gets messy...
> > > 
> > 
> > Agreed and this is what we are worried about.
> > 
> > Can we do what Dan and Doug have proposed in the past and have Doug take 
> > over
> > the staging/rdma sub-tree?
> > 
> > http://driverdev.linuxdriverproject.org/pipermail/driverdev-devel/2015-November/081922.html
> > 
> > I think the upcoming merge window is a reasonable time for him to do that.
> 
> Ok, but keeping on top of all of the generic staging patches that come
> in is a tough thing to do, that's up to Doug, if he is ready for it...
> 

To help this process, once the change over happens, we will help to monitor
driverdev-devel for anything submitted to staging/rdma.  If something is
submitted which was not to Doug and linux-rdma we can handle alerting the
submitter to make sure it gets submitted to Doug as per the current MAINTAINERS
file.

Hope this helps,
Ira

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

Re: [RFC PATCH 00/15] staging/rdma/hfi1: Initial patches to add rdmavt support in HFI1

2015-12-22 Thread ira.weiny 
On Mon, Dec 21, 2015 at 05:01:48PM -0800, gre...@linuxfoundation.org wrote:
> On Mon, Dec 21, 2015 at 07:19:43PM -0500, ira.weiny wrote:
> > On Mon, Dec 21, 2015 at 02:02:35PM -0800, gre...@linuxfoundation.org wrote:
> > > On Mon, Dec 21, 2015 at 01:12:14AM -0500, ira.weiny wrote:
> > > > Greg, Doug,
> > > > 
> > > > As mentioned below, these patches depend on the new rdmavt library 
> > > > submitted to
> > > > Doug on linux-rdma.
> > > > 
> > > > We continue to identify (and rework) patches by our other developers 
> > > > which can
> > > > be submitted without conflicts with this series.  Furthermore, We have, 
> > > > as much
> > > > as possible, placed fixes directly into rdmavt such that those changes 
> > > > can be
> > > > dropped from hfi1.  But at this point, we need to know if and where 
> > > > these are
> > > > going to land so that we can start reworking as appropriate.
> > > > 
> > > > Therefore, I would like to discuss plans to get hfi1 under the same 
> > > > maintainer
> > > > to work through this transitional period.
> > > > 
> > > > Basically, At what point should we stop submitting patches to Greg and 
> > > > start
> > > > submitting to Doug?
> > > > 
> > > > Should we consider the merge window itself as the swap over point and 
> > > > submit
> > > > changes to Doug at that point?  If so, should we continue to submit 
> > > > what we can
> > > > to Greg until then (and continue rebase'ing the series below on that 
> > > > work)?  Or
> > > > given Gregs backlog, should we stop submitting to Greg sometime prior 
> > > > to the
> > > > merge window?
> > > > 
> > > > That brings up my final question, at the point of swap over I assume 
> > > > anything
> > > > not accepted by Greg should be considered rejected and we need to 
> > > > resubmit to
> > > > Doug?
> > > 
> > > If Doug accepts the library changes, let me know that public git commit
> > > and I can pull it into the staging-next branch and you can continue to
> > > send me staging patches that way.
> > 
> > Won't this cause a conflict during the merge window?
> 
> No, git is good :)
> 
> > How do we handle changes which affect both qib and hfi1?
> 
> I don't know, now this gets messy...
> 

Agreed and this is what we are worried about.

Can we do what Dan and Doug have proposed in the past and have Doug take over
the staging/rdma sub-tree?

http://driverdev.linuxdriverproject.org/pipermail/driverdev-devel/2015-November/081922.html

I think the upcoming merge window is a reasonable time for him to do that.

Ira

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

Re: [RFC PATCH 00/15] staging/rdma/hfi1: Initial patches to add rdmavt support in HFI1

2015-12-22 Thread gre...@linuxfoundation.org 
On Tue, Dec 22, 2015 at 02:15:08PM -0500, ira.weiny wrote:
> On Mon, Dec 21, 2015 at 05:01:48PM -0800, gre...@linuxfoundation.org wrote:
> > On Mon, Dec 21, 2015 at 07:19:43PM -0500, ira.weiny wrote:
> > > On Mon, Dec 21, 2015 at 02:02:35PM -0800, gre...@linuxfoundation.org 
> > > wrote:
> > > > On Mon, Dec 21, 2015 at 01:12:14AM -0500, ira.weiny wrote:
> > > > > Greg, Doug,
> > > > > 
> > > > > As mentioned below, these patches depend on the new rdmavt library 
> > > > > submitted to
> > > > > Doug on linux-rdma.
> > > > > 
> > > > > We continue to identify (and rework) patches by our other developers 
> > > > > which can
> > > > > be submitted without conflicts with this series.  Furthermore, We 
> > > > > have, as much
> > > > > as possible, placed fixes directly into rdmavt such that those 
> > > > > changes can be
> > > > > dropped from hfi1.  But at this point, we need to know if and where 
> > > > > these are
> > > > > going to land so that we can start reworking as appropriate.
> > > > > 
> > > > > Therefore, I would like to discuss plans to get hfi1 under the same 
> > > > > maintainer
> > > > > to work through this transitional period.
> > > > > 
> > > > > Basically, At what point should we stop submitting patches to Greg 
> > > > > and start
> > > > > submitting to Doug?
> > > > > 
> > > > > Should we consider the merge window itself as the swap over point and 
> > > > > submit
> > > > > changes to Doug at that point?  If so, should we continue to submit 
> > > > > what we can
> > > > > to Greg until then (and continue rebase'ing the series below on that 
> > > > > work)?  Or
> > > > > given Gregs backlog, should we stop submitting to Greg sometime prior 
> > > > > to the
> > > > > merge window?
> > > > > 
> > > > > That brings up my final question, at the point of swap over I assume 
> > > > > anything
> > > > > not accepted by Greg should be considered rejected and we need to 
> > > > > resubmit to
> > > > > Doug?
> > > > 
> > > > If Doug accepts the library changes, let me know that public git commit
> > > > and I can pull it into the staging-next branch and you can continue to
> > > > send me staging patches that way.
> > > 
> > > Won't this cause a conflict during the merge window?
> > 
> > No, git is good :)
> > 
> > > How do we handle changes which affect both qib and hfi1?
> > 
> > I don't know, now this gets messy...
> > 
> 
> Agreed and this is what we are worried about.
> 
> Can we do what Dan and Doug have proposed in the past and have Doug take over
> the staging/rdma sub-tree?
> 
> http://driverdev.linuxdriverproject.org/pipermail/driverdev-devel/2015-November/081922.html
> 
> I think the upcoming merge window is a reasonable time for him to do that.

Ok, but keeping on top of all of the generic staging patches that come
in is a tough thing to do, that's up to Doug, if he is ready for it...

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

Re: [RFC PATCH 00/15] staging/rdma/hfi1: Initial patches to add rdmavt support in HFI1

2015-12-22 Thread Doug Ledford 
On 12/22/2015 09:27 PM, gre...@linuxfoundation.org wrote:
> On Tue, Dec 22, 2015 at 02:15:08PM -0500, ira.weiny wrote:
>> On Mon, Dec 21, 2015 at 05:01:48PM -0800, gre...@linuxfoundation.org wrote:
>>> On Mon, Dec 21, 2015 at 07:19:43PM -0500, ira.weiny wrote:
 On Mon, Dec 21, 2015 at 02:02:35PM -0800, gre...@linuxfoundation.org wrote:
> On Mon, Dec 21, 2015 at 01:12:14AM -0500, ira.weiny wrote:
>> Greg, Doug,
>>
>> As mentioned below, these patches depend on the new rdmavt library 
>> submitted to
>> Doug on linux-rdma.
>>
>> We continue to identify (and rework) patches by our other developers 
>> which can
>> be submitted without conflicts with this series.  Furthermore, We have, 
>> as much
>> as possible, placed fixes directly into rdmavt such that those changes 
>> can be
>> dropped from hfi1.  But at this point, we need to know if and where 
>> these are
>> going to land so that we can start reworking as appropriate.
>>
>> Therefore, I would like to discuss plans to get hfi1 under the same 
>> maintainer
>> to work through this transitional period.
>>
>> Basically, At what point should we stop submitting patches to Greg and 
>> start
>> submitting to Doug?
>>
>> Should we consider the merge window itself as the swap over point and 
>> submit
>> changes to Doug at that point?  If so, should we continue to submit what 
>> we can
>> to Greg until then (and continue rebase'ing the series below on that 
>> work)?  Or
>> given Gregs backlog, should we stop submitting to Greg sometime prior to 
>> the
>> merge window?
>>
>> That brings up my final question, at the point of swap over I assume 
>> anything
>> not accepted by Greg should be considered rejected and we need to 
>> resubmit to
>> Doug?
>
> If Doug accepts the library changes, let me know that public git commit
> and I can pull it into the staging-next branch and you can continue to
> send me staging patches that way.

 Won't this cause a conflict during the merge window?
>>>
>>> No, git is good :)
>>>
 How do we handle changes which affect both qib and hfi1?
>>>
>>> I don't know, now this gets messy...
>>>
>>
>> Agreed and this is what we are worried about.
>>
>> Can we do what Dan and Doug have proposed in the past and have Doug take over
>> the staging/rdma sub-tree?
>>
>> http://driverdev.linuxdriverproject.org/pipermail/driverdev-devel/2015-November/081922.html
>>
>> I think the upcoming merge window is a reasonable time for him to do that.
> 
> Ok, but keeping on top of all of the generic staging patches that come
> in is a tough thing to do, that's up to Doug, if he is ready for it...

I'm not worried about that.  Patchworks makes the workflow reasonable.

-- 
Doug Ledford 
  GPG KeyID: 0E572FDD




signature.asc
Description: OpenPGP digital signature

Re: [RFC PATCH 00/15] staging/rdma/hfi1: Initial patches to add rdmavt support in HFI1

2015-12-21 Thread ira.weiny 
On Mon, Dec 21, 2015 at 02:02:35PM -0800, gre...@linuxfoundation.org wrote:
> On Mon, Dec 21, 2015 at 01:12:14AM -0500, ira.weiny wrote:
> > Greg, Doug,
> > 
> > As mentioned below, these patches depend on the new rdmavt library 
> > submitted to
> > Doug on linux-rdma.
> > 
> > We continue to identify (and rework) patches by our other developers which 
> > can
> > be submitted without conflicts with this series.  Furthermore, We have, as 
> > much
> > as possible, placed fixes directly into rdmavt such that those changes can 
> > be
> > dropped from hfi1.  But at this point, we need to know if and where these 
> > are
> > going to land so that we can start reworking as appropriate.
> > 
> > Therefore, I would like to discuss plans to get hfi1 under the same 
> > maintainer
> > to work through this transitional period.
> > 
> > Basically, At what point should we stop submitting patches to Greg and start
> > submitting to Doug?
> > 
> > Should we consider the merge window itself as the swap over point and submit
> > changes to Doug at that point?  If so, should we continue to submit what we 
> > can
> > to Greg until then (and continue rebase'ing the series below on that work)? 
> >  Or
> > given Gregs backlog, should we stop submitting to Greg sometime prior to the
> > merge window?
> > 
> > That brings up my final question, at the point of swap over I assume 
> > anything
> > not accepted by Greg should be considered rejected and we need to resubmit 
> > to
> > Doug?
> 
> If Doug accepts the library changes, let me know that public git commit
> and I can pull it into the staging-next branch and you can continue to
> send me staging patches that way.

Won't this cause a conflict during the merge window?

How do we handle changes which affect both qib and hfi1?

Ira

> 
> That's the easiest thing to do usually.
> 
> thanks,
> 
> greg k-h
> --
> To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC PATCH 00/15] staging/rdma/hfi1: Initial patches to add rdmavt support in HFI1

2015-12-21 Thread gre...@linuxfoundation.org 
On Mon, Dec 21, 2015 at 01:12:14AM -0500, ira.weiny wrote:
> Greg, Doug,
> 
> As mentioned below, these patches depend on the new rdmavt library submitted 
> to
> Doug on linux-rdma.
> 
> We continue to identify (and rework) patches by our other developers which can
> be submitted without conflicts with this series.  Furthermore, We have, as 
> much
> as possible, placed fixes directly into rdmavt such that those changes can be
> dropped from hfi1.  But at this point, we need to know if and where these are
> going to land so that we can start reworking as appropriate.
> 
> Therefore, I would like to discuss plans to get hfi1 under the same maintainer
> to work through this transitional period.
> 
> Basically, At what point should we stop submitting patches to Greg and start
> submitting to Doug?
> 
> Should we consider the merge window itself as the swap over point and submit
> changes to Doug at that point?  If so, should we continue to submit what we 
> can
> to Greg until then (and continue rebase'ing the series below on that work)?  
> Or
> given Gregs backlog, should we stop submitting to Greg sometime prior to the
> merge window?
> 
> That brings up my final question, at the point of swap over I assume anything
> not accepted by Greg should be considered rejected and we need to resubmit to
> Doug?

If Doug accepts the library changes, let me know that public git commit
and I can pull it into the staging-next branch and you can continue to
send me staging patches that way.

That's the easiest thing to do usually.

thanks,

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

Re: [RFC PATCH 00/15] staging/rdma/hfi1: Initial patches to add rdmavt support in HFI1

2015-12-21 Thread gre...@linuxfoundation.org 
On Mon, Dec 21, 2015 at 07:19:43PM -0500, ira.weiny wrote:
> On Mon, Dec 21, 2015 at 02:02:35PM -0800, gre...@linuxfoundation.org wrote:
> > On Mon, Dec 21, 2015 at 01:12:14AM -0500, ira.weiny wrote:
> > > Greg, Doug,
> > > 
> > > As mentioned below, these patches depend on the new rdmavt library 
> > > submitted to
> > > Doug on linux-rdma.
> > > 
> > > We continue to identify (and rework) patches by our other developers 
> > > which can
> > > be submitted without conflicts with this series.  Furthermore, We have, 
> > > as much
> > > as possible, placed fixes directly into rdmavt such that those changes 
> > > can be
> > > dropped from hfi1.  But at this point, we need to know if and where these 
> > > are
> > > going to land so that we can start reworking as appropriate.
> > > 
> > > Therefore, I would like to discuss plans to get hfi1 under the same 
> > > maintainer
> > > to work through this transitional period.
> > > 
> > > Basically, At what point should we stop submitting patches to Greg and 
> > > start
> > > submitting to Doug?
> > > 
> > > Should we consider the merge window itself as the swap over point and 
> > > submit
> > > changes to Doug at that point?  If so, should we continue to submit what 
> > > we can
> > > to Greg until then (and continue rebase'ing the series below on that 
> > > work)?  Or
> > > given Gregs backlog, should we stop submitting to Greg sometime prior to 
> > > the
> > > merge window?
> > > 
> > > That brings up my final question, at the point of swap over I assume 
> > > anything
> > > not accepted by Greg should be considered rejected and we need to 
> > > resubmit to
> > > Doug?
> > 
> > If Doug accepts the library changes, let me know that public git commit
> > and I can pull it into the staging-next branch and you can continue to
> > send me staging patches that way.
> 
> Won't this cause a conflict during the merge window?

No, git is good :)

> How do we handle changes which affect both qib and hfi1?

I don't know, now this gets messy...

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

Re: [RFC PATCH 00/15] staging/rdma/hfi1: Initial patches to add rdmavt support in HFI1

2015-12-20 Thread ira.weiny 
Greg, Doug,

As mentioned below, these patches depend on the new rdmavt library submitted to
Doug on linux-rdma.

We continue to identify (and rework) patches by our other developers which can
be submitted without conflicts with this series.  Furthermore, We have, as much
as possible, placed fixes directly into rdmavt such that those changes can be
dropped from hfi1.  But at this point, we need to know if and where these are
going to land so that we can start reworking as appropriate.

Therefore, I would like to discuss plans to get hfi1 under the same maintainer
to work through this transitional period.

Basically, At what point should we stop submitting patches to Greg and start
submitting to Doug?

Should we consider the merge window itself as the swap over point and submit
changes to Doug at that point?  If so, should we continue to submit what we can
to Greg until then (and continue rebase'ing the series below on that work)?  Or
given Gregs backlog, should we stop submitting to Greg sometime prior to the
merge window?

That brings up my final question, at the point of swap over I assume anything
not accepted by Greg should be considered rejected and we need to resubmit to
Doug?

Thanks in advance for any guidance,
Ira


On Mon, Dec 14, 2015 at 12:27:49PM -0500, Dalessandro, Dennis wrote:
> This patch series is being submitted as a Request For Comment only. It depends
> on code submitted to the rdma subsystem [1].
> 
> This work is the first submission aimed to satisfy the TODO item for removing
> duplicated code in hfi1. At the time of submission hfi1 and qib contained alot
> of duplicated verbs processing code. The qib driver is having similar changes
> made to use rdmavt. This will result in a common code base that both drivers 
> and
> future drivers such as soft-roce can use.
> 
> Note that due to the ongoing submission of hfi1 improvement patches, there 
> will
> likely be a number of conflicts which will still need to be resolved.
> 
> We also are still faced with the issue of separate trees for this work as was
> discussed previously [2]. The result of that conversation was to keep the
> drivers in separate trees until the 4.5 merge window. We are hoping that after
> this merge window a single maintainer can take control of hfi1, qib, and 
> rdmavt
> so that these patches can move forward and be applied.
> 
> For now though we would like to get feedback on these patches with more to
> follow.
> 
> [1] https://www.mail-archive.com/linux-rdma@vger.kernel.org/msg30074.html
> [2] https://www.mail-archive.com/linux-rdma%40vger.kernel.org/msg29360.html
> 
> ---
> 
> Dennis Dalessandro (15):
>   IB/hfi1: Begin to use rdmavt for verbs
>   IB/hfi1: Add basic rdmavt capability flags for hfi1
>   IB/hfi1: Consolidate dma ops for hfi1
>   IB/hfi1: Use rdmavt protection domain
>   IB/hfi1: Remove MR data structures from hfi1
>   IB/hfi1: Remove driver specific members from hfi1 qp type
>   IB/hfi1: Add device specific info prints
>   IB/hfi1: Use correct rdmavt header files after move.
>   IB/hfi1: Use address handle in rdmavt and remove from hfi1
>   IB/hfi1: Implement hfi1 support for AH notification
>   IB/hfi1: Remove hfi1 MR and hfi1 specific qp type
>   IB/hfi1: Remove srq from hfi1
>   IB/hfi1: Remove ibport and use rdmavt version
>   IB/hfi1: Remove mmap from hfi1
>   IB/hfi1: Use rdmavt pkey verbs function
> 
> 
>  drivers/staging/rdma/hfi1/Kconfig   |2 
>  drivers/staging/rdma/hfi1/Makefile  |4 
>  drivers/staging/rdma/hfi1/chip.c|   36 +-
>  drivers/staging/rdma/hfi1/common.h  |2 
>  drivers/staging/rdma/hfi1/cq.c  |   20 +
>  drivers/staging/rdma/hfi1/diag.c|   13 -
>  drivers/staging/rdma/hfi1/driver.c  |   31 +-
>  drivers/staging/rdma/hfi1/hfi.h |   27 +-
>  drivers/staging/rdma/hfi1/init.c|5 
>  drivers/staging/rdma/hfi1/intr.c|2 
>  drivers/staging/rdma/hfi1/keys.c|  356 -
>  drivers/staging/rdma/hfi1/mad.c |  163 +-
>  drivers/staging/rdma/hfi1/mmap.c|  192 ---
>  drivers/staging/rdma/hfi1/mr.c  |  522 --
>  drivers/staging/rdma/hfi1/pio.c |   10 -
>  drivers/staging/rdma/hfi1/qp.c  |  214 +++-
>  drivers/staging/rdma/hfi1/qp.h  |   44 +--
>  drivers/staging/rdma/hfi1/rc.c  |  155 +
>  drivers/staging/rdma/hfi1/ruc.c |  161 +
>  drivers/staging/rdma/hfi1/sdma.h|8 
>  drivers/staging/rdma/hfi1/srq.c |   58 ++-
>  drivers/staging/rdma/hfi1/sysfs.c   |   18 +
>  drivers/staging/rdma/hfi1/trace.h   |   22 +
>  drivers/staging/rdma/hfi1/uc.c  |   19 +
>  drivers/staging/rdma/hfi1/ud.c  |   91 +++--
>  drivers/staging/rdma/hfi1/verbs.c   |  526 
> +++
>  drivers/staging/rdma/hfi1/verbs.h   |  531 
>

[RFC PATCH 00/15] staging/rdma/hfi1: Initial patches to add rdmavt support in HFI1

2015-12-14 Thread Dennis Dalessandro 
This patch series is being submitted as a Request For Comment only. It depends
on code submitted to the rdma subsystem [1].

This work is the first submission aimed to satisfy the TODO item for removing
duplicated code in hfi1. At the time of submission hfi1 and qib contained alot
of duplicated verbs processing code. The qib driver is having similar changes
made to use rdmavt. This will result in a common code base that both drivers and
future drivers such as soft-roce can use.

Note that due to the ongoing submission of hfi1 improvement patches, there will
likely be a number of conflicts which will still need to be resolved.

We also are still faced with the issue of separate trees for this work as was
discussed previously [2]. The result of that conversation was to keep the
drivers in separate trees until the 4.5 merge window. We are hoping that after
this merge window a single maintainer can take control of hfi1, qib, and rdmavt
so that these patches can move forward and be applied.

For now though we would like to get feedback on these patches with more to
follow.

[1] https://www.mail-archive.com/linux-rdma@vger.kernel.org/msg30074.html
[2] https://www.mail-archive.com/linux-rdma%40vger.kernel.org/msg29360.html

---

Dennis Dalessandro (15):
  IB/hfi1: Begin to use rdmavt for verbs
  IB/hfi1: Add basic rdmavt capability flags for hfi1
  IB/hfi1: Consolidate dma ops for hfi1
  IB/hfi1: Use rdmavt protection domain
  IB/hfi1: Remove MR data structures from hfi1
  IB/hfi1: Remove driver specific members from hfi1 qp type
  IB/hfi1: Add device specific info prints
  IB/hfi1: Use correct rdmavt header files after move.
  IB/hfi1: Use address handle in rdmavt and remove from hfi1
  IB/hfi1: Implement hfi1 support for AH notification
  IB/hfi1: Remove hfi1 MR and hfi1 specific qp type
  IB/hfi1: Remove srq from hfi1
  IB/hfi1: Remove ibport and use rdmavt version
  IB/hfi1: Remove mmap from hfi1
  IB/hfi1: Use rdmavt pkey verbs function


 drivers/staging/rdma/hfi1/Kconfig   |2 
 drivers/staging/rdma/hfi1/Makefile  |4 
 drivers/staging/rdma/hfi1/chip.c|   36 +-
 drivers/staging/rdma/hfi1/common.h  |2 
 drivers/staging/rdma/hfi1/cq.c  |   20 +
 drivers/staging/rdma/hfi1/diag.c|   13 -
 drivers/staging/rdma/hfi1/driver.c  |   31 +-
 drivers/staging/rdma/hfi1/hfi.h |   27 +-
 drivers/staging/rdma/hfi1/init.c|5 
 drivers/staging/rdma/hfi1/intr.c|2 
 drivers/staging/rdma/hfi1/keys.c|  356 -
 drivers/staging/rdma/hfi1/mad.c |  163 +-
 drivers/staging/rdma/hfi1/mmap.c|  192 ---
 drivers/staging/rdma/hfi1/mr.c  |  522 --
 drivers/staging/rdma/hfi1/pio.c |   10 -
 drivers/staging/rdma/hfi1/qp.c  |  214 +++-
 drivers/staging/rdma/hfi1/qp.h  |   44 +--
 drivers/staging/rdma/hfi1/rc.c  |  155 +
 drivers/staging/rdma/hfi1/ruc.c |  161 +
 drivers/staging/rdma/hfi1/sdma.h|8 
 drivers/staging/rdma/hfi1/srq.c |   58 ++-
 drivers/staging/rdma/hfi1/sysfs.c   |   18 +
 drivers/staging/rdma/hfi1/trace.h   |   22 +
 drivers/staging/rdma/hfi1/uc.c  |   19 +
 drivers/staging/rdma/hfi1/ud.c  |   91 +++--
 drivers/staging/rdma/hfi1/verbs.c   |  526 +++
 drivers/staging/rdma/hfi1/verbs.h   |  531 ---
 drivers/staging/rdma/hfi1/verbs_mcast.c |   36 +-
 28 files changed, 843 insertions(+), 2425 deletions(-)
 delete mode 100644 drivers/staging/rdma/hfi1/keys.c
 delete mode 100644 drivers/staging/rdma/hfi1/mmap.c
 delete mode 100644 drivers/staging/rdma/hfi1/mr.c

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