From: Greg KH <gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r@public.gmane.org>
To: "ira.weiny" <ira.weiny-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
Cc: devel-gWbeCf7V1WCQmaza687I9mD2FQJk+8+b@public.gmane.org,
dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org,
linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: Re: [PATCH v2 0/5] Clean up SDMA engine code
Date: Mon, 21 Dec 2015 16:13:49 -0800 [thread overview]
Message-ID: <20151222001349.GA27154@kroah.com> (raw)
In-Reply-To: <20151221234803.GL3860-W4f6Xiosr+yv7QzWx2u06xL4W9x8LtSr@public.gmane.org>
On Mon, Dec 21, 2015 at 06:48:03PM -0500, ira.weiny wrote:
> On Tue, Dec 08, 2015 at 05:10:08PM -0500, ira.weiny-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org wrote:
> > From: Ira Weiny <ira.weiny-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
> >
> > Various improvements to the SDMA engine code.
>
> Greg,
>
> Thanks for reviewing and accepting our patches to staging-testing. I apologize
> for the conflicts we had between the 3 of us submitting. However, in
> attempting to rework an internal branch to ensure this does not happen again I
> believe there were more conflicts than their should have been due to patches
> being accepted out of order.
>
> For example, I found the following error in your staging tree below.
>
> This series you applied in the following order which causes a build failure on
> the middle commit -- a0d4069.
>
> 483119a staging/rdma/hfi1: Unconditionally clean-up SDMA queues
> def8228 staging/rdma/hfi1: Convert to use get_user_pages_fast
> a0d4069 staging/rdma/hfi1: Add page lock limit check for SDMA requests
> faa98b8 staging/rdma/hfi1: Clean-up unnecessary goto statements
> 6a5464f staging/rdma/hfi1: Detect SDMA transmission error early
>
> The order as submitted was:
>
> staging/rdma/hfi1: Convert to use get_user_pages_fast
> staging/rdma/hfi1: Unconditionally clean-up SDMA queues
> staging/rdma/hfi1: Clean-up unnecessary goto statements
> staging/rdma/hfi1: Detect SDMA transmission error early
> staging/rdma/hfi1: Add page lock limit check for SDMA requests
>
>
>
> Do I need to resolve this somehow? Or is this something you resolve while the
> patches are in staging-testing?
>
> Is there something we need to do in the cover letter of a patch series to
> ensure order? Perhaps my cover letter implied these were not ordered? If so,
> I again apologize.
Did you number your patches? That's the only way to ensure that they
are applied in the correct order, that's what I sort on to apply them.
If you don't order them, I randomly guess, or just reject them...
All seems to build now, right?
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
next prev parent reply other threads:[~2015-12-22 0:13 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-12-08 22:10 [PATCH v2 0/5] Clean up SDMA engine code ira.weiny-ral2JQCrhuEAvxtiuMwx3w
[not found] ` <1449612613-6616-1-git-send-email-ira.weiny-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
2015-12-08 22:10 ` [PATCH v2 1/5] staging/rdma/hfi1: Convert to use get_user_pages_fast ira.weiny-ral2JQCrhuEAvxtiuMwx3w
2015-12-08 22:10 ` [PATCH v2 2/5] staging/rdma/hfi1: Unconditionally clean-up SDMA queues ira.weiny-ral2JQCrhuEAvxtiuMwx3w
2015-12-08 22:10 ` [PATCH v2 3/5] staging/rdma/hfi1: Clean-up unnecessary goto statements ira.weiny-ral2JQCrhuEAvxtiuMwx3w
2015-12-08 22:10 ` [PATCH v2 4/5] staging/rdma/hfi1: Detect SDMA transmission error early ira.weiny-ral2JQCrhuEAvxtiuMwx3w
2015-12-08 22:10 ` [PATCH v2 5/5] staging/rdma/hfi1: Add page lock limit check for SDMA requests ira.weiny-ral2JQCrhuEAvxtiuMwx3w
2015-12-21 23:48 ` [PATCH v2 0/5] Clean up SDMA engine code ira.weiny
[not found] ` <20151221234803.GL3860-W4f6Xiosr+yv7QzWx2u06xL4W9x8LtSr@public.gmane.org>
2015-12-22 0:13 ` Greg KH [this message]
[not found] ` <20151222001349.GA27154-U8xfFu+wG4EAvxtiuMwx3w@public.gmane.org>
2015-12-22 0:26 ` ira.weiny
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20151222001349.GA27154@kroah.com \
--to=gregkh-hqyy1w1ycw8ekmwlsbkhg0b+6bgklq7r@public.gmane.org \
--cc=devel-gWbeCf7V1WCQmaza687I9mD2FQJk+8+b@public.gmane.org \
--cc=dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org \
--cc=ira.weiny-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org \
--cc=linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.