summaryrefslogtreecommitdiff
path: root/arch/arm/lib/strncpy_from_user.S
AgeCommit message (Collapse)AuthorFilesLines
2010-04-21ARM: fix build error in arch/arm/kernel/process.cRussell King1-2/+2
/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>
2009-07-24Thumb-2: Implement the unified arch/arm/lib functionsCatalin Marinas1-1/+1
This patch adds the ARM/Thumb-2 unified support for the arch/arm/lib/* files. Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
2008-09-01[ARM] 5227/1: Add the ENDPROC declarations to the .S filesCatalin Marinas1-0/+1
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>
2006-06-28[ARM] Remove the __arch_* layer from uaccess.hRussell King1-1/+1
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>
2006-06-25[ARM] Remove save_lr/restore_pc macrosRussell King1-3/+2
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>
2005-04-17Linux-2.6.12-rc2v2.6.12-rc2Linus Torvalds1-0/+43
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!