From: Borislav Petkov <bp@alien8.de>
To: Shawn Guo <shawnguo@kernel.org>
Cc: York Sun <york.sun@nxp.com>, Mark Rutland <mark.rutland@arm.com>,
yangbo lu <yangbo.lu@freescale.com>, Liu Gang <Gang.Liu@nxp.com>,
morbidrsa@gmail.com, linux-arm-kernel@lists.infradead.org,
Arnd Bergmann <arnd@arndb.de>,
devicetree@vger.kernel.org,
Bhupesh Sharma <bhupesh.sharma@freescale.com>,
Catalin Marinas <catalin.marinas@arm.com>,
Will Deacon <will.deacon@arm.com>,
stuart.yoder@nxp.com, linux-kernel@vger.kernel.org,
oss@buserror.net, Rob Herring <robh+dt@kernel.org>,
Rajesh Bhagat <rajesh.bhagat@freescale.com>,
Olof Johansson <olof@lixom.net>,
Mingkai Hu <Mingkai.Hu@freescale.com>,
Li Yang <leoli@freescale.com>, Yuan Yao <yao.yuan@nxp.com>,
linux-edac@vger.kernel.org
Subject: Re: [Patch v4 9/9] arm64: Update device tree for Layerscape SoCs
Date: Mon, 29 Aug 2016 15:51:30 +0200 [thread overview]
Message-ID: <20160829135130.GB28806@nazgul.tnic> (raw)
In-Reply-To: <20160829083350.GL30790@tiger>
On Mon, Aug 29, 2016 at 04:33:50PM +0800, Shawn Guo wrote:
> To avoid potential merge conflicts.
Haven't heard of any so far. And I don't see how adding 1 or 2 DT
entries more per driver is a serious merge conflict.
> Unless there are hard dependencies like making it compile, avoiding
> regression or maintaining bisect, patches should go through their
> established subsystem/architecture tree.
Well, doh, the driver simply doesn't work. How are people even supposed
to test the EDAC tree?
Why is it even such a big deal if it is acked by the proper maintainers?
Cross-tree maintainer acking happens all the time. So don't tell me the
merge conflicts are your big issue with this.
> Luckily. If there are many patches on architecture DT branch changing
> the same file, when driver branch and DT branch merges in upstream
> branch, there will likely be merge conflicts.
So? There are tools to resolve those. And again, the DT changes for
EDAC are basically adding blocks so resolving those conflicts should be
trivial most of the time.
So no, I don't consider the potential merge conflicts an issue here.
--
Regards/Gruss,
Boris.
ECO tip #101: Trim your mails when you reply.
--
WARNING: multiple messages have this Message-ID (diff)
From: Borislav Petkov <bp@alien8.de>
To: Shawn Guo <shawnguo@kernel.org>
Cc: Mark Rutland <mark.rutland@arm.com>,
devicetree@vger.kernel.org, Liu Gang <Gang.Liu@nxp.com>,
morbidrsa@gmail.com, linux-edac@vger.kernel.org,
Arnd Bergmann <arnd@arndb.de>,
Bhupesh Sharma <bhupesh.sharma@freescale.com>,
Catalin Marinas <catalin.marinas@arm.com>,
Will Deacon <will.deacon@arm.com>,
stuart.yoder@nxp.com, linux-kernel@vger.kernel.org,
oss@buserror.net, Rob Herring <robh+dt@kernel.org>,
Rajesh Bhagat <rajesh.bhagat@freescale.com>,
Yuan Yao <yao.yuan@nxp.com>, Olof Johansson <olof@lixom.net>,
York Sun <york.sun@nxp.com>, Li Yang <leoli@freescale.com>,
Mingkai Hu <Mingkai.Hu@freescale.com>,
linux-arm-kernel@lists.infradead.org,
yangbo lu <yangbo.lu@freescale.com>
Subject: Re: [Patch v4 9/9] arm64: Update device tree for Layerscape SoCs
Date: Mon, 29 Aug 2016 15:51:30 +0200 [thread overview]
Message-ID: <20160829135130.GB28806@nazgul.tnic> (raw)
In-Reply-To: <20160829083350.GL30790@tiger>
On Mon, Aug 29, 2016 at 04:33:50PM +0800, Shawn Guo wrote:
> To avoid potential merge conflicts.
Haven't heard of any so far. And I don't see how adding 1 or 2 DT
entries more per driver is a serious merge conflict.
> Unless there are hard dependencies like making it compile, avoiding
> regression or maintaining bisect, patches should go through their
> established subsystem/architecture tree.
Well, doh, the driver simply doesn't work. How are people even supposed
to test the EDAC tree?
Why is it even such a big deal if it is acked by the proper maintainers?
Cross-tree maintainer acking happens all the time. So don't tell me the
merge conflicts are your big issue with this.
> Luckily. If there are many patches on architecture DT branch changing
> the same file, when driver branch and DT branch merges in upstream
> branch, there will likely be merge conflicts.
So? There are tools to resolve those. And again, the DT changes for
EDAC are basically adding blocks so resolving those conflicts should be
trivial most of the time.
So no, I don't consider the potential merge conflicts an issue here.
--
Regards/Gruss,
Boris.
ECO tip #101: Trim your mails when you reply.
--
WARNING: multiple messages have this Message-ID (diff)
From: bp@alien8.de (Borislav Petkov)
To: linux-arm-kernel@lists.infradead.org
Subject: [Patch v4 9/9] arm64: Update device tree for Layerscape SoCs
Date: Mon, 29 Aug 2016 15:51:30 +0200 [thread overview]
Message-ID: <20160829135130.GB28806@nazgul.tnic> (raw)
In-Reply-To: <20160829083350.GL30790@tiger>
On Mon, Aug 29, 2016 at 04:33:50PM +0800, Shawn Guo wrote:
> To avoid potential merge conflicts.
Haven't heard of any so far. And I don't see how adding 1 or 2 DT
entries more per driver is a serious merge conflict.
> Unless there are hard dependencies like making it compile, avoiding
> regression or maintaining bisect, patches should go through their
> established subsystem/architecture tree.
Well, doh, the driver simply doesn't work. How are people even supposed
to test the EDAC tree?
Why is it even such a big deal if it is acked by the proper maintainers?
Cross-tree maintainer acking happens all the time. So don't tell me the
merge conflicts are your big issue with this.
> Luckily. If there are many patches on architecture DT branch changing
> the same file, when driver branch and DT branch merges in upstream
> branch, there will likely be merge conflicts.
So? There are tools to resolve those. And again, the DT changes for
EDAC are basically adding blocks so resolving those conflicts should be
trivial most of the time.
So no, I don't consider the potential merge conflicts an issue here.
--
Regards/Gruss,
Boris.
ECO tip #101: Trim your mails when you reply.
--
next prev parent reply other threads:[~2016-08-29 14:42 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-08-09 21:59 [Patch v4 9/9] arm64: Update device tree for Layerscape SoCs York Sun
2016-08-09 21:59 ` York Sun
2016-08-09 21:59 ` York Sun
2016-08-12 9:13 ` Borislav Petkov
2016-08-12 9:13 ` Borislav Petkov
2016-08-12 9:13 ` Borislav Petkov
2016-08-29 6:34 ` Shawn Guo
2016-08-29 6:34 ` Shawn Guo
2016-08-29 6:34 ` Shawn Guo
2016-08-29 8:05 ` Borislav Petkov
2016-08-29 8:05 ` Borislav Petkov
2016-08-29 8:33 ` Shawn Guo
2016-08-29 8:33 ` Shawn Guo
2016-08-29 8:33 ` Shawn Guo
2016-08-29 13:51 ` Borislav Petkov [this message]
2016-08-29 13:51 ` Borislav Petkov
2016-08-29 13:51 ` Borislav Petkov
2016-08-29 15:10 ` Shawn Guo
2016-08-29 15:10 ` Shawn Guo
2016-08-29 15:10 ` Shawn Guo
2016-08-29 21:39 ` Olof Johansson
2016-08-29 21:39 ` Olof Johansson
2016-08-29 21:39 ` Olof Johansson
2016-08-30 5:17 ` Borislav Petkov
2016-08-30 5:17 ` Borislav Petkov
2016-08-30 5:17 ` Borislav Petkov
2016-08-23 21:37 ` york sun
2016-08-23 21:37 ` york sun
2016-08-23 21:37 ` york sun
2016-08-30 10:57 ` Shawn Guo
2016-08-30 10:57 ` Shawn Guo
2016-08-30 15:15 ` york sun
2016-08-30 15:15 ` york sun
2016-08-30 15:15 ` york sun
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=20160829135130.GB28806@nazgul.tnic \
--to=bp@alien8.de \
--cc=Gang.Liu@nxp.com \
--cc=Mingkai.Hu@freescale.com \
--cc=arnd@arndb.de \
--cc=bhupesh.sharma@freescale.com \
--cc=catalin.marinas@arm.com \
--cc=devicetree@vger.kernel.org \
--cc=leoli@freescale.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-edac@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=morbidrsa@gmail.com \
--cc=olof@lixom.net \
--cc=oss@buserror.net \
--cc=rajesh.bhagat@freescale.com \
--cc=robh+dt@kernel.org \
--cc=shawnguo@kernel.org \
--cc=stuart.yoder@nxp.com \
--cc=will.deacon@arm.com \
--cc=yangbo.lu@freescale.com \
--cc=yao.yuan@nxp.com \
--cc=york.sun@nxp.com \
/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.