asgardius/android_kernel_motorola_sm6225

Fork 0

Commit graph

Author	SHA1	Message	Date
Nicolas Pitre	499b2ea11f	[ARM] 3103/1: ARM EABI: stack pointer must be 64-bit aligned (part 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>	2006-01-14 16:18:09 +00:00
Russell King	63150fcf73	[ARM] Fix warning in arch/arm/kernel/semaphore.c Newer binutils complains: /tmp/cc07pbI9.s:146: Warning: ignoring changed section type for .sched.text Fix this warning by adding %progbits to the .section. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>	2005-09-18 21:49:29 +01:00
Linus Torvalds	1da177e4c3	Linux-2.6.12-rc2 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!	2005-04-16 15:20:36 -07:00

Author

SHA1

Message

Date

Nicolas Pitre

499b2ea11f

[ARM] 3103/1: ARM EABI: stack pointer must be 64-bit aligned (part 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>

2006-01-14 16:18:09 +00:00

Russell King

63150fcf73

[ARM] Fix warning in arch/arm/kernel/semaphore.c

Newer binutils complains:
/tmp/cc07pbI9.s:146: Warning: ignoring changed section type for .sched.text

Fix this warning by adding %progbits to the .section.

Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>

2005-09-18 21:49:29 +01:00

Linus Torvalds

1da177e4c3

Linux-2.6.12-rc2

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!

2005-04-16 15:20:36 -07:00

3 commits