--- /dev/null
+From mtosatti@redhat.com Fri Nov 6 13:34:46 2009
+From: Darrick J. Wong <djwong@us.ibm.com>
+Date: Fri, 6 Nov 2009 12:00:51 -0200
+Subject: KVM: Prevent kvm_init from corrupting debugfs structures
+To: Greg KH <greg@kroah.com>
+Cc: stable@kernel.org, "Darrick J. Wong" <djwong@us.ibm.com>
+Message-ID: <20091106140051.GA10313@amt.cnet>
+Content-Disposition: inline
+
+From: Darrick J. Wong <djwong@us.ibm.com>
+
+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 <djwong@us.ibm.com>
+Signed-off-by: Marcelo Tosatti <mtosatti@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+---
+ 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);
+ }
--- /dev/null
+From 7d948b1114c7eded14e5a31f440af751d70ecde0 Mon Sep 17 00:00:00 2001
+From: JosephChan@via.com.tw <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 <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 <josephchan@via.com.tw>
+Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+---
+ 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 },
--- /dev/null
+From cede3930f0ca6fef353fa01306c72a01420bd45e Mon Sep 17 00:00:00 2001
+From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
+Date: Mon, 31 Aug 2009 21:34:36 +0000
+Subject: powerpc: Fix some late PowerMac G5 with PCIe ATI graphics
+
+From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
+
+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 <benh@kernel.crashing.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+---
+ 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
--- /dev/null
+From 8435b027b87a78145992c37b0b8ed0f1b7761bf0 Mon Sep 17 00:00:00 2001
+From: Andre Detsch <adetsch@br.ibm.com>
+Date: Wed, 4 Nov 2009 13:03:19 -0200
+Subject: powerpc/pci: Fix regression in powerpc MSI-X
+
+From: Andre Detsch <adetsch@br.ibm.com>
+
+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 <adetsch@br.ibm.com>
+Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
+Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+---
+ 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 <linux/init.h>
+ #include <linux/radix-tree.h>
+ #include <linux/cpu.h>
++#include <linux/msi.h>
+ #include <linux/of.h>
+
+ #include <asm/firmware.h>
+@@ -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;
--- /dev/null
+From 11a50873ef2b3c1c3fe99a661c22c08f35d93553 Mon Sep 17 00:00:00 2001
+From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
+Date: Fri, 9 Oct 2009 11:27:54 +0000
+Subject: powerpc/pmac: Fix issues with sleep on some powerbooks
+
+From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
+
+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 <benh@kernel.crashing.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+---
+ 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;
+ }
--- /dev/null
+From 527b3639616b21c257518ee7c26fbf05232db0c0 Mon Sep 17 00:00:00 2001
+From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
+Date: Tue, 14 Jul 2009 20:56:58 +0000
+Subject: powerpc/pmac: Fix PowerSurge SMP IPI allocation
+
+From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
+
+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 <benh@kernel.crashing.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+---
+ 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");
+ }
+
--- /dev/null
+From f38e35b43f2924b3b4e51147b7193f32e9276db4 Mon Sep 17 00:00:00 2001
+From: JosephChan@via.com.tw <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 <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 <josephchan@via.com.tw>
+Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+---
+ 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 */
+ };
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
--- /dev/null
+From ca0207114f1708b563f510b7781a360ec5b98359 Mon Sep 17 00:00:00 2001
+From: Joerg Roedel <joerg.roedel@amd.com>
+Date: Wed, 28 Oct 2009 18:02:26 +0100
+Subject: x86/amd-iommu: Un__init function required on shutdown
+
+From: Joerg Roedel <joerg.roedel@amd.com>
+
+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 <joerg.roedel@amd.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+---
+ 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;
+
projects / thirdparty / kernel / stable-queue.git / commitdiff
