linux-kernel - Re: [PATCH v6 00/17] memory: omap-gpmc: mtd: nand: Support GPMC NAND on non-OMAP platforms

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20160415154139.GS5995@atomide.com>
Date:	Fri, 15 Apr 2016 08:41:40 -0700
From:	Tony Lindgren <tony@...mide.com>
To:	Boris Brezillon <boris.brezillon@...e-electrons.com>
Cc:	Roger Quadros <rogerq@...com>, javier@...hile0.org, fcooper@...com,
	nsekhar@...com, linux-mtd@...ts.infradead.org,
	linux-omap@...r.kernel.org, computersforpeace@...il.com,
	dwmw2@...radead.org, ezequiel@...guardiasur.com.ar,
	devicetree@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v6 00/17] memory: omap-gpmc: mtd: nand: Support GPMC NAND
 on non-OMAP platforms

* Boris Brezillon <boris.brezillon@...e-electrons.com> [160415 04:52]:
> Roger, Tony,
> 
> On Fri, 15 Apr 2016 13:54:34 +0300
> Roger Quadros <rogerq@...com> wrote:
> 
> > On 15/04/16 13:09, Boris Brezillon wrote:
> > > Hi Roger,
> > > 
> > > On Fri, 15 Apr 2016 12:34:04 +0300
> > > Roger Quadros <rogerq@...com> wrote:
> > > 
> > >> Tony & Boris,
> > >>
> > >> On 14/04/16 00:25, Tony Lindgren wrote:
> > >>> * Roger Quadros <rogerq@...com> [160407 03:10]:
> > >>>> Hi,
> > >>>>
> > >>>> As this series has cross dependency between omap and mtd subsystems,
> > >>>> I'll set up a immutable branch which omap-soc and l2-mtd must
> > >>>> merge in together to avoid any conflicts/breakage during integration.
> > >>>>
> > >>>> Brian has acked all mtd patches. Tony needs to give his Ack for the
> > >>>> gpmc driver part and then I can provide the immutable branch.
> > >>>
> > >>> Looks good to me, please feel free to add:
> > >>>
> > >>> Acked-by: Tony Lindgren <tony@...mide.com>
> > >>>
> > >>
> > >> I've added Tony and Rob's Acked-by tags and pushed the patches at the
> > >> below PULL request.
> > >>
> > >> Please take this into omap-soc and l2-mtd trees. Thanks.
> > > 
> > > I Pulled this branch into nand/next and had to resolve a few conflicts
> > > (as you may have noticed, a few other reworks in the NAND and MTD layer
> > > have been merged in the meantime).
> > 
> > OK. I'm not sure how well this will play when this merges into liunx-next
> > via the omap-soc tree.
> > 
> > Instead, can you please create a non-mutable nand/base for me (which could be
> > today's nand/next) and I can base my branch on that and Tony can use my
> > branch without causing any merge-conflict in linux-next?
> 
> I just created a branch called nand/for-gpmc-rework based on today's
> nand/next, but I'm still unsure how to proceed once you've rebased your
> work on this branch?
> 
> Tony will first have to pull my immutable branch, then pull yours, and
> then I'll have to pull an immutable branch from the the omap-soc tree
> to get your changes into my nand/next branch (in case other patches
> modify the same files before I send my PR). Am I missing something?
> If I'm not, then this option looks over-complicated to me.

Well why don't you merge it all via NAND then? I'm not seeing
any merge conflicts with the arch/arm/mach-omap* code.

> ITOH, if we decide to let your patches go through the nand or omap-soc
> tree, only one immutable branch will be created, and either the nand or
> omap-soc maintainer (depending on who takes the patches) will have to
> pull it into its -next branch.
> 
> I'm quite new to all this merging process, so don't hesitate to correct
> me if I'm wrong.

Well the rules are that if something agreed to be immutable, then
it will never get redone. And the immutable branch should be based
on the absolute minimal set of patches against some earlier tag,
usually -rc1 is a good one. This avoids other tree to need to pull
in a huge amount of changes from other trees just to avoid merge
conflicts.

Regards,

Tony