All of lore.kernel.org
 help / color / mirror / Atom feed
From: olof@lixom.net (Olof Johansson)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v2 0/4] Device Tree updates of UniPhier SoCs for Linux 4.3
Date: Thu, 13 Aug 2015 11:27:21 +0200	[thread overview]
Message-ID: <20150813092721.GF30160@localhost> (raw)
In-Reply-To: <CAK7LNAS_Tx=-it9LFg1K7i-URu1Dx_2xnHPkgM1KJkBFb9q4ig@mail.gmail.com>

On Wed, Aug 12, 2015 at 10:39:47PM +0900, Masahiro Yamada wrote:
> 2015-08-11 22:20 GMT+09:00 Olof Johansson <olof@lixom.net>:
> > On Thu, Aug 06, 2015 at 07:37:44PM +0900, Masahiro Yamada wrote:
> >> Hi Olof and Arnd,
> >>
> >> Here are a little more updates for device trees for UniPhier SoCs.
> >>
> >> Please consider applying this series to your ARM-SOC tree.
> >>
> >> Thanks!
> >
> > Hi,
> >
> > Please always comment on when the previous when you respin. I didn't
> > see this thread until after I had applied v1.
> >
> > I've taken 2/4 directly now, since it's the only difference.
> 
> 
> Instead, build fails between commit a5e921b4771 and 63ef577d9
> because 2/4 is a pre-requisite patch for 3/4 and /4/4.
> 
> 
> Maybe I should have sent a pull-request instead of patches.

The most important thing you should have done is followed up on the bad
patch series. Sending this as a pull request wouldn't have saved you if
you had just sent a second pull request without withdrawing the first one.

Sending patches and pull requests make little different for us for a new
platform with only a few patches per release. We still need to review
your code before we merge it. Actually, doing it as patches is sometimes
a bit easier since we can touch up trivial things instead of asking you
to redo the pull request.


-Olof

WARNING: multiple messages have this Message-ID (diff)
From: Olof Johansson <olof@lixom.net>
To: Masahiro Yamada <yamada.masahiro@socionext.com>
Cc: arm@kernel.org, Russell King <linux@arm.linux.org.uk>,
	devicetree@vger.kernel.org, Kumar Gala <galak@codeaurora.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Ian Campbell <ijc+devicetree@hellion.org.uk>,
	Rob Herring <robh+dt@kernel.org>, Pawel Moll <pawel.moll@arm.com>,
	Mark Rutland <mark.rutland@arm.com>,
	linux-arm-kernel <linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH v2 0/4] Device Tree updates of UniPhier SoCs for Linux 4.3
Date: Thu, 13 Aug 2015 11:27:21 +0200	[thread overview]
Message-ID: <20150813092721.GF30160@localhost> (raw)
In-Reply-To: <CAK7LNAS_Tx=-it9LFg1K7i-URu1Dx_2xnHPkgM1KJkBFb9q4ig@mail.gmail.com>

On Wed, Aug 12, 2015 at 10:39:47PM +0900, Masahiro Yamada wrote:
> 2015-08-11 22:20 GMT+09:00 Olof Johansson <olof@lixom.net>:
> > On Thu, Aug 06, 2015 at 07:37:44PM +0900, Masahiro Yamada wrote:
> >> Hi Olof and Arnd,
> >>
> >> Here are a little more updates for device trees for UniPhier SoCs.
> >>
> >> Please consider applying this series to your ARM-SOC tree.
> >>
> >> Thanks!
> >
> > Hi,
> >
> > Please always comment on when the previous when you respin. I didn't
> > see this thread until after I had applied v1.
> >
> > I've taken 2/4 directly now, since it's the only difference.
> 
> 
> Instead, build fails between commit a5e921b4771 and 63ef577d9
> because 2/4 is a pre-requisite patch for 3/4 and /4/4.
> 
> 
> Maybe I should have sent a pull-request instead of patches.

The most important thing you should have done is followed up on the bad
patch series. Sending this as a pull request wouldn't have saved you if
you had just sent a second pull request without withdrawing the first one.

Sending patches and pull requests make little different for us for a new
platform with only a few patches per release. We still need to review
your code before we merge it. Actually, doing it as patches is sometimes
a bit easier since we can touch up trivial things instead of asking you
to redo the pull request.


-Olof

  reply	other threads:[~2015-08-13  9:27 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-08-06 10:37 [PATCH v2 0/4] Device Tree updates of UniPhier SoCs for Linux 4.3 Masahiro Yamada
2015-08-06 10:37 ` Masahiro Yamada
2015-08-06 10:37 ` Masahiro Yamada
2015-08-06 10:37 ` [PATCH v2 1/4] ARM: dts: UniPhier: add I2C controller device nodes Masahiro Yamada
2015-08-06 10:37   ` Masahiro Yamada
2015-08-06 10:37 ` [PATCH v2 2/4] ARM: dts: UniPhier: add reference daughter board Masahiro Yamada
2015-08-06 10:37   ` Masahiro Yamada
2015-08-06 10:37   ` Masahiro Yamada
2015-08-06 10:37 ` [PATCH v2 3/4] ARM: dts: UniPhier: add PH1-Pro5 SoC support Masahiro Yamada
2015-08-06 10:37   ` Masahiro Yamada
2015-08-06 10:37   ` Masahiro Yamada
2015-08-06 10:37 ` [PATCH v2 4/4] ARM: dts: UniPhier: add ProXstream2 and PH1-LD6b SoC/board support Masahiro Yamada
2015-08-06 10:37   ` Masahiro Yamada
2015-08-11 13:20 ` [PATCH v2 0/4] Device Tree updates of UniPhier SoCs for Linux 4.3 Olof Johansson
2015-08-11 13:20   ` Olof Johansson
2015-08-11 13:20   ` Olof Johansson
2015-08-12 13:39   ` Masahiro Yamada
2015-08-12 13:39     ` Masahiro Yamada
2015-08-13  9:27     ` Olof Johansson [this message]
2015-08-13  9:27       ` Olof Johansson

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=20150813092721.GF30160@localhost \
    --to=olof@lixom.net \
    --cc=linux-arm-kernel@lists.infradead.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.