<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel.git/arch/arm/kernel, branch linux-2.6.37.y</title>
<subtitle>Hosts the 0x221E linux distro kernel.
</subtitle>
<id>https://git.0xinfinity.dev/distro/kernel.git/atom?h=linux-2.6.37.y</id>
<link rel='self' href='https://git.0xinfinity.dev/distro/kernel.git/atom?h=linux-2.6.37.y'/>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/'/>
<updated>2011-02-24T22:54:37Z</updated>
<entry>
<title>ARM: Keep exit text/data around for SMP_ON_UP</title>
<updated>2011-02-24T22:54:37Z</updated>
<author>
<name>Russell King</name>
</author>
<published>2011-02-21T10:13:36Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=9c7fa067fc9e25a086a8039192b20059c6d7d293'/>
<id>urn:sha1:9c7fa067fc9e25a086a8039192b20059c6d7d293</id>
<content type='text'>
commit a9ad21fed09cb95d34af9474be0831525b30c4c6 upstream.

When SMP_ON_UP is used and the spinlocks are inlined, we end up with
inline spinlocks in the exit code, with references from the SMP
alternatives section to the exit sections.  This causes link time
errors.  Avoid this by placing the exit sections in the init-discarded
region.

Tested-by: Dave Martin &lt;dave.martin@linaro.org&gt;
Signed-off-by: Russell King &lt;rmk+kernel@arm.linux.org.uk&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</content>
</entry>
<entry>
<title>ARM: Ensure predictable endian state on signal handler entry</title>
<updated>2011-02-24T22:54:37Z</updated>
<author>
<name>Russell King</name>
</author>
<published>2011-02-20T12:22:52Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=854ea584c38a037f90fc9f7edcce0cd81232001f'/>
<id>urn:sha1:854ea584c38a037f90fc9f7edcce0cd81232001f</id>
<content type='text'>
commit 53399053eb505cf541b2405bd9d9bca5ecfb96fb upstream.

Ensure a predictable endian state when entering signal handlers.  This
avoids programs which use SETEND to momentarily switch their endian
state from having their signal handlers entered with an unpredictable
endian state.

Acked-by: Dave Martin &lt;dave.martin@linaro.org&gt;
Signed-off-by: Russell King &lt;rmk+kernel@arm.linux.org.uk&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</content>
</entry>
<entry>
<title>ARM: smp_on_up: allow non-ARM SMP processors</title>
<updated>2011-02-17T23:14:44Z</updated>
<author>
<name>Russell King</name>
</author>
<published>2011-01-30T16:40:20Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=b770e599b231a81cf53e00beee29261cfc8be46c'/>
<id>urn:sha1:b770e599b231a81cf53e00beee29261cfc8be46c</id>
<content type='text'>
commit e98ff0f55a0232b578c9aa7f1c245868277ac7bc upstream.

Allow non-ARM SMP processors to use the SMP_ON_UP feature.  CPUs
supporting SMP must have the new CPU ID format, so check for this first.
Then check for ARM11MPCore, which fails the MPIDR check.  Lastly check
the MPIDR reports multiprocessing extensions and that the CPU is part of
a multiprocessing system.

Reported-and-Tested-by: Stephen Boyd &lt;sboyd@codeaurora.org&gt;
Acked-by: Will Deacon &lt;will.deacon@arm.com&gt;
Signed-off-by: Russell King &lt;rmk+kernel@arm.linux.org.uk&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</content>
</entry>
<entry>
<title>ARM: SMP: use more sane register allocation for __fixup_smp_on_up</title>
<updated>2011-02-17T23:14:43Z</updated>
<author>
<name>Russell King</name>
</author>
<published>2010-11-22T12:06:28Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=3eb02dfd31bf0d6ada5c78a4136b215144871011'/>
<id>urn:sha1:3eb02dfd31bf0d6ada5c78a4136b215144871011</id>
<content type='text'>
commit 0eb0511d176534674600a1986c3c766756288908 upstream.

Use r0,r3-r6 rather than r0,r3,r4,r6,r7, which makes it easier to
understand which registers can be modified.  Also document which
registers hold values which must be preserved.

Signed-off-by: Russell King &lt;rmk+kernel@arm.linux.org.uk&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</content>
</entry>
<entry>
<title>ARM: 6540/1: Stop irqsoff trace on return to user</title>
<updated>2010-12-24T09:37:59Z</updated>
<author>
<name>Todd Android Poynor</name>
</author>
<published>2010-12-23T00:52:44Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=d13e5edd7284bedcf5952e1b6490e39ad843cb91'/>
<id>urn:sha1:d13e5edd7284bedcf5952e1b6490e39ad843cb91</id>
<content type='text'>
If the irqsoff tracer is in use, stop tracing the interrupt disable
interval when returning to userspace.  Tracing userspace execution time
as interrupts disabled time is not helpful for kernel performance
analysis purposes.  Only do so if the irqsoff tracer is enabled, to
avoid overhead for lockdep, which doesn't care.

Signed-off-by: Todd Poynor &lt;toddpoynor@google.com&gt;
Signed-off-by: Russell King &lt;rmk+kernel@arm.linux.org.uk&gt;
</content>
</entry>
<entry>
<title>ARM: smp: avoid incrementing mm_users on CPU startup</title>
<updated>2010-12-18T13:57:00Z</updated>
<author>
<name>Russell King</name>
</author>
<published>2010-12-18T13:57:00Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=1ae1b5f053cf36bd0f913e83f3b136fec8152d4d'/>
<id>urn:sha1:1ae1b5f053cf36bd0f913e83f3b136fec8152d4d</id>
<content type='text'>
We should not be incrementing mm_users when we startup a secondary
CPU - doing so results in mm_users incrementing by one each time we
hotplug a CPU, which will eventually wrap, and will cause problems.

Other architectures such as x86 do not increment mm_users, but only
mm_count, so we follow that pattern.

Signed-off-by: Russell King &lt;rmk+kernel@arm.linux.org.uk&gt;
</content>
</entry>
<entry>
<title>ARM: 6519/1: kuser: Fix incorrect cmpxchg syscall in kuser helpers</title>
<updated>2010-12-04T11:01:12Z</updated>
<author>
<name>Dave Martin</name>
</author>
<published>2010-12-01T17:12:43Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=55afd264cdd5d5848753e90884ed596e11bce0ff'/>
<id>urn:sha1:55afd264cdd5d5848753e90884ed596e11bce0ff</id>
<content type='text'>
The existing code invokes the syscall with rubbish in r7,
due to what looks like an incorrect literal load idiom.

Reviewed-by: Will Deacon &lt;will.deacon@arm.com&gt;
Signed-off-by: Dave Martin &lt;dave.martin@linaro.org&gt;
Acked-by: Catalin Marinas &lt;catalin.marinas@arm.com&gt;
Signed-off-by: Russell King &lt;rmk+kernel@arm.linux.org.uk&gt;
</content>
</entry>
<entry>
<title>ARM: 6504/1: Thumb-2: Fix long-distance conditional branches in head.S for Thumb-2.</title>
<updated>2010-11-30T13:44:26Z</updated>
<author>
<name>Dave Martin</name>
</author>
<published>2010-11-29T18:43:28Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=a75e5248c51af1eaeed936be6bd3497b93f09685'/>
<id>urn:sha1:a75e5248c51af1eaeed936be6bd3497b93f09685</id>
<content type='text'>
The 32-bit conditional branches in Thumb-2 have a shorter range
(+/-512K) than their ARM counterparts (+/-32MB).  The linker does
not currently generate trampolines to extend the range of these
Thumb-2 conditional branches, resulting in link errors when vmlinux
is sufficiently large, e.g.:

head.o:(.text+0x464): relocation truncated to fit: R_ARM_THM_JUMP19

This patch forces the longer-range, unconditional branch encoding
by use of an explicit IT instruction.  The resulting branches are
triggered on the same conditions as before.

Signed-off-by: Dave Martin &lt;dave.martin@linaro.org&gt;
Signed-off-by: Russell King &lt;rmk+kernel@arm.linux.org.uk&gt;
</content>
</entry>
<entry>
<title>ARM: 6500/1: Thumb-2: Correct data alignment for CONFIG_THUMB2_KERNEL in kernel/head.S</title>
<updated>2010-11-30T13:44:24Z</updated>
<author>
<name>Dave Martin</name>
</author>
<published>2010-11-29T18:43:24Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=4f79a5dd7c3e316e2230dc0ee665c40a39023a81'/>
<id>urn:sha1:4f79a5dd7c3e316e2230dc0ee665c40a39023a81</id>
<content type='text'>
Directives such as .long and .word do not magically cause the
assembler location counter to become aligned in gas.  As a result,
using these directives in code sections can result in misaligned
data words when building a Thumb-2 kernel (CONFIG_THUMB2_KERNEL).

This is a Bad Thing, since the ABI permits the compiler to assume
that fundamental types of word size or above are word- aligned when
accessing them from C.  If the data is not really word-aligned,
this can cause impaired performance and stray alignment faults in
some circumstances.

In general, the following rules should be applied when using data
word declaration directives inside code sections:

    * .quad and .double:
         .align 3

    * .long, .word, .single, .float:
         .align (or .align 2)

    * .short:
        No explicit alignment required, since Thumb-2
        instructions are always 2 or 4 bytes in size.
        immediately after an instruction.

Reviewed-by: Will Deacon &lt;will.deacon@arm.com&gt;
Signed-off-by: Dave Martin &lt;dave.martin@linaro.org&gt;
Acked-by: Catalin Marinas &lt;catalin.marinas@arm.com&gt;
Signed-off-by: Russell King &lt;rmk+kernel@arm.linux.org.uk&gt;
</content>
</entry>
<entry>
<title>ARM: 6497/1: kexec: Correct data alignment for CONFIG_THUMB2_KERNEL</title>
<updated>2010-11-30T13:44:23Z</updated>
<author>
<name>Dave Martin</name>
</author>
<published>2010-11-29T18:43:21Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=bc8b57f08c53344d13e3b5e644c56c0355899b47'/>
<id>urn:sha1:bc8b57f08c53344d13e3b5e644c56c0355899b47</id>
<content type='text'>
Directives such as .long and .word do not magically cause the
assembler location counter to become aligned in gas.  As a result,
using these directives in code sections can result in misaligned
data words when building a Thumb-2 kernel (CONFIG_THUMB2_KERNEL).

This is a Bad Thing, since the ABI permits the compiler to assume
that fundamental types of word size or above are word- aligned when
accessing them from C.  If the data is not really word-aligned,
this can cause impaired performance and stray alignment faults in
some circumstances.

In general, the following rules should be applied when using data
word declaration directives inside code sections:

    * .quad and .double:
         .align 3

    * .long, .word, .single, .float:
         .align (or .align 2)

    * .short:
        No explicit alignment required, since Thumb-2
        instructions are always 2 or 4 bytes in size.
        immediately after an instruction.

Reviewed-by: Will Deacon &lt;will.deacon@arm.com&gt;
Signed-off-by: Dave Martin &lt;dave.martin@linaro.org&gt;
Acked-by: Catalin Marinas &lt;catalin.marinas@arm.com&gt;
Signed-off-by: Russell King &lt;rmk+kernel@arm.linux.org.uk&gt;
</content>
</entry>
</feed>
