All of lore.kernel.org
 help / color / mirror / Atom feed
From: Shawn Guo <shawnguo@kernel.org>
To: Borislav Petkov <bp@alien8.de>
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 16:33:50 +0800	[thread overview]
Message-ID: <20160829083350.GL30790@tiger> (raw)
In-Reply-To: <20160829080530.GA25468@nazgul.tnic>

On Mon, Aug 29, 2016 at 10:05:30AM +0200, Borislav Petkov wrote:
> On Mon, Aug 29, 2016 at 02:34:48PM +0800, Shawn Guo wrote:
> > Is it mandatory to have DTS changes go with driver part altogether?
> 
> Yes, because the EDAC driver needs them to even load properly.

When separate branches get merged on Linus tree, it works anyway.

> 
> > Otherwise, I prefer to have them go through separate tree.
> 
> Any particular reason why you prefer that?

To avoid potential merge conflicts.  Unless there are hard dependencies
like making it compile, avoiding regression or maintaining bisect,
patches should go through their established subsystem/architecture tree.

> We've been doing this for other ARM EDAC drivers already and there were
> no issues whatsoever.

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.

Shawn

WARNING: multiple messages have this Message-ID (diff)
From: Shawn Guo <shawnguo-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
To: Borislav Petkov <bp-Gina5bIWoIWzQB+pC5nmwQ@public.gmane.org>
Cc: York Sun <york.sun-3arQi8VN3Tc@public.gmane.org>,
	Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org>,
	yangbo lu <yangbo.lu-KZfg59tc24xl57MIdRCFDg@public.gmane.org>,
	Liu Gang <Gang.Liu-3arQi8VN3Tc@public.gmane.org>,
	morbidrsa-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org,
	linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
	Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org>,
	devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	Bhupesh Sharma
	<bhupesh.sharma-KZfg59tc24xl57MIdRCFDg@public.gmane.org>,
	Catalin Marinas <catalin.marinas-5wv7dgnIgG8@public.gmane.org>,
	Will Deacon <will.deacon-5wv7dgnIgG8@public.gmane.org>,
	stuart.yoder-3arQi8VN3Tc@public.gmane.org,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	oss-fOR+EgIDQEHk1uMJSBkQmQ@public.gmane.org,
	Rob Herring <robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>,
	Rajesh Bhagat
	<rajesh.bhagat-KZfg59tc24xl57MIdRCFDg@public.gmane.org>,
	Olof Johansson <olof-nZhT3qVonbNeoWH0uzbU5w@public.gmane.org>,
	Mingkai Hu <Mingkai.Hu-KZfg59tc24xl57MIdRCFDg@public.gmane.org>,
	Li Yang <leoli-KZfg59tc24xl57MIdRCFDg@public.gmane.org>,
	Yuan Yao <yao.yuan-3arQi8VN3Tc@public.gmane.org>,
	linux-edac-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: Re: [Patch v4 9/9] arm64: Update device tree for Layerscape SoCs
Date: Mon, 29 Aug 2016 16:33:50 +0800	[thread overview]
Message-ID: <20160829083350.GL30790@tiger> (raw)
In-Reply-To: <20160829080530.GA25468-K5JNixvcfoxupOikMc4+xw@public.gmane.org>

On Mon, Aug 29, 2016 at 10:05:30AM +0200, Borislav Petkov wrote:
> On Mon, Aug 29, 2016 at 02:34:48PM +0800, Shawn Guo wrote:
> > Is it mandatory to have DTS changes go with driver part altogether?
> 
> Yes, because the EDAC driver needs them to even load properly.

When separate branches get merged on Linus tree, it works anyway.

> 
> > Otherwise, I prefer to have them go through separate tree.
> 
> Any particular reason why you prefer that?

To avoid potential merge conflicts.  Unless there are hard dependencies
like making it compile, avoiding regression or maintaining bisect,
patches should go through their established subsystem/architecture tree.

> We've been doing this for other ARM EDAC drivers already and there were
> no issues whatsoever.

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.

Shawn
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

WARNING: multiple messages have this Message-ID (diff)
From: shawnguo@kernel.org (Shawn Guo)
To: linux-arm-kernel@lists.infradead.org
Subject: [Patch v4 9/9] arm64: Update device tree for Layerscape SoCs
Date: Mon, 29 Aug 2016 16:33:50 +0800	[thread overview]
Message-ID: <20160829083350.GL30790@tiger> (raw)
In-Reply-To: <20160829080530.GA25468@nazgul.tnic>

On Mon, Aug 29, 2016 at 10:05:30AM +0200, Borislav Petkov wrote:
> On Mon, Aug 29, 2016 at 02:34:48PM +0800, Shawn Guo wrote:
> > Is it mandatory to have DTS changes go with driver part altogether?
> 
> Yes, because the EDAC driver needs them to even load properly.

When separate branches get merged on Linus tree, it works anyway.

> 
> > Otherwise, I prefer to have them go through separate tree.
> 
> Any particular reason why you prefer that?

To avoid potential merge conflicts.  Unless there are hard dependencies
like making it compile, avoiding regression or maintaining bisect,
patches should go through their established subsystem/architecture tree.

> We've been doing this for other ARM EDAC drivers already and there were
> no issues whatsoever.

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.

Shawn

  reply	other threads:[~2016-08-29  8:34 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 [this message]
2016-08-29  8:33         ` Shawn Guo
2016-08-29  8:33         ` Shawn Guo
2016-08-29 13:51         ` Borislav Petkov
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=20160829083350.GL30790@tiger \
    --to=shawnguo@kernel.org \
    --cc=Gang.Liu@nxp.com \
    --cc=Mingkai.Hu@freescale.com \
    --cc=arnd@arndb.de \
    --cc=bhupesh.sharma@freescale.com \
    --cc=bp@alien8.de \
    --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=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.