On 2017/8/25 3:31, Doug Ledford wrote:
On Thu, 2017-08-24 at 16:34 +0800, oulijun wrote:
在 2017/8/24 15:35, Wei Hu (Xavier) 写道:
On 2017/8/21 20:57, Doug Ledford wrote:
On 8/21/2017 2:16 AM, oulijun wrote:
Hi, Doug Ledford
We are preparing the hip08 RoCE driver for upstreaming. I
am found that
you have create a new branch named net-next-base and this
branch has
included
hns3 patchset. If we generate patchset of hip08 RoCE driver,
can
directly based
on this branch?
Yes.
Hi, Doug
In the repo https://git.kernel.org/pub/scm/linux/kernel/git/dled
ford/rdma.git,
we found for-next-merged branch looks newer than k.o/net-next-
base, right ?
please reconfirm which branch we should generate patcheset based
on.
Thank you very much!
1. k.o/for-next-merged branch
git log --oneline drivers/infiniband/hw/hns/
b0e32e2 Merge branch 'k.o/for-4.13-rc' into k.o/for-next
5b59a39 IB/hns: fix memory leak on ah on error return path
3e5f088 IB/hns: Avoid compile test under non 64bit environments
8ccf098 Revert "RDMA/hns: fix build regression"
5db465f IB/hns: checking for IS_ERR() instead of NULL
967de35 IB/hns: include linux/interrupt.h
ecd840f RDMA/hns: fix build regression
d1d7149 IB/hns: fix semicolon.cocci warnings
87809f8 IB/hns: fix returnvar.cocci warnings
3756c7f IB/hns: fix boolreturn.cocci warnings
e89bf46 IB/hns: Support compile test for hns RoCE driver
5f110ac4 IB/hns: Fix for checkpatch.pl comment style warnings
d322f00 IB/hns: Fix the bug with modifying the MAC address without
removing the driver
9de61d3 IB/hns: Fix the bug with rdma operation
58c4f0d IB/hns: Fix the bug with wild pointer when destroy rc qp
2. k.o/net-next-base
git log --oneline drivers/infiniband/hw/hns/
5db465f IB/hns: checking for IS_ERR() instead of NULL
5f110ac4 IB/hns: Fix for checkpatch.pl comment style warnings
d322f00 IB/hns: Fix the bug with modifying the MAC address without
removing the driver
9de61d3 IB/hns: Fix the bug with rdma operation
58c4f0d IB/hns: Fix the bug with wild pointer when destroy rc qp
Regards
Wei Hu
Please use net-next-base. Doug have comfirm. Please refer to his
reply for this email.
The net-next-based branch is not intended to go to the next kernel
merge window, it's destined for the merge window after that. If you
don't need anything in net-next-based, then use for-next instead.
That's what will actually be going to Linus.
As for what's newer, the for-next-merged branch is everything merged
together (for-4.13-rc, for-next, and net-next-based), and I really only
have it there for one reason: so I can put the for-next tag on it and
Stephen Rothwell can then pull it into his for-next kernel testing. I
put stuff in there (the net-next-based branch) that isn't going into
the next merge window so that it gets early for-next testing, but that
doesn't mean it is actually going into for-next.
So, like I said, use the for-next branch unless you absolutely depend
on code in the net-next-based branch, and if you do, it means the
submission will flow through into the second merge window instead of
the next merge window.
Thanks , Doug.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
