--- /dev/null
+From 57c8a456640fa3ca777652f11f2db4179a3e66b6 Mon Sep 17 00:00:00 2001
+From: Oliver Hartkopp <socketcan@hartkopp.net>
+Date: Tue, 18 May 2010 14:03:10 -0700
+Subject: can: Fix SJA1000 command register writes on SMP systems
+
+From: Oliver Hartkopp <socketcan@hartkopp.net>
+
+commit 57c8a456640fa3ca777652f11f2db4179a3e66b6 upstream.
+
+The SJA1000 command register is concurrently written in the rx-path to free
+the receive buffer _and_ in the tx-path to start the transmission.
+
+The SJA1000 data sheet, 6.4.4 COMMAND REGISTER (CMR) states:
+"Between two commands at least one internal clock cycle is needed in
+order to proceed. The internal clock is half of the external oscillator
+frequency."
+
+On SMP systems the current implementation leads to a write stall in the
+tx-path, which can be solved by adding some general locking and some time
+to settle the write_reg() operation for the command register.
+
+Thanks to Klaus Hitschler for the original fix and detailed problem
+description.
+
+This patch applies on net-2.6 and (with some offsets) on net-next-2.6 .
+
+Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net>
+Acked-by: Wolfgang Grandegger <wg@grandegger.com>
+Signed-off-by: David S. Miller <davem@davemloft.net>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+---
+ drivers/net/can/sja1000/sja1000.c | 20 +++++++++++++++++---
+ drivers/net/can/sja1000/sja1000.h | 1 +
+ 2 files changed, 18 insertions(+), 3 deletions(-)
+
+--- a/drivers/net/can/sja1000/sja1000.c
++++ b/drivers/net/can/sja1000/sja1000.c
+@@ -84,6 +84,20 @@ static struct can_bittiming_const sja100
+ .brp_inc = 1,
+ };
+
++static void sja1000_write_cmdreg(struct sja1000_priv *priv, u8 val)
++{
++ unsigned long flags;
++
++ /*
++ * The command register needs some locking and time to settle
++ * the write_reg() operation - especially on SMP systems.
++ */
++ spin_lock_irqsave(&priv->cmdreg_lock, flags);
++ priv->write_reg(priv, REG_CMR, val);
++ priv->read_reg(priv, REG_SR);
++ spin_unlock_irqrestore(&priv->cmdreg_lock, flags);
++}
++
+ static int sja1000_probe_chip(struct net_device *dev)
+ {
+ struct sja1000_priv *priv = netdev_priv(dev);
+@@ -279,7 +293,7 @@ static netdev_tx_t sja1000_start_xmit(st
+
+ can_put_echo_skb(skb, dev, 0);
+
+- priv->write_reg(priv, REG_CMR, CMD_TR);
++ sja1000_write_cmdreg(priv, CMD_TR);
+
+ return NETDEV_TX_OK;
+ }
+@@ -334,7 +348,7 @@ static void sja1000_rx(struct net_device
+ cf->data[i++] = 0;
+
+ /* release receive buffer */
+- priv->write_reg(priv, REG_CMR, CMD_RRB);
++ sja1000_write_cmdreg(priv, CMD_RRB);
+
+ netif_rx(skb);
+
+@@ -368,7 +382,7 @@ static int sja1000_err(struct net_device
+ cf->data[1] = CAN_ERR_CRTL_RX_OVERFLOW;
+ stats->rx_over_errors++;
+ stats->rx_errors++;
+- priv->write_reg(priv, REG_CMR, CMD_CDO); /* clear bit */
++ sja1000_write_cmdreg(priv, CMD_CDO); /* clear bit */
+ }
+
+ if (isrc & IRQ_EI) {
+--- a/drivers/net/can/sja1000/sja1000.h
++++ b/drivers/net/can/sja1000/sja1000.h
+@@ -165,6 +165,7 @@ struct sja1000_priv {
+
+ void __iomem *reg_base; /* ioremap'ed address to registers */
+ unsigned long irq_flags; /* for request_irq() */
++ spinlock_t cmdreg_lock; /* lock for concurrent cmd register writes */
+
+ u16 flags; /* custom mode flags */
+ u8 ocr; /* output control register */
--- /dev/null
+From cdc6e3d3968052cebb2f2ddcd742bff29fbd1a90 Mon Sep 17 00:00:00 2001
+From: Jan Beulich <JBeulich@novell.com>
+Date: Tue, 27 Apr 2010 14:01:20 -0700
+Subject: drivers/base/cpu.c: fix the output from /sys/devices/system/cpu/offline
+
+From: Jan Beulich <JBeulich@novell.com>
+
+commit cdc6e3d3968052cebb2f2ddcd742bff29fbd1a90 upstream.
+
+Without CONFIG_CPUMASK_OFFSTACK, simply inverting cpu_online_mask leads
+to CPUs beyond nr_cpu_ids to be displayed twice and CPUs not even
+possible to be displayed as offline.
+
+Signed-off-by: Jan Beulich <jbeulich@novell.com>
+Cc: Andi Kleen <ak@linux.intel.com>
+Cc: Stephen Rothwell <sfr@canb.auug.org.au>
+Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+---
+ drivers/base/cpu.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/base/cpu.c
++++ b/drivers/base/cpu.c
+@@ -149,7 +149,7 @@ static ssize_t print_cpus_offline(struct
+ /* display offline cpus < nr_cpu_ids */
+ if (!alloc_cpumask_var(&offline, GFP_KERNEL))
+ return -ENOMEM;
+- cpumask_complement(offline, cpu_online_mask);
++ cpumask_andnot(offline, cpu_possible_mask, cpu_online_mask);
+ n = cpulist_scnprintf(buf, len, offline);
+ free_cpumask_var(offline);
+
--- /dev/null
+From 654fc6073f68efa3b6c466825749e73e7fbb92cd Mon Sep 17 00:00:00 2001
+From: Chris Wilson <chris@chris-wilson.co.uk>
+Date: Thu, 27 May 2010 13:18:21 +0100
+Subject: drm/i915: Reject bind_to_gtt() early if object > aperture
+
+From: Chris Wilson <chris@chris-wilson.co.uk>
+
+commit 654fc6073f68efa3b6c466825749e73e7fbb92cd upstream.
+
+If the object is bigger than the entire aperture, reject it early
+before evicting everything in a vain attempt to find space.
+
+v2: Use E2BIG as suggested by Owain G. Ainsworth.
+
+Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
+Signed-off-by: Eric Anholt <eric@anholt.net>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+---
+ drivers/gpu/drm/i915/i915_gem.c | 8 ++++++++
+ 1 file changed, 8 insertions(+)
+
+--- a/drivers/gpu/drm/i915/i915_gem.c
++++ b/drivers/gpu/drm/i915/i915_gem.c
+@@ -2615,6 +2615,14 @@ i915_gem_object_bind_to_gtt(struct drm_g
+ return -EINVAL;
+ }
+
++ /* If the object is bigger than the entire aperture, reject it early
++ * before evicting everything in a vain attempt to find space.
++ */
++ if (obj->size > dev->gtt_total) {
++ DRM_ERROR("Attempting to bind an object larger than the aperture\n");
++ return -E2BIG;
++ }
++
+ search_free:
+ free_space = drm_mm_search_free(&dev_priv->mm.gtt_space,
+ obj->size, alignment, 0);
--- /dev/null
+From d211e90e28a074447584729018a39910d691d1a8 Mon Sep 17 00:00:00 2001
+From: Jouni Malinen <j@w1.fi>
+Date: Sun, 28 Mar 2010 22:29:52 -0700
+Subject: mac80211: Fix robust management frame handling (MFP)
+
+From: Jouni Malinen <j@w1.fi>
+
+commit d211e90e28a074447584729018a39910d691d1a8 upstream.
+
+Commit e34e09401ee9888dd662b2fca5d607794a56daf2 incorrectly removed
+use of ieee80211_has_protected() from the management frame case and in
+practice, made this validation drop all Action frames when MFP is
+enabled. This should have only been done for frames with Protected
+field set to zero.
+
+Signed-off-by: Jouni Malinen <j@w1.fi>
+Signed-off-by: John W. Linville <linville@tuxdriver.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+---
+ net/mac80211/rx.c | 3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+--- a/net/mac80211/rx.c
++++ b/net/mac80211/rx.c
+@@ -1220,7 +1220,8 @@ ieee80211_drop_unencrypted(struct ieee80
+ (rx->key || rx->sdata->drop_unencrypted)))
+ return -EACCES;
+ if (rx->sta && test_sta_flags(rx->sta, WLAN_STA_MFP)) {
+- if (unlikely(ieee80211_is_unicast_robust_mgmt_frame(rx->skb) &&
++ if (unlikely(!ieee80211_has_protected(fc) &&
++ ieee80211_is_unicast_robust_mgmt_frame(rx->skb) &&
+ rx->key))
+ return -EACCES;
+ /* BIP does not use Protected field, so need to check MMIE */
--- /dev/null
+From a2c40249a36d0b4d76d1caf6bf806e4ae5b06e8a Mon Sep 17 00:00:00 2001
+From: Shanyu Zhao <shanyu.zhao@intel.com>
+Date: Tue, 27 Apr 2010 11:15:12 -0700
+Subject: mac80211: fix rts threshold check
+
+From: Shanyu Zhao <shanyu.zhao@intel.com>
+
+commit a2c40249a36d0b4d76d1caf6bf806e4ae5b06e8a upstream.
+
+Currently whenever rts thresold is set, every packet will use RTS
+protection no matter its size exceeds the threshold or not. This is
+due to a bug in the rts threshold check.
+ if (len > tx->local->hw.wiphy->rts_threshold) {
+ txrc.rts = rts = true;
+ }
+Basically it is comparing an int (len) and a u32 (rts_threshold),
+and the variable len is assigned as:
+ len = min_t(int, tx->skb->len + FCS_LEN,
+ tx->local->hw.wiphy->frag_threshold);
+However, when frag_threshold is "-1", len is always "-1", which is
+0xffffffff therefore rts is always set to true.
+
+Signed-off-by: Shanyu Zhao <shanyu.zhao@intel.com>
+Reviewed-by: Johannes Berg <johannes@sipsolutions.net>
+Signed-off-by: John W. Linville <linville@tuxdriver.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+---
+ net/mac80211/tx.c | 5 +++--
+ 1 file changed, 3 insertions(+), 2 deletions(-)
+
+--- a/net/mac80211/tx.c
++++ b/net/mac80211/tx.c
+@@ -496,7 +496,8 @@ ieee80211_tx_h_rate_ctrl(struct ieee8021
+ struct ieee80211_hdr *hdr = (void *)tx->skb->data;
+ struct ieee80211_supported_band *sband;
+ struct ieee80211_rate *rate;
+- int i, len;
++ int i;
++ u32 len;
+ bool inval = false, rts = false, short_preamble = false;
+ struct ieee80211_tx_rate_control txrc;
+ u32 sta_flags;
+@@ -505,7 +506,7 @@ ieee80211_tx_h_rate_ctrl(struct ieee8021
+
+ sband = tx->local->hw.wiphy->bands[tx->channel->band];
+
+- len = min_t(int, tx->skb->len + FCS_LEN,
++ len = min_t(u32, tx->skb->len + FCS_LEN,
+ tx->local->hw.wiphy->frag_threshold);
+
+ /* set up the tx rate control struct we give the RC algo */
--- /dev/null
+From c2ef355bf3ef0b8006b96128726684fba47ac928 Mon Sep 17 00:00:00 2001
+From: Andres Salomon <dilinger@collabora.co.uk>
+Date: Thu, 25 Feb 2010 19:18:47 -0500
+Subject: mac80211: give warning if building w/out rate ctrl algorithm
+
+From: Andres Salomon <dilinger@collabora.co.uk>
+
+commit c2ef355bf3ef0b8006b96128726684fba47ac928 upstream.
+
+I discovered that if EMBEDDED=y, one can accidentally build a mac80211 stack
+and drivers w/ no rate control algorithm. For drivers like RTL8187 that don't
+supply their own RC algorithms, this will cause ieee80211_register_hw to
+fail (making the driver unusable).
+
+This will tell kconfig to provide a warning if no rate control algorithms
+have been selected. That'll at least warn the user; users that know that
+their drivers supply a rate control algorithm can safely ignore the
+warning, and those who don't know (or who expect to be using multiple
+drivers) can select a default RC algorithm.
+
+Signed-off-by: Andres Salomon <dilinger@collabora.co.uk>
+Signed-off-by: John W. Linville <linville@tuxdriver.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+---
+ net/mac80211/Kconfig | 9 +++++++++
+ 1 file changed, 9 insertions(+)
+
+--- a/net/mac80211/Kconfig
++++ b/net/mac80211/Kconfig
+@@ -15,8 +15,12 @@ comment "CFG80211 needs to be enabled fo
+
+ if MAC80211 != n
+
++config MAC80211_HAS_RC
++ def_bool n
++
+ config MAC80211_RC_PID
+ bool "PID controller based rate control algorithm" if EMBEDDED
++ select MAC80211_HAS_RC
+ ---help---
+ This option enables a TX rate control algorithm for
+ mac80211 that uses a PID controller to select the TX
+@@ -24,12 +28,14 @@ config MAC80211_RC_PID
+
+ config MAC80211_RC_MINSTREL
+ bool "Minstrel" if EMBEDDED
++ select MAC80211_HAS_RC
+ default y
+ ---help---
+ This option enables the 'minstrel' TX rate control algorithm
+
+ choice
+ prompt "Default rate control algorithm"
++ depends on MAC80211_HAS_RC
+ default MAC80211_RC_DEFAULT_MINSTREL
+ ---help---
+ This option selects the default rate control algorithm
+@@ -62,6 +68,9 @@ config MAC80211_RC_DEFAULT
+
+ endif
+
++comment "Some wireless drivers require a rate control algorithm"
++ depends on MAC80211_HAS_RC=n
++
+ config MAC80211_MESH
+ bool "Enable mac80211 mesh networking (pre-802.11s) support"
+ depends on MAC80211 && EXPERIMENTAL
--- /dev/null
+From e4146bb9088c01c8b6e82be11f0c371f8aff023c Mon Sep 17 00:00:00 2001
+From: Ben Hutchings <ben@decadent.org.uk>
+Date: Sun, 16 May 2010 02:28:49 +0100
+Subject: PCI: Disable MSI for MCP55 on P5N32-E SLI
+
+From: Ben Hutchings <ben@decadent.org.uk>
+
+commit e4146bb9088c01c8b6e82be11f0c371f8aff023c upstream.
+
+As reported in <http://bugs.debian.org/552299>, MSI appears to be
+broken for this on-board device. We already have a quirk for the
+P5N32-SLI Premium; extend it to cover both variants of the board.
+
+Reported-by: Romain DEGEZ <romain.degez@smartjog.com>
+Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
+Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+---
+ drivers/pci/quirks.c | 7 ++++---
+ 1 file changed, 4 insertions(+), 3 deletions(-)
+
+--- a/drivers/pci/quirks.c
++++ b/drivers/pci/quirks.c
+@@ -2185,15 +2185,16 @@ DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_S
+ DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_AMD, PCI_DEVICE_ID_AMD_8132_BRIDGE,
+ ht_enable_msi_mapping);
+
+-/* The P5N32-SLI Premium motherboard from Asus has a problem with msi
++/* The P5N32-SLI motherboards from Asus have a problem with msi
+ * for the MCP55 NIC. It is not yet determined whether the msi problem
+ * also affects other devices. As for now, turn off msi for this device.
+ */
+ static void __devinit nvenet_msi_disable(struct pci_dev *dev)
+ {
+- if (dmi_name_in_vendors("P5N32-SLI PREMIUM")) {
++ if (dmi_name_in_vendors("P5N32-SLI PREMIUM") ||
++ dmi_name_in_vendors("P5N32-E SLI")) {
+ dev_info(&dev->dev,
+- "Disabling msi for MCP55 NIC on P5N32-SLI Premium\n");
++ "Disabling msi for MCP55 NIC on P5N32-SLI\n");
+ dev->no_msi = 1;
+ }
+ }
--- /dev/null
+From 134b345081534235dbf228b1005c14590e0570ba Mon Sep 17 00:00:00 2001
+From: Matthew Wilcox <matthew@wil.cx>
+Date: Wed, 24 Mar 2010 07:11:01 -0600
+Subject: PCI quirk: Disable MSI on VIA K8T890 systems
+
+From: Matthew Wilcox <matthew@wil.cx>
+
+commit 134b345081534235dbf228b1005c14590e0570ba upstream.
+
+Bugzilla 15287 indicates that there's a problem with Message Signalled
+Interrupts on VIA K8T890 systems. Add a quirk to disable MSI on these
+systems.
+
+Signed-off-by: Matthew Wilcox <willy@linux.intel.com>
+Tested-by: Jan Kreuzer <kontrollator@gmx.de>
+Tested-by: lh <jarryson@gmail.com>
+Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+---
+ drivers/pci/quirks.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/drivers/pci/quirks.c
++++ b/drivers/pci/quirks.c
+@@ -2092,6 +2092,7 @@ static void __devinit quirk_disable_msi(
+ }
+ }
+ DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_AMD, PCI_DEVICE_ID_AMD_8131_BRIDGE, quirk_disable_msi);
++DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_VIA, 0xa238, quirk_disable_msi);
+
+ /* Go through the list of Hypertransport capabilities and
+ * return 1 if a HT MSI capability is found and enabled */
--- /dev/null
+From 9313ff450400e6a2ab10fe6b9bdb12a828329410 Mon Sep 17 00:00:00 2001
+From: Alex Deucher <alexdeucher@gmail.com>
+Date: Tue, 18 May 2010 10:42:53 -0400
+Subject: PCI quirks: disable msi on AMD rs4xx internal gfx bridges
+
+From: Alex Deucher <alexdeucher@gmail.com>
+
+commit 9313ff450400e6a2ab10fe6b9bdb12a828329410 upstream.
+
+Doesn't work reliably for internal gfx. Fixes kernel bug
+https://bugzilla.kernel.org/show_bug.cgi?id=15626.
+
+Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
+Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+---
+ drivers/pci/quirks.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/drivers/pci/quirks.c
++++ b/drivers/pci/quirks.c
+@@ -2093,6 +2093,7 @@ static void __devinit quirk_disable_msi(
+ }
+ DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_AMD, PCI_DEVICE_ID_AMD_8131_BRIDGE, quirk_disable_msi);
+ DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_VIA, 0xa238, quirk_disable_msi);
++DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_ATI, 0x5a3f, quirk_disable_msi);
+
+ /* Go through the list of Hypertransport capabilities and
+ * return 1 if a HT MSI capability is found and enabled */
usb-xhci-fix-issue-with-set-interface-after-stall.patch
usb-xhci-fix-check-for-room-on-the-ring.patch
usb-xhci-fix-wrong-usage-of-macro-trb_type.patch
+mac80211-give-warning-if-building-w-out-rate-ctrl-algorithm.patch
+mac80211-fix-robust-management-frame-handling-mfp.patch
+mac80211-fix-rts-threshold-check.patch
+drm-i915-reject-bind_to_gtt-early-if-object-aperture.patch
+drivers-base-cpu.c-fix-the-output-from-sys-devices-system-cpu-offline.patch
+can-fix-sja1000-command-register-writes-on-smp-systems.patch
+pci-quirk-disable-msi-on-via-k8t890-systems.patch
+pci-quirks-disable-msi-on-amd-rs4xx-internal-gfx-bridges.patch
+pci-disable-msi-for-mcp55-on-p5n32-e-sli.patch
+virtio_net-make-delayed-refill-more-reliable.patch
--- /dev/null
+From 39d321577405e8e269fd238b278aaf2425fa788a Mon Sep 17 00:00:00 2001
+From: Herbert Xu <herbert@gondor.apana.org.au>
+Date: Mon, 25 Jan 2010 15:51:01 -0800
+Subject: virtio_net: Make delayed refill more reliable
+
+From: Herbert Xu <herbert@gondor.apana.org.au>
+
+commit 39d321577405e8e269fd238b278aaf2425fa788a upstream.
+
+I have seen RX stalls on a machine that experienced a suspected
+OOM. After the stall, the RX buffer is empty on the guest side
+and there are exactly 16 entries available on the host side. As
+the number of entries is less than that required by a maximal
+skb, the host cannot proceed.
+
+The guest did not have a refill job scheduled.
+
+My diagnosis is that an OOM had occured, with the delayed refill
+job scheduled. The job was able to allocate at least one skb, but
+not enough to overcome the minimum required by the host to proceed.
+
+As the refill job would only reschedule itself if it failed completely
+to allocate any skbs, this would lead to an RX stall.
+
+The following patch removes this stall possibility by always
+rescheduling the refill job until the ring is totally refilled.
+
+Testing has shown that the RX stall no longer occurs whereas
+previously it would occur within a day.
+
+Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
+Acked-by: Rusty Russell <rusty@rustcorp.com.au>
+Signed-off-by: David S. Miller <davem@davemloft.net>
+Cc: Bruce Rogers <brogers@novell.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+---
+ drivers/net/virtio_net.c | 3 +--
+ 1 file changed, 1 insertion(+), 2 deletions(-)
+
+--- a/drivers/net/virtio_net.c
++++ b/drivers/net/virtio_net.c
+@@ -398,8 +398,7 @@ static void refill_work(struct work_stru
+
+ vi = container_of(work, struct virtnet_info, refill.work);
+ napi_disable(&vi->napi);
+- try_fill_recv(vi, GFP_KERNEL);
+- still_empty = (vi->num == 0);
++ still_empty = !try_fill_recv(vi, GFP_KERNEL);
+ napi_enable(&vi->napi);
+
+ /* In theory, this can happen: if we don't get any buffers in
projects / thirdparty / kernel / stable-queue.git / commitdiff
