[PATCH] [0/50] 2.6.35.14 longterm review

[PATCH] [0/50] 2.6.35.14 longterm review

[Andi Kleen]

This is the start of the longterm review cycle for the 2.6.35.14 release.
There are a large number of patches in this series, which will be posted as a 
response to this one.  If anyone has any issues with these being applied, 
please let me know.  If anyone is a maintainer of the proper subsystem, and
wants to add a Signed-off-by: line to the patch, please respond with it.

I'm posting the patches in 100 patch chunks to not overload the mailing
list. The next chunk will come tomorrow.

The full quilt queue can be found at
git://git.kernel.org/pub/scm/linux/kernel/git/longterm/longterm-queue-2.6.35

Responses should be made within 48 hours.

-Andi

[PATCH] [1/50] x86: Make Dell Latitude E6420 use reboot=pci

[Andi Kleen]

2.6.35-longterm review patch.  If anyone has any objections, please let me know.

------------------
From: H. Peter Anvin <hpa@zytor.com>

[ upstream commit a536877e77f73ea22d12d94a019fedd9671b6acd ]

Yet another variant of the Dell Latitude series which requires
reboot=pci.

>From the E5420 bug report by Daniel J Blueman:

> The E6420 is affected also (same platform, different casing and
> features), which provides an external confirmation of the issue; I can
> submit a patch for that later or include it if you prefer:
> http://linux.koolsolutions.com/2009/08/04/howto-fix-linux-hangfreeze-during-reboots-and-restarts/

Reported-by: Daniel J Blueman <daniel.blueman@gmail.com>
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
Cc: <stable@kernel.org>
Signed-off-by: Andi Kleen <ak@linux.intel.com>

Index: linux-2.6.35.y/arch/x86/kernel/reboot.c
===================================================================
--- linux-2.6.35.y.orig/arch/x86/kernel/reboot.c
+++ linux-2.6.35.y/arch/x86/kernel/reboot.c
@@ -485,6 +485,14 @@ static struct dmi_system_id __initdata p
 			DMI_MATCH(DMI_PRODUCT_NAME, "Latitude E5420"),
 		},
 	},
+	{	/* Handle problems with rebooting on the Latitude E6420. */
+		.callback = set_pci_reboot,
+		.ident = "Dell Latitude E6420",
+		.matches = {
+			DMI_MATCH(DMI_SYS_VENDOR, "Dell Inc."),
+			DMI_MATCH(DMI_PRODUCT_NAME, "Latitude E6420"),
+		},
+	},
 	{ }
 };
 

[PATCH] [2/50] mm/futex: fix futex writes on archs with SW tracking of

[Andi Kleen]

2.6.35-longterm review patch.  If anyone has any objections, please let me know.

------------------
From: Benjamin Herrenschmidt <benh@kernel.crashing.org>

[ upstream commit 2efaca927f5cd7ecd0f1554b8f9b6a9a2c329c03 ]
 dirty & young

I haven't reproduced it myself but the fail scenario is that on such
machines (notably ARM and some embedded powerpc), if you manage to hit
that futex path on a writable page whose dirty bit has gone from the PTE,
you'll livelock inside the kernel from what I can tell.

It will go in a loop of trying the atomic access, failing, trying gup to
"fix it up", getting succcess from gup, go back to the atomic access,
failing again because dirty wasn't fixed etc...

So I think you essentially hang in the kernel.

The scenario is probably rare'ish because affected architecture are
embedded and tend to not swap much (if at all) so we probably rarely hit
the case where dirty is missing or young is missing, but I think Shan has
a piece of SW that can reliably reproduce it using a shared writable
mapping & fork or something like that.

On archs who use SW tracking of dirty & young, a page without dirty is
effectively mapped read-only and a page without young unaccessible in the
PTE.

Additionally, some architectures might lazily flush the TLB when relaxing
write protection (by doing only a local flush), and expect a fault to
invalidate the stale entry if it's still present on another processor.

The futex code assumes that if the "in_atomic()" access -EFAULT's, it can
"fix it up" by causing get_user_pages() which would then be equivalent to
taking the fault.

However that isn't the case.  get_user_pages() will not call
handle_mm_fault() in the case where the PTE seems to have the right
permissions, regardless of the dirty and young state.  It will eventually
update those bits ...  in the struct page, but not in the PTE.

Additionally, it will not handle the lazy TLB flushing that can be
required by some architectures in the fault case.

Basically, gup is the wrong interface for the job.  The patch provides a
more appropriate one which boils down to just calling handle_mm_fault()
since what we are trying to do is simulate a real page fault.

The futex code currently attempts to write to user memory within a
pagefault disabled section, and if that fails, tries to fix it up using
get_user_pages().

This doesn't work on archs where the dirty and young bits are maintained
by software, since they will gate access permission in the TLB, and will
not be updated by gup().

In addition, there's an expectation on some archs that a spurious write
fault triggers a local TLB flush, and that is missing from the picture as
well.

I decided that adding those "features" to gup() would be too much for this
already too complex function, and instead added a new simpler
fixup_user_fault() which is essentially a wrapper around handle_mm_fault()
which the futex code can call.

[akpm@linux-foundation.org: coding-style fixes]
[akpm@linux-foundation.org: fix some nits Darren saw, fiddle comment layout]
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Reported-by: Shan Hai <haishan.bai@gmail.com>
Tested-by: Shan Hai <haishan.bai@gmail.com>
Cc: David Laight <David.Laight@ACULAB.COM>
Acked-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Darren Hart <darren.hart@intel.com>
Cc: <stable@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Andi Kleen <ak@linux.intel.com>

Index: linux-2.6.35.y/include/linux/mm.h
===================================================================
--- linux-2.6.35.y.orig/include/linux/mm.h
+++ linux-2.6.35.y/include/linux/mm.h
@@ -850,6 +850,8 @@ int get_user_pages(struct task_struct *t
 int get_user_pages_fast(unsigned long start, int nr_pages, int write,
 			struct page **pages);
 struct page *get_dump_page(unsigned long addr);
+extern int fixup_user_fault(struct task_struct *tsk, struct mm_struct *mm,
+			    unsigned long address, unsigned int fault_flags);
 
 extern int try_to_release_page(struct page * page, gfp_t gfp_mask);
 extern void do_invalidatepage(struct page *page, unsigned long offset);
Index: linux-2.6.35.y/kernel/futex.c
===================================================================
--- linux-2.6.35.y.orig/kernel/futex.c
+++ linux-2.6.35.y/kernel/futex.c
@@ -306,8 +306,8 @@ static int fault_in_user_writeable(u32 _
 	int ret;
 
 	down_read(&mm->mmap_sem);
-	ret = get_user_pages(current, mm, (unsigned long)uaddr,
-			     1, 1, 0, NULL, NULL);
+	ret = fixup_user_fault(current, mm, (unsigned long)uaddr,
+			       FAULT_FLAG_WRITE);
 	up_read(&mm->mmap_sem);
 
 	return ret < 0 ? ret : 0;
Index: linux-2.6.35.y/mm/memory.c
===================================================================
--- linux-2.6.35.y.orig/mm/memory.c
+++ linux-2.6.35.y/mm/memory.c
@@ -1497,7 +1497,63 @@ int __get_user_pages(struct task_struct 
 	return i;
 }
 
-/**
+/*
+ * fixup_user_fault() - manually resolve a user page fault
+ * @tsk:	the task_struct to use for page fault accounting, or
+ *		NULL if faults are not to be recorded.
+ * @mm:		mm_struct of target mm
+ * @address:	user address
+ * @fault_flags:flags to pass down to handle_mm_fault()
+ *
+ * This is meant to be called in the specific scenario where for locking reasons
+ * we try to access user memory in atomic context (within a pagefault_disable()
+ * section), this returns -EFAULT, and we want to resolve the user fault before
+ * trying again.
+ *
+ * Typically this is meant to be used by the futex code.
+ *
+ * The main difference with get_user_pages() is that this function will
+ * unconditionally call handle_mm_fault() which will in turn perform all the
+ * necessary SW fixup of the dirty and young bits in the PTE, while
+ * handle_mm_fault() only guarantees to update these in the struct page.
+ *
+ * This is important for some architectures where those bits also gate the
+ * access permission to the page because they are maintained in software.  On
+ * such architectures, gup() will not be enough to make a subsequent access
+ * succeed.
+ *
+ * This should be called with the mm_sem held for read.
+ */
+int fixup_user_fault(struct task_struct *tsk, struct mm_struct *mm,
+		     unsigned long address, unsigned int fault_flags)
+{
+	struct vm_area_struct *vma;
+	int ret;
+
+	vma = find_extend_vma(mm, address);
+	if (!vma || address < vma->vm_start)
+		return -EFAULT;
+
+	ret = handle_mm_fault(mm, vma, address, fault_flags);
+	if (ret & VM_FAULT_ERROR) {
+		if (ret & VM_FAULT_OOM)
+			return -ENOMEM;
+		if (ret & VM_FAULT_HWPOISON)
+			return -EFAULT;
+		if (ret & VM_FAULT_SIGBUS)
+			return -EFAULT;
+		BUG();
+	}
+	if (tsk) {
+		if (ret & VM_FAULT_MAJOR)
+			tsk->maj_flt++;
+		else
+			tsk->min_flt++;
+	}
+	return 0;
+}
+
+/*
  * get_user_pages() - pin user pages in memory
  * @tsk:	task_struct of target task
  * @mm:		mm_struct of target mm

[PATCH] [3/50] mm/backing-dev.c: reset bdi min_ratio in bdi_unregister()

[Andi Kleen]

2.6.35-longterm review patch.  If anyone has any objections, please let me know.

------------------
From: Peter Zijlstra <peterz@infradead.org>

[ upstream commit ccb6108f5b0b541d3eb332c3a73e645c0f84278e ]

Vito said:

: The system has many usb disks coming and going day to day, with their
: respective bdi's having min_ratio set to 1 when inserted.  It works for
: some time until eventually min_ratio can no longer be set, even when the
: active set of bdi's seen in /sys/class/bdi/*/min_ratio doesn't add up to
: anywhere near 100.
:
: This then leads to an unrelated starvation problem caused by write-heavy
: fuse mounts being used atop the usb disks, a problem the min_ratio setting
: at the underlying devices bdi effectively prevents.

Fix this leakage by resetting the bdi min_ratio when unregistering the
BDI.

Signed-off-by: Peter Zijlstra <peterz@infradead.org>
Reported-by: Vito Caputo <lkml@pengaru.com>
Cc: Wu Fengguang <fengguang.wu@intel.com>
Cc: Miklos Szeredi <miklos@szeredi.hu>
Cc: <stable@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Andi Kleen <ak@linux.intel.com>

Index: linux-2.6.35.y/mm/backing-dev.c
===================================================================
--- linux-2.6.35.y.orig/mm/backing-dev.c
+++ linux-2.6.35.y/mm/backing-dev.c
@@ -646,6 +646,7 @@ static void bdi_prune_sb(struct backing_
 void bdi_unregister(struct backing_dev_info *bdi)
 {
 	if (bdi->dev) {
+		bdi_set_min_ratio(bdi, 0);
 		bdi_prune_sb(bdi);
 
 		if (!bdi_cap_flush_forker(bdi))

[PATCH] [4/50] xtensa: prevent arbitrary read in ptrace

[Andi Kleen]

2.6.35-longterm review patch.  If anyone has any objections, please let me know.

------------------
From: Dan Rosenberg <drosenberg@vsecurity.com>

[ upstream commit 0d0138ebe24b94065580bd2601f8bb7eb6152f56 ]

Prevent an arbitrary kernel read.  Check the user pointer with access_ok()
before copying data in.

[akpm@linux-foundation.org: s/EIO/EFAULT/]
Signed-off-by: Dan Rosenberg <drosenberg@vsecurity.com>
Cc: Christian Zankel <chris@zankel.net>
Cc: Oleg Nesterov <oleg@redhat.com>
Cc: <stable@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Andi Kleen <ak@linux.intel.com>

Index: linux-2.6.35.y/arch/xtensa/kernel/ptrace.c
===================================================================
--- linux-2.6.35.y.orig/arch/xtensa/kernel/ptrace.c
+++ linux-2.6.35.y/arch/xtensa/kernel/ptrace.c
@@ -147,6 +147,9 @@ int ptrace_setxregs(struct task_struct *
 	elf_xtregs_t *xtregs = uregs;
 	int ret = 0;
 
+	if (!access_ok(VERIFY_READ, uregs, sizeof(elf_xtregs_t)))
+		return -EFAULT;
+
 #if XTENSA_HAVE_COPROCESSORS
 	/* Flush all coprocessors before we overwrite them. */
 	coprocessor_flush_all(ti);

[PATCH] [5/50] ipc/sem.c: fix race with concurrent semtimedop() timeouts

[Andi Kleen]

2.6.35-longterm review patch.  If anyone has any objections, please let me know.

------------------
From: Manfred Spraul <manfred@colorfullife.com>

[ upstream commit d694ad62bf539dbb20a0899ac2a954555f9e4a83 ]
 and IPC_RMID

If a semaphore array is removed and in parallel a sleeping task is woken
up (signal or timeout, does not matter), then the woken up task does not
wait until wake_up_sem_queue_do() is completed.  This will cause crashes,
because wake_up_sem_queue_do() will read from a stale pointer.

The fix is simple: Regardless of anything, always call get_queue_result().
This function waits until wake_up_sem_queue_do() has finished it's task.

Addresses https://bugzilla.kernel.org/show_bug.cgi?id=27142

Reported-by: Yuriy Yevtukhov <yuriy@ucoz.com>
Reported-by: Harald Laabs <kernel@dasr.de>
Signed-off-by: Manfred Spraul <manfred@colorfullife.com>
Acked-by: Eric Dumazet <eric.dumazet@gmail.com>
Cc: <stable@kernel.org>		[2.6.35+]
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Andi Kleen <ak@linux.intel.com>

Index: linux-2.6.35.y/ipc/sem.c
===================================================================
--- linux-2.6.35.y.orig/ipc/sem.c
+++ linux-2.6.35.y/ipc/sem.c
@@ -1452,15 +1452,24 @@ SYSCALL_DEFINE4(semtimedop, int, semid, 
 	}
 
 	sma = sem_lock(ns, semid);
+
+	/*
+	 * Wait until it's guaranteed that no wakeup_sem_queue_do() is ongoing.
+	 */
+	error = get_queue_result(&queue);
+
+	/*
+	 * Array removed? If yes, leave without sem_unlock().
+	 */
 	if (IS_ERR(sma)) {
 		error = -EIDRM;
 		goto out_free;
 	}
 
-	error = get_queue_result(&queue);
 
 	/*
-	 * If queue.status != -EINTR we are woken up by another process
+	 * If queue.status != -EINTR we are woken up by another process.
+	 * Leave without unlink_queue(), but with sem_unlock().
 	 */
 
 	if (error != -EINTR) {

[PATCH] [6/50] jme: Fix unmap error (Causing system freeze)

[Andi Kleen]

2.6.35-longterm review patch.  If anyone has any objections, please let me know.

------------------
From: Guo-Fu Tseng <cooldavid@cooldavid.org>

[ upstream commit 94c5b41b327e08de0ddf563237855f55080652a1 ]

This patch add the missing dma_unmap().
Which solved the critical issue of system freeze on heavy load.

Michal Miroslaw's rejected patch:
[PATCH v2 10/46] net: jme: convert to generic DMA API
Pointed out the issue also, thank you Michal.
But the fix was incorrect. It would unmap needed address
when low memory.

Got lots of feedback from End user and Gentoo Bugzilla.
https://bugs.gentoo.org/show_bug.cgi?id=373109
Thank you all. :)

Cc: stable@kernel.org
Signed-off-by: Guo-Fu Tseng <cooldavid@cooldavid.org>
Acked-by: Chris Wright <chrisw@sous-sol.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Andi Kleen <ak@linux.intel.com>

Index: linux-2.6.35.y/drivers/net/jme.c
===================================================================
--- linux-2.6.35.y.orig/drivers/net/jme.c
+++ linux-2.6.35.y/drivers/net/jme.c
@@ -678,20 +678,28 @@ jme_make_new_rx_buf(struct jme_adapter *
 	struct jme_ring *rxring = &(jme->rxring[0]);
 	struct jme_buffer_info *rxbi = rxring->bufinf + i;
 	struct sk_buff *skb;
+	dma_addr_t mapping;
 
 	skb = netdev_alloc_skb(jme->dev,
 		jme->dev->mtu + RX_EXTRA_LEN);
 	if (unlikely(!skb))
 		return -ENOMEM;
 
+	mapping = pci_map_page(jme->pdev, virt_to_page(skb->data),
+			       offset_in_page(skb->data), skb_tailroom(skb),
+			       PCI_DMA_FROMDEVICE);
+	if (unlikely(pci_dma_mapping_error(jme->pdev, mapping))) {
+		dev_kfree_skb(skb);
+		return -ENOMEM;
+	}
+
+	if (likely(rxbi->mapping))
+		pci_unmap_page(jme->pdev, rxbi->mapping,
+			       rxbi->len, PCI_DMA_FROMDEVICE);
+
 	rxbi->skb = skb;
 	rxbi->len = skb_tailroom(skb);
-	rxbi->mapping = pci_map_page(jme->pdev,
-					virt_to_page(skb->data),
-					offset_in_page(skb->data),
-					rxbi->len,
-					PCI_DMA_FROMDEVICE);
-
+	rxbi->mapping = mapping;
 	return 0;
 }
 

[PATCH] [7/50] fix crash in scsi_dispatch_cmd()

[Andi Kleen]

2.6.35-longterm review patch.  If anyone has any objections, please let me know.

------------------
From: James Bottomley <James.Bottomley@HansenPartnership.com>

[ upstream commit bfe159a51203c15d23cb3158fffdc25ec4b4dda1 ]

USB surprise removal of sr is triggering an oops in
scsi_dispatch_command().  What seems to be happening is that USB is
hanging on to a queue reference until the last close of the upper
device, so the crash is caused by surprise remove of a mounted CD
followed by attempted unmount.

The problem is that USB doesn't issue its final commands as part of
the SCSI teardown path, but on last close when the block queue is long
gone.  The long term fix is probably to make sr do the teardown in the
same way as sd (so remove all the lower bits on ejection, but keep the
upper disk alive until last close of user space).  However, the
current oops can be simply fixed by not allowing any commands to be
sent to a dead queue.

Cc: stable@kernel.org
Signed-off-by: James Bottomley <JBottomley@Parallels.com>
Signed-off-by: Andi Kleen <ak@linux.intel.com>

Index: linux-2.6.35.y/block/blk-core.c
===================================================================
--- linux-2.6.35.y.orig/block/blk-core.c
+++ linux-2.6.35.y/block/blk-core.c
@@ -893,6 +893,9 @@ struct request *blk_get_request(struct r
 {
 	struct request *rq;
 
+	if (unlikely(test_bit(QUEUE_FLAG_DEAD, &q->queue_flags)))
+		return NULL;
+
 	BUG_ON(rw != READ && rw != WRITE);
 
 	spin_lock_irq(q->queue_lock);
Index: linux-2.6.35.y/block/blk-exec.c
===================================================================
--- linux-2.6.35.y.orig/block/blk-exec.c
+++ linux-2.6.35.y/block/blk-exec.c
@@ -50,6 +50,13 @@ void blk_execute_rq_nowait(struct reques
 {
 	int where = at_head ? ELEVATOR_INSERT_FRONT : ELEVATOR_INSERT_BACK;
 
+	if (unlikely(test_bit(QUEUE_FLAG_DEAD, &q->queue_flags))) {
+		rq->errors = -ENXIO;
+		if (rq->end_io)
+			rq->end_io(rq, rq->errors);
+		return;
+	}
+
 	rq->rq_disk = bd_disk;
 	rq->end_io = done;
 	WARN_ON(irqs_disabled());
Index: linux-2.6.35.y/drivers/scsi/scsi_lib.c
===================================================================
--- linux-2.6.35.y.orig/drivers/scsi/scsi_lib.c
+++ linux-2.6.35.y/drivers/scsi/scsi_lib.c
@@ -215,6 +215,8 @@ int scsi_execute(struct scsi_device *sde
 	int ret = DRIVER_ERROR << 24;
 
 	req = blk_get_request(sdev->request_queue, write, __GFP_WAIT);
+	if (!req)
+		return ret;
 
 	if (bufflen &&	blk_rq_map_kern(sdev->request_queue, req,
 					buffer, bufflen, __GFP_WAIT))

[PATCH] [8/50] mmc: Add PCI fixup quirks for Ricoh 1180:e823 reader

[Andi Kleen]

2.6.35-longterm review patch.  If anyone has any objections, please let me know.

------------------
From: Manoj Iyer <manoj.iyer@canonical.com>

[ upstream commit be98ca652faa6468916a9b7608befff215a8ca70 ]

Signed-off-by: Manoj Iyer <manoj.iyer@canonical.com>
Cc: <stable@kernel.org>
Signed-off-by: Chris Ball <cjb@laptop.org>
Signed-off-by: Andi Kleen <ak@linux.intel.com>

Index: linux-2.6.35.y/drivers/pci/quirks.c
===================================================================
--- linux-2.6.35.y.orig/drivers/pci/quirks.c
+++ linux-2.6.35.y/drivers/pci/quirks.c
@@ -2701,6 +2701,8 @@ static void ricoh_mmc_fixup_r5c832(struc
 }
 DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_RICOH, PCI_DEVICE_ID_RICOH_R5C832, ricoh_mmc_fixup_r5c832);
 DECLARE_PCI_FIXUP_RESUME_EARLY(PCI_VENDOR_ID_RICOH, PCI_DEVICE_ID_RICOH_R5C832, ricoh_mmc_fixup_r5c832);
+DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_RICOH, PCI_DEVICE_ID_RICOH_R5CE823, ricoh_mmc_fixup_r5c832);
+DECLARE_PCI_FIXUP_RESUME_EARLY(PCI_VENDOR_ID_RICOH, PCI_DEVICE_ID_RICOH_R5CE823, ricoh_mmc_fixup_r5c832);
 #endif /*CONFIG_MMC_RICOH_MMC*/
 
 #if defined(CONFIG_DMAR) || defined(CONFIG_INTR_REMAP)
Index: linux-2.6.35.y/include/linux/pci_ids.h
===================================================================
--- linux-2.6.35.y.orig/include/linux/pci_ids.h
+++ linux-2.6.35.y/include/linux/pci_ids.h
@@ -1524,6 +1524,7 @@
 #define PCI_DEVICE_ID_RICOH_RL5C476	0x0476
 #define PCI_DEVICE_ID_RICOH_RL5C478	0x0478
 #define PCI_DEVICE_ID_RICOH_R5C822	0x0822
+#define PCI_DEVICE_ID_RICOH_R5CE823	0xe823
 #define PCI_DEVICE_ID_RICOH_R5C832	0x0832
 #define PCI_DEVICE_ID_RICOH_R5C843	0x0843
 

[PATCH] [9/50] mmc: Added quirks for Ricoh 1180:e823 lower base clock

[Andi Kleen]

2.6.35-longterm review patch.  If anyone has any objections, please let me know.

------------------
From: Manoj Iyer <manoj.iyer@canonical.com>

[ upstream commit 15bed0f2fa8e1d7db201692532c210a7823d2d21 ]
 frequency

Ricoh 1180:e823 does not recognize certain types of SD/MMC cards,
as reported at http://launchpad.net/bugs/773524.  Lowering the SD
base clock frequency from 200Mhz to 50Mhz fixes this issue. This
solution was suggest by Koji Matsumuro, Ricoh Company, Ltd.

This change has no negative performance effect on standard SD
cards, though it's quite possible that there will be one on
UHS-1 cards.

Signed-off-by: Manoj Iyer <manoj.iyer@canonical.com>
Tested-by: Daniel Manrique <daniel.manrique@canonical.com>
Cc: Koji Matsumuro <matsumur@nts.ricoh.co.jp>
Cc: <stable@kernel.org>
Acked-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Chris Ball <cjb@laptop.org>
Signed-off-by: Andi Kleen <ak@linux.intel.com>

Index: linux-2.6.35.y/drivers/pci/quirks.c
===================================================================
--- linux-2.6.35.y.orig/drivers/pci/quirks.c
+++ linux-2.6.35.y/drivers/pci/quirks.c
@@ -2698,6 +2698,29 @@ static void ricoh_mmc_fixup_r5c832(struc
 
 	dev_notice(&dev->dev, "proprietary Ricoh MMC controller disabled (via firewire function)\n");
 	dev_notice(&dev->dev, "MMC cards are now supported by standard SDHCI controller\n");
+
+	/*
+	 * RICOH 0xe823 SD/MMC card reader fails to recognize
+	 * certain types of SD/MMC cards. Lowering the SD base
+	 * clock frequency from 200Mhz to 50Mhz fixes this issue.
+	 *
+	 * 0x150 - SD2.0 mode enable for changing base clock
+	 *	   frequency to 50Mhz
+	 * 0xe1  - Base clock frequency
+	 * 0x32  - 50Mhz new clock frequency
+	 * 0xf9  - Key register for 0x150
+	 * 0xfc  - key register for 0xe1
+	 */
+	if (dev->device == PCI_DEVICE_ID_RICOH_R5CE823) {
+		pci_write_config_byte(dev, 0xf9, 0xfc);
+		pci_write_config_byte(dev, 0x150, 0x10);
+		pci_write_config_byte(dev, 0xf9, 0x00);
+		pci_write_config_byte(dev, 0xfc, 0x01);
+		pci_write_config_byte(dev, 0xe1, 0x32);
+		pci_write_config_byte(dev, 0xfc, 0x00);
+
+		dev_notice(&dev->dev, "MMC controller base frequency changed to 50Mhz.\n");
+	}
 }
 DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_RICOH, PCI_DEVICE_ID_RICOH_R5C832, ricoh_mmc_fixup_r5c832);
 DECLARE_PCI_FIXUP_RESUME_EARLY(PCI_VENDOR_ID_RICOH, PCI_DEVICE_ID_RICOH_R5C832, ricoh_mmc_fixup_r5c832);

[PATCH] [10/50] Drop -Werror in perf

[Andi Kleen]

2.6.35-longterm review patch.  If anyone has any objections, please let me know.

------------------
From: Andi Kleen <andi@firstfloor.org>

Drop -Werror in perf Makefile. This fixes the build with gcc 4.5.x

Not in mainline.
Signed-off-by: Andi Kleen <ak@linux.intel.com>

Index: linux-2.6.35.y/tools/perf/Makefile
===================================================================
--- linux-2.6.35.y.orig/tools/perf/Makefile
+++ linux-2.6.35.y/tools/perf/Makefile
@@ -225,7 +225,7 @@ ifndef PERF_DEBUG
   CFLAGS_OPTIMIZE = -O6
 endif
 
-CFLAGS = -ggdb3 -Wall -Wextra -std=gnu99 -Werror $(CFLAGS_OPTIMIZE) -D_FORTIFY_SOURCE=2 $(EXTRA_WARNINGS) $(EXTRA_CFLAGS)
+CFLAGS = -ggdb3 -Wall -Wextra -std=gnu99 $(CFLAGS_OPTIMIZE) -D_FORTIFY_SOURCE=2 $(EXTRA_WARNINGS) $(EXTRA_CFLAGS)
 EXTLIBS = -lpthread -lrt -lelf -lm
 ALL_CFLAGS = $(CFLAGS) -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64
 ALL_LDFLAGS = $(LDFLAGS)

[PATCH] [11/50] kexec, x86: Fix incorrect jump back address if not

[Andi Kleen]

2.6.35-longterm review patch.  If anyone has any objections, please let me know.

------------------
From: Huang Ying <ying.huang@intel.com>

[ upstream commit 050438ed5a05b25cdf287f5691e56a58c2606997 ]
 preserving context

In kexec jump support, jump back address passed to the kexeced
kernel via function calling ABI, that is, the function call
return address is the jump back entry.

Furthermore, jump back entry == 0 should be used to signal that
the jump back or preserve context is not enabled in the original
kernel.

But in the current implementation the stack position used for
function call return address is not cleared context
preservation is disabled. The patch fixes this bug.

Reported-and-tested-by: Yin Kangkai <kangkai.yin@intel.com>
Signed-off-by: Huang Ying <ying.huang@intel.com>
Cc: Eric W. Biederman <ebiederm@xmission.com>
Cc: Vivek Goyal <vgoyal@redhat.com>
Cc: <stable@kernel.org>
Signed-off-by: Andi Kleen <ak@linux.intel.com>
Link: http://lkml.kernel.org/r/1310607277-25029-1-git-send-email-ying.huang@intel.com
Signed-off-by: Ingo Molnar <mingo@elte.hu>

Index: linux-2.6.35.y/arch/x86/kernel/relocate_kernel_32.S
===================================================================
--- linux-2.6.35.y.orig/arch/x86/kernel/relocate_kernel_32.S
+++ linux-2.6.35.y/arch/x86/kernel/relocate_kernel_32.S
@@ -97,6 +97,8 @@ relocate_kernel:
 	ret
 
 identity_mapped:
+	/* set return address to 0 if not preserving context */
+	pushl	$0
 	/* store the start address on the stack */
 	pushl   %edx
 
Index: linux-2.6.35.y/arch/x86/kernel/relocate_kernel_64.S
===================================================================
--- linux-2.6.35.y.orig/arch/x86/kernel/relocate_kernel_64.S
+++ linux-2.6.35.y/arch/x86/kernel/relocate_kernel_64.S
@@ -100,6 +100,8 @@ relocate_kernel:
 	ret
 
 identity_mapped:
+	/* set return address to 0 if not preserving context */
+	pushq	$0
 	/* store the start address on the stack */
 	pushq   %rdx
 

[PATCH] [12/50] USB: serial: add IDs for WinChipHead USB->RS232 adapter

[Andi Kleen]

2.6.35-longterm review patch.  If anyone has any objections, please let me know.

------------------
From: Wolfgang Denk <wd@denx.de>

[ upstream commit 026dfaf18973404a01f488d6aa556a8c466e06a4 ]

Add ID 4348:5523 for WinChipHead USB->RS 232 adapter with
Prolifec PL2303 chipset

Signed-off-by: Wolfgang Denk <wd@denx.de>
Cc: stable <stable@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Andi Kleen <ak@linux.intel.com>

Index: linux-2.6.35.y/drivers/usb/serial/pl2303.c
===================================================================
--- linux-2.6.35.y.orig/drivers/usb/serial/pl2303.c
+++ linux-2.6.35.y/drivers/usb/serial/pl2303.c
@@ -91,6 +91,7 @@ static const struct usb_device_id id_tab
 	{ USB_DEVICE(SONY_VENDOR_ID, SONY_QN3USB_PRODUCT_ID) },
 	{ USB_DEVICE(SANWA_VENDOR_ID, SANWA_PRODUCT_ID) },
 	{ USB_DEVICE(ADLINK_VENDOR_ID, ADLINK_ND6530_PRODUCT_ID) },
+	{ USB_DEVICE(WINCHIPHEAD_VENDOR_ID, WINCHIPHEAD_USBSER_PRODUCT_ID) },
 	{ }					/* Terminating entry */
 };
 
Index: linux-2.6.35.y/drivers/usb/serial/pl2303.h
===================================================================
--- linux-2.6.35.y.orig/drivers/usb/serial/pl2303.h
+++ linux-2.6.35.y/drivers/usb/serial/pl2303.h
@@ -144,3 +144,7 @@
 /* ADLINK ND-6530 RS232,RS485 and RS422 adapter */
 #define ADLINK_VENDOR_ID		0x0b63
 #define ADLINK_ND6530_PRODUCT_ID	0x6530
+
+/* WinChipHead USB->RS 232 adapter */
+#define WINCHIPHEAD_VENDOR_ID		0x4348
+#define WINCHIPHEAD_USBSER_PRODUCT_ID	0x5523

[PATCH] [13/50] davinci: DM365 EVM: fix video input mux bits

[Andi Kleen]

2.6.35-longterm review patch.  If anyone has any objections, please let me know.

------------------
From: Jon Povey <jon.povey@racelogic.co.uk>

[ upstream commit 9daedd833a38edd90cf7baa1b1fcf61c3a0721e3 ]

Video input mux settings for tvp7002 and imager inputs were swapped.
Comment was correct.

Tested on EVM with tvp7002 input.

Signed-off-by: Jon Povey <jon.povey@racelogic.co.uk>
Acked-by: Manjunath Hadli <manjunath.hadli@ti.com>
Cc: stable@kernel.org
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
Signed-off-by: Andi Kleen <ak@linux.intel.com>

Index: linux-2.6.35.y/arch/arm/mach-davinci/board-dm365-evm.c
===================================================================
--- linux-2.6.35.y.orig/arch/arm/mach-davinci/board-dm365-evm.c
+++ linux-2.6.35.y/arch/arm/mach-davinci/board-dm365-evm.c
@@ -520,7 +520,7 @@ fail:
 	 */
 	if (have_imager()) {
 		label = "HD imager";
-		mux |= 1;
+		mux |= 2;
 
 		/* externally mux MMC1/ENET/AIC33 to imager */
 		mux |= BIT(6) | BIT(5) | BIT(3);
@@ -541,7 +541,7 @@ fail:
 		resets &= ~BIT(1);
 
 		if (have_tvp7002()) {
-			mux |= 2;
+			mux |= 1;
 			resets &= ~BIT(2);
 			label = "tvp7002 HD";
 		} else {

[PATCH] [14/50] powerpc/pseries/hvconsole: Fix dropped console output

[Andi Kleen]

2.6.35-longterm review patch.  If anyone has any objections, please let me know.

------------------
From: Anton Blanchard <anton@samba.org>

[ upstream commit 51d33021425e1f905beb4208823146f2fb6517da ]

Return -EAGAIN when we get H_BUSY back from the hypervisor. This
makes the hvc console driver retry, avoiding dropped printks.

Signed-off-by: Anton Blanchard <anton@samba.org>
Cc: <stable@kernel.org>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Andi Kleen <ak@linux.intel.com>

Index: linux-2.6.35.y/arch/powerpc/platforms/pseries/hvconsole.c
===================================================================
--- linux-2.6.35.y.orig/arch/powerpc/platforms/pseries/hvconsole.c
+++ linux-2.6.35.y/arch/powerpc/platforms/pseries/hvconsole.c
@@ -73,7 +73,7 @@ int hvc_put_chars(uint32_t vtermno, cons
 	if (ret == H_SUCCESS)
 		return count;
 	if (ret == H_BUSY)
-		return 0;
+		return -EAGAIN;
 	return -EIO;
 }
 

[PATCH] [15/50] hvc_console: Improve tty/console put_chars handling

[Andi Kleen]

2.6.35-longterm review patch.  If anyone has any objections, please let me know.

------------------
From: Hendrik Brueckner <brueckner@linux.vnet.ibm.com>

[ upstream commit 8c2381af0d3ef62a681dac5a141b6dabb27bf2e1 ]

Currently, the hvc_console_print() function drops console output if the
hvc backend's put_chars() returns 0.  This patch changes this behavior
to allow a retry through returning -EAGAIN.

This change also affects the hvc_push() function.  Both functions are
changed to handle -EAGAIN and to retry the put_chars() operation.

If a hvc backend returns -EAGAIN, the retry handling differs:

  - hvc_console_print() spins to write the complete console output.
  - hvc_push() behaves the same way as for returning 0.

Now hvc backends can indirectly control the way how console output is
handled through the hvc console layer.

Signed-off-by: Hendrik Brueckner <brueckner@linux.vnet.ibm.com>
Acked-by: Anton Blanchard <anton@samba.org>
Cc: <stable@kernel.org>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Andi Kleen <ak@linux.intel.com>

Index: linux-2.6.35.y/drivers/char/hvc_console.c
===================================================================
--- linux-2.6.35.y.orig/drivers/char/hvc_console.c
+++ linux-2.6.35.y/drivers/char/hvc_console.c
@@ -163,8 +163,10 @@ static void hvc_console_print(struct con
 		} else {
 			r = cons_ops[index]->put_chars(vtermnos[index], c, i);
 			if (r <= 0) {
-				/* throw away chars on error */
-				i = 0;
+				/* throw away characters on error
+				 * but spin in case of -EAGAIN */
+				if (r != -EAGAIN)
+					i = 0;
 			} else if (r > 0) {
 				i -= r;
 				if (i > 0)
@@ -448,7 +450,7 @@ static int hvc_push(struct hvc_struct *h
 
 	n = hp->ops->put_chars(hp->vtermno, hp->outbuf, hp->n_outbuf);
 	if (n <= 0) {
-		if (n == 0) {
+		if (n == 0 || n == -EAGAIN) {
 			hp->do_wakeup = 1;
 			return 0;
 		}

[PATCH] [16/50] powerpc/kdump: Fix timeout in crash_kexec_wait_realmode

[Andi Kleen]

2.6.35-longterm review patch.  If anyone has any objections, please let me know.

------------------
From: Michael Neuling <mikey@neuling.org>

[ upstream commit 63f21a56f1cc0b800a4c00349c59448f82473d19 ]

The existing code it pretty ugly.  How about we clean it up even more
like this?

From: Anton Blanchard <anton@samba.org>

We check for timeout expiry in the outer loop, but we also need to
check it in the inner loop or we can lock up forever waiting for a
CPU to hit real mode.

Signed-off-by: Anton Blanchard <anton@samba.org>
Signed-off-by: Michael Neuling <mikey@neuling.org>
Cc: <stable@kernel.org>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Andi Kleen <ak@linux.intel.com>

Index: linux-2.6.35.y/arch/powerpc/kernel/crash.c
===================================================================
--- linux-2.6.35.y.orig/arch/powerpc/kernel/crash.c
+++ linux-2.6.35.y/arch/powerpc/kernel/crash.c
@@ -176,12 +176,8 @@ static void crash_kexec_wait_realmode(in
 
 		while (paca[i].kexec_state < KEXEC_STATE_REAL_MODE) {
 			barrier();
-			if (!cpu_possible(i)) {
+			if (!cpu_possible(i) || !cpu_online(i) || (msecs <= 0))
 				break;
-			}
-			if (!cpu_online(i)) {
-				break;
-			}
 			msecs--;
 			mdelay(1);
 		}

[PATCH] [17/50] si4713-i2c: avoid potential buffer overflow on si4713

[Andi Kleen]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1716 bytes --]

2.6.35-longterm review patch.  If anyone has any objections, please let me know.

------------------
From: Mauro Carvalho Chehab <mchehab@redhat.com>

[ upstream commit dc6b845044ccb7e9e6f3b7e71bd179b3cf0223b6 ]
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

While compiling it with Fedora 15, I noticed this issue:

  inlined from ‘si4713_write_econtrol_string’ at drivers/media/radio/si4713-i2c.c:1065:24:
  arch/x86/include/asm/uaccess_32.h:211:26: error: call to ‘copy_from_user_overflow’ declared with attribute error: copy_from_user() buffer size is not provably correct

Cc: stable@kernel.org
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Acked-by: Sakari Ailus <sakari.ailus@maxwell.research.nokia.com>
Acked-by: Eduardo Valentin <edubezval@gmail.com>
Reviewed-by: Eugene Teo <eugeneteo@kernel.sg>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Andi Kleen <ak@linux.intel.com>

Index: linux-2.6.35.y/drivers/media/radio/si4713-i2c.c
===================================================================
--- linux-2.6.35.y.orig/drivers/media/radio/si4713-i2c.c
+++ linux-2.6.35.y/drivers/media/radio/si4713-i2c.c
@@ -1004,7 +1004,7 @@ static int si4713_write_econtrol_string(
 		char ps_name[MAX_RDS_PS_NAME + 1];
 
 		len = control->size - 1;
-		if (len > MAX_RDS_PS_NAME) {
+		if (len < 0 || len > MAX_RDS_PS_NAME) {
 			rval = -ERANGE;
 			goto exit;
 		}
@@ -1026,7 +1026,7 @@ static int si4713_write_econtrol_string(
 		char radio_text[MAX_RDS_RADIO_TEXT + 1];
 
 		len = control->size - 1;
-		if (len > MAX_RDS_RADIO_TEXT) {
+		if (len < 0 || len > MAX_RDS_RADIO_TEXT) {
 			rval = -ERANGE;
 			goto exit;
 		}

[PATCH] [18/50] hwmon: (max1111) Fix race condition causing NULL pointer

[Andi Kleen]

2.6.35-longterm review patch.  If anyone has any objections, please let me know.

------------------
From: Pavel Herrmann <morpheus.ibis@gmail.com>

[ upstream commit d3f684f2820a7f42acef68bea6622d9032127fb2 ]
 exception

spi_sync call uses its spi_message parameter to keep completion information,
using a drvdata structure is not thread-safe. Use a mutex to prevent
multiple access to shared driver data.

Signed-off-by: Pavel Herrmann <morpheus.ibis@gmail.com>
Acked-by: Russell King <rmk+kernel@arm.linux.org.uk>
Acked-by: Pavel Machek <pavel@ucw.cz>
Acked-by: Marek Vasut <marek.vasut@gmail.com>
Acked-by: Cyril Hrubis <metan@ucw.cz>
Tested-by: Stanislav Brabec <utx@penguin.cz>
Signed-off-by: Jean Delvare <khali@linux-fr.org>
Cc: stable@kernel.org
Signed-off-by: Andi Kleen <ak@linux.intel.com>

Index: linux-2.6.35.y/drivers/hwmon/max1111.c
===================================================================
--- linux-2.6.35.y.orig/drivers/hwmon/max1111.c
+++ linux-2.6.35.y/drivers/hwmon/max1111.c
@@ -40,6 +40,8 @@ struct max1111_data {
 	struct spi_transfer	xfer[2];
 	uint8_t *tx_buf;
 	uint8_t *rx_buf;
+	struct mutex		drvdata_lock;
+	/* protect msg, xfer and buffers from multiple access */
 };
 
 static int max1111_read(struct device *dev, int channel)
@@ -48,6 +50,9 @@ static int max1111_read(struct device *d
 	uint8_t v1, v2;
 	int err;
 
+	/* writing to drvdata struct is not thread safe, wait on mutex */
+	mutex_lock(&data->drvdata_lock);
+
 	data->tx_buf[0] = (channel << MAX1111_CTRL_SEL_SH) |
 		MAX1111_CTRL_PD0 | MAX1111_CTRL_PD1 |
 		MAX1111_CTRL_SGL | MAX1111_CTRL_UNI | MAX1111_CTRL_STR;
@@ -55,12 +60,15 @@ static int max1111_read(struct device *d
 	err = spi_sync(data->spi, &data->msg);
 	if (err < 0) {
 		dev_err(dev, "spi_sync failed with %d\n", err);
+		mutex_unlock(&data->drvdata_lock);
 		return err;
 	}
 
 	v1 = data->rx_buf[0];
 	v2 = data->rx_buf[1];
 
+	mutex_unlock(&data->drvdata_lock);
+
 	if ((v1 & 0xc0) || (v2 & 0x3f))
 		return -EINVAL;
 
@@ -176,6 +184,8 @@ static int __devinit max1111_probe(struc
 	if (err)
 		goto err_free_data;
 
+	mutex_init(&data->drvdata_lock);
+
 	data->spi = spi;
 	spi_set_drvdata(spi, data);
 
@@ -213,6 +223,7 @@ static int __devexit max1111_remove(stru
 
 	hwmon_device_unregister(data->hwmon_dev);
 	sysfs_remove_group(&spi->dev.kobj, &max1111_attr_group);
+	mutex_destroy(&data->drvdata_lock);
 	kfree(data->rx_buf);
 	kfree(data->tx_buf);
 	kfree(data);

[PATCH] [19/50] hwmon: (asus_atk0110) Fix memory leak

[Andi Kleen]

2.6.35-longterm review patch.  If anyone has any objections, please let me know.

------------------
From: Luca Tettamanti <kronos.it@gmail.com>

[ upstream commit 0b8e77f12cb6bfe2e5a67f2cdc8c7af23abc4ccf ]

The object returned by atk_gitm is dynamically allocated and must be
freed.

Signed-off-by: Luca Tettamanti <kronos.it@gmail.com>
Signed-off-by: Jean Delvare <khali@linux-fr.org>
Cc: stable@kernel.org
Signed-off-by: Andi Kleen <ak@linux.intel.com>

Index: linux-2.6.35.y/drivers/hwmon/asus_atk0110.c
===================================================================
--- linux-2.6.35.y.orig/drivers/hwmon/asus_atk0110.c
+++ linux-2.6.35.y/drivers/hwmon/asus_atk0110.c
@@ -655,6 +655,7 @@ static int atk_debugfs_gitm_get(void *p,
 	else
 		err = -EIO;
 
+	ACPI_FREE(ret);
 	return err;
 }
 

[PATCH] [20/50] USB: OHCI: fix another regression for NVIDIA controllers

[Andi Kleen]

2.6.35-longterm review patch.  If anyone has any objections, please let me know.

------------------
From: Alan Stern <stern@rowland.harvard.edu>

[ upstream commit 6ea12a04d295235ed67010a09fdea58c949e3eb0 ]

The NVIDIA series of OHCI controllers continues to be troublesome.  A
few people using the MCP67 chipset have reported that even with the
most recent kernels, the OHCI controller fails to handle new
connections and spams the system log with "unable to enumerate USB
port" messages.  This is different from the other problems previously
reported for NVIDIA OHCI controllers, although it is probably related.

It turns out that the MCP67 controller does not like to be kept in the
RESET state very long.  After only a few seconds, it decides not to
work any more.  This patch (as1479) changes the PCI initialization
quirk code so that NVIDIA controllers are switched into the SUSPEND
state after 50 ms of RESET.  With no interrupts enabled and all the
downstream devices reset, and thus unable to send wakeup requests,
this should be perfectly safe (even for non-NVIDIA hardware).

The removal code in ohci-hcd hasn't been changed; it will still leave
the controller in the RESET state.  As a result, if someone unloads
ohci-hcd and then reloads it, the controller won't work again until
the system is rebooted.  If anybody complains about this, the removal
code can be updated similarly.

This fixes Bugzilla #22052.

Tested-by: Larry Finger <Larry.Finger@lwfinger.net>
Cc: stable <stable@kernel.org>
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Andi Kleen <ak@linux.intel.com>

Index: linux-2.6.35.y/drivers/usb/host/pci-quirks.c
===================================================================
--- linux-2.6.35.y.orig/drivers/usb/host/pci-quirks.c
+++ linux-2.6.35.y/drivers/usb/host/pci-quirks.c
@@ -34,6 +34,8 @@
 #define OHCI_INTRSTATUS		0x0c
 #define OHCI_INTRENABLE		0x10
 #define OHCI_INTRDISABLE	0x14
+#define OHCI_FMINTERVAL		0x34
+#define OHCI_HCR		(1 << 0)	/* host controller reset */
 #define OHCI_OCR		(1 << 3)	/* ownership change request */
 #define OHCI_CTRL_RWC		(1 << 9)	/* remote wakeup connected */
 #define OHCI_CTRL_IR		(1 << 8)	/* interrupt routing */
@@ -204,6 +206,32 @@ static void __devinit quirk_usb_handoff_
 
 	/* reset controller, preserving RWC (and possibly IR) */
 	writel(control & OHCI_CTRL_MASK, base + OHCI_CONTROL);
+	readl(base + OHCI_CONTROL);
+
+	/* Some NVIDIA controllers stop working if kept in RESET for too long */
+	if (pdev->vendor == PCI_VENDOR_ID_NVIDIA) {
+		u32 fminterval;
+		int cnt;
+
+		/* drive reset for at least 50 ms (7.1.7.5) */
+		msleep(50);
+
+		/* software reset of the controller, preserving HcFmInterval */
+		fminterval = readl(base + OHCI_FMINTERVAL);
+		writel(OHCI_HCR, base + OHCI_CMDSTATUS);
+
+		/* reset requires max 10 us delay */
+		for (cnt = 30; cnt > 0; --cnt) {	/* ... allow extra time */
+			if ((readl(base + OHCI_CMDSTATUS) & OHCI_HCR) == 0)
+				break;
+			udelay(1);
+		}
+		writel(fminterval, base + OHCI_FMINTERVAL);
+
+		/* Now we're in the SUSPEND state with all devices reset
+		 * and wakeups and interrupts disabled
+		 */
+	}
 
 	/*
 	 * disable interrupts

[PATCH] [21/50] firewire: cdev: prevent race between first get_info ioctl

[Andi Kleen]

2.6.35-longterm review patch.  If anyone has any objections, please let me know.

------------------
From: Stefan Richter <stefanr@s5r6.in-berlin.de>

[ upstream commit 93b37905f70083d6143f5f4dba0a45cc64379a62 ]
 and bus reset event queuing

Between open(2) of a /dev/fw* and the first FW_CDEV_IOC_GET_INFO
ioctl(2) on it, the kernel already queues FW_CDEV_EVENT_BUS_RESET events
to be read(2) by the client.  The get_info ioctl is practically always
issued right away after open, hence this condition only occurs if the
client opens during a bus reset, especially during a rapid series of bus
resets.

The problem with this condition is twofold:

  - These bus reset events carry the (as yet undocumented) @closure
    value of 0.  But it is not the kernel's place to choose closures;
    they are privat to the client.  E.g., this 0 value forced from the
    kernel makes it unsafe for clients to dereference it as a pointer to
    a closure object without NULL pointer check.

  - It is impossible for clients to determine the relative order of bus
    reset events from get_info ioctl(2) versus those from read(2),
    except in one way:  By comparison of closure values.  Again, such a
    procedure imposes complexity on clients and reduces freedom in use
    of the bus reset closure.

So, change the ABI to suppress queuing of bus reset events before the
first FW_CDEV_IOC_GET_INFO ioctl was issued by the client.

Note, this ABI change cannot be version-controlled.  The kernel cannot
distinguish old from new clients before the first FW_CDEV_IOC_GET_INFO
ioctl.

We will try to back-merge this change into currently maintained stable/
longterm series, and we only document the new behaviour.  The old
behavior is now considered a kernel bug, which it basically is.

Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Cc: <stable@kernel.org>
Signed-off-by: Andi Kleen <ak@linux.intel.com>

Index: linux-2.6.35.y/drivers/firewire/core-cdev.c
===================================================================
--- linux-2.6.35.y.orig/drivers/firewire/core-cdev.c
+++ linux-2.6.35.y/drivers/firewire/core-cdev.c
@@ -219,14 +219,11 @@ static int fw_device_op_open(struct inod
 	idr_init(&client->resource_idr);
 	INIT_LIST_HEAD(&client->event_list);
 	init_waitqueue_head(&client->wait);
+	INIT_LIST_HEAD(&client->link);
 	kref_init(&client->kref);
 
 	file->private_data = client;
 
-	mutex_lock(&device->client_list_mutex);
-	list_add_tail(&client->link, &device->client_list);
-	mutex_unlock(&device->client_list_mutex);
-
 	return nonseekable_open(inode, file);
 }
 
@@ -414,15 +411,20 @@ static int ioctl_get_info(struct client 
 	if (ret != 0)
 		return -EFAULT;
 
+	mutex_lock(&client->device->client_list_mutex);
+
 	client->bus_reset_closure = a->bus_reset_closure;
 	if (a->bus_reset != 0) {
 		fill_bus_reset_event(&bus_reset, client);
-		if (copy_to_user(u64_to_uptr(a->bus_reset),
-				 &bus_reset, sizeof(bus_reset)))
-			return -EFAULT;
+		ret = copy_to_user(u64_to_uptr(a->bus_reset),
+				   &bus_reset, sizeof(bus_reset));
 	}
+	if (ret == 0 && list_empty(&client->link))
+		list_add_tail(&client->link, &client->device->client_list);
 
-	return 0;
+	mutex_unlock(&client->device->client_list_mutex);
+
+	return ret ? -EFAULT : 0;
 }
 
 static int add_client_resource(struct client *client,
Index: linux-2.6.35.y/include/linux/firewire-cdev.h
===================================================================
--- linux-2.6.35.y.orig/include/linux/firewire-cdev.h
+++ linux-2.6.35.y/include/linux/firewire-cdev.h
@@ -284,6 +284,9 @@ union fw_cdev_event {
  *		of the bus.  This does not cause a bus reset to happen.
  * @bus_reset_closure: Value of &closure in this and subsequent bus reset events
  * @card:	The index of the card this device belongs to
+ *
+ * As a side effect, reception of %FW_CDEV_EVENT_BUS_RESET events to be read(2)
+ * is started by this ioctl.
  */
 struct fw_cdev_get_info {
 	__u32 version;

[PATCH] [22/50] firewire: cdev: return -ENOTTY for unimplemented ioctls, not

[Andi Kleen]

2.6.35-longterm review patch.  If anyone has any objections, please let me know.

------------------
From: Stefan Richter <stefanr@s5r6.in-berlin.de>

[ upstream commit d873d794235efa590ab3c94d5ee22bb1fab19ac4 ]
 -EINVAL

On Jun 27 Linus Torvalds wrote:
> The correct error code for "I don't understand this ioctl" is ENOTTY.
> The naming may be odd, but you should think of that error value as a
> "unrecognized ioctl number, you're feeding me random numbers that I
> don't understand and I assume for historical reasons that you tried to
> do some tty operation on me".
[...]
> The EINVAL thing goes way back, and is a disaster. It predates Linux
> itself, as far as I can tell. You'll find lots of man-pages that have
> this line in it:
>
>   EINVAL Request or argp is not valid.
>
> and it shows up in POSIX etc. And sadly, it generally shows up
> _before_ the line that says
>
>   ENOTTY The specified request does not apply to the kind of object
> that the descriptor d references.
>
> so a lot of people get to the EINVAL, and never even notice the ENOTTY.
[...]
> At least glibc (and hopefully other C libraries) use a _string_ that
> makes much more sense: strerror(ENOTTY) is "Inappropriate ioctl for
> device"

So let's correct this in the <linux/firewire-cdev.h> ABI while it is
still young, relative to distributor adoption.

Side note:  We return -ENOTTY not only on _IOC_TYPE or _IOC_NR mismatch,
but also on _IOC_SIZE mismatch.  An ioctl with an unsupported size of
argument structure can be seen as an unsupported version of that ioctl.

Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Cc: <stable@kernel.org>
Signed-off-by: Andi Kleen <ak@linux.intel.com>

Index: linux-2.6.35.y/drivers/firewire/core-cdev.c
===================================================================
--- linux-2.6.35.y.orig/drivers/firewire/core-cdev.c
+++ linux-2.6.35.y/drivers/firewire/core-cdev.c
@@ -1361,7 +1361,7 @@ static int dispatch_ioctl(struct client 
 	if (_IOC_TYPE(cmd) != '#' ||
 	    _IOC_NR(cmd) >= ARRAY_SIZE(ioctl_handlers) ||
 	    _IOC_SIZE(cmd) > sizeof(buffer))
-		return -EINVAL;
+		return -ENOTTY;
 
 	if (_IOC_DIR(cmd) == _IOC_READ)
 		memset(&buffer, 0, _IOC_SIZE(cmd));

[PATCH] [23/50] svcrpc: fix list-corrupting race on nfsd shutdown

[Andi Kleen]

2.6.35-longterm review patch.  If anyone has any objections, please let me know.

------------------
From: J. Bruce Fields <bfields@redhat.com>

[ upstream commit ebc63e531cc6a457595dd110b07ac530eae788c3 ]

After commit 3262c816a3d7fb1eaabce633caa317887ed549ae "[PATCH] knfsd:
split svc_serv into pools", svc_delete_xprt (then svc_delete_socket) no
longer removed its xpt_ready (then sk_ready) field from whatever list it
was on, noting that there was no point since the whole list was about to
be destroyed anyway.

That was mostly true, but forgot that a few svc_xprt_enqueue()'s might
still be hanging around playing with the about-to-be-destroyed list, and
could get themselves into trouble writing to freed memory if we left
this xprt on the list after freeing it.

(This is actually functionally identical to a patch made first by Ben
Greear, but with more comments.)

Cc: stable@kernel.org
Cc: gnb@fmeh.org
Reported-by: Ben Greear <greearb@candelatech.com>
Tested-by: Ben Greear <greearb@candelatech.com>
Signed-off-by: J. Bruce Fields <bfields@redhat.com>
Signed-off-by: Andi Kleen <ak@linux.intel.com>

Index: linux-2.6.35.y/net/sunrpc/svc_xprt.c
===================================================================
--- linux-2.6.35.y.orig/net/sunrpc/svc_xprt.c
+++ linux-2.6.35.y/net/sunrpc/svc_xprt.c
@@ -894,12 +894,13 @@ void svc_delete_xprt(struct svc_xprt *xp
 	if (!test_and_set_bit(XPT_DETACHED, &xprt->xpt_flags))
 		list_del_init(&xprt->xpt_list);
 	/*
-	 * We used to delete the transport from whichever list
-	 * it's sk_xprt.xpt_ready node was on, but we don't actually
-	 * need to.  This is because the only time we're called
-	 * while still attached to a queue, the queue itself
-	 * is about to be destroyed (in svc_destroy).
+	 * The only time we're called while xpt_ready is still on a list
+	 * is while the list itself is about to be destroyed (in
+	 * svc_destroy).  BUT svc_xprt_enqueue could still be attempting
+	 * to add new entries to the sp_sockets list, so we can't leave
+	 * a freed xprt on it.
 	 */
+	list_del_init(&xprt->xpt_ready);
 	if (test_bit(XPT_TEMP, &xprt->xpt_flags))
 		serv->sv_tmpcnt--;
 	spin_unlock_bh(&serv->sv_lock);

[PATCH] [24/50] x86: Look for IA32_ENERGY_PERF_BIAS support

[Andi Kleen]

2.6.35-longterm review patch.  If anyone has any objections, please let me know.

------------------
From: Venkatesh Pallipadi <venki@google.com>

[ upstream commit 23016bf0 ]

The new IA32_ENERGY_PERF_BIAS MSR allows system software to give
hardware a hint whether OS policy favors more power saving,
or more performance.  This allows the OS to have some influence
on internal hardware power/performance tradeoffs where the OS
has previously had no influence.

The support for this feature is indicated by CPUID.06H.ECX.bit3,
as documented in the Intel Architectures Software Developer's Manual.

This patch discovers support of this feature and displays it
as "epb" in /proc/cpuinfo.

Signed-off-by: Venkatesh Pallipadi <venki@google.com>
Signed-off-by: Andi Kleen <ak@linux.intel.com>
LKML-Reference: <alpine.LFD.2.00.1006032310160.6669@localhost.localdomain>
Signed-off-by: Len Brown <len.brown@intel.com>
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>

Index: linux-2.6.35.y/arch/x86/include/asm/cpufeature.h
===================================================================
--- linux-2.6.35.y.orig/arch/x86/include/asm/cpufeature.h
+++ linux-2.6.35.y/arch/x86/include/asm/cpufeature.h
@@ -162,6 +162,7 @@
 #define X86_FEATURE_IDA		(7*32+ 0) /* Intel Dynamic Acceleration */
 #define X86_FEATURE_ARAT	(7*32+ 1) /* Always Running APIC Timer */
 #define X86_FEATURE_CPB		(7*32+ 2) /* AMD Core Performance Boost */
+#define X86_FEATURE_EPB		(7*32+ 3) /* IA32_ENERGY_PERF_BIAS support */
 
 /* Virtualization flags: Linux defined */
 #define X86_FEATURE_TPR_SHADOW  (8*32+ 0) /* Intel TPR Shadow */
Index: linux-2.6.35.y/arch/x86/include/asm/msr-index.h
===================================================================
--- linux-2.6.35.y.orig/arch/x86/include/asm/msr-index.h
+++ linux-2.6.35.y/arch/x86/include/asm/msr-index.h
@@ -243,6 +243,8 @@
 
 #define MSR_IA32_TEMPERATURE_TARGET	0x000001a2
 
+#define MSR_IA32_ENERGY_PERF_BIAS	0x000001b0
+
 /* MISC_ENABLE bits: architectural */
 #define MSR_IA32_MISC_ENABLE_FAST_STRING	(1ULL << 0)
 #define MSR_IA32_MISC_ENABLE_TCC		(1ULL << 1)
Index: linux-2.6.35.y/arch/x86/kernel/cpu/addon_cpuid_features.c
===================================================================
--- linux-2.6.35.y.orig/arch/x86/kernel/cpu/addon_cpuid_features.c
+++ linux-2.6.35.y/arch/x86/kernel/cpu/addon_cpuid_features.c
@@ -33,6 +33,7 @@ void __cpuinit init_scattered_cpuid_feat
 		{ X86_FEATURE_IDA,   		CR_EAX, 1, 0x00000006 },
 		{ X86_FEATURE_ARAT,  		CR_EAX, 2, 0x00000006 },
 		{ X86_FEATURE_APERFMPERF,	CR_ECX, 0, 0x00000006 },
+		{ X86_FEATURE_EPB,		CR_ECX, 3, 0x00000006 },
 		{ X86_FEATURE_CPB,   		CR_EDX, 9, 0x80000007 },
 		{ X86_FEATURE_NPT,   		CR_EDX, 0, 0x8000000a },
 		{ X86_FEATURE_LBRV,  		CR_EDX, 1, 0x8000000a },

[PATCH] [25/50] x86, intel, power: Initialize MSR_IA32_ENERGY_PERF_BIAS

[Andi Kleen]

2.6.35-longterm review patch.  If anyone has any objections, please let me know.

------------------
From: Len Brown <len.brown@intel.com>

[ upstream commit abe48b108247e9b90b4c6739662a2e5c765ed114 ]

Since 2.6.36 (23016bf0d25), Linux prints the existence of "epb" in /proc/cpuinfo,
Since 2.6.38 (d5532ee7b40), the x86_energy_perf_policy(8) utility has
been available in-tree to update MSR_IA32_ENERGY_PERF_BIAS.

However, the typical BIOS fails to initialize the MSR, presumably
because this is handled by high-volume shrink-wrap operating systems...

Linux distros, on the other hand, do not yet invoke x86_energy_perf_policy(8).
As a result, WSM-EP, SNB, and later hardware from Intel will run in its
default hardware power-on state (performance), which assumes that users
care for performance at all costs and not for energy efficiency.
While that is fine for performance benchmarks, the hardware's intended default
operating point is "normal" mode...

Initialize the MSR to the "normal" by default during kernel boot.

x86_energy_perf_policy(8) is available to change the default after boot,
should the user have a different preference.

Signed-off-by: Len Brown <len.brown@intel.com>
Signed-off-by: Andi Kleen <ak@linux.intel.com>
Link: http://lkml.kernel.org/r/alpine.LFD.2.02.1107140051020.18606@x980
Acked-by: Rafael J. Wysocki <rjw@sisk.pl>
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
Cc: <stable@kernel.org>

Index: linux-2.6.35.y/arch/x86/include/asm/msr-index.h
===================================================================
--- linux-2.6.35.y.orig/arch/x86/include/asm/msr-index.h
+++ linux-2.6.35.y/arch/x86/include/asm/msr-index.h
@@ -231,6 +231,11 @@
 #define THERM_INT_LOW_ENABLE		(1 << 0)
 #define THERM_INT_HIGH_ENABLE		(1 << 1)
 
+#define MSR_IA32_ENERGY_PERF_BIAS	0x000001b0
+#define ENERGY_PERF_BIAS_PERFORMANCE	0
+#define ENERGY_PERF_BIAS_NORMAL		6
+#define ENERGY_PERF_BIAS_POWERSWAVE	15
+
 #define MSR_IA32_THERM_STATUS		0x0000019c
 
 #define THERM_STATUS_PROCHOT		(1 << 0)
Index: linux-2.6.35.y/arch/x86/kernel/cpu/intel.c
===================================================================
--- linux-2.6.35.y.orig/arch/x86/kernel/cpu/intel.c
+++ linux-2.6.35.y/arch/x86/kernel/cpu/intel.c
@@ -450,6 +450,24 @@ static void __cpuinit init_intel(struct 
 
 	if (cpu_has(c, X86_FEATURE_VMX))
 		detect_vmx_virtcap(c);
+
+	/*
+	 * Initialize MSR_IA32_ENERGY_PERF_BIAS if BIOS did not.
+	 * x86_energy_perf_policy(8) is available to change it at run-time
+	 */
+	if (cpu_has(c, X86_FEATURE_EPB)) {
+		u64 epb;
+
+		rdmsrl(MSR_IA32_ENERGY_PERF_BIAS, epb);
+		if ((epb & 0xF) == 0) {
+			printk_once(KERN_WARNING, "x86: updated energy_perf_bias"
+				" to 'normal' from 'performance'\n"
+				"You can view and update epb via utility,"
+				" such as x86_energy_perf_policy(8)\n");
+			epb = (epb & ~0xF) | ENERGY_PERF_BIAS_NORMAL;
+			wrmsrl(MSR_IA32_ENERGY_PERF_BIAS, epb);
+		}
+	}
 }
 
 #ifdef CONFIG_X86_32

[PATCH] [26/50] SUNRPC: Fix use of static variable in rpcb_getport_async

[Andi Kleen]

2.6.35-longterm review patch.  If anyone has any objections, please let me know.

------------------
From: Ben Greear <greearb@candelatech.com>

[ upstream commit ec0dd267bf7d08cb30e321e45a75fd40edd7e528 ]

Because struct rpcbind_args *map was declared static, if two
threads entered this method at the same time, the values
assigned to map could be sent two two differen tasks.
This could cause all sorts of problems, include use-after-free
and double-free of memory.

Fix this by removing the static declaration so that the map
pointer is on the stack.

Signed-off-by: Ben Greear <greearb@candelatech.com>
Cc: stable@kernel.org
Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
Signed-off-by: Andi Kleen <ak@linux.intel.com>

Index: linux-2.6.35.y/net/sunrpc/rpcb_clnt.c
===================================================================
--- linux-2.6.35.y.orig/net/sunrpc/rpcb_clnt.c
+++ linux-2.6.35.y/net/sunrpc/rpcb_clnt.c
@@ -580,7 +580,7 @@ void rpcb_getport_async(struct rpc_task 
 	u32 bind_version;
 	struct rpc_xprt *xprt;
 	struct rpc_clnt	*rpcb_clnt;
-	static struct rpcbind_args *map;
+	struct rpcbind_args *map;
 	struct rpc_task	*child;
 	struct sockaddr_storage addr;
 	struct sockaddr *sap = (struct sockaddr *)&addr;

[PATCH] [27/50] ARM: pxa/cm-x300: fix V3020 RTC functionality

[Andi Kleen]

2.6.35-longterm review patch.  If anyone has any objections, please let me know.

------------------
From: Igor Grinberg <grinberg@compulab.co.il>

[ upstream commit 6c7b3ea52e345ab614edb91d3f0e9f3bb3713871 ]

While in sleep mode the CS# and other V3020 RTC GPIOs must be driven
high, otherwise V3020 RTC fails to keep the right time in sleep mode.

Signed-off-by: Igor Grinberg <grinberg@compulab.co.il>
Cc: stable@kernel.org
Signed-off-by: Eric Miao <eric.y.miao@gmail.com>
Signed-off-by: Andi Kleen <ak@linux.intel.com>

Index: linux-2.6.35.y/arch/arm/mach-pxa/cm-x300.c
===================================================================
--- linux-2.6.35.y.orig/arch/arm/mach-pxa/cm-x300.c
+++ linux-2.6.35.y/arch/arm/mach-pxa/cm-x300.c
@@ -157,10 +157,10 @@ static mfp_cfg_t cm_x3xx_mfp_cfg[] __ini
 	GPIO99_GPIO,			/* Ethernet IRQ */
 
 	/* RTC GPIOs */
-	GPIO95_GPIO,			/* RTC CS */
-	GPIO96_GPIO,			/* RTC WR */
-	GPIO97_GPIO,			/* RTC RD */
-	GPIO98_GPIO,			/* RTC IO */
+	GPIO95_GPIO | MFP_LPM_DRIVE_HIGH,	/* RTC CS */
+	GPIO96_GPIO | MFP_LPM_DRIVE_HIGH,	/* RTC WR */
+	GPIO97_GPIO | MFP_LPM_DRIVE_HIGH,	/* RTC RD */
+	GPIO98_GPIO,				/* RTC IO */
 
 	/* Standard I2C */
 	GPIO21_I2C_SCL,

[PATCH] [28/50] firewire: ohci: do not bind to Pinnacle cards, avert panic

[Andi Kleen]

2.6.35-longterm review patch.  If anyone has any objections, please let me know.

------------------
From: Stefan Richter <stefanr@s5r6.in-berlin.de>

[ upstream commit 7f7e37115a8b6724f26d0637a04e1d35e3c59717 ]

When firewire-ohci is bound to a Pinnacle MovieBoard, eventually a
"Register access failure" is logged and an interrupt storm or a kernel
panic happens.  https://bugzilla.kernel.org/show_bug.cgi?id=36622

Until this is sorted out (if that is going to succeed at all), let's
just prevent firewire-ohci from touching these devices.

Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Cc: <stable@kernel.org>
Signed-off-by: Andi Kleen <ak@linux.intel.com>

Index: linux-2.6.35.y/drivers/firewire/ohci.c
===================================================================
--- linux-2.6.35.y.orig/drivers/firewire/ohci.c
+++ linux-2.6.35.y/drivers/firewire/ohci.c
@@ -232,6 +232,7 @@ static inline struct fw_ohci *fw_ohci(st
 static char ohci_driver_name[] = KBUILD_MODNAME;
 
 #define PCI_DEVICE_ID_TI_TSB12LV22	0x8009
+#define PCI_VENDOR_ID_PINNACLE_SYSTEMS	0x11bd
 
 #define QUIRK_CYCLE_TIMER		1
 #define QUIRK_RESET_PACKET		2
@@ -2480,6 +2481,11 @@ static int __devinit pci_probe(struct pc
 	int i, err, n_ir, n_it;
 	size_t size;
 
+	if (dev->vendor == PCI_VENDOR_ID_PINNACLE_SYSTEMS) {
+		dev_err(&dev->dev, "Pinnacle MovieBoard is not yet supported\n");
+		return -ENOSYS;
+	}
+
 	ohci = kzalloc(sizeof(*ohci), GFP_KERNEL);
 	if (ohci == NULL) {
 		err = -ENOMEM;

[PATCH] [29/50] mm/nommu.c: fix remap_pfn_range()

[Andi Kleen]

2.6.35-longterm review patch.  If anyone has any objections, please let me know.

------------------
From: Bob Liu <lliubbo@gmail.com>

[ upstream commit 8f3b1327aa454bc8283e96bca7669c3c88b83f79 ]

remap_pfn_range() means map physical address pfn<<PAGE_SHIFT to user addr.

For nommu arch it's implemented by vma->vm_start = pfn << PAGE_SHIFT which
is wrong acroding the original meaning of this function.  And some driver
developer using remap_pfn_range() with correct parameter will get
unexpected result because vm_start is changed.  It should be implementd
like addr = pfn << PAGE_SHIFT but which is meanless on nommu arch, this
patch just make it simply return.

Parameter name and setting of vma->vm_flags also be fixed.

Signed-off-by: Bob Liu <lliubbo@gmail.com>
Cc: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: David Howells <dhowells@redhat.com>
Acked-by: Greg Ungerer <gerg@uclinux.org>
Cc: Mike Frysinger <vapier@gentoo.org>
Cc: Bob Liu <lliubbo@gmail.com>
Cc: <stable@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Andi Kleen <ak@linux.intel.com>

Index: linux-2.6.35.y/mm/nommu.c
===================================================================
--- linux-2.6.35.y.orig/mm/nommu.c
+++ linux-2.6.35.y/mm/nommu.c
@@ -1747,10 +1747,13 @@ struct page *follow_page(struct vm_area_
 	return NULL;
 }
 
-int remap_pfn_range(struct vm_area_struct *vma, unsigned long from,
-		unsigned long to, unsigned long size, pgprot_t prot)
+int remap_pfn_range(struct vm_area_struct *vma, unsigned long addr,
+		unsigned long pfn, unsigned long size, pgprot_t prot)
 {
-	vma->vm_start = vma->vm_pgoff << PAGE_SHIFT;
+	if (addr != (pfn << PAGE_SHIFT))
+		return -EINVAL;
+
+	vma->vm_flags |= VM_IO | VM_RESERVED | VM_PFNMAP;
 	return 0;
 }
 EXPORT_SYMBOL(remap_pfn_range);

[PATCH] [30/50] EHCI: only power off port if over-current is active

[Andi Kleen]

2.6.35-longterm review patch.  If anyone has any objections, please let me know.

------------------
From: Sergei Shtylyov <sshtylyov@ru.mvista.com>

[ upstream commit 81463c1d707186adbbe534016cd1249edeab0dac ]

MAX4967 USB power supply chip we use on our boards signals over-current when
power is not enabled; once it's enabled, over-current signal returns to normal.
That unfortunately caused the endless stream of "over-current change on port"
messages. The EHCI root hub code reacts on every over-current signal change
with powering off the port -- such change event is generated the moment the
port power is enabled, so once enabled the power is immediately cut off.
I think we should only cut off power when we're seeing the active over-current
signal, so I'm adding such check to that code. I also think that the fact that
we've cut off the port power should be reflected in the result of GetPortStatus
request immediately, hence I'm adding a PORTSCn register readback after write...

Signed-off-by: Sergei Shtylyov <sshtylyov@ru.mvista.com>
Cc: stable@kernel.org
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Andi Kleen <ak@linux.intel.com>

Index: linux-2.6.35.y/drivers/usb/host/ehci-hub.c
===================================================================
--- linux-2.6.35.y.orig/drivers/usb/host/ehci-hub.c
+++ linux-2.6.35.y/drivers/usb/host/ehci-hub.c
@@ -837,10 +837,11 @@ static int ehci_hub_control (
 			 * power switching; they're allowed to just limit the
 			 * current.  khubd will turn the power back on.
 			 */
-			if (HCS_PPC (ehci->hcs_params)){
+			if ((temp & PORT_OC) && HCS_PPC(ehci->hcs_params)) {
 				ehci_writel(ehci,
 					temp & ~(PORT_RWC_BITS | PORT_POWER),
 					status_reg);
+				temp = ehci_readl(ehci, status_reg);
 			}
 		}
 

[PATCH] [31/50] mac80211: Restart STA timers only on associated state

[Andi Kleen]

2.6.35-longterm review patch.  If anyone has any objections, please let me know.

------------------
From: Rajkumar Manoharan <rmanohar@qca.qualcomm.com>

[ upstream commit 676b58c27475a9defccc025fea1cbd2b141ee539 ]

A panic was observed when the device is failed to resume properly,
and there are no running interfaces. ieee80211_reconfig tries
to restart STA timers on unassociated state.

Cc: stable@kernel.org
Signed-off-by: Rajkumar Manoharan <rmanohar@qca.qualcomm.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Andi Kleen <ak@linux.intel.com>

Index: linux-2.6.35.y/net/mac80211/mlme.c
===================================================================
--- linux-2.6.35.y.orig/net/mac80211/mlme.c
+++ linux-2.6.35.y/net/mac80211/mlme.c
@@ -1995,6 +1995,9 @@ void ieee80211_sta_restart(struct ieee80
 {
 	struct ieee80211_if_managed *ifmgd = &sdata->u.mgd;
 
+	if (!ifmgd->associated)
+		return;
+
 	if (test_and_clear_bit(TMR_RUNNING_TIMER, &ifmgd->timers_running))
 		add_timer(&ifmgd->timer);
 	if (test_and_clear_bit(TMR_RUNNING_CHANSW, &ifmgd->timers_running))

[PATCH] [32/50] usb: musb: restore INDEX register in resume path

[Andi Kleen]

2.6.35-longterm review patch.  If anyone has any objections, please let me know.

------------------
From: Ajay Kumar Gupta <ajay.gupta@ti.com>

[ upstream commit 3c5fec75e121b21a2eb35e5a6b44291509abba6f ]

Restoring the missing INDEX register value in musb_restore_context().
Without this suspend resume functionality is broken with offmode
enabled.

Cc: stable@kernel.org
Acked-by: Anand Gadiyar <gadiyar@ti.com>
Signed-off-by: Ajay Kumar Gupta <ajay.gupta@ti.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Andi Kleen <ak@linux.intel.com>

Index: linux-2.6.35.y/drivers/usb/musb/musb_core.c
===================================================================
--- linux-2.6.35.y.orig/drivers/usb/musb/musb_core.c
+++ linux-2.6.35.y/drivers/usb/musb/musb_core.c
@@ -1697,6 +1697,7 @@ void musb_dma_completion(struct musb *mu
 			}
 		}
 	}
+	musb_writeb(musb_base, MUSB_INDEX, musb->context.index);
 }
 
 #else

[PATCH] [33/50] SUNRPC: Fix a race between work-queue and rpc_killall_tasks

[Andi Kleen]

2.6.35-longterm review patch.  If anyone has any objections, please let me know.

------------------
From: Trond Myklebust <Trond.Myklebust@netapp.com>

[ upstream commit b55c59892e1f3b6c7d4b9ccffb4263e1486fb990 ]

Since rpc_killall_tasks may modify the rpc_task's tk_action field
without any locking, we need to be careful when dereferencing it.

Reported-by: Ben Greear <greearb@candelatech.com>
Tested-by: Ben Greear <greearb@candelatech.com>
Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
Cc: stable@kernel.org
Signed-off-by: Andi Kleen <ak@linux.intel.com>

Index: linux-2.6.35.y/net/sunrpc/sched.c
===================================================================
--- linux-2.6.35.y.orig/net/sunrpc/sched.c
+++ linux-2.6.35.y/net/sunrpc/sched.c
@@ -623,30 +623,25 @@ static void __rpc_execute(struct rpc_tas
 	BUG_ON(RPC_IS_QUEUED(task));
 
 	for (;;) {
+		void (*do_action)(struct rpc_task *);
 
 		/*
-		 * Execute any pending callback.
+		 * Execute any pending callback first.
 		 */
-		if (task->tk_callback) {
-			void (*save_callback)(struct rpc_task *);
-
-			/*
-			 * We set tk_callback to NULL before calling it,
-			 * in case it sets the tk_callback field itself:
-			 */
-			save_callback = task->tk_callback;
-			task->tk_callback = NULL;
-			save_callback(task);
-		} else {
+		do_action = task->tk_callback;
+		task->tk_callback = NULL;
+		if (do_action == NULL) {
 			/*
 			 * Perform the next FSM step.
-			 * tk_action may be NULL when the task has been killed
-			 * by someone else.
+			 * tk_action may be NULL if the task has been killed.
+			 * In particular, note that rpc_killall_tasks may
+			 * do this at any time, so beware when dereferencing.
 			 */
-			if (task->tk_action == NULL)
+			do_action = task->tk_action;
+			if (do_action == NULL)
 				break;
-			task->tk_action(task);
 		}
+		do_action(task);
 
 		/*
 		 * Lockless check for whether task is sleeping or not.

[PATCH] [34/50] bttv: fix s_tuner for radio

[Andi Kleen]

2.6.35-longterm review patch.  If anyone has any objections, please let me know.

------------------
From: Hans Verkuil <hans.verkuil@cisco.com>

[ upstream commit a024c1a6b274e11596d124619e43c25560f64c01 ]

Fix typo: g_tuner should have been s_tuner.

Tested with a bttv card.

Cc: stable@kernel.org
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Signed-off-by: Andi Kleen <ak@linux.intel.com>

Index: linux-2.6.35.y/drivers/media/video/bt8xx/bttv-driver.c
===================================================================
--- linux-2.6.35.y.orig/drivers/media/video/bt8xx/bttv-driver.c
+++ linux-2.6.35.y/drivers/media/video/bt8xx/bttv-driver.c
@@ -3525,7 +3525,7 @@ static int radio_s_tuner(struct file *fi
 	if (0 != t->index)
 		return -EINVAL;
 
-	bttv_call_all(btv, tuner, g_tuner, t);
+	bttv_call_all(btv, tuner, s_tuner, t);
 	return 0;
 }
 

[PATCH] [35/50] pvrusb2: fix g/s_tuner support

[Andi Kleen]

2.6.35-longterm review patch.  If anyone has any objections, please let me know.

------------------
From: Hans Verkuil <hans.verkuil@cisco.com>

[ upstream commit 50e9efd60b213ce43ad6979bfc18e25eec2d8413 ]

The tuner-core subdev requires that the type field of v4l2_tuner is
filled in correctly. This is done in v4l2-ioctl.c, but pvrusb2 doesn't
use that yet, so we have to do it manually based on whether the current
input is radio or not.

Tested with my pvrusb2.

Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Acked-by: Mike Isely <isely@pobox.com>
Cc: stable@kernel.org
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Signed-off-by: Andi Kleen <ak@linux.intel.com>

Index: linux-2.6.35.y/drivers/media/video/pvrusb2/pvrusb2-hdw.c
===================================================================
--- linux-2.6.35.y.orig/drivers/media/video/pvrusb2/pvrusb2-hdw.c
+++ linux-2.6.35.y/drivers/media/video/pvrusb2/pvrusb2-hdw.c
@@ -3039,6 +3039,8 @@ static void pvr2_subdev_update(struct pv
 	if (hdw->input_dirty || hdw->audiomode_dirty || hdw->force_dirty) {
 		struct v4l2_tuner vt;
 		memset(&vt, 0, sizeof(vt));
+		vt.type = (hdw->input_val == PVR2_CVAL_INPUT_RADIO) ?
+			V4L2_TUNER_RADIO : V4L2_TUNER_ANALOG_TV;
 		vt.audmode = hdw->audiomode_val;
 		v4l2_device_call_all(&hdw->v4l2_dev, 0, tuner, s_tuner, &vt);
 	}
@@ -5163,6 +5165,8 @@ void pvr2_hdw_status_poll(struct pvr2_hd
 {
 	struct v4l2_tuner *vtp = &hdw->tuner_signal_info;
 	memset(vtp, 0, sizeof(*vtp));
+	vtp->type = (hdw->input_val == PVR2_CVAL_INPUT_RADIO) ?
+		V4L2_TUNER_RADIO : V4L2_TUNER_ANALOG_TV;
 	hdw->tuner_signal_stale = 0;
 	/* Note: There apparently is no replacement for VIDIOC_CROPCAP
 	   using v4l2-subdev - therefore we can't support that AT ALL right

[PATCH] [36/50] v4l2-ioctl.c: prefill tuner type for g_frequency and

[Andi Kleen]

2.6.35-longterm review patch.  If anyone has any objections, please let me know.

------------------
From: Hans Verkuil <hans.verkuil@cisco.com>

[ upstream commit 227690df75382e46a4f6ea1bbc5df855a674b47f ]
 g/s_tuner

The subdevs are supposed to receive a valid tuner type for the g_frequency
and g/s_tuner subdev ops. Some drivers do this, others don't. So prefill
this in v4l2-ioctl.c based on whether the device node from which this is
called is a radio node or not.

The spec does not require applications to fill in the type, and if they
leave it at 0 then the 'check_mode' call in tuner-core.c will return
an error and the ioctl does nothing.

Cc: stable@kernel.org
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Signed-off-by: Andi Kleen <ak@linux.intel.com>

Index: linux-2.6.35.y/drivers/media/video/v4l2-ioctl.c
===================================================================
--- linux-2.6.35.y.orig/drivers/media/video/v4l2-ioctl.c
+++ linux-2.6.35.y/drivers/media/video/v4l2-ioctl.c
@@ -1644,6 +1644,8 @@ static long __video_do_ioctl(struct file
 		if (!ops->vidioc_g_tuner)
 			break;
 
+		p->type = (vfd->vfl_type == VFL_TYPE_RADIO) ?
+			V4L2_TUNER_RADIO : V4L2_TUNER_ANALOG_TV;
 		ret = ops->vidioc_g_tuner(file, fh, p);
 		if (!ret)
 			dbgarg(cmd, "index=%d, name=%s, type=%d, "
@@ -1662,6 +1664,8 @@ static long __video_do_ioctl(struct file
 
 		if (!ops->vidioc_s_tuner)
 			break;
+		p->type = (vfd->vfl_type == VFL_TYPE_RADIO) ?
+			V4L2_TUNER_RADIO : V4L2_TUNER_ANALOG_TV;
 		dbgarg(cmd, "index=%d, name=%s, type=%d, "
 				"capability=0x%x, rangelow=%d, "
 				"rangehigh=%d, signal=%d, afc=%d, "
@@ -1680,6 +1684,8 @@ static long __video_do_ioctl(struct file
 		if (!ops->vidioc_g_frequency)
 			break;
 
+		p->type = (vfd->vfl_type == VFL_TYPE_RADIO) ?
+			V4L2_TUNER_RADIO : V4L2_TUNER_ANALOG_TV;
 		ret = ops->vidioc_g_frequency(file, fh, p);
 		if (!ret)
 			dbgarg(cmd, "tuner=%d, type=%d, frequency=%d\n",

[PATCH] [37/50] mac80211: fix TKIP replay vulnerability

[Andi Kleen]

2.6.35-longterm review patch.  If anyone has any objections, please let me know.

------------------
From: Johannes Berg <johannes.berg@intel.com>

[ upstream commit 34459512ffa7236c849466e3bd604801389734e1 ]

Unlike CCMP, the presence or absence of the QoS
field doesn't change the encryption, only the
TID is used. When no QoS field is present, zero
is used as the TID value. This means that it is
possible for an attacker to take a QoS packet
with TID 0 and replay it as a non-QoS packet.

Unfortunately, mac80211 uses different IVs for
checking the validity of the packet's TKIP IV
when it checks TID 0 and when it checks non-QoS
packets. This means it is vulnerable to this
replay attack.

To fix this, use the same replay counter for
TID 0 and non-QoS packets by overriding the
rx->queue value to 0 if it is 16 (non-QoS).

This is a minimal fix for now. I caused this
issue in

commit 1411f9b531f0a910cd1c85a337737c1e6ffbae6a
Author: Johannes Berg <johannes@sipsolutions.net>
Date:   Thu Jul 10 10:11:02 2008 +0200

    mac80211: fix RX sequence number check

while fixing a sequence number issue (there,
a separate counter needs to be used).

[AK: This was a non trivial backport. Johannes, John,
please double check]

Cc: stable@kernel.org
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Andi Kleen <ak@linux.intel.com>

Index: linux-2.6.35.y/net/mac80211/wpa.c
===================================================================
--- linux-2.6.35.y.orig/net/mac80211/wpa.c
+++ linux-2.6.35.y/net/mac80211/wpa.c
@@ -89,6 +89,11 @@ ieee80211_rx_h_michael_mic_verify(struct
 	struct ieee80211_rx_status *status = IEEE80211_SKB_RXCB(skb);
 	struct ieee80211_hdr *hdr = (struct ieee80211_hdr *)skb->data;
 	int authenticator = 1, wpa_test = 0;
+	int queue = rx->queue;
+
+	/* otherwise, TKIP is vulnerable to TID 0 vs. non-QoS replays */
+	if (rx->queue == NUM_RX_DATA_QUEUES - 1)
+		queue = 0;
 
 	/* No way to verify the MIC if the hardware stripped it */
 	if (status->flag & RX_FLAG_MMIC_STRIPPED)
@@ -130,8 +135,8 @@ ieee80211_rx_h_michael_mic_verify(struct
 	skb_trim(skb, skb->len - MICHAEL_MIC_LEN);
 
 	/* update IV in key information to be able to detect replays */
-	rx->key->u.tkip.rx[rx->queue].iv32 = rx->tkip_iv32;
-	rx->key->u.tkip.rx[rx->queue].iv16 = rx->tkip_iv16;
+	rx->key->u.tkip.rx[queue].iv32 = rx->tkip_iv32;
+	rx->key->u.tkip.rx[queue].iv16 = rx->tkip_iv16;
 
 	return RX_CONTINUE;
 }
@@ -213,6 +218,11 @@ ieee80211_crypto_tkip_decrypt(struct iee
 	struct ieee80211_key *key = rx->key;
 	struct sk_buff *skb = rx->skb;
 	struct ieee80211_rx_status *status = IEEE80211_SKB_RXCB(skb);
+	int queue = rx->queue;
+
+	/* otherwise, TKIP is vulnerable to TID 0 vs. non-QoS replays */
+	if (rx->queue == NUM_RX_DATA_QUEUES - 1)
+		queue = 0;
 
 	hdrlen = ieee80211_hdrlen(hdr->frame_control);
 
@@ -239,7 +249,7 @@ ieee80211_crypto_tkip_decrypt(struct iee
 	res = ieee80211_tkip_decrypt_data(rx->local->wep_rx_tfm,
 					  key, skb->data + hdrlen,
 					  skb->len - hdrlen, rx->sta->sta.addr,
-					  hdr->addr1, hwaccel, rx->queue,
+					  hdr->addr1, hwaccel, queue,
 					  &rx->tkip_iv32,
 					  &rx->tkip_iv16);
 	if (res != TKIP_DECRYPT_OK || wpa_test)

[PATCH] [38/50] ASoC: ak4642: fixup snd_soc_update_bits mask for PW_MGMT2

[Andi Kleen]

2.6.35-longterm review patch.  If anyone has any objections, please let me know.

------------------
From: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>

[ upstream commit bd7fdbcaa2d06d446577fd3c9b81847b04469e01 ]

mask didn't cover update-data

Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Acked-by: Liam Girdwood <lrg@ti.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Cc: stable@kernel.org
Signed-off-by: Andi Kleen <ak@linux.intel.com>

Index: linux-2.6.35.y/sound/soc/codecs/ak4642.c
===================================================================
--- linux-2.6.35.y.orig/sound/soc/codecs/ak4642.c
+++ linux-2.6.35.y/sound/soc/codecs/ak4642.c
@@ -319,7 +319,7 @@ static int ak4642_dai_set_fmt(struct snd
 	default:
 		return -EINVAL;
 	}
-	snd_soc_update_bits(codec, PW_MGMT2, MS, data);
+	snd_soc_update_bits(codec, PW_MGMT2, MS | MCKO | PMPLL, data);
 	snd_soc_update_bits(codec, MD_CTL1, BCKO_MASK, bcko);
 
 	return 0;

[PATCH] [39/50] tracing: Fix bug when reading system filters on module

[Andi Kleen]

2.6.35-longterm review patch.  If anyone has any objections, please let me know.

------------------
From: Steven Rostedt <srostedt@redhat.com>

[ upstream commit e9dbfae53eeb9fc3d4bb7da3df87fa9875f5da02 ]
 removal

The event system is freed when its nr_events is set to zero. This happens
when a module created an event system and then later the module is
removed. Modules may share systems, so the system is allocated when
it is created and freed when the modules are unloaded and all the
events under the system are removed (nr_events set to zero).

The problem arises when a task opened the "filter" file for the
system. If the module is unloaded and it removed the last event for
that system, the system structure is freed. If the task that opened
the filter file accesses the "filter" file after the system has
been freed, the system will access an invalid pointer.

By adding a ref_count, and using it to keep track of what
is using the event system, we can free it after all users
are finished with the event system.

Cc: <stable@kernel.org>
Reported-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
Signed-off-by: Andi Kleen <ak@linux.intel.com>

Index: linux-2.6.35.y/kernel/trace/trace.h
===================================================================
--- linux-2.6.35.y.orig/kernel/trace/trace.h
+++ linux-2.6.35.y/kernel/trace/trace.h
@@ -731,6 +731,7 @@ struct event_subsystem {
 	struct dentry		*entry;
 	struct event_filter	*filter;
 	int			nr_events;
+	int			ref_count;
 };
 
 struct filter_pred;
Index: linux-2.6.35.y/kernel/trace/trace_events.c
===================================================================
--- linux-2.6.35.y.orig/kernel/trace/trace_events.c
+++ linux-2.6.35.y/kernel/trace/trace_events.c
@@ -182,6 +182,35 @@ static void ftrace_clear_events(void)
 	mutex_unlock(&event_mutex);
 }
 
+static void __put_system(struct event_subsystem *system)
+{
+	struct event_filter *filter = system->filter;
+
+	WARN_ON_ONCE(system->ref_count == 0);
+	if (--system->ref_count)
+		return;
+
+	if (filter) {
+		kfree(filter->filter_string);
+		kfree(filter);
+	}
+	kfree(system->name);
+	kfree(system);
+}
+
+static void __get_system(struct event_subsystem *system)
+{
+	WARN_ON_ONCE(system->ref_count == 0);
+	system->ref_count++;
+}
+
+static void put_system(struct event_subsystem *system)
+{
+	mutex_lock(&event_mutex);
+	__put_system(system);
+	mutex_unlock(&event_mutex);
+}
+
 /*
  * __ftrace_set_clr_event(NULL, NULL, NULL, set) will set/unset all events.
  */
@@ -704,6 +733,47 @@ event_filter_write(struct file *filp, co
 	return cnt;
 }
 
+static LIST_HEAD(event_subsystems);
+
+static int subsystem_open(struct inode *inode, struct file *filp)
+{
+	struct event_subsystem *system = NULL;
+	int ret;
+
+	/* Make sure the system still exists */
+	mutex_lock(&event_mutex);
+	list_for_each_entry(system, &event_subsystems, list) {
+		if (system == inode->i_private) {
+			/* Don't open systems with no events */
+			if (!system->nr_events) {
+				system = NULL;
+				break;
+			}
+			__get_system(system);
+			break;
+		}
+	}
+	mutex_unlock(&event_mutex);
+
+	if (system != inode->i_private)
+		return -ENODEV;
+
+	ret = tracing_open_generic(inode, filp);
+	if (ret < 0)
+		put_system(system);
+
+	return ret;
+}
+
+static int subsystem_release(struct inode *inode, struct file *file)
+{
+	struct event_subsystem *system = inode->i_private;
+
+	put_system(system);
+
+	return 0;
+}
+
 static ssize_t
 subsystem_filter_read(struct file *filp, char __user *ubuf, size_t cnt,
 		      loff_t *ppos)
@@ -836,9 +906,10 @@ static const struct file_operations ftra
 };
 
 static const struct file_operations ftrace_subsystem_filter_fops = {
-	.open = tracing_open_generic,
+	.open = subsystem_open,
 	.read = subsystem_filter_read,
 	.write = subsystem_filter_write,
+	.release = subsystem_release,
 };
 
 static const struct file_operations ftrace_system_enable_fops = {
@@ -872,8 +943,6 @@ static struct dentry *event_trace_events
 	return d_events;
 }
 
-static LIST_HEAD(event_subsystems);
-
 static struct dentry *
 event_subsystem_dir(const char *name, struct dentry *d_events)
 {
@@ -883,6 +952,7 @@ event_subsystem_dir(const char *name, st
 	/* First see if we did not already create this dir */
 	list_for_each_entry(system, &event_subsystems, list) {
 		if (strcmp(system->name, name) == 0) {
+			__get_system(system);
 			system->nr_events++;
 			return system->entry;
 		}
@@ -905,6 +975,7 @@ event_subsystem_dir(const char *name, st
 	}
 
 	system->nr_events = 1;
+	system->ref_count = 1;
 	system->name = kstrdup(name, GFP_KERNEL);
 	if (!system->name) {
 		debugfs_remove(system->entry);
@@ -1050,16 +1121,9 @@ static void remove_subsystem_dir(const c
 	list_for_each_entry(system, &event_subsystems, list) {
 		if (strcmp(system->name, name) == 0) {
 			if (!--system->nr_events) {
-				struct event_filter *filter = system->filter;
-
 				debugfs_remove_recursive(system->entry);
 				list_del(&system->list);
-				if (filter) {
-					kfree(filter->filter_string);
-					kfree(filter);
-				}
-				kfree(system->name);
-				kfree(system);
+				__put_system(system);
 			}
 			break;
 		}
Index: linux-2.6.35.y/kernel/trace/trace_events_filter.c
===================================================================
--- linux-2.6.35.y.orig/kernel/trace/trace_events_filter.c
+++ linux-2.6.35.y/kernel/trace/trace_events_filter.c
@@ -1340,6 +1340,12 @@ int apply_subsystem_event_filter(struct 
 	if (err)
 		goto out_unlock;
 
+	/* Make sure the system still has events */
+	if (!system->nr_events) {
+		err = -ENODEV;
+		goto out_unlock;
+	}
+
 	if (!strcmp(strstrip(filter_string), "0")) {
 		filter_free_subsystem_preds(system);
 		remove_filter_string(system->filter);

[PATCH] [40/50] tracing: Have "enable" file use refcounts like the "filter"

[Andi Kleen]

2.6.35-longterm review patch.  If anyone has any objections, please let me know.

------------------
From: Steven Rostedt <srostedt@redhat.com>

[ upstream commit 40ee4dffff061399eb9358e0c8fcfbaf8de4c8fe ]
 file

The "enable" file for the event system can be removed when a module
is unloaded and the event system only has events from that module.
As the event system nr_events count goes to zero, it may be freed
if its ref_count is also set to zero.

Like the "filter" file, the "enable" file may be opened by a task and
referenced later, after a module has been unloaded and the events for
that event system have been removed.

Although the "filter" file referenced the event system structure,
the "enable" file only references a pointer to the event system
name. Since the name is freed when the event system is removed,
it is possible that an access to the "enable" file may reference
a freed pointer.

Update the "enable" file to use the subsystem_open() routine that
the "filter" file uses, to keep a reference to the event system
structure while the "enable" file is opened.

Cc: <stable@kernel.org>
Reported-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
Signed-off-by: Andi Kleen <ak@linux.intel.com>

Index: linux-2.6.35.y/kernel/trace/trace_events.c
===================================================================
--- linux-2.6.35.y.orig/kernel/trace/trace_events.c
+++ linux-2.6.35.y/kernel/trace/trace_events.c
@@ -495,7 +495,7 @@ system_enable_read(struct file *filp, ch
 		   loff_t *ppos)
 {
 	const char set_to_char[4] = { '?', '0', '1', 'X' };
-	const char *system = filp->private_data;
+	struct event_subsystem *system = filp->private_data;
 	struct ftrace_event_call *call;
 	char buf[2];
 	int set = 0;
@@ -507,7 +507,7 @@ system_enable_read(struct file *filp, ch
 		    (!call->class->probe && !call->class->reg))
 			continue;
 
-		if (system && strcmp(call->class->system, system) != 0)
+		if (system && strcmp(call->class->system, system->name) != 0)
 			continue;
 
 		/*
@@ -537,7 +537,8 @@ static ssize_t
 system_enable_write(struct file *filp, const char __user *ubuf, size_t cnt,
 		    loff_t *ppos)
 {
-	const char *system = filp->private_data;
+	struct event_subsystem *system = filp->private_data;
+	const char *name = NULL;
 	unsigned long val;
 	char buf[64];
 	ssize_t ret;
@@ -561,7 +562,14 @@ system_enable_write(struct file *filp, c
 	if (val != 0 && val != 1)
 		return -EINVAL;
 
-	ret = __ftrace_set_clr_event(NULL, system, NULL, val);
+	/*
+	 * Opening of "enable" adds a ref count to system,
+	 * so the name is safe to use.
+	 */
+	if (system)
+		name = system->name;
+
+	ret = __ftrace_set_clr_event(NULL, name, NULL, val);
 	if (ret)
 		goto out;
 
@@ -740,6 +748,9 @@ static int subsystem_open(struct inode *
 	struct event_subsystem *system = NULL;
 	int ret;
 
+	if (!inode->i_private)
+		goto skip_search;
+
 	/* Make sure the system still exists */
 	mutex_lock(&event_mutex);
 	list_for_each_entry(system, &event_subsystems, list) {
@@ -758,8 +769,9 @@ static int subsystem_open(struct inode *
 	if (system != inode->i_private)
 		return -ENODEV;
 
+ skip_search:
 	ret = tracing_open_generic(inode, filp);
-	if (ret < 0)
+	if (ret < 0 && system)
 		put_system(system);
 
 	return ret;
@@ -769,7 +781,8 @@ static int subsystem_release(struct inod
 {
 	struct event_subsystem *system = inode->i_private;
 
-	put_system(system);
+	if (system)
+		put_system(system);
 
 	return 0;
 }
@@ -913,9 +926,10 @@ static const struct file_operations ftra
 };
 
 static const struct file_operations ftrace_system_enable_fops = {
-	.open = tracing_open_generic,
+	.open = subsystem_open,
 	.read = system_enable_read,
 	.write = system_enable_write,
+	.release = subsystem_release,
 };
 
 static const struct file_operations ftrace_show_header_fops = {
@@ -1003,8 +1017,7 @@ event_subsystem_dir(const char *name, st
 			   "'%s/filter' entry\n", name);
 	}
 
-	trace_create_file("enable", 0644, system->entry,
-			  (void *)system->name,
+	trace_create_file("enable", 0644, system->entry, system,
 			  &ftrace_system_enable_fops);
 
 	return system->entry;

[PATCH] [41/50] ARM: pxa: fix PGSR register address calculation

[Andi Kleen]

2.6.35-longterm review patch.  If anyone has any objections, please let me know.

------------------
From: Paul Parsons <lost.distance@yahoo.com>

[ upstream commit beb0c9b056b1c23d2029b46a425362e9ccbeba01 ]

The file mfp-pxa2xx.c defines a macro, PGSR(), which translates a gpio
bank number to a PGSR register address. The function pxa2xx_mfp_suspend()
erroneously passed in a gpio number instead of a gpio bank number.

Signed-off-by: Paul Parsons <lost.distance@yahoo.com>
Cc: stable@kernel.org
Signed-off-by: Eric Miao <eric.y.miao@gmail.com>
Signed-off-by: Andi Kleen <ak@linux.intel.com>

Index: linux-2.6.35.y/arch/arm/mach-pxa/mfp-pxa2xx.c
===================================================================
--- linux-2.6.35.y.orig/arch/arm/mach-pxa/mfp-pxa2xx.c
+++ linux-2.6.35.y/arch/arm/mach-pxa/mfp-pxa2xx.c
@@ -347,9 +347,9 @@ static int pxa2xx_mfp_suspend(struct sys
 		if ((gpio_desc[i].config & MFP_LPM_KEEP_OUTPUT) &&
 		    (GPDR(i) & GPIO_bit(i))) {
 			if (GPLR(i) & GPIO_bit(i))
-				PGSR(i) |= GPIO_bit(i);
+				PGSR(gpio_to_bank(i)) |= GPIO_bit(i);
 			else
-				PGSR(i) &= ~GPIO_bit(i);
+				PGSR(gpio_to_bank(i)) &= ~GPIO_bit(i);
 		}
 	}
 

[PATCH] [42/50] iommu/amd: Don't use MSI address range for DMA addresses

[Andi Kleen]

2.6.35-longterm review patch.  If anyone has any objections, please let me know.

------------------
From: Joerg Roedel <joerg.roedel@amd.com>

[ upstream commit 17f5b569e09cfa3488eaa663cbf9feada2e789f5 ]

Reserve the MSI address range in the address allocator so
that MSI addresses are not handed out as dma handles.

Cc: stable@kernel.org
Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
Signed-off-by: Andi Kleen <ak@linux.intel.com>

Index: linux-2.6.35.y/arch/x86/kernel/amd_iommu.c
===================================================================
--- linux-2.6.35.y.orig/arch/x86/kernel/amd_iommu.c
+++ linux-2.6.35.y/arch/x86/kernel/amd_iommu.c
@@ -25,6 +25,7 @@
 #include <linux/dma-mapping.h>
 #include <linux/iommu-helper.h>
 #include <linux/iommu.h>
+#include <asm/msidef.h>
 #include <asm/proto.h>
 #include <asm/iommu.h>
 #include <asm/gart.h>
@@ -1048,7 +1049,7 @@ static int alloc_new_range(struct dma_op
 {
 	int index = dma_dom->aperture_size >> APERTURE_RANGE_SHIFT;
 	struct amd_iommu *iommu;
-	unsigned long i;
+	unsigned long i, old_size;
 
 #ifdef CONFIG_IOMMU_STRESS
 	populate = false;
@@ -1084,8 +1085,21 @@ static int alloc_new_range(struct dma_op
 		}
 	}
 
+	old_size                = dma_dom->aperture_size;
 	dma_dom->aperture_size += APERTURE_RANGE_SIZE;
 
+	/* Reserve address range used for MSI messages */
+	if (old_size < MSI_ADDR_BASE_LO &&
+	    dma_dom->aperture_size > MSI_ADDR_BASE_LO) {
+		unsigned long spage;
+		int pages;
+
+		pages = iommu_num_pages(MSI_ADDR_BASE_LO, 0x10000, PAGE_SIZE);
+		spage = MSI_ADDR_BASE_LO >> PAGE_SHIFT;
+
+		dma_ops_reserve_addresses(dma_dom, spage, pages);
+	}
+
 	/* Intialize the exclusion range if necessary */
 	for_each_iommu(iommu) {
 		if (iommu->exclusion_start &&

[PATCH] [43/50] staging: r8192e_pci: Handle duplicate PCI ID 0x10ec:0x8192

[Andi Kleen]

2.6.35-longterm review patch.  If anyone has any objections, please let me know.

------------------
From: Larry Finger <Larry.Finger@lwfinger.net>

[ upstream commit 1c50bf7e415cf6ce9545dbecc2ac0d89d3916c53 ]
 conflict with rtl8192se

There are two devices with PCI ID 0x10ec:0x8192, namely RTL8192E and
RTL8192SE. The method of distinguishing them is by the revision ID
at offset 0x8 of the PCI configuration space. If the value is 0x10,
then the device uses rtl8192se for a driver.

Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Cc: Stable <stable@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Andi Kleen <ak@linux.intel.com>

Index: linux-2.6.35.y/drivers/staging/rtl8192e/r8192E_core.c
===================================================================
--- linux-2.6.35.y.orig/drivers/staging/rtl8192e/r8192E_core.c
+++ linux-2.6.35.y/drivers/staging/rtl8192e/r8192E_core.c
@@ -6334,6 +6334,7 @@ static int __devinit rtl8192_pci_probe(s
 	struct net_device *dev = NULL;
 	struct r8192_priv *priv= NULL;
 	u8 unit = 0;
+	u8 revisionid;
 
 #ifdef CONFIG_RTL8192_IO_MAP
 	unsigned long pio_start, pio_len, pio_flags;
@@ -6423,6 +6424,11 @@ static int __devinit rtl8192_pci_probe(s
          pci_write_config_byte(pdev, 0x41, 0x00);
 
 
+	pci_read_config_byte(pdev, 0x08, &revisionid);
+	/* If the revisionid is 0x10, the device uses rtl8192se. */
+	if (pdev->device == 0x8192 && revisionid == 0x10)
+		goto fail1;
+
 	pci_read_config_byte(pdev, 0x05, &unit);
 	pci_write_config_byte(pdev, 0x05, unit & (~0x04));
 

[PATCH] [44/50] staging: comedi: fix infoleak to userspace

[Andi Kleen]

2.6.35-longterm review patch.  If anyone has any objections, please let me know.

------------------
From: Vasiliy Kulikov <segoon@openwall.com>

[ upstream commit 819cbb120eaec7e014e5abd029260db1ca8c5735 ]

driver_name and board_name are pointers to strings, not buffers of size
COMEDI_NAMELEN.  Copying COMEDI_NAMELEN bytes of a string containing
less than COMEDI_NAMELEN-1 bytes would leak some unrelated bytes.

Signed-off-by: Vasiliy Kulikov <segoon@openwall.com>
Cc: stable <stable@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Andi Kleen <ak@linux.intel.com>

Index: linux-2.6.35.y/drivers/staging/comedi/comedi_fops.c
===================================================================
--- linux-2.6.35.y.orig/drivers/staging/comedi/comedi_fops.c
+++ linux-2.6.35.y/drivers/staging/comedi/comedi_fops.c
@@ -383,8 +383,8 @@ static int do_devinfo_ioctl(struct comed
 	/* fill devinfo structure */
 	devinfo.version_code = COMEDI_VERSION_CODE;
 	devinfo.n_subdevs = dev->n_subdevices;
-	memcpy(devinfo.driver_name, dev->driver->driver_name, COMEDI_NAMELEN);
-	memcpy(devinfo.board_name, dev->board_name, COMEDI_NAMELEN);
+	strlcpy(devinfo.driver_name, dev->driver->driver_name, COMEDI_NAMELEN);
+	strlcpy(devinfo.board_name, dev->board_name, COMEDI_NAMELEN);
 
 	if (read_subdev)
 		devinfo.read_subdevice = read_subdev - dev->subdevices;

[PATCH] [45/50] Staging: hv: netvsc: Fix a bug in accounting transmit slots

[Andi Kleen]

2.6.35-longterm review patch.  If anyone has any objections, please let me know.

------------------
From: K. Y. Srinivasan <kys@microsoft.com>

[ upstream commit 9079ce691255792009c446d8c3382507b8d38635 ]

The transmit slots were manipulated without proper locking. Fix this bug by
making the variable tracking the transmit slots atomic.

This patch should be ported to prior stable kernels 2.6.32 and later.

Signed-off-by: K. Y. Srinivasan <kys@microsoft.com>
Signed-off-by: Haiyang Zhang <haiyangz@microsoft.com>
Signed-off-by: Hank Janssen <hjanssen@microsoft.com>
Cc: stable <stable@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Andi Kleen <ak@linux.intel.com>

Index: linux-2.6.35.y/drivers/staging/hv/netvsc_drv.c
===================================================================
--- linux-2.6.35.y.orig/drivers/staging/hv/netvsc_drv.c
+++ linux-2.6.35.y/drivers/staging/hv/netvsc_drv.c
@@ -19,6 +19,7 @@
  *   Hank Janssen  <hjanssen@microsoft.com>
  */
 #include <linux/init.h>
+#include <linux/atomic.h>
 #include <linux/module.h>
 #include <linux/highmem.h>
 #include <linux/device.h>
@@ -45,7 +46,7 @@
 struct net_device_context {
 	/* point back to our device context */
 	struct vm_device *device_ctx;
-	unsigned long avail;
+	atomic_t avail;
 	struct work_struct work;
 };
 
@@ -133,7 +134,9 @@ static void netvsc_xmit_completion(void 
 
 		dev_kfree_skb_any(skb);
 
-		if ((net_device_ctx->avail += num_pages) >= PACKET_PAGES_HIWATER)
+		atomic_add(num_pages, &net_device_ctx->avail);
+		if (atomic_read(&net_device_ctx->avail) >=
+				PACKET_PAGES_HIWATER)
  			netif_wake_queue(net);
 	}
 
@@ -159,7 +162,7 @@ static int netvsc_start_xmit(struct sk_b
 
 	/* Add 1 for skb->data and additional one for RNDIS */
 	num_pages = skb_shinfo(skb)->nr_frags + 1 + 1;
-	if (num_pages > net_device_ctx->avail)
+	if (num_pages > atomic_read(&net_device_ctx->avail))
 		return NETDEV_TX_BUSY;
 
 	/* Allocate a netvsc packet based on # of frags. */
@@ -218,7 +221,8 @@ static int netvsc_start_xmit(struct sk_b
 			   net->stats.tx_packets,
 			   net->stats.tx_bytes);
 
-		if ((net_device_ctx->avail -= num_pages) < PACKET_PAGES_LOWATER)
+		atomic_sub(num_pages, &net_device_ctx->avail);
+		if (atomic_read(&net_device_ctx->avail) < PACKET_PAGES_LOWATER)
 			netif_stop_queue(net);
 	} else {
 		/* we are shutting down or bus overloaded, just drop packet */
@@ -406,7 +410,7 @@ static int netvsc_probe(struct device *d
 
 	net_device_ctx = netdev_priv(net);
 	net_device_ctx->device_ctx = device_ctx;
-	net_device_ctx->avail = ring_size;
+	atomic_set(&net_device_ctx->avail, ring_size);
 	dev_set_drvdata(device, net);
 	INIT_WORK(&net_device_ctx->work, netvsc_send_garp);
 

[PATCH] [46/50] ARM: 6989/1: perf: do not start the PMU when no events are

[Andi Kleen]

2.6.35-longterm review patch.  If anyone has any objections, please let me know.

------------------
From: Will Deacon <will.deacon@arm.com>

[ upstream commit f4f38430c94c38187db73a2cf3892cc8b12a2713 ]
 present

armpmu_enable can be called in situations where no events are present
(for example, from the event rotation tick after a profiled task has
exited). In this case, we currently start the PMU anyway which may
leave it active inevitably without any events being monitored.

This patch adds a simple check to the enabling code so that we avoid
starting the PMU when no events are present.

Cc: <stable@kernel.org>
Reported-by: Ashwin Chaugle <ashwinc@codeaurora.org>
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: Andi Kleen <ak@linux.intel.com>

Index: linux-2.6.35.y/arch/arm/kernel/perf_event.c
===================================================================
--- linux-2.6.35.y.orig/arch/arm/kernel/perf_event.c
+++ linux-2.6.35.y/arch/arm/kernel/perf_event.c
@@ -531,7 +531,7 @@ void
 hw_perf_enable(void)
 {
 	/* Enable all of the perf events on hardware. */
-	int idx;
+	int idx, enabled = 0;
 	struct cpu_hw_events *cpuc = &__get_cpu_var(cpu_hw_events);
 
 	if (!armpmu)
@@ -544,9 +544,11 @@ hw_perf_enable(void)
 			continue;
 
 		armpmu->enable(&event->hw, idx);
+		enabled = 1;
 	}
 
-	armpmu->start();
+	if (enabled)
+		armpmu->start();
 }
 
 void

[PATCH] [47/50] ASoC: Ensure we delay long enough for WM8994 FLL to lock

[Andi Kleen]

2.6.35-longterm review patch.  If anyone has any objections, please let me know.

------------------
From: Mark Brown <broonie@opensource.wolfsonmicro.com>

[ upstream commit 8e9ddf811ba021506d2316fcfe619faa0ab3f567 ]
 when starting

This delay is very conservative.

Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Acked-by: Liam Girdwood <lrg@ti.com>
Cc: stable@kernel.org
Signed-off-by: Andi Kleen <ak@linux.intel.com>

Index: linux-2.6.35.y/sound/soc/codecs/wm8994.c
===================================================================
--- linux-2.6.35.y.orig/sound/soc/codecs/wm8994.c
+++ linux-2.6.35.y/sound/soc/codecs/wm8994.c
@@ -2929,6 +2929,8 @@ static int wm8994_set_fll(struct snd_soc
 		snd_soc_update_bits(codec, WM8994_FLL1_CONTROL_1 + reg_offset,
 				    WM8994_FLL1_ENA | WM8994_FLL1_FRAC,
 				    reg);
+
+		msleep(5);
 	}
 
 	wm8994->fll[id].in = freq_in;

[PATCH] [48/50] SERIAL: SC26xx: Fix link error.

[Andi Kleen]

2.6.35-longterm review patch.  If anyone has any objections, please let me know.

------------------
From: Ralf Baechle <ralf@linux-mips.org>

[ upstream commit f2eb3cdf14457fccb14ae8c4d7d7cee088cd3957 ]

Kconfig allows enabling console support for the SC26xx driver even when
it's configured as a module resulting in a:

ERROR: "uart_console_device" [drivers/tty/serial/sc26xx.ko] undefined!

modpost error since the driver was merged in
eea63e0e8a60d00485b47fb6e75d9aa2566b989b [SC26XX: New serial driver for
SC2681 uarts] in 2.6.25.  Fixed by only allowing console support to be
enabled if the driver is builtin.

Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
Cc: linux-serial@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-mips@linux-mips.org
Cc: stable <stable@kernel.org>
Acked-by: Alan Cox <alan@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Andi Kleen <ak@linux.intel.com>

Index: linux-2.6.35.y/drivers/serial/Kconfig
===================================================================
--- linux-2.6.35.y.orig/drivers/serial/Kconfig
+++ linux-2.6.35.y/drivers/serial/Kconfig
@@ -1417,7 +1417,7 @@ config SERIAL_SC26XX
 
 config SERIAL_SC26XX_CONSOLE
 	bool "Console on SC2681/SC2692 serial port"
-	depends on SERIAL_SC26XX
+	depends on SERIAL_SC26XX=y
 	select SERIAL_CORE_CONSOLE
 	help
 	  Support for Console on SC2681/SC2692 serial ports.

[PATCH] [49/50] x86, mtrr: lock stop machine during MTRR rendezvous sequence

[Andi Kleen]

2.6.35-longterm review patch.  If anyone has any objections, please let me know.

------------------
From: Suresh Siddha <suresh.b.siddha@intel.com>

[ upstream commit 6d3321e8e2b3bf6a5892e2ef673c7bf536e3f904 ]

MTRR rendezvous sequence using stop_one_cpu_nowait() can potentially
happen in parallel with another system wide rendezvous using
stop_machine(). This can lead to deadlock (The order in which
works are queued can be different on different cpu's. Some cpu's
will be running the first rendezvous handler and others will be running
the second rendezvous handler. Each set waiting for the other set to join
for the system wide rendezvous, leading to a deadlock).

MTRR rendezvous sequence is not implemented using stop_machine() as this
gets called both from the process context aswell as the cpu online paths
(where the cpu has not come online and the interrupts are disabled etc).
stop_machine() works with only online cpus.

For now, take the stop_machine mutex in the MTRR rendezvous sequence that
gets called from an online cpu (here we are in the process context
and can potentially sleep while taking the mutex). And the MTRR rendezvous
that gets triggered during cpu online doesn't need to take this stop_machine
lock (as the stop_machine() already ensures that there is no cpu hotplug
going on in parallel by doing get_online_cpus())

    TBD: Pursue a cleaner solution of extending the stop_machine()
         infrastructure to handle the case where the calling cpu is
         still not online and use this for MTRR rendezvous sequence.

fixes: https://bugzilla.novell.com/show_bug.cgi?id=672008

Reported-by: Vadim Kotelnikov <vadimuzzz@inbox.ru>
Signed-off-by: Suresh Siddha <suresh.b.siddha@intel.com>
Signed-off-by: Andi Kleen <ak@linux.intel.com>
Link: http://lkml.kernel.org/r/20110623182056.807230326@sbsiddha-MOBL3.sc.intel.com
Cc: stable@kernel.org # 2.6.35+, backport a week or two after this gets more testing in mainline
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>

Index: linux-2.6.35.y/arch/x86/kernel/cpu/mtrr/main.c
===================================================================
--- linux-2.6.35.y.orig/arch/x86/kernel/cpu/mtrr/main.c
+++ linux-2.6.35.y/arch/x86/kernel/cpu/mtrr/main.c
@@ -247,6 +247,25 @@ set_mtrr(unsigned int reg, unsigned long
 	unsigned long flags;
 	int cpu;
 
+#ifdef CONFIG_SMP
+	/*
+	 * If this cpu is not yet active, we are in the cpu online path. There
+	 * can be no stop_machine() in parallel, as stop machine ensures this
+	 * by using get_online_cpus(). We can skip taking the stop_cpus_mutex,
+	 * as we don't need it and also we can't afford to block while waiting
+	 * for the mutex.
+	 *
+	 * If this cpu is active, we need to prevent stop_machine() happening
+	 * in parallel by taking the stop cpus mutex.
+	 *
+	 * Also, this is called in the context of cpu online path or in the
+	 * context where cpu hotplug is prevented. So checking the active status
+	 * of the raw_smp_processor_id() is safe.
+	 */
+	if (cpu_active(raw_smp_processor_id()))
+		mutex_lock(&stop_cpus_mutex);
+#endif
+
 	preempt_disable();
 
 	data.smp_reg = reg;
@@ -329,6 +348,10 @@ set_mtrr(unsigned int reg, unsigned long
 
 	local_irq_restore(flags);
 	preempt_enable();
+#ifdef CONFIG_SMP
+	if (cpu_active(raw_smp_processor_id()))
+		mutex_unlock(&stop_cpus_mutex);
+#endif
 }
 
 /**
Index: linux-2.6.35.y/include/linux/stop_machine.h
===================================================================
--- linux-2.6.35.y.orig/include/linux/stop_machine.h
+++ linux-2.6.35.y/include/linux/stop_machine.h
@@ -27,6 +27,8 @@ struct cpu_stop_work {
 	struct cpu_stop_done	*done;
 };
 
+extern struct mutex stop_cpus_mutex;
+
 int stop_one_cpu(unsigned int cpu, cpu_stop_fn_t fn, void *arg);
 void stop_one_cpu_nowait(unsigned int cpu, cpu_stop_fn_t fn, void *arg,
 			 struct cpu_stop_work *work_buf);
Index: linux-2.6.35.y/kernel/stop_machine.c
===================================================================
--- linux-2.6.35.y.orig/kernel/stop_machine.c
+++ linux-2.6.35.y/kernel/stop_machine.c
@@ -132,8 +132,8 @@ void stop_one_cpu_nowait(unsigned int cp
 	cpu_stop_queue_work(&per_cpu(cpu_stopper, cpu), work_buf);
 }
 
+DEFINE_MUTEX(stop_cpus_mutex);
 /* static data for stop_cpus */
-static DEFINE_MUTEX(stop_cpus_mutex);
 static DEFINE_PER_CPU(struct cpu_stop_work, stop_cpus_work);
 
 int __stop_cpus(const struct cpumask *cpumask, cpu_stop_fn_t fn, void *arg)

[PATCH] [50/50] ipv6: add special mode forwarding=2 to send RS while

[Andi Kleen]

2.6.35-longterm review patch.  If anyone has any objections, please let me know.

------------------
From: Thomas Graf <tgraf@infradead.org>

[ upstream commit c3bccac2fa76f1619dfe4fb7b9bee69de7f066d8 ]
 configured as router

Similar to accepting router advertisement, the IPv6 stack does not send router
solicitations if forwarding is enabled.

This patch enables this behavior to be overruled by setting forwarding to the
special value 2.

Signed-off-by: Thomas Graf <tgraf@infradead.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Andi Kleen <ak@linux.intel.com>

Index: linux-2.6.35.y/net/ipv6/addrconf.c
===================================================================
--- linux-2.6.35.y.orig/net/ipv6/addrconf.c
+++ linux-2.6.35.y/net/ipv6/addrconf.c
@@ -2960,7 +2960,8 @@ static void addrconf_dad_completed(struc
 	   start sending router solicitations.
 	 */
 
-	if (ifp->idev->cnf.forwarding == 0 &&
+	if ((ifp->idev->cnf.forwarding == 0 ||
+	     ifp->idev->cnf.forwarding == 2) &&
 	    ifp->idev->cnf.rtr_solicits > 0 &&
 	    (dev->flags&IFF_LOOPBACK) == 0 &&
 	    (ipv6_addr_type(&ifp->addr) & IPV6_ADDR_LINKLOCAL)) {

Re: [PATCH] [9/50] mmc: Added quirks for Ricoh 1180:e823 lower base clock

[matsumur]

Dear Sir,

Ricoh 1180:e823 device is named R5U220/R5U232 (2 devices have the same
device ID ).
So, I think it should be declared to as PCI_DEVICE_ID_RICOH_R5U220.

BTW, does anyone know whether the current SDHCI-driver sets 200Mhz to
SD-CLK for UHS-I cards ?


Thanks,

Koji Matsumuro
Ricoh Company,Ltd.




                                                                           
             Andi Kleen                                                    
             <andi@firstfloor.                                             
             org>                                                     宛先 
                                        manoj.iyer@canonical.com,          
             2011/07/29 08:44           daniel.manrique@canonical.com,     
                                        Koji Matsumuro/R/RICOH@RICOH,      
                                        jbarnes@virtuousgeek.org,          
                                        cjb@laptop.org,                    
                                        ak@linux.intel.com,                
                                        linux-kernel@vger.kernel.org,      
                                        stable@kernel.org,                 
                                        tim.bird@am.sony.com               
                                                                        cc 
                                                                           
                                                                      件名 
                                        [PATCH] [9/50] mmc: Added quirks   
                                        for Ricoh 1180:e823 lower base     
                                        clock                              
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           



2.6.35-longterm review patch.  If anyone has any objections, please let me
know.

------------------
From: Manoj Iyer <manoj.iyer@canonical.com>

[ upstream commit 15bed0f2fa8e1d7db201692532c210a7823d2d21 ]
 frequency

Ricoh 1180:e823 does not recognize certain types of SD/MMC cards,
as reported at http://launchpad.net/bugs/773524.  Lowering the SD
base clock frequency from 200Mhz to 50Mhz fixes this issue. This
solution was suggest by Koji Matsumuro, Ricoh Company, Ltd.

This change has no negative performance effect on standard SD
cards, though it's quite possible that there will be one on
UHS-1 cards.

Signed-off-by: Manoj Iyer <manoj.iyer@canonical.com>
Tested-by: Daniel Manrique <daniel.manrique@canonical.com>
Cc: Koji Matsumuro <matsumur@nts.ricoh.co.jp>
Cc: <stable@kernel.org>
Acked-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Chris Ball <cjb@laptop.org>
Signed-off-by: Andi Kleen <ak@linux.intel.com>

Index: linux-2.6.35.y/drivers/pci/quirks.c
===================================================================
--- linux-2.6.35.y.orig/drivers/pci/quirks.c
+++ linux-2.6.35.y/drivers/pci/quirks.c
@@ -2698,6 +2698,29 @@ static void ricoh_mmc_fixup_r5c832(struc

  dev_notice(&dev->dev, "proprietary Ricoh MMC controller disabled (via
  firewire function)\n");
  dev_notice(&dev->dev, "MMC cards are now supported by standard SDHCI
  controller\n");
+
+     /*
+      * RICOH 0xe823 SD/MMC card reader fails to recognize
+      * certain types of SD/MMC cards. Lowering the SD base
+      * clock frequency from 200Mhz to 50Mhz fixes this issue.
+      *
+      * 0x150 - SD2.0 mode enable for changing base clock
+      *       frequency to 50Mhz
+      * 0xe1  - Base clock frequency
+      * 0x32  - 50Mhz new clock frequency
+      * 0xf9  - Key register for 0x150
+      * 0xfc  - key register for 0xe1
+      */
+     if (dev->device == PCI_DEVICE_ID_RICOH_R5CE823) {
+           pci_write_config_byte(dev, 0xf9, 0xfc);
+           pci_write_config_byte(dev, 0x150, 0x10);
+           pci_write_config_byte(dev, 0xf9, 0x00);
+           pci_write_config_byte(dev, 0xfc, 0x01);
+           pci_write_config_byte(dev, 0xe1, 0x32);
+           pci_write_config_byte(dev, 0xfc, 0x00);
+
+           dev_notice(&dev->dev, "MMC controller base frequency changed to
50Mhz.\n");
+     }
 }
 DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_RICOH, PCI_DEVICE_ID_RICOH_R5C832,
 ricoh_mmc_fixup_r5c832);
 DECLARE_PCI_FIXUP_RESUME_EARLY(PCI_VENDOR_ID_RICOH,
 PCI_DEVICE_ID_RICOH_R5C832, ricoh_mmc_fixup_r5c832);

Re: [PATCH] [9/50] mmc: Added quirks for Ricoh 1180:e823 lower base clock

[Andi Kleen]

On Fri, Jul 29, 2011 at 09:27:56AM +0900, matsumur@nts.ricoh.co.jp wrote:
> Dear Sir,
> 
> Ricoh 1180:e823 device is named R5U220/R5U232 (2 devices have the same
> device ID ).
> So, I think it should be declared to as PCI_DEVICE_ID_RICOH_R5U220.

Is that just the wrong name or will it actually cause misfunction?

I will keep it if it's just the wrong name, but the name should be probably
fixed upstream.

-Andi

Re: [PATCH] [9/50] mmc: Added quirks for Ricoh 1180:e823 lower base clock

[matsumur]

It's no misfunction. Just the wrong name.

Koji Matsumuro

Andi Kleen <andi@firstfloor.org> wrote on 2011/07/29 09:37:03:

> On Fri, Jul 29, 2011 at 09:27:56AM +0900, matsumur@nts.ricoh.co.jp wrote:
> > Dear Sir,
> >
> > Ricoh 1180:e823 device is named R5U220/R5U232 (2 devices have the same
> > device ID ).
> > So, I think it should be declared to as PCI_DEVICE_ID_RICOH_R5U220.

> Is that just the wrong name or will it actually cause misfunction?

> I will keep it if it's just the wrong name, but the name should be
probably
> fixed upstream.

> -Andi

Re: [PATCH] [9/50] mmc: Added quirks for Ricoh 1180:e823 lower base clock

[Chris Ball]

Hi,

On Thu, Jul 28 2011, Andi Kleen wrote:
> On Fri, Jul 29, 2011 at 09:27:56AM +0900, matsumur@nts.ricoh.co.jp wrote:
>> Dear Sir,
>> 
>> Ricoh 1180:e823 device is named R5U220/R5U232 (2 devices have the same
>> device ID ).
>> So, I think it should be declared to as PCI_DEVICE_ID_RICOH_R5U220.
>
> Is that just the wrong name or will it actually cause misfunction?

I don't think it could possibly cause misfunction; it's just a macro name.

> BTW, does anyone know whether the current SDHCI-driver sets 200Mhz to
> SD-CLK for UHS-I cards ?

The Linux 3.1 SD driver will set the SD-CLK to 50MHz for every card on an
e823 device, and older kernels will do so too once the commit has been
applied to the stable trees.  See this commit:

http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=15bed0f2fa8e1d7db201692532c210a7823d2d21

Do you know of a better solution than always lowering the clock speed to
50MHz for this controller?

Thanks,

- Chris.
-- 
Chris Ball   <cjb@laptop.org>   <http://printf.net/>
One Laptop Per Child

Re: [PATCH] [9/50] mmc: Added quirks for Ricoh 1180:e823 lower base clock

[matsumur]

Hi Chris,

> Do you know of a better solution than always lowering the clock speed to
> 50MHz for this controller?

Yes, it is a better solution.
As you know, SD ver.1.1 and 2.0(SDHC) cards can be applied 50MHz SD-CLK..
SD 3.0 (UHS-I) cards also can be applied 50Mhz. However UHS-I cards are
available 200 or 100Mhz SD-CLK.
I would like to know if the current SD Host driver has the function of
setting SD-CLK to 200Mhz for SD ver3.0 compliant Host Controller.


Thanks,


Koji Matsumuro
Ricoh Company,Ltd.


Chris Ball <cjb@laptop.org> wrote on 2011/07/29 09:47:53:

> Hi,

> On Thu, Jul 28 2011, Andi Kleen wrote:
> > On Fri, Jul 29, 2011 at 09:27:56AM +0900, matsumur@nts.ricoh.co.jp
wrote:
> >> Dear Sir,
> >>
> >> Ricoh 1180:e823 device is named R5U220/R5U232 (2 devices have the same
> >> device ID ).
> >> So, I think it should be declared to as PCI_DEVICE_ID_RICOH_R5U220.
> >
> > Is that just the wrong name or will it actually cause misfunction?

> I don't think it could possibly cause misfunction; it's just a macro
name.

> > BTW, does anyone know whether the current SDHCI-driver sets 200Mhz to
> > SD-CLK for UHS-I cards ?

> The Linux 3.1 SD driver will set the SD-CLK to 50MHz for every card on an
> e823 device, and older kernels will do so too once the commit has been
> applied to the stable trees.  See this commit:

> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;
> a=commitdiff;h=15bed0f2fa8e1d7db201692532c210a7823d2d21

> Do you know of a better solution than always lowering the clock speed to
> 50MHz for this controller?

> Thanks,

> - Chris.
> --
> Chris Ball   <cjb@laptop.org>   <http://printf.net/>
> One Laptop Per Child

Re: [PATCH] [9/50] mmc: Added quirks for Ricoh 1180:e823 lower base clock

[Chris Ball]

Hi,

On Thu, Jul 28 2011, matsumur@nts.ricoh.co.jp wrote:
> As you know, SD ver.1.1 and 2.0(SDHC) cards can be applied 50MHz SD-CLK..
> SD 3.0 (UHS-I) cards also can be applied 50Mhz. However UHS-I cards are
> available 200 or 100Mhz SD-CLK.
> I would like to know if the current SD Host driver has the function of
> setting SD-CLK to 200Mhz for SD ver3.0 compliant Host Controller.

Yes, we normally would set the higher clock rates for SDv3 controllers.
We are only restricting to 50MHz on this Ricoh 0xe823 controller.

We added support for the SDR104 UHS-1 speeds in Linux 3.0, thanks to
a patchset from Arindam Nath.

Thanks,

- Chris.
-- 
Chris Ball   <cjb@laptop.org>   <http://printf.net/>
One Laptop Per Child