--- /dev/null
+From e24aa0a4c5ac92a171d9dd74a8d3dbf652990d36 Mon Sep 17 00:00:00 2001
+From: Takashi Iwai <tiwai@suse.de>
+Date: Sun, 10 Aug 2014 13:30:08 +0200
+Subject: ALSA: hda/ca0132 - Don't try loading firmware at resume when already failed
+
+From: Takashi Iwai <tiwai@suse.de>
+
+commit e24aa0a4c5ac92a171d9dd74a8d3dbf652990d36 upstream.
+
+CA0132 driver tries to reload the firmware at resume. Usually this
+works since the firmware loader core caches the firmware contents by
+itself. However, if the driver failed to load the firmwares
+(e.g. missing files), reloading the firmware at resume goes through
+the actual file loading code path, and triggers a kernel WARNING like:
+
+ WARNING: CPU: 10 PID:11371 at drivers/base/firmware_class.c:1105 _request_firmware+0x9ab/0x9d0()
+
+For avoiding this situation, this patch makes CA0132 skipping the f/w
+loading at resume when it failed at probe time.
+
+Reported-and-tested-by: Janek Kozicki <cosurgi@gmail.com>
+Signed-off-by: Takashi Iwai <tiwai@suse.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ sound/pci/hda/patch_ca0132.c | 7 ++++++-
+ 1 file changed, 6 insertions(+), 1 deletion(-)
+
+--- a/sound/pci/hda/patch_ca0132.c
++++ b/sound/pci/hda/patch_ca0132.c
+@@ -4379,6 +4379,9 @@ static void ca0132_download_dsp(struct h
+ return; /* NOP */
+ #endif
+
++ if (spec->dsp_state == DSP_DOWNLOAD_FAILED)
++ return; /* don't retry failures */
++
+ chipio_enable_clocks(codec);
+ spec->dsp_state = DSP_DOWNLOADING;
+ if (!ca0132_download_dsp_images(codec))
+@@ -4555,7 +4558,8 @@ static int ca0132_init(struct hda_codec
+ struct auto_pin_cfg *cfg = &spec->autocfg;
+ int i;
+
+- spec->dsp_state = DSP_DOWNLOAD_INIT;
++ if (spec->dsp_state != DSP_DOWNLOAD_FAILED)
++ spec->dsp_state = DSP_DOWNLOAD_INIT;
+ spec->curr_chip_addx = INVALID_CHIP_ADDRESS;
+
+ snd_hda_power_up(codec);
+@@ -4666,6 +4670,7 @@ static int patch_ca0132(struct hda_codec
+ codec->spec = spec;
+ spec->codec = codec;
+
++ spec->dsp_state = DSP_DOWNLOAD_INIT;
+ spec->num_mixers = 1;
+ spec->mixers[0] = ca0132_mixer;
+
--- /dev/null
+From 7440850c20b69658f322119d20a94dc914127cc7 Mon Sep 17 00:00:00 2001
+From: Hui Wang <hui.wang@canonical.com>
+Date: Wed, 30 Jul 2014 11:11:48 +0800
+Subject: ALSA: hda - fix an external mic jack problem on a HP machine
+
+From: Hui Wang <hui.wang@canonical.com>
+
+commit 7440850c20b69658f322119d20a94dc914127cc7 upstream.
+
+ON the machine, two pin complex (0xb and 0xe) are both routed to
+the same external right-side mic jack, this makes the jack can't work.
+
+To fix this problem, set the 0xe to "not connected".
+
+BugLink: https://bugs.launchpad.net/bugs/1350148
+Tested-by: Franz Hsieh <franz.hsieh@canonical.com>
+Signed-off-by: Hui Wang <hui.wang@canonical.com>
+Signed-off-by: Takashi Iwai <tiwai@suse.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ sound/pci/hda/patch_sigmatel.c | 12 ++++++++++++
+ 1 file changed, 12 insertions(+)
+
+--- a/sound/pci/hda/patch_sigmatel.c
++++ b/sound/pci/hda/patch_sigmatel.c
+@@ -84,6 +84,7 @@ enum {
+ STAC_DELL_EQ,
+ STAC_ALIENWARE_M17X,
+ STAC_92HD89XX_HP_FRONT_JACK,
++ STAC_92HD89XX_HP_Z1_G2_RIGHT_MIC_JACK,
+ STAC_92HD73XX_MODELS
+ };
+
+@@ -1783,6 +1784,11 @@ static const struct hda_pintbl stac92hd8
+ {}
+ };
+
++static const struct hda_pintbl stac92hd89xx_hp_z1_g2_right_mic_jack_pin_configs[] = {
++ { 0x0e, 0x400000f0 },
++ {}
++};
++
+ static void stac92hd73xx_fixup_ref(struct hda_codec *codec,
+ const struct hda_fixup *fix, int action)
+ {
+@@ -1905,6 +1911,10 @@ static const struct hda_fixup stac92hd73
+ [STAC_92HD89XX_HP_FRONT_JACK] = {
+ .type = HDA_FIXUP_PINS,
+ .v.pins = stac92hd89xx_hp_front_jack_pin_configs,
++ },
++ [STAC_92HD89XX_HP_Z1_G2_RIGHT_MIC_JACK] = {
++ .type = HDA_FIXUP_PINS,
++ .v.pins = stac92hd89xx_hp_z1_g2_right_mic_jack_pin_configs,
+ }
+ };
+
+@@ -1965,6 +1975,8 @@ static const struct snd_pci_quirk stac92
+ "Alienware M17x", STAC_ALIENWARE_M17X),
+ SND_PCI_QUIRK(PCI_VENDOR_ID_DELL, 0x0490,
+ "Alienware M17x R3", STAC_DELL_EQ),
++ SND_PCI_QUIRK(PCI_VENDOR_ID_HP, 0x1927,
++ "HP Z1 G2", STAC_92HD89XX_HP_Z1_G2_RIGHT_MIC_JACK),
+ SND_PCI_QUIRK(PCI_VENDOR_ID_HP, 0x2b17,
+ "unknown HP", STAC_92HD89XX_HP_FRONT_JACK),
+ {} /* terminator */
--- /dev/null
+From f3ee07d8b6e061bf34a7167c3f564e8da4360a99 Mon Sep 17 00:00:00 2001
+From: Takashi Iwai <tiwai@suse.de>
+Date: Fri, 15 Aug 2014 17:35:00 +0200
+Subject: ALSA: hda/realtek - Avoid setting wrong COEF on ALC269 & co
+
+From: Takashi Iwai <tiwai@suse.de>
+
+commit f3ee07d8b6e061bf34a7167c3f564e8da4360a99 upstream.
+
+ALC269 & co have many vendor-specific setups with COEF verbs.
+However, some verbs seem specific to some codec versions and they
+result in the codec stalling. Typically, such a case can be avoided
+by checking the return value from reading a COEF. If the return value
+is -1, it implies that the COEF is invalid, thus it shouldn't be
+written.
+
+This patch adds the invalid COEF checks in appropriate places
+accessing ALC269 and its variants. The patch actually fixes the
+resume problem on Acer AO725 laptop.
+
+Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=52181
+Tested-by: Francesco Muzio <muziofg@gmail.com>
+Signed-off-by: Takashi Iwai <tiwai@suse.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ sound/pci/hda/patch_realtek.c | 17 ++++++++++++-----
+ 1 file changed, 12 insertions(+), 5 deletions(-)
+
+--- a/sound/pci/hda/patch_realtek.c
++++ b/sound/pci/hda/patch_realtek.c
+@@ -175,6 +175,8 @@ static void alc_fix_pll(struct hda_codec
+ spec->pll_coef_idx);
+ val = snd_hda_codec_read(codec, spec->pll_nid, 0,
+ AC_VERB_GET_PROC_COEF, 0);
++ if (val == -1)
++ return;
+ snd_hda_codec_write(codec, spec->pll_nid, 0, AC_VERB_SET_COEF_INDEX,
+ spec->pll_coef_idx);
+ snd_hda_codec_write(codec, spec->pll_nid, 0, AC_VERB_SET_PROC_COEF,
+@@ -2677,6 +2679,8 @@ static int alc269_parse_auto_config(stru
+ static void alc269vb_toggle_power_output(struct hda_codec *codec, int power_up)
+ {
+ int val = alc_read_coef_idx(codec, 0x04);
++ if (val == -1)
++ return;
+ if (power_up)
+ val |= 1 << 11;
+ else
+@@ -3822,27 +3826,30 @@ static void alc269_fill_coef(struct hda_
+ if ((alc_get_coef0(codec) & 0x00ff) == 0x017) {
+ val = alc_read_coef_idx(codec, 0x04);
+ /* Power up output pin */
+- alc_write_coef_idx(codec, 0x04, val | (1<<11));
++ if (val != -1)
++ alc_write_coef_idx(codec, 0x04, val | (1<<11));
+ }
+
+ if ((alc_get_coef0(codec) & 0x00ff) == 0x018) {
+ val = alc_read_coef_idx(codec, 0xd);
+- if ((val & 0x0c00) >> 10 != 0x1) {
++ if (val != -1 && (val & 0x0c00) >> 10 != 0x1) {
+ /* Capless ramp up clock control */
+ alc_write_coef_idx(codec, 0xd, val | (1<<10));
+ }
+ val = alc_read_coef_idx(codec, 0x17);
+- if ((val & 0x01c0) >> 6 != 0x4) {
++ if (val != -1 && (val & 0x01c0) >> 6 != 0x4) {
+ /* Class D power on reset */
+ alc_write_coef_idx(codec, 0x17, val | (1<<7));
+ }
+ }
+
+ val = alc_read_coef_idx(codec, 0xd); /* Class D */
+- alc_write_coef_idx(codec, 0xd, val | (1<<14));
++ if (val != -1)
++ alc_write_coef_idx(codec, 0xd, val | (1<<14));
+
+ val = alc_read_coef_idx(codec, 0x4); /* HP */
+- alc_write_coef_idx(codec, 0x4, val | (1<<11));
++ if (val != -1)
++ alc_write_coef_idx(codec, 0x4, val | (1<<11));
+ }
+
+ /*
--- /dev/null
+From f42bb22243d2ae264d721b055f836059fe35321f Mon Sep 17 00:00:00 2001
+From: Clemens Ladisch <clemens@ladisch.de>
+Date: Mon, 4 Aug 2014 15:17:55 +0200
+Subject: ALSA: virtuoso: add Xonar Essence STX II support
+
+From: Clemens Ladisch <clemens@ladisch.de>
+
+commit f42bb22243d2ae264d721b055f836059fe35321f upstream.
+
+Just add the PCI ID for the STX II. It appears to work the same as the
+STX, except for the addition of the not-yet-supported daughterboard.
+
+Tested-by: Mario <fugazzi99@gmail.com>
+Tested-by: corubba <corubba@gmx.de>
+Signed-off-by: Clemens Ladisch <clemens@ladisch.de>
+Signed-off-by: Takashi Iwai <tiwai@suse.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ Documentation/sound/alsa/ALSA-Configuration.txt | 4 ++--
+ sound/pci/Kconfig | 4 ++--
+ sound/pci/oxygen/virtuoso.c | 1 +
+ sound/pci/oxygen/xonar_pcm179x.c | 12 ++++++++++--
+ 4 files changed, 15 insertions(+), 6 deletions(-)
+
+--- a/Documentation/sound/alsa/ALSA-Configuration.txt
++++ b/Documentation/sound/alsa/ALSA-Configuration.txt
+@@ -2026,8 +2026,8 @@ Prior to version 0.9.0rc4 options had a
+ -------------------
+
+ Module for sound cards based on the Asus AV66/AV100/AV200 chips,
+- i.e., Xonar D1, DX, D2, D2X, DS, Essence ST (Deluxe), Essence STX,
+- HDAV1.3 (Deluxe), and HDAV1.3 Slim.
++ i.e., Xonar D1, DX, D2, D2X, DS, DSX, Essence ST (Deluxe),
++ Essence STX (II), HDAV1.3 (Deluxe), and HDAV1.3 Slim.
+
+ This module supports autoprobe and multiple cards.
+
+--- a/sound/pci/Kconfig
++++ b/sound/pci/Kconfig
+@@ -856,8 +856,8 @@ config SND_VIRTUOSO
+ select SND_JACK if INPUT=y || INPUT=SND
+ help
+ Say Y here to include support for sound cards based on the
+- Asus AV66/AV100/AV200 chips, i.e., Xonar D1, DX, D2, D2X, DS,
+- Essence ST (Deluxe), and Essence STX.
++ Asus AV66/AV100/AV200 chips, i.e., Xonar D1, DX, D2, D2X, DS, DSX,
++ Essence ST (Deluxe), and Essence STX (II).
+ Support for the HDAV1.3 (Deluxe) and HDAV1.3 Slim is experimental;
+ for the Xense, missing.
+
+--- a/sound/pci/oxygen/virtuoso.c
++++ b/sound/pci/oxygen/virtuoso.c
+@@ -53,6 +53,7 @@ static DEFINE_PCI_DEVICE_TABLE(xonar_ids
+ { OXYGEN_PCI_SUBID(0x1043, 0x835e) },
+ { OXYGEN_PCI_SUBID(0x1043, 0x838e) },
+ { OXYGEN_PCI_SUBID(0x1043, 0x8522) },
++ { OXYGEN_PCI_SUBID(0x1043, 0x85f4) },
+ { OXYGEN_PCI_SUBID_BROKEN_EEPROM },
+ { }
+ };
+--- a/sound/pci/oxygen/xonar_pcm179x.c
++++ b/sound/pci/oxygen/xonar_pcm179x.c
+@@ -100,8 +100,8 @@
+ */
+
+ /*
+- * Xonar Essence ST (Deluxe)/STX
+- * -----------------------------
++ * Xonar Essence ST (Deluxe)/STX (II)
++ * ----------------------------------
+ *
+ * CMI8788:
+ *
+@@ -1137,6 +1137,14 @@ int get_xonar_pcm179x_model(struct oxyge
+ chip->model.init = xonar_stx_init;
+ chip->model.resume = xonar_stx_resume;
+ chip->model.set_dac_params = set_pcm1796_params;
++ break;
++ case 0x85f4:
++ chip->model = model_xonar_st;
++ /* TODO: daughterboard support */
++ chip->model.shortname = "Xonar STX II";
++ chip->model.init = xonar_stx_init;
++ chip->model.resume = xonar_stx_resume;
++ chip->model.set_dac_params = set_pcm1796_params;
+ break;
+ default:
+ return -EINVAL;
--- /dev/null
+From 9b5f7428f8b16bd8980213f2b70baf1dd0b9e36c Mon Sep 17 00:00:00 2001
+From: Jeremy Vial <jvial@adeneo-embedded.com>
+Date: Thu, 31 Jul 2014 15:10:33 +0200
+Subject: ARM: OMAP3: Fix choice of omap3_restore_es function in OMAP34XX rev3.1.2 case.
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Jeremy Vial <jvial@adeneo-embedded.com>
+
+commit 9b5f7428f8b16bd8980213f2b70baf1dd0b9e36c upstream.
+
+According to the comment “restore_es3: applies to 34xx >= ES3.0" in
+"arch/arm/mach-omap2/sleep34xx.S”, omap3_restore_es3 should be used
+if the revision of an OMAP34xx is ES3.1.2.
+
+Signed-off-by: Jeremy Vial <jvial@adeneo-embedded.com>
+Signed-off-by: Tony Lindgren <tony@atomide.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/arm/mach-omap2/control.c | 3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+--- a/arch/arm/mach-omap2/control.c
++++ b/arch/arm/mach-omap2/control.c
+@@ -323,7 +323,8 @@ void omap3_save_scratchpad_contents(void
+ scratchpad_contents.public_restore_ptr =
+ virt_to_phys(omap3_restore_3630);
+ else if (omap_rev() != OMAP3430_REV_ES3_0 &&
+- omap_rev() != OMAP3430_REV_ES3_1)
++ omap_rev() != OMAP3430_REV_ES3_1 &&
++ omap_rev() != OMAP3430_REV_ES3_1_2)
+ scratchpad_contents.public_restore_ptr =
+ virt_to_phys(omap3_restore);
+ else
--- /dev/null
+From 2d31ca3ad7d5d44c8adc7f253c96ce33f3a2e931 Mon Sep 17 00:00:00 2001
+From: Russell King <rmk+kernel@arm.linux.org.uk>
+Date: Sat, 12 Jul 2014 10:53:41 +0100
+Subject: drm: omapdrm: fix compiler errors
+
+From: Russell King <rmk+kernel@arm.linux.org.uk>
+
+commit 2d31ca3ad7d5d44c8adc7f253c96ce33f3a2e931 upstream.
+
+Regular randconfig nightly testing has detected problems with omapdrm.
+
+omapdrm fails to build when the kernel is built to support 64-bit DMA
+addresses and/or 64-bit physical addresses due to an assumption about
+the width of these types.
+
+Use %pad to print DMA addresses, rather than %x or %Zx (which is even
+more wrong than %x). Avoid passing a uint32_t pointer into a function
+which expects dma_addr_t pointer.
+
+drivers/gpu/drm/omapdrm/omap_plane.c: In function 'omap_plane_pre_apply':
+drivers/gpu/drm/omapdrm/omap_plane.c:145:2: error: format '%x' expects argument of type 'unsigned int', but argument 5 has type 'dma_addr_t' [-Werror=format]
+drivers/gpu/drm/omapdrm/omap_plane.c:145:2: error: format '%x' expects argument of type 'unsigned int', but argument 6 has type 'dma_addr_t' [-Werror=format]
+make[5]: *** [drivers/gpu/drm/omapdrm/omap_plane.o] Error 1
+drivers/gpu/drm/omapdrm/omap_gem.c: In function 'omap_gem_get_paddr':
+drivers/gpu/drm/omapdrm/omap_gem.c:794:4: error: format '%x' expects argument of type 'unsigned int', but argument 3 has type 'dma_addr_t' [-Werror=format]
+drivers/gpu/drm/omapdrm/omap_gem.c: In function 'omap_gem_describe':
+drivers/gpu/drm/omapdrm/omap_gem.c:991:4: error: format '%Zx' expects argument of type 'size_t', but argument 7 has type 'dma_addr_t' [-Werror=format]
+drivers/gpu/drm/omapdrm/omap_gem.c: In function 'omap_gem_init':
+drivers/gpu/drm/omapdrm/omap_gem.c:1470:4: error: format '%x' expects argument of type 'unsigned int', but argument 7 has type 'dma_addr_t' [-Werror=format]
+make[5]: *** [drivers/gpu/drm/omapdrm/omap_gem.o] Error 1
+drivers/gpu/drm/omapdrm/omap_dmm_tiler.c: In function 'dmm_txn_append':
+drivers/gpu/drm/omapdrm/omap_dmm_tiler.c:226:2: error: passing argument 3 of 'alloc_dma' from incompatible pointer type [-Werror]
+make[5]: *** [drivers/gpu/drm/omapdrm/omap_dmm_tiler.o] Error 1
+make[5]: Target `__build' not remade because of errors.
+make[4]: *** [drivers/gpu/drm/omapdrm] Error 2
+
+Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
+Signed-off-by: Dave Airlie <airlied@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/gpu/drm/omapdrm/omap_dmm_tiler.c | 6 ++++--
+ drivers/gpu/drm/omapdrm/omap_gem.c | 10 +++++-----
+ drivers/gpu/drm/omapdrm/omap_plane.c | 4 ++--
+ 3 files changed, 11 insertions(+), 9 deletions(-)
+
+--- a/drivers/gpu/drm/omapdrm/omap_dmm_tiler.c
++++ b/drivers/gpu/drm/omapdrm/omap_dmm_tiler.c
+@@ -199,7 +199,7 @@ static struct dmm_txn *dmm_txn_init(stru
+ static void dmm_txn_append(struct dmm_txn *txn, struct pat_area *area,
+ struct page **pages, uint32_t npages, uint32_t roll)
+ {
+- dma_addr_t pat_pa = 0;
++ dma_addr_t pat_pa = 0, data_pa = 0;
+ uint32_t *data;
+ struct pat *pat;
+ struct refill_engine *engine = txn->engine_handle;
+@@ -223,7 +223,9 @@ static void dmm_txn_append(struct dmm_tx
+ .lut_id = engine->tcm->lut_id,
+ };
+
+- data = alloc_dma(txn, 4*i, &pat->data_pa);
++ data = alloc_dma(txn, 4*i, &data_pa);
++ /* FIXME: what if data_pa is more than 32-bit ? */
++ pat->data_pa = data_pa;
+
+ while (i--) {
+ int n = i + roll;
+--- a/drivers/gpu/drm/omapdrm/omap_gem.c
++++ b/drivers/gpu/drm/omapdrm/omap_gem.c
+@@ -806,7 +806,7 @@ int omap_gem_get_paddr(struct drm_gem_ob
+ omap_obj->paddr = tiler_ssptr(block);
+ omap_obj->block = block;
+
+- DBG("got paddr: %08x", omap_obj->paddr);
++ DBG("got paddr: %pad", &omap_obj->paddr);
+ }
+
+ omap_obj->paddr_cnt++;
+@@ -1004,9 +1004,9 @@ void omap_gem_describe(struct drm_gem_ob
+ if (obj->map_list.map)
+ off = (uint64_t)obj->map_list.hash.key;
+
+- seq_printf(m, "%08x: %2d (%2d) %08llx %08Zx (%2d) %p %4d",
++ seq_printf(m, "%08x: %2d (%2d) %08llx %pad (%2d) %p %4d",
+ omap_obj->flags, obj->name, obj->refcount.refcount.counter,
+- off, omap_obj->paddr, omap_obj->paddr_cnt,
++ off, &omap_obj->paddr, omap_obj->paddr_cnt,
+ omap_obj->vaddr, omap_obj->roll);
+
+ if (omap_obj->flags & OMAP_BO_TILED) {
+@@ -1489,8 +1489,8 @@ void omap_gem_init(struct drm_device *de
+ entry->paddr = tiler_ssptr(block);
+ entry->block = block;
+
+- DBG("%d:%d: %dx%d: paddr=%08x stride=%d", i, j, w, h,
+- entry->paddr,
++ DBG("%d:%d: %dx%d: paddr=%pad stride=%d", i, j, w, h,
++ &entry->paddr,
+ usergart[i].stride_pfn << PAGE_SHIFT);
+ }
+ }
+--- a/drivers/gpu/drm/omapdrm/omap_plane.c
++++ b/drivers/gpu/drm/omapdrm/omap_plane.c
+@@ -146,8 +146,8 @@ static void omap_plane_pre_apply(struct
+ DBG("%dx%d -> %dx%d (%d)", info->width, info->height,
+ info->out_width, info->out_height,
+ info->screen_width);
+- DBG("%d,%d %08x %08x", info->pos_x, info->pos_y,
+- info->paddr, info->p_uv_addr);
++ DBG("%d,%d %pad %pad", info->pos_x, info->pos_y,
++ &info->paddr, &info->p_uv_addr);
+
+ /* TODO: */
+ ilace = false;
--- /dev/null
+From 410dd3cf4c9b36f27ed4542ee18b1af5e68645a4 Mon Sep 17 00:00:00 2001
+From: Jan Kara <jack@suse.cz>
+Date: Sun, 17 Aug 2014 11:49:57 +0200
+Subject: isofs: Fix unbounded recursion when processing relocated directories
+
+From: Jan Kara <jack@suse.cz>
+
+commit 410dd3cf4c9b36f27ed4542ee18b1af5e68645a4 upstream.
+
+We did not check relocated directory in any way when processing Rock
+Ridge 'CL' tag. Thus a corrupted isofs image can possibly have a CL
+entry pointing to another CL entry leading to possibly unbounded
+recursion in kernel code and thus stack overflow or deadlocks (if there
+is a loop created from CL entries).
+
+Fix the problem by not allowing CL entry to point to a directory entry
+with CL entry (such use makes no good sense anyway) and by checking
+whether CL entry doesn't point to itself.
+
+Reported-by: Chris Evans <cevans@google.com>
+Signed-off-by: Jan Kara <jack@suse.cz>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ fs/isofs/inode.c | 15 ++++++++-------
+ fs/isofs/isofs.h | 23 +++++++++++++++++++----
+ fs/isofs/rock.c | 39 ++++++++++++++++++++++++++++-----------
+ 3 files changed, 55 insertions(+), 22 deletions(-)
+
+--- a/fs/isofs/inode.c
++++ b/fs/isofs/inode.c
+@@ -69,7 +69,7 @@ static void isofs_put_super(struct super
+ return;
+ }
+
+-static int isofs_read_inode(struct inode *);
++static int isofs_read_inode(struct inode *, int relocated);
+ static int isofs_statfs (struct dentry *, struct kstatfs *);
+
+ static struct kmem_cache *isofs_inode_cachep;
+@@ -1274,7 +1274,7 @@ out_toomany:
+ goto out;
+ }
+
+-static int isofs_read_inode(struct inode *inode)
++static int isofs_read_inode(struct inode *inode, int relocated)
+ {
+ struct super_block *sb = inode->i_sb;
+ struct isofs_sb_info *sbi = ISOFS_SB(sb);
+@@ -1419,7 +1419,7 @@ static int isofs_read_inode(struct inode
+ */
+
+ if (!high_sierra) {
+- parse_rock_ridge_inode(de, inode);
++ parse_rock_ridge_inode(de, inode, relocated);
+ /* if we want uid/gid set, override the rock ridge setting */
+ if (sbi->s_uid_set)
+ inode->i_uid = sbi->s_uid;
+@@ -1498,9 +1498,10 @@ static int isofs_iget5_set(struct inode
+ * offset that point to the underlying meta-data for the inode. The
+ * code below is otherwise similar to the iget() code in
+ * include/linux/fs.h */
+-struct inode *isofs_iget(struct super_block *sb,
+- unsigned long block,
+- unsigned long offset)
++struct inode *__isofs_iget(struct super_block *sb,
++ unsigned long block,
++ unsigned long offset,
++ int relocated)
+ {
+ unsigned long hashval;
+ struct inode *inode;
+@@ -1522,7 +1523,7 @@ struct inode *isofs_iget(struct super_bl
+ return ERR_PTR(-ENOMEM);
+
+ if (inode->i_state & I_NEW) {
+- ret = isofs_read_inode(inode);
++ ret = isofs_read_inode(inode, relocated);
+ if (ret < 0) {
+ iget_failed(inode);
+ inode = ERR_PTR(ret);
+--- a/fs/isofs/isofs.h
++++ b/fs/isofs/isofs.h
+@@ -107,7 +107,7 @@ extern int iso_date(char *, int);
+
+ struct inode; /* To make gcc happy */
+
+-extern int parse_rock_ridge_inode(struct iso_directory_record *, struct inode *);
++extern int parse_rock_ridge_inode(struct iso_directory_record *, struct inode *, int relocated);
+ extern int get_rock_ridge_filename(struct iso_directory_record *, char *, struct inode *);
+ extern int isofs_name_translate(struct iso_directory_record *, char *, struct inode *);
+
+@@ -118,9 +118,24 @@ extern struct dentry *isofs_lookup(struc
+ extern struct buffer_head *isofs_bread(struct inode *, sector_t);
+ extern int isofs_get_blocks(struct inode *, sector_t, struct buffer_head **, unsigned long);
+
+-extern struct inode *isofs_iget(struct super_block *sb,
+- unsigned long block,
+- unsigned long offset);
++struct inode *__isofs_iget(struct super_block *sb,
++ unsigned long block,
++ unsigned long offset,
++ int relocated);
++
++static inline struct inode *isofs_iget(struct super_block *sb,
++ unsigned long block,
++ unsigned long offset)
++{
++ return __isofs_iget(sb, block, offset, 0);
++}
++
++static inline struct inode *isofs_iget_reloc(struct super_block *sb,
++ unsigned long block,
++ unsigned long offset)
++{
++ return __isofs_iget(sb, block, offset, 1);
++}
+
+ /* Because the inode number is no longer relevant to finding the
+ * underlying meta-data for an inode, we are free to choose a more
+--- a/fs/isofs/rock.c
++++ b/fs/isofs/rock.c
+@@ -288,12 +288,16 @@ eio:
+ goto out;
+ }
+
++#define RR_REGARD_XA 1
++#define RR_RELOC_DE 2
++
+ static int
+ parse_rock_ridge_inode_internal(struct iso_directory_record *de,
+- struct inode *inode, int regard_xa)
++ struct inode *inode, int flags)
+ {
+ int symlink_len = 0;
+ int cnt, sig;
++ unsigned int reloc_block;
+ struct inode *reloc;
+ struct rock_ridge *rr;
+ int rootflag;
+@@ -305,7 +309,7 @@ parse_rock_ridge_inode_internal(struct i
+
+ init_rock_state(&rs, inode);
+ setup_rock_ridge(de, inode, &rs);
+- if (regard_xa) {
++ if (flags & RR_REGARD_XA) {
+ rs.chr += 14;
+ rs.len -= 14;
+ if (rs.len < 0)
+@@ -485,12 +489,22 @@ repeat:
+ "relocated directory\n");
+ goto out;
+ case SIG('C', 'L'):
+- ISOFS_I(inode)->i_first_extent =
+- isonum_733(rr->u.CL.location);
+- reloc =
+- isofs_iget(inode->i_sb,
+- ISOFS_I(inode)->i_first_extent,
+- 0);
++ if (flags & RR_RELOC_DE) {
++ printk(KERN_ERR
++ "ISOFS: Recursive directory relocation "
++ "is not supported\n");
++ goto eio;
++ }
++ reloc_block = isonum_733(rr->u.CL.location);
++ if (reloc_block == ISOFS_I(inode)->i_iget5_block &&
++ ISOFS_I(inode)->i_iget5_offset == 0) {
++ printk(KERN_ERR
++ "ISOFS: Directory relocation points to "
++ "itself\n");
++ goto eio;
++ }
++ ISOFS_I(inode)->i_first_extent = reloc_block;
++ reloc = isofs_iget_reloc(inode->i_sb, reloc_block, 0);
+ if (IS_ERR(reloc)) {
+ ret = PTR_ERR(reloc);
+ goto out;
+@@ -637,9 +651,11 @@ static char *get_symlink_chunk(char *rpn
+ return rpnt;
+ }
+
+-int parse_rock_ridge_inode(struct iso_directory_record *de, struct inode *inode)
++int parse_rock_ridge_inode(struct iso_directory_record *de, struct inode *inode,
++ int relocated)
+ {
+- int result = parse_rock_ridge_inode_internal(de, inode, 0);
++ int flags = relocated ? RR_RELOC_DE : 0;
++ int result = parse_rock_ridge_inode_internal(de, inode, flags);
+
+ /*
+ * if rockridge flag was reset and we didn't look for attributes
+@@ -647,7 +663,8 @@ int parse_rock_ridge_inode(struct iso_di
+ */
+ if ((ISOFS_SB(inode->i_sb)->s_rock_offset == -1)
+ && (ISOFS_SB(inode->i_sb)->s_rock == 2)) {
+- result = parse_rock_ridge_inode_internal(de, inode, 14);
++ result = parse_rock_ridge_inode_internal(de, inode,
++ flags | RR_REGARD_XA);
+ }
+ return result;
+ }
--- /dev/null
+From 22b987a325701223f9a37db700c6eb20b9924c6f Mon Sep 17 00:00:00 2001
+From: Alexander Usyskin <alexander.usyskin@intel.com>
+Date: Thu, 17 Jul 2014 10:53:35 +0300
+Subject: mei: start disconnect request timer consistently
+
+From: Alexander Usyskin <alexander.usyskin@intel.com>
+
+commit 22b987a325701223f9a37db700c6eb20b9924c6f upstream.
+
+Link must be reset in case the fw doesn't
+respond to client disconnect request.
+We did charge the timer only in irq path
+from mei_cl_irq_close and not in mei_cl_disconnect
+
+Signed-off-by: Alexander Usyskin <alexander.usyskin@intel.com>
+Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/misc/mei/client.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/drivers/misc/mei/client.c
++++ b/drivers/misc/mei/client.c
+@@ -405,6 +405,7 @@ int mei_cl_disconnect(struct mei_cl *cl)
+ dev_err(&dev->pdev->dev, "failed to disconnect.\n");
+ goto free;
+ }
++ cl->timer_count = MEI_CONNECT_TIMEOUT;
+ mdelay(10); /* Wait for hardware disconnection ready */
+ list_add_tail(&cb->list, &dev->ctrl_rd_list.list);
+ } else {
stable_kernel_rules-add-pointer-to-netdev-faq-for-network-patches.patch
hid-logitech-perform-bounds-checking-on-device_id-early-enough.patch
hid-fix-a-couple-of-off-by-ones.patch
+isofs-fix-unbounded-recursion-when-processing-relocated-directories.patch
+usb-ohci-don-t-lose-track-of-eds-when-a-controller-dies.patch
+usb-serial-ftdi_sio-annotate-the-current-xsens-pid-assignments.patch
+usb-serial-ftdi_sio-add-support-for-new-xsens-devices.patch
+usb-ehci-pci-usb-host-controller-support-for-intel-quark-x1000.patch
+usb-fix-persist-resume-of-some-ss-usb-devices.patch
+alsa-hda-fix-an-external-mic-jack-problem-on-a-hp-machine.patch
+alsa-virtuoso-add-xonar-essence-stx-ii-support.patch
+alsa-hda-ca0132-don-t-try-loading-firmware-at-resume-when-already-failed.patch
+alsa-hda-realtek-avoid-setting-wrong-coef-on-alc269-co.patch
+mei-start-disconnect-request-timer-consistently.patch
+arm-omap3-fix-choice-of-omap3_restore_es-function-in-omap34xx-rev3.1.2-case.patch
+drm-omapdrm-fix-compiler-errors.patch
--- /dev/null
+From 6e693739e9b603b3ca9ce0d4f4178f0633458465 Mon Sep 17 00:00:00 2001
+From: Bryan O'Donoghue <bryan.odonoghue@intel.com>
+Date: Wed, 2 Jul 2014 01:58:18 -0700
+Subject: USB: ehci-pci: USB host controller support for Intel Quark X1000
+
+From: Bryan O'Donoghue <bryan.odonoghue@intel.com>
+
+commit 6e693739e9b603b3ca9ce0d4f4178f0633458465 upstream.
+
+The EHCI packet buffer in/out threshold is programmable for Intel Quark X1000
+USB host controller, and the default value is 0x20 dwords. The in/out threshold
+can be programmed to 0x80 dwords (512 Bytes) to maximize the perfomrance,
+but only when isochronous/interrupt transactions are not initiated by the USB
+host controller. This patch is to reconfigure the packet buffer in/out
+threshold as maximal as possible to maximize the performance, and 0x7F dwords
+(508 Bytes) should be used because the USB host controller initiates
+isochronous/interrupt transactions.
+
+Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@intel.com>
+Signed-off-by: Alvin (Weike) Chen <alvin.chen@intel.com>
+Acked-by: Alan Stern <stern@rowland.harvard.edu>
+Reviewed-by: Jingoo Han <jg1.han@samsung.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/usb/host/ehci-pci.c | 25 +++++++++++++++++++++++++
+ 1 file changed, 25 insertions(+)
+
+--- a/drivers/usb/host/ehci-pci.c
++++ b/drivers/usb/host/ehci-pci.c
+@@ -35,6 +35,21 @@ static const char hcd_name[] = "ehci-pci
+ #define PCI_DEVICE_ID_INTEL_CE4100_USB 0x2e70
+
+ /*-------------------------------------------------------------------------*/
++#define PCI_DEVICE_ID_INTEL_QUARK_X1000_SOC 0x0939
++static inline bool is_intel_quark_x1000(struct pci_dev *pdev)
++{
++ return pdev->vendor == PCI_VENDOR_ID_INTEL &&
++ pdev->device == PCI_DEVICE_ID_INTEL_QUARK_X1000_SOC;
++}
++
++/*
++ * 0x84 is the offset of in/out threshold register,
++ * and it is the same offset as the register of 'hostpc'.
++ */
++#define intel_quark_x1000_insnreg01 hostpc
++
++/* Maximum usable threshold value is 0x7f dwords for both IN and OUT */
++#define INTEL_QUARK_X1000_EHCI_MAX_THRESHOLD 0x007f007f
+
+ /* called after powerup, by probe or system-pm "wakeup" */
+ static int ehci_pci_reinit(struct ehci_hcd *ehci, struct pci_dev *pdev)
+@@ -50,6 +65,16 @@ static int ehci_pci_reinit(struct ehci_h
+ if (!retval)
+ ehci_dbg(ehci, "MWI active\n");
+
++ /* Reset the threshold limit */
++ if (is_intel_quark_x1000(pdev)) {
++ /*
++ * For the Intel QUARK X1000, raise the I/O threshold to the
++ * maximum usable value in order to improve performance.
++ */
++ ehci_writel(ehci, INTEL_QUARK_X1000_EHCI_MAX_THRESHOLD,
++ ehci->regs->intel_quark_x1000_insnreg01);
++ }
++
+ return 0;
+ }
+
--- /dev/null
+From a40178b2fa6ad87670fb1e5fa4024db00c149629 Mon Sep 17 00:00:00 2001
+From: Pratyush Anand <pratyush.anand@st.com>
+Date: Fri, 18 Jul 2014 12:37:10 +0530
+Subject: USB: Fix persist resume of some SS USB devices
+
+From: Pratyush Anand <pratyush.anand@st.com>
+
+commit a40178b2fa6ad87670fb1e5fa4024db00c149629 upstream.
+
+Problem Summary: Problem has been observed generally with PM states
+where VBUS goes off during suspend. There are some SS USB devices which
+take longer time for link training compared to many others. Such
+devices fail to reconnect with same old address which was associated
+with it before suspend.
+
+When system resumes, at some point of time (dpm_run_callback->
+usb_dev_resume->usb_resume->usb_resume_both->usb_resume_device->
+usb_port_resume) SW reads hub status. If device is present,
+then it finishes port resume and re-enumerates device with same
+address. If device is not present then, SW thinks that device was
+removed during suspend and therefore does logical disconnection
+and removes all the resource allocated for this device.
+
+Now, if I put sufficient delay just before root hub status read in
+usb_resume_device then, SW sees always that device is present. In normal
+course(without any delay) SW sees that no device is present and then SW
+removes all resource associated with the device at this port. In the
+latter case, after sometime, device says that hey I am here, now host
+enumerates it, but with new address.
+
+Problem had been reproduced when I connect verbatim USB3.0 hard disc
+with my STiH407 XHCI host running with 3.10 kernel.
+
+I see that similar problem has been reported here.
+https://bugzilla.kernel.org/show_bug.cgi?id=53211
+Reading above it seems that bug was not in 3.6.6 and was present in 3.8
+and again it was not present for some in 3.12.6, while it was present
+for few others. I tested with 3.13-FC19 running at i686 desktop, problem
+was still there. However, I was failed to reproduce it with 3.16-RC4
+running at same i686 machine. I would say it is just a random
+observation. Problem for few devices is always there, as I am unable to
+find a proper fix for the issue.
+
+So, now question is what should be the amount of delay so that host is
+always able to recognize suspended device after resume.
+
+XHCI specs 4.19.4 says that when Link training is successful, port sets
+CSC bit to 1. So if SW reads port status before successful link
+training, then it will not find device to be present. USB Analyzer log
+with such buggy devices show that in some cases device switch on the
+RX termination after long delay of host enabling the VBUS. In few other
+cases it has been seen that device fails to negotiate link training in
+first attempt. It has been reported till now that few devices take as
+long as 2000 ms to train the link after host enabling its VBUS and
+RX termination. This patch implements a 2000 ms timeout for CSC bit to set
+ie for link training. If in a case link trains before timeout, loop will
+exit earlier.
+
+This patch implements above delay, but only for SS device and when
+persist is enabled.
+
+So, for the good device overhead is almost none. While for the bad
+devices penalty could be the time which it take for link training.
+But, If a device was connected before suspend, and was removed
+while system was asleep, then the penalty would be the timeout ie
+2000 ms.
+
+Results:
+
+Verbatim USB SS hard disk connected with STiH407 USB host running 3.10
+Kernel resumes in 461 msecs without this patch, but hard disk is
+assigned a new device address. Same system resumes in 790 msecs with
+this patch, but with old device address.
+
+Signed-off-by: Pratyush Anand <pratyush.anand@st.com>
+Acked-by: Alan Stern <stern@rowland.harvard.edu>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/usb/core/hub.c | 41 +++++++++++++++++++++++++++++++++++++++++
+ 1 file changed, 41 insertions(+)
+
+--- a/drivers/usb/core/hub.c
++++ b/drivers/usb/core/hub.c
+@@ -3166,6 +3166,43 @@ static int finish_port_resume(struct usb
+ }
+
+ /*
++ * There are some SS USB devices which take longer time for link training.
++ * XHCI specs 4.19.4 says that when Link training is successful, port
++ * sets CSC bit to 1. So if SW reads port status before successful link
++ * training, then it will not find device to be present.
++ * USB Analyzer log with such buggy devices show that in some cases
++ * device switch on the RX termination after long delay of host enabling
++ * the VBUS. In few other cases it has been seen that device fails to
++ * negotiate link training in first attempt. It has been
++ * reported till now that few devices take as long as 2000 ms to train
++ * the link after host enabling its VBUS and termination. Following
++ * routine implements a 2000 ms timeout for link training. If in a case
++ * link trains before timeout, loop will exit earlier.
++ *
++ * FIXME: If a device was connected before suspend, but was removed
++ * while system was asleep, then the loop in the following routine will
++ * only exit at timeout.
++ *
++ * This routine should only be called when persist is enabled for a SS
++ * device.
++ */
++static int wait_for_ss_port_enable(struct usb_device *udev,
++ struct usb_hub *hub, int *port1,
++ u16 *portchange, u16 *portstatus)
++{
++ int status = 0, delay_ms = 0;
++
++ while (delay_ms < 2000) {
++ if (status || *portstatus & USB_PORT_STAT_CONNECTION)
++ break;
++ msleep(20);
++ delay_ms += 20;
++ status = hub_port_status(hub, *port1, portstatus, portchange);
++ }
++ return status;
++}
++
++/*
+ * usb_port_resume - re-activate a suspended usb device's upstream port
+ * @udev: device to re-activate, not a root hub
+ * Context: must be able to sleep; device not locked; pm locks held
+@@ -3267,6 +3304,10 @@ int usb_port_resume(struct usb_device *u
+
+ clear_bit(port1, hub->busy_bits);
+
++ if (udev->persist_enabled && hub_is_superspeed(hub->hdev))
++ status = wait_for_ss_port_enable(udev, hub, &port1, &portchange,
++ &portstatus);
++
+ status = check_port_resume_type(udev,
+ hub, port1, status, portchange, portstatus);
+ if (status == 0)
--- /dev/null
+From 977dcfdc60311e7aa571cabf6f39c36dde13339e Mon Sep 17 00:00:00 2001
+From: Alan Stern <stern@rowland.harvard.edu>
+Date: Thu, 17 Jul 2014 16:34:29 -0400
+Subject: USB: OHCI: don't lose track of EDs when a controller dies
+
+From: Alan Stern <stern@rowland.harvard.edu>
+
+commit 977dcfdc60311e7aa571cabf6f39c36dde13339e upstream.
+
+This patch fixes a bug in ohci-hcd. When an URB is unlinked, the
+corresponding Endpoint Descriptor is added to the ed_rm_list and taken
+off the hardware schedule. Once the ED is no longer visible to the
+hardware, finish_unlinks() handles the URBs that were unlinked or have
+completed. If any URBs remain attached to the ED, the ED is added
+back to the hardware schedule -- but only if the controller is
+running.
+
+This fails when a controller dies. A non-empty ED does not get added
+back to the hardware schedule and does not remain on the ed_rm_list;
+ohci-hcd loses track of it. The remaining URBs cannot be unlinked,
+which causes the USB stack to hang.
+
+The patch changes finish_unlinks() so that non-empty EDs remain on
+the ed_rm_list if the controller isn't running. This requires moving
+some of the existing code around, to avoid modifying the ED's hardware
+fields more than once.
+
+Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/usb/host/ohci-q.c | 46 +++++++++++++++++++++++++++++-----------------
+ 1 file changed, 29 insertions(+), 17 deletions(-)
+
+--- a/drivers/usb/host/ohci-q.c
++++ b/drivers/usb/host/ohci-q.c
+@@ -314,8 +314,7 @@ static void periodic_unlink (struct ohci
+ * - ED_OPER: when there's any request queued, the ED gets rescheduled
+ * immediately. HC should be working on them.
+ *
+- * - ED_IDLE: when there's no TD queue. there's no reason for the HC
+- * to care about this ED; safe to disable the endpoint.
++ * - ED_IDLE: when there's no TD queue or the HC isn't running.
+ *
+ * When finish_unlinks() runs later, after SOF interrupt, it will often
+ * complete one or more URB unlinks before making that state change.
+@@ -928,6 +927,10 @@ rescan_all:
+ int completed, modified;
+ __hc32 *prev;
+
++ /* Is this ED already invisible to the hardware? */
++ if (ed->state == ED_IDLE)
++ goto ed_idle;
++
+ /* only take off EDs that the HC isn't using, accounting for
+ * frame counter wraps and EDs with partially retired TDs
+ */
+@@ -957,12 +960,20 @@ skip_ed:
+ }
+ }
+
++ /* ED's now officially unlinked, hc doesn't see */
++ ed->state = ED_IDLE;
++ if (quirk_zfmicro(ohci) && ed->type == PIPE_INTERRUPT)
++ ohci->eds_scheduled--;
++ ed->hwHeadP &= ~cpu_to_hc32(ohci, ED_H);
++ ed->hwNextED = 0;
++ wmb();
++ ed->hwINFO &= ~cpu_to_hc32(ohci, ED_SKIP | ED_DEQUEUE);
++ed_idle:
++
+ /* reentrancy: if we drop the schedule lock, someone might
+ * have modified this list. normally it's just prepending
+ * entries (which we'd ignore), but paranoia won't hurt.
+ */
+- *last = ed->ed_next;
+- ed->ed_next = NULL;
+ modified = 0;
+
+ /* unlink urbs as requested, but rescan the list after
+@@ -1020,19 +1031,20 @@ rescan_this:
+ if (completed && !list_empty (&ed->td_list))
+ goto rescan_this;
+
+- /* ED's now officially unlinked, hc doesn't see */
+- ed->state = ED_IDLE;
+- if (quirk_zfmicro(ohci) && ed->type == PIPE_INTERRUPT)
+- ohci->eds_scheduled--;
+- ed->hwHeadP &= ~cpu_to_hc32(ohci, ED_H);
+- ed->hwNextED = 0;
+- wmb ();
+- ed->hwINFO &= ~cpu_to_hc32 (ohci, ED_SKIP | ED_DEQUEUE);
+-
+- /* but if there's work queued, reschedule */
+- if (!list_empty (&ed->td_list)) {
+- if (ohci->rh_state == OHCI_RH_RUNNING)
+- ed_schedule (ohci, ed);
++ /*
++ * If no TDs are queued, take ED off the ed_rm_list.
++ * Otherwise, if the HC is running, reschedule.
++ * If not, leave it on the list for further dequeues.
++ */
++ if (list_empty(&ed->td_list)) {
++ *last = ed->ed_next;
++ ed->ed_next = NULL;
++ } else if (ohci->rh_state == OHCI_RH_RUNNING) {
++ *last = ed->ed_next;
++ ed->ed_next = NULL;
++ ed_schedule(ohci, ed);
++ } else {
++ last = &ed->ed_next;
+ }
+
+ if (modified)
--- /dev/null
+From 4bdcde358b4bda74e356841d351945ca3f2245dd Mon Sep 17 00:00:00 2001
+From: Patrick Riphagen <patrick.riphagen@xsens.com>
+Date: Thu, 24 Jul 2014 09:09:50 +0200
+Subject: USB: serial: ftdi_sio: Add support for new Xsens devices
+
+From: Patrick Riphagen <patrick.riphagen@xsens.com>
+
+commit 4bdcde358b4bda74e356841d351945ca3f2245dd upstream.
+
+This adds support for new Xsens devices, using Xsens' own Vendor ID.
+
+Signed-off-by: Patrick Riphagen <patrick.riphagen@xsens.com>
+Signed-off-by: Frans Klaver <frans.klaver@xsens.com>
+Cc: Johan Hovold <johan@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/usb/serial/ftdi_sio.c | 2 ++
+ drivers/usb/serial/ftdi_sio_ids.h | 3 +++
+ 2 files changed, 5 insertions(+)
+
+--- a/drivers/usb/serial/ftdi_sio.c
++++ b/drivers/usb/serial/ftdi_sio.c
+@@ -676,6 +676,8 @@ static struct usb_device_id id_table_com
+ { USB_DEVICE(FTDI_VID, XSENS_CONVERTER_5_PID) },
+ { USB_DEVICE(FTDI_VID, XSENS_CONVERTER_6_PID) },
+ { USB_DEVICE(FTDI_VID, XSENS_CONVERTER_7_PID) },
++ { USB_DEVICE(XSENS_VID, XSENS_CONVERTER_PID) },
++ { USB_DEVICE(XSENS_VID, XSENS_MTW_PID) },
+ { USB_DEVICE(FTDI_VID, FTDI_OMNI1509) },
+ { USB_DEVICE(MOBILITY_VID, MOBILITY_USB_SERIAL_PID) },
+ { USB_DEVICE(FTDI_VID, FTDI_ACTIVE_ROBOTS_PID) },
+--- a/drivers/usb/serial/ftdi_sio_ids.h
++++ b/drivers/usb/serial/ftdi_sio_ids.h
+@@ -140,6 +140,9 @@
+ /*
+ * Xsens Technologies BV products (http://www.xsens.com).
+ */
++#define XSENS_VID 0x2639
++#define XSENS_CONVERTER_PID 0xD00D /* Xsens USB-serial converter */
++#define XSENS_MTW_PID 0x0200 /* Xsens MTw */
+ #define XSENS_CONVERTER_0_PID 0xD388 /* Xsens USB converter */
+ #define XSENS_CONVERTER_1_PID 0xD389 /* Xsens Wireless Receiver */
+ #define XSENS_CONVERTER_2_PID 0xD38A
--- /dev/null
+From 9273b8a270878906540349422ab24558b9d65716 Mon Sep 17 00:00:00 2001
+From: Patrick Riphagen <patrick.riphagen@xsens.com>
+Date: Thu, 24 Jul 2014 09:12:52 +0200
+Subject: USB: serial: ftdi_sio: Annotate the current Xsens PID assignments
+
+From: Patrick Riphagen <patrick.riphagen@xsens.com>
+
+commit 9273b8a270878906540349422ab24558b9d65716 upstream.
+
+The converters are used in specific products. It can be useful to know
+which they are exactly.
+
+Signed-off-by: Patrick Riphagen <patrick.riphagen@xsens.com>
+Signed-off-by: Frans Klaver <frans.klaver@xsens.com>
+Cc: Johan Hovold <johan@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/usb/serial/ftdi_sio_ids.h | 10 +++++-----
+ 1 file changed, 5 insertions(+), 5 deletions(-)
+
+--- a/drivers/usb/serial/ftdi_sio_ids.h
++++ b/drivers/usb/serial/ftdi_sio_ids.h
+@@ -140,12 +140,12 @@
+ /*
+ * Xsens Technologies BV products (http://www.xsens.com).
+ */
+-#define XSENS_CONVERTER_0_PID 0xD388
+-#define XSENS_CONVERTER_1_PID 0xD389
++#define XSENS_CONVERTER_0_PID 0xD388 /* Xsens USB converter */
++#define XSENS_CONVERTER_1_PID 0xD389 /* Xsens Wireless Receiver */
+ #define XSENS_CONVERTER_2_PID 0xD38A
+-#define XSENS_CONVERTER_3_PID 0xD38B
+-#define XSENS_CONVERTER_4_PID 0xD38C
+-#define XSENS_CONVERTER_5_PID 0xD38D
++#define XSENS_CONVERTER_3_PID 0xD38B /* Xsens USB-serial converter */
++#define XSENS_CONVERTER_4_PID 0xD38C /* Xsens Wireless Receiver */
++#define XSENS_CONVERTER_5_PID 0xD38D /* Xsens Awinda Station */
+ #define XSENS_CONVERTER_6_PID 0xD38E
+ #define XSENS_CONVERTER_7_PID 0xD38F
+