linux-dev - Linux kernel development work

Age	Commit message (Collapse)	Author	Files	Lines
2011-05-27	ARM: 6945/1: Add unwinding support for division functions	Laura Abbott	1	-5/+20
	The software division functions never had unwinding annotations added. Currently, when a division by zero occurs the backtrace shown will stop at Ldiv0 or some completely unrelated function. Add unwinding annotations in hopes of getting a more useful backtrace when a division by zero occurs. Signed-off-by: Laura Abbott <lauraa@codeaurora.org> Acked-by: Dave Martin <dave.martin@linaro.org> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2009-09-15	Nicolas Pitre has a new email address	Nicolas Pitre	1	-1/+1
	Due to problems at cam.org, my nico@cam.org email address is no longer valid. FRom now on, nico@fluxnic.net should be used instead. Signed-off-by: Nicolas Pitre <nico@fluxnic.net> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2008-09-01	[ARM] 5227/1: Add the ENDPROC declarations to the .S files	Catalin Marinas	1	-0/+11
	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-01-14	[ARM] 3104/1: ARM EABI: new helper function names	Nicolas Pitre	1	-0/+23
	Patch from Nicolas Pitre The ARM EABI defines new names for GCC helper functions. Signed-off-by: Nicolas Pitre <nico@cam.org> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2006-01-14	[ARM] 3103/1: ARM EABI: stack pointer must be 64-bit aligned (part 2)	Nicolas Pitre	1	-2/+2
	Patch from Nicolas Pitre We must make sure that assembly code that modifies the stack pointer before calling a C function does it so it remains 64-bit aligned. Signed-off-by: Nicolas Pitre <nico@cam.org> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2005-04-16	Linux-2.6.12-rc2	Linus Torvalds	1	-0/+314
	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!