From: Greg Kroah-Hartman Date: Fri, 6 Nov 2009 21:40:54 +0000 (-0800) Subject: more .31 patches X-Git-Tag: v2.6.31.6~5 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=714a168599dadc68a6a719ce5a468f0019b22e27;p=thirdparty%2Fkernel%2Fstable-queue.git more .31 patches --- diff --git a/queue-2.6.31/kvm-prevent-kvm_init-from-corrupting-debugfs-structures.patch b/queue-2.6.31/kvm-prevent-kvm_init-from-corrupting-debugfs-structures.patch new file mode 100644 index 00000000000..7bdbe60f8d5 --- /dev/null +++ b/queue-2.6.31/kvm-prevent-kvm_init-from-corrupting-debugfs-structures.patch @@ -0,0 +1,93 @@ +From mtosatti@redhat.com Fri Nov 6 13:34:46 2009 +From: Darrick J. Wong +Date: Fri, 6 Nov 2009 12:00:51 -0200 +Subject: KVM: Prevent kvm_init from corrupting debugfs structures +To: Greg KH +Cc: stable@kernel.org, "Darrick J. Wong" +Message-ID: <20091106140051.GA10313@amt.cnet> +Content-Disposition: inline + +From: Darrick J. Wong + +commit: 0ea4ed8e948c30f88c824c973ee4b9529015fe65 upstream + +I'm seeing an oops condition when kvm-intel and kvm-amd are modprobe'd +during boot (say on an Intel system) and then rmmod'd: + + # modprobe kvm-intel + kvm_init() + kvm_init_debug() + kvm_arch_init() <-- stores debugfs dentries internally + (success, etc) + + # modprobe kvm-amd + kvm_init() + kvm_init_debug() <-- second initialization clobbers kvm's + internal pointers to dentries + kvm_arch_init() + kvm_exit_debug() <-- and frees them + + # rmmod kvm-intel + kvm_exit() + kvm_exit_debug() <-- double free of debugfs files! + + *BOOM* + +If execution gets to the end of kvm_init(), then the calling module has been +established as the kvm provider. Move the debugfs initialization to the end of +the function, and remove the now-unnecessary call to kvm_exit_debug() from the +error path. That way we avoid trampling on the debugfs entries and freeing +them twice. + +Signed-off-by: Darrick J. Wong +Signed-off-by: Marcelo Tosatti +Signed-off-by: Greg Kroah-Hartman + +--- + virt/kvm/kvm_main.c | 7 +++---- + 1 file changed, 3 insertions(+), 4 deletions(-) + +--- a/virt/kvm/kvm_main.c ++++ b/virt/kvm/kvm_main.c +@@ -2590,8 +2590,6 @@ int kvm_init(void *opaque, unsigned int + int r; + int cpu; + +- kvm_init_debug(); +- + r = kvm_arch_init(opaque); + if (r) + goto out_fail; +@@ -2658,6 +2656,8 @@ int kvm_init(void *opaque, unsigned int + kvm_preempt_ops.sched_in = kvm_sched_in; + kvm_preempt_ops.sched_out = kvm_sched_out; + ++ kvm_init_debug(); ++ + return 0; + + out_free: +@@ -2679,7 +2679,6 @@ out_free_0: + __free_page(bad_page); + out: + kvm_arch_exit(); +- kvm_exit_debug(); + out_fail: + return r; + } +@@ -2688,6 +2687,7 @@ EXPORT_SYMBOL_GPL(kvm_init); + void kvm_exit(void) + { + kvm_trace_cleanup(); ++ kvm_exit_debug(); + misc_deregister(&kvm_dev); + kmem_cache_destroy(kvm_vcpu_cache); + sysdev_unregister(&kvm_sysdev); +@@ -2697,7 +2697,6 @@ void kvm_exit(void) + on_each_cpu(hardware_disable, NULL, 1); + kvm_arch_hardware_unsetup(); + kvm_arch_exit(); +- kvm_exit_debug(); + free_cpumask_var(cpus_hardware_enabled); + __free_page(bad_page); + } diff --git a/queue-2.6.31/pata_via-extend-the-rev_max-for-vt6330.patch b/queue-2.6.31/pata_via-extend-the-rev_max-for-vt6330.patch new file mode 100644 index 00000000000..55af91e91d2 --- /dev/null +++ b/queue-2.6.31/pata_via-extend-the-rev_max-for-vt6330.patch @@ -0,0 +1,31 @@ +From 7d948b1114c7eded14e5a31f440af751d70ecde0 Mon Sep 17 00:00:00 2001 +From: JosephChan@via.com.tw +Date: Fri, 16 Oct 2009 15:45:23 +0800 +Subject: pata_via: extend the rev_max for VT6330 + +From: JosephChan@via.com.tw + +commit 7d948b1114c7eded14e5a31f440af751d70ecde0 upstream. + +Fix the VT6330 issue, it's because the rev_max of VT6330 exceeds 0x2f. +The VT6415 and VT6330 share the same device ID. + +Signed-off-by: Joseph Chan +Signed-off-by: Jeff Garzik +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/ata/pata_via.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/drivers/ata/pata_via.c ++++ b/drivers/ata/pata_via.c +@@ -111,7 +111,7 @@ static const struct via_isa_bridge { + { "vt8251", PCI_DEVICE_ID_VIA_8251, 0x00, 0x2f, VIA_UDMA_133 | VIA_BAD_AST }, + { "cx700", PCI_DEVICE_ID_VIA_CX700, 0x00, 0x2f, VIA_UDMA_133 | VIA_BAD_AST | VIA_SATA_PATA }, + { "vt6410", PCI_DEVICE_ID_VIA_6410, 0x00, 0x2f, VIA_UDMA_133 | VIA_BAD_AST | VIA_NO_ENABLES }, +- { "vt6415", PCI_DEVICE_ID_VIA_6415, 0x00, 0x2f, VIA_UDMA_133 | VIA_BAD_AST | VIA_NO_ENABLES }, ++ { "vt6415", PCI_DEVICE_ID_VIA_6415, 0x00, 0xff, VIA_UDMA_133 | VIA_BAD_AST | VIA_NO_ENABLES }, + { "vt8237a", PCI_DEVICE_ID_VIA_8237A, 0x00, 0x2f, VIA_UDMA_133 | VIA_BAD_AST }, + { "vt8237", PCI_DEVICE_ID_VIA_8237, 0x00, 0x2f, VIA_UDMA_133 | VIA_BAD_AST }, + { "vt8235", PCI_DEVICE_ID_VIA_8235, 0x00, 0x2f, VIA_UDMA_133 | VIA_BAD_AST }, diff --git a/queue-2.6.31/powerpc-fix-some-late-powermac-g5-with-pcie-ati-graphics.patch b/queue-2.6.31/powerpc-fix-some-late-powermac-g5-with-pcie-ati-graphics.patch new file mode 100644 index 00000000000..6af4c39ce58 --- /dev/null +++ b/queue-2.6.31/powerpc-fix-some-late-powermac-g5-with-pcie-ati-graphics.patch @@ -0,0 +1,103 @@ +From cede3930f0ca6fef353fa01306c72a01420bd45e Mon Sep 17 00:00:00 2001 +From: Benjamin Herrenschmidt +Date: Mon, 31 Aug 2009 21:34:36 +0000 +Subject: powerpc: Fix some late PowerMac G5 with PCIe ATI graphics + +From: Benjamin Herrenschmidt + +commit cede3930f0ca6fef353fa01306c72a01420bd45e upstream. + +A misconfiguration by the firmware of the U4 PCIe bridge on PowerMac G5 +with the U4 bridge (latest generations, may also affect the iMac G5 +"iSight") is causing us to re-assign the PCI BARs of the video card, +which can get it out of sync with the firmware, thus breaking offb. + +This works around it by fixing up the bridge configuration properly +at boot time. It also fixes a bug where the firmware provides us with +an incorrect set of accessible regions in the device-tree. + +Signed-off-by: Benjamin Herrenschmidt +Signed-off-by: Greg Kroah-Hartman + +--- + arch/powerpc/platforms/powermac/pci.c | 61 ++++++++++++++++++++++++++++++++++ + include/linux/pci_ids.h | 1 + 2 files changed, 62 insertions(+) + +--- a/arch/powerpc/platforms/powermac/pci.c ++++ b/arch/powerpc/platforms/powermac/pci.c +@@ -1286,3 +1286,64 @@ static void fixup_k2_sata(struct pci_dev + } + DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_SERVERWORKS, 0x0240, fixup_k2_sata); + ++/* ++ * On U4 (aka CPC945) the PCIe root complex "P2P" bridge resource ranges aren't ++ * configured by the firmware. The bridge itself seems to ignore them but it ++ * causes problems with Linux which then re-assigns devices below the bridge, ++ * thus changing addresses of those devices from what was in the device-tree, ++ * which sucks when those are video cards using offb ++ * ++ * We could just mark it transparent but I prefer fixing up the resources to ++ * properly show what's going on here, as I have some doubts about having them ++ * badly configured potentially being an issue for DMA. ++ * ++ * We leave PIO alone, it seems to be fine ++ * ++ * Oh and there's another funny bug. The OF properties advertize the region ++ * 0xf1000000..0xf1ffffff as being forwarded as memory space. But that's ++ * actually not true, this region is the memory mapped config space. So we ++ * also need to filter it out or we'll map things in the wrong place. ++ */ ++static void fixup_u4_pcie(struct pci_dev* dev) ++{ ++ struct pci_controller *host = pci_bus_to_host(dev->bus); ++ struct resource *region = NULL; ++ u32 reg; ++ int i; ++ ++ /* Only do that on PowerMac */ ++ if (!machine_is(powermac)) ++ return; ++ ++ /* Find the largest MMIO region */ ++ for (i = 0; i < 3; i++) { ++ struct resource *r = &host->mem_resources[i]; ++ if (!(r->flags & IORESOURCE_MEM)) ++ continue; ++ /* Skip the 0xf0xxxxxx..f2xxxxxx regions, we know they ++ * are reserved by HW for other things ++ */ ++ if (r->start >= 0xf0000000 && r->start < 0xf3000000) ++ continue; ++ if (!region || (r->end - r->start) > ++ (region->end - region->start)) ++ region = r; ++ } ++ /* Nothing found, bail */ ++ if (region == 0) ++ return; ++ ++ /* Print things out */ ++ printk(KERN_INFO "PCI: Fixup U4 PCIe bridge range: %pR\n", region); ++ ++ /* Fixup bridge config space. We know it's a Mac, resource aren't ++ * offset so let's just blast them as-is. We also know that they ++ * fit in 32 bits ++ */ ++ reg = ((region->start >> 16) & 0xfff0) | (region->end & 0xfff00000); ++ pci_write_config_dword(dev, PCI_MEMORY_BASE, reg); ++ pci_write_config_dword(dev, PCI_PREF_BASE_UPPER32, 0); ++ pci_write_config_dword(dev, PCI_PREF_LIMIT_UPPER32, 0); ++ pci_write_config_dword(dev, PCI_PREF_MEMORY_BASE, 0); ++} ++DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_APPLE, PCI_DEVICE_ID_APPLE_U4_PCIE, fixup_u4_pcie); +--- a/include/linux/pci_ids.h ++++ b/include/linux/pci_ids.h +@@ -880,6 +880,7 @@ + #define PCI_DEVICE_ID_APPLE_SH_SUNGEM 0x0051 + #define PCI_DEVICE_ID_APPLE_U3L_AGP 0x0058 + #define PCI_DEVICE_ID_APPLE_U3H_AGP 0x0059 ++#define PCI_DEVICE_ID_APPLE_U4_PCIE 0x005b + #define PCI_DEVICE_ID_APPLE_IPID2_AGP 0x0066 + #define PCI_DEVICE_ID_APPLE_IPID2_ATA 0x0069 + #define PCI_DEVICE_ID_APPLE_IPID2_FW 0x006a diff --git a/queue-2.6.31/powerpc-pci-fix-regression-in-powerpc-msi-x.patch b/queue-2.6.31/powerpc-pci-fix-regression-in-powerpc-msi-x.patch new file mode 100644 index 00000000000..b962591d9c7 --- /dev/null +++ b/queue-2.6.31/powerpc-pci-fix-regression-in-powerpc-msi-x.patch @@ -0,0 +1,63 @@ +From 8435b027b87a78145992c37b0b8ed0f1b7761bf0 Mon Sep 17 00:00:00 2001 +From: Andre Detsch +Date: Wed, 4 Nov 2009 13:03:19 -0200 +Subject: powerpc/pci: Fix regression in powerpc MSI-X + +From: Andre Detsch + +commit 8435b027b87a78145992c37b0b8ed0f1b7761bf0 upstream. + +Patch f598282f5145036312d90875d0ed5c14b49fd8a7 exposed a problem in +powerpc MSI-X functionality, making network interfaces such as ixgbe +and cxgb3 stop to work when MSI-X is enabled. RX interrupts were not +being generated. + +The problem was caused because MSI irq was not being effectively +unmasked after device initialization. + +Signed-off-by: Andre Detsch +Signed-off-by: Michael Ellerman +Signed-off-by: Benjamin Herrenschmidt +Signed-off-by: Greg Kroah-Hartman + +--- + arch/powerpc/platforms/pseries/msi.c | 2 -- + arch/powerpc/platforms/pseries/xics.c | 9 +++++++++ + 2 files changed, 9 insertions(+), 2 deletions(-) + +--- a/arch/powerpc/platforms/pseries/msi.c ++++ b/arch/powerpc/platforms/pseries/msi.c +@@ -432,8 +432,6 @@ static int rtas_setup_msi_irqs(struct pc + /* Read config space back so we can restore after reset */ + read_msi_msg(virq, &msg); + entry->msg = msg; +- +- unmask_msi_irq(virq); + } + + return 0; +--- a/arch/powerpc/platforms/pseries/xics.c ++++ b/arch/powerpc/platforms/pseries/xics.c +@@ -18,6 +18,7 @@ + #include + #include + #include ++#include + #include + + #include +@@ -219,6 +220,14 @@ static void xics_unmask_irq(unsigned int + + static unsigned int xics_startup(unsigned int virq) + { ++ /* ++ * The generic MSI code returns with the interrupt disabled on the ++ * card, using the MSI mask bits. Firmware doesn't appear to unmask ++ * at that level, so we do it here by hand. ++ */ ++ if (irq_to_desc(virq)->msi_desc) ++ unmask_msi_irq(virq); ++ + /* unmask it */ + xics_unmask_irq(virq); + return 0; diff --git a/queue-2.6.31/powerpc-pmac-fix-issues-with-sleep-on-some-powerbooks.patch b/queue-2.6.31/powerpc-pmac-fix-issues-with-sleep-on-some-powerbooks.patch new file mode 100644 index 00000000000..2ebcd807045 --- /dev/null +++ b/queue-2.6.31/powerpc-pmac-fix-issues-with-sleep-on-some-powerbooks.patch @@ -0,0 +1,155 @@ +From 11a50873ef2b3c1c3fe99a661c22c08f35d93553 Mon Sep 17 00:00:00 2001 +From: Benjamin Herrenschmidt +Date: Fri, 9 Oct 2009 11:27:54 +0000 +Subject: powerpc/pmac: Fix issues with sleep on some powerbooks + +From: Benjamin Herrenschmidt + +commit 11a50873ef2b3c1c3fe99a661c22c08f35d93553 upstream. + +Since the change of how interrupts are disabled during suspend, +certain PowerBook models started exhibiting various issues during +suspend or resume from sleep. + +I finally tracked it down to the code that runs various "platform" +functions (kind of little scripts extracted from the device-tree), +which uses our i2c and PMU drivers expecting interrutps to work, +and at a time where with the new scheme, they have been disabled. + +This causes timeouts internally which for some reason results in +the PMU being unable to see the trackpad, among other issues, really +it depends on the machine. Most of the time, we fail to properly adjust +some clocks for suspend/resume so the results are not always +predictable. + +This patch fixes it by using IRQF_TIMER for both the PMU and the I2C +interrupts. I prefer doing it this way than moving the call sites since +I really want those platform functions to still be called after all +drivers (and before sysdevs). + +We also do a slight cleanup to via-pmu.c driver to make sure the +ADB autopoll mask is handled correctly when doing bus resets + +Signed-off-by: Benjamin Herrenschmidt +Signed-off-by: Greg Kroah-Hartman + +--- + arch/powerpc/platforms/powermac/low_i2c.c | 7 +++-- + drivers/macintosh/via-pmu.c | 40 +++++++++++++++++------------- + 2 files changed, 28 insertions(+), 19 deletions(-) + +--- a/arch/powerpc/platforms/powermac/low_i2c.c ++++ b/arch/powerpc/platforms/powermac/low_i2c.c +@@ -540,8 +540,11 @@ static struct pmac_i2c_host_kw *__init k + /* Make sure IRQ is disabled */ + kw_write_reg(reg_ier, 0); + +- /* Request chip interrupt */ +- if (request_irq(host->irq, kw_i2c_irq, 0, "keywest i2c", host)) ++ /* Request chip interrupt. We set IRQF_TIMER because we don't ++ * want that interrupt disabled between the 2 passes of driver ++ * suspend or we'll have issues running the pfuncs ++ */ ++ if (request_irq(host->irq, kw_i2c_irq, IRQF_TIMER, "keywest i2c", host)) + host->irq = NO_IRQ; + + printk(KERN_INFO "KeyWest i2c @0x%08x irq %d %s\n", +--- a/drivers/macintosh/via-pmu.c ++++ b/drivers/macintosh/via-pmu.c +@@ -405,7 +405,11 @@ static int __init via_pmu_start(void) + printk(KERN_ERR "via-pmu: can't map interrupt\n"); + return -ENODEV; + } +- if (request_irq(irq, via_pmu_interrupt, 0, "VIA-PMU", (void *)0)) { ++ /* We set IRQF_TIMER because we don't want the interrupt to be disabled ++ * between the 2 passes of driver suspend, we control our own disabling ++ * for that one ++ */ ++ if (request_irq(irq, via_pmu_interrupt, IRQF_TIMER, "VIA-PMU", (void *)0)) { + printk(KERN_ERR "via-pmu: can't request irq %d\n", irq); + return -ENODEV; + } +@@ -419,7 +423,7 @@ static int __init via_pmu_start(void) + gpio_irq = irq_of_parse_and_map(gpio_node, 0); + + if (gpio_irq != NO_IRQ) { +- if (request_irq(gpio_irq, gpio1_interrupt, 0, ++ if (request_irq(gpio_irq, gpio1_interrupt, IRQF_TIMER, + "GPIO1 ADB", (void *)0)) + printk(KERN_ERR "pmu: can't get irq %d" + " (GPIO1)\n", gpio_irq); +@@ -925,8 +929,7 @@ proc_write_options(struct file *file, co + + #ifdef CONFIG_ADB + /* Send an ADB command */ +-static int +-pmu_send_request(struct adb_request *req, int sync) ++static int pmu_send_request(struct adb_request *req, int sync) + { + int i, ret; + +@@ -1005,16 +1008,11 @@ pmu_send_request(struct adb_request *req + } + + /* Enable/disable autopolling */ +-static int +-pmu_adb_autopoll(int devs) ++static int __pmu_adb_autopoll(int devs) + { + struct adb_request req; + +- if ((vias == NULL) || (!pmu_fully_inited) || !pmu_has_adb) +- return -ENXIO; +- + if (devs) { +- adb_dev_map = devs; + pmu_request(&req, NULL, 5, PMU_ADB_CMD, 0, 0x86, + adb_dev_map >> 8, adb_dev_map); + pmu_adb_flags = 2; +@@ -1027,9 +1025,17 @@ pmu_adb_autopoll(int devs) + return 0; + } + ++static int pmu_adb_autopoll(int devs) ++{ ++ if ((vias == NULL) || (!pmu_fully_inited) || !pmu_has_adb) ++ return -ENXIO; ++ ++ adb_dev_map = devs; ++ return __pmu_adb_autopoll(devs); ++} ++ + /* Reset the ADB bus */ +-static int +-pmu_adb_reset_bus(void) ++static int pmu_adb_reset_bus(void) + { + struct adb_request req; + int save_autopoll = adb_dev_map; +@@ -1038,13 +1044,13 @@ pmu_adb_reset_bus(void) + return -ENXIO; + + /* anyone got a better idea?? */ +- pmu_adb_autopoll(0); ++ __pmu_adb_autopoll(0); + +- req.nbytes = 5; ++ req.nbytes = 4; + req.done = NULL; + req.data[0] = PMU_ADB_CMD; +- req.data[1] = 0; +- req.data[2] = ADB_BUSRESET; ++ req.data[1] = ADB_BUSRESET; ++ req.data[2] = 0; + req.data[3] = 0; + req.data[4] = 0; + req.reply_len = 0; +@@ -1056,7 +1062,7 @@ pmu_adb_reset_bus(void) + pmu_wait_complete(&req); + + if (save_autopoll != 0) +- pmu_adb_autopoll(save_autopoll); ++ __pmu_adb_autopoll(save_autopoll); + + return 0; + } diff --git a/queue-2.6.31/powerpc-pmac-fix-powersurge-smp-ipi-allocation.patch b/queue-2.6.31/powerpc-pmac-fix-powersurge-smp-ipi-allocation.patch new file mode 100644 index 00000000000..66d9038f4b0 --- /dev/null +++ b/queue-2.6.31/powerpc-pmac-fix-powersurge-smp-ipi-allocation.patch @@ -0,0 +1,30 @@ +From 527b3639616b21c257518ee7c26fbf05232db0c0 Mon Sep 17 00:00:00 2001 +From: Benjamin Herrenschmidt +Date: Tue, 14 Jul 2009 20:56:58 +0000 +Subject: powerpc/pmac: Fix PowerSurge SMP IPI allocation + +From: Benjamin Herrenschmidt + +commit 527b3639616b21c257518ee7c26fbf05232db0c0 upstream. + +The code for setting up the IPIs for SMP PowerSurge marchines bitrot, +it needs to properly map the HW interrupt number + +Signed-off-by: Benjamin Herrenschmidt +Signed-off-by: Greg Kroah-Hartman + +--- + arch/powerpc/platforms/powermac/smp.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/arch/powerpc/platforms/powermac/smp.c ++++ b/arch/powerpc/platforms/powermac/smp.c +@@ -408,7 +408,7 @@ static void __init smp_psurge_setup_cpu( + /* reset the entry point so if we get another intr we won't + * try to startup again */ + out_be32(psurge_start, 0x100); +- if (setup_irq(30, &psurge_irqaction)) ++ if (setup_irq(irq_create_mapping(NULL, 30), &psurge_irqaction)) + printk(KERN_ERR "Couldn't get primary IPI interrupt"); + } + diff --git a/queue-2.6.31/sata_via-remove-redundant-device-id-for-via-vt8261.patch b/queue-2.6.31/sata_via-remove-redundant-device-id-for-via-vt8261.patch new file mode 100644 index 00000000000..5e4457e8522 --- /dev/null +++ b/queue-2.6.31/sata_via-remove-redundant-device-id-for-via-vt8261.patch @@ -0,0 +1,31 @@ +From f38e35b43f2924b3b4e51147b7193f32e9276db4 Mon Sep 17 00:00:00 2001 +From: JosephChan@via.com.tw +Date: Mon, 2 Nov 2009 19:36:08 +0800 +Subject: sata_via: Remove redundant device ID for VIA VT8261 + +From: JosephChan@via.com.tw + +commit f38e35b43f2924b3b4e51147b7193f32e9276db4 upstream. + +Just remove redundant device ID for VIA VT8261. +The device ID 0x9000 and 0x9040 are redundant (for VT8261). +The 0x9040 is reserved for other usage. + +Signed-off-by: Joseph Chan +Signed-off-by: Jeff Garzik +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/ata/sata_via.c | 1 - + 1 file changed, 1 deletion(-) + +--- a/drivers/ata/sata_via.c ++++ b/drivers/ata/sata_via.c +@@ -93,7 +93,6 @@ static const struct pci_device_id svia_p + { PCI_VDEVICE(VIA, 0x7372), vt6420 }, + { PCI_VDEVICE(VIA, 0x5287), vt8251 }, /* 2 sata chnls (Master/Slave) */ + { PCI_VDEVICE(VIA, 0x9000), vt8251 }, +- { PCI_VDEVICE(VIA, 0x9040), vt8251 }, + + { } /* terminate list */ + }; diff --git a/queue-2.6.31/series b/queue-2.6.31/series index 317ce547335..850e3872e7c 100644 --- a/queue-2.6.31/series +++ b/queue-2.6.31/series @@ -89,3 +89,11 @@ x86-mce-clean-up-thermal-throttling-state-tracking-code.patch x86-mce-fix-thermal-throttling-message-storm.patch iwlwifi-fix-potential-rx-buffer-loss.patch iwlwifi-reduce-noise-when-skb-allocation-fails.patch +x86-amd-iommu-un__init-function-required-on-shutdown.patch +kvm-prevent-kvm_init-from-corrupting-debugfs-structures.patch +powerpc-pmac-fix-powersurge-smp-ipi-allocation.patch +powerpc-pmac-fix-issues-with-sleep-on-some-powerbooks.patch +powerpc-pci-fix-regression-in-powerpc-msi-x.patch +powerpc-fix-some-late-powermac-g5-with-pcie-ati-graphics.patch +sata_via-remove-redundant-device-id-for-via-vt8261.patch +pata_via-extend-the-rev_max-for-vt6330.patch diff --git a/queue-2.6.31/x86-amd-iommu-un__init-function-required-on-shutdown.patch b/queue-2.6.31/x86-amd-iommu-un__init-function-required-on-shutdown.patch new file mode 100644 index 00000000000..3da71060073 --- /dev/null +++ b/queue-2.6.31/x86-amd-iommu-un__init-function-required-on-shutdown.patch @@ -0,0 +1,32 @@ +From ca0207114f1708b563f510b7781a360ec5b98359 Mon Sep 17 00:00:00 2001 +From: Joerg Roedel +Date: Wed, 28 Oct 2009 18:02:26 +0100 +Subject: x86/amd-iommu: Un__init function required on shutdown + +From: Joerg Roedel + +commit ca0207114f1708b563f510b7781a360ec5b98359 upstream. + +The function iommu_feature_disable is required on system +shutdown to disable the IOMMU but it is marked as __init. +This may result in a panic if the memory is reused. This +patch fixes this bug. + +Signed-off-by: Joerg Roedel +Signed-off-by: Greg Kroah-Hartman + +--- + arch/x86/kernel/amd_iommu_init.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/arch/x86/kernel/amd_iommu_init.c ++++ b/arch/x86/kernel/amd_iommu_init.c +@@ -240,7 +240,7 @@ static void iommu_feature_enable(struct + writel(ctrl, iommu->mmio_base + MMIO_CONTROL_OFFSET); + } + +-static void __init iommu_feature_disable(struct amd_iommu *iommu, u8 bit) ++static void iommu_feature_disable(struct amd_iommu *iommu, u8 bit) + { + u32 ctrl; +