Hi, On Wed, Mar 7, 2012 at 9:10 AM, Tony Lindgren <tony@xxxxxxxxxxx> wrote: > Hi, > > Arnd & Olof, some urgent changes are needed, see below. > > * Russell King - ARM Linux <linux@xxxxxxxxxxxxxxxx> [120307 01:34]: >> On Tue, Mar 06, 2012 at 05:01:53PM +0000, Arnd Bergmann wrote: >> > On Tuesday 06 March 2012, Russell King - ARM Linux wrote: >> > > On Tue, Feb 28, 2012 at 12:11:37PM +0200, Ohad Ben-Cohen wrote: >> > > > On Tue, Feb 28, 2012 at 12:01 PM, Arnd Bergmann <arnd@xxxxxxxx> wrote: >> > > > > I think 'depends' would be better here, because selecting IOMMU_SUPPORT >> > > > > has other side-effects that a user might not want. It's just as likely >> > > > > that someone wants to disable IOMMU_SUPPORT and needs to find OMAP_REMOTEPROC >> > > > > as wanting to enable OMAP_REMOTEPROC and having to find IOMMU_SUPPORT. >> > > > > >> > > > > In most cases, the defconfig should just set both. >> > > > >> > > > Ok, 'depends on' it is. >> > > >> > > We're a week on, which means I now have a full set of 7 builds on the >> > > website for OMAP4430 all of which have failed in part due to this >> > > as yet unresolved problem. >> > > >> > > What's happening to get it fixed and those fixes into whatever tree is >> > > necessary for them (presumably arm-soc)? >> > >> > Ohad has sent a series of patches for review and there were no comments >> > on those. The fix was part of it as far as I remember. I'm still waiting >> > for a pull request from Ohad. >> >> Given that we're coming to the end of what could be the _final_ week >> before the merge window opens, this is not good news. Read: maybe >> three days before final. >> >> The fact is that OMAP is - yet again - in a totally rotten state in terms >> of what's queued up in the armsoc tree. It is - yet again - completely >> unbuildable for many configurations. Just go and have a look at: >> >> http://www.arm.linux.org.uk/developer/build/ >> >> to see what an utterly crappy state OMAP is in again. Last nights build >> was my tree plus latest arm-soc. Some of those issues have patches (I >> had been applying one patch manually to the build tree) but that's not >> the point - they're not in arm-soc, so the OMAP code in arm-soc is not >> yet ready for mainline. > > Yes looks like there's an issue with getting urgent patches applied into > the arm-soc tree.. The patches to fix these issues are known and > other issues and warnings should be all sorted out now except for some > MMC changes that are still being discussed. > >> So, as OMAP is soo broken, and as promised after the last merge window - >> I don't want any OMAP stuff going upstream from armsoc until we get error >> free builds from the allno and old configs on the builder. > > What I got queued up in fixes-non-critical-part2 should fix all those > errors and warnings. > > Arnd & Olof, I've posted one fix that should be applied to arm-soc tree > at [1]. I've also posted a request to revert one commit in arm-soc tree > at [2]. > > As it seems that you did not apply those to arm-soc, please apply them, > or repull the following two branches ASAP: Done (repulled the branches). Stephen Rothwell has not surfaced on irc yet, so hopefully this means it'll make it into today's linux-next. > > Re-pull fixes-non-critical containing one revert: > > Revert "ARM: OMAP2+: Fix multiple randconfig errors with SOC_OMAP and SOC_OMAP_NOOP" > > git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap fixes-non-critical > > Re-pull cleanup again containing one fix: > > ARM: OMAP2+: Fix L4_EMU_34XX_BASE error after iomap changes > > git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap cleanup > > Note that the second one I just pushed, however the patch is known to > work for the build errors after merging arm-soc with Russell's changes. Looks like you pasted the wrong subject above -- the mail below contains the patch that you added though so it looked OK to me (the subject above was the previous top-of-branch before you added the last one). > Arnd & Olof, for future, how you want to handle urgent issues like this? Personally I missed the requests since they ended up in the chain of replies and I didn't notice them, my mistake. A separate email requesting pulls or patch application it to arm@xxxxxxxxxx would reduce the risk of that happening (Flagging the subject with [URGENT] wouldn't hurt). -Olof -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
