From: Tony Lindgren <tony@atomide.com> To: Boris Brezillon <boris.brezillon@free-electrons.com> Cc: Roger Quadros <rogerq@ti.com>, javier@dowhile0.org, fcooper@ti.com, nsekhar@ti.com, linux-mtd@lists.infradead.org, linux-omap@vger.kernel.org, computersforpeace@gmail.com, dwmw2@infradead.org, ezequiel@vanguardiasur.com.ar, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v6 00/17] memory: omap-gpmc: mtd: nand: Support GPMC NAND on non-OMAP platforms Date: Fri, 15 Apr 2016 09:19:51 -0700 [thread overview] Message-ID: <20160415161950.GT5995@atomide.com> (raw) In-Reply-To: <20160415180531.15d790d2@bbrezillon> * Boris Brezillon <boris.brezillon@free-electrons.com> [160415 09:06]: > On Fri, 15 Apr 2016 08:41:40 -0700 > Tony Lindgren <tony@atomide.com> wrote: > > 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. > > How would you do it in this particular case. Say I have to provide you > with an immutable branch, it should only contain Roger's patches, right? Well ideally it would be just minimal NAND related changes branch against v4.6-rc1. Then if Roger has a dependency to that, Roger can pull it in. Then Roger would make a branch for the GPMC changes against your minimal NAND branch. Then if there were non-trivial merge conflicts, I could pull in Roger's GPMC branch as needed. But in this case, it seems you can just merge everything via the NAND tree and problem solved. > But this also means this immutable branch has to be pulled into my > nand/next branch before all other changes touching the same set of > files, which in turn means that I'll have to rebase and push -f my > nand/next branch (which I'd like to avoid). Yeah let's not do rebases, there should be no need for it. > Or should I just pull this immutable branch in my current nand/next and > let you pull the same immutable branch in omap-soc. I mean, would this > prevent conflicts when our branches are merged into linux-next, no > matter the order. Ideally just one or more branches with just minimal changes in them against -rc1. But you may have other dependencies in your NAND tree so that may no longer be doable :) Usually if I merge something that may need to get merged into other branches, I just apply them into a separate branch against -rc1 to start with, then merge that branch in. Regards, Tony
WARNING: multiple messages have this Message-ID (diff)
From: Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org> To: Boris Brezillon <boris.brezillon-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org> Cc: Roger Quadros <rogerq-l0cyMroinI0@public.gmane.org>, javier-0uQlZySMnqxg9hUCZPvPmw@public.gmane.org, fcooper-l0cyMroinI0@public.gmane.org, nsekhar-l0cyMroinI0@public.gmane.org, linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org, linux-omap-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, computersforpeace-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org, dwmw2-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org, ezequiel-30ULvvUtt6G51wMPkGsGjgyUoB5FGQPZ@public.gmane.org, devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org Subject: Re: [PATCH v6 00/17] memory: omap-gpmc: mtd: nand: Support GPMC NAND on non-OMAP platforms Date: Fri, 15 Apr 2016 09:19:51 -0700 [thread overview] Message-ID: <20160415161950.GT5995@atomide.com> (raw) In-Reply-To: <20160415180531.15d790d2@bbrezillon> * Boris Brezillon <boris.brezillon-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org> [160415 09:06]: > On Fri, 15 Apr 2016 08:41:40 -0700 > Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org> wrote: > > 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. > > How would you do it in this particular case. Say I have to provide you > with an immutable branch, it should only contain Roger's patches, right? Well ideally it would be just minimal NAND related changes branch against v4.6-rc1. Then if Roger has a dependency to that, Roger can pull it in. Then Roger would make a branch for the GPMC changes against your minimal NAND branch. Then if there were non-trivial merge conflicts, I could pull in Roger's GPMC branch as needed. But in this case, it seems you can just merge everything via the NAND tree and problem solved. > But this also means this immutable branch has to be pulled into my > nand/next branch before all other changes touching the same set of > files, which in turn means that I'll have to rebase and push -f my > nand/next branch (which I'd like to avoid). Yeah let's not do rebases, there should be no need for it. > Or should I just pull this immutable branch in my current nand/next and > let you pull the same immutable branch in omap-soc. I mean, would this > prevent conflicts when our branches are merged into linux-next, no > matter the order. Ideally just one or more branches with just minimal changes in them against -rc1. But you may have other dependencies in your NAND tree so that may no longer be doable :) Usually if I merge something that may need to get merged into other branches, I just apply them into a separate branch against -rc1 to start with, then merge that branch in. Regards, Tony -- 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
next prev parent reply other threads:[~2016-04-15 16:19 UTC|newest] Thread overview: 93+ messages / expand[flat|nested] mbox.gz Atom feed top 2016-04-07 10:08 [PATCH v6 00/17] memory: omap-gpmc: mtd: nand: Support GPMC NAND on non-OMAP platforms Roger Quadros 2016-04-07 10:08 ` Roger Quadros 2016-04-07 10:08 ` [PATCH v6 01/17] ARM: OMAP2+: gpmc: Add platform data Roger Quadros 2016-04-07 10:08 ` Roger Quadros 2016-04-07 10:08 ` [PATCH v6 02/17] ARM: OMAP2+: gpmc: Add gpmc timings and settings to " Roger Quadros 2016-04-07 10:08 ` Roger Quadros 2016-04-07 10:08 ` [PATCH v6 03/17] memory: omap-gpmc: Introduce GPMC to NAND interface Roger Quadros 2016-04-07 10:08 ` Roger Quadros 2016-04-07 10:08 ` [PATCH v6 04/17] memory: omap-gpmc: Add GPMC-NAND ops to get writebufferempty status Roger Quadros 2016-04-07 10:08 ` Roger Quadros 2016-04-07 10:08 ` [PATCH v6 05/17] memory: omap-gpmc: Implement IRQ domain for NAND IRQs Roger Quadros 2016-04-07 10:08 ` Roger Quadros 2016-04-11 14:52 ` Rob Herring 2016-04-11 14:52 ` Rob Herring 2016-04-07 10:08 ` [PATCH v6 06/17] mtd: nand: omap: Use gpmc_omap_get_nand_ops() to get NAND registers Roger Quadros 2016-04-07 10:08 ` Roger Quadros 2016-04-07 10:08 ` [PATCH v6 07/17] mtd: nand: omap: Switch to using GPMC-NAND ops for writebuffer empty check Roger Quadros 2016-04-07 10:08 ` Roger Quadros 2016-04-07 10:08 ` [PATCH v6 08/17] mtd: nand: omap: Copy platform data parameters to omap_nand_info data Roger Quadros 2016-04-07 10:08 ` Roger Quadros 2016-04-07 10:08 ` [PATCH v6 09/17] mtd: nand: omap: Clean up device tree support Roger Quadros 2016-04-07 10:08 ` Roger Quadros 2016-04-07 10:08 ` [PATCH v6 10/17] mtd: nand: omap: Update DT binding documentation Roger Quadros 2016-04-07 10:08 ` Roger Quadros 2016-04-07 10:08 ` [PATCH v6 11/17] memory: omap-gpmc: Prevent mapping into 1st 16MB Roger Quadros 2016-04-07 10:08 ` Roger Quadros 2016-04-07 10:08 ` [PATCH v6 12/17] memory: omap-gpmc: Move device tree binding to correct location Roger Quadros 2016-04-07 10:08 ` Roger Quadros 2016-04-07 10:08 ` [PATCH v6 13/17] memory: omap-gpmc: Support general purpose input for WAITPINs Roger Quadros 2016-04-07 10:08 ` Roger Quadros 2016-04-11 15:00 ` Rob Herring 2016-04-11 15:00 ` Rob Herring 2016-04-07 10:08 ` [PATCH v6 14/17] memory: omap-gpmc: Reserve WAITPIN if needed for WAIT monitoring Roger Quadros 2016-04-07 10:08 ` Roger Quadros 2016-04-07 10:08 ` [PATCH v6 15/17] memory: omap-gpmc: Support WAIT pin edge interrupts Roger Quadros 2016-04-07 10:08 ` Roger Quadros 2016-04-11 15:03 ` Rob Herring 2016-04-11 15:03 ` Rob Herring 2016-04-07 10:08 ` [PATCH v6 16/17] memory: omap-gpmc: Prevent GPMC_STATUS from being accessed via gpmc_regs Roger Quadros 2016-04-07 10:08 ` Roger Quadros 2016-04-07 10:08 ` [PATCH v6 17/17] mtd: nand: omap2: Implement NAND ready using gpiolib Roger Quadros 2016-04-07 10:08 ` Roger Quadros 2016-04-11 15:04 ` Rob Herring 2016-04-11 15:04 ` Rob Herring 2016-04-13 21:25 ` [PATCH v6 00/17] memory: omap-gpmc: mtd: nand: Support GPMC NAND on non-OMAP platforms Tony Lindgren 2016-04-13 21:25 ` Tony Lindgren 2016-04-15 9:34 ` Roger Quadros 2016-04-15 9:34 ` Roger Quadros 2016-04-15 10:09 ` Boris Brezillon 2016-04-15 10:09 ` Boris Brezillon 2016-04-15 10:54 ` Roger Quadros 2016-04-15 10:54 ` Roger Quadros 2016-04-15 11:12 ` Boris Brezillon 2016-04-15 11:12 ` Boris Brezillon 2016-04-15 11:51 ` Boris Brezillon 2016-04-15 11:51 ` Boris Brezillon 2016-04-15 15:41 ` Tony Lindgren 2016-04-15 15:41 ` Tony Lindgren 2016-04-15 16:05 ` Boris Brezillon 2016-04-15 16:05 ` Boris Brezillon 2016-04-15 16:19 ` Tony Lindgren [this message] 2016-04-15 16:19 ` Tony Lindgren 2016-04-16 8:57 ` Boris Brezillon 2016-04-18 12:31 ` Roger Quadros 2016-04-18 12:31 ` Roger Quadros 2016-04-18 12:52 ` Roger Quadros 2016-04-18 12:52 ` Roger Quadros 2016-04-18 13:13 ` Boris Brezillon 2016-04-18 13:13 ` Boris Brezillon 2016-04-18 13:48 ` Roger Quadros 2016-04-18 13:48 ` Roger Quadros 2016-04-18 14:10 ` Boris Brezillon 2016-04-18 14:10 ` Boris Brezillon 2016-04-18 14:39 ` Roger Quadros 2016-04-18 14:39 ` Roger Quadros 2016-04-18 14:57 ` Boris Brezillon 2016-04-18 14:57 ` Boris Brezillon 2016-04-19 12:46 ` Roger Quadros 2016-04-19 12:46 ` Roger Quadros 2016-04-19 12:50 ` Boris Brezillon 2016-04-19 12:50 ` Boris Brezillon 2016-04-19 20:11 ` Boris Brezillon 2016-04-19 20:11 ` Boris Brezillon 2016-04-20 8:58 ` Roger Quadros 2016-04-20 8:58 ` Roger Quadros 2016-04-20 14:45 ` Tony Lindgren 2016-04-20 14:45 ` Tony Lindgren 2016-04-19 13:22 ` Boris Brezillon 2016-04-19 13:22 ` Boris Brezillon 2016-04-19 14:26 ` Roger Quadros 2016-04-19 14:26 ` Roger Quadros 2016-04-19 14:49 ` Roger Quadros 2016-04-19 14:49 ` Roger Quadros
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=20160415161950.GT5995@atomide.com \ --to=tony@atomide.com \ --cc=boris.brezillon@free-electrons.com \ --cc=computersforpeace@gmail.com \ --cc=devicetree@vger.kernel.org \ --cc=dwmw2@infradead.org \ --cc=ezequiel@vanguardiasur.com.ar \ --cc=fcooper@ti.com \ --cc=javier@dowhile0.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-mtd@lists.infradead.org \ --cc=linux-omap@vger.kernel.org \ --cc=nsekhar@ti.com \ --cc=rogerq@ti.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: linkBe 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.