linux-toradex.git/arch/m68k/lib, branch v4.3.2

m68k: Remove FSF address

2015-03-15T09:23:30+00:00

We have a central copy of the GPL for that, and the FSF may change
address again in the future.

Signed-off-by: Geert Uytterhoeven

m68k/uaccess: Fix asm constraints for userspace access

2013-06-24T17:44:19+00:00

When compiling a MMU kernel with CPU_HAS_ADDRESS_SPACES=n (e.g. "MMU=y
allnoconfig": "echo CONFIG_MMU=y > allno.config && make KCONFIG_ALLCONFIG=1
allnoconfig"), we use plain "move" instead of "moves", and I got:

  CC      arch/m68k/lib/uaccess.o
{standard input}: Assembler messages:
{standard input}:47: Error: operands mismatch -- statement `move.b %a0,(%a1)' ignored

This happens because plain "move" doesn't support byte transfers between
memory and address registers, while "moves" does.

Fix the asm constraints for __generic_copy_from_user(),
__generic_copy_to_user(), and __clear_user() to only use data registers
when accessing userspace.

Also, relax the asm constraints for 16-bit userspace accesses in
__put_user() and __get_user(), as both "move" and "moves" do support
such transfers between memory and address registers.

Signed-off-by: Geert Uytterhoeven

m68k: Remove inline strcpy() and strcat() implementations

2013-06-24T17:44:18+00:00

Gcc may replace calls to standard string functions by open code and/or
calls to other standard string functions. If the replacement function is
not available out-of-line, link errors will happen.

To avoid this, the out-of-line versions were provided by
arch/m68k/lib/string.c, but they were usually not linked in anymore as
typically none of its symbols are referenced by built-in code.
However, if any module would need them, they would not be available.

Hence remove the inline strcpy() and strcat() implementations, remove
arch/m68k/lib/string.c, and let the generic string library code handle it.

Impact on a typical kernel build seems minimal or nonexistent:

-      .text : 0x00001000 - 0x002aac74   (2728 KiB)
-      .data : 0x002ada48 - 0x00392148   ( 914 KiB)
+      .text : 0x00001000 - 0x002aacf4   (2728 KiB)
+      .data : 0x002adac8 - 0x00392148   ( 914 KiB)

See also commit e00c73ee05dc38ecaccced55d4f5fc58b0b769f7 ("m68k: Remove
inline strlen() implementation").

Signed-off-by: Geert Uytterhoeven

m68k: Remove inline strlen() implementation

2013-04-16T19:35:43+00:00

GCC can replace a strncat() call with constant second argument into a
strlen + store, which results in a link error:

ERROR: "strlen" [net/ipv4/ip_tunnel.ko] undefined!

The inline function is a simple for loop in C. Other architectures
either use an asm optimized variant, or use the generic function from
lib/string.c.

Reported-by: Geert Uytterhoeven 
Signed-off-by: Michal Marek 
Signed-off-by: Geert Uytterhoeven

m68k: fix unused variable warning in mempcy.c

2012-12-05T00:51:23+00:00

When compiling for original 68000 or ColdFire targets you will get the
following warning when compiling arch/m68k/lib/memcpy.c:

  CC      arch/m68k/lib/memcpy.o
arch/m68k/lib/memcpy.c: In function ‘__builtin_memcpy’:
arch/m68k/lib/memcpy.c:13:15: warning: unused variable ‘temp1’

This is easily fixed by moving the definition of temp1 into the code block
where it is used.

Signed-off-by: Greg Ungerer

m68k: delay, muldi3 - Use CONFIG_CPU_HAS_NO_MULDIV64

2012-06-10T08:18:30+00:00

instead of open coding CONFIG_M68000 || CONFIG_COLDFIRE

Signed-off-by: Geert Uytterhoeven 
Acked-by: Greg Ungerer

m68k: Use generic strncpy_from_user(), strlen_user(), and strnlen_user()

2012-06-06T13:31:28+00:00

Signed-off-by: Geert Uytterhoeven 
Acked-by: Greg Ungerer

m68k: modify user space access functions to support ColdFire CPUs

2011-12-30T00:20:21+00:00

Modify the user space access functions to support the ColdFire V4e cores
running with MMU enabled.

The ColdFire processors do not support the "moves" instruction used by
the traditional 680x0 processors for moving data into and out of another
address space. They only support the notion of a single address space,
and you use the usual "move" instruction to access that.

Create a new config symbol (CONFIG_CPU_HAS_ADDRESS_SPACES) to mark the
CPU types that support separate address spaces, and thus also support
the sfc/dfc registers and the "moves" instruction that go along with that.

The code is almost identical for user space access, so lets just use a
define to choose either the "move" or "moves" in the assembler code.

Signed-off-by: Greg Ungerer 
Acked-by: Matt Waddel 
Acked-by: Kurt Mahan 
Acked-by: Geert Uytterhoeven

m68k: handle presence of 64bit mul/div instructions cleanly

2011-12-24T11:47:57+00:00

The traditional 68000 processors and the newer reduced instruction set
ColdFire processors do not support the 32*32->64 multiply or the 64/32->32
divide instructions. This is not a difference based on the presence of
a hardware MMU or not.

Create a new config symbol to mark that a CPU type doesn't support the
longer multiply/divide instructions. Use this then as a basis for using
the fast 64bit based divide (in div64.h) and for linking in the extra
libgcc functions that may be required (mulsi3, divsi3, etc).

Signed-off-by: Greg Ungerer 
Acked-by: Geert Uytterhoeven

m68k: simpler m68k and ColdFire CPU's can use generic csum code

2011-12-24T11:47:57+00:00

We have two implementations of the IP checksuming code for the m68k arch.
One uses the more advanced instructions available in 68020 and above
processors, the other uses the simpler instructions available on the
original 68000 processors and the modern ColdFire processors.

This simpler code is pretty much the same as the generic lib implementation
of the IP csum functions. So lets just switch over to using that. That
means we can completely remove the checksum_no.c file, and only have the
local fast code used for the more complex 68k CPU family members.

Signed-off-by: Greg Ungerer