From 8f54c4e4b193d8aed1c3fcdb2c74e0c66addbbb8 Mon Sep 17 00:00:00 2001 From: Greg Kroah-Hartman Date: Wed, 30 Apr 2014 17:46:35 -0700 Subject: [PATCH] 3.14-stable patches added patches: ftrace-x86-one-more-missing-sync-after-fixup-of-function-modification-failure.patch pci-imx6-wait-for-retraining.patch pci-mvebu-fix-potential-issue-in-range-parsing.patch regulator-arizona-ldo1-correct-default-regulator-init_data.patch usb-fix-crash-during-hotplug-of-pci-usb-controller-card.patch x86-64-modify_ldt-ban-16-bit-segments-on-64-bit-kernels.patch x86-avx-512-avx-512-feature-detection.patch x86-avx-512-enable-avx-512-states-context-switch.patch x86-hash-fix-build-failure-with-older-binutils.patch --- ...xup-of-function-modification-failure.patch | 56 +++++++++ queue-3.14/pci-imx6-wait-for-retraining.patch | 111 ++++++++++++++++++ ...fix-potential-issue-in-range-parsing.patch | 36 ++++++ ...-correct-default-regulator-init_data.patch | 47 ++++++++ queue-3.14/series | 9 ++ ...g-hotplug-of-pci-usb-controller-card.patch | 46 ++++++++ ...an-16-bit-segments-on-64-bit-kernels.patch | 50 ++++++++ ...86-avx-512-avx-512-feature-detection.patch | 39 ++++++ ...enable-avx-512-states-context-switch.patch | 53 +++++++++ ...ix-build-failure-with-older-binutils.patch | 53 +++++++++ 10 files changed, 500 insertions(+) create mode 100644 queue-3.14/ftrace-x86-one-more-missing-sync-after-fixup-of-function-modification-failure.patch create mode 100644 queue-3.14/pci-imx6-wait-for-retraining.patch create mode 100644 queue-3.14/pci-mvebu-fix-potential-issue-in-range-parsing.patch create mode 100644 queue-3.14/regulator-arizona-ldo1-correct-default-regulator-init_data.patch create mode 100644 queue-3.14/usb-fix-crash-during-hotplug-of-pci-usb-controller-card.patch create mode 100644 queue-3.14/x86-64-modify_ldt-ban-16-bit-segments-on-64-bit-kernels.patch create mode 100644 queue-3.14/x86-avx-512-avx-512-feature-detection.patch create mode 100644 queue-3.14/x86-avx-512-enable-avx-512-states-context-switch.patch create mode 100644 queue-3.14/x86-hash-fix-build-failure-with-older-binutils.patch diff --git a/queue-3.14/ftrace-x86-one-more-missing-sync-after-fixup-of-function-modification-failure.patch b/queue-3.14/ftrace-x86-one-more-missing-sync-after-fixup-of-function-modification-failure.patch new file mode 100644 index 00000000000..5bff48e9afb --- /dev/null +++ b/queue-3.14/ftrace-x86-one-more-missing-sync-after-fixup-of-function-modification-failure.patch @@ -0,0 +1,56 @@ +From 12729f14d8357fb845d75155228b21e76360272d Mon Sep 17 00:00:00 2001 +From: Petr Mladek +Date: Mon, 24 Feb 2014 17:12:20 +0100 +Subject: ftrace/x86: One more missing sync after fixup of function modification failure + +From: Petr Mladek + +commit 12729f14d8357fb845d75155228b21e76360272d upstream. + +If a failure occurs while modifying ftrace function, it bails out and will +remove the tracepoints to be back to what the code originally was. + +There is missing the final sync run across the CPUs after the fix up is done +and before the ftrace int3 handler flag is reset. + +Here's the description of the problem: + + CPU0 CPU1 + ---- ---- + remove_breakpoint(); + modifying_ftrace_code = 0; + + [still sees breakpoint] + + [sees modifying_ftrace_code as zero] + [no breakpoint handler] + [goto failed case] + [trap exception - kernel breakpoint, no + handler] + BUG() + +Link: http://lkml.kernel.org/r/1393258342-29978-2-git-send-email-pmladek@suse.cz + +Fixes: 8a4d0a687a5 "ftrace: Use breakpoint method to update ftrace caller" +Acked-by: Frederic Weisbecker +Acked-by: H. Peter Anvin +Signed-off-by: Petr Mladek +Signed-off-by: Steven Rostedt +Signed-off-by: Greg Kroah-Hartman + +--- + arch/x86/kernel/ftrace.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/arch/x86/kernel/ftrace.c ++++ b/arch/x86/kernel/ftrace.c +@@ -659,8 +659,8 @@ ftrace_modify_code(unsigned long ip, uns + ret = -EPERM; + goto out; + } +- run_sync(); + out: ++ run_sync(); + return ret; + + fail_update: diff --git a/queue-3.14/pci-imx6-wait-for-retraining.patch b/queue-3.14/pci-imx6-wait-for-retraining.patch new file mode 100644 index 00000000000..193b7cc89c2 --- /dev/null +++ b/queue-3.14/pci-imx6-wait-for-retraining.patch @@ -0,0 +1,111 @@ +From f95d3ae771916c8c7024fecfb6c420e5dfeced05 Mon Sep 17 00:00:00 2001 +From: Marek Vasut +Date: Wed, 19 Feb 2014 13:22:18 -0700 +Subject: PCI: imx6: Wait for retraining + +From: Marek Vasut + +commit f95d3ae771916c8c7024fecfb6c420e5dfeced05 upstream. + +This patch handles the case where the PCIe link is up and running, yet +drops into the LTSSM training mode. The link spends short time in the LTSSM +training mode, but the current code can misinterpret it as the link being +stalled. Waiting for the LTSSM training to complete fixes the issue. + +Quoting Sascha: + + This is broken since commit 7f9f40c01cce ('PCI: imx6: Report "link up" + only after link training completes'). + + The designware driver changes the PORT_LOGIC_SPEED_CHANGE bit in + dw_pcie_host_init() which causes the link to be retrained. During the + next call to dw_pcie_rd_conf() the link is then reported being down and + the function returns PCIBIOS_DEVICE_NOT_FOUND resulting in nonfunctioning + PCIe. + +Fixes: 7f9f40c01cce (PCI: imx6: Report "link up" only after link training completes) +Tested-by: Troy Kisky +Tested-by: Sascha Hauer +Signed-off-by: Marek Vasut +Signed-off-by: Troy Kisky +Signed-off-by: Bjorn Helgaas +Acked-by: Shawn Guo +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/pci/host/pci-imx6.c | 47 +++++++++++++++++++++++++++++++------------- + 1 file changed, 34 insertions(+), 13 deletions(-) + +--- a/drivers/pci/host/pci-imx6.c ++++ b/drivers/pci/host/pci-imx6.c +@@ -424,20 +424,40 @@ static void imx6_pcie_reset_phy(struct p + + static int imx6_pcie_link_up(struct pcie_port *pp) + { +- u32 rc, ltssm, rx_valid; ++ u32 rc, debug_r0, rx_valid; ++ int count = 5; + + /* +- * Test if the PHY reports that the link is up and also that +- * the link training finished. It might happen that the PHY +- * reports the link is already up, but the link training bit +- * is still set, so make sure to check the training is done +- * as well here. ++ * Test if the PHY reports that the link is up and also that the LTSSM ++ * training finished. There are three possible states of the link when ++ * this code is called: ++ * 1) The link is DOWN (unlikely) ++ * The link didn't come up yet for some reason. This usually means ++ * we have a real problem somewhere. Reset the PHY and exit. This ++ * state calls for inspection of the DEBUG registers. ++ * 2) The link is UP, but still in LTSSM training ++ * Wait for the training to finish, which should take a very short ++ * time. If the training does not finish, we have a problem and we ++ * need to inspect the DEBUG registers. If the training does finish, ++ * the link is up and operating correctly. ++ * 3) The link is UP and no longer in LTSSM training ++ * The link is up and operating correctly. + */ +- rc = readl(pp->dbi_base + PCIE_PHY_DEBUG_R1); +- if ((rc & PCIE_PHY_DEBUG_R1_XMLH_LINK_UP) && +- !(rc & PCIE_PHY_DEBUG_R1_XMLH_LINK_IN_TRAINING)) +- return 1; +- ++ while (1) { ++ rc = readl(pp->dbi_base + PCIE_PHY_DEBUG_R1); ++ if (!(rc & PCIE_PHY_DEBUG_R1_XMLH_LINK_UP)) ++ break; ++ if (!(rc & PCIE_PHY_DEBUG_R1_XMLH_LINK_IN_TRAINING)) ++ return 1; ++ if (!count--) ++ break; ++ dev_dbg(pp->dev, "Link is up, but still in training\n"); ++ /* ++ * Wait a little bit, then re-check if the link finished ++ * the training. ++ */ ++ usleep_range(1000, 2000); ++ } + /* + * From L0, initiate MAC entry to gen2 if EP/RC supports gen2. + * Wait 2ms (LTSSM timeout is 24ms, PHY lock is ~5us in gen2). +@@ -446,15 +466,16 @@ static int imx6_pcie_link_up(struct pcie + * to gen2 is stuck + */ + pcie_phy_read(pp->dbi_base, PCIE_PHY_RX_ASIC_OUT, &rx_valid); +- ltssm = readl(pp->dbi_base + PCIE_PHY_DEBUG_R0) & 0x3F; ++ debug_r0 = readl(pp->dbi_base + PCIE_PHY_DEBUG_R0); + + if (rx_valid & 0x01) + return 0; + +- if (ltssm != 0x0d) ++ if ((debug_r0 & 0x3f) != 0x0d) + return 0; + + dev_err(pp->dev, "transition to gen2 is stuck, reset PHY!\n"); ++ dev_dbg(pp->dev, "debug_r0=%08x debug_r1=%08x\n", debug_r0, rc); + + imx6_pcie_reset_phy(pp); + diff --git a/queue-3.14/pci-mvebu-fix-potential-issue-in-range-parsing.patch b/queue-3.14/pci-mvebu-fix-potential-issue-in-range-parsing.patch new file mode 100644 index 00000000000..51e1f6329ff --- /dev/null +++ b/queue-3.14/pci-mvebu-fix-potential-issue-in-range-parsing.patch @@ -0,0 +1,36 @@ +From 4f4bde1df33bde076f53325bdf2c6430cf85e1bb Mon Sep 17 00:00:00 2001 +From: Jean-Jacques Hiblot +Date: Fri, 14 Feb 2014 11:46:15 -0700 +Subject: PCI: mvebu: Fix potential issue in range parsing + +From: Jean-Jacques Hiblot + +commit 4f4bde1df33bde076f53325bdf2c6430cf85e1bb upstream. + +The second parameter of of_read_number() is not the index, but a size. As +it happens, in this case it may work just fine because of the conversion to +u32 and the favorable endianness on this architecture. + +Fixes: 11be65472a427 ("PCI: mvebu: Adapt to the new device tree layout") +Tested-by: Thomas Petazzoni +Signed-off-by: Jean-Jacques Hiblot +Signed-off-by: Bjorn Helgaas +Acked-by: Thomas Petazzoni +Acked-by: Jason Cooper +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/pci/host/pci-mvebu.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/drivers/pci/host/pci-mvebu.c ++++ b/drivers/pci/host/pci-mvebu.c +@@ -797,7 +797,7 @@ static int mvebu_get_tgt_attr(struct dev + + for (i = 0; i < nranges; i++) { + u32 flags = of_read_number(range, 1); +- u32 slot = of_read_number(range, 2); ++ u32 slot = of_read_number(range + 1, 1); + u64 cpuaddr = of_read_number(range + na, pna); + unsigned long rtype; + diff --git a/queue-3.14/regulator-arizona-ldo1-correct-default-regulator-init_data.patch b/queue-3.14/regulator-arizona-ldo1-correct-default-regulator-init_data.patch new file mode 100644 index 00000000000..a36cfd2a6a0 --- /dev/null +++ b/queue-3.14/regulator-arizona-ldo1-correct-default-regulator-init_data.patch @@ -0,0 +1,47 @@ +From a35ff2861690eaf9dbb38fa744a8a9e6f4ebfd61 Mon Sep 17 00:00:00 2001 +From: Charles Keepax +Date: Tue, 18 Mar 2014 10:49:17 +0000 +Subject: regulator: arizona-ldo1: Correct default regulator init_data + +From: Charles Keepax + +commit a35ff2861690eaf9dbb38fa744a8a9e6f4ebfd61 upstream. + +Both 5102 and 8997 have the regulator capable of supplying 1.8V, and the +voltage step from the 5110 regulator is different from what is specified +in the default description. This patch updates the default regulator +description to match 5110 and selects the 1.8V capable description for +8997. + +Signed-off-by: Charles Keepax +Signed-off-by: Mark Brown +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/regulator/arizona-ldo1.c | 7 +++---- + 1 file changed, 3 insertions(+), 4 deletions(-) + +--- a/drivers/regulator/arizona-ldo1.c ++++ b/drivers/regulator/arizona-ldo1.c +@@ -153,11 +153,9 @@ static const struct regulator_desc arizo + + .vsel_reg = ARIZONA_LDO1_CONTROL_1, + .vsel_mask = ARIZONA_LDO1_VSEL_MASK, +- .bypass_reg = ARIZONA_LDO1_CONTROL_1, +- .bypass_mask = ARIZONA_LDO1_BYPASS, + .min_uV = 900000, +- .uV_step = 50000, +- .n_voltages = 7, ++ .uV_step = 25000, ++ .n_voltages = 13, + .enable_time = 500, + + .owner = THIS_MODULE, +@@ -203,6 +201,7 @@ static int arizona_ldo1_probe(struct pla + */ + switch (arizona->type) { + case WM5102: ++ case WM8997: + desc = &arizona_ldo1_hc; + ldo1->init_data = arizona_ldo1_dvfs; + break; diff --git a/queue-3.14/series b/queue-3.14/series index 088284313e1..63b9e687af4 100644 --- a/queue-3.14/series +++ b/queue-3.14/series @@ -53,3 +53,12 @@ staging-serqt_usb2-fix-sparse-warning-restricted-__le16-degrades-to-integer.patc staging-r8712u-fix-case-where-ethtype-was-never-obtained-and-always-be-checked-against-0.patch staging-comedi-usbdux-bug-fix-for-accessing-ao_chanlist-in-private-data.patch staging-r8188eu-calling-rtw_get_stainfo-with-a-null-sta_addr-will-return-null.patch +x86-hash-fix-build-failure-with-older-binutils.patch +x86-avx-512-avx-512-feature-detection.patch +x86-avx-512-enable-avx-512-states-context-switch.patch +ftrace-x86-one-more-missing-sync-after-fixup-of-function-modification-failure.patch +x86-64-modify_ldt-ban-16-bit-segments-on-64-bit-kernels.patch +regulator-arizona-ldo1-correct-default-regulator-init_data.patch +pci-imx6-wait-for-retraining.patch +pci-mvebu-fix-potential-issue-in-range-parsing.patch +usb-fix-crash-during-hotplug-of-pci-usb-controller-card.patch diff --git a/queue-3.14/usb-fix-crash-during-hotplug-of-pci-usb-controller-card.patch b/queue-3.14/usb-fix-crash-during-hotplug-of-pci-usb-controller-card.patch new file mode 100644 index 00000000000..c03651d9c3f --- /dev/null +++ b/queue-3.14/usb-fix-crash-during-hotplug-of-pci-usb-controller-card.patch @@ -0,0 +1,46 @@ +From a2ff864b53eac9a0e9b05bfe9d1781ccd6c2af71 Mon Sep 17 00:00:00 2001 +From: Alan Stern +Date: Mon, 14 Apr 2014 13:48:47 -0400 +Subject: USB: fix crash during hotplug of PCI USB controller card + +From: Alan Stern + +commit a2ff864b53eac9a0e9b05bfe9d1781ccd6c2af71 upstream. + +The code in hcd-pci.c that matches up EHCI controllers with their +companion UHCI or OHCI controllers assumes that the private drvdata +fields don't get set too early. However, it turns out that this field +gets set by usb_create_hcd(), before hcd-pci expects it, and this can +result in a crash when two controllers are probed in parallel (as can +happen when a new controller card is hotplugged). + +The companions_rwsem lock was supposed to prevent this sort of thing, +but usb_create_hcd() is called outside the scope of the rwsem. + +A simple solution is to check that the root-hub pointer has been +initialized as well as the drvdata field. This doesn't happen until +usb_add_hcd() is called; that call and the check are both protected by +the rwsem. + +This patch should be applied to stable kernels from 3.10 onward. + +Signed-off-by: Alan Stern +Reported-by: Stefani Seibold +Tested-by: Stefani Seibold +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/usb/core/hcd-pci.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/drivers/usb/core/hcd-pci.c ++++ b/drivers/usb/core/hcd-pci.c +@@ -75,7 +75,7 @@ static void for_each_companion(struct pc + PCI_SLOT(companion->devfn) != slot) + continue; + companion_hcd = pci_get_drvdata(companion); +- if (!companion_hcd) ++ if (!companion_hcd || !companion_hcd->self.root_hub) + continue; + fn(pdev, hcd, companion, companion_hcd); + } diff --git a/queue-3.14/x86-64-modify_ldt-ban-16-bit-segments-on-64-bit-kernels.patch b/queue-3.14/x86-64-modify_ldt-ban-16-bit-segments-on-64-bit-kernels.patch new file mode 100644 index 00000000000..33d6bfc3181 --- /dev/null +++ b/queue-3.14/x86-64-modify_ldt-ban-16-bit-segments-on-64-bit-kernels.patch @@ -0,0 +1,50 @@ +From b3b42ac2cbae1f3cecbb6229964a4d48af31d382 Mon Sep 17 00:00:00 2001 +From: "H. Peter Anvin" +Date: Sun, 16 Mar 2014 15:31:54 -0700 +Subject: x86-64, modify_ldt: Ban 16-bit segments on 64-bit kernels + +From: "H. Peter Anvin" + +commit b3b42ac2cbae1f3cecbb6229964a4d48af31d382 upstream. + +The IRET instruction, when returning to a 16-bit segment, only +restores the bottom 16 bits of the user space stack pointer. We have +a software workaround for that ("espfix") for the 32-bit kernel, but +it relies on a nonzero stack segment base which is not available in +32-bit mode. + +Since 16-bit support is somewhat crippled anyway on a 64-bit kernel +(no V86 mode), and most (if not quite all) 64-bit processors support +virtualization for the users who really need it, simply reject +attempts at creating a 16-bit segment when running on top of a 64-bit +kernel. + +Cc: Linus Torvalds +Signed-off-by: H. Peter Anvin +Link: http://lkml.kernel.org/n/tip-kicdm89kzw9lldryb1br9od0@git.kernel.org +Signed-off-by: Greg Kroah-Hartman + +--- + arch/x86/kernel/ldt.c | 11 +++++++++++ + 1 file changed, 11 insertions(+) + +--- a/arch/x86/kernel/ldt.c ++++ b/arch/x86/kernel/ldt.c +@@ -229,6 +229,17 @@ static int write_ldt(void __user *ptr, u + } + } + ++ /* ++ * On x86-64 we do not support 16-bit segments due to ++ * IRET leaking the high bits of the kernel stack address. ++ */ ++#ifdef CONFIG_X86_64 ++ if (!ldt_info.seg_32bit) { ++ error = -EINVAL; ++ goto out_unlock; ++ } ++#endif ++ + fill_ldt(&ldt, &ldt_info); + if (oldmode) + ldt.avl = 0; diff --git a/queue-3.14/x86-avx-512-avx-512-feature-detection.patch b/queue-3.14/x86-avx-512-avx-512-feature-detection.patch new file mode 100644 index 00000000000..14627416215 --- /dev/null +++ b/queue-3.14/x86-avx-512-avx-512-feature-detection.patch @@ -0,0 +1,39 @@ +From 8e5780fdeef7dc490b3f0b3a62704593721fa4f3 Mon Sep 17 00:00:00 2001 +From: Fenghua Yu +Date: Thu, 20 Feb 2014 13:24:50 -0800 +Subject: x86, AVX-512: AVX-512 Feature Detection + +From: Fenghua Yu + +commit 8e5780fdeef7dc490b3f0b3a62704593721fa4f3 upstream. + +AVX-512 is an extention of AVX2. Its spec can be found at: +http://download-software.intel.com/sites/default/files/managed/71/2e/319433-017.pdf + +This patch detects AVX-512 features by CPUID. + +Signed-off-by: Fenghua Yu +Link: http://lkml.kernel.org/r/1392931491-33237-1-git-send-email-fenghua.yu@intel.com +Signed-off-by: H. Peter Anvin +Signed-off-by: Greg Kroah-Hartman + +--- + arch/x86/include/asm/cpufeature.h | 4 ++++ + 1 file changed, 4 insertions(+) + +--- a/arch/x86/include/asm/cpufeature.h ++++ b/arch/x86/include/asm/cpufeature.h +@@ -217,9 +217,13 @@ + #define X86_FEATURE_INVPCID (9*32+10) /* Invalidate Processor Context ID */ + #define X86_FEATURE_RTM (9*32+11) /* Restricted Transactional Memory */ + #define X86_FEATURE_MPX (9*32+14) /* Memory Protection Extension */ ++#define X86_FEATURE_AVX512F (9*32+16) /* AVX-512 Foundation */ + #define X86_FEATURE_RDSEED (9*32+18) /* The RDSEED instruction */ + #define X86_FEATURE_ADX (9*32+19) /* The ADCX and ADOX instructions */ + #define X86_FEATURE_SMAP (9*32+20) /* Supervisor Mode Access Prevention */ ++#define X86_FEATURE_AVX512PF (9*32+26) /* AVX-512 Prefetch */ ++#define X86_FEATURE_AVX512ER (9*32+27) /* AVX-512 Exponential and Reciprocal */ ++#define X86_FEATURE_AVX512CD (9*32+28) /* AVX-512 Conflict Detection */ + + /* + * BUG word(s) diff --git a/queue-3.14/x86-avx-512-enable-avx-512-states-context-switch.patch b/queue-3.14/x86-avx-512-enable-avx-512-states-context-switch.patch new file mode 100644 index 00000000000..05cada4cab7 --- /dev/null +++ b/queue-3.14/x86-avx-512-enable-avx-512-states-context-switch.patch @@ -0,0 +1,53 @@ +From c2bc11f10a39527cd1bb252097b5525664560956 Mon Sep 17 00:00:00 2001 +From: Fenghua Yu +Date: Thu, 20 Feb 2014 13:24:51 -0800 +Subject: x86, AVX-512: Enable AVX-512 States Context Switch + +From: Fenghua Yu + +commit c2bc11f10a39527cd1bb252097b5525664560956 upstream. + +This patch enables Opmask, ZMM_Hi256, and Hi16_ZMM AVX-512 states for +xstate context switch. + +Signed-off-by: Fenghua Yu +Link: http://lkml.kernel.org/r/1392931491-33237-2-git-send-email-fenghua.yu@intel.com +Signed-off-by: H. Peter Anvin +Signed-off-by: Greg Kroah-Hartman + +--- + arch/x86/include/asm/xsave.h | 16 ++++++++++------ + 1 file changed, 10 insertions(+), 6 deletions(-) + +--- a/arch/x86/include/asm/xsave.h ++++ b/arch/x86/include/asm/xsave.h +@@ -6,11 +6,14 @@ + + #define XSTATE_CPUID 0x0000000d + +-#define XSTATE_FP 0x1 +-#define XSTATE_SSE 0x2 +-#define XSTATE_YMM 0x4 +-#define XSTATE_BNDREGS 0x8 +-#define XSTATE_BNDCSR 0x10 ++#define XSTATE_FP 0x1 ++#define XSTATE_SSE 0x2 ++#define XSTATE_YMM 0x4 ++#define XSTATE_BNDREGS 0x8 ++#define XSTATE_BNDCSR 0x10 ++#define XSTATE_OPMASK 0x20 ++#define XSTATE_ZMM_Hi256 0x40 ++#define XSTATE_Hi16_ZMM 0x80 + + #define XSTATE_FPSSE (XSTATE_FP | XSTATE_SSE) + +@@ -23,7 +26,8 @@ + #define XSAVE_YMM_OFFSET (XSAVE_HDR_SIZE + XSAVE_HDR_OFFSET) + + /* Supported features which support lazy state saving */ +-#define XSTATE_LAZY (XSTATE_FP | XSTATE_SSE | XSTATE_YMM) ++#define XSTATE_LAZY (XSTATE_FP | XSTATE_SSE | XSTATE_YMM \ ++ | XSTATE_OPMASK | XSTATE_ZMM_Hi256 | XSTATE_Hi16_ZMM) + + /* Supported features which require eager state saving */ + #define XSTATE_EAGER (XSTATE_BNDREGS | XSTATE_BNDCSR) diff --git a/queue-3.14/x86-hash-fix-build-failure-with-older-binutils.patch b/queue-3.14/x86-hash-fix-build-failure-with-older-binutils.patch new file mode 100644 index 00000000000..4426ed55eae --- /dev/null +++ b/queue-3.14/x86-hash-fix-build-failure-with-older-binutils.patch @@ -0,0 +1,53 @@ +From 06325190bd577e11429444d54f454b9d13f560c9 Mon Sep 17 00:00:00 2001 +From: Jan Beulich +Date: Thu, 27 Feb 2014 08:47:02 +0000 +Subject: x86, hash: Fix build failure with older binutils + +From: Jan Beulich + +commit 06325190bd577e11429444d54f454b9d13f560c9 upstream. + +Just like for other ISA extension instruction uses we should check +whether the assembler actually supports them. The fallback here simply +is to encode an instruction with fixed operands (%eax and %ecx). + +[ hpa: tagging for -stable as a build fix ] + +Signed-off-by: Jan Beulich +Link: http://lkml.kernel.org/r/530F0996020000780011FBE7@nat28.tlf.novell.com +Cc: Francesco Fusco +Cc: Thomas Graf +Cc: David S. Miller +Acked-by: Daniel Borkmann +Signed-off-by: H. Peter Anvin +Signed-off-by: Greg Kroah-Hartman + +--- + arch/x86/Makefile | 1 + + arch/x86/lib/hash.c | 4 ++++ + 2 files changed, 5 insertions(+) + +--- a/arch/x86/Makefile ++++ b/arch/x86/Makefile +@@ -152,6 +152,7 @@ cfi-sections := $(call as-instr,.cfi_sec + + # does binutils support specific instructions? + asinstr := $(call as-instr,fxsaveq (%rax),-DCONFIG_AS_FXSAVEQ=1) ++asinstr += $(call as-instr,crc32l %eax$(comma)%eax,-DCONFIG_AS_CRC32=1) + avx_instr := $(call as-instr,vxorps %ymm0$(comma)%ymm1$(comma)%ymm2,-DCONFIG_AS_AVX=1) + avx2_instr :=$(call as-instr,vpbroadcastb %xmm0$(comma)%ymm1,-DCONFIG_AS_AVX2=1) + +--- a/arch/x86/lib/hash.c ++++ b/arch/x86/lib/hash.c +@@ -39,7 +39,11 @@ + + static inline u32 crc32_u32(u32 crc, u32 val) + { ++#ifdef CONFIG_AS_CRC32 + asm ("crc32l %1,%0\n" : "+r" (crc) : "rm" (val)); ++#else ++ asm (".byte 0xf2, 0x0f, 0x38, 0xf1, 0xc1" : "+a" (crc) : "c" (val)); ++#endif + return crc; + } + -- 2.47.3