Makefile | 2 arch/x86/kernel/cpu/amd.c | 2 arch/x86/kernel/reboot_32.S | 12 +- arch/x86/mm/numa_64.c | 2 arch/x86/xen/mmu.c | 125 ++++++++++++++++++++++++++++++- drivers/gpu/drm/drm_irq.c | 23 +++++ drivers/gpu/drm/radeon/evergreen.c | 17 ++-- drivers/gpu/drm/radeon/evergreend.h | 5 + drivers/gpu/drm/radeon/radeon_atombios.c | 5 - drivers/gpu/drm/radeon/radeon_kms.c | 3 drivers/input/touchscreen/wm831x-ts.c | 75 +++++++++++++++--- drivers/mmc/core/bus.c | 1 drivers/mmc/core/host.c | 9 -- drivers/mmc/host/omap.c | 2 drivers/mmc/host/sdhci-pci.c | 1 drivers/mmc/host/sdhci.c | 9 +- drivers/mmc/host/tmio_mmc_pio.c | 10 +- fs/logfs/super.c | 8 - include/drm/drm_pciids.h | 5 + include/drm/radeon_drm.h | 1 include/linux/mfd/wm831x/pdata.h | 2 include/linux/mmc/host.h | 1 kernel/irq/proc.c | 2 23 files changed, 273 insertions(+), 49 deletions(-)
New commits: commit 0ee5623f9a6e52df90a78bd21179f8ab370e102e Author: Linus Torvalds <[email protected]> Date: Tue May 3 19:59:13 2011 -0700 Linux 2.6.39-rc6 commit 8aeb96f80232e9a701b5c4715504f4c9173978bd Author: Alex Deucher <[email protected]> Date: Tue May 3 19:28:02 2011 -0400 drm/radeon/kms: fix gart setup on fusion parts (v2) Out of the entire GART/VM subsystem, the hw designers changed the location of 3 regs. v2: airlied: add parameter for userspace to work from. Signed-off-by: Alex Deucher <[email protected]> Signed-off-by: Jerome Glisse <[email protected]> Cc: [email protected] Signed-off-by: Dave Airlie <[email protected]> commit 498548ec69c6897fe4376b2ca90758762fa0b817 Author: Christopher James Halse Rogers <[email protected]> Date: Wed Apr 27 16:10:57 2011 +1000 drm: Send pending vblank events before disabling vblank. This is the least-bad behaviour. It means that we signal the vblank event before it actually happens, but since we're disabling vblanks there's no guarantee that it will *ever* happen otherwise. This prevents GL applications which use WaitMSC from hanging indefinitely. Signed-off-by: Christopher James Halse Rogers <[email protected]> Signed-off-by: Dave Airlie <[email protected]> commit eaa4f5e1d0b816291a59a47917e569c0384f2b6f Author: Dave Airlie <[email protected]> Date: Sun May 1 20:16:30 2011 +1000 drm/radeon: fix regression on atom cards with hardcoded EDID record. Since fafcf94e2b5732d1e13b440291c53115d2b172e9 introduced an edid size, it seems to have broken this path. This manifest as oops on T500 Lenovo laptops with dual graphics primarily. Fixes: https://bugzilla.kernel.org/show_bug.cgi?id3812 cc: [email protected] Reviewed-by: Alex Deucher <[email protected]> Signed-off-by: Dave Airlie <[email protected]> commit e2c85d8e3974c9041ad7b080846b28d2243e771b Author: Alex Deucher <[email protected]> Date: Tue May 3 15:15:55 2011 -0400 drm/radeon/kms: add some new pci ids Signed-off-by: Alex Deucher <[email protected]> Cc: [email protected] Signed-off-by: Dave Airlie <[email protected]> commit cce2c56e7666199916525907dc817209dd58287c Author: Linus Torvalds <[email protected]> Date: Tue May 3 16:10:25 2011 -0700 logfs: initialize superblock entries earlier In particular, s_freeing_list needs to be initialized early, since it is used on some of the error paths when mounts fail. The mapping inode, for example, would be initialized and then free'd on an error path before s_freeing_list was initialized, but the inode drop operation needs the s_freeing_list to be set up. Normally you'd never see this, because not only is logfs fairly rare, but a successful mount will never have any issues. Reported-by: werner <[email protected]> Signed-off-by: Linus Torvalds <[email protected]> commit 7806a49ab625ebeb1709e5e87299b64932b807a7 Author: H. Peter Anvin <[email protected]> Date: Mon May 2 14:33:24 2011 -0700 x86, reboot: Fix relocations in reboot_32.S The use of base for %ebx in this file is arbitrary, *except* that we also use it to compute the real-mode segment. Therefore, make it so that r_base really is the true address to which %ebx points. This resolves kernel bugzilla 33302. Reported-and-tested-by: Alexey Zaytsev <[email protected]> Signed-off-by: H. Peter Anvin <[email protected]> Link: http://lkml.kernel.org/n/[email protected] commit b9269dc7bfdf8c985971c09f2dcb2aa04ad7986d Author: Stefano Stabellini <[email protected]> Date: Tue Apr 12 12:19:49 2011 +0100 xen: mask_rw_pte mark RO all pagetable pages up to pgt_buf_top mask_rw_pte is currently checking if a pfn is a pagetable page if it falls in the range pgt_buf_start - pgt_buf_end but that is incorrect because pgt_buf_end is a moving target: pgt_buf_top is the real boundary. Acked-by: "H. Peter Anvin" <[email protected]> Signed-off-by: Stefano Stabellini <[email protected]> Signed-off-by: Konrad Rzeszutek Wilk <[email protected]> commit a38647837a411f7df79623128421eef2118b5884 Author: Konrad Rzeszutek Wilk <[email protected]> Date: Fri Apr 29 11:34:00 2011 -0400 xen/mmu: Add workaround "x86-64, mm: Put early page table high" As a consequence of the commit: commit 4b239f458c229de044d6905c2b0f9fe16ed9e01e Author: Yinghai Lu <[email protected]> Date: Fri Dec 17 16:58:28 2010 -0800 x86-64, mm: Put early page table high it causes the Linux kernel to crash under Xen: mapping kernel into physical memory Xen: setup ISA identity maps about to get started... (XEN) mm.c:2466:d0 Bad type (saw 7400000000000001 != exp 1000000000000000) for mfn b1d89 (pfn bacf7) (XEN) mm.c:3027:d0 Error while pinning mfn b1d89 (XEN) traps.c:481:d0 Unhandled invalid opcode fault/trap [#6] on VCPU 0 [ec 00] (XEN) domain_crash_sync called from entry.S (XEN) Domain 0 (vcpu#0) crashed on cpu#0: ... The reason is that at some point init_memory_mapping is going to reach the pagetable pages area and map those pages too (mapping them as normal memory that falls in the range of addresses passed to init_memory_mapping as argument). Some of those pages are already pagetable pages (they are in the range pgt_buf_start-pgt_buf_end) therefore they are going to be mapped RO and everything is fine. Some of these pages are not pagetable pages yet (they fall in the range pgt_buf_end-pgt_buf_top; for example the page at pgt_buf_end) so they are going to be mapped RW. When these pages become pagetable pages and are hooked into the pagetable, xen will find that the guest has already a RW mapping of them somewhere and fail the operation. The reason Xen requires pagetables to be RO is that the hypervisor needs to verify that the pagetables are valid before using them. The validation operations are called "pinning" (more details in arch/x86/xen/mmu.c). In order to fix the issue we mark all the pages in the entire range pgt_buf_start-pgt_buf_top as RO, however when the pagetable allocation is completed only the range pgt_buf_start-pgt_buf_end is reserved by init_memory_mapping. Hence the kernel is going to crash as soon as one of the pages in the range pgt_buf_end-pgt_buf_top is reused (b/c those ranges are RO). For this reason, this function is introduced which is called _after_ the init_memory_mapping has completed (in a perfect world we would call this function from init_memory_mapping, but lets ignore that). Because we are called _after_ init_memory_mapping the pgt_buf_[start, end,top] have all changed to new values (b/c another init_memory_mapping is called). Hence, the first time we enter this function, we save away the pgt_buf_start value and update the pgt_buf_[end,top]. When we detect that the "old" pgt_buf_start through pgt_buf_end PFNs have been reserved (so memblock_x86_reserve_range has been called), we immediately set out to RW the "old" pgt_buf_end through pgt_buf_top. And then we update those "old" pgt_buf_[end|top] with the new ones so that we can redo this on the next pagetable. Acked-by: "H. Peter Anvin" <[email protected]> Reviewed-by: Jeremy Fitzhardinge <[email protected]> [v1: Updated with Jeremy's comments] [v2: Added the crash output] Signed-off-by: Konrad Rzeszutek Wilk <[email protected]> commit 94b2c363dcf732a4edab4ed66041cb36e7f28fbf Author: Geert Uytterhoeven <[email protected]> Date: Sat Apr 30 22:56:20 2011 +0200 genirq: Fix typo CONFIG_GENIRC_IRQ_SHOW_LEVEL commit ab7798ffcf98b11a9525cf65bacdae3fd58d357f ("genirq: Expand generic show_interrupts()") added the Kconfig option GENERIC_IRQ_SHOW_LEVEL to accomodate PowerPC, but this doesn't actually enable the functionality due to a typo in the #ifdef check. Signed-off-by: Geert Uytterhoeven <[email protected]> Cc: Linux/PPC Development <[email protected]> Link: http://lkml.kernel.org/r/%3Calpine.DEB.2.00.1104302251370.19068%40ayla.of.borg%3E Signed-off-by: Thomas Gleixner <[email protected]> commit 2be19102b71c1a45d37fec50303791daa1a06869 Author: Yinghai Lu <[email protected]> Date: Sun May 1 19:12:04 2011 +0200 x86, NUMA: Fix empty memblk detection in numa_cleanup_meminfo() numa_cleanup_meminfo() trims each memblk between low (0) and high (max_pfn) limits and discards empty ones. However, the emptiness detection incorrectly used equality test. If the start of a memblk is higher than max_pfn, it is empty but fails the equality test and doesn't get discarded. The condition triggers when max_pfn is lower than start of a NUMA node and results in memory misconfiguration - leading to WARN_ON()s and other funnies. The bug was discovered in devel branch where 32bit too uses this code path for NUMA init. If a node is above the addressing limit, max_pfn ends up lower than the node triggering this problem. The failure hasn't been observed on x86-64 but is still possible with broken hardware e820/NUMA info. As the fix is very low risk, it would be better to apply it even for 64bit. Fix it by using >= instead of ==. Signed-off-by: Yinghai Lu <[email protected]> [ Extracted the actual fix from the original patch and rewrote patch description. ] Signed-off-by: Tejun Heo <[email protected]> Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Ingo Molnar <[email protected]> commit e20a2d205c05cef6b5783df339a7d54adeb50962 Author: Boris Ostrovsky <[email protected]> Date: Fri Apr 29 17:47:43 2011 -0400 x86, AMD: Fix APIC timer erratum 400 affecting K8 Rev.A-E processors Older AMD K8 processors (Revisions A-E) are affected by erratum 400 (APIC timer interrupts don't occur in C states greater than C1). This, for example, means that X86_FEATURE_ARAT flag should not be set for these parts. This addresses regression introduced by commit b87cf80af3ba4b4c008b4face3c68d604e1715c6 ("x86, AMD: Set ARAT feature on AMD processors") where the system may become unresponsive until external interrupt (such as keyboard input) occurs. This results, for example, in time not being reported correctly, lack of progress on the system and other lockups. Reported-by: Joerg-Volker Peetz <[email protected]> Tested-by: Joerg-Volker Peetz <[email protected]> Acked-by: Borislav Petkov <[email protected]> Signed-off-by: Boris Ostrovsky <[email protected]> Cc: [email protected] Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Ingo Molnar <[email protected]> commit bf283707d5fb174ec09215ae19860ad04ba7b67a Author: Mark Brown <[email protected]> Date: Wed Apr 27 23:09:26 2011 -0700 Input: wm831x-ts - move BTN_TOUCH reporting to data transfer Don't report BTN_TOUCH until we've got data as some less robust applications can be confused by getting a touch event by itself and it doesn't seem unreasonable for them to expect coordinates along with a touch. Signed-off-by: Mark Brown <[email protected]> Signed-off-by: Dmitry Torokhov <[email protected]> commit acad9853b95df6a3887f52e0ec88e4a77119ee28 Author: Mark Brown <[email protected]> Date: Wed Apr 27 23:08:51 2011 -0700 Input: wm831x-ts - allow IRQ flags to be specified This allows maximum flexibility for configuring the direct GPIO based interrupts. Signed-off-by: Mark Brown <[email protected]> Signed-off-by: Dmitry Torokhov <[email protected]> commit f5346668150c37094b42cc2d07ec5fd1451eb980 Author: Mark Brown <[email protected]> Date: Wed Apr 27 23:08:34 2011 -0700 Input: wm831x-ts - fix races with IRQ management If the WM831x pen down and data IRQs run in parallel it is possible for the data and pen down IRQs to deadlock themselves as one is part way through disabling its operation while the other is part way through enabling. Fix this by always disabling the pen down interrupt while data is active and vice versa. When a changeover is required we disable the IRQ that is to be stopped then schedule work that will enable the new IRQ. We need to handle the data flow in the data IRQ as the readback from the device needs to be ordered correctly with the IRQ for robust operation. This also fixes an issue when using the built in IRQs due to enable_irq() not being valid from interrupt context on an interrupt controller with bus operations like the built in IRQ controller - this issue may also have affected other interrupt controllers. We can't rely on having the data and pen down IRQs available via GPIOs on the CPU on every system. Signed-off-by: Mark Brown <[email protected]> Signed-off-by: Dmitry Torokhov <[email protected]> commit 0c9c99a765321104cc5f9c97f949382a9ba4927e Author: Chris Ball <[email protected]> Date: Wed Apr 27 17:35:31 2011 -0400 mmc: sdhci: Check mrq != NULL in sdhci_tasklet_finish It seems that under certain circumstances the sdhci_tasklet_finish() call can be entered with mrq set to NULL, causing the system to crash with a NULL pointer de-reference. Seen on S3C6410 system. Based on a patch by Dimitris Papastamos. Reported-by: Dimitris Papastamos <[email protected]> Cc: <[email protected]> Signed-off-by: Chris Ball <[email protected]> commit b7b4d3426d2b5ecab21578eb20d8e456a1aace8f Author: Ben Dooks <[email protected]> Date: Wed Apr 27 14:24:19 2011 +0100 mmc: sdhci: Check mrq->cmd in sdhci_tasklet_finish It seems that under certain circumstances that the sdhci_tasklet_finish() call can be entered with mrq->cmd set to NULL, causing the system to crash with a NULL pointer de-reference. Unable to handle kernel NULL pointer dereference at virtual address 00000000 PC is at sdhci_tasklet_finish+0x34/0xe8 LR is at sdhci_tasklet_finish+0x24/0xe8 Seen on S3C6410 system. Signed-off-by: Ben Dooks <[email protected]> Signed-off-by: Mark Brown <[email protected]> Cc: <[email protected]> Signed-off-by: Chris Ball <[email protected]> commit c919c2a073c5d2e076e52a56b44281d922721b61 Author: Guennadi Liakhovetski <[email protected]> Date: Thu Apr 21 09:09:59 2011 +0200 mmc: tmio: fix .set_ios(MMC_POWER_UP) handling The aggressive clock gating for TMIO MMC patch has broken switching interface power on, using MFD or platform callbacks. Restore the ios->power_mode == MMC_POWER_UP && ios->clock == 0 case handling. Signed-off-by: Guennadi Liakhovetski <[email protected]> Signed-off-by: Chris Ball <[email protected]> commit 26fc8775b51484d8c0a671198639c6d5ae60533e Author: Guennadi Liakhovetski <[email protected]> Date: Fri Apr 15 20:08:19 2011 +0200 mmc: fix a race between card-detect rescan and clock-gate work instances Currently there is a race in the MMC core between a card-detect rescan work and the clock-gating work, scheduled from a command completion. Fix it by removing the dedicated clock-gating mutex and using the MMC standard locking mechanism instead. Signed-off-by: Guennadi Liakhovetski <[email protected]> Cc: Simon Horman <[email protected]> Cc: Magnus Damm <[email protected]> Acked-by: Linus Walleij <[email protected]> Cc: <[email protected]> Signed-off-by: Chris Ball <[email protected]> commit f69475142136c8ad9b9c717aea2ff907aed9f863 Author: Michael Buesch <[email protected]> Date: Mon Apr 11 17:00:44 2011 -0400 mmc: omap: Fix possible NULL pointer deref Either OMAP_MMC_STAT_CARD_ERR or OMAP_MMC_STAT_END_OF_CMD might fire if there is no host->cmd pointer. Check for a valid host->cmd pointer before calling mmc_omap_cmd_done(). Signed-off-by: Michael Buesch <[email protected]> Acked-by: Tony Lindgren <[email protected]> Signed-off-by: Chris Ball <[email protected]> commit 9bc21848b1d6cb8389d927196b16c9950b5e21e9 Author: MichaÅ MirosÅaw <[email protected]> Date: Sat Apr 9 08:16:47 2011 +0200 mmc: core: mmc_add_card(): fix missing break in switch statement Fixes a cosmetic bug that affects printk() for SD-combo cards. Reported-by: Prashanth Bhat <[email protected]> Signed-off-by: MichaÅ MirosÅaw <[email protected]> Signed-off-by: Chris Ball <[email protected]> commit 9fdcdbb0d84922e7ccda2f717a04ea62629f7e18 Author: Chris Ball <[email protected]> Date: Tue Mar 29 00:46:12 2011 -0400 mmc: sdhci-pci: Fix error case in sdhci_pci_probe_slot() If pci_ioremap_bar() fails during probe, we "goto release;" and free the host, but then we return 0 -- which tells sdhci_pci_probe() that the probe succeeded. Since we think the probe succeeded, when we unload sdhci we'll go to sdhci_pci_remove_slot() and it will try to dereference slot->host, which is now NULL because we freed it in the error path earlier. The patch simply sets ret appropriately, so that sdhci_pci_probe() will detect the failure immediately and bail out. Signed-off-by: Chris Ball <[email protected]> Cc: <[email protected]> http://suva.vyatta.com/git/?p=linux-vyatta.git;a=commitdiff;he5623f9a6e52df90a78bd21179f8ab370e102e http://suva.vyatta.com/git/?p=linux-vyatta.git;a=commitdiff;heb96f80232e9a701b5c4715504f4c9173978bd http://suva.vyatta.com/git/?p=linux-vyatta.git;a=commitdiff;hI8548ec69c6897fe4376b2ca90758762fa0b817 http://suva.vyatta.com/git/?p=linux-vyatta.git;a=commitdiff;hêa4f5e1d0b816291a59a47917e569c0384f2b6f http://suva.vyatta.com/git/?p=linux-vyatta.git;a=commitdiff;hâc85d8e3974c9041ad7b080846b28d2243e771b http://suva.vyatta.com/git/?p=linux-vyatta.git;a=commitdiff;hÌe2c56e7666199916525907dc817209dd58287c http://suva.vyatta.com/git/?p=linux-vyatta.git;a=commitdiff;hx06a49ab625ebeb1709e5e87299b64932b807a7 http://suva.vyatta.com/git/?p=linux-vyatta.git;a=commitdiff;h¹269dc7bfdf8c985971c09f2dcb2aa04ad7986d http://suva.vyatta.com/git/?p=linux-vyatta.git;a=commitdiff;h£8647837a411f7df79623128421eef2118b5884 http://suva.vyatta.com/git/?p=linux-vyatta.git;a=commitdiff;hb2c363dcf732a4edab4ed66041cb36e7f28fbf http://suva.vyatta.com/git/?p=linux-vyatta.git;a=commitdiff;h+e19102b71c1a45d37fec50303791daa1a06869 http://suva.vyatta.com/git/?p=linux-vyatta.git;a=commitdiff;hâ0a2d205c05cef6b5783df339a7d54adeb50962 http://suva.vyatta.com/git/?p=linux-vyatta.git;a=commitdiff;h¿283707d5fb174ec09215ae19860ad04ba7b67a http://suva.vyatta.com/git/?p=linux-vyatta.git;a=commitdiff;h¬ad9853b95df6a3887f52e0ec88e4a77119ee28 http://suva.vyatta.com/git/?p=linux-vyatta.git;a=commitdiff;hõ346668150c37094b42cc2d07ec5fd1451eb980 http://suva.vyatta.com/git/?p=linux-vyatta.git;a=commitdiff;h 9c99a765321104cc5f9c97f949382a9ba4927e http://suva.vyatta.com/git/?p=linux-vyatta.git;a=commitdiff;h·b4d3426d2b5ecab21578eb20d8e456a1aace8f http://suva.vyatta.com/git/?p=linux-vyatta.git;a=commitdiff;hÉ19c2a073c5d2e076e52a56b44281d922721b61 http://suva.vyatta.com/git/?p=linux-vyatta.git;a=commitdiff;h&fc8775b51484d8c0a671198639c6d5ae60533e http://suva.vyatta.com/git/?p=linux-vyatta.git;a=commitdiff;hö9475142136c8ad9b9c717aea2ff907aed9f863 http://suva.vyatta.com/git/?p=linux-vyatta.git;a=commitdiff;hc21848b1d6cb8389d927196b16c9950b5e21e9 http://suva.vyatta.com/git/?p=linux-vyatta.git;a=commitdiff;hdcdbb0d84922e7ccda2f717a04ea62629f7e18
_______________________________________________ svn mailing list [email protected] http://mailman.vyatta.com/mailman/listinfo/svn
