Message ID | CACRpkdY9BDyGQ-DiEhTiyHEYoxpGiL+H0baqsBYX_a-0upktUQ@mail.gmail.com |
---|---|
State | New |
Headers | show |
Hi, On Tue, Jan 29, 2013 at 10:06 AM, Linus Walleij <linus.walleij@linaro.org> wrote: > Hi ARM SoC maintainers, > > This patch set removes the use of <mach/id.h> from being broadcasted across > the kernel and blocks any further usage of cpu_is* outside of the machine. > > Target is v3.9 cleanups. > > It is part of our path toward single zImage. > > Please pull it in! Detailed description in the tag, MFD hunk ACKed by > Samuel Ortiz. > > Yours, > Linus Walleij > > The following changes since commit d1c3ed669a2d452cacfb48c2d171a1f364dae2ed: > > Linux 3.8-rc2 (2013-01-02 18:13:21 -0800) > > are available in the git repository at: > > git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-stericsson.git > tags/ux500-no-idh Pulled in. This has a somewhat annoying (but trivial) conflict against your own code (the cpufreq driver changes). -Olof
On Wed, Jan 30, 2013 at 1:12 AM, Olof Johansson <olof@lixom.net> wrote: > [Me] >> git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-stericsson.git >> tags/ux500-no-idh > > Pulled in. > > This has a somewhat annoying (but trivial) conflict against your own > code (the cpufreq driver changes). Arnd always told me to split stuff cleanly on branches, which of course leads to conflicts like that, but I thought he wanted them, rather than huge accumulated patch sets built on to of each othere ... a bit hard to do the right thing here, what would have been the right way? Does it help if I base stuff off ARM SoC tree branches, and which ones can be relied upon in that case? Yours, Linus Walleij
On Wednesday 30 January 2013, Linus Walleij wrote: > On Wed, Jan 30, 2013 at 1:12 AM, Olof Johansson <olof@lixom.net> wrote: > > [Me] > >> git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-stericsson.git > >> tags/ux500-no-idh > > > > Pulled in. > > > > This has a somewhat annoying (but trivial) conflict against your own > > code (the cpufreq driver changes). > > Arnd always told me to split stuff cleanly on branches, which of course > leads to conflicts like that, but I thought he wanted them, rather than > huge accumulated patch sets built on to of each othere ... a bit hard to > do the right thing here, what would have been the right way? > > Does it help if I base stuff off ARM SoC tree branches, and which > ones can be relied upon in that case? Not sure if it applies here, but in a lot of cases, one can extract the parts that do conflict and put those patches first in the series, and merge them together before the pull request. The classic example of this is two independent features A and B that both contain some cleanup. By moving the cleanup first, you can merge the cleanup-A patches with the cleanup-B patches and submit them as one branch, and then have feature A on top of cleanup-A merge cleanly with both feature-B (because there are no conflicts) and with cleanup-A-B (because cleanup-A-B has already resolved the conflict). Unrelated to this: The mach/id.h removal seems to have caused a few build errors in the for-next tree with u8500_defconfig. Can you have a look at what went wrong there? Arnd
On Thu, Jan 31, 2013 at 12:15 AM, Arnd Bergmann <arnd@arndb.de> wrote: > Unrelated to this: The mach/id.h removal seems to have caused a few > build errors in the for-next tree with u8500_defconfig. Can you have > a look at what went wrong there? Yes ... hm. I have no clue how this happened, somehow new dependencues have appeared and I've somehow had a config that builds without some of the drivers or something :-( Or I built the wrong branch and thought it was clear to go. Shall we just drop it until I've fixed it up? Yours, Linus Walleij
Hi, On Thu, Jan 31, 2013 at 6:40 AM, Linus Walleij <linus.walleij@linaro.org> wrote: > On Thu, Jan 31, 2013 at 12:15 AM, Arnd Bergmann <arnd@arndb.de> wrote: > >> Unrelated to this: The mach/id.h removal seems to have caused a few >> build errors in the for-next tree with u8500_defconfig. Can you have >> a look at what went wrong there? > > Yes ... hm. > > I have no clue how this happened, somehow new dependencues > have appeared and I've somehow had a config that builds without > some of the drivers or something :-( > > Or I built the wrong branch and thought it was clear to go. > > Shall we just drop it until I've fixed it up? What's the expected timeline for fixup? I can revert the patch in for-next and we can take a fix on top of the branch that introduced the breakage, if that's easier. -Olof