linux-toradex.git/arch/arm/lib/strncpy_from_user.S, branch v3.4.18 Linux kernel for Apalis and Colibri modules ARM: fix build error in arch/arm/kernel/process.c 2010-04-21T07:45:21+00:00 Russell King rmk+kernel@arm.linux.org.uk 2010-04-19T09:15:03+00:00 4260415f6a3b92c5c986398d96c314df37a4ccbf /tmp/ccJ3ssZW.s: Assembler messages: /tmp/ccJ3ssZW.s:1952: Error: can't resolve `.text' {.text section} - `.LFB1077' This is caused because: .section .data .section .text .section .text .previous does not return us to the .text section, but the .data section; this makes use of .previous dangerous if the ordering of previous sections is not known. Fix up the other users of .previous; .pushsection and .popsection are a safer pairing to use than .section and .previous. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> 
/tmp/ccJ3ssZW.s: Assembler messages:
/tmp/ccJ3ssZW.s:1952: Error: can't resolve `.text' {.text section} - `.LFB1077'

This is caused because:

	.section .data
	.section .text
	.section .text
	.previous

does not return us to the .text section, but the .data section; this
makes use of .previous dangerous if the ordering of previous sections
is not known.

Fix up the other users of .previous; .pushsection and .popsection are
a safer pairing to use than .section and .previous.

Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Thumb-2: Implement the unified arch/arm/lib functions 2009-07-24T11:32:57+00:00 Catalin Marinas catalin.marinas@arm.com 2009-07-24T11:32:57+00:00 8b592783a2e8b7721a99730bd549aab5208f36af This patch adds the ARM/Thumb-2 unified support for the arch/arm/lib/* files. Signed-off-by: Catalin Marinas <catalin.marinas@arm.com> 
This patch adds the ARM/Thumb-2 unified support for the arch/arm/lib/*
files.

Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
[ARM] 5227/1: Add the ENDPROC declarations to the .S files 2008-09-01T11:06:34+00:00 Catalin Marinas catalin.marinas@arm.com 2008-08-28T10:22:32+00:00 93ed3970114983543bbebd195bef65db84444ea2 This declaration specifies the "function" type and size for various assembly functions, mainly needed for generating the correct branch instructions in Thumb-2. Signed-off-by: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> 
This declaration specifies the "function" type and size for various
assembly functions, mainly needed for generating the correct branch
instructions in Thumb-2.

Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
[ARM] Remove the __arch_* layer from uaccess.h 2006-06-28T16:53:27+00:00 Russell King rmk@dyn-67.arm.linux.org.uk 2006-06-21T13:44:52+00:00 02fcb974369d21c3df61d4ac5a2e1a58dce86495 Back in the days when we had armo (26-bit) and armv (32-bit) combined, we had an additional layer to the uaccess macros to ensure correct typing. Since we no longer have 26-bit in this tree, we no longer need this layer, so eliminate it. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> 
Back in the days when we had armo (26-bit) and armv (32-bit) combined,
we had an additional layer to the uaccess macros to ensure correct
typing.  Since we no longer have 26-bit in this tree, we no longer
need this layer, so eliminate it.

Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
[ARM] Remove save_lr/restore_pc macros 2006-06-25T10:37:09+00:00 Russell King rmk@dyn-67.arm.linux.org.uk 2006-06-25T10:37:09+00:00 405040a78b33e39edf4180fc993b9608f07d3c41 As for RETINSTR/LOADREGS macros, these were for compatibility with 26-bit ARMs. No longer required, so remove them. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> 
As for RETINSTR/LOADREGS macros, these were for compatibility
with 26-bit ARMs.  No longer required, so remove them.

Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Linux-2.6.12-rc2 2005-04-16T22:20:36+00:00 Linus Torvalds torvalds@ppc970.osdl.org 2005-04-16T22:20:36+00:00 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip! 
Initial git repository build. I'm not bothering with the full history,
even though we have it. We can create a separate "historical" git
archive of that later if we want to, and in the meantime it's about
3.2GB when imported into git - space that would just make the early
git days unnecessarily complicated, when we don't have a lot of good
infrastructure for it.

Let it rip!