Message ID | 20121220163814.GA29557@quad.lixom.net |
---|---|
State | New |
Headers | show |
On Thu, Dec 20, 2012 at 8:38 AM, Olof Johansson <olof@lixom.net> wrote: > > One of the sunxi patches from the last pull request was misapplied (I > realized what happened -- git am -s didn't apply cleanly so I had done it > through regular patch, thus not catching the renames properly). Here's > a fresh version of the pull request with a couple more OMAP and Samsung > patches included. Argh! I pulled your earlier branch due to Tony's ack, and now you're re-created that branch with new pulls (effectively rebasing it). Don't do things like this to me. Linus
[proper reply-to-all this time] On Thu, Dec 20, 2012 at 8:49 AM, Linus Torvalds <torvalds@linux-foundation.org> wrote: > On Thu, Dec 20, 2012 at 8:38 AM, Olof Johansson <olof@lixom.net> wrote: >> >> One of the sunxi patches from the last pull request was misapplied (I >> realized what happened -- git am -s didn't apply cleanly so I had done it >> through regular patch, thus not catching the renames properly). Here's >> a fresh version of the pull request with a couple more OMAP and Samsung >> patches included. > > Argh! > > I pulled your earlier branch due to Tony's ack, and now you're > re-created that branch with new pulls (effectively rebasing it). > > Don't do things like this to me. Yeah, sorry about that -- I wanted to replace the broken patch, and Tony's branch was based on a newer version of your tree so I brought everything forward as I had to rebase anyway. I'll rebuild on top of what you've pulled, and send a fresh request of just the delta. Sorry about the race condition here. -Olof
* Olof Johansson <olof@lixom.net> [121220 09:30]: > [proper reply-to-all this time] > > On Thu, Dec 20, 2012 at 8:49 AM, Linus Torvalds > <torvalds@linux-foundation.org> wrote: > > On Thu, Dec 20, 2012 at 8:38 AM, Olof Johansson <olof@lixom.net> wrote: > >> > >> One of the sunxi patches from the last pull request was misapplied (I > >> realized what happened -- git am -s didn't apply cleanly so I had done it > >> through regular patch, thus not catching the renames properly). Here's > >> a fresh version of the pull request with a couple more OMAP and Samsung > >> patches included. > > > > Argh! > > > > I pulled your earlier branch due to Tony's ack, and now you're > > re-created that branch with new pulls (effectively rebasing it). > > > > Don't do things like this to me. > > Yeah, sorry about that -- I wanted to replace the broken patch, and > Tony's branch was based on a newer version of your tree so I brought > everything forward as I had to rebase anyway. > > I'll rebuild on top of what you've pulled, and send a fresh request of > just the delta. Sorry about the race condition here. Sorry for me adding to the confusion too. Looks like Linus already applied "ARM: OMAP: Fix build breakage due to missing include in i2c.c" that I had queued earlier. Olof, I suggest you just merge my pull request up to the other commit c16acf12 (ARM: OMAP2+: Fix compillation error in mach-omap2/timer.c). Or just pick it whichever works better for you. Regards, Tony
On Thu, Dec 20, 2012 at 9:35 AM, Tony Lindgren <tony@atomide.com> wrote: > > Looks like Linus already applied "ARM: OMAP: Fix build breakage due > to missing include in i2c.c" that I had queued earlier. Yeah, since it was my mis-merge, and I realized that I had entirely missed the header file fixup, I felt like I had to correct it since I had the report and the pointer to the fix.. Linus
On Thu, Dec 20, 2012 at 08:38:14AM -0800, Olof Johansson wrote: > One of the sunxi patches from the last pull request was misapplied (I > realized what happened -- git am -s didn't apply cleanly so I had done it > through regular patch, thus not catching the renames properly). Here's > a fresh version of the pull request with a couple more OMAP and Samsung > patches included. > > There's a chance that a couple of the OMAP patches will also go in through > Russell, since my connectivity has been crap so far this trip and it > causes build breaks for the platform. It's a branch pull from Tony, > it should be a no-op either way. Olof, Not sure what's going on, but my recent pull from arm-soc for-next still hasn't solved the OMAP build failures in my kbuild - I'm still getting: arch/arm/mach-omap2/timer.c: In function 'omap_get_timer_dt': arch/arm/mach-omap2/timer.c:178:3: error: implicit declaration of function 'prom_add_property' arch/arm/mach-omap2/i2c.c: In function 'omap_pm_set_max_mpu_wakeup_lat_compat': arch/arm/mach-omap2/i2c.c:130:2: error: implicit declaration of function 'omap_pm_set_max_mpu_wakeup_lat' This is the top commit I have from you: commit aad05c3602ba5c42ff8d0e572b2f614f25779ede Merge: eccf4b3 f64d204 Author: Olof Johansson <olof@lixom.net> Date: Mon Dec 17 18:44:26 2012 -0800 Merge branch 'late/omap-cleanup' into for-next By Tony Lindgren (3) and others via Tony Lindgren * late/omap-cleanup: arch/arm/mach-omap2/dpll3xxx.c: drop if around WARN_ON OMAP2: Fix a typo - replace regist with register. ARM/omap: use module_platform_driver macro ARM: OMAP2+: PMU: Remove unused header ARM: OMAP4: remove duplicated include from omap_hwmod_44xx_data.c ARM: OMAP2+: omap2plus_defconfig: enable twl4030 SoC audio ARM: OMAP2+: omap2plus_defconfig: Add tps65217 support ARM: OMAP2+: enable devtmpfs and devtmpfs automount ARM: OMAP2+: omap_twl: Change TWL4030_MODULE_PM_RECEIVER to TWL_MODULE_PM_RECEIVER ARM: OMAP2+: Drop plat/cpu.h for omap2plus ARM: OMAP: Split fb.c to remove last remaining cpu_is_omap usage MAINTAINERS: Add an entry for omap related .dts files
On Thu, Dec 20, 2012 at 9:56 AM, Russell King - ARM Linux <linux@arm.linux.org.uk> wrote: > On Thu, Dec 20, 2012 at 08:38:14AM -0800, Olof Johansson wrote: >> One of the sunxi patches from the last pull request was misapplied (I >> realized what happened -- git am -s didn't apply cleanly so I had done it >> through regular patch, thus not catching the renames properly). Here's >> a fresh version of the pull request with a couple more OMAP and Samsung >> patches included. >> >> There's a chance that a couple of the OMAP patches will also go in through >> Russell, since my connectivity has been crap so far this trip and it >> causes build breaks for the platform. It's a branch pull from Tony, >> it should be a no-op either way. > > Olof, > > Not sure what's going on, but my recent pull from arm-soc for-next still > hasn't solved the OMAP build failures in my kbuild - I'm still getting: > > arch/arm/mach-omap2/timer.c: In function 'omap_get_timer_dt': > arch/arm/mach-omap2/timer.c:178:3: error: implicit declaration of function 'prom_add_property' > arch/arm/mach-omap2/i2c.c: In function 'omap_pm_set_max_mpu_wakeup_lat_compat': > arch/arm/mach-omap2/i2c.c:130:2: error: implicit declaration of function 'omap_pm_set_max_mpu_wakeup_lat' Yep, I forgot to bring the fixes branch into our for-next. Try again once it mirrors out, I just pushed out a rebuild of it. New top commit should be e691d77e8825054376b31e79a9b5f9fa79fe764d. I'm doing a "build all defconfigs" run before sending the incremental pull request of fixes to Linus. -Olof
* Olof Johansson <olof@lixom.net> [121220 10:11]: > > Yep, I forgot to bring the fixes branch into our for-next. Try again > once it mirrors out, I just pushed out a rebuild of it. New top commit > should be e691d77e8825054376b31e79a9b5f9fa79fe764d. > > I'm doing a "build all defconfigs" run before sending the incremental > pull request of fixes to Linus. Commit e691d77e8825054376b31e79a9b5f9fa79fe764d builds and boots with my testconfigs. I'm seeing the "BUG: spinlock bad magic on CPU#0" issue reported and fixed here: http://marc.info/?l=linux-arm-kernel&m=135594868503683&w=2 But that's probably been already posted as a proper patch somewhere? Regards, Tony
On Thu, Dec 20, 2012 at 10:08:42AM -0800, Olof Johansson wrote: > On Thu, Dec 20, 2012 at 9:56 AM, Russell King - ARM Linux > <linux@arm.linux.org.uk> wrote: > > On Thu, Dec 20, 2012 at 08:38:14AM -0800, Olof Johansson wrote: > >> One of the sunxi patches from the last pull request was misapplied (I > >> realized what happened -- git am -s didn't apply cleanly so I had done it > >> through regular patch, thus not catching the renames properly). Here's > >> a fresh version of the pull request with a couple more OMAP and Samsung > >> patches included. > >> > >> There's a chance that a couple of the OMAP patches will also go in through > >> Russell, since my connectivity has been crap so far this trip and it > >> causes build breaks for the platform. It's a branch pull from Tony, > >> it should be a no-op either way. > > > > Olof, > > > > Not sure what's going on, but my recent pull from arm-soc for-next still > > hasn't solved the OMAP build failures in my kbuild - I'm still getting: > > > > arch/arm/mach-omap2/timer.c: In function 'omap_get_timer_dt': > > arch/arm/mach-omap2/timer.c:178:3: error: implicit declaration of function 'prom_add_property' > > arch/arm/mach-omap2/i2c.c: In function 'omap_pm_set_max_mpu_wakeup_lat_compat': > > arch/arm/mach-omap2/i2c.c:130:2: error: implicit declaration of function 'omap_pm_set_max_mpu_wakeup_lat' > > Yep, I forgot to bring the fixes branch into our for-next. Try again > once it mirrors out, I just pushed out a rebuild of it. New top commit > should be e691d77e8825054376b31e79a9b5f9fa79fe764d. Yes, this looks much better, thanks.
On Thu, Dec 20, 2012 at 10:45 AM, Tony Lindgren <tony@atomide.com> wrote: > > I'm seeing the "BUG: spinlock bad magic on CPU#0" issue > reported and fixed here: > > http://marc.info/?l=linux-arm-kernel&m=135594868503683&w=2 > > But that's probably been already posted as a proper patch > somewhere? Hmm. The patch there looks better than any alternative I can think of. It uses the same spinlock name for the whole array, but I think it's only used for lockdep printouts, so that should be fine. Send me the patch with signed-off and tested-by, and perhaps have a few more people test it. The powerpc and sparc people both use it in their 32-bit versions and have responsible maintainers, so it might be worth it double-checking with BenH and DaveM about it, just in case. Added to the Cc. Linus
* Linus Torvalds <torvalds@linux-foundation.org> [121220 11:03]: > On Thu, Dec 20, 2012 at 10:45 AM, Tony Lindgren <tony@atomide.com> wrote: > > > > I'm seeing the "BUG: spinlock bad magic on CPU#0" issue > > reported and fixed here: > > > > http://marc.info/?l=linux-arm-kernel&m=135594868503683&w=2 > > > > But that's probably been already posted as a proper patch > > somewhere? > > Hmm. The patch there looks better than any alternative I can think of. > It uses the same spinlock name for the whole array, but I think it's > only used for lockdep printouts, so that should be fine. > > Send me the patch with signed-off and tested-by, and perhaps have a > few more people test it. The powerpc and sparc people both use it in > their 32-bit versions and have responsible maintainers, so it might be > worth it double-checking with BenH and DaveM about it, just in case. > Added to the Cc. Looks like it's been posted to LKML as: [PATCH] lib: atomic64: Initialize locks statically to fix early users Replied to it with my tested-by if you want to pick it up. Regards, Tony
On Thu, 2012-12-20 at 11:00 -0800, Linus Torvalds wrote: > Hmm. The patch there looks better than any alternative I can think of. > It uses the same spinlock name for the whole array, but I think it's > only used for lockdep printouts, so that should be fine. > > Send me the patch with signed-off and tested-by, and perhaps have a > few more people test it. The powerpc and sparc people both use it in > their 32-bit versions and have responsible maintainers, so it might be > worth it double-checking with BenH and DaveM about it, just in case. > Added to the Cc. The patch looks fine. I won't personally be able to test it until after I'm back from vacation though. I'll see if I can get somebody else to but don't wait for me. Cheers, Ben.