--- /dev/null
+From 12729f14d8357fb845d75155228b21e76360272d Mon Sep 17 00:00:00 2001
+From: Petr Mladek <pmladek@suse.cz>
+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 <pmladek@suse.cz>
+
+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]
+ <takes trap>
+ [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 <fweisbec@gmail.com>
+Acked-by: H. Peter Anvin <hpa@linux.intel.com>
+Signed-off-by: Petr Mladek <pmladek@suse.cz>
+Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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:
--- /dev/null
+From f95d3ae771916c8c7024fecfb6c420e5dfeced05 Mon Sep 17 00:00:00 2001
+From: Marek Vasut <marex@denx.de>
+Date: Wed, 19 Feb 2014 13:22:18 -0700
+Subject: PCI: imx6: Wait for retraining
+
+From: Marek Vasut <marex@denx.de>
+
+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 <troy.kisky@boundarydevices.com>
+Tested-by: Sascha Hauer <s.hauer@pengutronix.de>
+Signed-off-by: Marek Vasut <marex@denx.de>
+Signed-off-by: Troy Kisky <troy.kisky@boundarydevices.com>
+Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
+Acked-by: Shawn Guo <shawn.guo@linaro.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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);
+
--- /dev/null
+From 4f4bde1df33bde076f53325bdf2c6430cf85e1bb Mon Sep 17 00:00:00 2001
+From: Jean-Jacques Hiblot <jjhiblot@traphandler.com>
+Date: Fri, 14 Feb 2014 11:46:15 -0700
+Subject: PCI: mvebu: Fix potential issue in range parsing
+
+From: Jean-Jacques Hiblot <jjhiblot@traphandler.com>
+
+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 <thomas.petazzoni@free-electrons.com>
+Signed-off-by: Jean-Jacques Hiblot <jjhiblot@traphandler.com>
+Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
+Acked-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
+Acked-by: Jason Cooper <jason@lakedaemon.net>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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;
+
--- /dev/null
+From a35ff2861690eaf9dbb38fa744a8a9e6f4ebfd61 Mon Sep 17 00:00:00 2001
+From: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
+Date: Tue, 18 Mar 2014 10:49:17 +0000
+Subject: regulator: arizona-ldo1: Correct default regulator init_data
+
+From: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
+
+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 <ckeepax@opensource.wolfsonmicro.com>
+Signed-off-by: Mark Brown <broonie@linaro.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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;
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
--- /dev/null
+From a2ff864b53eac9a0e9b05bfe9d1781ccd6c2af71 Mon Sep 17 00:00:00 2001
+From: Alan Stern <stern@rowland.harvard.edu>
+Date: Mon, 14 Apr 2014 13:48:47 -0400
+Subject: USB: fix crash during hotplug of PCI USB controller card
+
+From: Alan Stern <stern@rowland.harvard.edu>
+
+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 <stern@rowland.harvard.edu>
+Reported-by: Stefani Seibold <stefani@seibold.net>
+Tested-by: Stefani Seibold <stefani@seibold.net>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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);
+ }
--- /dev/null
+From b3b42ac2cbae1f3cecbb6229964a4d48af31d382 Mon Sep 17 00:00:00 2001
+From: "H. Peter Anvin" <hpa@linux.intel.com>
+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" <hpa@linux.intel.com>
+
+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 <torvalds@linux-foundation.org>
+Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
+Link: http://lkml.kernel.org/n/tip-kicdm89kzw9lldryb1br9od0@git.kernel.org
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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;
--- /dev/null
+From 8e5780fdeef7dc490b3f0b3a62704593721fa4f3 Mon Sep 17 00:00:00 2001
+From: Fenghua Yu <fenghua.yu@intel.com>
+Date: Thu, 20 Feb 2014 13:24:50 -0800
+Subject: x86, AVX-512: AVX-512 Feature Detection
+
+From: Fenghua Yu <fenghua.yu@intel.com>
+
+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 <fenghua.yu@intel.com>
+Link: http://lkml.kernel.org/r/1392931491-33237-1-git-send-email-fenghua.yu@intel.com
+Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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)
--- /dev/null
+From c2bc11f10a39527cd1bb252097b5525664560956 Mon Sep 17 00:00:00 2001
+From: Fenghua Yu <fenghua.yu@intel.com>
+Date: Thu, 20 Feb 2014 13:24:51 -0800
+Subject: x86, AVX-512: Enable AVX-512 States Context Switch
+
+From: Fenghua Yu <fenghua.yu@intel.com>
+
+commit c2bc11f10a39527cd1bb252097b5525664560956 upstream.
+
+This patch enables Opmask, ZMM_Hi256, and Hi16_ZMM AVX-512 states for
+xstate context switch.
+
+Signed-off-by: Fenghua Yu <fenghua.yu@intel.com>
+Link: http://lkml.kernel.org/r/1392931491-33237-2-git-send-email-fenghua.yu@intel.com
+Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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)
--- /dev/null
+From 06325190bd577e11429444d54f454b9d13f560c9 Mon Sep 17 00:00:00 2001
+From: Jan Beulich <JBeulich@suse.com>
+Date: Thu, 27 Feb 2014 08:47:02 +0000
+Subject: x86, hash: Fix build failure with older binutils
+
+From: Jan Beulich <JBeulich@suse.com>
+
+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 <jbeulich@suse.com>
+Link: http://lkml.kernel.org/r/530F0996020000780011FBE7@nat28.tlf.novell.com
+Cc: Francesco Fusco <ffusco@redhat.com>
+Cc: Thomas Graf <tgraf@redhat.com>
+Cc: David S. Miller <davem@davemloft.net>
+Acked-by: Daniel Borkmann <dborkman@redhat.com>
+Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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;
+ }
+
projects / thirdparty / kernel / stable-queue.git / commitdiff
