On Tue, Apr 08, 2014 at 09:12:44AM -0700, Kevin Hilman wrote:
Hi Russell,
On Mon, Apr 7, 2014 at 7:25 AM, Russell King - ARM Linux linux@arm.linux.org.uk wrote:
On Mon, Apr 07, 2014 at 07:15:34AM -0700, Olof Johansson wrote:
On Mon, Apr 7, 2014 at 2:10 AM, Russell King - ARM Linux linux@arm.linux.org.uk wrote:
On Sun, Apr 06, 2014 at 11:12:51PM -0700, Olof's autobooter wrote:
Failed boards:
cubie multi_v7_defconfig : FAILED 1:05.77 cubie2 sunxi_defconfig : FAILED 1:21.41 cubie2 multi_v7_defconfig : FAILED 1:09.94 cubie2 multi_lpae_defconfig : FAILED 0:59.68 hummingboard multi_v7_defconfig : FAILED 1:04.69 panda multi_v7_defconfig : FAILED 1:36.35 snow exynos_defconfig : FAILED 2:24.53 snowball multi_v7_defconfig : FAILED 1:07.90 wandboard multi_v7_defconfig : FAILED 1:05.66So do we have any clues what's causing these to fail?
I'm pretty sure these will be fixed by:
"arm: pj4: check cpu id for pj4 cp0 access"
That I don't see in -next yet. Adding Chao on this thread, since we've already requested the patch to be sent to the patch tracker...
I haven't applied anything from the patch system for the last month or more as I've been soo bogged down with the l2c and fec changes.
The multi_v7_defconfig change that triggers the PJ4 enable (and thus some boot failures[1]) is now in mainline. The fixes for this are in the patch tracker as 8015/1 and 8016/1.
Right, eventually submitted four days *after* the merge window had opened.
A good question at this point is what change introduced this regression,
What introduced this regression was enabling MACH_DOVE in multi_v7_defconfig (commit 5c436fbef207e11aeae54ea6c8dfd4c65b2aaac2) since that selects the PJ4 options.
We've had this reverted in arm-soc/for-next while waiting for the patches to make it through your patch tracker, but the pull request with that change has gone out, and now it's in mainline, so we have boot failures in mainline[1]
Right, so rather than checking with me about those *late* submitted patches, arm-soc people decided to go off and do their own thing.
and why did that change go through a different tree to that which is being asked to carry the fixes?
The original change was a multi_v7_defconfig change which we've been handling through arm-soc. The fix is a core CPU identification change that typically goes through you.
Right. If we're doing the strict file ownership thing, then this is what _should_ have happened, because there's a strict dependency between these two changes:
- the fixes for the PJ4B needed to be merged into a branch in my tree - _then_ that branch cross-merged into arm-soc - _then_ the offending arm-soc change should have been committed on top of that.
That means whoever merges first, the outcome is the same, and avoids any kind of build breakage.
If that didn't happen (it didn't) then with strict file ownership, arm-soc can't take the offending change. arm-soc shouldn't just stuff it into the mainline kernel anyway.
I will merge these two patches today. However, I'm *not* changing my plans as for pull requests to Linus for.
We _could_ of course all calm down, and realise that there will always be cases where patches for "files under our control" to go through different trees from time to time, and just deal with it as we have done in the past - but the message I'm getting is that arm-soc want to own all the SoC stuff exclusively, _and_ they want to take core ARM patches too. As I've already said, that's not on.