Re: next pass of cleaning up micropatch.c

[Tom Rini <trini@kernel.crashing.org>]

On Fri, Oct 08, 2004 at 11:45:59AM -0400, Robert P. J. Day wrote:
> On Fri, 8 Oct 2004, Tom Rini wrote:
> >On Fri, Oct 08, 2004 at 11:34:06AM -0400, Dan Malek wrote:
> >>On Oct 8, 2004, at 8:44 AM, Robert P. J. Day wrote:
> >>>+ *  Shortcut macros for patching code.
> >>> */
> >>>+
> >>>+#define PATCH2000 \
> >>>+	dp = (uint *)(commproc->cp_dpmem); \
> >>>+	for (i=0; i<(sizeof(patch_2000)/4); i++) \
> >>>+		*dp++ = patch_2000[i];
> >>>+
> >>>+#define PATCH2E00 \
> >>>+	dp = (uint *)&(commproc->cp_dpmem[0x0e00]); \
> >>>+	for (i=0; i<(sizeof(patch_2e00)/4); i++) \
> >>>+		*dp++ = patch_2e00[i];
> >>>+
> >>>+#define PATCH2F00 \
> >>>+	dp = (uint *)&(commproc->cp_dpmem[0x0f00]); \
> >>>+	for (i=0; i<(sizeof(patch_2f00)/4); i++) \
> >>>+		*dp++ = patch_2f00[i];
> >>
> >>Please get rid of these macros and place the code where it
> >>belongs.  They add no value and just make it harder to
> >>read the code and understand what it does.
> >
> >I agree.  If there were more patches it might make sense to write a
> >do_microcode_patch2(N) macro, but PATCH2NNN isn't "readable" and it's
> >only 3 patches.
> 
> fair enough, but keep in mind, the whole point was that what you're 
> looking at is the minimal *infrastructure* for possibly adding more 
> patches down the road.  right *now*, there's only three because those 
> are the only ones that were in micropatch.c at the moment.  there's 
> certainly a lot more available at freescale that can be added as time 
> goes by.
> 
> i'll put the actual code back in, but you might have second thoughts 
> when we're up to 8 or 10 patches some day. :-)

When we get to 8 or 10 patches, we can figure out what a
do_microcode_patch*() macro might look like :)

-- 
Tom Rini
http://gate.crashing.org/~trini/