| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| ... | |
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Fix a hole in the VFP thread migration. Lets define two threads.
Thread 1, we'll call 'interesting_thread' which is a thread which is
running on CPU0, using VFP (so vfp_current_hw_state[0] =
&interesting_thread->vfpstate) and gets migrated off to CPU1, where
it continues execution of VFP instructions.
Thread 2, we'll call 'new_cpu0_thread' which is the thread which takes
over on CPU0. This has also been using VFP, and last used VFP on CPU0,
but doesn't use it again.
The following code will be executed twice:
cpu = thread->cpu;
/*
* On SMP, if VFP is enabled, save the old state in
* case the thread migrates to a different CPU. The
* restoring is done lazily.
*/
if ((fpexc & FPEXC_EN) && vfp_current_hw_state[cpu]) {
vfp_save_state(vfp_current_hw_state[cpu], fpexc);
vfp_current_hw_state[cpu]->hard.cpu = cpu;
}
/*
* Thread migration, just force the reloading of the
* state on the new CPU in case the VFP registers
* contain stale data.
*/
if (thread->vfpstate.hard.cpu != cpu)
vfp_current_hw_state[cpu] = NULL;
The first execution will be on CPU0 to switch away from 'interesting_thread'.
interesting_thread->cpu will be 0.
So, vfp_current_hw_state[0] points at interesting_thread->vfpstate.
The hardware state will be saved, along with the CPU number (0) that
it was executing on.
'thread' will be 'new_cpu0_thread' with new_cpu0_thread->cpu = 0.
Also, because it was executing on CPU0, new_cpu0_thread->vfpstate.hard.cpu = 0,
and so the thread migration check is not triggered.
This means that vfp_current_hw_state[0] remains pointing at interesting_thread.
The second execution will be on CPU1 to switch _to_ 'interesting_thread'.
So, 'thread' will be 'interesting_thread' and interesting_thread->cpu now
will be 1. The previous thread executing on CPU1 is not relevant to this
so we shall ignore that.
We get to the thread migration check. Here, we discover that
interesting_thread->vfpstate.hard.cpu = 0, yet interesting_thread->cpu is
now 1, indicating thread migration. We set vfp_current_hw_state[1] to
NULL.
So, at this point vfp_current_hw_state[] contains the following:
[0] = &interesting_thread->vfpstate
[1] = NULL
Our interesting thread now executes a VFP instruction, takes a fault
which loads the state into the VFP hardware. Now, through the assembly
we now have:
[0] = &interesting_thread->vfpstate
[1] = &interesting_thread->vfpstate
CPU1 stops due to ptrace (and so saves its VFP state) using the thread
switch code above), and CPU0 calls vfp_sync_hwstate().
if (vfp_current_hw_state[cpu] == &thread->vfpstate) {
vfp_save_state(&thread->vfpstate, fpexc | FPEXC_EN);
BANG, we corrupt interesting_thread's VFP state by overwriting the
more up-to-date state saved by CPU1 with the old VFP state from CPU0.
Fix this by ensuring that we have sane semantics for the various state
describing variables:
1. vfp_current_hw_state[] points to the current owner of the context
information stored in each CPUs hardware, or NULL if that state
information is invalid.
2. thread->vfpstate.hard.cpu always contains the most recent CPU number
which the state was loaded into or NR_CPUS if no CPU owns the state.
So, for a particular CPU to be a valid owner of the VFP state for a
particular thread t, two things must be true:
vfp_current_hw_state[cpu] == &t->vfpstate && t->vfpstate.hard.cpu == cpu.
and that is valid from the moment a CPU loads the saved VFP context
into the hardware. This gives clear and consistent semantics to
interpreting these variables.
This patch also fixes thread copying, ensuring that t->vfpstate.hard.cpu
is invalidated, otherwise CPU0 may believe it was the last owner. The
hole can happen thus:
- thread1 runs on CPU2 using VFP, migrates to CPU3, exits and thread_info
freed.
- New thread allocated from a previously running thread on CPU2, reusing
memory for thread1 and copying vfp.hard.cpu.
At this point, the following are true:
new_thread1->vfpstate.hard.cpu == 2
&new_thread1->vfpstate == vfp_current_hw_state[2]
Lastly, this also addresses thread flushing in a similar way to thread
copying. Hole is:
- thread runs on CPU0, using VFP, migrates to CPU1 but does not use VFP.
- thread calls execve(), so thread flush happens, leaving
vfp_current_hw_state[0] intact. This vfpstate is memset to 0 causing
thread->vfpstate.hard.cpu = 0.
- thread migrates back to CPU0 before using VFP.
At this point, the following are true:
thread->vfpstate.hard.cpu == 0
&thread->vfpstate == vfp_current_hw_state[0]
Change-Id: Ifd268aa2499217ad0abd25cb0905b80bc5057229
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: Lanchon <lanchon@gmail.com>
|
| | | |
| | |
| | |
| | | |
Change-Id: Ibc204aae682f175922d1886f93a7c3534c5d5692
|
| | | |
| | |
| | |
| | | |
Change-Id: If01d4a165b4b6bdc26a20fb449104e7bcb0c9403
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Add assembler versions of AES and SHA1 for ARM platforms. This has provided
up to a 50% improvement in IPsec/TCP throughout for tunnels using AES128/SHA1.
Platform CPU SPeed Endian Before (bps) After (bps) Improvement
IXP425 533 MHz big 11217042 15566294 ~38%
KS8695 166 MHz little 3828549 5795373 ~51%
Signed-off-by: David McCullough <ucdevel@gmail.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
ARM: 7626/1: arm/crypto: Make asm SHA-1 and AES code Thumb-2 compatible
This patch fixes aes-armv4.S and sha1-armv4-large.S to work
natively in Thumb. This allows ARM/Thumb interworking workarounds
to be removed.
I also take the opportunity to convert some explicit assembler
directives for exported functions to the standard
ENTRY()/ENDPROC().
For the code itself:
* In sha1_block_data_order, use of TEQ with sp is deprecated in
ARMv7 and not supported in Thumb. For the branches back to
.L_00_15 and .L_40_59, the TEQ is converted to a CMP, under the
assumption that clobbering the C flag here will not cause
incorrect behaviour.
For the first branch back to .L_20_39_or_60_79 the C flag is
important, so sp is moved temporarily into another register so
that TEQ can be used for the comparison.
* In the AES code, most forms of register-indexed addressing with
shifts and rotates are not permitted for loads and stores in
Thumb, so the address calculation is done using a separate
instruction for the Thumb case.
The resulting code is unlikely to be optimally scheduled, but it
should not have a large impact given the overall size of the code.
I haven't run any benchmarks.
Signed-off-by: Dave Martin <dave.martin@linaro.org>
Tested-by: David McCullough <ucdevel@gmail.com> (ARM only)
Acked-by: David McCullough <ucdevel@gmail.com>
Acked-by: Nicolas Pitre <nico@linaro.org>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
ARM: 7723/1: crypto: sha1-armv4-large.S: fix SP handling
Make the SHA1 asm code ABI conformant by making sure all stack
accesses occur above the stack pointer.
Origin:
http://git.openssl.org/gitweb/?p=openssl.git;a=commit;h=1a9d60d2
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Acked-by: Nicolas Pitre <nico@linaro.org>
Cc: stable@vger.kernel.org
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
ARM: 7837/3: fix Thumb-2 bug in AES assembler code
commit 40190c85f427dcfdbab5dbef4ffd2510d649da1f upstream.
Patch 638591c enabled building the AES assembler code in Thumb2 mode.
However, this code used arithmetic involving PC rather than adr{l}
instructions to generate PC-relative references to the lookup tables,
and this needs to take into account the different PC offset when
running in Thumb mode.
Change-Id: I0d036eaa94dabefa0a025d522f415c663d00ae9f
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Acked-by: Nicolas Pitre <nico@linaro.org>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
| | | |
| | |
| | |
| | | |
Change-Id: Ie15e742139768865672990ba29757105447076ad
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Commit 455bd4c430b0 ("ARM: 7668/1: fix memset-related crashes caused by
recent GCC (4.7.2) optimizations") attempted to fix a compliance issue
with the memset return value. However the memset itself became broken
by that patch for misaligned pointers.
This fixes the above by branching over the entry code from the
misaligned fixup code to avoid reloading the original pointer.
Also, because the function entry alignment is wrong in the Thumb mode
compilation, that fixup code is moved to the end.
While at it, the entry instructions are slightly reworked to help dual
issue pipelines.
Signed-off-by: Nicolas Pitre <nico@linaro.org>
Tested-by: Alexander Holler <holler@ahsoftware.de>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Change-Id: Ifdc6b0167104b42d23a72ffe5e6173f6e14c97ee
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
optimizations
Recent GCC versions (e.g. GCC-4.7.2) perform optimizations based on
assumptions about the implementation of memset and similar functions.
The current ARM optimized memset code does not return the value of
its first argument, as is usually expected from standard implementations.
For instance in the following function:
void debug_mutex_lock_common(struct mutex *lock, struct mutex_waiter *waiter)
{
memset(waiter, MUTEX_DEBUG_INIT, sizeof(*waiter));
waiter->magic = waiter;
INIT_LIST_HEAD(&waiter->list);
}
compiled as:
800554d0 <debug_mutex_lock_common>:
800554d0: e92d4008 push {r3, lr}
800554d4: e1a00001 mov r0, r1
800554d8: e3a02010 mov r2, #16 ; 0x10
800554dc: e3a01011 mov r1, #17 ; 0x11
800554e0: eb04426e bl 80165ea0 <memset>
800554e4: e1a03000 mov r3, r0
800554e8: e583000c str r0, [r3, #12]
800554ec: e5830000 str r0, [r3]
800554f0: e5830004 str r0, [r3, #4]
800554f4: e8bd8008 pop {r3, pc}
GCC assumes memset returns the value of pointer 'waiter' in register r0; causing
register/memory corruptions.
This patch fixes the return value of the assembly version of memset.
It adds a 'mov' instruction and merges an additional load+store into
existing load/store instructions.
For ease of review, here is a breakdown of the patch into 4 simple steps:
Step 1
======
Perform the following substitutions:
ip -> r8, then
r0 -> ip,
and insert 'mov ip, r0' as the first statement of the function.
At this point, we have a memset() implementation returning the proper result,
but corrupting r8 on some paths (the ones that were using ip).
Step 2
======
Make sure r8 is saved and restored when (! CALGN(1)+0) == 1:
save r8:
- str lr, [sp, #-4]!
+ stmfd sp!, {r8, lr}
and restore r8 on both exit paths:
- ldmeqfd sp!, {pc} @ Now <64 bytes to go.
+ ldmeqfd sp!, {r8, pc} @ Now <64 bytes to go.
(...)
tst r2, #16
stmneia ip!, {r1, r3, r8, lr}
- ldr lr, [sp], #4
+ ldmfd sp!, {r8, lr}
Step 3
======
Make sure r8 is saved and restored when (! CALGN(1)+0) == 0:
save r8:
- stmfd sp!, {r4-r7, lr}
+ stmfd sp!, {r4-r8, lr}
and restore r8 on both exit paths:
bgt 3b
- ldmeqfd sp!, {r4-r7, pc}
+ ldmeqfd sp!, {r4-r8, pc}
(...)
tst r2, #16
stmneia ip!, {r4-r7}
- ldmfd sp!, {r4-r7, lr}
+ ldmfd sp!, {r4-r8, lr}
Step 4
======
Rewrite register list "r4-r7, r8" as "r4-r8".
Signed-off-by: Ivan Djelic <ivan.djelic@parrot.com>
Reviewed-by: Nicolas Pitre <nico@linaro.org>
Signed-off-by: Dirk Behme <dirk.behme@gmail.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Change-Id: Ie0c05696ed7c2e0d0a934233947e6a4b935e3405
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
defconfig: cyanogenmod_n7000_defconfig
Fix two mali400 drivers compile together
Use mali400 r3p2 driver,disabled mali r3p1 driver.
Change-Id: Ia6c4290414b3f97f57b38da41dae6107c4d9c657
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | | |
* noticed these CONSTANTLY flooding the log with screen off
using wireless adb (so it was unplugged)
Change-Id: I4df4f0da9f62cfd86552b77c71d4a2de11dac5d4
|
| | | |
| | |
| | |
| | | |
Change-Id: I08dc1617e3f77b63a4eee45f78abbb989a5276f4
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | | |
This patch enables 'scaling_available_frequencies' attribute
showing list of available frequencies.
Change-Id: I9b6ad786ffaaba8ad6fe5aa9045fd793c095b5ae
|
| | | |
| | |
| | |
| | | |
Change-Id: I21144c9f3146c9043b137f180c064627ebeed71e
|
| | | |
| | |
| | |
| | | |
Change-Id: Ifd1bd76ec2ebf8014107747474145d0bfc9a3281
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
this corrects a bug where after pressing the button on a headset the mic becomes muted.
partial commit of "sound-soc: Sound platform and WM1811 changes" by SamsungOSRC
Change-Id: I3593e7f0d19b4450d8a3ec55debaede4f80e01c0
|
| | | |
| | |
| | |
| | | |
Change-Id: If1db8d46c3547b807eb3d4ca1fe739b7b932ffb9
|
| | | |
| | |
| | |
| | | |
Change-Id: I920dfbfea63e07bde185c36d6b555a18f7a37747
|
| | |\ \ |
|
| | | | |
| | | |
| | | |
| | | | |
Change-Id: I2b0af5e9b52ac0aba26628b67d06f2a9453ba2b8
|
| | |/ /
| | |
| | |
| | |
| | |
| | | |
Courtesy of a similar commit from OMNI ROM. Requires updated mali blobs
Change-Id: I9ee55b653b57b7c390f8e0e8cd4fc068f1c751c3
|
| | | |
| | |
| | |
| | | |
Change-Id: I7f6dbdd97e3ed66634bf123d43224a79524c04e9
|
| | | |
| | |
| | |
| | | |
Change-Id: I6c9798682f9f6349b37cb452353bd0c0e6958401
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Bug https://jira.cyanogenmod.org/browse/CYAN-2419
Could be applied on GT-I9305 and N7100 after tests.
Change-Id: I9bd094f0f672fa67c7a36ec52e1133afe6b06c8d
|
| | | |
| | |
| | |
| | |
| | | |
Signed-off-by: Humberto Borba <humberos@gmail.com>
Change-Id: I73e4f237c5cf67643f96930b3862155966bbf8bc
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
This reverts commit 1a05356029493b29f866cf04f7550243ef3ae687, the
enumerator breakage introduced by change Iafbd9fb45253b02d539ac0ba114f57b3bf9eeed4
can be reverted cleanly without further impact and it's a cleaner fix
Change-Id: I351c320f98691241fbe321a0b1ac54152802deb4
|
| | | |
| | |
| | |
| | | |
Change-Id: I1dd142d0b168101a8170e742d115bf70a47daa48
|
| | | |
| | |
| | |
| | | |
Change-Id: I20678ad210403fc0cbb894fe16ba0edc357020b4
|
| | | |
| | |
| | |
| | | |
Signed-off-by: Paul Kocialkowski <contact@paulk.fr>
|
| | | |
| | |
| | |
| | | |
Signed-off-by: Paul Kocialkowski <contact@paulk.fr>
|
| |/ /
| |
| |
| |
| |
| |
| |
| | |
This reverts commit 1a05356029493b29f866cf04f7550243ef3ae687, the
enumerator breakage introduced by change Iafbd9fb45253b02d539ac0ba114f57b3bf9eeed4
can be reverted cleanly without further impact and it's a cleaner fix
Change-Id: I351c320f98691241fbe321a0b1ac54152802deb4
|
| | |
| |
| |
| | |
Change-Id: I90ed70f2071c5328d71a18e6cbd0cb8a8cc0c82d
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Why the hell does Samsung keep on derping the Makefile for GPS on
n80xx devices? I'm getting tired of fixing this crap over and over
again.
Before they assumed wifi N80xx units didn't have GPS. Now they're
keying compilation of the GPS stuff off of a nonexistent config
entry.
grr
Change-Id: I034c521e6f398aa0d5f3a4fa1bb97e30e401a807
|
| | |
| |
| |
| | |
Change-Id: I17d3befd6a6538c16db0675253927068a09085c6
|
| | |
| |
| |
| | |
Change-Id: Iafbd9fb45253b02d539ac0ba114f57b3bf9eeed4
|
| | |
| |
| |
| | |
Change-Id: I9ab2dd10866b3b68cf86fbee9f95c130dc664192
|
| | |
| |
| |
| | |
Change-Id: Icd3e7b601f3f4c8b3dcf053fed5819fb7caf5296
|
| | |
| |
| |
| | |
Change-Id: I84dc53e949be90ca464cb80432105130d089dd90
|
| | |
| |
| |
| | |
Change-Id: Iab4e05f831e09d6cb2b40a2117accdb5b903a6b2
|
| | |
| |
| |
| | |
Change-Id: Iefbeee4aa149eaf9a5aca1651cc39a592f0e4208
|
| | |
| |
| |
| |
| |
| |
| | |
This reduces the janky scrolling observed
Picked from : https://github.com/kgp700/exyroid-sgs2-jb/commit/2476a919c24f07e04f50a80442fc65d27af51ff5
Change-Id: I07c166f6f07b2874fa20be6f41bc5a016d93e653
|
| | |
| |
| |
| | |
Change-Id: If3270ba8e454d224d18202ff5e751fc61792b4d7
|
| | |
| |
| |
| | |
Change-Id: Ibf954e20e70c9e6dac75b8e1da02bf5a1152098c
|
| | |
| |
| |
| | |
Change-Id: I9629a4060538c9c4c6a43a86a56826cd7123d1b5
|
| | |
| |
| |
| |
| |
| | |
On OSX hosts the md5sum executable is called md5 instead.
Change-Id: I0b8e3ab137136be6e45fd4b9f77f2c036e8b981a
|
| | |
| |
| |
| | |
Change-Id: I7f0e89e533f7d639d88da16bd56ccc931eb36ad7
|
| | |
| |
| |
| | |
Change-Id: I3a8ffe754b222d553975ca0ea85489f8f71bdbbd
|
| | |
| |
| |
| | |
Change-Id: I210846d796a04daf844924129626f4b9ca0ed1ec
|
| | |
| |
| |
| | |
Change-Id: Ifed3eefcbc081b3cdde4082ec86c8a39a2a3071a
|
| | |
| |
| |
| | |
Change-Id: Ic5d7355620b6762b6a6b0e39d8fb895c119d1dce
|
| | |
| |
| |
| | |
Change-Id: Iaa76975d4635d2f5c560d39fbf23919410e7e64f
|
| | |
| |
| |
| | |
Change-Id: I67f753a0702f224c6202247d0fd500c719326a96
|
