[PATCH] arch/powerpc/lib/copy_32.S: Use alternate memcpy for MPC512x and MPC52xx
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
> Steve, what code is doing a memcpy from flash?
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