Re: [PATCH] m68k: Use generic strncpy_from_user(), strlen_user(),and strnlen_user()

From: Greg Ungerer
Date: Thu Jun 07 2012 - 07:12:45 EST


Hi Geert,

On 06/07/2012 03:46 AM, Geert Uytterhoeven wrote:
On Wed, Jun 6, 2012 at 8:31 AM, Greg Ungerer<gerg@xxxxxxxxxxxx> wrote:
Yes, looks like that should have a "|| defined(CONFIG_CPU32)".
(According to the CPU32 reference manual words and long words must
be aligned on word boundaries.)

I think something like CONFIG_CPU_HAS_NO_UNALIGNED makes sense.

OK, doing that now...

Then I saw arch/m68k/lib/memcpy.c.

commit f230e80b423f6cb002015ab4771c06a53d5a2287
("m68k: fix memcpy to unmatched/unaligned source and dest on 68000")

| The original 68000 processors cannot copy 16bit or larger quantities from
| odd addresses. All newer members of the 68k family (including ColdFire)
| can do this.

So all Coldfires can do unaligned _reads_, but not unaligned _writes_
(exceptions below)?

This strikes me as odd. Maybe this has been wrong all along. I need
to check further but in a little testing I did today I think it may
well be that all ColdFire support unaligned reads and writes.


I also think that the Coldfire 5272 can do unaligned accesses, but I
cannot test that at the moment.


According to the MCF5272 User Manual, "it supports misaligned data
accesses ...". So it looks like it does.

Having a CONFIG_CPU_HAS_NO_UNALIGNED looks like a really good solution
then. We need to be able select it as required on individual CPU types.

For now, I just make COLDFIRE select it, but we can move it to the individual
CPU types later.

No matter what I find I still think this is the way to go.

Thanks
Greg


------------------------------------------------------------------------
Greg Ungerer -- Principal Engineer EMAIL: gerg@xxxxxxxxxxxx
SnapGear Group, McAfee PHONE: +61 7 3435 2888
8 Gardner Close, FAX: +61 7 3891 3630
Milton, QLD, 4064, Australia WEB: http://www.SnapGear.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/