--- /dev/null
+From 2e286947f1294239527c11f9f466ddce6466455b Mon Sep 17 00:00:00 2001
+From: Felix Fietkau <nbd@openwrt.org>
+Date: Wed, 9 Mar 2011 01:48:12 +0100
+Subject: ath9k: remove support for the FIF_PROMISC_IN_BSS filter flag
+
+From: Felix Fietkau <nbd@openwrt.org>
+
+commit 2e286947f1294239527c11f9f466ddce6466455b upstream.
+
+The hardware rx filter flag triggered by FIF_PROMISC_IN_BSS is overly broad
+and covers even frames with PHY errors. When this flag is enabled, this message
+shows up frequently during scanning or hardware resets:
+
+ath: Could not stop RX, we could be confusing the DMA engine when we start RX up
+
+Since promiscuous mode is usually not particularly useful, yet enabled by
+default by bridging (either used normally in 4-addr mode, or with hacks
+for various virtualization software), we should sacrifice it for better
+reliability during normal operation.
+
+This patch leaves it enabled if there are active monitor mode interfaces, since
+it's very useful for debugging.
+
+Signed-off-by: Felix Fietkau <nbd@openwrt.org>
+Signed-off-by: John W. Linville <linville@tuxdriver.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+---
+ drivers/net/wireless/ath/ath9k/recv.c | 4 +---
+ 1 file changed, 1 insertion(+), 3 deletions(-)
+
+--- a/drivers/net/wireless/ath/ath9k/recv.c
++++ b/drivers/net/wireless/ath/ath9k/recv.c
+@@ -439,9 +439,7 @@ u32 ath_calcrxfilter(struct ath_softc *s
+ * mode interface or when in monitor mode. AP mode does not need this
+ * since it receives all in-BSS frames anyway.
+ */
+- if (((sc->sc_ah->opmode != NL80211_IFTYPE_AP) &&
+- (sc->rx.rxfilter & FIF_PROMISC_IN_BSS)) ||
+- (sc->sc_ah->is_monitoring))
++ if (sc->sc_ah->is_monitoring)
+ rfilt |= ATH9K_RX_FILTER_PROM;
+
+ if (sc->rx.rxfilter & FIF_CONTROL)
--- /dev/null
+From ac45c12dfb3f727a5a7a3332ed9c11b4a5ab287e Mon Sep 17 00:00:00 2001
+From: Senthil Balasubramanian <senthilkumar@atheros.com>
+Date: Wed, 22 Dec 2010 21:14:20 +0530
+Subject: ath9k_hw: Fix incorrect macversion and macrev checks
+
+From: Senthil Balasubramanian <senthilkumar@atheros.com>
+
+commit ac45c12dfb3f727a5a7a3332ed9c11b4a5ab287e upstream.
+
+There are few places where we are checking for macversion and revsions
+before RTC is powered ON. However we are reading the macversion and
+revisions only after RTC is powered ON and so both macversion and
+revisions are actully zero and this leads to incorrect srev checks
+
+Incorrect srev checks can cause registers to be configured wrongly and can
+cause unexpected behavior. Fixing this seems to address the ASPM issue that
+we have observed. The laptop becomes very slow and hangs mostly with ASPM L1
+enabled without this fix.
+
+fix this by reading the macversion and revisisons even before we start
+using them. There is no reason why should we delay reading this info
+until RTC is powered on as this is just a register information.
+
+Signed-off-by: Senthil Balasubramanian <senthilkumar@atheros.com>
+Signed-off-by: John W. Linville <linville@tuxdriver.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+---
+ drivers/net/wireless/ath/ath9k/hw.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+--- a/drivers/net/wireless/ath/ath9k/hw.c
++++ b/drivers/net/wireless/ath/ath9k/hw.c
+@@ -504,6 +504,8 @@ static int __ath9k_hw_init(struct ath_hw
+ ah->WARegVal |= (AR_WA_D3_L1_DISABLE |
+ AR_WA_ASPM_TIMER_BASED_DISABLE);
+
++ ath9k_hw_read_revisions(ah);
++
+ if (!ath9k_hw_set_reset_reg(ah, ATH9K_RESET_POWER_ON)) {
+ ath_err(common, "Couldn't reset chip\n");
+ return -EIO;
+@@ -1083,8 +1085,6 @@ static bool ath9k_hw_set_reset_power_on(
+ return false;
+ }
+
+- ath9k_hw_read_revisions(ah);
+-
+ return ath9k_hw_set_reset(ah, ATH9K_RESET_WARM);
+ }
+
--- /dev/null
+From 0a8d7cb0c8182df7a28ad719780071178c386f0f Mon Sep 17 00:00:00 2001
+From: Senthil Balasubramanian <senthilkumar@atheros.com>
+Date: Wed, 22 Dec 2010 19:17:18 +0530
+Subject: ath9k_hw: read and backup AR_WA register value even before chip reset on.
+
+From: Senthil Balasubramanian <senthilkumar@atheros.com>
+
+commit 0a8d7cb0c8182df7a28ad719780071178c386f0f upstream.
+
+We need to read and backup AR_WA register value permanently and reading
+this after the chip is awakened results in this register being zeroed out.
+
+This seems to fix the ASPM with L1 enabled issue that we have observed.
+The laptop becomes very slow and hangs mostly with ASPM L1 enabled without
+this fix.
+
+Signed-off-by: Senthil Balasubramanian <senthilkumar@atheros.com>
+Signed-off-by: John W. Linville <linville@tuxdriver.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+---
+ drivers/net/wireless/ath/ath9k/hw.c | 17 +++++++++--------
+ 1 file changed, 9 insertions(+), 8 deletions(-)
+
+--- a/drivers/net/wireless/ath/ath9k/hw.c
++++ b/drivers/net/wireless/ath/ath9k/hw.c
+@@ -495,6 +495,15 @@ static int __ath9k_hw_init(struct ath_hw
+ if (ah->hw_version.devid == AR5416_AR9100_DEVID)
+ ah->hw_version.macVersion = AR_SREV_VERSION_9100;
+
++ /*
++ * Read back AR_WA into a permanent copy and set bits 14 and 17.
++ * We need to do this to avoid RMW of this register. We cannot
++ * read the reg when chip is asleep.
++ */
++ ah->WARegVal = REG_READ(ah, AR_WA);
++ ah->WARegVal |= (AR_WA_D3_L1_DISABLE |
++ AR_WA_ASPM_TIMER_BASED_DISABLE);
++
+ if (!ath9k_hw_set_reset_reg(ah, ATH9K_RESET_POWER_ON)) {
+ ath_err(common, "Couldn't reset chip\n");
+ return -EIO;
+@@ -563,14 +572,6 @@ static int __ath9k_hw_init(struct ath_hw
+
+ ath9k_hw_init_mode_regs(ah);
+
+- /*
+- * Read back AR_WA into a permanent copy and set bits 14 and 17.
+- * We need to do this to avoid RMW of this register. We cannot
+- * read the reg when chip is asleep.
+- */
+- ah->WARegVal = REG_READ(ah, AR_WA);
+- ah->WARegVal |= (AR_WA_D3_L1_DISABLE |
+- AR_WA_ASPM_TIMER_BASED_DISABLE);
+
+ if (ah->is_pciexpress)
+ ath9k_hw_configpcipowersave(ah, 0, 0);
--- /dev/null
+From 007c80a5497a3f9c8393960ec6e6efd30955dcb1 Mon Sep 17 00:00:00 2001
+From: Chris Wilson <chris@chris-wilson.co.uk>
+Date: Tue, 15 Mar 2011 11:40:00 +0000
+Subject: drm: Hold the mode mutex whilst probing for sysfs status
+
+From: Chris Wilson <chris@chris-wilson.co.uk>
+
+commit 007c80a5497a3f9c8393960ec6e6efd30955dcb1 upstream.
+
+As detect will use hw registers and may modify structures, it needs to be
+serialised by use of the dev->mode_config.mutex. Make it so.
+
+Otherwise, we may cause random crashes as the sysfs file is queried
+whilst a concurrent hotplug poll is being run. For example:
+
+[ 1189.189626] BUG: unable to handle kernel NULL pointer dereference at 00000100
+[ 1189.189821] IP: [<e0c22019>] intel_tv_detect_type+0xa2/0x203 [i915]
+[ 1189.190020] *pde = 00000000
+[ 1189.190104] Oops: 0000 [#1] SMP
+[ 1189.190209] last sysfs file: /sys/devices/pci0000:00/0000:00:02.0/drm/card0/card0-SVIDEO-1/status
+[ 1189.190412] Modules linked in: mperf cpufreq_conservative cpufreq_userspace cpufreq_powersave cpufreq_stats decnet uinput fuse loop joydev snd_hd a_codec_realtek snd_hda_intel snd_hda_codec snd_hwdep snd_pcm_oss snd_mixer_oss snd_pcm i915 snd_seq_midi snd_rawmidi snd_seq_midi_event snd_seq drm_kms_helper snd_timer uvcvideo d rm snd_seq_device eeepc_laptop tpm_tis usbhid videodev i2c_algo_bit v4l1_compat snd sparse_keymap i2c_core hid serio_raw tpm psmouse evdev tpm_bios rfkill shpchp ac processor rng_c ore battery video power_supply soundcore pci_hotplug button output snd_page_alloc usb_storage uas ext3 jbd mbcache sd_mod crc_t10dif ata_generic ahci libahci ata_piix libata uhci_h cd ehci_hcd scsi_mod usbcore thermal atl2 thermal_sys nls_base [last unloaded: scsi_wait_scan]
+[ 1189.192007]
+[ 1189.192007] Pid: 1464, comm: upowerd Not tainted 2.6.37-2-686 #1 ASUSTeK Computer INC. 701/701
+[ 1189.192007] EIP: 0060:[<e0c22019>] EFLAGS: 00010246 CPU: 0
+[ 1189.192007] EIP is at intel_tv_detect_type+0xa2/0x203 [i915]
+[ 1189.192007] EAX: 00000000 EBX: dca74000 ECX: e0f68004 EDX: 00068004
+[ 1189.192007] ESI: dd110c00 EDI: 400c0c37 EBP: dca7429c ESP: de365e2c
+[ 1189.192007] DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
+[ 1189.192007] Process upowerd (pid: 1464, ti=de364000 task=dcc8acb0 task.ti=de364000)
+[ 1189.192007] Stack: Mar 15 03:43:23 hostname kernel: [ 1189.192007] e0c2cda4 70000000 400c0c30 00000000 dd111000 de365e54 de365f24 dd110c00
+[ 1189.192007] e0c22203 01000000 00000003 00000000 00000000 00000000 00000000 4353544e
+[ 1189.192007] 30383420 00000069 00000000 00000000 00000000 00000000 00000000 00000000
+[ 1189.192007] Call Trace: Mar 15 03:43:23 hostname kernel: [ 1189.192007] [<e0c22203>] ? intel_tv_detect+0x89/0x12d [i915]
+[ 1189.192007] [<e0a9dcef>] ? status_show+0x0/0x2f [drm]
+[ 1189.192007] [<e0a9dd03>] ? status_show+0x14/0x2f [drm]
+
+[Digression: what is upowerd doing reading those power hungry files?]
+
+Reported-by: Paul Menzel <paulepanter@users.sourceforge.net>
+Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
+Signed-off-by: Dave Airlie <airlied@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+---
+ drivers/gpu/drm/drm_sysfs.c | 7 +++++++
+ 1 file changed, 7 insertions(+)
+
+--- a/drivers/gpu/drm/drm_sysfs.c
++++ b/drivers/gpu/drm/drm_sysfs.c
+@@ -158,8 +158,15 @@ static ssize_t status_show(struct device
+ {
+ struct drm_connector *connector = to_drm_connector(device);
+ enum drm_connector_status status;
++ int ret;
++
++ ret = mutex_lock_interruptible(&connector->dev->mode_config.mutex);
++ if (ret)
++ return ret;
+
+ status = connector->funcs->detect(connector, true);
++ mutex_unlock(&connector->dev->mode_config.mutex);
++
+ return snprintf(buf, PAGE_SIZE, "%s\n",
+ drm_get_connector_status_name(status));
+ }
--- /dev/null
+From 8692d00e996ed2a6560702623e5cb646da0f9767 Mon Sep 17 00:00:00 2001
+From: Chris Wilson <chris@chris-wilson.co.uk>
+Date: Sat, 5 Feb 2011 10:08:21 +0000
+Subject: drm/i915: Replace vblank PM QoS with "Interrupt-Based AGPBUSY#"
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Chris Wilson <chris@chris-wilson.co.uk>
+
+commit 8692d00e996ed2a6560702623e5cb646da0f9767 upstream.
+
+I stumbled over this magic bit in the gen3 INSTPM:
+
+Bit11 Interrupt-Based AGPBUSY# Enable:
+
+‘0’ = Pending GMCH interrupts will not cause AGPBUSY# assertion.
+‘1’ = Pending GMCH interrupts will cause AGPBUSY# assertion and hence
+ can cause the CPU to exit C3. There is no suppression of cacheable
+ writes.
+
+Note that in either case in C3 the interrupts are not lost. They will be
+forwarded to the ICH when the GMCH is out of C3.
+
+Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
+Tested-by: Daniel Vetter <daniel.vetter@ffwll.ch>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+---
+ drivers/gpu/drm/i915/i915_irq.c | 9 +++++++++
+ drivers/gpu/drm/i915/i915_reg.h | 5 ++++-
+ 2 files changed, 13 insertions(+), 1 deletion(-)
+
+--- a/drivers/gpu/drm/i915/i915_irq.c
++++ b/drivers/gpu/drm/i915/i915_irq.c
+@@ -1377,7 +1377,12 @@ int i915_enable_vblank(struct drm_device
+ else
+ i915_enable_pipestat(dev_priv, pipe,
+ PIPE_VBLANK_INTERRUPT_ENABLE);
++
++ /* maintain vblank delivery even in deep C-states */
++ if (dev_priv->info->gen == 3)
++ I915_WRITE(INSTPM, INSTPM_AGPBUSY_DIS << 16);
+ spin_unlock_irqrestore(&dev_priv->irq_lock, irqflags);
++
+ return 0;
+ }
+
+@@ -1390,6 +1395,10 @@ void i915_disable_vblank(struct drm_devi
+ unsigned long irqflags;
+
+ spin_lock_irqsave(&dev_priv->irq_lock, irqflags);
++ if (dev_priv->info->gen == 3)
++ I915_WRITE(INSTPM,
++ INSTPM_AGPBUSY_DIS << 16 | INSTPM_AGPBUSY_DIS);
++
+ if (HAS_PCH_SPLIT(dev))
+ ironlake_disable_display_irq(dev_priv, (pipe == 0) ?
+ DE_PIPEA_VBLANK: DE_PIPEB_VBLANK);
+--- a/drivers/gpu/drm/i915/i915_reg.h
++++ b/drivers/gpu/drm/i915/i915_reg.h
+@@ -405,9 +405,12 @@
+ #define I915_ERROR_INSTRUCTION (1<<0)
+ #define INSTPM 0x020c0
+ #define INSTPM_SELF_EN (1<<12) /* 915GM only */
++#define INSTPM_AGPBUSY_DIS (1<<11) /* gen3: when disabled, pending interrupts
++ will not assert AGPBUSY# and will only
++ be delivered when out of C3. */
+ #define ACTHD 0x020c8
+ #define FW_BLC 0x020d8
+-#define FW_BLC2 0x020dc
++#define FW_BLC2 0x020dc
+ #define FW_BLC_SELF 0x020e0 /* 915+ only */
+ #define FW_BLC_SELF_EN_MASK (1<<31)
+ #define FW_BLC_SELF_FIFO_MASK (1<<16) /* 945 only */
--- /dev/null
+From 942b0e95c34f1ba432d08e1c0288ed032d32c3b2 Mon Sep 17 00:00:00 2001
+From: Alex Deucher <alexdeucher@gmail.com>
+Date: Mon, 14 Mar 2011 23:18:00 -0400
+Subject: drm/radeon/kms: fix typo in atom overscan setup
+
+From: Alex Deucher <alexdeucher@gmail.com>
+
+commit 942b0e95c34f1ba432d08e1c0288ed032d32c3b2 upstream.
+
+Typo in the aspect scale setup.
+
+Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
+Signed-off-by: Dave Airlie <airlied@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+---
+ drivers/gpu/drm/radeon/atombios_crtc.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+--- a/drivers/gpu/drm/radeon/atombios_crtc.c
++++ b/drivers/gpu/drm/radeon/atombios_crtc.c
+@@ -61,8 +61,8 @@ static void atombios_overscan_setup(stru
+ args.usOverscanLeft = cpu_to_le16((adjusted_mode->crtc_hdisplay - (a2 / mode->crtc_vdisplay)) / 2);
+ args.usOverscanRight = cpu_to_le16((adjusted_mode->crtc_hdisplay - (a2 / mode->crtc_vdisplay)) / 2);
+ } else if (a2 > a1) {
+- args.usOverscanLeft = cpu_to_le16((adjusted_mode->crtc_vdisplay - (a1 / mode->crtc_hdisplay)) / 2);
+- args.usOverscanRight = cpu_to_le16((adjusted_mode->crtc_vdisplay - (a1 / mode->crtc_hdisplay)) / 2);
++ args.usOverscanTop = cpu_to_le16((adjusted_mode->crtc_vdisplay - (a1 / mode->crtc_hdisplay)) / 2);
++ args.usOverscanBottom = cpu_to_le16((adjusted_mode->crtc_vdisplay - (a1 / mode->crtc_hdisplay)) / 2);
+ }
+ break;
+ case RMX_FULL:
--- /dev/null
+From 294d95f2cbc2aef5346258f216cd9df570e271a5 Mon Sep 17 00:00:00 2001
+From: Matthew Garrett <mjg@redhat.com>
+Date: Tue, 11 Jan 2011 12:26:48 -0500
+Subject: ehci: Check individual port status registers on resume
+
+From: Matthew Garrett <mjg@redhat.com>
+
+commit 294d95f2cbc2aef5346258f216cd9df570e271a5 upstream.
+
+If a device plug/unplug is detected on an ATI SB700 USB controller in D3,
+it appears to set the port status register but not the controller status
+register. As a result we'll fail to detect the plug event. Check the port
+status register on resume as well in order to catch this case.
+
+Signed-off-by: Matthew Garrett <mjg@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+---
+ drivers/usb/host/ehci-hub.c | 23 ++++++++++++++++++++++-
+ 1 file changed, 22 insertions(+), 1 deletion(-)
+
+--- a/drivers/usb/host/ehci-hub.c
++++ b/drivers/usb/host/ehci-hub.c
+@@ -106,6 +106,27 @@ static void ehci_handover_companion_port
+ ehci->owned_ports = 0;
+ }
+
++static int ehci_port_change(struct ehci_hcd *ehci)
++{
++ int i = HCS_N_PORTS(ehci->hcs_params);
++
++ /* First check if the controller indicates a change event */
++
++ if (ehci_readl(ehci, &ehci->regs->status) & STS_PCD)
++ return 1;
++
++ /*
++ * Not all controllers appear to update this while going from D3 to D0,
++ * so check the individual port status registers as well
++ */
++
++ while (i--)
++ if (ehci_readl(ehci, &ehci->regs->port_status[i]) & PORT_CSC)
++ return 1;
++
++ return 0;
++}
++
+ static void ehci_adjust_port_wakeup_flags(struct ehci_hcd *ehci,
+ bool suspending, bool do_wakeup)
+ {
+@@ -173,7 +194,7 @@ static void ehci_adjust_port_wakeup_flag
+ }
+
+ /* Does the root hub have a port wakeup pending? */
+- if (!suspending && (ehci_readl(ehci, &ehci->regs->status) & STS_PCD))
++ if (!suspending && ehci_port_change(ehci))
+ usb_hcd_resume_root_hub(ehci_to_hcd(ehci));
+
+ spin_unlock_irqrestore(&ehci->lock, flags);
--- /dev/null
+From 6410db593e8c1b2b79a2f18554310d6da9415584 Mon Sep 17 00:00:00 2001
+From: Larry Finger <Larry.Finger@lwfinger.net>
+Date: Mon, 28 Feb 2011 23:36:09 -0600
+Subject: rtl8187: Change rate-control feedback
+
+From: Larry Finger <Larry.Finger@lwfinger.net>
+
+commit 6410db593e8c1b2b79a2f18554310d6da9415584 upstream.
+
+The driver for the RTL8187L chips returns IEEE80211_TX_STAT_ACK for all
+packets, even if the maximum number of retries was exhausted. In addition
+it fails to setup max_rates in the ieee80211_hw struct, This behavior
+may be responsible for the problems noted in Bug 14168. As the bug is very
+old, testers have not been found, and I do not have the case where the
+indicated signal is less than -70 dBm.
+
+Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
+Acked-by: Hin-Tak Leung <htl10@users.sourceforge.net>
+Signed-off-by: John W. Linville <linville@tuxdriver.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+---
+ drivers/net/wireless/rtl818x/rtl8187/dev.c | 25 ++++++++++++++++++++-----
+ drivers/net/wireless/rtl818x/rtl8187/rtl8187.h | 2 ++
+ 2 files changed, 22 insertions(+), 5 deletions(-)
+
+--- a/drivers/net/wireless/rtl818x/rtl8187/dev.c
++++ b/drivers/net/wireless/rtl818x/rtl8187/dev.c
+@@ -871,23 +871,35 @@ static void rtl8187_work(struct work_str
+ /* The RTL8187 returns the retry count through register 0xFFFA. In
+ * addition, it appears to be a cumulative retry count, not the
+ * value for the current TX packet. When multiple TX entries are
+- * queued, the retry count will be valid for the last one in the queue.
+- * The "error" should not matter for purposes of rate setting. */
++ * waiting in the queue, the retry count will be the total for all.
++ * The "error" may matter for purposes of rate setting, but there is
++ * no other choice with this hardware.
++ */
+ struct rtl8187_priv *priv = container_of(work, struct rtl8187_priv,
+ work.work);
+ struct ieee80211_tx_info *info;
+ struct ieee80211_hw *dev = priv->dev;
+ static u16 retry;
+ u16 tmp;
++ u16 avg_retry;
++ int length;
+
+ mutex_lock(&priv->conf_mutex);
+ tmp = rtl818x_ioread16(priv, (__le16 *)0xFFFA);
++ length = skb_queue_len(&priv->b_tx_status.queue);
++ if (unlikely(!length))
++ length = 1;
++ if (unlikely(tmp < retry))
++ tmp = retry;
++ avg_retry = (tmp - retry) / length;
+ while (skb_queue_len(&priv->b_tx_status.queue) > 0) {
+ struct sk_buff *old_skb;
+
+ old_skb = skb_dequeue(&priv->b_tx_status.queue);
+ info = IEEE80211_SKB_CB(old_skb);
+- info->status.rates[0].count = tmp - retry + 1;
++ info->status.rates[0].count = avg_retry + 1;
++ if (info->status.rates[0].count > RETRY_COUNT)
++ info->flags &= ~IEEE80211_TX_STAT_ACK;
+ ieee80211_tx_status_irqsafe(dev, old_skb);
+ }
+ retry = tmp;
+@@ -933,8 +945,8 @@ static int rtl8187_start(struct ieee8021
+ rtl818x_iowrite32(priv, &priv->map->TX_CONF,
+ RTL818X_TX_CONF_HW_SEQNUM |
+ RTL818X_TX_CONF_DISREQQSIZE |
+- (7 << 8 /* short retry limit */) |
+- (7 << 0 /* long retry limit */) |
++ (RETRY_COUNT << 8 /* short retry limit */) |
++ (RETRY_COUNT << 0 /* long retry limit */) |
+ (7 << 21 /* MAX TX DMA */));
+ rtl8187_init_urbs(dev);
+ rtl8187b_init_status_urb(dev);
+@@ -1378,6 +1390,9 @@ static int __devinit rtl8187_probe(struc
+ dev->flags = IEEE80211_HW_HOST_BROADCAST_PS_BUFFERING |
+ IEEE80211_HW_SIGNAL_DBM |
+ IEEE80211_HW_RX_INCLUDES_FCS;
++ /* Initialize rate-control variables */
++ dev->max_rates = 1;
++ dev->max_rate_tries = RETRY_COUNT;
+
+ eeprom.data = dev;
+ eeprom.register_read = rtl8187_eeprom_register_read;
+--- a/drivers/net/wireless/rtl818x/rtl8187/rtl8187.h
++++ b/drivers/net/wireless/rtl818x/rtl8187/rtl8187.h
+@@ -35,6 +35,8 @@
+ #define RFKILL_MASK_8187_89_97 0x2
+ #define RFKILL_MASK_8198 0x4
+
++#define RETRY_COUNT 7
++
+ struct rtl8187_rx_info {
+ struct urb *urb;
+ struct ieee80211_hw *dev;
--- /dev/null
+From 95926d2db6256e08d06b753752a0d903a0580acc Mon Sep 17 00:00:00 2001
+From: Yin Kangkai <kangkai.yin@linux.intel.com>
+Date: Wed, 9 Feb 2011 11:34:20 +0800
+Subject: serial: also set the uartclk value in resume after goes to highspeed
+
+From: Yin Kangkai <kangkai.yin@linux.intel.com>
+
+commit 95926d2db6256e08d06b753752a0d903a0580acc upstream.
+
+For any reason if the NS16550A was not work in high speed mode (e.g. we hold
+NS16550A from going to high speed mode in autoconfig_16550a()), now we are
+resume from suspend, we should also set the uartclk to the correct
+value. Otherwise it is still the old 1843200 and that will bring issues.
+
+CC: Greg Kroah-Hartman <greg@kroah.com>
+CC: David Woodhouse <dwmw2@infradead.org>
+CC: linux-kernel@vger.kernel.org
+Signed-off-by: Yin Kangkai <kangkai.yin@linux.intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+---
+ drivers/tty/serial/8250.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/drivers/tty/serial/8250.c
++++ b/drivers/tty/serial/8250.c
+@@ -3036,6 +3036,7 @@ void serial8250_resume_port(int line)
+ serial_outp(up, 0x04, tmp);
+
+ serial_outp(up, UART_LCR, 0);
++ up->port.uartclk = 921600*16;
+ }
+ uart_resume_port(&serial8250_reg, &up->port);
+ }
--- /dev/null
+From 0d0389e5414c8950b1613e8bdc74289cde3d6d98 Mon Sep 17 00:00:00 2001
+From: Yin Kangkai <kangkai.yin@linux.intel.com>
+Date: Wed, 9 Feb 2011 11:35:18 +0800
+Subject: serial: change the divisor latch only when prescalar actually changed
+
+From: Yin Kangkai <kangkai.yin@linux.intel.com>
+
+commit 0d0389e5414c8950b1613e8bdc74289cde3d6d98 upstream.
+
+In 8250.c original ns16550 autoconfig code, we change the divisor latch when
+we goto to high speed mode, we're assuming the previous speed is legacy. This
+some times is not true.
+
+For example in a system with both CONFIG_SERIAL_8250 and
+CONFIG_SERIAL_8250_PNP set, in this case, the code (autoconfig) will be called
+twice, one in serial8250_init/probe() and the other is from
+serial_pnp_probe. When serial_pnp_probe calls the autoconfig for NS16550A,
+it's already in high speed mode, change the divisor latch (quot << 3) in this
+case will make the UART console garbled.
+
+CC: Greg Kroah-Hartman <greg@kroah.com>
+CC: David Woodhouse <dwmw2@infradead.org>
+CC: linux-kernel@vger.kernel.org
+Signed-off-by: Yin Kangkai <kangkai.yin@linux.intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+---
+ drivers/tty/serial/8250.c | 32 ++++++++++++++++++++------------
+ 1 file changed, 20 insertions(+), 12 deletions(-)
+
+--- a/drivers/tty/serial/8250.c
++++ b/drivers/tty/serial/8250.c
+@@ -954,6 +954,23 @@ static int broken_efr(struct uart_8250_p
+ return 0;
+ }
+
++static inline int ns16550a_goto_highspeed(struct uart_8250_port *up)
++{
++ unsigned char status;
++
++ status = serial_in(up, 0x04); /* EXCR2 */
++#define PRESL(x) ((x) & 0x30)
++ if (PRESL(status) == 0x10) {
++ /* already in high speed mode */
++ return 0;
++ } else {
++ status &= ~0xB0; /* Disable LOCK, mask out PRESL[01] */
++ status |= 0x10; /* 1.625 divisor for baud_base --> 921600 */
++ serial_outp(up, 0x04, status);
++ }
++ return 1;
++}
++
+ /*
+ * We know that the chip has FIFOs. Does it have an EFR? The
+ * EFR is located in the same register position as the IIR and
+@@ -1025,12 +1042,8 @@ static void autoconfig_16550a(struct uar
+ quot = serial_dl_read(up);
+ quot <<= 3;
+
+- status1 = serial_in(up, 0x04); /* EXCR2 */
+- status1 &= ~0xB0; /* Disable LOCK, mask out PRESL[01] */
+- status1 |= 0x10; /* 1.625 divisor for baud_base --> 921600 */
+- serial_outp(up, 0x04, status1);
+-
+- serial_dl_write(up, quot);
++ if (ns16550a_goto_highspeed(up))
++ serial_dl_write(up, quot);
+
+ serial_outp(up, UART_LCR, 0);
+
+@@ -3025,15 +3038,10 @@ void serial8250_resume_port(int line)
+ struct uart_8250_port *up = &serial8250_ports[line];
+
+ if (up->capabilities & UART_NATSEMI) {
+- unsigned char tmp;
+-
+ /* Ensure it's still in high speed mode */
+ serial_outp(up, UART_LCR, 0xE0);
+
+- tmp = serial_in(up, 0x04); /* EXCR2 */
+- tmp &= ~0xB0; /* Disable LOCK, mask out PRESL[01] */
+- tmp |= 0x10; /* 1.625 divisor for baud_base --> 921600 */
+- serial_outp(up, 0x04, tmp);
++ ns16550a_goto_highspeed(up);
+
+ serial_outp(up, UART_LCR, 0);
+ up->port.uartclk = 921600*16;
--- /dev/null
+From d8653d305ef66861c91fa7455fb8038460a7274c Mon Sep 17 00:00:00 2001
+From: Dan Carpenter <error27@gmail.com>
+Date: Tue, 25 Jan 2011 14:15:11 +0000
+Subject: serial: mrst_max3110: make buffer larger
+
+From: Dan Carpenter <error27@gmail.com>
+
+commit d8653d305ef66861c91fa7455fb8038460a7274c upstream.
+
+This is used to store the spi_device ->modalias so they have to be the same
+size. SPI_NAME_SIZE is 32.
+
+Signed-off-by: Dan Carpenter <error27@gmail.com>
+Signed-off-by: Alan Cox <alan@linux.intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+---
+ drivers/tty/serial/mrst_max3110.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/tty/serial/mrst_max3110.c
++++ b/drivers/tty/serial/mrst_max3110.c
+@@ -51,7 +51,7 @@
+ struct uart_max3110 {
+ struct uart_port port;
+ struct spi_device *spi;
+- char name[24];
++ char name[SPI_NAME_SIZE];
+
+ wait_queue_head_t wq;
+ struct task_struct *main_thread;
microblaze-fix-dev-zero-corruption-from-__clear_user.patch
x86-stop_machine_text_poke-should-issue-sync_core.patch
tomoyo-fix-memory-leak-upon-file-open.patch
+drm-i915-replace-vblank-pm-qos-with-interrupt-based-agpbusy.patch
+drm-radeon-kms-fix-typo-in-atom-overscan-setup.patch
+drm-hold-the-mode-mutex-whilst-probing-for-sysfs-status.patch
+ath9k_hw-read-and-backup-ar_wa-register-value-even-before-chip-reset-on.patch
+ath9k_hw-fix-incorrect-macversion-and-macrev-checks.patch
+ath9k-remove-support-for-the-fif_promisc_in_bss-filter-flag.patch
+serial-mrst_max3110-make-buffer-larger.patch
+serial-also-set-the-uartclk-value-in-resume-after-goes-to-highspeed.patch
+serial-change-the-divisor-latch-only-when-prescalar-actually-changed.patch
+usb-serial-drivers-need-to-use-larger-bulk-in-buffers.patch
+usb-serial-kobil_sct-fix-potential-tty-null-dereference.patch
+usb-serial-option-apply-option_blacklist_sendsetup-also-for-zte-mf626.patch
+usb-serial-ch341-add-new-id.patch
+staging-winbond-needs-linux-delay.h-for-msleep-and-friends.patch
+staging-tidspbridge-protect-dmm_map-properly.patch
+rtl8187-change-rate-control-feedback.patch
+usb-isp1760-implement-solution-for-erratum-2.patch
+ehci-check-individual-port-status-registers-on-resume.patch
+usb-move-usbcore-away-from-hcd-state.patch
+xhci-update-internal-dequeue-pointers-after-stalls.patch
+xhci-fix-cycle-bit-calculation-during-stall-handling.patch
+usb-add-support-for-superspeed-isoc-endpoints.patch
--- /dev/null
+From ab42abf33a3efdf754710a0a513c00c40854cd61 Mon Sep 17 00:00:00 2001
+From: Felipe Contreras <felipe.contreras@nokia.com>
+Date: Fri, 11 Mar 2011 18:29:06 -0600
+Subject: staging: tidspbridge: protect dmm_map properly
+
+From: Felipe Contreras <felipe.contreras@nokia.com>
+
+commit ab42abf33a3efdf754710a0a513c00c40854cd61 upstream.
+
+We need to protect not only the dmm_map list, but the individual
+map_obj's, otherwise, we might be building the scatter-gather list with
+garbage. So, use the existing proc_lock for that.
+
+I observed race conditions which caused kernel panics while running
+stress tests, also, Tuomas Kulve found it happening quite often in
+Gumstix Over. This patch fixes those.
+
+Cc: Tuomas Kulve <tuomas@kulve.fi>
+Signed-off-by: Felipe Contreras <felipe.contreras@nokia.com>
+Signed-off-by: Omar Ramirez Luna <omar.ramirez@ti.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+---
+ drivers/staging/tidspbridge/rmgr/proc.c | 19 ++++++++++++++-----
+ 1 file changed, 14 insertions(+), 5 deletions(-)
+
+--- a/drivers/staging/tidspbridge/rmgr/proc.c
++++ b/drivers/staging/tidspbridge/rmgr/proc.c
+@@ -781,12 +781,14 @@ int proc_begin_dma(void *hprocessor, voi
+ (u32)pmpu_addr,
+ ul_size, dir);
+
++ mutex_lock(&proc_lock);
++
+ /* find requested memory are in cached mapping information */
+ map_obj = find_containing_mapping(pr_ctxt, (u32) pmpu_addr, ul_size);
+ if (!map_obj) {
+ pr_err("%s: find_containing_mapping failed\n", __func__);
+ status = -EFAULT;
+- goto err_out;
++ goto no_map;
+ }
+
+ if (memory_give_ownership(map_obj, (u32) pmpu_addr, ul_size, dir)) {
+@@ -795,6 +797,8 @@ int proc_begin_dma(void *hprocessor, voi
+ status = -EFAULT;
+ }
+
++no_map:
++ mutex_unlock(&proc_lock);
+ err_out:
+
+ return status;
+@@ -819,21 +823,24 @@ int proc_end_dma(void *hprocessor, void
+ (u32)pmpu_addr,
+ ul_size, dir);
+
++ mutex_lock(&proc_lock);
++
+ /* find requested memory are in cached mapping information */
+ map_obj = find_containing_mapping(pr_ctxt, (u32) pmpu_addr, ul_size);
+ if (!map_obj) {
+ pr_err("%s: find_containing_mapping failed\n", __func__);
+ status = -EFAULT;
+- goto err_out;
++ goto no_map;
+ }
+
+ if (memory_regain_ownership(map_obj, (u32) pmpu_addr, ul_size, dir)) {
+ pr_err("%s: InValid address parameters %p %x\n",
+ __func__, pmpu_addr, ul_size);
+ status = -EFAULT;
+- goto err_out;
+ }
+
++no_map:
++ mutex_unlock(&proc_lock);
+ err_out:
+ return status;
+ }
+@@ -1726,9 +1733,8 @@ int proc_un_map(void *hprocessor, void *
+ (p_proc_object->hbridge_context, va_align, size_align);
+ }
+
+- mutex_unlock(&proc_lock);
+ if (status)
+- goto func_end;
++ goto unmap_failed;
+
+ /*
+ * A successful unmap should be followed by removal of map_obj
+@@ -1737,6 +1743,9 @@ int proc_un_map(void *hprocessor, void *
+ */
+ remove_mapping_information(pr_ctxt, (u32) map_addr, size_align);
+
++unmap_failed:
++ mutex_unlock(&proc_lock);
++
+ func_end:
+ dev_dbg(bridge, "%s: hprocessor: 0x%p map_addr: 0x%p status: 0x%x\n",
+ __func__, hprocessor, map_addr, status);
--- /dev/null
+From cecf826df8648c843ea8db63b1f82c154a74db36 Mon Sep 17 00:00:00 2001
+From: Jeff Mahoney <jeffm@suse.com>
+Date: Thu, 24 Feb 2011 14:49:00 -0500
+Subject: staging: winbond: needs <linux/delay.h> for msleep and friends
+
+From: Jeff Mahoney <jeffm@suse.com>
+
+commit cecf826df8648c843ea8db63b1f82c154a74db36 upstream.
+
+linux/delay.h is pulled in somehow on x86 but not on ia64 or powerpc.
+
+This fixes a build failure on those arches since they use [mu]delay.
+
+Signed-off-by: Jeff Mahoney <jeffm@suse.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+---
+ drivers/staging/winbond/core.h | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/drivers/staging/winbond/core.h
++++ b/drivers/staging/winbond/core.h
+@@ -3,6 +3,7 @@
+
+ #include <linux/wireless.h>
+ #include <linux/types.h>
++#include <linux/delay.h>
+
+ #include "wbhal.h"
+ #include "mto.h"
--- /dev/null
+From 500132a0f26ad7d9916102193cbc6c1b1becb373 Mon Sep 17 00:00:00 2001
+From: Paul Zimmerman <Paul.Zimmerman@synopsys.com>
+Date: Mon, 28 Feb 2011 18:11:27 -0800
+Subject: USB: Add support for SuperSpeed isoc endpoints
+
+From: Paul Zimmerman <Paul.Zimmerman@synopsys.com>
+
+commit 500132a0f26ad7d9916102193cbc6c1b1becb373 upstream.
+
+Use the Mult and bMaxBurst values from the endpoint companion
+descriptor to calculate the max length of an isoc transfer.
+
+Add USB_SS_MULT macro to access Mult field of bmAttributes, at
+Sarah's suggestion.
+
+This patch should be queued for the 2.6.36 and 2.6.37 stable trees, since
+those were the first kernels to have isochronous support for SuperSpeed
+devices.
+
+Signed-off-by: Paul Zimmerman <paulz@synopsys.com>
+Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+---
+ drivers/usb/core/urb.c | 11 ++++++++++-
+ include/linux/usb/ch9.h | 2 ++
+ 2 files changed, 12 insertions(+), 1 deletion(-)
+
+--- a/drivers/usb/core/urb.c
++++ b/drivers/usb/core/urb.c
+@@ -366,7 +366,16 @@ int usb_submit_urb(struct urb *urb, gfp_
+ if (xfertype == USB_ENDPOINT_XFER_ISOC) {
+ int n, len;
+
+- /* FIXME SuperSpeed isoc endpoints have up to 16 bursts */
++ /* SuperSpeed isoc endpoints have up to 16 bursts of up to
++ * 3 packets each
++ */
++ if (dev->speed == USB_SPEED_SUPER) {
++ int burst = 1 + ep->ss_ep_comp.bMaxBurst;
++ int mult = USB_SS_MULT(ep->ss_ep_comp.bmAttributes);
++ max *= burst;
++ max *= mult;
++ }
++
+ /* "high bandwidth" mode, 1-3 packets/uframe? */
+ if (dev->speed == USB_SPEED_HIGH) {
+ int mult = 1 + ((max >> 11) & 0x03);
+--- a/include/linux/usb/ch9.h
++++ b/include/linux/usb/ch9.h
+@@ -585,6 +585,8 @@ struct usb_ss_ep_comp_descriptor {
+ #define USB_DT_SS_EP_COMP_SIZE 6
+ /* Bits 4:0 of bmAttributes if this is a bulk endpoint */
+ #define USB_SS_MAX_STREAMS(p) (1 << (p & 0x1f))
++/* Bits 1:0 of bmAttributes if this is an isoc endpoint */
++#define USB_SS_MULT(p) (1 + ((p) & 0x3))
+
+ /*-------------------------------------------------------------------------*/
+
--- /dev/null
+From b14e840d04dba211fbdc930247e379085623eacd Mon Sep 17 00:00:00 2001
+From: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
+Date: Tue, 8 Feb 2011 21:07:40 +0100
+Subject: USB: isp1760: Implement solution for erratum 2
+
+From: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
+
+commit b14e840d04dba211fbdc930247e379085623eacd upstream.
+
+The document says:
+|2.1 Problem description
+| When at least two USB devices are simultaneously running, it is observed that
+| sometimes the INT corresponding to one of the USB devices stops occurring. This may
+| be observed sometimes with USB-to-serial or USB-to-network devices.
+| The problem is not noticed when only USB mass storage devices are running.
+|2.2 Implication
+| This issue is because of the clearing of the respective Done Map bit on reading the ATL
+| PTD Done Map register when an INT is generated by another PTD completion, but is not
+| found set on that read access. In this situation, the respective Done Map bit will remain
+| reset and no further INT will be asserted so the data transfer corresponding to that USB
+| device will stop.
+|2.3 Workaround
+| An SOF INT can be used instead of an ATL INT with polling on Done bits. A time-out can
+| be implemented and if a certain Done bit is never set, verification of the PTD completion
+| can be done by reading PTD contents (valid bit).
+| This is a proven workaround implemented in software.
+
+Russell King run into this with an USB-to-serial converter. This patch
+implements his suggestion to enable the high frequent SOF interrupt only
+at the time we have ATL packages queued. It goes even one step further
+and enables the SOF interrupt only if we have more than one ATL packet
+queued at the same time.
+
+Tested-by: Russell King <rmk+kernel@arm.linux.org.uk>
+Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+---
+ drivers/usb/host/isp1760-hcd.c | 22 ++++++++++++++++------
+ drivers/usb/host/isp1760-hcd.h | 1 +
+ 2 files changed, 17 insertions(+), 6 deletions(-)
+
+--- a/drivers/usb/host/isp1760-hcd.c
++++ b/drivers/usb/host/isp1760-hcd.c
+@@ -33,6 +33,7 @@ struct isp1760_hcd {
+ struct inter_packet_info atl_ints[32];
+ struct inter_packet_info int_ints[32];
+ struct memory_chunk memory_pool[BLOCKS];
++ u32 atl_queued;
+
+ /* periodic schedule support */
+ #define DEFAULT_I_TDPS 1024
+@@ -850,6 +851,11 @@ static void enqueue_an_ATL_packet(struct
+ skip_map &= ~queue_entry;
+ isp1760_writel(skip_map, hcd->regs + HC_ATL_PTD_SKIPMAP_REG);
+
++ priv->atl_queued++;
++ if (priv->atl_queued == 2)
++ isp1760_writel(INTERRUPT_ENABLE_SOT_MASK,
++ hcd->regs + HC_INTERRUPT_ENABLE);
++
+ buffstatus = isp1760_readl(hcd->regs + HC_BUFFER_STATUS_REG);
+ buffstatus |= ATL_BUFFER;
+ isp1760_writel(buffstatus, hcd->regs + HC_BUFFER_STATUS_REG);
+@@ -992,6 +998,7 @@ static void do_atl_int(struct usb_hcd *u
+ u32 dw3;
+
+ status = 0;
++ priv->atl_queued--;
+
+ queue_entry = __ffs(done_map);
+ done_map &= ~(1 << queue_entry);
+@@ -1054,11 +1061,6 @@ static void do_atl_int(struct usb_hcd *u
+ * device is not able to send data fast enough.
+ * This happens mostly on slower hardware.
+ */
+- printk(KERN_NOTICE "Reloading ptd %p/%p... qh %p read: "
+- "%d of %zu done: %08x cur: %08x\n", qtd,
+- urb, qh, PTD_XFERRED_LENGTH(dw3),
+- qtd->length, done_map,
+- (1 << queue_entry));
+
+ /* RL counter = ERR counter */
+ dw3 &= ~(0xf << 19);
+@@ -1086,6 +1088,11 @@ static void do_atl_int(struct usb_hcd *u
+ priv_write_copy(priv, (u32 *)&ptd, usb_hcd->regs +
+ atl_regs, sizeof(ptd));
+
++ priv->atl_queued++;
++ if (priv->atl_queued == 2)
++ isp1760_writel(INTERRUPT_ENABLE_SOT_MASK,
++ usb_hcd->regs + HC_INTERRUPT_ENABLE);
++
+ buffstatus = isp1760_readl(usb_hcd->regs +
+ HC_BUFFER_STATUS_REG);
+ buffstatus |= ATL_BUFFER;
+@@ -1191,6 +1198,9 @@ static void do_atl_int(struct usb_hcd *u
+ skip_map = isp1760_readl(usb_hcd->regs +
+ HC_ATL_PTD_SKIPMAP_REG);
+ }
++ if (priv->atl_queued <= 1)
++ isp1760_writel(INTERRUPT_ENABLE_MASK,
++ usb_hcd->regs + HC_INTERRUPT_ENABLE);
+ }
+
+ static void do_intl_int(struct usb_hcd *usb_hcd)
+@@ -1770,7 +1780,7 @@ static irqreturn_t isp1760_irq(struct us
+ goto leave;
+
+ isp1760_writel(imask, usb_hcd->regs + HC_INTERRUPT_REG);
+- if (imask & HC_ATL_INT)
++ if (imask & (HC_ATL_INT | HC_SOT_INT))
+ do_atl_int(usb_hcd);
+
+ if (imask & HC_INTL_INT)
+--- a/drivers/usb/host/isp1760-hcd.h
++++ b/drivers/usb/host/isp1760-hcd.h
+@@ -69,6 +69,7 @@ void deinit_kmem_cache(void);
+
+ #define HC_INTERRUPT_ENABLE 0x314
+ #define INTERRUPT_ENABLE_MASK (HC_INTL_INT | HC_ATL_INT | HC_EOT_INT)
++#define INTERRUPT_ENABLE_SOT_MASK (HC_INTL_INT | HC_SOT_INT | HC_EOT_INT)
+
+ #define HC_ISO_INT (1 << 9)
+ #define HC_ATL_INT (1 << 8)
--- /dev/null
+From 9b37596a2e860404503a3f2a6513db60c296bfdc Mon Sep 17 00:00:00 2001
+From: Alan Stern <stern@rowland.harvard.edu>
+Date: Mon, 7 Mar 2011 11:11:52 -0500
+Subject: USB: move usbcore away from hcd->state
+
+From: Alan Stern <stern@rowland.harvard.edu>
+
+commit 9b37596a2e860404503a3f2a6513db60c296bfdc upstream.
+
+The hcd->state variable is a disaster. It's not clearly owned by
+either usbcore or the host controller drivers, and they both change it
+from time to time, potentially stepping on each other's toes. It's
+not protected by any locks. And there's no mechanism to prevent it
+from going through an invalid transition.
+
+This patch (as1451) takes a first step toward fixing these problems.
+As it turns out, usbcore uses hcd->state for essentially only two
+things: checking whether the controller's root hub is running and
+checking whether the controller has died. Therefore the patch adds
+two new atomic bitflags to the hcd structure, to store these pieces of
+information. The new flags are used only by usbcore, and a private
+spinlock prevents invalid combinations (a dead controller's root hub
+cannot be running).
+
+The patch does not change the places where usbcore sets hcd->state,
+since HCDs may depend on them. Furthermore, there is one place in
+usb_hcd_irq() where usbcore still must use hcd->state: An HCD's
+interrupt handler can implicitly indicate that the controller died by
+setting hcd->state to HC_STATE_HALT. Nevertheless, the new code is a
+big improvement over the current code.
+
+The patch makes one other change. The hcd_bus_suspend() and
+hcd_bus_resume() routines now check first whether the host controller
+has died; if it has then they return immediately without calling the
+HCD's bus_suspend or bus_resume methods.
+
+This fixes the major problem reported in Bugzilla #29902: The system
+fails to suspend after a host controller dies during system resume.
+
+Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
+Tested-by: Alex Terekhov <a.terekhov@gmail.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+---
+ drivers/usb/core/hcd-pci.c | 13 ++++------
+ drivers/usb/core/hcd.c | 55 +++++++++++++++++++++++++++++++++------------
+ include/linux/usb/hcd.h | 4 +++
+ 3 files changed, 51 insertions(+), 21 deletions(-)
+
+--- a/drivers/usb/core/hcd-pci.c
++++ b/drivers/usb/core/hcd-pci.c
+@@ -363,8 +363,7 @@ static int check_root_hub_suspended(stru
+ struct pci_dev *pci_dev = to_pci_dev(dev);
+ struct usb_hcd *hcd = pci_get_drvdata(pci_dev);
+
+- if (!(hcd->state == HC_STATE_SUSPENDED ||
+- hcd->state == HC_STATE_HALT)) {
++ if (HCD_RH_RUNNING(hcd)) {
+ dev_warn(dev, "Root hub is not suspended\n");
+ return -EBUSY;
+ }
+@@ -386,7 +385,7 @@ static int suspend_common(struct device
+ if (retval)
+ return retval;
+
+- if (hcd->driver->pci_suspend) {
++ if (hcd->driver->pci_suspend && !HCD_DEAD(hcd)) {
+ /* Optimization: Don't suspend if a root-hub wakeup is
+ * pending and it would cause the HCD to wake up anyway.
+ */
+@@ -427,7 +426,7 @@ static int resume_common(struct device *
+ struct usb_hcd *hcd = pci_get_drvdata(pci_dev);
+ int retval;
+
+- if (hcd->state != HC_STATE_SUSPENDED) {
++ if (HCD_RH_RUNNING(hcd)) {
+ dev_dbg(dev, "can't resume, not suspended!\n");
+ return 0;
+ }
+@@ -442,7 +441,7 @@ static int resume_common(struct device *
+
+ clear_bit(HCD_FLAG_SAW_IRQ, &hcd->flags);
+
+- if (hcd->driver->pci_resume) {
++ if (hcd->driver->pci_resume && !HCD_DEAD(hcd)) {
+ if (event != PM_EVENT_AUTO_RESUME)
+ wait_for_companions(pci_dev, hcd);
+
+@@ -475,10 +474,10 @@ static int hcd_pci_suspend_noirq(struct
+
+ pci_save_state(pci_dev);
+
+- /* If the root hub is HALTed rather than SUSPENDed,
++ /* If the root hub is dead rather than suspended,
+ * disallow remote wakeup.
+ */
+- if (hcd->state == HC_STATE_HALT)
++ if (HCD_DEAD(hcd))
+ device_set_wakeup_enable(dev, 0);
+ dev_dbg(dev, "wakeup: %d\n", device_may_wakeup(dev));
+
+--- a/drivers/usb/core/hcd.c
++++ b/drivers/usb/core/hcd.c
+@@ -983,7 +983,7 @@ static int register_root_hub(struct usb_
+ spin_unlock_irq (&hcd_root_hub_lock);
+
+ /* Did the HC die before the root hub was registered? */
+- if (hcd->state == HC_STATE_HALT)
++ if (HCD_DEAD(hcd) || hcd->state == HC_STATE_HALT)
+ usb_hc_died (hcd); /* This time clean up */
+ }
+
+@@ -1089,13 +1089,10 @@ int usb_hcd_link_urb_to_ep(struct usb_hc
+ * Check the host controller's state and add the URB to the
+ * endpoint's queue.
+ */
+- switch (hcd->state) {
+- case HC_STATE_RUNNING:
+- case HC_STATE_RESUMING:
++ if (HCD_RH_RUNNING(hcd)) {
+ urb->unlinked = 0;
+ list_add_tail(&urb->urb_list, &urb->ep->urb_list);
+- break;
+- default:
++ } else {
+ rc = -ESHUTDOWN;
+ goto done;
+ }
+@@ -1913,7 +1910,7 @@ int usb_hcd_get_frame_number (struct usb
+ {
+ struct usb_hcd *hcd = bus_to_hcd(udev->bus);
+
+- if (!HC_IS_RUNNING (hcd->state))
++ if (!HCD_RH_RUNNING(hcd))
+ return -ESHUTDOWN;
+ return hcd->driver->get_frame_number (hcd);
+ }
+@@ -1930,9 +1927,15 @@ int hcd_bus_suspend(struct usb_device *r
+
+ dev_dbg(&rhdev->dev, "bus %s%s\n",
+ (msg.event & PM_EVENT_AUTO ? "auto-" : ""), "suspend");
++ if (HCD_DEAD(hcd)) {
++ dev_dbg(&rhdev->dev, "skipped %s of dead bus\n", "suspend");
++ return 0;
++ }
++
+ if (!hcd->driver->bus_suspend) {
+ status = -ENOENT;
+ } else {
++ clear_bit(HCD_FLAG_RH_RUNNING, &hcd->flags);
+ hcd->state = HC_STATE_QUIESCING;
+ status = hcd->driver->bus_suspend(hcd);
+ }
+@@ -1940,7 +1943,12 @@ int hcd_bus_suspend(struct usb_device *r
+ usb_set_device_state(rhdev, USB_STATE_SUSPENDED);
+ hcd->state = HC_STATE_SUSPENDED;
+ } else {
+- hcd->state = old_state;
++ spin_lock_irq(&hcd_root_hub_lock);
++ if (!HCD_DEAD(hcd)) {
++ set_bit(HCD_FLAG_RH_RUNNING, &hcd->flags);
++ hcd->state = old_state;
++ }
++ spin_unlock_irq(&hcd_root_hub_lock);
+ dev_dbg(&rhdev->dev, "bus %s fail, err %d\n",
+ "suspend", status);
+ }
+@@ -1955,9 +1963,13 @@ int hcd_bus_resume(struct usb_device *rh
+
+ dev_dbg(&rhdev->dev, "usb %s%s\n",
+ (msg.event & PM_EVENT_AUTO ? "auto-" : ""), "resume");
++ if (HCD_DEAD(hcd)) {
++ dev_dbg(&rhdev->dev, "skipped %s of dead bus\n", "resume");
++ return 0;
++ }
+ if (!hcd->driver->bus_resume)
+ return -ENOENT;
+- if (hcd->state == HC_STATE_RUNNING)
++ if (HCD_RH_RUNNING(hcd))
+ return 0;
+
+ hcd->state = HC_STATE_RESUMING;
+@@ -1966,10 +1978,15 @@ int hcd_bus_resume(struct usb_device *rh
+ if (status == 0) {
+ /* TRSMRCY = 10 msec */
+ msleep(10);
+- usb_set_device_state(rhdev, rhdev->actconfig
+- ? USB_STATE_CONFIGURED
+- : USB_STATE_ADDRESS);
+- hcd->state = HC_STATE_RUNNING;
++ spin_lock_irq(&hcd_root_hub_lock);
++ if (!HCD_DEAD(hcd)) {
++ usb_set_device_state(rhdev, rhdev->actconfig
++ ? USB_STATE_CONFIGURED
++ : USB_STATE_ADDRESS);
++ set_bit(HCD_FLAG_RH_RUNNING, &hcd->flags);
++ hcd->state = HC_STATE_RUNNING;
++ }
++ spin_unlock_irq(&hcd_root_hub_lock);
+ } else {
+ hcd->state = old_state;
+ dev_dbg(&rhdev->dev, "bus %s fail, err %d\n",
+@@ -2080,7 +2097,7 @@ irqreturn_t usb_hcd_irq (int irq, void *
+ */
+ local_irq_save(flags);
+
+- if (unlikely(hcd->state == HC_STATE_HALT || !HCD_HW_ACCESSIBLE(hcd))) {
++ if (unlikely(HCD_DEAD(hcd) || !HCD_HW_ACCESSIBLE(hcd))) {
+ rc = IRQ_NONE;
+ } else if (hcd->driver->irq(hcd) == IRQ_NONE) {
+ rc = IRQ_NONE;
+@@ -2114,6 +2131,8 @@ void usb_hc_died (struct usb_hcd *hcd)
+ dev_err (hcd->self.controller, "HC died; cleaning up\n");
+
+ spin_lock_irqsave (&hcd_root_hub_lock, flags);
++ clear_bit(HCD_FLAG_RH_RUNNING, &hcd->flags);
++ set_bit(HCD_FLAG_DEAD, &hcd->flags);
+ if (hcd->rh_registered) {
+ clear_bit(HCD_FLAG_POLL_RH, &hcd->flags);
+
+@@ -2256,6 +2275,12 @@ int usb_add_hcd(struct usb_hcd *hcd,
+ */
+ device_init_wakeup(&rhdev->dev, 1);
+
++ /* HCD_FLAG_RH_RUNNING doesn't matter until the root hub is
++ * registered. But since the controller can die at any time,
++ * let's initialize the flag before touching the hardware.
++ */
++ set_bit(HCD_FLAG_RH_RUNNING, &hcd->flags);
++
+ /* "reset" is misnamed; its role is now one-time init. the controller
+ * should already have been reset (and boot firmware kicked off etc).
+ */
+@@ -2323,6 +2348,7 @@ int usb_add_hcd(struct usb_hcd *hcd,
+ return retval;
+
+ error_create_attr_group:
++ clear_bit(HCD_FLAG_RH_RUNNING, &hcd->flags);
+ if (HC_IS_RUNNING(hcd->state))
+ hcd->state = HC_STATE_QUIESCING;
+ spin_lock_irq(&hcd_root_hub_lock);
+@@ -2375,6 +2401,7 @@ void usb_remove_hcd(struct usb_hcd *hcd)
+ usb_get_dev(rhdev);
+ sysfs_remove_group(&rhdev->dev.kobj, &usb_bus_attr_group);
+
++ clear_bit(HCD_FLAG_RH_RUNNING, &hcd->flags);
+ if (HC_IS_RUNNING (hcd->state))
+ hcd->state = HC_STATE_QUIESCING;
+
+--- a/include/linux/usb/hcd.h
++++ b/include/linux/usb/hcd.h
+@@ -99,6 +99,8 @@ struct usb_hcd {
+ #define HCD_FLAG_POLL_RH 2 /* poll for rh status? */
+ #define HCD_FLAG_POLL_PENDING 3 /* status has changed? */
+ #define HCD_FLAG_WAKEUP_PENDING 4 /* root hub is resuming? */
++#define HCD_FLAG_RH_RUNNING 5 /* root hub is running? */
++#define HCD_FLAG_DEAD 6 /* controller has died? */
+
+ /* The flags can be tested using these macros; they are likely to
+ * be slightly faster than test_bit().
+@@ -108,6 +110,8 @@ struct usb_hcd {
+ #define HCD_POLL_RH(hcd) ((hcd)->flags & (1U << HCD_FLAG_POLL_RH))
+ #define HCD_POLL_PENDING(hcd) ((hcd)->flags & (1U << HCD_FLAG_POLL_PENDING))
+ #define HCD_WAKEUP_PENDING(hcd) ((hcd)->flags & (1U << HCD_FLAG_WAKEUP_PENDING))
++#define HCD_RH_RUNNING(hcd) ((hcd)->flags & (1U << HCD_FLAG_RH_RUNNING))
++#define HCD_DEAD(hcd) ((hcd)->flags & (1U << HCD_FLAG_DEAD))
+
+ /* Flags that get set only during HCD registration or removal. */
+ unsigned rh_registered:1;/* is root hub registered? */
--- /dev/null
+From d0781383038e983a63843a9a6a067ed781db89c1 Mon Sep 17 00:00:00 2001
+From: wangyanqing <udknight@gmail.com>
+Date: Fri, 11 Mar 2011 06:24:38 -0800
+Subject: USB: serial: ch341: add new id
+
+From: wangyanqing <udknight@gmail.com>
+
+commit d0781383038e983a63843a9a6a067ed781db89c1 upstream.
+
+I picked up a new DAK-780EX(professional digitl reverb/mix system),
+which use CH341T chipset to communication with computer on 3/2011
+and the CH341T's vendor code is 1a86
+
+Looking up the CH341T's vendor and product id's I see:
+
+1a86 QinHeng Electronics
+ 5523 CH341 in serial mode, usb to serial port converter
+
+CH341T,CH341 are the products of the same company, maybe
+have some common hardware, and I test the ch341.c works
+well with CH341T
+
+Cc: Linus Torvalds <torvalds@linux-foundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+---
+ drivers/usb/serial/ch341.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/drivers/usb/serial/ch341.c
++++ b/drivers/usb/serial/ch341.c
+@@ -75,6 +75,7 @@ static int debug;
+ static const struct usb_device_id id_table[] = {
+ { USB_DEVICE(0x4348, 0x5523) },
+ { USB_DEVICE(0x1a86, 0x7523) },
++ { USB_DEVICE(0x1a86, 0x5523) },
+ { },
+ };
+ MODULE_DEVICE_TABLE(usb, id_table);
--- /dev/null
+From 969e3033ae7733a0af8f7742ca74cd16c0857e71 Mon Sep 17 00:00:00 2001
+From: Alan Stern <stern@rowland.harvard.edu>
+Date: Wed, 23 Feb 2011 15:28:18 -0500
+Subject: USB: serial drivers need to use larger bulk-in buffers
+
+From: Alan Stern <stern@rowland.harvard.edu>
+
+commit 969e3033ae7733a0af8f7742ca74cd16c0857e71 upstream.
+
+When a driver doesn't know how much data a device is going to send,
+the buffer size should be at least as big as the endpoint's maxpacket
+value. The serial drivers don't follow this rule; many of them
+request only 256-byte bulk-in buffers. As a result, they suffer
+overflow errors if a high-speed device wants to send a lot of data,
+because high-speed bulk endpoints are required to have a maxpacket
+size of 512.
+
+This patch (as1450) fixes the problem by using the driver's
+bulk_in_size value as a minimum, always allocating buffers no smaller
+than the endpoint's maxpacket size.
+
+Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
+Tested-by: Flynn Marquardt <flynn@flynnux.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+---
+ drivers/usb/serial/usb-serial.c | 5 ++---
+ include/linux/usb/serial.h | 3 ++-
+ 2 files changed, 4 insertions(+), 4 deletions(-)
+
+--- a/drivers/usb/serial/usb-serial.c
++++ b/drivers/usb/serial/usb-serial.c
+@@ -911,9 +911,8 @@ int usb_serial_probe(struct usb_interfac
+ dev_err(&interface->dev, "No free urbs available\n");
+ goto probe_error;
+ }
+- buffer_size = serial->type->bulk_in_size;
+- if (!buffer_size)
+- buffer_size = le16_to_cpu(endpoint->wMaxPacketSize);
++ buffer_size = max_t(int, serial->type->bulk_in_size,
++ le16_to_cpu(endpoint->wMaxPacketSize));
+ port->bulk_in_size = buffer_size;
+ port->bulk_in_endpointAddress = endpoint->bEndpointAddress;
+ port->bulk_in_buffer = kmalloc(buffer_size, GFP_KERNEL);
+--- a/include/linux/usb/serial.h
++++ b/include/linux/usb/serial.h
+@@ -191,7 +191,8 @@ static inline void usb_set_serial_data(s
+ * @id_table: pointer to a list of usb_device_id structures that define all
+ * of the devices this structure can support.
+ * @num_ports: the number of different ports this device will have.
+- * @bulk_in_size: bytes to allocate for bulk-in buffer (0 = end-point size)
++ * @bulk_in_size: minimum number of bytes to allocate for bulk-in buffer
++ * (0 = end-point size)
+ * @bulk_out_size: bytes to allocate for bulk-out buffer (0 = end-point size)
+ * @calc_num_ports: pointer to a function to determine how many ports this
+ * device has dynamically. It will be called after the probe()
--- /dev/null
+From 6960f40a954619857e7095a6179eef896f297077 Mon Sep 17 00:00:00 2001
+From: Jiri Slaby <jslaby@suse.cz>
+Date: Mon, 28 Feb 2011 10:34:06 +0100
+Subject: USB: serial/kobil_sct, fix potential tty NULL dereference
+
+From: Jiri Slaby <jslaby@suse.cz>
+
+commit 6960f40a954619857e7095a6179eef896f297077 upstream.
+
+Make sure that we check the return value of tty_port_tty_get.
+Sometimes it may return NULL and we later dereference that.
+
+The only place here is in kobil_read_int_callback, so fix it.
+
+Signed-off-by: Jiri Slaby <jslaby@suse.cz>
+Cc: Alan Cox <alan@linux.intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+---
+ drivers/usb/serial/kobil_sct.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/usb/serial/kobil_sct.c
++++ b/drivers/usb/serial/kobil_sct.c
+@@ -372,7 +372,7 @@ static void kobil_read_int_callback(stru
+ }
+
+ tty = tty_port_tty_get(&port->port);
+- if (urb->actual_length) {
++ if (tty && urb->actual_length) {
+
+ /* BEGIN DEBUG */
+ /*
--- /dev/null
+From 7a89e4cb9cdaba92f5fbc509945cf4e3c48db4e2 Mon Sep 17 00:00:00 2001
+From: Herton Ronaldo Krzesinski <herton.krzesinski@canonical.com>
+Date: Wed, 9 Mar 2011 09:19:48 +0000
+Subject: USB: serial: option: Apply OPTION_BLACKLIST_SENDSETUP also for ZTE MF626
+
+From: Herton Ronaldo Krzesinski <herton.krzesinski@canonical.com>
+
+commit 7a89e4cb9cdaba92f5fbc509945cf4e3c48db4e2 upstream.
+
+On https://bugs.launchpad.net/ubuntu/+source/linux/+bug/636091, one of
+the cases reported is a big timeout on option_send_setup, which causes
+some side effects as tty_lock is held. Looks like some of ZTE MF626
+devices also don't like the RTS/DTR setting in option_send_setup, like
+with 4G XS Stick W14. The reporter confirms which this it solves the
+long freezes in his system.
+
+Signed-off-by: Herton Ronaldo Krzesinski <herton.krzesinski@canonical.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+---
+ drivers/usb/serial/option.c | 3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+--- a/drivers/usb/serial/option.c
++++ b/drivers/usb/serial/option.c
+@@ -652,7 +652,8 @@ static const struct usb_device_id option
+ { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x0028, 0xff, 0xff, 0xff) },
+ { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x0029, 0xff, 0xff, 0xff) },
+ { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x0030, 0xff, 0xff, 0xff) },
+- { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, ZTE_PRODUCT_MF626, 0xff, 0xff, 0xff) },
++ { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, ZTE_PRODUCT_MF626, 0xff,
++ 0xff, 0xff), .driver_info = (kernel_ulong_t)&four_g_w14_blacklist },
+ { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x0032, 0xff, 0xff, 0xff) },
+ { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x0033, 0xff, 0xff, 0xff) },
+ { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x0034, 0xff, 0xff, 0xff) },
--- /dev/null
+From 01a1fdb9a7afa5e3c14c9316d6f380732750b4e4 Mon Sep 17 00:00:00 2001
+From: Sarah Sharp <sarah.a.sharp@linux.intel.com>
+Date: Wed, 23 Feb 2011 18:12:29 -0800
+Subject: xhci: Fix cycle bit calculation during stall handling.
+
+From: Sarah Sharp <sarah.a.sharp@linux.intel.com>
+
+commit 01a1fdb9a7afa5e3c14c9316d6f380732750b4e4 upstream.
+
+When an endpoint stalls, we need to update the xHCI host's internal
+dequeue pointer to move it past the stalled transfer. This includes
+updating the cycle bit (TRB ownership bit) if we have moved the dequeue
+pointer past a link TRB with the toggle cycle bit set.
+
+When we're trying to find the new dequeue segment, find_trb_seg() is
+supposed to keep track of whether we've passed any link TRBs with the
+toggle cycle bit set. However, this while loop's body
+
+ while (cur_seg->trbs > trb ||
+ &cur_seg->trbs[TRBS_PER_SEGMENT - 1] < trb) {
+
+Will never get executed if the ring only contains one segment.
+find_trb_seg() will return immediately, without updating the new cycle
+bit. Since find_trb_seg() has no idea where in the segment the TD that
+stalled was, make the caller, xhci_find_new_dequeue_state(), check for
+this special case and update the cycle bit accordingly.
+
+This patch should be queued to kernels all the way back to 2.6.31.
+
+Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
+Tested-by: Takashi Iwai <tiwai@suse.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+---
+ drivers/usb/host/xhci-ring.c | 14 ++++++++++++++
+ 1 file changed, 14 insertions(+)
+
+--- a/drivers/usb/host/xhci-ring.c
++++ b/drivers/usb/host/xhci-ring.c
+@@ -500,6 +500,20 @@ void xhci_find_new_dequeue_state(struct
+ state->new_cycle_state = ~(state->new_cycle_state) & 0x1;
+ next_trb(xhci, ep_ring, &state->new_deq_seg, &state->new_deq_ptr);
+
++ /*
++ * If there is only one segment in a ring, find_trb_seg()'s while loop
++ * will not run, and it will return before it has a chance to see if it
++ * needs to toggle the cycle bit. It can't tell if the stalled transfer
++ * ended just before the link TRB on a one-segment ring, or if the TD
++ * wrapped around the top of the ring, because it doesn't have the TD in
++ * question. Look for the one-segment case where stalled TRB's address
++ * is greater than the new dequeue pointer address.
++ */
++ if (ep_ring->first_seg == ep_ring->first_seg->next &&
++ state->new_deq_ptr < dev->eps[ep_index].stopped_trb)
++ state->new_cycle_state ^= 0x1;
++ xhci_dbg(xhci, "Cycle state = 0x%x\n", state->new_cycle_state);
++
+ /* Don't update the ring cycle state for the producer (us). */
+ xhci_dbg(xhci, "New dequeue segment = %p (virtual)\n",
+ state->new_deq_seg);
--- /dev/null
+From bf161e85fb153c0dd5a95faca73fd6a9d237c389 Mon Sep 17 00:00:00 2001
+From: Sarah Sharp <sarah.a.sharp@linux.intel.com>
+Date: Wed, 23 Feb 2011 15:46:42 -0800
+Subject: xhci: Update internal dequeue pointers after stalls.
+
+From: Sarah Sharp <sarah.a.sharp@linux.intel.com>
+
+commit bf161e85fb153c0dd5a95faca73fd6a9d237c389 upstream.
+
+When an endpoint stalls, the xHCI driver must move the endpoint ring's
+dequeue pointer past the stalled transfer. To do that, the driver issues
+a Set TR Dequeue Pointer command, which will complete some time later.
+
+Takashi was having issues with USB 1.1 audio devices that stalled, and his
+analysis of the code was that the old code would not update the xHCI
+driver's ring dequeue pointer after the command completes. However, the
+dequeue pointer is set in xhci_find_new_dequeue_state(), just before the
+set command is issued to the hardware.
+
+Setting the dequeue pointer before the Set TR Dequeue Pointer command
+completes is a dangerous thing to do, since the xHCI hardware can fail the
+command. Instead, store the new dequeue pointer in the xhci_virt_ep
+structure, and update the ring's dequeue pointer when the Set TR dequeue
+pointer command completes.
+
+While we're at it, make sure we can't queue another Set TR Dequeue Command
+while the first one is still being processed. This just won't work with
+the internal xHCI state code. I'm still not sure if this is the right
+thing to do, since we might have a case where a driver queues multiple
+URBs to a control ring, one of the URBs Stalls, and then the driver tries
+to cancel the second URB. There may be a race condition there where the
+xHCI driver might try to issue multiple Set TR Dequeue Pointer commands,
+but I would have to think very hard about how the Stop Endpoint and
+cancellation code works. Keep the fix simple until when/if we run into
+that case.
+
+This patch should be queued to kernels all the way back to 2.6.31.
+
+Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
+Tested-by: Takashi Iwai <tiwai@suse.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+---
+ drivers/usb/host/xhci-ring.c | 29 ++++++++++++++++++++++++++---
+ drivers/usb/host/xhci.h | 9 +++++++++
+ 2 files changed, 35 insertions(+), 3 deletions(-)
+
+--- a/drivers/usb/host/xhci-ring.c
++++ b/drivers/usb/host/xhci-ring.c
+@@ -506,9 +506,6 @@ void xhci_find_new_dequeue_state(struct
+ addr = xhci_trb_virt_to_dma(state->new_deq_seg, state->new_deq_ptr);
+ xhci_dbg(xhci, "New dequeue pointer = 0x%llx (DMA)\n",
+ (unsigned long long) addr);
+- xhci_dbg(xhci, "Setting dequeue pointer in internal ring state.\n");
+- ep_ring->dequeue = state->new_deq_ptr;
+- ep_ring->deq_seg = state->new_deq_seg;
+ }
+
+ static void td_to_noop(struct xhci_hcd *xhci, struct xhci_ring *ep_ring,
+@@ -951,9 +948,26 @@ static void handle_set_deq_completion(st
+ } else {
+ xhci_dbg(xhci, "Successful Set TR Deq Ptr cmd, deq = @%08llx\n",
+ ep_ctx->deq);
++ if (xhci_trb_virt_to_dma(dev->eps[ep_index].queued_deq_seg,
++ dev->eps[ep_index].queued_deq_ptr) ==
++ (ep_ctx->deq & ~(EP_CTX_CYCLE_MASK))) {
++ /* Update the ring's dequeue segment and dequeue pointer
++ * to reflect the new position.
++ */
++ ep_ring->deq_seg = dev->eps[ep_index].queued_deq_seg;
++ ep_ring->dequeue = dev->eps[ep_index].queued_deq_ptr;
++ } else {
++ xhci_warn(xhci, "Mismatch between completed Set TR Deq "
++ "Ptr command & xHCI internal state.\n");
++ xhci_warn(xhci, "ep deq seg = %p, deq ptr = %p\n",
++ dev->eps[ep_index].queued_deq_seg,
++ dev->eps[ep_index].queued_deq_ptr);
++ }
+ }
+
+ dev->eps[ep_index].ep_state &= ~SET_DEQ_PENDING;
++ dev->eps[ep_index].queued_deq_seg = NULL;
++ dev->eps[ep_index].queued_deq_ptr = NULL;
+ /* Restart any rings with pending URBs */
+ ring_doorbell_for_active_rings(xhci, slot_id, ep_index);
+ }
+@@ -3229,6 +3243,7 @@ static int queue_set_tr_deq(struct xhci_
+ u32 trb_ep_index = EP_ID_FOR_TRB(ep_index);
+ u32 trb_stream_id = STREAM_ID_FOR_TRB(stream_id);
+ u32 type = TRB_TYPE(TRB_SET_DEQ);
++ struct xhci_virt_ep *ep;
+
+ addr = xhci_trb_virt_to_dma(deq_seg, deq_ptr);
+ if (addr == 0) {
+@@ -3237,6 +3252,14 @@ static int queue_set_tr_deq(struct xhci_
+ deq_seg, deq_ptr);
+ return 0;
+ }
++ ep = &xhci->devs[slot_id]->eps[ep_index];
++ if ((ep->ep_state & SET_DEQ_PENDING)) {
++ xhci_warn(xhci, "WARN Cannot submit Set TR Deq Ptr\n");
++ xhci_warn(xhci, "A Set TR Deq Ptr command is pending.\n");
++ return 0;
++ }
++ ep->queued_deq_seg = deq_seg;
++ ep->queued_deq_ptr = deq_ptr;
+ return queue_command(xhci, lower_32_bits(addr) | cycle_state,
+ upper_32_bits(addr), trb_stream_id,
+ trb_slot_id | trb_ep_index | type, false);
+--- a/drivers/usb/host/xhci.h
++++ b/drivers/usb/host/xhci.h
+@@ -644,6 +644,9 @@ struct xhci_ep_ctx {
+ #define AVG_TRB_LENGTH_FOR_EP(p) ((p) & 0xffff)
+ #define MAX_ESIT_PAYLOAD_FOR_EP(p) (((p) & 0xffff) << 16)
+
++/* deq bitmasks */
++#define EP_CTX_CYCLE_MASK (1 << 0)
++
+
+ /**
+ * struct xhci_input_control_context
+@@ -746,6 +749,12 @@ struct xhci_virt_ep {
+ struct timer_list stop_cmd_timer;
+ int stop_cmds_pending;
+ struct xhci_hcd *xhci;
++ /* Dequeue pointer and dequeue segment for a submitted Set TR Dequeue
++ * command. We'll need to update the ring's dequeue segment and dequeue
++ * pointer after the command completes.
++ */
++ struct xhci_segment *queued_deq_seg;
++ union xhci_trb *queued_deq_ptr;
+ /*
+ * Sometimes the xHC can not process isochronous endpoint ring quickly
+ * enough, and it will miss some isoc tds on the ring and generate
projects / thirdparty / kernel / stable-queue.git / commitdiff
