--- /dev/null
+From 29ebe40284c75a5888c601872059fca7e258528d Mon Sep 17 00:00:00 2001
+From: Josh Boyer <jwboyer@redhat.com>
+Date: Thu, 12 Apr 2012 13:55:36 -0400
+Subject: ALSA: hda/realtek - Add quirk for Mac Pro 5,1 machines
+
+From: Josh Boyer <jwboyer@redhat.com>
+
+commit 29ebe40284c75a5888c601872059fca7e258528d upstream.
+
+A user reported that setting model=imac24 used to allow sound to work on their
+Mac Pro 5,1 machine. Commit 5671087ffa "Move ALC885 macpro and imac24 models
+to auto-parser" removed this model option. All Mac machines are now explicitly
+handled with a quirk and the auto-parser. This adds a quirk for the device
+found on the Mac Pro 5,1 machines.
+
+This (partially) fixes https://bugzilla.redhat.com/show_bug.cgi?id=808559
+
+[sorted the new entry in the ID number order by tiwai]
+
+Reported-by: Gabriel Somlo <somlo@cmu.edu>
+Signed-off-by: Josh Boyer <jwboyer@redhat.com>
+Signed-off-by: Takashi Iwai <tiwai@suse.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c
+index d25a6f9..8f4a484 100644
+--- a/sound/pci/hda/patch_realtek.c
++++ b/sound/pci/hda/patch_realtek.c
+@@ -5389,6 +5389,7 @@ static const struct snd_pci_quirk alc882_fixup_tbl[] = {
+ SND_PCI_QUIRK(0x106b, 0x3f00, "Macbook 5,1", ALC889_FIXUP_IMAC91_VREF),
+ SND_PCI_QUIRK(0x106b, 0x4000, "MacbookPro 5,1", ALC889_FIXUP_IMAC91_VREF),
+ SND_PCI_QUIRK(0x106b, 0x4100, "Macmini 3,1", ALC889_FIXUP_IMAC91_VREF),
++ SND_PCI_QUIRK(0x106b, 0x4200, "Mac Pro 5,1", ALC885_FIXUP_MACPRO_GPIO),
+ SND_PCI_QUIRK(0x106b, 0x4600, "MacbookPro 5,2", ALC889_FIXUP_IMAC91_VREF),
+ SND_PCI_QUIRK(0x106b, 0x4900, "iMac 9,1 Aluminum", ALC889_FIXUP_IMAC91_VREF),
+ SND_PCI_QUIRK(0x106b, 0x4a00, "Macbook 5,2", ALC889_FIXUP_IMAC91_VREF),
--- /dev/null
+From 7e1f7c8a6e517900cd84da1b8ae020f08f286c3b Mon Sep 17 00:00:00 2001
+From: Mark Brown <broonie@opensource.wolfsonmicro.com>
+Date: Thu, 12 Apr 2012 17:29:36 +0100
+Subject: ASoC: dapm: Ensure power gets managed for line widgets
+
+From: Mark Brown <broonie@opensource.wolfsonmicro.com>
+
+commit 7e1f7c8a6e517900cd84da1b8ae020f08f286c3b upstream.
+
+Line widgets had not been included in either the power up or power down
+sequences so if a widget had an event associated with it that event would
+never be run. Fix this minimally by adding them to the sequences, we
+should probably be doing away with the specific widget types as they all
+have the same priority anyway.
+
+Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ sound/soc/soc-dapm.c | 2 ++
+ 1 file changed, 2 insertions(+)
+
+--- a/sound/soc/soc-dapm.c
++++ b/sound/soc/soc-dapm.c
+@@ -67,6 +67,7 @@ static int dapm_up_seq[] = {
+ [snd_soc_dapm_out_drv] = 10,
+ [snd_soc_dapm_hp] = 10,
+ [snd_soc_dapm_spk] = 10,
++ [snd_soc_dapm_line] = 10,
+ [snd_soc_dapm_post] = 11,
+ };
+
+@@ -75,6 +76,7 @@ static int dapm_down_seq[] = {
+ [snd_soc_dapm_adc] = 1,
+ [snd_soc_dapm_hp] = 2,
+ [snd_soc_dapm_spk] = 2,
++ [snd_soc_dapm_line] = 2,
+ [snd_soc_dapm_out_drv] = 2,
+ [snd_soc_dapm_pga] = 4,
+ [snd_soc_dapm_mixer_named_ctl] = 5,
--- /dev/null
+From ed8b0d67f33518a16c6b2450fe5ebebf180c2d04 Mon Sep 17 00:00:00 2001
+From: Nicolas Ferre <nicolas.ferre@atmel.com>
+Date: Mon, 16 Apr 2012 14:46:30 +0200
+Subject: dmaengine: at_hdmac: remove clear-on-read in atc_dostart()
+
+From: Nicolas Ferre <nicolas.ferre@atmel.com>
+
+commit ed8b0d67f33518a16c6b2450fe5ebebf180c2d04 upstream.
+
+This loop on EBCISR register was designed to clear IRQ sources before enabling
+a DMA channel. This register is clear-on-read so a race condition can appear if
+another channel is already active and has just finished its transfer.
+Removing this read on EBCISR is fixing the issue as there is no case where an IRQ
+could be pending: we already make sure that this register is drained at probe()
+time and during resume.
+
+Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
+Signed-off-by: Vinod Koul <vinod.koul@linux.intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/dma/at_hdmac.c | 4 ----
+ 1 file changed, 4 deletions(-)
+
+--- a/drivers/dma/at_hdmac.c
++++ b/drivers/dma/at_hdmac.c
+@@ -237,10 +237,6 @@ static void atc_dostart(struct at_dma_ch
+
+ vdbg_dump_regs(atchan);
+
+- /* clear any pending interrupt */
+- while (dma_readl(atdma, EBCISR))
+- cpu_relax();
+-
+ channel_writel(atchan, SADDR, 0);
+ channel_writel(atchan, DADDR, 0);
+ channel_writel(atchan, CTRLA, 0);
--- /dev/null
+From 44afb3a04391a74309d16180d1e4f8386fdfa745 Mon Sep 17 00:00:00 2001
+From: Xi Wang <xi.wang@gmail.com>
+Date: Mon, 23 Apr 2012 04:06:42 -0400
+Subject: drm/i915: fix integer overflow in i915_gem_do_execbuffer()
+
+From: Xi Wang <xi.wang@gmail.com>
+
+commit 44afb3a04391a74309d16180d1e4f8386fdfa745 upstream.
+
+On 32-bit systems, a large args->num_cliprects from userspace via ioctl
+may overflow the allocation size, leading to out-of-bounds access.
+
+This vulnerability was introduced in commit 432e58ed ("drm/i915: Avoid
+allocation for execbuffer object list").
+
+Signed-off-by: Xi Wang <xi.wang@gmail.com>
+Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
+Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/gpu/drm/i915/i915_gem_execbuffer.c | 5 +++++
+ 1 file changed, 5 insertions(+)
+
+--- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
++++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
+@@ -1046,6 +1046,11 @@ i915_gem_do_execbuffer(struct drm_device
+ return -EINVAL;
+ }
+
++ if (args->num_cliprects > UINT_MAX / sizeof(*cliprects)) {
++ DRM_DEBUG("execbuf with %u cliprects\n",
++ args->num_cliprects);
++ return -EINVAL;
++ }
+ cliprects = kmalloc(args->num_cliprects * sizeof(*cliprects),
+ GFP_KERNEL);
+ if (cliprects == NULL) {
--- /dev/null
+From ed8cd3b2cd61004cab85380c52b1817aca1ca49b Mon Sep 17 00:00:00 2001
+From: Xi Wang <xi.wang@gmail.com>
+Date: Mon, 23 Apr 2012 04:06:41 -0400
+Subject: drm/i915: fix integer overflow in i915_gem_execbuffer2()
+
+From: Xi Wang <xi.wang@gmail.com>
+
+commit ed8cd3b2cd61004cab85380c52b1817aca1ca49b upstream.
+
+On 32-bit systems, a large args->buffer_count from userspace via ioctl
+may overflow the allocation size, leading to out-of-bounds access.
+
+This vulnerability was introduced in commit 8408c282 ("drm/i915:
+First try a normal large kmalloc for the temporary exec buffers").
+
+Signed-off-by: Xi Wang <xi.wang@gmail.com>
+Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
+Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/gpu/drm/i915/i915_gem_execbuffer.c | 3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+--- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
++++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
+@@ -1296,7 +1296,8 @@ i915_gem_execbuffer2(struct drm_device *
+ struct drm_i915_gem_exec_object2 *exec2_list = NULL;
+ int ret;
+
+- if (args->buffer_count < 1) {
++ if (args->buffer_count < 1 ||
++ args->buffer_count > UINT_MAX / sizeof(*exec2_list)) {
+ DRM_ERROR("execbuf2 with %d buffers\n", args->buffer_count);
+ return -EINVAL;
+ }
--- /dev/null
+From 6651819b4b4fc3caa6964c5d825eb4bb996f3905 Mon Sep 17 00:00:00 2001
+From: Daniel Vetter <daniel.vetter@ffwll.ch>
+Date: Sun, 1 Apr 2012 19:16:18 +0200
+Subject: drm/i915: handle input/output sdvo timings separately in mode_set
+
+From: Daniel Vetter <daniel.vetter@ffwll.ch>
+
+commit 6651819b4b4fc3caa6964c5d825eb4bb996f3905 upstream.
+
+We seem to have a decent confusion between the output timings and the
+input timings of the sdvo encoder. If I understand the code correctly,
+we use the original mode unchanged for the output timings, safe for
+the lvds case. And we should use the adjusted mode for input timings.
+
+Clarify the situation by adding an explicit output_dtd to the sdvo
+mode_set function and streamline the code-flow by moving the input and
+output mode setting in the sdvo encode together.
+
+Furthermore testing showed that the sdvo input timing needs the
+unadjusted dotclock, the sdvo chip will automatically compute the
+required pixel multiplier to get a dotclock above 100 MHz.
+
+Fix this up when converting a drm mode to an sdvo dtd.
+
+This regression was introduced in
+
+commit c74696b9c890074c1e1ee3d7496fc71eb3680ced
+Author: Pavel Roskin <proski@gnu.org>
+Date: Thu Sep 2 14:46:34 2010 -0400
+
+ i915: revert some checks added by commit 32aad86f
+
+particularly the following hunk:
+
+# diff --git a/drivers/gpu/drm/i915/intel_sdvo.c
+# b/drivers/gpu/drm/i915/intel_sdvo.c
+# index 093e914..62d22ae 100644
+# --- a/drivers/gpu/drm/i915/intel_sdvo.c
+# +++ b/drivers/gpu/drm/i915/intel_sdvo.c
+# @@ -1122,11 +1123,9 @@ static void intel_sdvo_mode_set(struct drm_encoder *encoder,
+#
+# /* We have tried to get input timing in mode_fixup, and filled into
+# adjusted_mode */
+# - if (intel_sdvo->is_tv || intel_sdvo->is_lvds) {
+# - intel_sdvo_get_dtd_from_mode(&input_dtd, adjusted_mode);
+# + intel_sdvo_get_dtd_from_mode(&input_dtd, adjusted_mode);
+# + if (intel_sdvo->is_tv || intel_sdvo->is_lvds)
+# input_dtd.part2.sdvo_flags = intel_sdvo->sdvo_flags;
+# - } else
+# - intel_sdvo_get_dtd_from_mode(&input_dtd, mode);
+#
+# /* If it's a TV, we already set the output timing in mode_fixup.
+# * Otherwise, the output timing is equal to the input timing.
+
+Due to questions raised in review, below a more elaborate analysis of
+the bug at hand:
+
+Sdvo seems to have two timings, one is the output timing which will be
+sent over whatever is connected on the other side of the sdvo chip (panel,
+hdmi screen, tv), the other is the input timing which will be generated by
+the gmch pipe. It looks like sdvo is expected to scale between the two.
+
+To make things slightly more complicated, we have a bunch of special
+cases:
+- For lvds panel we always use a fixed output timing, namely
+ intel_sdvo->sdvo_lvds_fixed_mode, hence that special case.
+- Sdvo has an interface to generate a preferred input timing for a given
+ output timing. This is the confusing thing that I've tried to clear up
+ with the follow-on patches.
+- A special requirement is that the input pixel clock needs to be between
+ 100MHz and 200MHz (likely to keep it within the electromechanical design
+ range of PCIe), 270MHz on later gen4+. Lower pixel clocks are
+ doubled/quadrupled.
+
+The thing this patch tries to fix is that the pipe needs to be
+explicitly instructed to double/quadruple the pixels and needs the
+correspondingly higher pixel clock, whereas the sdvo adaptor seems to
+do that itself and needs the unadjusted pixel clock. For the sdvo
+encode side we already set the pixel mutliplier with a different
+command (0x21).
+
+This patch tries to fix this mess by:
+- Keeping the output mode timing in the unadjusted plain mode, safe
+ for the lvds case.
+- Storing the input timing in the adjusted_mode with the adjusted
+ pixel clock. This way we don't need to frob around with the core
+ crtc mode set code.
+- Fixing up the pixelclock when constructing the sdvo dtd timing
+ struct. This is why the first hunk of the patch is an integral part
+ of the series.
+- Dropping the is_tv special case because input_dtd is equivalent to
+ adjusted_mode after these changes. Follow-up patches clear this up
+ further (by simply ripping out intel_sdvo->input_dtd because it's
+ not needed).
+
+v2: Extend commit message with an in-depth bug analysis.
+
+Reported-and-Tested-by: Bernard Blackham <b-linuxgit@largestprime.net>
+Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=48157
+Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
+Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/gpu/drm/i915/intel_sdvo.c | 34 ++++++++++++++++++----------------
+ 1 file changed, 18 insertions(+), 16 deletions(-)
+
+--- a/drivers/gpu/drm/i915/intel_sdvo.c
++++ b/drivers/gpu/drm/i915/intel_sdvo.c
+@@ -724,6 +724,7 @@ static void intel_sdvo_get_dtd_from_mode
+ uint16_t width, height;
+ uint16_t h_blank_len, h_sync_len, v_blank_len, v_sync_len;
+ uint16_t h_sync_offset, v_sync_offset;
++ int mode_clock;
+
+ width = mode->crtc_hdisplay;
+ height = mode->crtc_vdisplay;
+@@ -738,7 +739,11 @@ static void intel_sdvo_get_dtd_from_mode
+ h_sync_offset = mode->crtc_hsync_start - mode->crtc_hblank_start;
+ v_sync_offset = mode->crtc_vsync_start - mode->crtc_vblank_start;
+
+- dtd->part1.clock = mode->clock / 10;
++ mode_clock = mode->clock;
++ mode_clock /= intel_mode_get_pixel_multiplier(mode) ?: 1;
++ mode_clock /= 10;
++ dtd->part1.clock = mode_clock;
++
+ dtd->part1.h_active = width & 0xff;
+ dtd->part1.h_blank = h_blank_len & 0xff;
+ dtd->part1.h_high = (((width >> 8) & 0xf) << 4) |
+@@ -990,7 +995,7 @@ static void intel_sdvo_mode_set(struct d
+ struct intel_sdvo *intel_sdvo = to_intel_sdvo(encoder);
+ u32 sdvox;
+ struct intel_sdvo_in_out_map in_out;
+- struct intel_sdvo_dtd input_dtd;
++ struct intel_sdvo_dtd input_dtd, output_dtd;
+ int pixel_multiplier = intel_mode_get_pixel_multiplier(adjusted_mode);
+ int rate;
+
+@@ -1015,20 +1020,13 @@ static void intel_sdvo_mode_set(struct d
+ intel_sdvo->attached_output))
+ return;
+
+- /* We have tried to get input timing in mode_fixup, and filled into
+- * adjusted_mode.
+- */
+- if (intel_sdvo->is_tv || intel_sdvo->is_lvds) {
+- input_dtd = intel_sdvo->input_dtd;
+- } else {
+- /* Set the output timing to the screen */
+- if (!intel_sdvo_set_target_output(intel_sdvo,
+- intel_sdvo->attached_output))
+- return;
+-
+- intel_sdvo_get_dtd_from_mode(&input_dtd, adjusted_mode);
+- (void) intel_sdvo_set_output_timing(intel_sdvo, &input_dtd);
+- }
++ /* lvds has a special fixed output timing. */
++ if (intel_sdvo->is_lvds)
++ intel_sdvo_get_dtd_from_mode(&output_dtd,
++ intel_sdvo->sdvo_lvds_fixed_mode);
++ else
++ intel_sdvo_get_dtd_from_mode(&output_dtd, mode);
++ (void) intel_sdvo_set_output_timing(intel_sdvo, &output_dtd);
+
+ /* Set the input timing to the screen. Assume always input 0. */
+ if (!intel_sdvo_set_target_input(intel_sdvo))
+@@ -1046,6 +1044,10 @@ static void intel_sdvo_mode_set(struct d
+ !intel_sdvo_set_tv_format(intel_sdvo))
+ return;
+
++ /* We have tried to get input timing in mode_fixup, and filled into
++ * adjusted_mode.
++ */
++ intel_sdvo_get_dtd_from_mode(&input_dtd, adjusted_mode);
+ (void) intel_sdvo_set_input_timing(intel_sdvo, &input_dtd);
+
+ switch (pixel_multiplier) {
--- /dev/null
+From 00250ec90963b7ef6678438888f3244985ecde14 Mon Sep 17 00:00:00 2001
+From: Andre Przywara <andre.przywara@amd.com>
+Date: Mon, 9 Apr 2012 18:16:34 -0400
+Subject: hwmon: fam15h_power: fix bogus values with current BIOSes
+
+From: Andre Przywara <andre.przywara@amd.com>
+
+commit 00250ec90963b7ef6678438888f3244985ecde14 upstream.
+
+Newer BKDG[1] versions recommend a different initialization value for
+the running average range register in the northbridge. This improves
+the power reading by avoiding counter saturations resulting in bogus
+values for anything below about 80% of TDP power consumption.
+Updated BIOSes will have this new value set up from the beginning,
+but meanwhile we correct this value ourselves.
+This needs to be done on all northbridges, even on those where the
+driver itself does not register at.
+
+This fixes the driver on all current machines to provide proper
+values for idle load.
+
+[1]
+http://support.amd.com/us/Processor_TechDocs/42301_15h_Mod_00h-0Fh_BKDG.pdf
+Chapter 3.8: D18F5xE0 Processor TDP Running Average (p. 452)
+
+Signed-off-by: Andre Przywara <andre.przywara@amd.com>
+Acked-by: Jean Delvare <khali@linux-fr.org>
+[guenter.roeck@ericsson.com: Removed unnecessary return statement]
+Signed-off-by: Guenter Roeck <guenter.roeck@ericsson.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/hwmon/fam15h_power.c | 39 +++++++++++++++++++++++++++++++++++++++
+ 1 file changed, 39 insertions(+)
+
+--- a/drivers/hwmon/fam15h_power.c
++++ b/drivers/hwmon/fam15h_power.c
+@@ -122,6 +122,38 @@ static bool __devinit fam15h_power_is_in
+ return true;
+ }
+
++/*
++ * Newer BKDG versions have an updated recommendation on how to properly
++ * initialize the running average range (was: 0xE, now: 0x9). This avoids
++ * counter saturations resulting in bogus power readings.
++ * We correct this value ourselves to cope with older BIOSes.
++ */
++static void __devinit tweak_runavg_range(struct pci_dev *pdev)
++{
++ u32 val;
++ const struct pci_device_id affected_device = {
++ PCI_VDEVICE(AMD, PCI_DEVICE_ID_AMD_15H_NB_F4) };
++
++ /*
++ * let this quirk apply only to the current version of the
++ * northbridge, since future versions may change the behavior
++ */
++ if (!pci_match_id(&affected_device, pdev))
++ return;
++
++ pci_bus_read_config_dword(pdev->bus,
++ PCI_DEVFN(PCI_SLOT(pdev->devfn), 5),
++ REG_TDP_RUNNING_AVERAGE, &val);
++ if ((val & 0xf) != 0xe)
++ return;
++
++ val &= ~0xf;
++ val |= 0x9;
++ pci_bus_write_config_dword(pdev->bus,
++ PCI_DEVFN(PCI_SLOT(pdev->devfn), 5),
++ REG_TDP_RUNNING_AVERAGE, val);
++}
++
+ static void __devinit fam15h_power_init_data(struct pci_dev *f4,
+ struct fam15h_power_data *data)
+ {
+@@ -155,6 +187,13 @@ static int __devinit fam15h_power_probe(
+ struct device *dev;
+ int err;
+
++ /*
++ * though we ignore every other northbridge, we still have to
++ * do the tweaking on _each_ node in MCM processors as the counters
++ * are working hand-in-hand
++ */
++ tweak_runavg_range(pdev);
++
+ if (!fam15h_power_is_internal_node0(pdev)) {
+ err = -ENODEV;
+ goto exit;
--- /dev/null
+From c3e40a9972428d6e2d8e287ed0233a57a218c30f Mon Sep 17 00:00:00 2001
+From: Guenter Roeck <guenter.roeck@ericsson.com>
+Date: Wed, 25 Apr 2012 13:44:20 -0700
+Subject: hwmon: (fam15h_power) Fix pci_device_id array
+
+From: Guenter Roeck <guenter.roeck@ericsson.com>
+
+commit c3e40a9972428d6e2d8e287ed0233a57a218c30f upstream.
+
+pci_match_id() takes an *array* of IDs which must be properly zero-
+terminated.
+
+Reported-by: Ben Hutchings <ben@decadent.org.uk>
+Signed-off-by: Guenter Roeck <guenter.roeck@ericsson.com>
+Acked-by: Jean Delvare <khali@linux-fr.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/hwmon/fam15h_power.c | 9 ++++++---
+ 1 file changed, 6 insertions(+), 3 deletions(-)
+
+--- a/drivers/hwmon/fam15h_power.c
++++ b/drivers/hwmon/fam15h_power.c
+@@ -128,17 +128,20 @@ static bool __devinit fam15h_power_is_in
+ * counter saturations resulting in bogus power readings.
+ * We correct this value ourselves to cope with older BIOSes.
+ */
++static DEFINE_PCI_DEVICE_TABLE(affected_device) = {
++ { PCI_VDEVICE(AMD, PCI_DEVICE_ID_AMD_15H_NB_F4) },
++ { 0 }
++};
++
+ static void __devinit tweak_runavg_range(struct pci_dev *pdev)
+ {
+ u32 val;
+- const struct pci_device_id affected_device = {
+- PCI_VDEVICE(AMD, PCI_DEVICE_ID_AMD_15H_NB_F4) };
+
+ /*
+ * let this quirk apply only to the current version of the
+ * northbridge, since future versions may change the behavior
+ */
+- if (!pci_match_id(&affected_device, pdev))
++ if (!pci_match_id(affected_device, pdev))
+ return;
+
+ pci_bus_read_config_dword(pdev->bus,
--- /dev/null
+From 98a2139f4f4d7b5fcc3a54c7fddbe88612abed20 Mon Sep 17 00:00:00 2001
+From: Jan Kara <jack@suse.cz>
+Date: Sat, 3 Sep 2011 01:09:43 +0200
+Subject: nfs: Enclose hostname in brackets when needed in
+ nfs_do_root_mount
+
+From: Jan Kara <jack@suse.cz>
+
+commit 98a2139f4f4d7b5fcc3a54c7fddbe88612abed20 upstream.
+
+When hostname contains colon (e.g. when it is an IPv6 address) it needs
+to be enclosed in brackets to make parsing of NFS device string possible.
+Fix nfs_do_root_mount() to enclose hostname properly when needed. NFS code
+actually does not need this as it does not parse the string passed by
+nfs_do_root_mount() but the device string is exposed to userspace in
+/proc/mounts.
+
+CC: Josh Boyer <jwboyer@redhat.com>
+CC: Trond Myklebust <Trond.Myklebust@netapp.com>
+Signed-off-by: Jan Kara <jack@suse.cz>
+Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ fs/nfs/super.c | 8 ++++++--
+ 1 file changed, 6 insertions(+), 2 deletions(-)
+
+--- a/fs/nfs/super.c
++++ b/fs/nfs/super.c
+@@ -2694,11 +2694,15 @@ static struct vfsmount *nfs_do_root_moun
+ char *root_devname;
+ size_t len;
+
+- len = strlen(hostname) + 3;
++ len = strlen(hostname) + 5;
+ root_devname = kmalloc(len, GFP_KERNEL);
+ if (root_devname == NULL)
+ return ERR_PTR(-ENOMEM);
+- snprintf(root_devname, len, "%s:/", hostname);
++ /* Does hostname needs to be enclosed in brackets? */
++ if (strchr(hostname, ':'))
++ snprintf(root_devname, len, "[%s]:/", hostname);
++ else
++ snprintf(root_devname, len, "%s:/", hostname);
+ root_mnt = vfs_kern_mount(fs_type, flags, root_devname, data);
+ kfree(root_devname);
+ return root_mnt;
--- /dev/null
+From 05ffe24f5290dc095f98fbaf84afe51ef404ccc5 Mon Sep 17 00:00:00 2001
+From: Trond Myklebust <Trond.Myklebust@netapp.com>
+Date: Wed, 18 Apr 2012 12:20:10 -0400
+Subject: NFSv4: Ensure that the LOCK code sets exception->inode
+
+From: Trond Myklebust <Trond.Myklebust@netapp.com>
+
+commit 05ffe24f5290dc095f98fbaf84afe51ef404ccc5 upstream.
+
+All callers of nfs4_handle_exception() that need to handle
+NFS4ERR_OPENMODE correctly should set exception->inode
+
+Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ fs/nfs/nfs4proc.c | 9 +++++++--
+ 1 file changed, 7 insertions(+), 2 deletions(-)
+
+--- a/fs/nfs/nfs4proc.c
++++ b/fs/nfs/nfs4proc.c
+@@ -4424,7 +4424,9 @@ static int _nfs4_do_setlk(struct nfs4_st
+ static int nfs4_lock_reclaim(struct nfs4_state *state, struct file_lock *request)
+ {
+ struct nfs_server *server = NFS_SERVER(state->inode);
+- struct nfs4_exception exception = { };
++ struct nfs4_exception exception = {
++ .inode = state->inode,
++ };
+ int err;
+
+ do {
+@@ -4442,7 +4444,9 @@ static int nfs4_lock_reclaim(struct nfs4
+ static int nfs4_lock_expired(struct nfs4_state *state, struct file_lock *request)
+ {
+ struct nfs_server *server = NFS_SERVER(state->inode);
+- struct nfs4_exception exception = { };
++ struct nfs4_exception exception = {
++ .inode = state->inode,
++ };
+ int err;
+
+ err = nfs4_set_lock_state(state, request);
+@@ -4508,6 +4512,7 @@ static int nfs4_proc_setlk(struct nfs4_s
+ {
+ struct nfs4_exception exception = {
+ .state = state,
++ .inode = state->inode,
+ };
+ int err;
+
--- /dev/null
+From 55725513b5ef9d462aa3e18527658a0362aaae83 Mon Sep 17 00:00:00 2001
+From: Trond Myklebust <Trond.Myklebust@netapp.com>
+Date: Wed, 18 Apr 2012 12:48:35 -0400
+Subject: NFSv4: Ensure that we check lock exclusive/shared type against open modes
+
+From: Trond Myklebust <Trond.Myklebust@netapp.com>
+
+commit 55725513b5ef9d462aa3e18527658a0362aaae83 upstream.
+
+Since we may be simulating flock() locks using NFS byte range locks,
+we can't rely on the VFS having checked the file open mode for us.
+
+Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ fs/nfs/nfs4proc.c | 14 ++++++++++++++
+ 1 file changed, 14 insertions(+)
+
+--- a/fs/nfs/nfs4proc.c
++++ b/fs/nfs/nfs4proc.c
+@@ -4558,6 +4558,20 @@ nfs4_proc_lock(struct file *filp, int cm
+
+ if (state == NULL)
+ return -ENOLCK;
++ /*
++ * Don't rely on the VFS having checked the file open mode,
++ * since it won't do this for flock() locks.
++ */
++ switch (request->fl_type & (F_RDLCK|F_WRLCK|F_UNLCK)) {
++ case F_RDLCK:
++ if (!(filp->f_mode & FMODE_READ))
++ return -EBADF;
++ break;
++ case F_WRLCK:
++ if (!(filp->f_mode & FMODE_WRITE))
++ return -EBADF;
++ }
++
+ do {
+ status = nfs4_proc_setlk(state, cmd, request);
+ if ((status != -EAGAIN) || IS_SETLK(cmd))
--- /dev/null
+From 2b5f8b0b44e17e625cfba1e7b88db44f4dcc0441 Mon Sep 17 00:00:00 2001
+From: Johannes Berg <johannes.berg@intel.com>
+Date: Mon, 2 Apr 2012 10:51:55 +0200
+Subject: nl80211: ensure interface is up in various APIs
+
+From: Johannes Berg <johannes.berg@intel.com>
+
+commit 2b5f8b0b44e17e625cfba1e7b88db44f4dcc0441 upstream.
+[backported by Ben Greear]
+
+The nl80211 handling code should ensure as much as
+it can that the interface is in a valid state, it
+can certainly ensure the interface is running.
+
+Not doing so can cause calls through mac80211 into
+the driver that result in warnings and unspecified
+behaviour in the driver.
+
+Reported-by: Ben Greear <greearb@candelatech.com>
+Signed-off-by: Johannes Berg <johannes.berg@intel.com>
+Signed-off-by: John W. Linville <linville@tuxdriver.com>
+Signed-off-by: Ben Greear <greearb@candelatech.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ net/wireless/nl80211.c | 29 +++++++++++++++++------------
+ 1 file changed, 17 insertions(+), 12 deletions(-)
+
+--- a/net/wireless/nl80211.c
++++ b/net/wireless/nl80211.c
+@@ -1181,6 +1181,11 @@ static int nl80211_set_wiphy(struct sk_b
+ goto bad_res;
+ }
+
++ if (!netif_running(netdev)) {
++ result = -ENETDOWN;
++ goto bad_res;
++ }
++
+ nla_for_each_nested(nl_txq_params,
+ info->attrs[NL80211_ATTR_WIPHY_TXQ_PARAMS],
+ rem_txq_params) {
+@@ -5432,7 +5437,7 @@ static struct genl_ops nl80211_ops[] = {
+ .doit = nl80211_get_key,
+ .policy = nl80211_policy,
+ .flags = GENL_ADMIN_PERM,
+- .internal_flags = NL80211_FLAG_NEED_NETDEV |
++ .internal_flags = NL80211_FLAG_NEED_NETDEV_UP |
+ NL80211_FLAG_NEED_RTNL,
+ },
+ {
+@@ -5464,7 +5469,7 @@ static struct genl_ops nl80211_ops[] = {
+ .policy = nl80211_policy,
+ .flags = GENL_ADMIN_PERM,
+ .doit = nl80211_addset_beacon,
+- .internal_flags = NL80211_FLAG_NEED_NETDEV |
++ .internal_flags = NL80211_FLAG_NEED_NETDEV_UP |
+ NL80211_FLAG_NEED_RTNL,
+ },
+ {
+@@ -5472,7 +5477,7 @@ static struct genl_ops nl80211_ops[] = {
+ .policy = nl80211_policy,
+ .flags = GENL_ADMIN_PERM,
+ .doit = nl80211_addset_beacon,
+- .internal_flags = NL80211_FLAG_NEED_NETDEV |
++ .internal_flags = NL80211_FLAG_NEED_NETDEV_UP |
+ NL80211_FLAG_NEED_RTNL,
+ },
+ {
+@@ -5496,7 +5501,7 @@ static struct genl_ops nl80211_ops[] = {
+ .doit = nl80211_set_station,
+ .policy = nl80211_policy,
+ .flags = GENL_ADMIN_PERM,
+- .internal_flags = NL80211_FLAG_NEED_NETDEV |
++ .internal_flags = NL80211_FLAG_NEED_NETDEV_UP |
+ NL80211_FLAG_NEED_RTNL,
+ },
+ {
+@@ -5512,7 +5517,7 @@ static struct genl_ops nl80211_ops[] = {
+ .doit = nl80211_del_station,
+ .policy = nl80211_policy,
+ .flags = GENL_ADMIN_PERM,
+- .internal_flags = NL80211_FLAG_NEED_NETDEV |
++ .internal_flags = NL80211_FLAG_NEED_NETDEV_UP |
+ NL80211_FLAG_NEED_RTNL,
+ },
+ {
+@@ -5545,7 +5550,7 @@ static struct genl_ops nl80211_ops[] = {
+ .doit = nl80211_del_mpath,
+ .policy = nl80211_policy,
+ .flags = GENL_ADMIN_PERM,
+- .internal_flags = NL80211_FLAG_NEED_NETDEV |
++ .internal_flags = NL80211_FLAG_NEED_NETDEV_UP |
+ NL80211_FLAG_NEED_RTNL,
+ },
+ {
+@@ -5553,7 +5558,7 @@ static struct genl_ops nl80211_ops[] = {
+ .doit = nl80211_set_bss,
+ .policy = nl80211_policy,
+ .flags = GENL_ADMIN_PERM,
+- .internal_flags = NL80211_FLAG_NEED_NETDEV |
++ .internal_flags = NL80211_FLAG_NEED_NETDEV_UP |
+ NL80211_FLAG_NEED_RTNL,
+ },
+ {
+@@ -5579,7 +5584,7 @@ static struct genl_ops nl80211_ops[] = {
+ .doit = nl80211_get_mesh_config,
+ .policy = nl80211_policy,
+ /* can be retrieved by unprivileged users */
+- .internal_flags = NL80211_FLAG_NEED_NETDEV |
++ .internal_flags = NL80211_FLAG_NEED_NETDEV_UP |
+ NL80211_FLAG_NEED_RTNL,
+ },
+ {
+@@ -5711,7 +5716,7 @@ static struct genl_ops nl80211_ops[] = {
+ .doit = nl80211_setdel_pmksa,
+ .policy = nl80211_policy,
+ .flags = GENL_ADMIN_PERM,
+- .internal_flags = NL80211_FLAG_NEED_NETDEV |
++ .internal_flags = NL80211_FLAG_NEED_NETDEV_UP |
+ NL80211_FLAG_NEED_RTNL,
+ },
+ {
+@@ -5719,7 +5724,7 @@ static struct genl_ops nl80211_ops[] = {
+ .doit = nl80211_setdel_pmksa,
+ .policy = nl80211_policy,
+ .flags = GENL_ADMIN_PERM,
+- .internal_flags = NL80211_FLAG_NEED_NETDEV |
++ .internal_flags = NL80211_FLAG_NEED_NETDEV_UP |
+ NL80211_FLAG_NEED_RTNL,
+ },
+ {
+@@ -5727,7 +5732,7 @@ static struct genl_ops nl80211_ops[] = {
+ .doit = nl80211_flush_pmksa,
+ .policy = nl80211_policy,
+ .flags = GENL_ADMIN_PERM,
+- .internal_flags = NL80211_FLAG_NEED_NETDEV |
++ .internal_flags = NL80211_FLAG_NEED_NETDEV_UP |
+ NL80211_FLAG_NEED_RTNL,
+ },
+ {
+@@ -5815,7 +5820,7 @@ static struct genl_ops nl80211_ops[] = {
+ .doit = nl80211_set_wds_peer,
+ .policy = nl80211_policy,
+ .flags = GENL_ADMIN_PERM,
+- .internal_flags = NL80211_FLAG_NEED_NETDEV |
++ .internal_flags = NL80211_FLAG_NEED_NETDEV_UP |
+ NL80211_FLAG_NEED_RTNL,
+ },
+ {
--- /dev/null
+From fcbf94b9dedd2ce08e798a99aafc94fec8668161 Mon Sep 17 00:00:00 2001
+From: Linus Torvalds <torvalds@linux-foundation.org>
+Date: Sat, 28 Apr 2012 08:29:56 -0700
+Subject: Revert "autofs: work around unhappy compat problem on x86-64"
+
+From: Linus Torvalds <torvalds@linux-foundation.org>
+
+commit fcbf94b9dedd2ce08e798a99aafc94fec8668161 upstream.
+
+This reverts commit a32744d4abae24572eff7269bc17895c41bd0085.
+
+While that commit was technically the right thing to do, and made the
+x86-64 compat mode work identically to native 32-bit mode (and thus
+fixing the problem with a 32-bit systemd install on a 64-bit kernel), it
+turns out that the automount binaries had workarounds for this compat
+problem.
+
+Now, the workarounds are disgusting: doing an "uname()" to find out the
+architecture of the kernel, and then comparing it for the 64-bit cases
+and fixing up the size of the read() in automount for those. And they
+were confused: it's not actually a generic 64-bit issue at all, it's
+very much tied to just x86-64, which has different alignment for an
+'u64' in 64-bit mode than in 32-bit mode.
+
+But the end result is that fixing the compat layer actually breaks the
+case of a 32-bit automount on a x86-64 kernel.
+
+There are various approaches to fix this (including just doing a
+"strcmp()" on current->comm and comparing it to "automount"), but I
+think that I will do the one that teaches pipes about a special "packet
+mode", which will allow user space to not have to care too deeply about
+the padding at the end of the autofs packet.
+
+That change will make the compat workaround unnecessary, so let's revert
+it first, and get automount working again in compat mode. The
+packetized pipes will then fix autofs for systemd.
+
+Reported-and-requested-by: Michael Tokarev <mjt@tls.msk.ru>
+Cc: Ian Kent <raven@themaw.net>
+Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ fs/autofs4/autofs_i.h | 1 -
+ fs/autofs4/dev-ioctl.c | 1 -
+ fs/autofs4/inode.c | 2 --
+ fs/autofs4/waitq.c | 20 ++------------------
+ 4 files changed, 2 insertions(+), 22 deletions(-)
+
+--- a/fs/autofs4/autofs_i.h
++++ b/fs/autofs4/autofs_i.h
+@@ -120,7 +120,6 @@ struct autofs_sb_info {
+ int sub_version;
+ int min_proto;
+ int max_proto;
+- int compat_daemon;
+ unsigned long exp_timeout;
+ unsigned int type;
+ int reghost_enabled;
+--- a/fs/autofs4/dev-ioctl.c
++++ b/fs/autofs4/dev-ioctl.c
+@@ -385,7 +385,6 @@ static int autofs_dev_ioctl_setpipefd(st
+ sbi->pipefd = pipefd;
+ sbi->pipe = pipe;
+ sbi->catatonic = 0;
+- sbi->compat_daemon = is_compat_task();
+ }
+ out:
+ mutex_unlock(&sbi->wq_mutex);
+--- a/fs/autofs4/inode.c
++++ b/fs/autofs4/inode.c
+@@ -19,7 +19,6 @@
+ #include <linux/parser.h>
+ #include <linux/bitops.h>
+ #include <linux/magic.h>
+-#include <linux/compat.h>
+ #include "autofs_i.h"
+ #include <linux/module.h>
+
+@@ -225,7 +224,6 @@ int autofs4_fill_super(struct super_bloc
+ set_autofs_type_indirect(&sbi->type);
+ sbi->min_proto = 0;
+ sbi->max_proto = 0;
+- sbi->compat_daemon = is_compat_task();
+ mutex_init(&sbi->wq_mutex);
+ spin_lock_init(&sbi->fs_lock);
+ sbi->queues = NULL;
+--- a/fs/autofs4/waitq.c
++++ b/fs/autofs4/waitq.c
+@@ -91,23 +91,6 @@ static int autofs4_write(struct file *fi
+ return (bytes > 0);
+ }
+
+-/*
+- * The autofs_v5 packet was misdesigned.
+- *
+- * The packets are identical on x86-32 and x86-64, but have different
+- * alignment. Which means that 'sizeof()' will give different results.
+- * Fix it up for the case of running 32-bit user mode on a 64-bit kernel.
+- */
+-static noinline size_t autofs_v5_packet_size(struct autofs_sb_info *sbi)
+-{
+- size_t pktsz = sizeof(struct autofs_v5_packet);
+-#if defined(CONFIG_X86_64) && defined(CONFIG_COMPAT)
+- if (sbi->compat_daemon > 0)
+- pktsz -= 4;
+-#endif
+- return pktsz;
+-}
+-
+ static void autofs4_notify_daemon(struct autofs_sb_info *sbi,
+ struct autofs_wait_queue *wq,
+ int type)
+@@ -164,7 +147,8 @@ static void autofs4_notify_daemon(struct
+ {
+ struct autofs_v5_packet *packet = &pkt.v5_pkt.v5_packet;
+
+- pktsz = autofs_v5_packet_size(sbi);
++ pktsz = sizeof(*packet);
++
+ packet->wait_queue_token = wq->wait_queue_token;
+ packet->len = wq->name.len;
+ memcpy(packet->name, wq->name.name, wq->name.len);
--- /dev/null
+nfs-enclose-hostname-in-brackets-when-needed-in.patch
+nfsv4-ensure-that-the-lock-code-sets-exception-inode.patch
+nfsv4-ensure-that-we-check-lock-exclusive-shared-type-against-open-modes.patch
+x86-apic-apic-code-touches-invalid-msr-on-p5-class-machines.patch
+revert-autofs-work-around-unhappy-compat-problem-on-x86-64.patch
+xen-correctly-check-for-pending-events-when-restoring-irq-flags.patch
+xen-smp-fix-crash-when-booting-with-acpi-hotplug-cpus.patch
+asoc-dapm-ensure-power-gets-managed-for-line-widgets.patch
+dmaengine-at_hdmac-remove-clear-on-read-in-atc_dostart.patch
+hwmon-fam15h_power-fix-bogus-values-with-current-bioses.patch
+hwmon-fam15h_power-fix-pci_device_id-array.patch
+drm-i915-handle-input-output-sdvo-timings-separately-in-mode_set.patch
+drm-i915-fix-integer-overflow-in-i915_gem_execbuffer2.patch
+drm-i915-fix-integer-overflow-in-i915_gem_do_execbuffer.patch
+nl80211-ensure-interface-is-up-in-various-apis.patch
+alsa-hda-realtek-add-quirk-for-mac-pro-5-1-machines.patch
--- /dev/null
+From cbf2829b61c136edcba302a5e1b6b40e97d32c00 Mon Sep 17 00:00:00 2001
+From: Bryan O'Donoghue <bryan.odonoghue@linux.intel.com>
+Date: Wed, 18 Apr 2012 17:37:39 +0100
+Subject: x86, apic: APIC code touches invalid MSR on P5 class machines
+
+From: Bryan O'Donoghue <bryan.odonoghue@linux.intel.com>
+
+commit cbf2829b61c136edcba302a5e1b6b40e97d32c00 upstream.
+
+Current APIC code assumes MSR_IA32_APICBASE is present for all systems.
+Pentium Classic P5 and friends didn't have this MSR. MSR_IA32_APICBASE
+was introduced as an architectural MSR by Intel @ P6.
+
+Code paths that can touch this MSR invalidly are when vendor == Intel &&
+cpu-family == 5 and APIC bit is set in CPUID - or when you simply pass
+lapic on the kernel command line, on a P5.
+
+The below patch stops Linux incorrectly interfering with the
+MSR_IA32_APICBASE for P5 class machines. Other code paths exist that
+touch the MSR - however those paths are not currently reachable for a
+conformant P5.
+
+Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@linux.intel.com>
+Link: http://lkml.kernel.org/r/4F8EEDD3.1080404@linux.intel.com
+Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/x86/kernel/apic/apic.c | 34 ++++++++++++++++++++--------------
+ 1 file changed, 20 insertions(+), 14 deletions(-)
+
+--- a/arch/x86/kernel/apic/apic.c
++++ b/arch/x86/kernel/apic/apic.c
+@@ -1558,9 +1558,11 @@ static int __init apic_verify(void)
+ mp_lapic_addr = APIC_DEFAULT_PHYS_BASE;
+
+ /* The BIOS may have set up the APIC at some other address */
+- rdmsr(MSR_IA32_APICBASE, l, h);
+- if (l & MSR_IA32_APICBASE_ENABLE)
+- mp_lapic_addr = l & MSR_IA32_APICBASE_BASE;
++ if (boot_cpu_data.x86 >= 6) {
++ rdmsr(MSR_IA32_APICBASE, l, h);
++ if (l & MSR_IA32_APICBASE_ENABLE)
++ mp_lapic_addr = l & MSR_IA32_APICBASE_BASE;
++ }
+
+ pr_info("Found and enabled local APIC!\n");
+ return 0;
+@@ -1578,13 +1580,15 @@ int __init apic_force_enable(unsigned lo
+ * MSR. This can only be done in software for Intel P6 or later
+ * and AMD K7 (Model > 1) or later.
+ */
+- rdmsr(MSR_IA32_APICBASE, l, h);
+- if (!(l & MSR_IA32_APICBASE_ENABLE)) {
+- pr_info("Local APIC disabled by BIOS -- reenabling.\n");
+- l &= ~MSR_IA32_APICBASE_BASE;
+- l |= MSR_IA32_APICBASE_ENABLE | addr;
+- wrmsr(MSR_IA32_APICBASE, l, h);
+- enabled_via_apicbase = 1;
++ if (boot_cpu_data.x86 >= 6) {
++ rdmsr(MSR_IA32_APICBASE, l, h);
++ if (!(l & MSR_IA32_APICBASE_ENABLE)) {
++ pr_info("Local APIC disabled by BIOS -- reenabling.\n");
++ l &= ~MSR_IA32_APICBASE_BASE;
++ l |= MSR_IA32_APICBASE_ENABLE | addr;
++ wrmsr(MSR_IA32_APICBASE, l, h);
++ enabled_via_apicbase = 1;
++ }
+ }
+ return apic_verify();
+ }
+@@ -2112,10 +2116,12 @@ static void lapic_resume(void)
+ * FIXME! This will be wrong if we ever support suspend on
+ * SMP! We'll need to do this as part of the CPU restore!
+ */
+- rdmsr(MSR_IA32_APICBASE, l, h);
+- l &= ~MSR_IA32_APICBASE_BASE;
+- l |= MSR_IA32_APICBASE_ENABLE | mp_lapic_addr;
+- wrmsr(MSR_IA32_APICBASE, l, h);
++ if (boot_cpu_data.x86 >= 6) {
++ rdmsr(MSR_IA32_APICBASE, l, h);
++ l &= ~MSR_IA32_APICBASE_BASE;
++ l |= MSR_IA32_APICBASE_ENABLE | mp_lapic_addr;
++ wrmsr(MSR_IA32_APICBASE, l, h);
++ }
+ }
+
+ maxlvt = lapic_get_maxlvt();
--- /dev/null
+From 7eb7ce4d2e8991aff4ecb71a81949a907ca755ac Mon Sep 17 00:00:00 2001
+From: David Vrabel <david.vrabel@citrix.com>
+Date: Thu, 26 Apr 2012 19:44:06 +0100
+Subject: xen: correctly check for pending events when restoring irq flags
+
+From: David Vrabel <david.vrabel@citrix.com>
+
+commit 7eb7ce4d2e8991aff4ecb71a81949a907ca755ac upstream.
+
+In xen_restore_fl_direct(), xen_force_evtchn_callback() was being
+called even if no events were pending. This resulted in (depending on
+workload) about a 100 times as many xen_version hypercalls as
+necessary.
+
+Fix this by correcting the sense of the conditional jump.
+
+This seems to give a significant performance benefit for some
+workloads.
+
+There is some subtle tricksy "..since the check here is trying to
+check both pending and masked in a single cmpw, but I think this is
+correct. It will call check_events now only when the combined
+mask+pending word is 0x0001 (aka unmasked, pending)." (Ian)
+
+Acked-by: Ian Campbell <ian.campbell@citrix.com>
+Signed-off-by: David Vrabel <david.vrabel@citrix.com>
+Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/x86/xen/xen-asm.S | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/arch/x86/xen/xen-asm.S
++++ b/arch/x86/xen/xen-asm.S
+@@ -96,7 +96,7 @@ ENTRY(xen_restore_fl_direct)
+
+ /* check for unmasked and pending */
+ cmpw $0x0001, PER_CPU_VAR(xen_vcpu_info) + XEN_vcpu_info_pending
+- jz 1f
++ jnz 1f
+ 2: call check_events
+ 1:
+ ENDPATCH(xen_restore_fl_direct)
--- /dev/null
+From cf405ae612b0f7e2358db7ff594c0e94846137aa Mon Sep 17 00:00:00 2001
+From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
+Date: Thu, 26 Apr 2012 13:50:03 -0400
+Subject: xen/smp: Fix crash when booting with ACPI hotplug CPUs.
+
+From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
+
+commit cf405ae612b0f7e2358db7ff594c0e94846137aa upstream.
+
+When we boot on a machine that can hotplug CPUs and we
+are using 'dom0_max_vcpus=X' on the Xen hypervisor line
+to clip the amount of CPUs available to the initial domain,
+we get this:
+
+(XEN) Command line: com1=115200,8n1 dom0_mem=8G noreboot dom0_max_vcpus=8 sync_console mce_verbosity=verbose console=com1,vga loglvl=all guest_loglvl=all
+.. snip..
+DMI: Intel Corporation S2600CP/S2600CP, BIOS SE5C600.86B.99.99.x032.072520111118 07/25/2011
+.. snip.
+SMP: Allowing 64 CPUs, 32 hotplug CPUs
+installing Xen timer for CPU 7
+cpu 7 spinlock event irq 361
+NMI watchdog: disabled (cpu7): hardware events not enabled
+Brought up 8 CPUs
+.. snip..
+ [acpi processor finds the CPUs are not initialized and starts calling
+ arch_register_cpu, which creates /sys/devices/system/cpu/cpu8/online]
+CPU 8 got hotplugged
+CPU 9 got hotplugged
+CPU 10 got hotplugged
+.. snip..
+initcall 1_acpi_battery_init_async+0x0/0x1b returned 0 after 406 usecs
+calling erst_init+0x0/0x2bb @ 1
+
+ [and the scheduler sticks newly started tasks on the new CPUs, but
+ said CPUs cannot be initialized b/c the hypervisor has limited the
+ amount of vCPUS to 8 - as per the dom0_max_vcpus=8 flag.
+ The spinlock tries to kick the other CPU, but the structure for that
+ is not initialized and we crash.]
+BUG: unable to handle kernel paging request at fffffffffffffed8
+IP: [<ffffffff81035289>] xen_spin_lock+0x29/0x60
+PGD 180d067 PUD 180e067 PMD 0
+Oops: 0002 [#1] SMP
+CPU 7
+Modules linked in:
+
+Pid: 1, comm: swapper/0 Not tainted 3.4.0-rc2upstream-00001-gf5154e8 #1 Intel Corporation S2600CP/S2600CP
+RIP: e030:[<ffffffff81035289>] [<ffffffff81035289>] xen_spin_lock+0x29/0x60
+RSP: e02b:ffff8801fb9b3a70 EFLAGS: 00010282
+
+With this patch, we cap the amount of vCPUS that the initial domain
+can run, to exactly what dom0_max_vcpus=X has specified.
+
+In the future, if there is a hypercall that will allow a running
+domain to expand past its initial set of vCPUS, this patch should
+be re-evaluated.
+
+Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/x86/xen/smp.c | 15 +++++++++++++++
+ 1 file changed, 15 insertions(+)
+
+--- a/arch/x86/xen/smp.c
++++ b/arch/x86/xen/smp.c
+@@ -172,6 +172,7 @@ static void __init xen_fill_possible_map
+ static void __init xen_filter_cpu_maps(void)
+ {
+ int i, rc;
++ unsigned int subtract = 0;
+
+ if (!xen_initial_domain())
+ return;
+@@ -186,8 +187,22 @@ static void __init xen_filter_cpu_maps(v
+ } else {
+ set_cpu_possible(i, false);
+ set_cpu_present(i, false);
++ subtract++;
+ }
+ }
++#ifdef CONFIG_HOTPLUG_CPU
++ /* This is akin to using 'nr_cpus' on the Linux command line.
++ * Which is OK as when we use 'dom0_max_vcpus=X' we can only
++ * have up to X, while nr_cpu_ids is greater than X. This
++ * normally is not a problem, except when CPU hotplugging
++ * is involved and then there might be more than X CPUs
++ * in the guest - which will not work as there is no
++ * hypercall to expand the max number of VCPUs an already
++ * running guest has. So cap it up to X. */
++ if (subtract)
++ nr_cpu_ids = nr_cpu_ids - subtract;
++#endif
++
+ }
+
+ static void __init xen_smp_prepare_boot_cpu(void)
projects / thirdparty / kernel / stable-queue.git / commitdiff
