[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20170831042812.GA3359@kroah.com>
Date: Thu, 31 Aug 2017 06:28:12 +0200
From: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To: Sherry Yang <sherryy@...roid.com>
Cc: "open list:ANDROID DRIVERS" <devel@...verdev.osuosl.org>,
Riley Andrews <riandrews@...roid.com>,
linux-kernel@...r.kernel.org,
Arve Hjønnevåg <arve@...roid.com>,
Martijn Coenen <maco@...gle.com>, Todd Kjos <tkjos@...gle.com>
Subject: Re: [PATCH v3 1/6] android: binder: Refactor prev and next buffer
into a helper function
On Wed, Aug 30, 2017 at 12:46:38PM -0700, Sherry Yang wrote:
> On Tue, Aug 29, 2017 at 11:07 PM, Greg Kroah-Hartman
> <gregkh@...uxfoundation.org> wrote:
> > On Tue, Aug 29, 2017 at 05:46:57PM -0700, Sherry Yang wrote:
> >> Use helper functions buffer_next and buffer_prev instead
> >> of list_entry to get the next and previous buffers.
> >>
> >> Signed-off-by: Sherry Yang <sherryy@...roid.com>
> >> ---
> >> drivers/android/binder_alloc.c | 24 +++++++++++++++---------
> >> 1 file changed, 15 insertions(+), 9 deletions(-)
> >
> > What changed from the previous version?
>
> This specific patch didn't change. The change is only in [patch v3
> 3/6] (crash fix) and in [patch v3 6/6] (new patch that add stats).
I need to know that :)
> > Always put the changes below the --- line. Like the documentation says
> > to do so.
>
> Do you mean I should use --annotate to git send-email to specify what
> has changed across versions for each patch? I used --compose and put
> what changed from v2 to v3 in the introductory message [patch 0/6].
I never got a patch 0/6 here, and honestly, almost always ignore them as
patches should be self-obvious :)
> > Also, don't I already have these patches in my tree? Do you want me to
> > revert the existing ones and use the new ones, or what about a fixup
> > patch for any differences?
>
> I got a message saying a test failed on [patch 3/5]. I resubmitted the
> entire thread because I wasn't sure if you would drop the failing
> patch set. If the entire failing patch set is dropped, then v3 can be
> used as a replacement.
Do you want me to revert all of these? I can not "drop" them as my tree
can not rebase. If it's just a simple fix, I'll gladly take that
instead.
> If you prefer a fixup patch, I can post another patch set (the crash
> fix and the new patch) on top of what you already applied, but it
> might be easier to do what's described in the previous paragraph (drop
> v2 and apply v3).
Ok, exactly what git commit ids should I revert from the tree? But
really, a fix would be easier at this point :)
thanks,
greg k-h
Powered by blists - more mailing lists