[PATCH] arch/powerpc/lib/copy_32.S: Use alternate memcpy for MPC512x and MPC52xx

Steve Deiters SteveDeiters at BASLER.com
Fri Jul 9 00:38:22 EST 2010

> -----Original Message-----
> From: glikely at secretlab.ca [mailto:glikely at secretlab.ca] On 
> Behalf Of Grant Likely
> Sent: Thursday, July 08, 2010 12:38 AM
> To: Benjamin Herrenschmidt
> Cc: Steve Deiters; linuxppc-dev at lists.ozlabs.org
> Subject: Re: [PATCH] arch/powerpc/lib/copy_32.S: Use 
> alternate memcpy for MPC512x and MPC52xx
> On Wed, Jul 7, 2010 at 11:10 PM, Benjamin Herrenschmidt 
> <benh at kernel.crashing.org> wrote:
> > On Tue, 2010-06-29 at 11:04 -0500, Steve Deiters wrote:
> >> These processors will corrupt data if accessing the local bus with 
> >> unaligned addresses. This version fixes the typical case 
> of copying 
> >> from Flash on the local bus by keeping the source address always 
> >> aligned.
> >
> > Shouldn't this be solved by using memcpy_to/fromio ?
> Maybe.  plain memcpy() access to anything localbus-attached 
> on the mpc5xxx is the wrong thing to do.  memcpy_to/fromio 
> might do the right thing; but the caller must understand the 
> limitations of the localplus bus.  The byte-wise alignment 
> that memcpy_to/fromio() does may not work (depending on 
> configuration).
> Steve, what code is doing a memcpy from flash?
> g.

This was done in the JFFS2 code, in fs/jffs2/scan.c.  At least in one
function, in jffs2_scan_dirent_node it was using memcpy on a localbus
mapped structure.  I was getting JFFS2 filesystem corruption because of
this.  In fact I first tried changing this to memcpy_fromio and it fixed
that particular problem.  I was concerned though that other places I was
not aware of might be using memcpy from the localbus in a similar manner
so I decided to just tweak the memcpy routine.

Just out of curiousity, what configuration might cause a byte-wise
alignment not to work?

More information about the Linuxppc-dev mailing list