Message ID | 20120829001129.GO19437@titan.lakedaemon.net |
---|---|
State | New |
Headers | show |
Hi Jason, On Tue, Aug 28, 2012 at 08:11:29PM -0400, Jason Cooper wrote: > The following changes since commit 0d7614f09c1ebdbaa1599a5aba7593f147bf96ee: > > Linux 3.6-rc1 (2012-08-02 16:38:10 -0700) > > are available in the git repository at: > git://git.infradead.org/users/jcooper/linux.git boards-for-v3.7-v2 Hmm, this branch contains one duplicate patch due to me applying one straight to our fixes branch ("ARM: Kirkwood: Fix 'SZ_1M' undeclared here for db88f6281-bp-setup.c"). I also didn't see that mentioned in the pull request below, so I'm guessing you added it afterwards. There are also a couple of merge conflicts with other fixes we have already pulled in from you, it'd be nice if you just based this branch on those fixes instead. Also, I wonder if I could have you split up this branch a bit more? My suggestions are below. You can have branches build on top of each other where there are dependencies, just please point them out when you send the pull requests. Let me know if I'm unclear or if there's something that doesn't make sense, I'll be happy to help. -Olof > > Alan M Butler (1): > ARM: Kirkwood: Iomega ix2-200 DT support New board, so can stay in boards branch > > Arnaud Patard (3): > ARM: Kirkwood: Describe iconnect keys in DT. > ARM: Kirkwood: Describe iconnect nand in DT. dt branch material > ARM: Kirkwood: fix Makefile.boot fixes for 3.6, or fixes-non-critical that we pick up before anything else in 3.7, your choice. > Jason Cooper (5): > ARM: Kirkwood: board-dockstar: use linux/platform_data/mvsdio.h instead of plat/mvsdio.h > ARM: Kirkwood: use linux/platform_data/mv643xx.h instead of linux/mv643xx.h > ARM: Kirkwood: Kconfig: keep DT boards together Those would be cleanup > ARM: Kirkwood: update defconfig > ARM: Kirkwood: add DT boards to defconfig defconfig branch > > Sebastian Hesselbarth (2): > ARM: kirkwood: DT board setup for Seagate FreeAgent Dockstar > ARM: kirkwood: DT descriptor for Seagate FreeAgent Dockstar new boards, board branch > > Thomas Petazzoni (15): > arm: add documentation describing Marvell families of SoC SoC branch or board branch > mtd: orion_nand: remove <mach/hardware.h> include cleanup > arm: plat-orion: use 'void __iomem *' in addr-map code Hmm, I would prefer if the actual constants were annotated instead of cast in the code here. See how we handled that on tegra with IOMEM(). That will also help sparse catch unannotated uses of those constants. > arm: plat-orion: introduce PLAT_ORION_LEGACY hidden config option cleanup or soc > arm: plat-orion: make bridge_virt_base non-const to support DT use case Hm, dt I suppose. > arm: mvebu: add basic address decoding support to Armada 370/XP > arm: mvebu: add address decoding controller to the DT soc patches, I'd say > sound: kirkwood: remove useless <plat/audio.h> include > sound: kirkwood: move <plat/audio.h> to <linux/platform_data/kirkwood-audio.h> > usb: ehci-orion: move <plat/ehci-orion.h> to <linux/platform_data/ehci-orion.h> > mmc: mvsdio: move <plat/mvsdio.h> to <linux/platform_data/mvsdio.h> > dma: mv_xor: move <plat/mv_xor.h> to <linux/platform_data/mv_xor.h> > mtd: orion_nand: move <plat/orion_nand.h> to <linux/platform_data/orion_nand.h> > i2c: mv643xx: move <linux/mv643xx_i2c.h> to <linux/platform_data/mv643xx_i2c.h> > net: mv643xx_eth: move <linux/mv643xx_eth.h> to <linux/platform_data/mv643xx_eth.h> All above are cleanup. -Olof
Olof, Thanks for the help! On Tue, Sep 04, 2012 at 09:34:35PM -0700, Olof Johansson wrote: > On Tue, Aug 28, 2012 at 08:11:29PM -0400, Jason Cooper wrote: > > The following changes since commit 0d7614f09c1ebdbaa1599a5aba7593f147bf96ee: > > > > Linux 3.6-rc1 (2012-08-02 16:38:10 -0700) > > > > are available in the git repository at: > > git://git.infradead.org/users/jcooper/linux.git boards-for-v3.7-v2 > > Hmm, this branch contains one duplicate patch due to me applying one > straight to our fixes branch ("ARM: Kirkwood: Fix 'SZ_1M' undeclared here > for db88f6281-bp-setup.c"). I also didn't see that mentioned in the pull > request below, so I'm guessing you added it afterwards. There are also a > couple of merge conflicts with other fixes we have already pulled in from > you, it'd be nice if you just based this branch on those fixes instead. > > Also, I wonder if I could have you split up this branch a bit more? My > suggestions are below. You can have branches build on top of each other where > there are dependencies, just please point them out when you send the pull > requests. > > > Let me know if I'm unclear or if there's something that doesn't make sense, > I'll be happy to help. No problem, but I do have one question. Say I have two branches, fixes dt And then a 'board' patch depends on stuff in both fixes and dt. If I base the board branch on fixes, do I 'git merge' the dt branch, 'git cherry-pick' the dependency (what I did before), or something else I'm not aware of? I've avoided 'git merge' up till now because it creates a merge commit, which feels wrong. Perhaps I'm wrong here? All the branch assignments look good, assuming I can figure out the above question. > > ... > > arm: plat-orion: use 'void __iomem *' in addr-map code > > Hmm, I would prefer if the actual constants were annotated instead of cast in > the code here. See how we handled that on tegra with IOMEM(). That will also > help sparse catch unannotated uses of those constants. > I'll ask Thomas if he can redo this one. thx, Jason.
Hi, On Wed, Sep 5, 2012 at 4:44 PM, Jason Cooper <jason@lakedaemon.net> wrote: > Olof, > > Thanks for the help! > > On Tue, Sep 04, 2012 at 09:34:35PM -0700, Olof Johansson wrote: >> On Tue, Aug 28, 2012 at 08:11:29PM -0400, Jason Cooper wrote: >> > The following changes since commit 0d7614f09c1ebdbaa1599a5aba7593f147bf96ee: >> > >> > Linux 3.6-rc1 (2012-08-02 16:38:10 -0700) >> > >> > are available in the git repository at: >> > git://git.infradead.org/users/jcooper/linux.git boards-for-v3.7-v2 >> >> Hmm, this branch contains one duplicate patch due to me applying one >> straight to our fixes branch ("ARM: Kirkwood: Fix 'SZ_1M' undeclared here >> for db88f6281-bp-setup.c"). I also didn't see that mentioned in the pull >> request below, so I'm guessing you added it afterwards. There are also a >> couple of merge conflicts with other fixes we have already pulled in from >> you, it'd be nice if you just based this branch on those fixes instead. >> >> Also, I wonder if I could have you split up this branch a bit more? My >> suggestions are below. You can have branches build on top of each other where >> there are dependencies, just please point them out when you send the pull >> requests. >> >> >> Let me know if I'm unclear or if there's something that doesn't make sense, >> I'll be happy to help. > > No problem, but I do have one question. Say I have two branches, > > fixes > dt > > And then a 'board' patch depends on stuff in both fixes and dt. If I base > the board branch on fixes, do I 'git merge' the dt branch, 'git > cherry-pick' the dependency (what I did before), or something else I'm > not aware of? Merge is the way to go, otherwise you will have new commits with the same contents in the new branch. > I've avoided 'git merge' up till now because it creates a merge commit, > which feels wrong. Perhaps I'm wrong here? It depends on what phase of development you're in, but for something like this it's the perfectly sane thing to do. There's nothing wrong with a few merge commits to bring in dependencies, etc. > All the branch assignments look good, assuming I can figure out the > above question. Sounds good. I think the above is a sufficient answer but let me know if you disagree. :-) >> > arm: plat-orion: use 'void __iomem *' in addr-map code >> >> Hmm, I would prefer if the actual constants were annotated instead of cast in >> the code here. See how we handled that on tegra with IOMEM(). That will also >> help sparse catch unannotated uses of those constants. >> > > I'll ask Thomas if he can redo this one. Thanks! -Olof
On Tue, Sep 04, 2012 at 09:34:35PM -0700, Olof Johansson wrote: > Hi Jason, > > > On Tue, Aug 28, 2012 at 08:11:29PM -0400, Jason Cooper wrote: > > The following changes since commit 0d7614f09c1ebdbaa1599a5aba7593f147bf96ee: > > > > Linux 3.6-rc1 (2012-08-02 16:38:10 -0700) > > > > are available in the git repository at: > > git://git.infradead.org/users/jcooper/linux.git boards-for-v3.7-v2 > > Hmm, this branch contains one duplicate patch due to me applying one > straight to our fixes branch ("ARM: Kirkwood: Fix 'SZ_1M' undeclared here > for db88f6281-bp-setup.c"). I also didn't see that mentioned in the pull > request below, so I'm guessing you added it afterwards. There are also a > couple of merge conflicts with other fixes we have already pulled in from > you, it'd be nice if you just based this branch on those fixes instead. I'm issuing new pull-requests broken up as you suggested, based on v3.6-rc5, which incorporates my previous 'fixes-for-v3.6*' pull request. So, hopefully it should go much better. ;-) > Also, I wonder if I could have you split up this branch a bit more? My > suggestions are below. You can have branches build on top of each other where > there are dependencies, just please point them out when you send the pull > requests. Done. Migration from previous monolithic branch is as follows: > > > > Alan M Butler (1): > > ARM: Kirkwood: Iomega ix2-200 DT support > > New board, so can stay in boards branch Done, kirkwood/boards > > Arnaud Patard (3): > > ARM: Kirkwood: Describe iconnect keys in DT. > > ARM: Kirkwood: Describe iconnect nand in DT. > > dt branch material Done, kirkwood/dt > > ARM: Kirkwood: fix Makefile.boot > > fixes for 3.6, or fixes-non-critical that we pick up before anything else in > 3.7, your choice. dropped from PR, it's in v3.6-rc5 > > Jason Cooper (5): > > ARM: Kirkwood: board-dockstar: use linux/platform_data/mvsdio.h instead of plat/mvsdio.h > > ARM: Kirkwood: use linux/platform_data/mv643xx.h instead of linux/mv643xx.h > > ARM: Kirkwood: Kconfig: keep DT boards together > > Those would be cleanup Done, kirkwood/cleanup. Except #3 (keep DT boards together), I had to edit the original patch anyway (submitter new to git), so I incorporated the change in the original patch. It was purely menuconfig cosmetic. > > ARM: Kirkwood: update defconfig > > ARM: Kirkwood: add DT boards to defconfig > > defconfig branch Done, kirkwood/defconfig. Updated to include km_kirkwood. > > Sebastian Hesselbarth (2): > > ARM: kirkwood: DT board setup for Seagate FreeAgent Dockstar > > ARM: kirkwood: DT descriptor for Seagate FreeAgent Dockstar > > new boards, board branch Done, kirkwood/boards. > > Thomas Petazzoni (15): > > arm: add documentation describing Marvell families of SoC > > SoC branch or board branch Done, kirkwood/boards. > > mtd: orion_nand: remove <mach/hardware.h> include > > cleanup Taken in via l2-mtd.git, so dropped from my branches, will note the dependency. > > arm: plat-orion: use 'void __iomem *' in addr-map code > > Hmm, I would prefer if the actual constants were annotated instead of cast in > the code here. See how we handled that on tegra with IOMEM(). That will also > help sparse catch unannotated uses of those constants. > > > arm: plat-orion: introduce PLAT_ORION_LEGACY hidden config option > > cleanup or soc > > > arm: plat-orion: make bridge_virt_base non-const to support DT use case > > Hm, dt I suppose. > > > arm: mvebu: add basic address decoding support to Armada 370/XP > > arm: mvebu: add address decoding controller to the DT > > soc patches, I'd say The above block was one series. They have been dropped until Thomas can respond to your comment. > > sound: kirkwood: remove useless <plat/audio.h> include > > sound: kirkwood: move <plat/audio.h> to <linux/platform_data/kirkwood-audio.h> > > usb: ehci-orion: move <plat/ehci-orion.h> to <linux/platform_data/ehci-orion.h> > > mmc: mvsdio: move <plat/mvsdio.h> to <linux/platform_data/mvsdio.h> > > dma: mv_xor: move <plat/mv_xor.h> to <linux/platform_data/mv_xor.h> > > mtd: orion_nand: move <plat/orion_nand.h> to <linux/platform_data/orion_nand.h> > > i2c: mv643xx: move <linux/mv643xx_i2c.h> to <linux/platform_data/mv643xx_i2c.h> > > net: mv643xx_eth: move <linux/mv643xx_eth.h> to <linux/platform_data/mv643xx_eth.h> > > All above are cleanup. Done, kirkwood/cleanup. thx, Jason.
On Mon, Sep 10, 2012 at 01:48:35AM -0400, Jason Cooper wrote: > Arnd, Olof, > > This branch depends on arm/cache-l2x0 which is going in through rmk's > tree. arm/cache-l2x0 contains the following from Gregory Clement: > > arm: cache-l2x0: make outer_cache_fns a field of l2x0_of_data > arm: cache-l2x0: add an optional register to save/restore Ok, we need to make sure that Russell is happy with the patches and is pulling them in (with an agreement to not rebase the merged branch) before we can pull in your branch that builds on it. Russell, please let us know if/when that's the case so we can merge in the dependent code. Thanks! -Olof
On Wed, Sep 12, 2012 at 10:30:45PM -0700, Olof Johansson wrote: > On Mon, Sep 10, 2012 at 01:48:35AM -0400, Jason Cooper wrote: > > Arnd, Olof, > > > > This branch depends on arm/cache-l2x0 which is going in through rmk's > > tree. arm/cache-l2x0 contains the following from Gregory Clement: > > > > arm: cache-l2x0: make outer_cache_fns a field of l2x0_of_data > > arm: cache-l2x0: add an optional register to save/restore > > Ok, we need to make sure that Russell is happy with the patches and > is pulling them in (with an agreement to not rebase the merged branch) > before we can pull in your branch that builds on it. Arnd, Olof, Ok, I'm still mastering the art of branch dependencies. The acceptance of Gregory's cache-l2x0 series is holding up everything else. Rightfully so, rmk has some issues with it. However, in my pullrqs and in my branch merging I treated it as a dependency for everything that came after it (pr 1,2,3,4). I'd like to undo that now to get things moving. The dependency was not strictly necessary, I was simply trying to achieve an ordering of branches. The only way I know to do this is to redo my branches and republish. Basically, I would remove Gregory's patches and the dependency on 'arm: cache-l2x0' from pullrq [1/4] Kirkwood DT bindings. Obviously, this would break things for folks tracking my branches. Hopefully anyone crazy enough to track my branches is competent enough rebase onto the new branches. Even still, I don't want to mess anyone up. I think the benefits of getting these patches in for this merge window outweigh a onetime breaking of my branches. Is there anything I'm not considering before I do this? I'll do the work now, but hold off on pushing or sending new pullrq's for a day or two or until I hear from you guys. thx, Jason.
On Tuesday 18 September 2012, Jason Cooper wrote: > Ok, I'm still mastering the art of branch dependencies. The acceptance > of Gregory's cache-l2x0 series is holding up everything else. > Rightfully so, rmk has some issues with it. > > However, in my pullrqs and in my branch merging I treated it as a > dependency for everything that came after it (pr 1,2,3,4). I'd like to > undo that now to get things moving. The dependency was not strictly > necessary, I was simply trying to achieve an ordering of branches. > > The only way I know to do this is to redo my branches and republish. > Basically, I would remove Gregory's patches and the dependency on 'arm: > cache-l2x0' from pullrq [1/4] Kirkwood DT bindings. Right, makes sense. > Obviously, this would break things for folks tracking my branches. > Hopefully anyone crazy enough to track my branches is competent enough > rebase onto the new branches. Even still, I don't want to mess anyone up. > > I think the benefits of getting these patches in for this merge window > outweigh a onetime breaking of my branches. Is there anything I'm not > considering before I do this? > > I'll do the work now, but hold off on pushing or sending new pullrq's > for a day or two or until I hear from you guys. My rule is normally that I treat any branches coming from subarchitecture maintainers as unstable until they are merged into arm-soc. If you haven't promised anyone to keep your branches stable, I see no problem with rebasing them to avoid the dependency. Arnd
Hi Jason, On Fri, Sep 21, 2012 at 03:46:29PM -0400, Jason Cooper wrote: > The following changes since commit 5b40baee4a39d96d4d6a48a2b2383982912c429b: > > arm: mvebu: add address decoding controller to the DT (2012-09-21 18:05:29 +0000) > > are available in the git repository at: > git://git.infradead.org/users/jcooper/linux.git kirkwood/dt Looking at this branch, it's much more than just device tree updates. It introduces the pinctrl driver (and bindings), and the gpio driver (and bindings). I think it would make more sense to break those two out to separate topics, and keep the generic DT updates in this branch. Also, see my comment on the EHCI binding patch. I wasn't going to ask you to respin the branch to fix/drop that on its own, but if you do rebuild and split this branch up you might as well delay those patches until the binding has been fixed. I'll pull in your branches under staging/* for now so they can get linux-next coverage until the "real" branches come in. -Olof
On Fri, Sep 21, 2012 at 03:57:14PM -0400, Jason Cooper wrote: > > NOTE: This branch depends on both kirkwood/boards and kirkwood/dt (and, > by extension, kirkwood/addr_decode). Some of that got pulled into this > summary (kirkwood/boards). Is this correct? Sould I be basing the > pullreq on v3.6-rc5? That would summarize all three branches. Doesn't > seem as useful. What I tend to do in these cases is that I merge the dependent branches into a temporary working branch, then merge in the "new" branch on top, and get the diffstat from the last merge there. It also looks like the base for this branch is something that is not a full -rc, please only base your branches on -rcs since that makes merge history much cleaner and easier to deal with on our side. So, for example: git checkout v3.6-rc5 git merge kirkwood/boards git merge kirkwood/dt And then you can use that HEAD as the reference in request-pull. -Olof
On Fri, Sep 21, 2012 at 03:41:41PM -0400, Jason Cooper wrote: > The following changes since commit 55d512e245bc7699a8800e23df1a24195dd08217: > > Linux 3.6-rc5 (2012-09-08 16:43:45 -0700) > > are available in the git repository at: > git://git.infradead.org/users/jcooper/linux.git kirkwood/addr_decode > > Thomas Petazzoni (17): > arm: mach-dove: use plus instead of or for address definitions > arm: mach-kirkwood: use plus instead of or for address definitions > arm: mach-mv78xx0: use plus instead of or for address definitions > arm: mach-orion5x: use plus instead of or for address definitions > arm: mach-dove: use IOMEM() for base address definitions > arm: mach-kirkwood: use IOMEM() for base address definitions > arm: mach-mv78xx0: use IOMEM() for base address definitions > arm: mach-orion5x: use IOMEM() for base address definitions > arm: mach-mvebu: use IOMEM() for base address definitions > arm: plat-orion: use void __iomem pointers for UART registration functions > arm: plat-orion: use void __iomem pointers for MPP functions > arm: plat-orion: use void __iomem pointers for time functions > arm: plat-orion: use void __iomem pointers for addr-map functions > arm: plat-orion: introduce PLAT_ORION_LEGACY hidden config option > arm: plat-orion: make bridge_virt_base non-const to support DT use case > arm: mvebu: add basic address decoding support to Armada 370/XP > arm: mvebu: add address decoding controller to the DT Hi, This branch has pretty massive merge conflicts with cleanup/io-pci and other branches, in particular due to the large number of conflicting cleanup patches. It'd be better to focus on just the address decoding pieces in this branch, and move the cleanups to a separate branch. Given the state of affairs w.r.t. conflicts for the cleanups, saving those for 3.8 might be a better idea. I mentioned in one of the other comments to a patch in this series that I was going to pull this in as staging/* and get linux-next coverage, but these conflicts are more than what I want to deal with now -- so I'll hold off pulling these in after all. -Olof
On Saturday 22 September 2012, Olof Johansson wrote: > This branch has pretty massive merge conflicts with cleanup/io-pci and other > branches, in particular due to the large number of conflicting cleanup patches. > > It'd be better to focus on just the address decoding pieces in this branch, and > move the cleanups to a separate branch. Given the state of affairs w.r.t. > conflicts for the cleanups, saving those for 3.8 might be a better idea. > > I mentioned in one of the other comments to a patch in this series that > I was going to pull this in as staging/* and get linux-next coverage, > but these conflicts are more than what I want to deal with now -- so > I'll hold off pulling these in after all. I think the branch is needed though, to avoid lots of build warnings when the changes to asm/io.h from Russell's tree hit mainline. I did similar patches for most of the other platforms but left out the ones that I knew Thomas was already working on. Arnd
Dear Olof Johansson, On Fri, 21 Sep 2012 22:29:04 -0700, Olof Johansson wrote: > This branch has pretty massive merge conflicts with cleanup/io-pci > and other branches, in particular due to the large number of > conflicting cleanup patches. > > It'd be better to focus on just the address decoding pieces in this > branch, and move the cleanups to a separate branch. Given the state > of affairs w.r.t. conflicts for the cleanups, saving those for 3.8 > might be a better idea. > > I mentioned in one of the other comments to a patch in this series > that I was going to pull this in as staging/* and get linux-next > coverage, but these conflicts are more than what I want to deal with > now -- so I'll hold off pulling these in after all. This is really surprising. Those cleanups were explicitly requested by Arnd Bergmann during the review process of my address decoding patch set. The earlier version of this patch set was only doing address decoding changes, not the IOMEM() cleanup. And Arnd requested the IOMEM() cleanup to be done as a pre-requisite to the address decoding changes. I've therefore spent two days last week doing these cleanups and retesting the address decoding changes, and now you're telling us exactly the opposite of what Arnd said two weeks ago? I'm sorry but that doesn't really fair here. Best regards, Thomas
On Fri, Sep 21, 2012 at 10:11:58PM -0700, Olof Johansson wrote: > Hi Jason, > > On Fri, Sep 21, 2012 at 03:46:29PM -0400, Jason Cooper wrote: > > The following changes since commit 5b40baee4a39d96d4d6a48a2b2383982912c429b: > > > > arm: mvebu: add address decoding controller to the DT (2012-09-21 18:05:29 +0000) > > > > are available in the git repository at: > > git://git.infradead.org/users/jcooper/linux.git kirkwood/dt > > Looking at this branch, it's much more than just device tree updates. Ok, my thinking was they (pinctrl and gpio) were devicetree-only drivers, see below. > It introduces the pinctrl driver (and bindings), and the gpio driver (and > bindings). I think it would make more sense to break those two out to separate > topics, and keep the generic DT updates in this branch. > > Also, see my comment on the EHCI binding patch. I wasn't going to ask you to > respin the branch to fix/drop that on its own, but if you do rebuild and split > this branch up you might as well delay those patches until the binding has been > fixed. Ok. I'll split out pinctrl and gpio into a kirkwood/drivers, leave the rest in /dt, and drop the ehci changes. /drivers will still depend on /addr_decode, once you, Arnd, and Thomas work that out. /dt should have no deps then. /cleanup will now depend only on /boards if we're dropping ehci for now. /defconfig will still only depend on /boards. /platform_data will still depend on everything kirkwood/*. So, I take it /boards is ok? > I'll pull in your branches under staging/* for now so they can get linux-next > coverage until the "real" branches come in. Okay, thanks. thx, Jason.