13 Apr, 2012
2 commits
-
commit 6cfeba53911d6d2f17ebbd1246893557d5ff5aeb upstream.
On multi-platform kernels, the Mac platform devices should be registered
when running on Mac only. Else it may crash later.Signed-off-by: Geert Uytterhoeven
Signed-off-by: Greg Kroah-Hartman -
[ Upstream commit 1d24fb3684f347226747c6b11ea426b7b992694e ]
When K >= 0xFFFF0000, AND needs the two least significant bytes of K as
its operand, but EMIT2() gives it the least significant byte of K and
0x2. EMIT() should be used here to replace EMIT2().Signed-off-by: Feiran Zhuang
Acked-by: Eric Dumazet
Signed-off-by: David S. Miller
Signed-off-by: Greg Kroah-Hartman
03 Apr, 2012
9 commits
-
commit 8f0750f19789cf352d7e24a6cc50f2ab1b4f1372 upstream.
These are used as offsets into an array of GDT_ENTRY_TLS_ENTRIES members
so GDT_ENTRY_TLS_ENTRIES is one past the end of the array.Signed-off-by: Dan Carpenter
Link: http://lkml.kernel.org/r/20120324075250.GA28258@elgon.mountain
Signed-off-by: H. Peter Anvin
Signed-off-by: Greg Kroah-Hartman -
commit 57779dc2b3b75bee05ef5d1ada47f615f7a13932 upstream.
While running the latest Linux as guest under VMware in highly
over-committed situations, we have seen cases when the refined TSC
algorithm fails to get a valid tsc_start value in
tsc_refine_calibration_work from multiple attempts. As a result the
kernel keeps on scheduling the tsc_irqwork task for later. Subsequently
after several attempts when it gets a valid start value it goes through
the refined calibration and either bails out or uses the new results.
Given that the kernel originally read the TSC frequency from the
platform, which is the best it can get, I don't think there is much
value in refining it.So for systems which get the TSC frequency from the platform we
should skip the refined tsc algorithm.We can use the TSC_RELIABLE cpu cap flag to detect this, right now it is
set only on VMware and for Moorestown Penwell both of which have there
own TSC calibration methods.Signed-off-by: Alok N Kataria
Cc: John Stultz
Cc: Dirk Brandewie
Cc: Alan Cox
[jstultz: Reworked to simply not schedule the refining work,
rather then scheduling the work and bombing out later]
Signed-off-by: John Stultz
Signed-off-by: Greg Kroah-Hartman -
[ Upstream commit dc72d99dabb870ca5bd6d9fff674be853bb4a88d ]
Matt Evans spotted that x86 bpf_jit was incorrectly handling negative
constant offsets in BPF_S_LDX_B_MSH instruction.We need to abort JIT compilation like we do in common_load so that
filter uses the interpreter code and can call __load_pointer()Reference: http://lists.openwall.net/netdev/2011/07/19/11
Thanks to Indan Zupancic to bring back this issue.
Reported-by: Matt Evans
Reported-by: Indan Zupancic
Signed-off-by: Eric Dumazet
Signed-off-by: David S. Miller
Signed-off-by: Greg Kroah-Hartman -
commit f35b431dde39fb40944d1024f08d88fbf04a3193 upstream.
The ARM IP revisions in Tegra are:
Tegra20: CPU r1p1, PL310 r2p0
Tegra30: CPU A01=r2p7/>=A02=r2p9, NEON r2p3-50, PL310 r3p1-50Based on work by Olof Johansson, although the actual list of errata is
somewhat different here, since I added a bunch more and removed one PL310
erratum that doesn't seem applicable.Signed-off-by: Stephen Warren
Signed-off-by: Olof Johansson
Signed-off-by: Greg Kroah-Hartman -
commit 29a2e2836ff9ea65a603c89df217f4198973a74f upstream.
The problem occurs on !CONFIG_VM86 kernels [1] when a kernel-mode task
returns from a system call with a pending signal.A real-life scenario is a child of 'khelper' returning from a failed
kernel_execve() in ____call_usermodehelper() [ kernel/kmod.c ].
kernel_execve() fails due to a pending SIGKILL, which is the result of
"kill -9 -1" (at least, busybox's init does it upon reboot).The loop is as follows:
* syscall_exit_work:
- work_pending: // start_of_the_loop
- work_notify_sig:
- do_notify_resume()
- do_signal()
- if (!user_mode(regs)) return;
- resume_userspace // TIF_SIGPENDING is still set
- work_pending // so we call work_pending => goto
// start_of_the_loopMore information can be found in another LKML thread:
http://www.serverphorums.com/read.php?12,457826[1] the problem was also seen on MIPS.
Signed-off-by: Dmitry Adamushko
Link: http://lkml.kernel.org/r/1332448765.2299.68.camel@dimm
Cc: Oleg Nesterov
Cc: Roland McGrath
Cc: Andrew Morton
Signed-off-by: H. Peter Anvin
Signed-off-by: Greg Kroah-Hartman -
commit c2226fc9e87ba3da060e47333657cd6616652b84 upstream.
On hosts without this patch, 32bit guests will crash (and 64bit guests
may behave in a wrong way) for example by simply executing following
nasm-demo-application:[bits 32]
global _start
SECTION .text
_start: syscall(I tested it with winxp and linux - both always crashed)
Disassembly of section .text:
00000000 :
0: 0f 05 syscallThe reason seems a missing "invalid opcode"-trap (int6) for the
syscall opcode "0f05", which is not available on Intel CPUs
within non-longmodes, as also on some AMD CPUs within legacy-mode.
(depending on CPU vendor, MSR_EFER and cpuid)Because previous mentioned OSs may not engage corresponding
syscall target-registers (STAR, LSTAR, CSTAR), they remain
NULL and (non trapping) syscalls are leading to multiple
faults and finally crashs.Depending on the architecture (AMD or Intel) pretended by
guests, various checks according to vendor's documentation
are implemented to overcome the current issue and behave
like the CPUs physical counterparts.[mtosatti: cleanup/beautify code]
Signed-off-by: Stephan Baerwolf
Signed-off-by: Marcelo Tosatti
Signed-off-by: Stefan Bader
Signed-off-by: Greg Kroah-Hartman -
commit bdb42f5afebe208eae90406959383856ae2caf2b upstream.
In order to be able to proceed checks on CPU-specific properties
within the emulator, function "get_cpuid" is introduced.
With "get_cpuid" it is possible to virtually call the guests
"cpuid"-opcode without changing the VM's context.[mtosatti: cleanup/beautify code]
Signed-off-by: Stephan Baerwolf
Signed-off-by: Marcelo Tosatti
Signed-off-by: Stefan Bader
Signed-off-by: Greg Kroah-Hartman -
commit 1a5a9906d4e8d1976b701f889d8f35d54b928f25 upstream.
In some cases it may happen that pmd_none_or_clear_bad() is called with
the mmap_sem hold in read mode. In those cases the huge page faults can
allocate hugepmds under pmd_none_or_clear_bad() and that can trigger a
false positive from pmd_bad() that will not like to see a pmd
materializing as trans huge.It's not khugepaged causing the problem, khugepaged holds the mmap_sem
in write mode (and all those sites must hold the mmap_sem in read mode
to prevent pagetables to go away from under them, during code review it
seems vm86 mode on 32bit kernels requires that too unless it's
restricted to 1 thread per process or UP builds). The race is only with
the huge pagefaults that can convert a pmd_none() into a
pmd_trans_huge().Effectively all these pmd_none_or_clear_bad() sites running with
mmap_sem in read mode are somewhat speculative with the page faults, and
the result is always undefined when they run simultaneously. This is
probably why it wasn't common to run into this. For example if the
madvise(MADV_DONTNEED) runs zap_page_range() shortly before the page
fault, the hugepage will not be zapped, if the page fault runs first it
will be zapped.Altering pmd_bad() not to error out if it finds hugepmds won't be enough
to fix this, because zap_pmd_range would then proceed to call
zap_pte_range (which would be incorrect if the pmd become a
pmd_trans_huge()).The simplest way to fix this is to read the pmd in the local stack
(regardless of what we read, no need of actual CPU barriers, only
compiler barrier needed), and be sure it is not changing under the code
that computes its value. Even if the real pmd is changing under the
value we hold on the stack, we don't care. If we actually end up in
zap_pte_range it means the pmd was not none already and it was not huge,
and it can't become huge from under us (khugepaged locking explained
above).All we need is to enforce that there is no way anymore that in a code
path like below, pmd_trans_huge can be false, but pmd_none_or_clear_bad
can run into a hugepmd. The overhead of a barrier() is just a compiler
tweak and should not be measurable (I only added it for THP builds). I
don't exclude different compiler versions may have prevented the race
too by caching the value of *pmd on the stack (that hasn't been
verified, but it wouldn't be impossible considering
pmd_none_or_clear_bad, pmd_bad, pmd_trans_huge, pmd_none are all inlines
and there's no external function called in between pmd_trans_huge and
pmd_none_or_clear_bad).if (pmd_trans_huge(*pmd)) {
if (next-addr != HPAGE_PMD_SIZE) {
VM_BUG_ON(!rwsem_is_locked(&tlb->mm->mmap_sem));
split_huge_page_pmd(vma->vm_mm, pmd);
} else if (zap_huge_pmd(tlb, vma, pmd, addr))
continue;
/* fall through */
}
if (pmd_none_or_clear_bad(pmd))Because this race condition could be exercised without special
privileges this was reported in CVE-2012-1179.The race was identified and fully explained by Ulrich who debugged it.
I'm quoting his accurate explanation below, for reference.====== start quote =======
mapcount 0 page_mapcount 1
kernel BUG at mm/huge_memory.c:1384!At some point prior to the panic, a "bad pmd ..." message similar to the
following is logged on the console:mm/memory.c:145: bad pmd ffff8800376e1f98(80000000314000e7).
The "bad pmd ..." message is logged by pmd_clear_bad() before it clears
the page's PMD table entry.143 void pmd_clear_bad(pmd_t *pmd)
144 {
-> 145 pmd_ERROR(*pmd);
146 pmd_clear(pmd);
147 }After the PMD table entry has been cleared, there is an inconsistency
between the actual number of PMD table entries that are mapping the page
and the page's map count (_mapcount field in struct page). When the page
is subsequently reclaimed, __split_huge_page() detects this inconsistency.1381 if (mapcount != page_mapcount(page))
1382 printk(KERN_ERR "mapcount %d page_mapcount %d\n",
1383 mapcount, page_mapcount(page));
-> 1384 BUG_ON(mapcount != page_mapcount(page));The root cause of the problem is a race of two threads in a multithreaded
process. Thread B incurs a page fault on a virtual address that has never
been accessed (PMD entry is zero) while Thread A is executing an madvise()
system call on a virtual address within the same 2 MB (huge page) range.virtual address space
.---------------------.
| |
| |
.-|---------------------|
| | |
| | |< |/////////////////////| > A(range)
page | |/////////////////////|-'
| | |
| | |
'-|---------------------|
| |
| |
'---------------------'- Thread A is executing an madvise(..., MADV_DONTNEED) system call
on the virtual address range "A(range)" shown in the picture.sys_madvise
// Acquire the semaphore in shared mode.
down_read(¤t->mm->mmap_sem)
...
madvise_vma
switch (behavior)
case MADV_DONTNEED:
madvise_dontneed
zap_page_range
unmap_vmas
unmap_page_range
zap_pud_range
zap_pmd_range
//
// Assume that this huge page has never been accessed.
// I.e. content of the PMD entry is zero (not mapped).
//
if (pmd_trans_huge(*pmd)) {
// We don't get here due to the above assumption.
}
//
// Assume that Thread B incurred a page fault and
.---------> // sneaks in here as shown below.
| //
| if (pmd_none_or_clear_bad(pmd))
| {
| if (unlikely(pmd_bad(*pmd)))
| pmd_clear_bad
| {
| pmd_ERROR
| // Log "bad pmd ..." message here.
| pmd_clear
| // Clear the page's PMD entry.
| // Thread B incremented the map count
| // in page_add_new_anon_rmap(), but
| // now the page is no longer mapped
| // by a PMD entry (-> inconsistency).
| }
| }
|
v
- Thread B is handling a page fault on virtual address "B(fault)" shown
in the picture....
do_page_fault
__do_page_fault
// Acquire the semaphore in shared mode.
down_read_trylock(&mm->mmap_sem)
...
handle_mm_fault
if (pmd_none(*pmd) && transparent_hugepage_enabled(vma))
// We get here due to the above assumption (PMD entry is zero).
do_huge_pmd_anonymous_page
alloc_hugepage_vma
// Allocate a new transparent huge page here.
...
__do_huge_pmd_anonymous_page
...
spin_lock(&mm->page_table_lock)
...
page_add_new_anon_rmap
// Here we increment the page's map count (starts at -1).
atomic_set(&page->_mapcount, 0)
set_pmd_at
// Here we set the page's PMD entry which will be cleared
// when Thread A calls pmd_clear_bad().
...
spin_unlock(&mm->page_table_lock)The mmap_sem does not prevent the race because both threads are acquiring
it in shared mode (down_read). Thread B holds the page_table_lock while
the page's map count and PMD table entry are updated. However, Thread A
does not synchronize on that lock.====== end quote =======
[akpm@linux-foundation.org: checkpatch fixes]
Reported-by: Ulrich Obergfell
Signed-off-by: Andrea Arcangeli
Acked-by: Johannes Weiner
Cc: Mel Gorman
Cc: Hugh Dickins
Cc: Dave Jones
Acked-by: Larry Woodman
Acked-by: Rik van Riel
Cc: Mark Salter
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
Signed-off-by: Greg Kroah-Hartman -
commit 73d63d038ee9f769f5e5b46792d227fe20e442c5 upstream.
With the recent changes to clear_IO_APIC_pin() which tries to
clear remoteIRR bit explicitly, some of the users started to see
"Unable to reset IRR for apic .." messages.Close look shows that these are related to bogus IO-APIC entries
which return's all 1's for their io-apic registers. And the
above mentioned error messages are benign. But kernel should
have ignored such io-apic's in the first place.Check if register 0, 1, 2 of the listed io-apic are all 1's and
ignore such io-apic.Reported-by: Álvaro Castillo
Tested-by: Jon Dufresne
Signed-off-by: Suresh Siddha
Cc: yinghai@kernel.org
Cc: kernel-team@fedoraproject.org
Cc: Josh Boyer
Link: http://lkml.kernel.org/r/1331577393.31585.94.camel@sbsiddha-desk.sc.intel.com
[ Performed minor cleanup of affected code. ]
Signed-off-by: Ingo Molnar
Signed-off-by: Greg Kroah-Hartman
24 Mar, 2012
1 commit
-
commit 78c5c68a4cf4329d17abfa469345ddf323d4fd62 upstream.
The code for "powersurge" SMP would kick in and cause a crash
at boot due to the lack of a NULL test.Signed-off-by: Benjamin Herrenschmidt
Signed-off-by: Jeremy Kerr
Reported-by: Adam Conrad
Tested-by: Adam Conrad
Signed-off-by: Greg Kroah-Hartman
20 Mar, 2012
3 commits
-
commit e0adb9902fb338a9fe634c3c2a3e474075c733ba upstream.
Newer version of binutils are more strict about specifying the
correct options to enable certain classes of instructions.The sparc32 build is done for v7 in order to support sun4c systems
which lack hardware integer multiply and divide instructions.So we have to pass -Av8 when building the assembler routines that
use these instructions and get patched into the kernel when we find
out that we have a v8 capable cpu.Reported-by: Paul Gortmaker
Signed-off-by: David S. Miller
Signed-off-by: Greg Kroah-Hartman -
commit 87e24f4b67e68d9fd8df16e0bf9c66d1ad2a2533 upstream.
Verified using the below proglet.. before:
[root@westmere ~]# perf stat -e node-stores -e node-store-misses ./numa 0
remote writePerformance counter stats for './numa 0':
2,101,554 node-stores
2,096,931 node-store-misses5.021546079 seconds time elapsed
[root@westmere ~]# perf stat -e node-stores -e node-store-misses ./numa 1
local writePerformance counter stats for './numa 1':
501,137 node-stores
199 node-store-misses5.124451068 seconds time elapsed
After:
[root@westmere ~]# perf stat -e node-stores -e node-store-misses ./numa 0
remote writePerformance counter stats for './numa 0':
2,107,516 node-stores
2,097,187 node-store-misses5.012755149 seconds time elapsed
[root@westmere ~]# perf stat -e node-stores -e node-store-misses ./numa 1
local writePerformance counter stats for './numa 1':
2,063,355 node-stores
165 node-store-misses5.082091494 seconds time elapsed
#define _GNU_SOURCE
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include#define SIZE (32*1024*1024)
volatile int done;
void sig_done(int sig)
{
done = 1;
}int main(int argc, char **argv)
{
cpu_set_t *mask, *mask2;
size_t size;
int i, err, t;
int nrcpus = 1024;
char *mem;
unsigned long nodemask = 0x01; /* node 0 */
DIR *node;
struct dirent *de;
int read = 0;
int local = 0;if (argc < 2) {
printf("usage: %s [0-3]\n", argv[0]);
printf(" bit0 - local/remote\n");
printf(" bit1 - read/write\n");
exit(0);
}switch (atoi(argv[1])) {
case 0:
printf("remote write\n");
break;
case 1:
printf("local write\n");
local = 1;
break;
case 2:
printf("remote read\n");
read = 1;
break;
case 3:
printf("local read\n");
local = 1;
read = 1;
break;
}mask = CPU_ALLOC(nrcpus);
size = CPU_ALLOC_SIZE(nrcpus);
CPU_ZERO_S(size, mask);node = opendir("/sys/devices/system/node/node0/");
if (!node)
perror("opendir");
while ((de = readdir(node))) {
int cpu;if (sscanf(de->d_name, "cpu%d", &cpu) == 1)
CPU_SET_S(cpu, size, mask);
}
closedir(node);mask2 = CPU_ALLOC(nrcpus);
CPU_ZERO_S(size, mask2);
for (i = 0; i < size; i++)
CPU_SET_S(i, size, mask2);
CPU_XOR_S(size, mask2, mask2, mask); // invertif (!local)
mask = mask2;err = sched_setaffinity(0, size, mask);
if (err)
perror("sched_setaffinity");mem = mmap(0, SIZE, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_ANONYMOUS, -1, 0);
err = mbind(mem, SIZE, MPOL_BIND, &nodemask, 8*sizeof(nodemask), MPOL_MF_MOVE);
if (err)
perror("mbind");signal(SIGALRM, sig_done);
alarm(5);if (!read) {
while (!done) {
for (i = 0; i < SIZE; i++)
mem[i] = 0x01;
}
} else {
while (!done) {
for (i = 0; i < SIZE; i++)
t += *(volatile char *)(mem + i);
}
}return 0;
}Signed-off-by: Peter Zijlstra
Cc: Stephane Eranian
Link: http://lkml.kernel.org/n/tip-tq73sxus35xmqpojf7ootxgs@git.kernel.org
Signed-off-by: Ingo Molnar
Signed-off-by: Greg Kroah-Hartman -
commit a7f4255f906f60f72e00aad2fb000939449ff32e upstream.
Commit f0fbf0abc093 ("x86: integrate delay functions") converted
delay_tsc() into a random delay generator for 64 bit. The reason is
that it merged the mostly identical versions of delay_32.c and
delay_64.c. Though the subtle difference of the result was:static void delay_tsc(unsigned long loops)
{
- unsigned bclock, now;
+ unsigned long bclock, now;Now the function uses rdtscl() which returns the lower 32bit of the
TSC. On 32bit that's not problematic as unsigned long is 32bit. On 64
bit this fails when the lower 32bit are close to wrap around when
bclock is read, because the following checkif ((now - bclock) >= loops)
break;evaluated to true on 64bit for e.g. bclock = 0xffffffff and now = 0
because the unsigned long (now - bclock) of these values results in
0xffffffff00000001 which is definitely larger than the loops
value. That explains Tvortkos observation:"Because I am seeing udelay(500) (_occasionally_) being short, and
that by delaying for some duration between 0us (yep) and 491us."Make those variables explicitely u32 again, so this works for both 32
and 64 bit.Reported-by: Tvrtko Ursulin
Signed-off-by: Thomas Gleixner
Signed-off-by: Linus Torvalds
Signed-off-by: Greg Kroah-Hartman
13 Mar, 2012
25 commits
-
commit 134d12fae0bb8f3d60dc7440a9e1950bb5427167 upstream.
For some weird (freudian?) reason, commit 435792d "ARM: OMAP: make
iommu subsys_initcall to fix builtin omap3isp" unintentionally changed
the mailbox's initcall instead of the iommu's.Fix that.
Reported-by: Fernando Guzman Lugo
Signed-off-by: Ohad Ben-Cohen
Cc: Laurent Pinchart
Cc: Joerg Roedel
Cc: Tony Lindgren
Signed-off-by: Joerg Roedel
Signed-off-by: Greg Kroah-Hartman -
commit 3f31ae121348afd9ed39700ea2a63c17cd7eeed1 upstream.
xscale2 PMUs indicate overflow not via the PMU control register, but by
a separate overflow FLAG register instead.This patch fixes the xscale2 PMU code to use this register to detect
to overflow and ensures that we clear any pending overflow when
disabling a counter.Signed-off-by: Will Deacon
Signed-off-by: Russell King
Signed-off-by: Greg Kroah-Hartman -
commit f6f5a30c834135c9f2fa10400c59ebbdd9188567 upstream.
The PMU IRQ handlers in perf assume that if a counter has overflowed
then perf must be responsible. In the paranoid world of crazy hardware,
this could be false, so check that we do have a valid event before
attempting to dereference NULL in the interrupt path.Signed-off-by: Ming Lei
Signed-off-by: Will Deacon
Signed-off-by: Russell King
Signed-off-by: Greg Kroah-Hartman -
commit 99c1745b9c76910e195889044f914b4898b7c9a5 upstream.
When disabling a counter on an ARMv7 PMU, we should also clear the
overflow flag in case an overflow occurred whilst stopping the counter.
This prevents a spurious overflow being picked up later and leading to
either false accounting or a NULL dereference.Reported-by: Ming Lei
Signed-off-by: Will Deacon
Signed-off-by: Russell King
Signed-off-by: Greg Kroah-Hartman -
commit 5727347180ebc6b4a866fcbe00dcb39cc03acb37 upstream.
On ARM, the PMU does not stop counting after an overflow and therefore
IRQ latency affects the new counter value read by the kernel. This is
significant for non-sampling runs where it is possible for the new value
to overtake the previous one, causing the delta to be out by up to
max_period events.Commit a737823d ("ARM: 6835/1: perf: ensure overflows aren't missed due
to IRQ latency") attempted to fix this problem by allowing interrupt
handlers to pass an overflow flag to the event update function, causing
the overflow calculation to assume that the counter passed through zero
when going from prev to new. Unfortunately, this doesn't work when
overflow occurs on the perf_task_tick path because we have the flag
cleared and end up computing a large negative delta.This patch removes the overflow flag from armpmu_event_update and
instead limits the sample_period to half of the max_period for
non-sampling profiling runs.Signed-off-by: Ming Lei
Signed-off-by: Will Deacon
Signed-off-by: Russell King
Signed-off-by: Greg Kroah-Hartman -
commit efbc74ace95338484f8d732037b99c7c77098fce upstream.
Erratum #743622 affects all r2 variants of the Cortex-A9 processor, so
ensure that the workaround is applied regardless of the revision.Reported-by: Russell King
Signed-off-by: Will Deacon
Signed-off-by: Russell King
Signed-off-by: Greg Kroah-Hartman -
commit c49d005b6cc8491fad5b24f82805be2d6bcbd3dd upstream.
A hardware bug in the OMAP4 HDMI PHY causes physical damage to the board
if the HDMI PHY is kept powered on when the cable is not connected.This patch solves the problem by adding hot-plug-detection into the HDMI
IP driver. This is not a real HPD support in the sense that nobody else
than the IP driver gets to know about the HPD events, but is only meant
to fix the HW bug.The strategy is simple: If the display device is turned off by the user,
the PHY power is set to OFF. When the display device is turned on by the
user, the PHY power is set either to LDOON or TXON, depending on whether
the HDMI cable is connected.The reason to avoid PHY OFF when the display device is on, but the cable
is disconnected, is that when the PHY is turned OFF, the HDMI IP is not
"ticking" and thus the DISPC does not receive pixel clock from the HDMI
IP. This would, for example, prevent any VSYNCs from happening, and
would thus affect the users of omapdss. By using LDOON when the cable is
disconnected we'll avoid the HW bug, but keep the HDMI working as usual
from the user's point of view.Signed-off-by: Tomi Valkeinen
Signed-off-by: Greg Kroah-Hartman -
commit aa74274b464d4aa24703963ac89a0ee942d5d267 upstream.
Both Panda and 4430SDP use GPIO 63 as HDMI hot-plug-detect. Configure
this GPIO in the board files.Signed-off-by: Tomi Valkeinen
Acked-by: Tony Lindgren
Signed-off-by: Greg Kroah-Hartman -
commit 78a1ad8f12db70b8b0a4548b90704de08ee216ce upstream.
The HDMI GPIO pins LS_OE and CT_CP_HPD are not currently configured.
This patch configures them as output pins.Signed-off-by: Tomi Valkeinen
Acked-by: Tony Lindgren
Signed-off-by: Greg Kroah-Hartman -
commit 7bb122d155f742fe2d79849090c825be7b4a247e upstream.
"hdmi_hpd" pin is muxed to INPUT and PULLUP, but the pin is not
currently used, and in the future when it is used, the pin is used as a
GPIO and is board specific, not an OMAP4 wide thing.So remove the muxing for now.
Signed-off-by: Tomi Valkeinen
Acked-by: Tony Lindgren
Signed-off-by: Greg Kroah-Hartman -
commit 3932a32fcf5393f8be70ac99dc718ad7ad0a415b upstream.
The GPIO 60 on 4430sdp and Panda is not HPD GPIO, as currently marked in
the board files, but CT_CP_HPD, which is used to enable/disable HPD
functionality.This patch renames the GPIO.
Signed-off-by: Tomi Valkeinen
Acked-by: Tony Lindgren
Signed-off-by: Greg Kroah-Hartman -
commit 575753e3bea3b67eef8e454fb87f719e3f7da599 upstream.
Instead of freeing the GPIOs individually, use gpio_free_array().
Signed-off-by: Tomi Valkeinen
Acked-by: Tony Lindgren
Signed-off-by: Greg Kroah-Hartman -
commit b06540371063f0f07aafc1d1ac5e974da85c973c upstream.
Patchset "ARM: orion: Refactor the MPP code common in the orion
platform" broke at least Orion5x based platforms. These platforms have
pins configured as GPIO when the selector is not 0x0. However the
common code assumes the selector is always 0x0 for a GPIO lines. It
then ignores the GPIO bits in the MPP definitions, resulting in that
Orion5x machines cannot correctly configure there GPIO lines.The Fix removes the assumption that the selector is always 0x0.
In order that none GPIO configurations are correctly blocked,
Kirkwood and mv78xx0 MPP definitions are corrected to only set the
GPIO bits for GPIO configurations.This third version, which does not contain any whitespace changes,
and is rebased on v3.3-rc2.Signed-off-by: Andrew Lunn
Acked-by: Nicolas Pitre
Signed-off-by: Olof Johansson -
commit 72053353583230952c4b187e110e9da00dfc3afb upstream.
The patch "ARM: orion: Consolidate USB platform setup code.", commit
4fcd3f374a928081d391cd9a570afe3b2c692fdc broke USB on TS-7800 and
other orion5x boards, because the wrong type of PHY was being passed
to the EHCI driver in the platform data. Orion5x needs EHCI_PHY_ORION
and all the others want EHCI_PHY_NA.Allow the mach- code to tell the generic plat-orion code which USB PHY
enum to place into the platform data.Version 2: Rebase to v3.3-rc2.
Reported-by: Ambroz Bizjak
Signed-off-by: Andrew Lunn
Tested-by: Ambroz Bizjak
Acked-by: Nicolas Pitre
Signed-off-by: Olof Johansson
Signed-off-by: Greg Kroah-Hartman -
commit 31e0017e6f6fb5cfdfaf932c1f98c9bef8d57688 upstream.
Enable use of the generic atomic64 implementation on AVR32 platforms.
Without this the kernel fails to build as the architecture does not
provide its version.Signed-off-by: Fabio Baltieri
Acked-by: Hans-Christian Egtvedt
Cc: Haavard Skinnemoen
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
Cc: Jean-Christophe PLAGNIOL-VILLARD
Signed-off-by: Greg Kroah-Hartman -
commit 62aca403657fe30e5235c5331e9871e676d9ea0a upstream.
Michael Cree said:
: : I have noticed some user space problems (pulseaudio crashes in pthread
: : code, glibc/nptl test suite failures, java compiler freezes on SMP alpha
: : systems) that arise when using a 2.6.39 or later kernel on Alpha.
: : Bisecting between 2.6.38 and 2.6.39 (using glibc/nptl test suite as
: : criterion for good/bad kernel) eventually leads to:
: :
: : 8d7718aa082aaf30a0b4989e1f04858952f941bc is the first bad commit
: : commit 8d7718aa082aaf30a0b4989e1f04858952f941bc
: : Author: Michel Lespinasse
: : Date: Thu Mar 10 18:50:58 2011 -0800
: :
: : futex: Sanitize futex ops argument types
: :
: : Change futex_atomic_op_inuser and futex_atomic_cmpxchg_inatomic
: : prototypes to use u32 types for the futex as this is the data type the
: : futex core code uses all over the place.
: :
: : Looking at the commit I see there is a change of the uaddr argument in
: : the Alpha architecture specific code for futexes from int to u32, but I
: : don't see why this should cause a problem.Richard Henderson said:
: futex_atomic_cmpxchg_inatomic(u32 *uval, u32 __user *uaddr,
: u32 oldval, u32 newval)
: ...
: : "r"(uaddr), "r"((long)oldval), "r"(newval)
:
:
: There is no 32-bit compare instruction. These are implemented by
: consistently extending the values to a 64-bit type. Since the
: load instruction sign-extends, we want to sign-extend the other
: quantity as well (despite the fact it's logically unsigned).
:
: So:
:
: - : "r"(uaddr), "r"((long)oldval), "r"(newval)
: + : "r"(uaddr), "r"((long)(int)oldval), "r"(newval)
:
: should do the trick.Michael said:
: This fixes the glibc test suite failures and the pulseaudio related
: crashes, but it does not fix the java compiiler lockups that I was (and
: are still) observing. That is some other problem.Reported-by: Michael Cree
Tested-by: Michael Cree
Acked-by: Phil Carmody
Cc: Richard Henderson
Cc: Michel Lespinasse
Cc: Ivan Kokshaysky
Reviewed-by: Matt Turner
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
Signed-off-by: Greg Kroah-Hartman -
commit e39d40c65dfd8390b50c03482ae9e289b8a8f351 upstream.
s3c2410_dma_suspend suspends channels from 0 to dma_channels.
s3c2410_dma_resume resumes channels in reverse order. So
pointer should be decremented instead of being incremented.Signed-off-by: Gusakov Andrey
Reviewed-by: Heiko Stuebner
Signed-off-by: Kukjin Kim
Signed-off-by: Greg Kroah-Hartman -
commit 1018faa6cf23b256bf25919ef203cd7c129f06f2 upstream.
It turned out that a performance counter on AMD does not
count at all when the GO or HO bit is set in the control
register and SVM is disabled in EFER.This patch works around this issue by masking out the HO bit
in the performance counter control register when SVM is not
enabled.The GO bit is not touched because it is only set when the
user wants to count in guest-mode only. So when SVM is
disabled the counter should not run at all and the
not-counting is the intended behaviour.Signed-off-by: Joerg Roedel
Signed-off-by: Peter Zijlstra
Cc: Avi Kivity
Cc: Stephane Eranian
Cc: David Ahern
Cc: Gleb Natapov
Cc: Robert Richter
Link: http://lkml.kernel.org/r/1330523852-19566-1-git-send-email-joerg.roedel@amd.com
Signed-off-by: Ingo Molnar
Signed-off-by: Greg Kroah-Hartman -
commit 1d057720609ed052a6371fe1d53300e5e6328e94 upstream.
Enable the compat keyctl wrapper on s390x so that 32-bit s390 userspace can
call the keyctl() syscall.There's an s390x assembly wrapper that truncates all the register values to
32-bits and this then calls compat_sys_keyctl() - but the latter only exists if
CONFIG_KEYS_COMPAT is enabled, and the s390 Kconfig doesn't enable it.Without this patch, 32-bit calls to the keyctl() syscall are given an ENOSYS
error:[root@devel4 ~]# keyctl show
Session Keyring
-3: key inaccessible (Function not implemented)Signed-off-by: David Howells
Acked-by: dan@danny.cz
Cc: Carsten Otte
Reviewed-by: Christian Borntraeger
Cc: linux-s390@vger.kernel.org
Signed-off-by: Heiko Carstens
Signed-off-by: Martin Schwidefsky
Signed-off-by: Greg Kroah-Hartman -
commit f6737055c1c432a9628a9a731f9881ad8e0a9eee upstream.
The GPI_28 IRQ was not registered properly. The registration of
IRQ_LPC32XX_GPI_28 was added and the (wrong) IRQ_LPC32XX_GPI_11 at
LPC32XX_SIC1_IRQ(4) was replaced by IRQ_LPC32XX_GPI_28 (see manual of
LPC32xx / interrupt controller).Signed-off-by: Roland Stigge
Signed-off-by: Greg Kroah-Hartman -
commit 35dd0a75d4a382e7f769dd0277732e7aa5235718 upstream.
This patch fixes the initialization of the interrupt controller of the LPC32xx
by correctly setting up SIC1 and SIC2 instead of (wrongly) using the same value
as for the Main Interrupt Controller (MIC).Signed-off-by: Roland Stigge
Signed-off-by: Greg Kroah-Hartman -
commit 94ed7830cba4dce57b18a2926b5d826bfd184bd6 upstream.
This patch fixes the wakeup disable function by clearing latched events.
Signed-off-by: Roland Stigge
Signed-off-by: Greg Kroah-Hartman -
commit ff424aa4c89d19082e8ae5a3351006bc8a4cd91b upstream.
This patch fixes a wrong loop limit on UART init.
Signed-off-by: Roland Stigge
Signed-off-by: Greg Kroah-Hartman -
commit 2707208ee8a80dbbd5426f5aa1a934f766825bb5 upstream.
This patch fixes a HW bug by flushing RX FIFOs of the UARTs on init. It was
ported from NXP's git.lpclinux.com tree.Signed-off-by: Roland Stigge
Signed-off-by: Greg Kroah-Hartman -
commit 048cd4e51d24ebf7f3552226d03c769d6ad91658 upstream.
The new is_compat_task() define for the !COMPAT case in
include/linux/compat.h conflicts with a similar define in
arch/s390/include/asm/compat.h.This is the minimal patch which fixes the build issues.
Signed-off-by: Heiko Carstens
Signed-off-by: Linus Torvalds
Cc: Jonathan Nieder
Signed-off-by: Greg Kroah-Hartman
