[U-Boot] [PATCH 7/7][v2] fsl_ifc: Add the workaround for erratum IFC A-003399(enabled on P1010)

[Aggrwal Poonam-B10812]

Kumar, Wolfgang
	
I think this is my mistake, I did not take care of checkpatch.

Please let me know , I can submit it again.

Regards
Poonam

> -----Original Message-----
> From: Kumar Gala [mailto:galak at kernel.crashing.org]
> Sent: Tuesday, October 18, 2011 5:18 PM
> To: Wolfgang Denk
> Cc: u-boot at lists.denx.de; Aggrwal Poonam-B10812
> Subject: Re: [U-Boot] [PATCH 7/7][v2] fsl_ifc: Add the workaround for
> erratum IFC A-003399(enabled on P1010)
> 
> 
> On Oct 18, 2011, at 1:35 AM, Wolfgang Denk wrote:
> 
> > Dear Kumar Gala,
> >
> > In message <1312555480-13401-8-git-send-email-
> galak at kernel.crashing.org> you wrote:
> >> From: Poonam Aggrwal <poonam.aggrwal at 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.aggrwal at freescale.com>
> >> Signed-off-by: Kumar Gala <galak at 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.3D53221C695 at gemini.denx.de>:
> >
> > | Dear Kumar Gala,
> > |
> > | In message
> > | <08144324-BE32-4A54-BC2D-B920F18F3D43 at 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