On Oct 18, 2011, at 1:35 AM, Wolfgang Denk wrote: > Dear Kumar Gala, > > In message <1312555480-13401-8-git-send-email-ga...@kernel.crashing.org> you > wrote: >> From: Poonam Aggrwal <poonam.aggr...@freescale.com> >> >> Issue: Address masking doesn't work properly. >> When sum of the base address, defined by BA, and memory bank size, >> defined by AM, exceeds 4GB (0xffff_ffff) then AMASKn[AM] doesn't mask >> CSPRn[BA] bits. >> >> Impact: >> This will impact booting when we are reprogramming CSPR0(BA) and >> AMASK0(AMASK) while executing from NOR Flash. >> >> Workaround: >> Re-programming of CSPR(BA) and AMASK is done while not executing from NOR >> Flash. The code which programs the BA and AMASK is executed from L2-SRAM. >> >> Signed-off-by: Poonam Aggrwal <poonam.aggr...@freescale.com> >> Signed-off-by: Kumar Gala <ga...@kernel.crashing.org> > > This commit introdces new build warnings for the following boards: > > P1010RDB_36BIT_NOR P1010RDB_NOR > P1010RDB_36BIT_NOR_SECBOOT P1010RDB_NOR_SECBOOT > > For example: > > Configuring for P1010RDB_NOR - Board: P1010RDB, Options: P1010RDB > cpu_init_early.c: In function 'cpu_init_early_f': > cpu_init_early.c:74: warning: 'l2srbar' may be used uninitialized in this > function > > > Please fix! > > > Kumar, Poonam - I'm really p*ssed off. Both of you have more than > enough of experience to know that you should not submit > untested patches. especially here, where I already had to reject this > patch because it did not even pass checkpatch: > > I wrote in message <20110804212403.3d53221c...@gemini.denx.de>: > > | Dear Kumar Gala, > | > | In message <08144324-be32-4a54-bc2d-b920f18f3...@kernel.crashing.org> > | you wrote: > | > > | > > Kumar, could you __please__ get used to running your patches > | > > throuch > | > > checkpatch __before__ submitting? Thanks. > | > > | > I try to, but not all of them are by me ;) > | > | I know. But you submitted them, so you are responsible. > > > This level of neglect is really disappointing. > > > Wolfgang Denk
If you look at the code I have NO IDEA how to fix this for older GCC. Gripping at me about this isn't fair. I'm sure if I hack something to make gcc-4.2 happy I'm going to piss off gcc-4.6. We can't win. At some point we have to move off gcc-4.2 as the baseline compiler w/regards to warning and code generation. - k _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
