- Linux-stable-mirror - lists.linaro.org

Patch "cpufreq/sh: Replace racy task affinity logic" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled cpufreq/sh: Replace racy task affinity logic to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: cpufreq-sh-replace-racy-task-affinity-logic.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Thu Mar 22 14:40:23 CET 2018 From: Thomas Gleixner <tglx(a)linutronix.de> Date: Wed, 12 Apr 2017 22:07:36 +0200 Subject: cpufreq/sh: Replace racy task affinity logic From: Thomas Gleixner <tglx(a)linutronix.de> [ Upstream commit 205dcc1ecbc566cbc20acf246e68de3b080b3ecf ] The target() callback must run on the affected cpu. This is achieved by temporarily setting the affinity of the calling thread to the requested CPU and reset it to the original affinity afterwards. That's racy vs. concurrent affinity settings for that thread resulting in code executing on the wrong CPU. Replace it by work_on_cpu(). All call pathes which invoke the callbacks are already protected against CPU hotplug. Signed-off-by: Thomas Gleixner <tglx(a)linutronix.de> Acked-by: Viresh Kumar <viresh.kumar(a)linaro.org> Cc: Fenghua Yu <fenghua.yu(a)intel.com> Cc: Tony Luck <tony.luck(a)intel.com> Cc: Herbert Xu <herbert(a)gondor.apana.org.au> Cc: "Rafael J. Wysocki" <rjw(a)rjwysocki.net> Cc: Peter Zijlstra <peterz(a)infradead.org> Cc: Benjamin Herrenschmidt <benh(a)kernel.crashing.org> Cc: Sebastian Siewior <bigeasy(a)linutronix.de> Cc: linux-pm(a)vger.kernel.org Cc: Lai Jiangshan <jiangshanlai(a)gmail.com> Cc: Michael Ellerman <mpe(a)ellerman.id.au> Cc: Tejun Heo <tj(a)kernel.org> Cc: "David S. Miller" <davem(a)davemloft.net> Cc: Len Brown <lenb(a)kernel.org> Link: http://lkml.kernel.org/r/20170412201042.958216363@linutronix.de Signed-off-by: Thomas Gleixner <tglx(a)linutronix.de> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/cpufreq/sh-cpufreq.c | 45 +++++++++++++++++++++++++------------------ 1 file changed, 27 insertions(+), 18 deletions(-) --- a/drivers/cpufreq/sh-cpufreq.c +++ b/drivers/cpufreq/sh-cpufreq.c @@ -30,54 +30,63 @@ static DEFINE_PER_CPU(struct clk, sh_cpuclk); +struct cpufreq_target { + struct cpufreq_policy *policy; + unsigned int freq; +}; + static unsigned int sh_cpufreq_get(unsigned int cpu) { return (clk_get_rate(&per_cpu(sh_cpuclk, cpu)) + 500) / 1000; } -/* - * Here we notify other drivers of the proposed change and the final change. - */ -static int sh_cpufreq_target(struct cpufreq_policy *policy, - unsigned int target_freq, - unsigned int relation) +static long __sh_cpufreq_target(void *arg) { - unsigned int cpu = policy->cpu; + struct cpufreq_target *target = arg; + struct cpufreq_policy *policy = target->policy; + int cpu = policy->cpu; struct clk *cpuclk = &per_cpu(sh_cpuclk, cpu); - cpumask_t cpus_allowed; struct cpufreq_freqs freqs; struct device *dev; long freq; - cpus_allowed = current->cpus_allowed; - set_cpus_allowed_ptr(current, cpumask_of(cpu)); - - BUG_ON(smp_processor_id() != cpu); + if (smp_processor_id() != cpu) + return -ENODEV; dev = get_cpu_device(cpu); /* Convert target_freq from kHz to Hz */ - freq = clk_round_rate(cpuclk, target_freq * 1000); + freq = clk_round_rate(cpuclk, target->freq * 1000); if (freq < (policy->min * 1000) || freq > (policy->max * 1000)) return -EINVAL; - dev_dbg(dev, "requested frequency %u Hz\n", target_freq * 1000); + dev_dbg(dev, "requested frequency %u Hz\n", target->freq * 1000); freqs.old = sh_cpufreq_get(cpu); freqs.new = (freq + 500) / 1000; freqs.flags = 0; - cpufreq_freq_transition_begin(policy, &freqs); - set_cpus_allowed_ptr(current, &cpus_allowed); + cpufreq_freq_transition_begin(target->policy, &freqs); clk_set_rate(cpuclk, freq); - cpufreq_freq_transition_end(policy, &freqs, 0); + cpufreq_freq_transition_end(target->policy, &freqs, 0); dev_dbg(dev, "set frequency %lu Hz\n", freq); - return 0; } +/* + * Here we notify other drivers of the proposed change and the final change. + */ +static int sh_cpufreq_target(struct cpufreq_policy *policy, + unsigned int target_freq, + unsigned int relation) +{ + struct cpufreq_target data = { .policy = policy, .freq = target_freq }; + + return work_on_cpu(policy->cpu, __sh_cpufreq_target, &data); +} + static int sh_cpufreq_verify(struct cpufreq_policy *policy) { struct clk *cpuclk = &per_cpu(sh_cpuclk, policy->cpu); Patches currently in stable-queue which might be from tglx(a)linutronix.de are queue-4.9/acpi-processor-fix-error-handling-in-__acpi_processor_start.patch queue-4.9/x86-reboot-turn-off-kvm-when-halting-a-cpu.patch queue-4.9/acpi-processor-replace-racy-task-affinity-logic.patch queue-4.9/time-change-posix-clocks-ops-interfaces-to-use-timespec64.patch queue-4.9/genirq-use-irqd_get_trigger_type-to-compare-the-trigger-type-for-shared-irqs.patch queue-4.9/cpufreq-sh-replace-racy-task-affinity-logic.patch queue-4.9/irqchip-mips-gic-separate-ipi-reservation-usage-tracking.patch queue-4.9/x86-kaslr-fix-kexec-kernel-boot-crash-when-kaslr-randomization-fails.patch

7 years, 6 months

1
0
0 0

Patch "coresight: Fix disabling of CoreSight TPIU" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled coresight: Fix disabling of CoreSight TPIU to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: coresight-fix-disabling-of-coresight-tpiu.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Thu Mar 22 14:40:24 CET 2018 From: Robert Walker <robert.walker(a)arm.com> Date: Mon, 18 Dec 2017 11:05:44 -0700 Subject: coresight: Fix disabling of CoreSight TPIU From: Robert Walker <robert.walker(a)arm.com> [ Upstream commit 11595db8e17faaa05fadc25746c870e31276962f ] The CoreSight TPIU should be disabled when tracing to other sinks to allow them to operate at full bandwidth. This patch fixes tpiu_disable_hw() to correctly disable the TPIU by configuring the TPIU to stop on flush, initiating a manual flush, waiting for the flush to complete and then waits for the TPIU to indicate it has stopped. Signed-off-by: Robert Walker <robert.walker(a)arm.com> Tested-by: Mike Leach <mike.leach(a)linaro.org> Signed-off-by: Mathieu Poirier <mathieu.poirier(a)linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/hwtracing/coresight/coresight-tpiu.c | 13 ++++++++++--- 1 file changed, 10 insertions(+), 3 deletions(-) --- a/drivers/hwtracing/coresight/coresight-tpiu.c +++ b/drivers/hwtracing/coresight/coresight-tpiu.c @@ -46,8 +46,11 @@ #define TPIU_ITATBCTR0 0xef8 /** register definition **/ +/* FFSR - 0x300 */ +#define FFSR_FT_STOPPED BIT(1) /* FFCR - 0x304 */ #define FFCR_FON_MAN BIT(6) +#define FFCR_STOP_FI BIT(12) /** * @base: memory mapped base address for this component. @@ -85,10 +88,14 @@ static void tpiu_disable_hw(struct tpiu_ { CS_UNLOCK(drvdata->base); - /* Clear formatter controle reg. */ - writel_relaxed(0x0, drvdata->base + TPIU_FFCR); + /* Clear formatter and stop on flush */ + writel_relaxed(FFCR_STOP_FI, drvdata->base + TPIU_FFCR); /* Generate manual flush */ - writel_relaxed(FFCR_FON_MAN, drvdata->base + TPIU_FFCR); + writel_relaxed(FFCR_STOP_FI | FFCR_FON_MAN, drvdata->base + TPIU_FFCR); + /* Wait for flush to complete */ + coresight_timeout(drvdata->base, TPIU_FFCR, FFCR_FON_MAN, 0); + /* Wait for formatter to stop */ + coresight_timeout(drvdata->base, TPIU_FFSR, FFSR_FT_STOPPED, 1); CS_LOCK(drvdata->base); } Patches currently in stable-queue which might be from robert.walker(a)arm.com are queue-4.9/coresight-fix-disabling-of-coresight-tpiu.patch

7 years, 6 months

1
0
0 0

Patch "clk: si5351: Rename internal plls to avoid name collisions" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled clk: si5351: Rename internal plls to avoid name collisions to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: clk-si5351-rename-internal-plls-to-avoid-name-collisions.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Thu Mar 22 14:40:24 CET 2018 From: Sergej Sawazki <sergej(a)taudac.com> Date: Tue, 25 Jul 2017 23:21:02 +0200 Subject: clk: si5351: Rename internal plls to avoid name collisions From: Sergej Sawazki <sergej(a)taudac.com> [ Upstream commit cdba9a4fb0b53703959ac861e415816cb61aded4 ] This drivers probe fails due to a clock name collision if a clock named 'plla' or 'pllb' is already registered when registering this drivers internal plls. Fix it by renaming internal plls to avoid name collisions. Cc: Sebastian Hesselbarth <sebastian.hesselbarth(a)gmail.com> Cc: Rabeeh Khoury <rabeeh(a)solid-run.com> Signed-off-by: Sergej Sawazki <sergej(a)taudac.com> Signed-off-by: Stephen Boyd <sboyd(a)codeaurora.org> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/clk/clk-si5351.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/drivers/clk/clk-si5351.c +++ b/drivers/clk/clk-si5351.c @@ -72,7 +72,7 @@ static const char * const si5351_input_n "xtal", "clkin" }; static const char * const si5351_pll_names[] = { - "plla", "pllb", "vxco" + "si5351_plla", "si5351_pllb", "si5351_vxco" }; static const char * const si5351_msynth_names[] = { "ms0", "ms1", "ms2", "ms3", "ms4", "ms5", "ms6", "ms7" Patches currently in stable-queue which might be from sergej(a)taudac.com are queue-4.9/clk-si5351-rename-internal-plls-to-avoid-name-collisions.patch

7 years, 6 months

1
0
0 0

Patch "clk: ns2: Correct SDIO bits" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled clk: ns2: Correct SDIO bits to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: clk-ns2-correct-sdio-bits.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Thu Mar 22 14:40:23 CET 2018 From: Bharat Kumar Reddy Gooty <bharat.gooty(a)broadcom.com> Date: Mon, 20 Mar 2017 18:12:14 -0400 Subject: clk: ns2: Correct SDIO bits From: Bharat Kumar Reddy Gooty <bharat.gooty(a)broadcom.com> [ Upstream commit 8973aa4aecac223548366ca81818309a0f0efa6d ] Corrected the bits for power and iso. Signed-off-by: Bharat Kumar Reddy Gooty <bharat.gooty(a)broadcom.com> Signed-off-by: Jon Mason <jon.mason(a)broadcom.com> Fixes: f7225a83 ("clk: ns2: add clock support for Broadcom Northstar 2 SoC") Signed-off-by: Stephen Boyd <sboyd(a)codeaurora.org> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/clk/bcm/clk-ns2.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/drivers/clk/bcm/clk-ns2.c +++ b/drivers/clk/bcm/clk-ns2.c @@ -103,7 +103,7 @@ CLK_OF_DECLARE(ns2_genpll_src_clk, "brcm static const struct iproc_pll_ctrl genpll_sw = { .flags = IPROC_CLK_AON | IPROC_CLK_PLL_SPLIT_STAT_CTRL, - .aon = AON_VAL(0x0, 2, 9, 8), + .aon = AON_VAL(0x0, 1, 11, 10), .reset = RESET_VAL(0x4, 2, 1), .dig_filter = DF_VAL(0x0, 9, 3, 5, 4, 2, 3), .ndiv_int = REG_VAL(0x8, 4, 10), Patches currently in stable-queue which might be from bharat.gooty(a)broadcom.com are queue-4.9/clk-ns2-correct-sdio-bits.patch

7 years, 6 months

1
0
0 0

Patch "clk: Don't touch hardware when reparenting during registration" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled clk: Don't touch hardware when reparenting during registration to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: clk-don-t-touch-hardware-when-reparenting-during-registration.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Thu Mar 22 14:40:24 CET 2018 From: Stephen Boyd <sboyd(a)codeaurora.org> Date: Thu, 2 Nov 2017 00:36:09 -0700 Subject: clk: Don't touch hardware when reparenting during registration From: Stephen Boyd <sboyd(a)codeaurora.org> [ Upstream commit f8f8f1d04494d3a6546bee3f0618c4dba31d7b72 ] The orphan clocks reparent operation shouldn't touch the hardware if clocks are enabled, otherwise it may get a chance to disable a newly registered critical clock which triggers the warning below. Assuming we have two clocks: A and B, B is the parent of A. Clock A has flag: CLK_OPS_PARENT_ENABLE Clock B has flag: CLK_IS_CRITICAL Step 1: Clock A is registered, then it becomes orphan. Step 2: Clock B is registered. Before clock B reach the critical clock enable operation, orphan A will find the newly registered parent B and do reparent operation, then parent B will be finally disabled in __clk_set_parent_after() due to CLK_OPS_PARENT_ENABLE flag as there's still no users of B which will then trigger the following warning. WARNING: CPU: 0 PID: 0 at drivers/clk/clk.c:597 clk_core_disable+0xb4/0xe0 Modules linked in: CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.11.0-rc1-00056-gdff1f66-dirty #1373 Hardware name: Generic DT based system Backtrace: [<c010c4bc>] (dump_backtrace) from [<c010c764>] (show_stack+0x18/0x1c) r6:600000d3 r5:00000000 r4:c0e26358 r3:00000000 [<c010c74c>] (show_stack) from [<c040599c>] (dump_stack+0xb4/0xe8) [<c04058e8>] (dump_stack) from [<c0125c94>] (__warn+0xd8/0x104) r10:c0c21cd0 r9:c048aa78 r8:00000255 r7:00000009 r6:c0c1cd90 r5:00000000 r4:00000000 r3:c0e01d34 [<c0125bbc>] (__warn) from [<c0125d74>] (warn_slowpath_null+0x28/0x30) r9:00000000 r8:ef00bf80 r7:c165ac4c r6:ef00bf80 r5:ef00bf80 r4:ef00bf80 [<c0125d4c>] (warn_slowpath_null) from [<c048aa78>] (clk_core_disable+0xb4/0xe0) [<c048a9c4>] (clk_core_disable) from [<c048be88>] (clk_core_disable_lock+0x20/0x2c) r4:000000d3 r3:c0e0af00 [<c048be68>] (clk_core_disable_lock) from [<c048c224>] (clk_core_disable_unprepare+0x14/0x28) r5:00000000 r4:ef00bf80 [<c048c210>] (clk_core_disable_unprepare) from [<c048c270>] (__clk_set_parent_after+0x38/0x54) r4:ef00bd80 r3:000010a0 [<c048c238>] (__clk_set_parent_after) from [<c048daa8>] (clk_register+0x4d0/0x648) r6:ef00d500 r5:ef00bf80 r4:ef00bd80 r3:ef00bfd4 [<c048d5d8>] (clk_register) from [<c048dc30>] (clk_hw_register+0x10/0x1c) r9:00000000 r8:00000003 r7:00000000 r6:00000824 r5:00000001 r4:ef00d500 [<c048dc20>] (clk_hw_register) from [<c048e698>] (_register_divider+0xcc/0x120) [<c048e5cc>] (_register_divider) from [<c048e730>] (clk_register_divider+0x44/0x54) r10:00000004 r9:00000003 r8:00000001 r7:00000000 r6:00000003 r5:00000001 r4:f0810030 [<c048e6ec>] (clk_register_divider) from [<c0d3ff58>] (imx7ulp_clocks_init+0x558/0xe98) r7:c0e296f8 r6:c165c808 r5:00000000 r4:c165c808 [<c0d3fa00>] (imx7ulp_clocks_init) from [<c0d24db0>] (of_clk_init+0x118/0x1e0) r10:00000001 r9:c0e01f68 r8:00000000 r7:c0e01f60 r6:ef7f8974 r5:ef0035c0 r4:00000006 [<c0d24c98>] (of_clk_init) from [<c0d04a50>] (time_init+0x2c/0x38) r10:efffed40 r9:c0d61a48 r8:c0e78000 r7:c0e07900 r6:ffffffff r5:c0e78000 r4:00000000 [<c0d04a24>] (time_init) from [<c0d00b8c>] (start_kernel+0x218/0x394) [<c0d00974>] (start_kernel) from [<6000807c>] (0x6000807c) r10:00000000 r9:410fc075 r8:6000406a r7:c0e0c930 r6:c0d61a44 r5:c0e07918 r4:c0e78294 We know that the clk isn't enabled with any sort of prepare_count here so we don't need to enable anything to prevent a race. And we're holding the prepare mutex so set_rate/set_parent can't race here either. Based on an earlier patch by Dong Aisheng. Fixes: fc8726a2c021 ("clk: core: support clocks which requires parents enable (part 2)") Cc: Michael Turquette <mturquette(a)baylibre.com> Cc: Shawn Guo <shawnguo(a)kernel.org> Reported-by: Dong Aisheng <aisheng.dong(a)nxp.com> Signed-off-by: Stephen Boyd <sboyd(a)codeaurora.org> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/clk/clk.c | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) --- a/drivers/clk/clk.c +++ b/drivers/clk/clk.c @@ -2443,14 +2443,17 @@ static int __clk_core_init(struct clk_co */ hlist_for_each_entry_safe(orphan, tmp2, &clk_orphan_list, child_node) { struct clk_core *parent = __clk_init_parent(orphan); + unsigned long flags; /* * we could call __clk_set_parent, but that would result in a * redundant call to the .set_rate op, if it exists */ if (parent) { - __clk_set_parent_before(orphan, parent); - __clk_set_parent_after(orphan, parent, NULL); + /* update the clk tree topology */ + flags = clk_enable_lock(); + clk_reparent(orphan, parent); + clk_enable_unlock(flags); __clk_recalc_accuracies(orphan); __clk_recalc_rates(orphan, 0); } Patches currently in stable-queue which might be from sboyd(a)codeaurora.org are queue-4.9/clk-ns2-correct-sdio-bits.patch queue-4.9/clk-si5351-rename-internal-plls-to-avoid-name-collisions.patch queue-4.9/clk-don-t-touch-hardware-when-reparenting-during-registration.patch queue-4.9/clk-axi-clkgen-correctly-handle-nocount-bit-in-recalc_rate.patch

7 years, 6 months

1
0
0 0

Patch "clk: axi-clkgen: Correctly handle nocount bit in recalc_rate()" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled clk: axi-clkgen: Correctly handle nocount bit in recalc_rate() to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: clk-axi-clkgen-correctly-handle-nocount-bit-in-recalc_rate.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Thu Mar 22 14:40:24 CET 2018 From: Lars-Peter Clausen <lars(a)metafoo.de> Date: Tue, 5 Sep 2017 11:32:40 +0200 Subject: clk: axi-clkgen: Correctly handle nocount bit in recalc_rate() From: Lars-Peter Clausen <lars(a)metafoo.de> [ Upstream commit 063578dc5f407f67d149133818efabe457daafda ] If the nocount bit is set the divider is bypassed and the settings for the divider count should be ignored and a divider value of 1 should be assumed. Handle this correctly in the driver recalc_rate() callback. While the driver sets up the part so that the read back dividers values yield the correct result the power-on reset settings of the part might not reflect this and hence calling e.g. clk_get_rate() without prior calls to clk_set_rate() will yield the wrong result. Signed-off-by: Lars-Peter Clausen <lars(a)metafoo.de> Signed-off-by: Stephen Boyd <sboyd(a)codeaurora.org> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/clk/clk-axi-clkgen.c | 29 ++++++++++++++++++++++++----- 1 file changed, 24 insertions(+), 5 deletions(-) --- a/drivers/clk/clk-axi-clkgen.c +++ b/drivers/clk/clk-axi-clkgen.c @@ -40,6 +40,10 @@ #define MMCM_REG_FILTER1 0x4e #define MMCM_REG_FILTER2 0x4f +#define MMCM_CLKOUT_NOCOUNT BIT(6) + +#define MMCM_CLK_DIV_NOCOUNT BIT(12) + struct axi_clkgen { void __iomem *base; struct clk_hw clk_hw; @@ -315,12 +319,27 @@ static unsigned long axi_clkgen_recalc_r unsigned int reg; unsigned long long tmp; - axi_clkgen_mmcm_read(axi_clkgen, MMCM_REG_CLKOUT0_1, &reg); - dout = (reg & 0x3f) + ((reg >> 6) & 0x3f); + axi_clkgen_mmcm_read(axi_clkgen, MMCM_REG_CLKOUT0_2, &reg); + if (reg & MMCM_CLKOUT_NOCOUNT) { + dout = 1; + } else { + axi_clkgen_mmcm_read(axi_clkgen, MMCM_REG_CLKOUT0_1, &reg); + dout = (reg & 0x3f) + ((reg >> 6) & 0x3f); + } + axi_clkgen_mmcm_read(axi_clkgen, MMCM_REG_CLK_DIV, &reg); - d = (reg & 0x3f) + ((reg >> 6) & 0x3f); - axi_clkgen_mmcm_read(axi_clkgen, MMCM_REG_CLK_FB1, &reg); - m = (reg & 0x3f) + ((reg >> 6) & 0x3f); + if (reg & MMCM_CLK_DIV_NOCOUNT) + d = 1; + else + d = (reg & 0x3f) + ((reg >> 6) & 0x3f); + + axi_clkgen_mmcm_read(axi_clkgen, MMCM_REG_CLK_FB2, &reg); + if (reg & MMCM_CLKOUT_NOCOUNT) { + m = 1; + } else { + axi_clkgen_mmcm_read(axi_clkgen, MMCM_REG_CLK_FB1, &reg); + m = (reg & 0x3f) + ((reg >> 6) & 0x3f); + } if (d == 0 || dout == 0) return 0; Patches currently in stable-queue which might be from lars(a)metafoo.de are queue-4.9/clk-axi-clkgen-correctly-handle-nocount-bit-in-recalc_rate.patch

7 years, 6 months

1
0
0 0

Patch "cifs: small underflow in cnvrtDosUnixTm()" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled cifs: small underflow in cnvrtDosUnixTm() to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: cifs-small-underflow-in-cnvrtdosunixtm.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Thu Mar 22 14:40:24 CET 2018 From: Dan Carpenter <dan.carpenter(a)oracle.com> Date: Mon, 1 May 2017 21:43:43 +0300 Subject: cifs: small underflow in cnvrtDosUnixTm() From: Dan Carpenter <dan.carpenter(a)oracle.com> [ Upstream commit 564277eceeca01e02b1ef3e141cfb939184601b4 ] January is month 1. There is no zero-th month. If someone passes a zero month then it means we read from one space before the start of the total_days_of_prev_months[] array. We may as well also be strict about days as well. Fixes: 1bd5bbcb6531 ("[CIFS] Legacy time handling for Win9x and OS/2 part 1") Signed-off-by: Dan Carpenter <dan.carpenter(a)oracle.com> Signed-off-by: Steve French <smfrench(a)gmail.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- fs/cifs/netmisc.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) --- a/fs/cifs/netmisc.c +++ b/fs/cifs/netmisc.c @@ -980,10 +980,10 @@ struct timespec cnvrtDosUnixTm(__le16 le cifs_dbg(VFS, "illegal hours %d\n", st->Hours); days = sd->Day; month = sd->Month; - if ((days > 31) || (month > 12)) { + if (days < 1 || days > 31 || month < 1 || month > 12) { cifs_dbg(VFS, "illegal date, month %d day: %d\n", month, days); - if (month > 12) - month = 12; + days = clamp(days, 1, 31); + month = clamp(month, 1, 12); } month -= 1; days += total_days_of_prev_months[month]; Patches currently in stable-queue which might be from dan.carpenter(a)oracle.com are queue-4.9/netfilter-x_tables-unlock-on-error-in-xt_find_table_lock.patch queue-4.9/asoc-intel-skylake-uninitialized-variable-in-probe_codec.patch queue-4.9/mmc-host-omap_hsmmc-checking-for-null-instead-of-is_err.patch queue-4.9/qed-unlock-on-error-in-qed_vf_pf_acquire.patch queue-4.9/hsi-ssi_protocol-double-free-in-ssip_pn_xmit.patch queue-4.9/cifs-small-underflow-in-cnvrtdosunixtm.patch queue-4.9/ib-rdmavt-restore-irqs-on-error-path-in-rvt_create_ah.patch

7 years, 6 months

1
0
0 0

Patch "Btrfs: send, fix file hole not being preserved due to inline extent" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled Btrfs: send, fix file hole not being preserved due to inline extent to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: btrfs-send-fix-file-hole-not-being-preserved-due-to-inline-extent.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Thu Mar 22 14:40:23 CET 2018 From: Filipe Manana <fdmanana(a)suse.com> Date: Tue, 4 Apr 2017 20:31:00 +0100 Subject: Btrfs: send, fix file hole not being preserved due to inline extent From: Filipe Manana <fdmanana(a)suse.com> [ Upstream commit e1cbfd7bf6dabdac561c75d08357571f44040a45 ] Normally we don't have inline extents followed by regular extents, but there's currently at least one harmless case where this happens. For example, when the page size is 4Kb and compression is enabled: $ mkfs.btrfs -f /dev/sdb $ mount -o compress /dev/sdb /mnt $ xfs_io -f -c "pwrite -S 0xaa 0 4K" -c "fsync" /mnt/foobar $ xfs_io -c "pwrite -S 0xbb 8K 4K" -c "fsync" /mnt/foobar In this case we get a compressed inline extent, representing 4Kb of data, followed by a hole extent and then a regular data extent. The inline extent was not expanded/converted to a regular extent exactly because it represents 4Kb of data. This does not cause any apparent problem (such as the issue solved by commit e1699d2d7bf6 ("btrfs: add missing memset while reading compressed inline extents")) except trigger an unexpected case in the incremental send code path that makes us issue an operation to write a hole when it's not needed, resulting in more writes at the receiver and wasting space at the receiver. So teach the incremental send code to deal with this particular case. The issue can be currently triggered by running fstests btrfs/137 with compression enabled (MOUNT_OPTIONS="-o compress" ./check btrfs/137). Signed-off-by: Filipe Manana <fdmanana(a)suse.com> Reviewed-by: Liu Bo <bo.li.liu(a)oracle.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- fs/btrfs/send.c | 23 +++++++++++++++++++++-- 1 file changed, 21 insertions(+), 2 deletions(-) --- a/fs/btrfs/send.c +++ b/fs/btrfs/send.c @@ -5156,13 +5156,19 @@ static int is_extent_unchanged(struct se while (key.offset < ekey->offset + left_len) { ei = btrfs_item_ptr(eb, slot, struct btrfs_file_extent_item); right_type = btrfs_file_extent_type(eb, ei); - if (right_type != BTRFS_FILE_EXTENT_REG) { + if (right_type != BTRFS_FILE_EXTENT_REG && + right_type != BTRFS_FILE_EXTENT_INLINE) { ret = 0; goto out; } right_disknr = btrfs_file_extent_disk_bytenr(eb, ei); - right_len = btrfs_file_extent_num_bytes(eb, ei); + if (right_type == BTRFS_FILE_EXTENT_INLINE) { + right_len = btrfs_file_extent_inline_len(eb, slot, ei); + right_len = PAGE_ALIGN(right_len); + } else { + right_len = btrfs_file_extent_num_bytes(eb, ei); + } right_offset = btrfs_file_extent_offset(eb, ei); right_gen = btrfs_file_extent_generation(eb, ei); @@ -5176,6 +5182,19 @@ static int is_extent_unchanged(struct se goto out; } + /* + * We just wanted to see if when we have an inline extent, what + * follows it is a regular extent (wanted to check the above + * condition for inline extents too). This should normally not + * happen but it's possible for example when we have an inline + * compressed extent representing data with a size matching + * the page size (currently the same as sector size). + */ + if (right_type == BTRFS_FILE_EXTENT_INLINE) { + ret = 0; + goto out; + } + left_offset_fixed = left_offset; if (key.offset < ekey->offset) { /* Fix the right offset for 2a and 7. */ Patches currently in stable-queue which might be from fdmanana(a)suse.com are queue-4.9/btrfs-fix-incorrect-space-accounting-after-failure-to-insert-inline-extent.patch queue-4.9/btrfs-fix-extent-map-leak-during-fallocate-error-path.patch queue-4.9/btrfs-send-fix-file-hole-not-being-preserved-due-to-inline-extent.patch

7 years, 6 months

1
0
0 0

Patch "Btrfs: fix incorrect space accounting after failure to insert inline extent" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled Btrfs: fix incorrect space accounting after failure to insert inline extent to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: btrfs-fix-incorrect-space-accounting-after-failure-to-insert-inline-extent.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Thu Mar 22 14:40:23 CET 2018 From: Filipe Manana <fdmanana(a)suse.com> Date: Wed, 8 Mar 2017 16:43:49 +0000 Subject: Btrfs: fix incorrect space accounting after failure to insert inline extent From: Filipe Manana <fdmanana(a)suse.com> [ Upstream commit 1c81ba237bcecad9bc885a1ddcf02d725ea38482 ] When using compression, if we fail to insert an inline extent we incorrectly end up attempting to free the reserved data space twice, once through extent_clear_unlock_delalloc(), because we pass it the flag EXTENT_DO_ACCOUNTING, and once through a direct call to btrfs_free_reserved_data_space_noquota(). This results in a trace like the following: [ 834.576240] ------------[ cut here ]------------ [ 834.576825] WARNING: CPU: 2 PID: 486 at fs/btrfs/extent-tree.c:4316 btrfs_free_reserved_data_space_noquota+0x60/0x9f [btrfs] [ 834.579501] Modules linked in: btrfs crc32c_generic xor raid6_pq ppdev i2c_piix4 acpi_cpufreq psmouse tpm_tis parport_pc pcspkr serio_raw tpm_tis_core sg parport evdev i2c_core tpm button loop autofs4 ext4 crc16 jbd2 mbcache sr_mod cdrom sd_mod ata_generic virtio_scsi ata_piix virtio_pci libata virtio_ring virtio scsi_mod e1000 floppy [last unloaded: btrfs] [ 834.592116] CPU: 2 PID: 486 Comm: kworker/u32:4 Not tainted 4.10.0-rc8-btrfs-next-37+ #2 [ 834.593316] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.9.1-0-gb3ef39f-prebuilt.qemu-project.org 04/01/2014 [ 834.595273] Workqueue: btrfs-delalloc btrfs_delalloc_helper [btrfs] [ 834.596103] Call Trace: [ 834.596103] dump_stack+0x67/0x90 [ 834.596103] __warn+0xc2/0xdd [ 834.596103] warn_slowpath_null+0x1d/0x1f [ 834.596103] btrfs_free_reserved_data_space_noquota+0x60/0x9f [btrfs] [ 834.596103] compress_file_range.constprop.42+0x2fa/0x3fc [btrfs] [ 834.596103] ? submit_compressed_extents+0x3a7/0x3a7 [btrfs] [ 834.596103] async_cow_start+0x32/0x4d [btrfs] [ 834.596103] btrfs_scrubparity_helper+0x187/0x3e7 [btrfs] [ 834.596103] btrfs_delalloc_helper+0xe/0x10 [btrfs] [ 834.596103] process_one_work+0x273/0x4e4 [ 834.596103] worker_thread+0x1eb/0x2ca [ 834.596103] ? rescuer_thread+0x2b6/0x2b6 [ 834.596103] kthread+0x100/0x108 [ 834.596103] ? __list_del_entry+0x22/0x22 [ 834.596103] ret_from_fork+0x2e/0x40 [ 834.611656] ---[ end trace 719902fe6bdef08f ]--- So fix this by not calling directly btrfs_free_reserved_data_space_noquota() if an error happened. Signed-off-by: Filipe Manana <fdmanana(a)suse.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- fs/btrfs/inode.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) --- a/fs/btrfs/inode.c +++ b/fs/btrfs/inode.c @@ -567,8 +567,10 @@ cont: PAGE_SET_WRITEBACK | page_error_op | PAGE_END_WRITEBACK); - btrfs_free_reserved_data_space_noquota(inode, start, - end - start + 1); + if (ret == 0) + btrfs_free_reserved_data_space_noquota(inode, + start, + end - start + 1); goto free_pages_out; } } Patches currently in stable-queue which might be from fdmanana(a)suse.com are queue-4.9/btrfs-fix-incorrect-space-accounting-after-failure-to-insert-inline-extent.patch queue-4.9/btrfs-fix-extent-map-leak-during-fallocate-error-path.patch queue-4.9/btrfs-send-fix-file-hole-not-being-preserved-due-to-inline-extent.patch

7 years, 6 months

1
0
0 0

Patch "Btrfs: fix extent map leak during fallocate error path" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled Btrfs: fix extent map leak during fallocate error path to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: btrfs-fix-extent-map-leak-during-fallocate-error-path.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Thu Mar 22 14:40:23 CET 2018 From: Filipe Manana <fdmanana(a)suse.com> Date: Mon, 3 Apr 2017 15:57:17 +0100 Subject: Btrfs: fix extent map leak during fallocate error path From: Filipe Manana <fdmanana(a)suse.com> [ Upstream commit be2d253cc98244765323a7c94cc1ac5cd5a17072 ] If the call to btrfs_qgroup_reserve_data() failed, we were leaking an extent map structure. The failure can happen either due to an -ENOMEM condition or, when quotas are enabled, due to -EDQUOT for example. Signed-off-by: Filipe Manana <fdmanana(a)suse.com> Reviewed-by: David Sterba <dsterba(a)suse.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- fs/btrfs/file.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) --- a/fs/btrfs/file.c +++ b/fs/btrfs/file.c @@ -2817,8 +2817,10 @@ static long btrfs_fallocate(struct file } ret = btrfs_qgroup_reserve_data(inode, cur_offset, last_byte - cur_offset); - if (ret < 0) + if (ret < 0) { + free_extent_map(em); break; + } } else { /* * Do not need to reserve unwritten extent for this Patches currently in stable-queue which might be from fdmanana(a)suse.com are queue-4.9/btrfs-fix-incorrect-space-accounting-after-failure-to-insert-inline-extent.patch queue-4.9/btrfs-fix-extent-map-leak-during-fallocate-error-path.patch queue-4.9/btrfs-send-fix-file-hole-not-being-preserved-due-to-inline-extent.patch

7 years, 6 months

1
0
0 0

Patch "btrfs: fix a bogus warning when converting only data or metadata" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled btrfs: fix a bogus warning when converting only data or metadata to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: btrfs-fix-a-bogus-warning-when-converting-only-data-or-metadata.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Thu Mar 22 14:40:23 CET 2018 From: Adam Borowski <kilobyte(a)angband.pl> Date: Tue, 7 Mar 2017 23:34:44 +0100 Subject: btrfs: fix a bogus warning when converting only data or metadata From: Adam Borowski <kilobyte(a)angband.pl> [ Upstream commit 14506127979a5a3d0c5d9b4cc76ce9d4ec23b717 ] If your filesystem has, eg, data:raid0 metadata:raid1, and you run "btrfs balance -dconvert=raid1", the meta.target field will be uninitialized. That's otherwise ok, as it's unused except for this warning. Thus, let's use the existing set of raid levels for the comparison. As a side effect, non-convert balances will now nag about data>metadata. Signed-off-by: Adam Borowski <kilobyte(a)angband.pl> Reviewed-by: Liu Bo <bo.li.liu(a)oracle.com> Signed-off-by: David Sterba <dsterba(a)suse.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- fs/btrfs/volumes.c | 12 +++++++++--- 1 file changed, 9 insertions(+), 3 deletions(-) --- a/fs/btrfs/volumes.c +++ b/fs/btrfs/volumes.c @@ -3765,6 +3765,7 @@ int btrfs_balance(struct btrfs_balance_c struct btrfs_ioctl_balance_args *bargs) { struct btrfs_fs_info *fs_info = bctl->fs_info; + u64 meta_target, data_target; u64 allowed; int mixed = 0; int ret; @@ -3861,11 +3862,16 @@ int btrfs_balance(struct btrfs_balance_c } } while (read_seqretry(&fs_info->profiles_lock, seq)); - if (btrfs_get_num_tolerated_disk_barrier_failures(bctl->meta.target) < - btrfs_get_num_tolerated_disk_barrier_failures(bctl->data.target)) { + /* if we're not converting, the target field is uninitialized */ + meta_target = (bctl->meta.flags & BTRFS_BALANCE_ARGS_CONVERT) ? + bctl->meta.target : fs_info->avail_metadata_alloc_bits; + data_target = (bctl->data.flags & BTRFS_BALANCE_ARGS_CONVERT) ? + bctl->data.target : fs_info->avail_data_alloc_bits; + if (btrfs_get_num_tolerated_disk_barrier_failures(meta_target) < + btrfs_get_num_tolerated_disk_barrier_failures(data_target)) { btrfs_warn(fs_info, "metadata profile 0x%llx has lower redundancy than data profile 0x%llx", - bctl->meta.target, bctl->data.target); + meta_target, data_target); } if (bctl->sys.flags & BTRFS_BALANCE_ARGS_CONVERT) { Patches currently in stable-queue which might be from kilobyte(a)angband.pl are queue-4.9/btrfs-fix-a-bogus-warning-when-converting-only-data-or-metadata.patch

7 years, 6 months

1
0
0 0

Patch "bonding: handle link transition from FAIL to UP correctly" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled bonding: handle link transition from FAIL to UP correctly to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: bonding-handle-link-transition-from-fail-to-up-correctly.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Thu Mar 22 14:40:23 CET 2018 From: Mahesh Bandewar <maheshb(a)google.com> Date: Tue, 11 Apr 2017 22:36:00 -0700 Subject: bonding: handle link transition from FAIL to UP correctly From: Mahesh Bandewar <maheshb(a)google.com> [ Upstream commit fb9eb899a6dc663e4a2deed9af2ac28f507d0ffb ] When link transitions from LINK_FAIL to LINK_UP, the commit phase is not called. This leads to an erroneous state causing slave-link state to get stuck in "going down" state while its speed and duplex are perfectly fine. This issue is a side-effect of splitting link-set into propose and commit phases introduced by de77ecd4ef02 ("bonding: improve link-status update in mii-monitoring") This patch fixes these issues by calling commit phase whenever link state change is proposed. Fixes: de77ecd4ef02 ("bonding: improve link-status update in mii-monitoring") Signed-off-by: Mahesh Bandewar <maheshb(a)google.com> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/net/bonding/bond_main.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) --- a/drivers/net/bonding/bond_main.c +++ b/drivers/net/bonding/bond_main.c @@ -2067,6 +2067,7 @@ static int bond_miimon_inspect(struct bo (bond->params.downdelay - slave->delay) * bond->params.miimon, slave->dev->name); + commit++; continue; } @@ -2104,7 +2105,7 @@ static int bond_miimon_inspect(struct bo (bond->params.updelay - slave->delay) * bond->params.miimon, slave->dev->name); - + commit++; continue; } Patches currently in stable-queue which might be from maheshb(a)google.com are queue-4.9/bonding-handle-link-transition-from-fail-to-up-correctly.patch

7 years, 6 months

1
0
0 0

Patch "bnx2x: Align RX buffers" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled bnx2x: Align RX buffers to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: bnx2x-align-rx-buffers.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Thu Mar 22 14:40:23 CET 2018 From: Scott Wood <swood(a)redhat.com> Date: Fri, 28 Apr 2017 19:17:41 -0500 Subject: bnx2x: Align RX buffers From: Scott Wood <swood(a)redhat.com> [ Upstream commit 9b70de6d0266888b3743f03802502e43131043c8 ] The bnx2x driver is not providing proper alignment on the receive buffers it passes to build_skb(), causing skb_shared_info to be misaligned. skb_shared_info contains an atomic, and while PPC normally supports unaligned accesses, it does not support unaligned atomics. Aligning the size of rx buffers will ensure that page_frag_alloc() returns aligned addresses. This can be reproduced on PPC by setting the network MTU to 1450 (or other non-multiple-of-4) and then generating sufficient inbound network traffic (one or two large "wget"s usually does it), producing the following oops: Unable to handle kernel paging request for unaligned access at address 0xc00000ffc43af656 Faulting instruction address: 0xc00000000080ef8c Oops: Kernel access of bad area, sig: 7 [#1] SMP NR_CPUS=2048 NUMA PowerNV Modules linked in: vmx_crypto powernv_rng rng_core powernv_op_panel leds_powernv led_class nfsd ip_tables x_tables autofs4 xfs lpfc bnx2x mdio libcrc32c crc_t10dif crct10dif_generic crct10dif_common CPU: 104 PID: 0 Comm: swapper/104 Not tainted 4.11.0-rc8-00088-g4c761da #2 task: c00000ffd4892400 task.stack: c00000ffd4920000 NIP: c00000000080ef8c LR: c00000000080eee8 CTR: c0000000001f8320 REGS: c00000ffffc33710 TRAP: 0600 Not tainted (4.11.0-rc8-00088-g4c761da) MSR: 9000000000009033 <SF,HV,EE,ME,IR,DR,RI,LE> CR: 24082042 XER: 00000000 CFAR: c00000000080eea0 DAR: c00000ffc43af656 DSISR: 00000000 SOFTE: 1 GPR00: c000000000907f64 c00000ffffc33990 c000000000dd3b00 c00000ffcaf22100 GPR04: c00000ffcaf22e00 0000000000000000 0000000000000000 0000000000000000 GPR08: 0000000000b80008 c00000ffc43af636 c00000ffc43af656 0000000000000000 GPR12: c0000000001f6f00 c00000000fe1a000 000000000000049f 000000000000c51f GPR16: 00000000ffffef33 0000000000000000 0000000000008a43 0000000000000001 GPR20: c00000ffc58a90c0 0000000000000000 000000000000dd86 0000000000000000 GPR24: c000007fd0ed10c0 00000000ffffffff 0000000000000158 000000000000014a GPR28: c00000ffc43af010 c00000ffc9144000 c00000ffcaf22e00 c00000ffcaf22100 NIP [c00000000080ef8c] __skb_clone+0xdc/0x140 LR [c00000000080eee8] __skb_clone+0x38/0x140 Call Trace: [c00000ffffc33990] [c00000000080fb74] skb_clone+0x74/0x110 (unreliable) [c00000ffffc339c0] [c000000000907f64] packet_rcv+0x144/0x510 [c00000ffffc33a40] [c000000000827b64] __netif_receive_skb_core+0x5b4/0xd80 [c00000ffffc33b00] [c00000000082b2bc] netif_receive_skb_internal+0x2c/0xc0 [c00000ffffc33b40] [c00000000082c49c] napi_gro_receive+0x11c/0x260 [c00000ffffc33b80] [d000000066483d68] bnx2x_poll+0xcf8/0x17b0 [bnx2x] [c00000ffffc33d00] [c00000000082babc] net_rx_action+0x31c/0x480 [c00000ffffc33e10] [c0000000000d5a44] __do_softirq+0x164/0x3d0 [c00000ffffc33f00] [c0000000000d60a8] irq_exit+0x108/0x120 [c00000ffffc33f20] [c000000000015b98] __do_irq+0x98/0x200 [c00000ffffc33f90] [c000000000027f14] call_do_irq+0x14/0x24 [c00000ffd4923a90] [c000000000015d94] do_IRQ+0x94/0x110 [c00000ffd4923ae0] [c000000000008d90] hardware_interrupt_common+0x150/0x160 Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.c | 1 + 1 file changed, 1 insertion(+) --- a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.c +++ b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.c @@ -2026,6 +2026,7 @@ static void bnx2x_set_rx_buf_size(struct ETH_OVREHEAD + mtu + BNX2X_FW_RX_ALIGN_END; + fp->rx_buf_size = SKB_DATA_ALIGN(fp->rx_buf_size); /* Note : rx_buf_size doesn't take into account NET_SKB_PAD */ if (fp->rx_buf_size + NET_SKB_PAD <= PAGE_SIZE) fp->rx_frag_size = fp->rx_buf_size + NET_SKB_PAD; Patches currently in stable-queue which might be from swood(a)redhat.com are queue-4.9/bnx2x-align-rx-buffers.patch

7 years, 6 months

1
0
0 0

Patch "Bluetooth: hci_qca: Avoid setup failure on missing rampatch" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled Bluetooth: hci_qca: Avoid setup failure on missing rampatch to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: bluetooth-hci_qca-avoid-setup-failure-on-missing-rampatch.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Thu Mar 22 14:40:24 CET 2018 From: Loic Poulain <loic.poulain(a)linaro.org> Date: Mon, 6 Nov 2017 12:16:56 +0100 Subject: Bluetooth: hci_qca: Avoid setup failure on missing rampatch From: Loic Poulain <loic.poulain(a)linaro.org> [ Upstream commit ba8f3597900291a93604643017fff66a14546015 ] Assuming that the original code idea was to enable in-band sleeping only if the setup_rome method returns succes and run in 'standard' mode otherwise, we should not return setup_rome return value which makes qca_setup fail if no rampatch/nvm file found. This fixes BT issue on the dragonboard-820C p4 which includes the following QCA controller: hci0: Product:0x00000008 hci0: Patch :0x00000111 hci0: ROM :0x00000302 hci0: SOC :0x00000044 Since there is no rampatch for this controller revision, just make it work as is. Signed-off-by: Loic Poulain <loic.poulain(a)linaro.org> Signed-off-by: Marcel Holtmann <marcel(a)holtmann.org> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/bluetooth/hci_qca.c | 3 +++ 1 file changed, 3 insertions(+) --- a/drivers/bluetooth/hci_qca.c +++ b/drivers/bluetooth/hci_qca.c @@ -936,6 +936,9 @@ static int qca_setup(struct hci_uart *hu if (!ret) { set_bit(STATE_IN_BAND_SLEEP_ENABLED, &qca->flags); qca_debugfs_init(hdev); + } else if (ret == -ENOENT) { + /* No patch/nvm-config found, run with original fw/config */ + ret = 0; } /* Setup bdaddr */ Patches currently in stable-queue which might be from loic.poulain(a)linaro.org are queue-4.9/bluetooth-btqcomsmd-fix-skb-double-free-corruption.patch queue-4.9/bluetooth-hci_qca-avoid-setup-failure-on-missing-rampatch.patch

7 years, 6 months

1
0
0 0

Patch "Bluetooth: hci_ldisc: Add protocol check to hci_uart_tx_wakeup()" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled Bluetooth: hci_ldisc: Add protocol check to hci_uart_tx_wakeup() to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: bluetooth-hci_ldisc-add-protocol-check-to-hci_uart_tx_wakeup.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Thu Mar 22 14:40:23 CET 2018 From: Dean Jenkins <Dean_Jenkins(a)mentor.com> Date: Fri, 28 Apr 2017 13:57:26 +0100 Subject: Bluetooth: hci_ldisc: Add protocol check to hci_uart_tx_wakeup() From: Dean Jenkins <Dean_Jenkins(a)mentor.com> [ Upstream commit 2d6f1da168e1d62c47f7d50135ac4cbd8411dcb1 ] Before attempting to schedule a work-item onto hu->write_work in hci_uart_tx_wakeup(), check that the Data Link protocol layer is still bound to the HCI UART driver. Failure to perform this protocol check causes a race condition between the work queue hu->write_work running hci_uart_write_work() and the Data Link protocol layer being unbound (closed) in hci_uart_tty_close(). Note hci_uart_tty_close() does have a "cancel_work_sync(&hu->write_work)" but it is ineffective because it cannot prevent work-items being added to hu->write_work after cancel_work_sync() has run. Therefore, add a check for HCI_UART_PROTO_READY into hci_uart_tx_wakeup() which prevents scheduling of the work queue when HCI_UART_PROTO_READY is in the clear state. However, note a small race condition remains because the hci_uart_tx_wakeup() thread can run in parallel with the hci_uart_tty_close() thread so it is possible that a schedule of hu->write_work can occur when HCI_UART_PROTO_READY is cleared. A complete solution needs locking of the threads which is implemented in a future commit. Signed-off-by: Dean Jenkins <Dean_Jenkins(a)mentor.com> Signed-off-by: Marcel Holtmann <marcel(a)holtmann.org> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/bluetooth/hci_ldisc.c | 3 +++ 1 file changed, 3 insertions(+) --- a/drivers/bluetooth/hci_ldisc.c +++ b/drivers/bluetooth/hci_ldisc.c @@ -125,6 +125,9 @@ static inline struct sk_buff *hci_uart_d int hci_uart_tx_wakeup(struct hci_uart *hu) { + if (!test_bit(HCI_UART_PROTO_READY, &hu->flags)) + return 0; + if (test_and_set_bit(HCI_UART_SENDING, &hu->tx_state)) { set_bit(HCI_UART_TX_WAKEUP, &hu->tx_state); return 0; Patches currently in stable-queue which might be from Dean_Jenkins(a)mentor.com are queue-4.9/bluetooth-hci_ldisc-add-protocol-check-to-hci_uart_dequeue.patch queue-4.9/bluetooth-hci_ldisc-add-protocol-check-to-hci_uart_tx_wakeup.patch

7 years, 6 months

1
0
0 0

Patch "Bluetooth: hci_ldisc: Add protocol check to hci_uart_dequeue()" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled Bluetooth: hci_ldisc: Add protocol check to hci_uart_dequeue() to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: bluetooth-hci_ldisc-add-protocol-check-to-hci_uart_dequeue.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Thu Mar 22 14:40:23 CET 2018 From: Dean Jenkins <Dean_Jenkins(a)mentor.com> Date: Fri, 28 Apr 2017 13:57:25 +0100 Subject: Bluetooth: hci_ldisc: Add protocol check to hci_uart_dequeue() From: Dean Jenkins <Dean_Jenkins(a)mentor.com> [ Upstream commit 048e1bd3a27fbeb84ccdff52e165370c1339a193 ] Before attempting to dequeue a Data Link protocol encapsulated message, check that the Data Link protocol is still bound to the HCI UART driver. This makes the code consistent with the usage of the other proto function pointers. Therefore, add a check for HCI_UART_PROTO_READY into hci_uart_dequeue() and return NULL if the Data Link protocol is not bound. This is needed for robustness as there is a scheduling race condition. hci_uart_write_work() is scheduled to run via work queue hu->write_work from hci_uart_tx_wakeup(). Therefore, there is a delay between scheduling hci_uart_write_work() to run and hci_uart_dequeue() running whereby the Data Link protocol layer could become unbound during the scheduling delay. In this case, without the check, the call to the unbound Data Link protocol layer dequeue function can crash. It is noted that hci_uart_tty_close() has a "cancel_work_sync(&hu->write_work)" statement but this only reduces the window of the race condition because it is possible for a new work-item to be added to work queue hu->write_work after the call to cancel_work_sync(). For example, Data Link layer retransmissions can be added to the work queue after the cancel_work_sync() has finished. Signed-off-by: Dean Jenkins <Dean_Jenkins(a)mentor.com> Signed-off-by: Marcel Holtmann <marcel(a)holtmann.org> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/bluetooth/hci_ldisc.c | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-) --- a/drivers/bluetooth/hci_ldisc.c +++ b/drivers/bluetooth/hci_ldisc.c @@ -113,10 +113,12 @@ static inline struct sk_buff *hci_uart_d { struct sk_buff *skb = hu->tx_skb; - if (!skb) - skb = hu->proto->dequeue(hu); - else + if (!skb) { + if (test_bit(HCI_UART_PROTO_READY, &hu->flags)) + skb = hu->proto->dequeue(hu); + } else { hu->tx_skb = NULL; + } return skb; } Patches currently in stable-queue which might be from Dean_Jenkins(a)mentor.com are queue-4.9/bluetooth-hci_ldisc-add-protocol-check-to-hci_uart_dequeue.patch queue-4.9/bluetooth-hci_ldisc-add-protocol-check-to-hci_uart_tx_wakeup.patch

7 years, 6 months

1
0
0 0

Patch "Bluetooth: btqcomsmd: Fix skb double free corruption" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled Bluetooth: btqcomsmd: Fix skb double free corruption to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: bluetooth-btqcomsmd-fix-skb-double-free-corruption.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Thu Mar 22 14:40:24 CET 2018 From: Loic Poulain <loic.poulain(a)linaro.org> Date: Wed, 22 Nov 2017 15:03:17 +0100 Subject: Bluetooth: btqcomsmd: Fix skb double free corruption From: Loic Poulain <loic.poulain(a)linaro.org> [ Upstream commit 67b8fbead4685b36d290a0ef91c6ddffc4920ec9 ] In case of hci send frame failure, skb is still owned by the caller (hci_core) and then should not be freed. This fixes crash on dragonboard-410c when sending SCO packet. skb is freed by both btqcomsmd and hci_core. Fixes: 1511cc750c3d ("Bluetooth: Introduce Qualcomm WCNSS SMD based HCI driver") Signed-off-by: Loic Poulain <loic.poulain(a)linaro.org> Signed-off-by: Marcel Holtmann <marcel(a)holtmann.org> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/bluetooth/btqcomsmd.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) --- a/drivers/bluetooth/btqcomsmd.c +++ b/drivers/bluetooth/btqcomsmd.c @@ -85,7 +85,8 @@ static int btqcomsmd_send(struct hci_dev break; } - kfree_skb(skb); + if (!ret) + kfree_skb(skb); return ret; } Patches currently in stable-queue which might be from loic.poulain(a)linaro.org are queue-4.9/bluetooth-btqcomsmd-fix-skb-double-free-corruption.patch queue-4.9/bluetooth-hci_qca-avoid-setup-failure-on-missing-rampatch.patch

7 years, 6 months

1
0
0 0

Patch "block/mq: Cure cpu hotplug lock inversion" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled block/mq: Cure cpu hotplug lock inversion to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: block-mq-cure-cpu-hotplug-lock-inversion.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Thu Mar 22 14:40:24 CET 2018 From: Peter Zijlstra <peterz(a)infradead.org> Date: Thu, 4 May 2017 15:05:26 +0200 Subject: block/mq: Cure cpu hotplug lock inversion From: Peter Zijlstra <peterz(a)infradead.org> [ Upstream commit eabe06595d62cfa9278e2cd012df614bc68a7042 ] By poking at /debug/sched_features I triggered the following splat: [] ====================================================== [] WARNING: possible circular locking dependency detected [] 4.11.0-00873-g964c8b7-dirty #694 Not tainted [] ------------------------------------------------------ [] bash/2109 is trying to acquire lock: [] (cpu_hotplug_lock.rw_sem){++++++}, at: [<ffffffff8120cb8b>] static_key_slow_dec+0x1b/0x50 [] [] but task is already holding lock: [] (&sb->s_type->i_mutex_key#4){+++++.}, at: [<ffffffff81140216>] sched_feat_write+0x86/0x170 [] [] which lock already depends on the new lock. [] [] [] the existing dependency chain (in reverse order) is: [] [] -> #2 (&sb->s_type->i_mutex_key#4){+++++.}: [] lock_acquire+0x100/0x210 [] down_write+0x28/0x60 [] start_creating+0x5e/0xf0 [] debugfs_create_dir+0x13/0x110 [] blk_mq_debugfs_register+0x21/0x70 [] blk_mq_register_dev+0x64/0xd0 [] blk_register_queue+0x6a/0x170 [] device_add_disk+0x22d/0x440 [] loop_add+0x1f3/0x280 [] loop_init+0x104/0x142 [] do_one_initcall+0x43/0x180 [] kernel_init_freeable+0x1de/0x266 [] kernel_init+0xe/0x100 [] ret_from_fork+0x31/0x40 [] [] -> #1 (all_q_mutex){+.+.+.}: [] lock_acquire+0x100/0x210 [] __mutex_lock+0x6c/0x960 [] mutex_lock_nested+0x1b/0x20 [] blk_mq_init_allocated_queue+0x37c/0x4e0 [] blk_mq_init_queue+0x3a/0x60 [] loop_add+0xe5/0x280 [] loop_init+0x104/0x142 [] do_one_initcall+0x43/0x180 [] kernel_init_freeable+0x1de/0x266 [] kernel_init+0xe/0x100 [] ret_from_fork+0x31/0x40 [] *** DEADLOCK *** [] [] 3 locks held by bash/2109: [] #0: (sb_writers#11){.+.+.+}, at: [<ffffffff81292bcd>] vfs_write+0x17d/0x1a0 [] #1: (debugfs_srcu){......}, at: [<ffffffff8155a90d>] full_proxy_write+0x5d/0xd0 [] #2: (&sb->s_type->i_mutex_key#4){+++++.}, at: [<ffffffff81140216>] sched_feat_write+0x86/0x170 [] [] stack backtrace: [] CPU: 9 PID: 2109 Comm: bash Not tainted 4.11.0-00873-g964c8b7-dirty #694 [] Hardware name: Intel Corporation S2600GZ/S2600GZ, BIOS SE5C600.86B.02.02.0002.122320131210 12/23/2013 [] Call Trace: [] lock_acquire+0x100/0x210 [] get_online_cpus+0x2a/0x90 [] static_key_slow_dec+0x1b/0x50 [] static_key_disable+0x20/0x30 [] sched_feat_write+0x131/0x170 [] full_proxy_write+0x97/0xd0 [] __vfs_write+0x28/0x120 [] vfs_write+0xb5/0x1a0 [] SyS_write+0x49/0xa0 [] entry_SYSCALL_64_fastpath+0x23/0xc2 This is because of the cpu hotplug lock rework. Break the chain at #1 by reversing the lock acquisition order. This way i_mutex_key#4 no longer depends on cpu_hotplug_lock and things are good. Cc: Jens Axboe <axboe(a)kernel.dk> Signed-off-by: Peter Zijlstra (Intel) <peterz(a)infradead.org> Signed-off-by: Jens Axboe <axboe(a)fb.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- block/blk-mq.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) --- a/block/blk-mq.c +++ b/block/blk-mq.c @@ -2014,15 +2014,15 @@ struct request_queue *blk_mq_init_alloca blk_mq_init_cpu_queues(q, set->nr_hw_queues); - get_online_cpus(); mutex_lock(&all_q_mutex); + get_online_cpus(); list_add_tail(&q->all_q_node, &all_q_list); blk_mq_add_queue_tag_set(set, q); blk_mq_map_swqueue(q, cpu_online_mask); - mutex_unlock(&all_q_mutex); put_online_cpus(); + mutex_unlock(&all_q_mutex); return q; Patches currently in stable-queue which might be from peterz(a)infradead.org are queue-4.9/acpi-processor-fix-error-handling-in-__acpi_processor_start.patch queue-4.9/x86-reboot-turn-off-kvm-when-halting-a-cpu.patch queue-4.9/block-mq-cure-cpu-hotplug-lock-inversion.patch queue-4.9/acpi-processor-replace-racy-task-affinity-logic.patch queue-4.9/perf-tests-kmod-path-don-t-fail-if-compressed-modules-aren-t-supported.patch queue-4.9/cpufreq-sh-replace-racy-task-affinity-logic.patch queue-4.9/x86-kaslr-fix-kexec-kernel-boot-crash-when-kaslr-randomization-fails.patch

7 years, 6 months

1
0
0 0

Patch "ath10k: handling qos at STA side based on AP WMM enable/disable" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled ath10k: handling qos at STA side based on AP WMM enable/disable to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: ath10k-handling-qos-at-sta-side-based-on-ap-wmm-enable-disable.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Thu Mar 22 14:40:24 CET 2018 From: Balaji Pothunoori <bpothuno(a)qti.qualcomm.com> Date: Thu, 7 Dec 2017 16:58:04 +0200 Subject: ath10k: handling qos at STA side based on AP WMM enable/disable From: Balaji Pothunoori <bpothuno(a)qti.qualcomm.com> [ Upstream commit 07ffb4497360ae8789f05555fec8171ee952304d ] Data packets are not sent by STA in case of STA joined to non QOS AP (WMM disabled AP). This is happening because of STA is sending data packets to firmware from host with qos enabled along with non qos queue value(TID = 16). Due to qos enabled, firmware is discarding the packet. This patch fixes this issue by updating the qos based on station WME capability field if WMM is disabled in AP. This patch is required by 10.4 family chipsets like QCA4019/QCA9888/QCA9884/QCA99X0. Firmware Versoin : 10.4-3.5.1-00018. For 10.2.4 family chipsets QCA988X/QCA9887 and QCA6174 this patch has no effect. Signed-off-by: Balaji Pothunoori <bpothuno(a)qti.qualcomm.com> Signed-off-by: Kalle Valo <kvalo(a)qca.qualcomm.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/net/wireless/ath/ath10k/mac.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/drivers/net/wireless/ath/ath10k/mac.c +++ b/drivers/net/wireless/ath/ath10k/mac.c @@ -2505,7 +2505,7 @@ static void ath10k_peer_assoc_h_qos(stru } break; case WMI_VDEV_TYPE_STA: - if (vif->bss_conf.qos) + if (sta->wme) arg->peer_flags |= arvif->ar->wmi.peer_flags->qos; break; case WMI_VDEV_TYPE_IBSS: Patches currently in stable-queue which might be from bpothuno(a)qti.qualcomm.com are queue-4.9/ath10k-handling-qos-at-sta-side-based-on-ap-wmm-enable-disable.patch

7 years, 6 months

1
0
0 0

Patch "ath10k: fix out of bounds access to local buffer" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled ath10k: fix out of bounds access to local buffer to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: ath10k-fix-out-of-bounds-access-to-local-buffer.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Thu Mar 22 14:40:24 CET 2018 From: Michael Mera <dev(a)michaelmera.com> Date: Mon, 24 Apr 2017 16:11:57 +0900 Subject: ath10k: fix out of bounds access to local buffer From: Michael Mera <dev(a)michaelmera.com> [ Upstream commit a16703aaeaedec7a8bee5be5522c7c3e75478951 ] During write to debugfs file simulate_fw_crash, fixed-size local buffer 'buf' is accessed and modified at index 'count-1', where 'count' is the size of the write (so potentially out of bounds). This patch fixes this problem. Signed-off-by: Michael Mera <dev(a)michaelmera.com> Signed-off-by: Kalle Valo <kvalo(a)qca.qualcomm.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/net/wireless/ath/ath10k/debug.c | 16 ++++++++++------ 1 file changed, 10 insertions(+), 6 deletions(-) --- a/drivers/net/wireless/ath/ath10k/debug.c +++ b/drivers/net/wireless/ath/ath10k/debug.c @@ -624,17 +624,21 @@ static ssize_t ath10k_write_simulate_fw_ size_t count, loff_t *ppos) { struct ath10k *ar = file->private_data; - char buf[32]; + char buf[32] = {0}; + ssize_t rc; int ret; - simple_write_to_buffer(buf, sizeof(buf) - 1, ppos, user_buf, count); + /* filter partial writes and invalid commands */ + if (*ppos != 0 || count >= sizeof(buf) || count == 0) + return -EINVAL; - /* make sure that buf is null terminated */ - buf[sizeof(buf) - 1] = 0; + rc = simple_write_to_buffer(buf, sizeof(buf) - 1, ppos, user_buf, count); + if (rc < 0) + return rc; /* drop the possible '\n' from the end */ - if (buf[count - 1] == '\n') - buf[count - 1] = 0; + if (buf[*ppos - 1] == '\n') + buf[*ppos - 1] = '\0'; mutex_lock(&ar->conf_mutex); Patches currently in stable-queue which might be from dev(a)michaelmera.com are queue-4.9/ath10k-fix-out-of-bounds-access-to-local-buffer.patch

7 years, 6 months

1
0
0 0

Patch "ath: Fix updating radar flags for coutry code India" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled ath: Fix updating radar flags for coutry code India to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: ath-fix-updating-radar-flags-for-coutry-code-india.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Thu Mar 22 14:40:23 CET 2018 From: Mohammed Shafi Shajakhan <mohammed(a)qti.qualcomm.com> Date: Wed, 12 Apr 2017 23:19:37 +0530 Subject: ath: Fix updating radar flags for coutry code India From: Mohammed Shafi Shajakhan <mohammed(a)qti.qualcomm.com> [ Upstream commit c0c345d4cacc6a1f39d4856f37dcf6e34f51a5e4 ] As per latest regulatory update for India, channel 52, 56, 60, 64 is no longer restricted to DFS. Enabling DFS/no infra flags in driver results in applying all DFS related restrictions (like doing CAC etc before this channel moves to 'available state') for these channels even though the country code is programmed as 'India' in he hardware, fix this by relaxing the frequency range while applying RADAR flags only if the country code is programmed to India. If the frequency range needs to modified based on different country code, ath_is_radar_freq can be extended/modified dynamically. Signed-off-by: Mohammed Shafi Shajakhan <mohammed(a)qti.qualcomm.com> Signed-off-by: Kalle Valo <kvalo(a)qca.qualcomm.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/net/wireless/ath/regd.c | 19 ++++++++++++------- 1 file changed, 12 insertions(+), 7 deletions(-) --- a/drivers/net/wireless/ath/regd.c +++ b/drivers/net/wireless/ath/regd.c @@ -254,8 +254,12 @@ bool ath_is_49ghz_allowed(u16 regdomain) EXPORT_SYMBOL(ath_is_49ghz_allowed); /* Frequency is one where radar detection is required */ -static bool ath_is_radar_freq(u16 center_freq) +static bool ath_is_radar_freq(u16 center_freq, + struct ath_regulatory *reg) + { + if (reg->country_code == CTRY_INDIA) + return (center_freq >= 5500 && center_freq <= 5700); return (center_freq >= 5260 && center_freq <= 5700); } @@ -306,7 +310,7 @@ __ath_reg_apply_beaconing_flags(struct w enum nl80211_reg_initiator initiator, struct ieee80211_channel *ch) { - if (ath_is_radar_freq(ch->center_freq) || + if (ath_is_radar_freq(ch->center_freq, reg) || (ch->flags & IEEE80211_CHAN_RADAR)) return; @@ -395,8 +399,9 @@ ath_reg_apply_ir_flags(struct wiphy *wip } } -/* Always apply Radar/DFS rules on freq range 5260 MHz - 5700 MHz */ -static void ath_reg_apply_radar_flags(struct wiphy *wiphy) +/* Always apply Radar/DFS rules on freq range 5500 MHz - 5700 MHz */ +static void ath_reg_apply_radar_flags(struct wiphy *wiphy, + struct ath_regulatory *reg) { struct ieee80211_supported_band *sband; struct ieee80211_channel *ch; @@ -409,7 +414,7 @@ static void ath_reg_apply_radar_flags(st for (i = 0; i < sband->n_channels; i++) { ch = &sband->channels[i]; - if (!ath_is_radar_freq(ch->center_freq)) + if (!ath_is_radar_freq(ch->center_freq, reg)) continue; /* We always enable radar detection/DFS on this * frequency range. Additionally we also apply on @@ -505,7 +510,7 @@ void ath_reg_notifier_apply(struct wiphy struct ath_common *common = container_of(reg, struct ath_common, regulatory); /* We always apply this */ - ath_reg_apply_radar_flags(wiphy); + ath_reg_apply_radar_flags(wiphy, reg); /* * This would happen when we have sent a custom regulatory request @@ -653,7 +658,7 @@ ath_regd_init_wiphy(struct ath_regulator } wiphy_apply_custom_regulatory(wiphy, regd); - ath_reg_apply_radar_flags(wiphy); + ath_reg_apply_radar_flags(wiphy, reg); ath_reg_apply_world_flags(wiphy, NL80211_REGDOM_SET_BY_DRIVER, reg); return 0; } Patches currently in stable-queue which might be from mohammed(a)qti.qualcomm.com are queue-4.9/mac80211-fix-possible-sband-related-null-pointer-de-reference.patch queue-4.9/ath-fix-updating-radar-flags-for-coutry-code-india.patch

7 years, 6 months

1
0
0 0

Patch "ASoC: Intel: Skylake: Uninitialized variable in probe_codec()" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled ASoC: Intel: Skylake: Uninitialized variable in probe_codec() to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: asoc-intel-skylake-uninitialized-variable-in-probe_codec.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Thu Mar 22 14:40:23 CET 2018 From: Dan Carpenter <dan.carpenter(a)oracle.com> Date: Thu, 20 Apr 2017 13:17:02 +0300 Subject: ASoC: Intel: Skylake: Uninitialized variable in probe_codec() From: Dan Carpenter <dan.carpenter(a)oracle.com> [ Upstream commit e6a33532affd14c12688c0e9b2e773e8b2550f3b ] My static checker complains that if snd_hdac_bus_get_response() returns -EIO then "res" is uninitialized. Fix this by initializing it to -1 so that the error is handled correctly. Fixes: d8c2dab8381d ("ASoC: Intel: Add Skylake HDA audio driver") Signed-off-by: Dan Carpenter <dan.carpenter(a)oracle.com> Signed-off-by: Mark Brown <broonie(a)kernel.org> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- sound/soc/intel/skylake/skl.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/sound/soc/intel/skylake/skl.c +++ b/sound/soc/intel/skylake/skl.c @@ -457,7 +457,7 @@ static int probe_codec(struct hdac_ext_b struct hdac_bus *bus = ebus_to_hbus(ebus); unsigned int cmd = (addr << 28) | (AC_NODE_ROOT << 20) | (AC_VERB_PARAMETERS << 8) | AC_PAR_VENDOR_ID; - unsigned int res; + unsigned int res = -1; mutex_lock(&bus->cmd_mutex); snd_hdac_bus_send_cmd(bus, cmd); Patches currently in stable-queue which might be from dan.carpenter(a)oracle.com are queue-4.9/netfilter-x_tables-unlock-on-error-in-xt_find_table_lock.patch queue-4.9/asoc-intel-skylake-uninitialized-variable-in-probe_codec.patch queue-4.9/mmc-host-omap_hsmmc-checking-for-null-instead-of-is_err.patch queue-4.9/qed-unlock-on-error-in-qed_vf_pf_acquire.patch queue-4.9/hsi-ssi_protocol-double-free-in-ssip_pn_xmit.patch queue-4.9/cifs-small-underflow-in-cnvrtdosunixtm.patch queue-4.9/ib-rdmavt-restore-irqs-on-error-path-in-rvt_create_ah.patch

7 years, 6 months

1
0
0 0

Patch "ASoC: Intel: Atom: update Thinkpad 10 quirk" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled ASoC: Intel: Atom: update Thinkpad 10 quirk to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: asoc-intel-atom-update-thinkpad-10-quirk.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Thu Mar 22 14:40:23 CET 2018 From: Pierre-Louis Bossart <pierre-louis.bossart(a)linux.intel.com> Date: Mon, 17 Apr 2017 10:04:07 -0500 Subject: ASoC: Intel: Atom: update Thinkpad 10 quirk From: Pierre-Louis Bossart <pierre-louis.bossart(a)linux.intel.com> [ Upstream commit beb5989a8c6c6867b4e873cca2a66d31f977368f ] There are multiple skews of the same Lenovo audio hardware based on the Realtek RT5670 codec. Manufacturer: LENOVO Product Name: 20C1CTO1WW Version: ThinkPad 10 Manufacturer: LENOVO Product Name: 20C3001VHH Version: ThinkPad 10 Manufacturer: LENOVO Product Name: 20C10024GE Version: ThinkPad Tablet B Manufacturer: LENOVO Product Name: 20359 Version: Lenovo Miix 2 10 For all these devices, the same quirk is used to force the machine driver to be based on RT5670 instead of RT5640 as indicated by the BIOS. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=96691 Tested-by: Nicole Faerber <nicole.faerber(a)dpin.de> Tested-by: Viacheslav Ostroukh <v.dev(a)ostroukh.me> Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart(a)linux.intel.com> Signed-off-by: Mark Brown <broonie(a)kernel.org> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- sound/soc/intel/atom/sst/sst_acpi.c | 16 +++++++++++++++- 1 file changed, 15 insertions(+), 1 deletion(-) --- a/sound/soc/intel/atom/sst/sst_acpi.c +++ b/sound/soc/intel/atom/sst/sst_acpi.c @@ -420,7 +420,21 @@ static const struct dmi_system_id byt_ta .callback = byt_thinkpad10_quirk_cb, .matches = { DMI_MATCH(DMI_SYS_VENDOR, "LENOVO"), - DMI_MATCH(DMI_PRODUCT_NAME, "20C3001VHH"), + DMI_MATCH(DMI_PRODUCT_VERSION, "ThinkPad 10"), + }, + }, + { + .callback = byt_thinkpad10_quirk_cb, + .matches = { + DMI_MATCH(DMI_SYS_VENDOR, "LENOVO"), + DMI_MATCH(DMI_PRODUCT_VERSION, "ThinkPad Tablet B"), + }, + }, + { + .callback = byt_thinkpad10_quirk_cb, + .matches = { + DMI_MATCH(DMI_SYS_VENDOR, "LENOVO"), + DMI_MATCH(DMI_PRODUCT_VERSION, "Lenovo Miix 2 10"), }, }, { } Patches currently in stable-queue which might be from pierre-louis.bossart(a)linux.intel.com are queue-4.9/asoc-intel-atom-update-thinkpad-10-quirk.patch

7 years, 6 months

1
0
0 0

Patch "ARM: dts: aspeed-evb: Add unit name to memory node" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled ARM: dts: aspeed-evb: Add unit name to memory node to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: arm-dts-aspeed-evb-add-unit-name-to-memory-node.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Thu Mar 22 14:40:24 CET 2018 From: Joel Stanley <joel(a)jms.id.au> Date: Mon, 18 Dec 2017 23:27:03 +1030 Subject: ARM: dts: aspeed-evb: Add unit name to memory node From: Joel Stanley <joel(a)jms.id.au> [ Upstream commit e40ed274489a5f516da120186578eb379b452ac6 ] Fixes a warning when building with W=1. All of the ASPEED device trees build without warnings now. Signed-off-by: Joel Stanley <joel(a)jms.id.au> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/arm/boot/dts/aspeed-ast2500-evb.dts | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/arch/arm/boot/dts/aspeed-ast2500-evb.dts +++ b/arch/arm/boot/dts/aspeed-ast2500-evb.dts @@ -15,7 +15,7 @@ bootargs = "console=ttyS4,115200 earlyprintk"; }; - memory { + memory@80000000 { reg = <0x80000000 0x20000000>; }; }; Patches currently in stable-queue which might be from joel(a)jms.id.au are queue-4.9/arm-dts-aspeed-evb-add-unit-name-to-memory-node.patch

7 years, 6 months

1
0
0 0

Patch "ARM: DRA7: clockdomain: Change the CLKTRCTRL of CM_PCIE_CLKSTCTRL to SW_WKUP" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled ARM: DRA7: clockdomain: Change the CLKTRCTRL of CM_PCIE_CLKSTCTRL to SW_WKUP to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: arm-dra7-clockdomain-change-the-clktrctrl-of-cm_pcie_clkstctrl-to-sw_wkup.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Thu Mar 22 14:40:23 CET 2018 From: Kishon Vijay Abraham I <kishon(a)ti.com> Date: Mon, 27 Mar 2017 15:15:20 +0530 Subject: ARM: DRA7: clockdomain: Change the CLKTRCTRL of CM_PCIE_CLKSTCTRL to SW_WKUP From: Kishon Vijay Abraham I <kishon(a)ti.com> [ Upstream commit 2c949ce38f4e81d7487f165fa3b8f77d74a2a6c4 ] The PCIe programming sequence in TRM suggests CLKSTCTRL of PCIe should be set to SW_WKUP. There are no issues when CLKSTCTRL is set to HW_AUTO in RC mode. However in EP mode, the host system is not able to access the MEMSPACE and setting the CLKSTCTRL to SW_WKUP fixes it. Acked-by: Tony Lindgren <tony(a)atomide.com> Signed-off-by: Kishon Vijay Abraham I <kishon(a)ti.com> Signed-off-by: Bjorn Helgaas <bhelgaas(a)google.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/arm/mach-omap2/clockdomains7xx_data.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/arch/arm/mach-omap2/clockdomains7xx_data.c +++ b/arch/arm/mach-omap2/clockdomains7xx_data.c @@ -524,7 +524,7 @@ static struct clockdomain pcie_7xx_clkdm .dep_bit = DRA7XX_PCIE_STATDEP_SHIFT, .wkdep_srcs = pcie_wkup_sleep_deps, .sleepdep_srcs = pcie_wkup_sleep_deps, - .flags = CLKDM_CAN_HWSUP_SWSUP, + .flags = CLKDM_CAN_SWSUP, }; static struct clockdomain atl_7xx_clkdm = { Patches currently in stable-queue which might be from kishon(a)ti.com are queue-4.9/arm-dra7-clockdomain-change-the-clktrctrl-of-cm_pcie_clkstctrl-to-sw_wkup.patch queue-4.9/mmc-host-omap_hsmmc-checking-for-null-instead-of-is_err.patch

7 years, 6 months

1
0
0 0

Patch "ARM: 8668/1: ftrace: Fix dynamic ftrace with DEBUG_RODATA and !FRAME_POINTER" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled ARM: 8668/1: ftrace: Fix dynamic ftrace with DEBUG_RODATA and !FRAME_POINTER to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: arm-8668-1-ftrace-fix-dynamic-ftrace-with-debug_rodata-and-frame_pointer.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Thu Mar 22 14:40:23 CET 2018 From: Abel Vesa <abelvesa(a)linux.com> Date: Mon, 3 Apr 2017 23:58:54 +0100 Subject: ARM: 8668/1: ftrace: Fix dynamic ftrace with DEBUG_RODATA and !FRAME_POINTER From: Abel Vesa <abelvesa(a)linux.com> [ Upstream commit 6f05d0761af612e04572ba4d65b4c0274a88444f ] The support for dynamic ftrace with CONFIG_DEBUG_RODATA involves overriding the weak arch_ftrace_update_code() with a variant which makes the kernel text writable around the patching. This override was however added under the CONFIG_OLD_MCOUNT ifdef, and CONFIG_OLD_MCOUNT is only enabled if frame pointers are enabled. This leads to non-functional dynamic ftrace (ftrace triggers a WARN_ON()) when CONFIG_DEBUG_RODATA is enabled and CONFIG_FRAME_POINTER is not. Move the override out of that ifdef and into the CONFIG_DYNAMIC_FTRACE ifdef where it belongs. Fixes: 80d6b0c2eed2a ("ARM: mm: allow text and rodata sections to be read-only") Suggested-by: Nicolai Stange <nicstange(a)gmail.com> Suggested-by: Rabin Vincent <rabin(a)rab.in> Signed-off-by: Abel Vesa <abelvesa(a)gmail.com> Acked-by: Rabin Vincent <rabin(a)rab.in> Signed-off-by: Russell King <rmk+kernel(a)armlinux.org.uk> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/arm/kernel/ftrace.c | 11 ++++++----- 1 file changed, 6 insertions(+), 5 deletions(-) --- a/arch/arm/kernel/ftrace.c +++ b/arch/arm/kernel/ftrace.c @@ -29,11 +29,6 @@ #endif #ifdef CONFIG_DYNAMIC_FTRACE -#ifdef CONFIG_OLD_MCOUNT -#define OLD_MCOUNT_ADDR ((unsigned long) mcount) -#define OLD_FTRACE_ADDR ((unsigned long) ftrace_caller_old) - -#define OLD_NOP 0xe1a00000 /* mov r0, r0 */ static int __ftrace_modify_code(void *data) { @@ -51,6 +46,12 @@ void arch_ftrace_update_code(int command stop_machine(__ftrace_modify_code, &command, NULL); } +#ifdef CONFIG_OLD_MCOUNT +#define OLD_MCOUNT_ADDR ((unsigned long) mcount) +#define OLD_FTRACE_ADDR ((unsigned long) ftrace_caller_old) + +#define OLD_NOP 0xe1a00000 /* mov r0, r0 */ + static unsigned long ftrace_nop_replace(struct dyn_ftrace *rec) { return rec->arch.old_mcount ? OLD_NOP : NOP; Patches currently in stable-queue which might be from abelvesa(a)linux.com are queue-4.9/arm-8668-1-ftrace-fix-dynamic-ftrace-with-debug_rodata-and-frame_pointer.patch

7 years, 6 months

1
0
0 0

Patch "ALSA: hda - Fix headset microphone detection for ASUS N551 and N751" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled ALSA: hda - Fix headset microphone detection for ASUS N551 and N751 to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: alsa-hda-fix-headset-microphone-detection-for-asus-n551-and-n751.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Thu Mar 22 14:40:23 CET 2018 From: Mikhail Paulyshka <me(a)mixaill.tk> Date: Fri, 21 Apr 2017 08:52:42 +0200 Subject: ALSA: hda - Fix headset microphone detection for ASUS N551 and N751 From: Mikhail Paulyshka <me(a)mixaill.tk> [ Upstream commit fc7438b1eb12b6c93d7b7a62423779eb5dfc673c ] Headset microphone does not work out of the box on ASUS Nx51 laptops. This patch fixes it. Patch tested on Asus N551 laptop. Asus N751 part is not tested, but according to [1] this laptop uses the same audiosystem. 1. https://bugzilla.kernel.org/show_bug.cgi?id=117781 Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=195437 Signed-off-by: Mikhail Paulyshka <me(a)mixaill.tk> Signed-off-by: Takashi Iwai <tiwai(a)suse.de> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- sound/pci/hda/patch_realtek.c | 12 ++++++++++-- 1 file changed, 10 insertions(+), 2 deletions(-) --- a/sound/pci/hda/patch_realtek.c +++ b/sound/pci/hda/patch_realtek.c @@ -6780,6 +6780,7 @@ enum { ALC668_FIXUP_DELL_DISABLE_AAMIX, ALC668_FIXUP_DELL_XPS13, ALC662_FIXUP_ASUS_Nx50, + ALC668_FIXUP_ASUS_Nx51_HEADSET_MODE, ALC668_FIXUP_ASUS_Nx51, ALC891_FIXUP_HEADSET_MODE, ALC891_FIXUP_DELL_MIC_NO_PRESENCE, @@ -7031,14 +7032,21 @@ static const struct hda_fixup alc662_fix .chained = true, .chain_id = ALC662_FIXUP_BASS_1A }, + [ALC668_FIXUP_ASUS_Nx51_HEADSET_MODE] = { + .type = HDA_FIXUP_FUNC, + .v.func = alc_fixup_headset_mode_alc668, + .chain_id = ALC662_FIXUP_BASS_CHMAP + }, [ALC668_FIXUP_ASUS_Nx51] = { .type = HDA_FIXUP_PINS, .v.pins = (const struct hda_pintbl[]) { - {0x1a, 0x90170151}, /* bass speaker */ + { 0x19, 0x03a1913d }, /* use as headphone mic, without its own jack detect */ + { 0x1a, 0x90170151 }, /* bass speaker */ + { 0x1b, 0x03a1113c }, /* use as headset mic, without its own jack detect */ {} }, .chained = true, - .chain_id = ALC662_FIXUP_BASS_CHMAP, + .chain_id = ALC668_FIXUP_ASUS_Nx51_HEADSET_MODE, }, [ALC891_FIXUP_HEADSET_MODE] = { .type = HDA_FIXUP_FUNC, Patches currently in stable-queue which might be from me(a)mixaill.tk are queue-4.9/alsa-hda-fix-headset-microphone-detection-for-asus-n551-and-n751.patch

7 years, 6 months

1
0
0 0

Patch "ACPICA: iasl: Fix IORT SMMU GSI disassembling" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled ACPICA: iasl: Fix IORT SMMU GSI disassembling to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: acpica-iasl-fix-iort-smmu-gsi-disassembling.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Thu Mar 22 14:40:23 CET 2018 From: Lv Zheng <lv.zheng(a)intel.com> Date: Wed, 26 Apr 2017 16:18:49 +0800 Subject: ACPICA: iasl: Fix IORT SMMU GSI disassembling From: Lv Zheng <lv.zheng(a)intel.com> [ Upstream commit bb1e23e66e6237ff7a1824b37366540a89149c33 ] ACPICA commit 637b88de24a78c20478728d9d66632b06fcaa5bf If the IORT template is compiled and then iort.aml binary disassembled to iort.dsl, SMMUv1 node lists incorrect offset for SMMU_Nsg_cfg_irpt Interrupt: [0ECh 0236 8] SMMU_Nsg_irpt Interrupt : 0000000000000000 [0ECh 0236 8] SMMU_Nsg_cfg_irpt Interrupt : 0000000000000000 This is because iasl hasn't implemented SMMU GSI decoding yet. This patch fixes this issue by preparing structures for decoding IORT SMMU GSI. ACPICA BZ 1340, reported by Alexei Fedorov, fixed by Lv Zheng. Link: https://github.com/acpica/acpica/commit/637b88de Link: https://bugs.acpica.org/show_bug.cgi?id=1340 Reported-by: Alexei Fedorov <Alexei.Fedorov(a)arm.com> Signed-off-by: Lv Zheng <lv.zheng(a)intel.com> Signed-off-by: Bob Moore <robert.moore(a)intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki(a)intel.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- include/acpi/actbl2.h | 9 +++++++++ 1 file changed, 9 insertions(+) --- a/include/acpi/actbl2.h +++ b/include/acpi/actbl2.h @@ -783,6 +783,15 @@ struct acpi_iort_smmu { #define ACPI_IORT_SMMU_DVM_SUPPORTED (1) #define ACPI_IORT_SMMU_COHERENT_WALK (1<<1) +/* Global interrupt format */ + +struct acpi_iort_smmu_gsi { + u32 nsg_irpt; + u32 nsg_irpt_flags; + u32 nsg_cfg_irpt; + u32 nsg_cfg_irpt_flags; +}; + struct acpi_iort_smmu_v3 { u64 base_address; /* SMMUv3 base address */ u32 flags; Patches currently in stable-queue which might be from lv.zheng(a)intel.com are queue-4.9/acpica-iasl-fix-iort-smmu-gsi-disassembling.patch

7 years, 6 months

1
0
0 0

Patch "ACPI/processor: Replace racy task affinity logic" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled ACPI/processor: Replace racy task affinity logic to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: acpi-processor-replace-racy-task-affinity-logic.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Thu Mar 22 14:40:23 CET 2018 From: Thomas Gleixner <tglx(a)linutronix.de> Date: Wed, 12 Apr 2017 22:07:34 +0200 Subject: ACPI/processor: Replace racy task affinity logic From: Thomas Gleixner <tglx(a)linutronix.de> [ Upstream commit 8153f9ac43897f9f4786b30badc134fcc1a4fb11 ] acpi_processor_get_throttling() requires to invoke the getter function on the target CPU. This is achieved by temporarily setting the affinity of the calling user space thread to the requested CPU and reset it to the original affinity afterwards. That's racy vs. CPU hotplug and concurrent affinity settings for that thread resulting in code executing on the wrong CPU and overwriting the new affinity setting. acpi_processor_get_throttling() is invoked in two ways: 1) The CPU online callback, which is already running on the target CPU and obviously protected against hotplug and not affected by affinity settings. 2) The ACPI driver probe function, which is not protected against hotplug during modprobe. Switch it over to work_on_cpu() and protect the probe function against CPU hotplug. Signed-off-by: Thomas Gleixner <tglx(a)linutronix.de> Cc: Fenghua Yu <fenghua.yu(a)intel.com> Cc: Tony Luck <tony.luck(a)intel.com> Cc: Herbert Xu <herbert(a)gondor.apana.org.au> Cc: "Rafael J. Wysocki" <rjw(a)rjwysocki.net> Cc: Peter Zijlstra <peterz(a)infradead.org> Cc: Benjamin Herrenschmidt <benh(a)kernel.crashing.org> Cc: Sebastian Siewior <bigeasy(a)linutronix.de> Cc: Lai Jiangshan <jiangshanlai(a)gmail.com> Cc: linux-acpi(a)vger.kernel.org Cc: Viresh Kumar <viresh.kumar(a)linaro.org> Cc: Michael Ellerman <mpe(a)ellerman.id.au> Cc: Tejun Heo <tj(a)kernel.org> Cc: "David S. Miller" <davem(a)davemloft.net> Cc: Len Brown <lenb(a)kernel.org> Link: http://lkml.kernel.org/r/20170412201042.785920903@linutronix.de Signed-off-by: Thomas Gleixner <tglx(a)linutronix.de> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/acpi/processor_driver.c | 7 +++- drivers/acpi/processor_throttling.c | 62 ++++++++++++++++++++---------------- 2 files changed, 42 insertions(+), 27 deletions(-) --- a/drivers/acpi/processor_driver.c +++ b/drivers/acpi/processor_driver.c @@ -262,11 +262,16 @@ err_power_exit: static int acpi_processor_start(struct device *dev) { struct acpi_device *device = ACPI_COMPANION(dev); + int ret; if (!device) return -ENODEV; - return __acpi_processor_start(device); + /* Protect against concurrent CPU hotplug operations */ + get_online_cpus(); + ret = __acpi_processor_start(device); + put_online_cpus(); + return ret; } static int acpi_processor_stop(struct device *dev) --- a/drivers/acpi/processor_throttling.c +++ b/drivers/acpi/processor_throttling.c @@ -62,8 +62,8 @@ struct acpi_processor_throttling_arg { #define THROTTLING_POSTCHANGE (2) static int acpi_processor_get_throttling(struct acpi_processor *pr); -int acpi_processor_set_throttling(struct acpi_processor *pr, - int state, bool force); +static int __acpi_processor_set_throttling(struct acpi_processor *pr, + int state, bool force, bool direct); static int acpi_processor_update_tsd_coord(void) { @@ -891,7 +891,8 @@ static int acpi_processor_get_throttling ACPI_DEBUG_PRINT((ACPI_DB_INFO, "Invalid throttling state, reset\n")); state = 0; - ret = acpi_processor_set_throttling(pr, state, true); + ret = __acpi_processor_set_throttling(pr, state, true, + true); if (ret) return ret; } @@ -901,36 +902,31 @@ static int acpi_processor_get_throttling return 0; } -static int acpi_processor_get_throttling(struct acpi_processor *pr) +static long __acpi_processor_get_throttling(void *data) { - cpumask_var_t saved_mask; - int ret; + struct acpi_processor *pr = data; + + return pr->throttling.acpi_processor_get_throttling(pr); +} +static int acpi_processor_get_throttling(struct acpi_processor *pr) +{ if (!pr) return -EINVAL; if (!pr->flags.throttling) return -ENODEV; - if (!alloc_cpumask_var(&saved_mask, GFP_KERNEL)) - return -ENOMEM; - /* - * Migrate task to the cpu pointed by pr. + * This is either called from the CPU hotplug callback of + * processor_driver or via the ACPI probe function. In the latter + * case the CPU is not guaranteed to be online. Both call sites are + * protected against CPU hotplug. */ - cpumask_copy(saved_mask, &current->cpus_allowed); - /* FIXME: use work_on_cpu() */ - if (set_cpus_allowed_ptr(current, cpumask_of(pr->id))) { - /* Can't migrate to the target pr->id CPU. Exit */ - free_cpumask_var(saved_mask); + if (!cpu_online(pr->id)) return -ENODEV; - } - ret = pr->throttling.acpi_processor_get_throttling(pr); - /* restore the previous state */ - set_cpus_allowed_ptr(current, saved_mask); - free_cpumask_var(saved_mask); - return ret; + return work_on_cpu(pr->id, __acpi_processor_get_throttling, pr); } static int acpi_processor_get_fadt_info(struct acpi_processor *pr) @@ -1080,8 +1076,15 @@ static long acpi_processor_throttling_fn arg->target_state, arg->force); } -int acpi_processor_set_throttling(struct acpi_processor *pr, - int state, bool force) +static int call_on_cpu(int cpu, long (*fn)(void *), void *arg, bool direct) +{ + if (direct) + return fn(arg); + return work_on_cpu(cpu, fn, arg); +} + +static int __acpi_processor_set_throttling(struct acpi_processor *pr, + int state, bool force, bool direct) { int ret = 0; unsigned int i; @@ -1130,7 +1133,8 @@ int acpi_processor_set_throttling(struct arg.pr = pr; arg.target_state = state; arg.force = force; - ret = work_on_cpu(pr->id, acpi_processor_throttling_fn, &arg); + ret = call_on_cpu(pr->id, acpi_processor_throttling_fn, &arg, + direct); } else { /* * When the T-state coordination is SW_ALL or HW_ALL, @@ -1163,8 +1167,8 @@ int acpi_processor_set_throttling(struct arg.pr = match_pr; arg.target_state = state; arg.force = force; - ret = work_on_cpu(pr->id, acpi_processor_throttling_fn, - &arg); + ret = call_on_cpu(pr->id, acpi_processor_throttling_fn, + &arg, direct); } } /* @@ -1182,6 +1186,12 @@ int acpi_processor_set_throttling(struct return ret; } +int acpi_processor_set_throttling(struct acpi_processor *pr, int state, + bool force) +{ + return __acpi_processor_set_throttling(pr, state, force, false); +} + int acpi_processor_get_throttling_info(struct acpi_processor *pr) { int result = 0; Patches currently in stable-queue which might be from tglx(a)linutronix.de are queue-4.9/acpi-processor-fix-error-handling-in-__acpi_processor_start.patch queue-4.9/x86-reboot-turn-off-kvm-when-halting-a-cpu.patch queue-4.9/acpi-processor-replace-racy-task-affinity-logic.patch queue-4.9/time-change-posix-clocks-ops-interfaces-to-use-timespec64.patch queue-4.9/genirq-use-irqd_get_trigger_type-to-compare-the-trigger-type-for-shared-irqs.patch queue-4.9/cpufreq-sh-replace-racy-task-affinity-logic.patch queue-4.9/irqchip-mips-gic-separate-ipi-reservation-usage-tracking.patch queue-4.9/x86-kaslr-fix-kexec-kernel-boot-crash-when-kaslr-randomization-fails.patch

7 years, 6 months

1
0
0 0

Patch "ACPI/processor: Fix error handling in __acpi_processor_start()" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled ACPI/processor: Fix error handling in __acpi_processor_start() to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: acpi-processor-fix-error-handling-in-__acpi_processor_start.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Thu Mar 22 14:40:23 CET 2018 From: Thomas Gleixner <tglx(a)linutronix.de> Date: Wed, 12 Apr 2017 22:07:33 +0200 Subject: ACPI/processor: Fix error handling in __acpi_processor_start() From: Thomas Gleixner <tglx(a)linutronix.de> [ Upstream commit a5cbdf693a60d5b86d4d21dfedd90f17754eb273 ] When acpi_install_notify_handler() fails the cooling device stays registered and the sysfs files created via acpi_pss_perf_init() are leaked and the function returns success. Undo acpi_pss_perf_init() and return a proper error code. Signed-off-by: Thomas Gleixner <tglx(a)linutronix.de> Cc: Fenghua Yu <fenghua.yu(a)intel.com> Cc: Tony Luck <tony.luck(a)intel.com> Cc: Herbert Xu <herbert(a)gondor.apana.org.au> Cc: "Rafael J. Wysocki" <rjw(a)rjwysocki.net> Cc: Peter Zijlstra <peterz(a)infradead.org> Cc: Benjamin Herrenschmidt <benh(a)kernel.crashing.org> Cc: Sebastian Siewior <bigeasy(a)linutronix.de> Cc: Lai Jiangshan <jiangshanlai(a)gmail.com> Cc: linux-acpi(a)vger.kernel.org Cc: Viresh Kumar <viresh.kumar(a)linaro.org> Cc: Michael Ellerman <mpe(a)ellerman.id.au> Cc: Tejun Heo <tj(a)kernel.org> Cc: "David S. Miller" <davem(a)davemloft.net> Cc: Len Brown <lenb(a)kernel.org> Link: http://lkml.kernel.org/r/20170412201042.695499645@linutronix.de Signed-off-by: Thomas Gleixner <tglx(a)linutronix.de> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/acpi/processor_driver.c | 3 +++ 1 file changed, 3 insertions(+) --- a/drivers/acpi/processor_driver.c +++ b/drivers/acpi/processor_driver.c @@ -251,6 +251,9 @@ static int __acpi_processor_start(struct if (ACPI_SUCCESS(status)) return 0; + result = -ENODEV; + acpi_pss_perf_exit(pr, device); + err_power_exit: acpi_processor_power_exit(pr); return result; Patches currently in stable-queue which might be from tglx(a)linutronix.de are queue-4.9/acpi-processor-fix-error-handling-in-__acpi_processor_start.patch queue-4.9/x86-reboot-turn-off-kvm-when-halting-a-cpu.patch queue-4.9/acpi-processor-replace-racy-task-affinity-logic.patch queue-4.9/time-change-posix-clocks-ops-interfaces-to-use-timespec64.patch queue-4.9/genirq-use-irqd_get_trigger_type-to-compare-the-trigger-type-for-shared-irqs.patch queue-4.9/cpufreq-sh-replace-racy-task-affinity-logic.patch queue-4.9/irqchip-mips-gic-separate-ipi-reservation-usage-tracking.patch queue-4.9/x86-kaslr-fix-kexec-kernel-boot-crash-when-kaslr-randomization-fails.patch

7 years, 6 months

1
0
0 0

Patch "ACPI / power: Delay turning off unused power resources after suspend" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled ACPI / power: Delay turning off unused power resources after suspend to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: acpi-power-delay-turning-off-unused-power-resources-after-suspend.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Thu Mar 22 14:40:23 CET 2018 From: Hans de Goede <hdegoede(a)redhat.com> Date: Sun, 30 Apr 2017 22:54:16 +0200 Subject: ACPI / power: Delay turning off unused power resources after suspend From: Hans de Goede <hdegoede(a)redhat.com> [ Upstream commit 8ece1d83346bcc431090d59a2184276192189cdd ] Commit 660b1113e0f3 (ACPI / PM: Fix consistency check for power resources during resume) introduced a check for ACPI power resources which have been turned on by the BIOS during suspend and turns these back off again. This is causing problems on a Dell Venue Pro 11 7130 (i5-4300Y) it causes the following messages to show up in dmesg: [ 131.014605] ACPI: Waking up from system sleep state S3 [ 131.150271] acpi LNXPOWER:07: Turning OFF [ 131.150323] acpi LNXPOWER:06: Turning OFF [ 131.150911] acpi LNXPOWER:00: Turning OFF [ 131.169014] ACPI : EC: interrupt unblocked [ 131.181811] xhci_hcd 0000:00:14.0: System wakeup disabled by ACPI [ 133.535728] pci_raw_set_power_state: 76 callbacks suppressed [ 133.535735] iwlwifi 0000:01:00.0: Refused to change power state, currently in D3 [ 133.597672] PM: noirq resume of devices complete after 2428.891 msecs Followed by a bunch of iwlwifi errors later on and the pcie device dropping from the bus (acpiphp thinks it has been unplugged). Disabling the turning off of unused power resources fixes this. Instead of adding a quirk for this system, this commit fixes this by moving the disabling of unused power resources to later in the resume sequence when the iwlwifi card has been moved out of D3 so the ref_count for its power resource no longer is 0. This new behavior seems to match the intend of the original commit which commit-msg says: "(... which means that no devices are going to need them any time soon) and we should turn them off". This also avoids power resources which we need when bringing devices out of D3 from getting bounced off and then back on again. Signed-off-by: Hans de Goede <hdegoede(a)redhat.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki(a)intel.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/acpi/power.c | 10 ++++++++++ drivers/acpi/sleep.c | 1 + drivers/acpi/sleep.h | 1 + 3 files changed, 12 insertions(+) --- a/drivers/acpi/power.c +++ b/drivers/acpi/power.c @@ -864,6 +864,16 @@ void acpi_resume_power_resources(void) mutex_unlock(&resource->resource_lock); } + + mutex_unlock(&power_resource_list_lock); +} + +void acpi_turn_off_unused_power_resources(void) +{ + struct acpi_power_resource *resource; + + mutex_lock(&power_resource_list_lock); + list_for_each_entry_reverse(resource, &acpi_power_resource_list, list_node) { int result, state; --- a/drivers/acpi/sleep.c +++ b/drivers/acpi/sleep.c @@ -474,6 +474,7 @@ static void acpi_pm_start(u32 acpi_state */ static void acpi_pm_end(void) { + acpi_turn_off_unused_power_resources(); acpi_scan_lock_release(); /* * This is necessary in case acpi_pm_finish() is not called during a --- a/drivers/acpi/sleep.h +++ b/drivers/acpi/sleep.h @@ -6,6 +6,7 @@ extern struct list_head acpi_wakeup_devi extern struct mutex acpi_device_lock; extern void acpi_resume_power_resources(void); +extern void acpi_turn_off_unused_power_resources(void); static inline acpi_status acpi_set_waking_vector(u32 wakeup_address) { Patches currently in stable-queue which might be from hdegoede(a)redhat.com are queue-4.9/power-supply-bq24190_charger-limit-over-under-voltage-fault-logging.patch queue-4.9/acpi-pmic-xpower-fix-power_table-addresses.patch queue-4.9/acpi-power-delay-turning-off-unused-power-resources-after-suspend.patch queue-4.9/rtc-cmos-do-not-assume-irq-8-for-rtc-when-there-are-no-legacy-irqs.patch queue-4.9/genirq-use-irqd_get_trigger_type-to-compare-the-trigger-type-for-shared-irqs.patch queue-4.9/power-supply-bq24190_charger-add-disable-reset-device-property.patch queue-4.9/x86-i8259-export-legacy_pic-symbol.patch

7 years, 6 months

1
0
0 0

Patch "ACPI / PMIC: xpower: Fix power_table addresses" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled ACPI / PMIC: xpower: Fix power_table addresses to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: acpi-pmic-xpower-fix-power_table-addresses.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Thu Mar 22 14:40:23 CET 2018 From: Hans de Goede <hdegoede(a)redhat.com> Date: Fri, 21 Apr 2017 13:48:08 +0200 Subject: ACPI / PMIC: xpower: Fix power_table addresses From: Hans de Goede <hdegoede(a)redhat.com> [ Upstream commit 2bde7c32b1db162692f05c6be066b5bcd3d9fdbe ] The power table addresses should be contiguous, but there was a hole where 0x34 was missing. On most devices this is not a problem as addresses above 0x34 are used for the BUC# convertors which are not used in the DSDTs I've access to but after the BUC# convertors there is a field named GPI1 in the DSTDs, which does get used in some cases and ended up turning BUC6 on and off due to the wrong addresses, resulting in turning the entire device off (or causing it to reboot). Removing the hole in the addresses fixes this, fixing one of my Bay Trail tablets turning off while booting the mainline kernel. While at it add comments with the field names used in the DSDTs to make it easier to compare the register and bits used at each address with the datasheet. Signed-off-by: Hans de Goede <hdegoede(a)redhat.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko(a)linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki(a)intel.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/acpi/pmic/intel_pmic_xpower.c | 50 +++++++++++++++++----------------- 1 file changed, 25 insertions(+), 25 deletions(-) --- a/drivers/acpi/pmic/intel_pmic_xpower.c +++ b/drivers/acpi/pmic/intel_pmic_xpower.c @@ -28,97 +28,97 @@ static struct pmic_table power_table[] = .address = 0x00, .reg = 0x13, .bit = 0x05, - }, + }, /* ALD1 */ { .address = 0x04, .reg = 0x13, .bit = 0x06, - }, + }, /* ALD2 */ { .address = 0x08, .reg = 0x13, .bit = 0x07, - }, + }, /* ALD3 */ { .address = 0x0c, .reg = 0x12, .bit = 0x03, - }, + }, /* DLD1 */ { .address = 0x10, .reg = 0x12, .bit = 0x04, - }, + }, /* DLD2 */ { .address = 0x14, .reg = 0x12, .bit = 0x05, - }, + }, /* DLD3 */ { .address = 0x18, .reg = 0x12, .bit = 0x06, - }, + }, /* DLD4 */ { .address = 0x1c, .reg = 0x12, .bit = 0x00, - }, + }, /* ELD1 */ { .address = 0x20, .reg = 0x12, .bit = 0x01, - }, + }, /* ELD2 */ { .address = 0x24, .reg = 0x12, .bit = 0x02, - }, + }, /* ELD3 */ { .address = 0x28, .reg = 0x13, .bit = 0x02, - }, + }, /* FLD1 */ { .address = 0x2c, .reg = 0x13, .bit = 0x03, - }, + }, /* FLD2 */ { .address = 0x30, .reg = 0x13, .bit = 0x04, - }, + }, /* FLD3 */ { - .address = 0x38, + .address = 0x34, .reg = 0x10, .bit = 0x03, - }, + }, /* BUC1 */ { - .address = 0x3c, + .address = 0x38, .reg = 0x10, .bit = 0x06, - }, + }, /* BUC2 */ { - .address = 0x40, + .address = 0x3c, .reg = 0x10, .bit = 0x05, - }, + }, /* BUC3 */ { - .address = 0x44, + .address = 0x40, .reg = 0x10, .bit = 0x04, - }, + }, /* BUC4 */ { - .address = 0x48, + .address = 0x44, .reg = 0x10, .bit = 0x01, - }, + }, /* BUC5 */ { - .address = 0x4c, + .address = 0x48, .reg = 0x10, .bit = 0x00 - }, + }, /* BUC6 */ }; /* TMP0 - TMP5 are the same, all from GPADC */ Patches currently in stable-queue which might be from hdegoede(a)redhat.com are queue-4.9/power-supply-bq24190_charger-limit-over-under-voltage-fault-logging.patch queue-4.9/acpi-pmic-xpower-fix-power_table-addresses.patch queue-4.9/acpi-power-delay-turning-off-unused-power-resources-after-suspend.patch queue-4.9/rtc-cmos-do-not-assume-irq-8-for-rtc-when-there-are-no-legacy-irqs.patch queue-4.9/genirq-use-irqd_get_trigger_type-to-compare-the-trigger-type-for-shared-irqs.patch queue-4.9/power-supply-bq24190_charger-add-disable-reset-device-property.patch queue-4.9/x86-i8259-export-legacy_pic-symbol.patch

7 years, 6 months

1
0
0 0

[GIT PULL] commits for Linux 4.14

by Sasha Levin

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi Greg, Pleae pull commits for Linux 4.14 . I've sent a review request for all commits over a week ago and all comments were addressed. Thanks, Sasha ===== The following changes since commit 267ef1d332845c1d361ff3fd1d346613a12db773: Linux 4.14.23 (2018-02-28 10:19:45 +0100) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/sashal/linux-stable.git tags/for-greg-4.14-19032018 for you to fetch changes up to 548224ecd13182106bf7f21f480e2762e95a700b: dmaengine: ti-dma-crossbar: Fix event mapping for TPCC_EVT_MUX_60_63 (2018-03-19 11:26:14 -0400) - ---------------------------------------------------------------- for-greg-4.14-19032018 - ---------------------------------------------------------------- Alexandre Belloni (1): rtc: ac100: Fix multiple race conditions Alexey Kodanev (1): ip6_vti: adjust vti mtu according to mtu of lower device Anton Vasilyev (1): RDMA/ocrdma: Fix permissions for OCRDMA_RESET_STATS Arnd Bergmann (1): cros_ec: fix nul-termination for firmware build info Artemy Kovalyov (1): IB/umem: Fix use of npages/nmap fields Balaji Pothunoori (1): ath10k: handling qos at STA side based on AP WMM enable/disable Benjamin Coddington (1): nfsd4: permit layoutget of executable-only files Bharat Potnuri (1): iser-target: avoid reinitializing rdma contexts for isert commands Bjorn Helgaas (1): vgacon: Set VGA struct resource types BjÃ¸rn Mork (1): qmi_wwan: set FLAG_SEND_ZLP to avoid network initiated disconnect Brian Norris (1): pinctrl: rockchip: enable clock when reading pin direction register Christophe JAILLET (1): media: bt8xx: Fix err 'bt878_probe()' Daniel Drake (1): mmc: avoid removing non-removable hosts during suspend Erez Shitrit (1): IB/ipoib: Avoid memory leak if the SA returns a different DGID Florian Fainelli (1): pinctrl: Really force states during suspend/resume Geert Uytterhoeven (3): RDMA/iwpm: Fix uninitialized error code in iwpm_send_mapinfo() spi: sh-msiof: Avoid writing to registers from spi_master.setup() PCI: rcar: Handle rcar_pcie_parse_request_of_pci_ranges() failures Guenter Roeck (2): watchdog: Fix potential kref imbalance when opening watchdog watchdog: Fix kref imbalance seen if handle_boot_enabled=0 Gustavo A. R. Silva (1): media: c8sectpfe: fix potential NULL pointer dereference in c8sectpfe_timer_interrupt H. Nikolaus Schaller (1): omapdrm: panel: fix compatible vendor string for td028ttec1 Haishuang Yan (2): ip_gre: fix error path when erspan_rcv failed ip_gre: fix potential memory leak in erspan_rcv Haiyang Zhang (2): hv_netvsc: Fix the receive buffer size limit hv_netvsc: Fix the TX/RX buffer default sizes James Smart (2): scsi: lpfc: Fix SCSI LUN discovery when SCSI and NVME enabled scsi: lpfc: Fix issues connecting with nvme initiator Jerome Brunet (1): net: phy: meson-gxl: check phy_write return value Jerry Snitselaar (1): iommu/vt-d: clean up pr_irq if request_threaded_irq fails Joel Stanley (1): ARM: dts: aspeed-evb: Add unit name to memory node Johan Hovold (1): soc: qcom: smsm: fix child-node lookup Kedareswara rao Appana (1): dmaengine: zynqmp_dma: Fix race condition in the probe Kees Cook (1): /dev/mem: Add bounce buffer for copy-out Kishon Vijay Abraham I (1): PCI: designware-ep: Fix ->get_msi() to check MSI_EN bit Lars Persson (1): crypto: artpec6 - set correct iv size for gcm(aes) Lars-Peter Clausen (1): clk: axi-clkgen: Correctly handle nocount bit in recalc_rate() Liu, Changcheng (1): mmc: block: fix logical error to avoid memory leak Logan Gunthorpe (1): drm/tilcdc: ensure nonatomic iowrite64 is not used Loic Poulain (2): Bluetooth: hci_qca: Avoid setup failure on missing rampatch Bluetooth: btqcomsmd: Fix skb double free corruption Mauro Carvalho Chehab (1): media: davinci: fix a debug printk NeilBrown (1): dm: ensure bio submission follows a depth-first tree walk Nicolas Iooss (1): rtlwifi: always initialize variables given to RT_TRACE() Niklas Cassel (1): PCI: endpoint: Fix find_first_zero_bit() usage Parav Pandit (1): RDMA/cma: Use correct size when writing netlink stats Peter Ujfalusi (1): drm/omap: DMM: Check for DMM readiness after successful transaction commit Prakash Kamliya (1): drm/msm: fix leak in failed get_pages Richard Leitner (1): net: fec: add phy_reset_after_clk_enable() support Robert Walker (1): coresight: Fix disabling of CoreSight TPIU Romain Izard (1): clk: at91: pmc: Wait for clocks when resuming Ron Economos (1): media: [RESEND] media: dvb-frontends: Add delay to Si2168 restart Russell King (2): sfp: fix EEPROM reading in the case of non-SFF8472 SFPs sfp: fix non-detection of PHY Sahara (1): pty: cancel pty slave port buf's work in tty_release Sebastian Andrzej Siewior (1): tty: goldfish: Enable 'earlycon' only if built-in Sergej Sawazki (1): clk: si5351: Rename internal plls to avoid name collisions Shawn Nematbakhsh (1): platform/chrome: Use proper protocol transfer function Shuah Khan (1): media: s5p-mfc: Fix lock contention - request_firmware() once Stefan Potyra (1): serial: 8250_dw: Disable clock on error Stephen Boyd (1): clk: Don't touch hardware when reparenting during registration Tsang-Shian Lin (1): rtlwifi: rtl_pci: Fix the bug when inactiveps is enabled. Vignesh R (1): dmaengine: ti-dma-crossbar: Fix event mapping for TPCC_EVT_MUX_60_63 Viresh Kumar (1): cpufreq: longhaul: Revert transition_delay_us to 200 ms Zhoujie Wu (1): mmc: sdhci-xenon: wait 5ms after set 1.8V signal enable .../{toppoly,td028ttec1.txt => tpo,td028ttec1.txt} | 4 +- arch/alpha/kernel/console.c | 1 + arch/arm/boot/dts/aspeed-ast2500-evb.dts | 2 +- drivers/bluetooth/btqcomsmd.c | 3 +- drivers/bluetooth/hci_qca.c | 3 ++ drivers/char/mem.c | 27 +++++++++--- drivers/clk/at91/pmc.c | 24 +++++++---- drivers/clk/clk-axi-clkgen.c | 29 ++++++++++--- drivers/clk/clk-si5351.c | 2 +- drivers/clk/clk.c | 7 ++- drivers/cpufreq/longhaul.c | 2 +- drivers/crypto/axis/artpec6_crypto.c | 5 ++- drivers/dma/ti-dma-crossbar.c | 10 ++++- drivers/dma/xilinx/zynqmp_dma.c | 3 +- drivers/gpu/drm/msm/msm_gem.c | 14 ++++-- .../drm/omapdrm/displays/panel-tpo-td028ttec1.c | 3 ++ drivers/gpu/drm/omapdrm/omap_dmm_tiler.c | 5 +++ drivers/gpu/drm/tilcdc/tilcdc_regs.h | 2 +- drivers/hwtracing/coresight/coresight-tpiu.c | 13 ++++-- drivers/infiniband/core/cma.c | 2 +- drivers/infiniband/core/iwpm_util.c | 1 + drivers/infiniband/core/umem.c | 2 +- drivers/infiniband/hw/ocrdma/ocrdma_stats.c | 2 +- drivers/infiniband/ulp/ipoib/ipoib_main.c | 16 +++++++ drivers/infiniband/ulp/isert/ib_isert.c | 7 +++ drivers/infiniband/ulp/isert/ib_isert.h | 1 + drivers/iommu/intel-svm.c | 9 ++-- drivers/md/dm.c | 33 ++++++++++---- drivers/media/dvb-frontends/si2168.c | 3 ++ drivers/media/pci/bt8xx/bt878.c | 3 +- drivers/media/platform/davinci/vpif_capture.c | 4 +- drivers/media/platform/s5p-mfc/s5p_mfc.c | 6 +++ drivers/media/platform/s5p-mfc/s5p_mfc_common.h | 3 ++ drivers/media/platform/s5p-mfc/s5p_mfc_ctrl.c | 5 +++ .../media/platform/sti/c8sectpfe/c8sectpfe-core.c | 4 +- drivers/mmc/core/block.c | 1 + drivers/mmc/core/core.c | 8 ++++ drivers/mmc/host/sdhci-xenon.c | 7 +++ drivers/net/ethernet/freescale/fec_main.c | 20 +++++++++ drivers/net/hyperv/hyperv_net.h | 19 ++++++-- drivers/net/hyperv/netvsc.c | 5 +++ drivers/net/hyperv/netvsc_drv.c | 4 -- drivers/net/phy/meson-gxl.c | 50 ++++++++++++++++------ drivers/net/phy/sfp.c | 15 +++---- drivers/net/usb/qmi_wwan.c | 4 +- drivers/net/wireless/ath/ath10k/mac.c | 2 +- drivers/net/wireless/realtek/rtlwifi/base.c | 2 +- drivers/net/wireless/realtek/rtlwifi/pci.c | 7 +++ drivers/pci/dwc/pcie-designware-ep.c | 12 ++---- drivers/pci/dwc/pcie-designware.h | 1 + drivers/pci/endpoint/pci-ep-cfs.c | 5 ++- drivers/pci/host/pcie-rcar.c | 5 ++- drivers/pinctrl/core.c | 24 ++++++++--- drivers/pinctrl/pinctrl-rockchip.c | 8 ++++ drivers/platform/chrome/cros_ec_proto.c | 8 ++-- drivers/platform/chrome/cros_ec_sysfs.c | 2 +- drivers/rtc/rtc-ac100.c | 19 +++++--- drivers/scsi/lpfc/lpfc_ct.c | 1 + drivers/scsi/lpfc/lpfc_els.c | 30 ++++++++----- drivers/scsi/lpfc/lpfc_nportdisc.c | 34 +++++++-------- drivers/soc/qcom/smsm.c | 6 ++- drivers/spi/spi-sh-msiof.c | 35 ++++++++++----- drivers/tty/Kconfig | 6 ++- drivers/tty/goldfish.c | 2 + drivers/tty/serial/8250/8250_dw.c | 3 +- drivers/tty/tty_io.c | 2 + drivers/video/console/vgacon.c | 34 +++++++++++---- .../omap2/omapfb/displays/panel-tpo-td028ttec1.c | 3 ++ drivers/watchdog/watchdog_dev.c | 17 ++++---- fs/nfsd/nfs4proc.c | 6 +-- net/ipv4/ip_gre.c | 6 ++- net/ipv6/ip6_vti.c | 20 +++++++++ security/Kconfig | 1 + 73 files changed, 512 insertions(+), 182 deletions(-) rename Documentation/devicetree/bindings/display/panel/{toppoly,td028ttec1.txt => tpo,td028ttec1.txt} (84%) -----BEGIN PGP SIGNATURE----- iQIcBAEBCAAGBQJar9lzAAoJEN6mb/eXdyzcSf8QAIcKmpDULDdSpczh7OmsuEHN PvN+cDGHyDkiNn1DVxzYNlw+Vl3+DGE463bxv1L15nsVGyh2jKHDrmDQ16QfCYHN P8W9R3o0RaVXdhLohUCZYk+Z9RXsVgOPmDFo51p7v5X9cLcTLtfalb5rMmkyt+/b PjMYupI9LDq8EkwP28EGanuiS10qNzDwoo+fMxwr/ox8cZkbJMCCuRNBJ5You8x5 QIhLopdJQYSoBBuMnF3ojSOWyEeIDg4kNGorYRFvTjxc+1Z+QUt8/WKKC82uESqw DqwJezhBCUwY9Rgpl+X05mFFXoiOVtbL8JjB1Vdl1QHOdQrTHtnc7aMar+xhEbxi vW3Cl9eyaXIf+OXJzETyywFwbSFPGpiaI0r8cXAlmpo0h2XRcd5n+Vf5HeR/joRk LBEqVMMStZQxGaUdowaB+dLGY3xyn3/zpmNdUmu8fIXHcXQW+3g0fyVcPV8rzamn gdFZiugaP8vbSnINcl45cFKABGt1S/sxrKjCUl/r5k4+4+6ZkPm16Mkt7kFCv1s6 ZqFj3gEmOVVRlb7Tyt9NLP0lNhagIOiOkuG4+/aSUpR9AHqup/r78gOqgWVVg5pv hllygJXdx11vWLEeuWHKI0Dc2nSG6VW0LzpOD2V4j5SH/UgSdNsgVGh5Mopnsuw+ 6XLPeoQqFminp4i7T2JO =6egy -----END PGP SIGNATURE-----

7 years, 6 months

2
1
0 0

Patch "watchdog: Fix potential kref imbalance when opening watchdog" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled watchdog: Fix potential kref imbalance when opening watchdog to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: watchdog-fix-potential-kref-imbalance-when-opening-watchdog.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Thu Mar 22 14:26:48 CET 2018 From: Guenter Roeck <linux(a)roeck-us.net> Date: Mon, 25 Sep 2017 09:17:01 -0700 Subject: watchdog: Fix potential kref imbalance when opening watchdog From: Guenter Roeck <linux(a)roeck-us.net> [ Upstream commit 4bcd615fad6adddc68b058d498b30a9e0e0db77a ] If a watchdog driver's open function sets WDOG_HW_RUNNING with the expectation that the watchdog can not be stopped, but then stops the watchdog anyway in its stop function, kref_get() wil not be called in watchdog_open(). If the watchdog then stops on close, WDOG_HW_RUNNING will be cleared and kref_put() will be called, causing a kref imbalance. As result the character device data structure will be released, which in turn will cause the system to crash on the next call to watchdog_open(). Fixes: ee142889e32f5 ("watchdog: Introduce WDOG_HW_RUNNING flag") Signed-off-by: Guenter Roeck <linux(a)roeck-us.net> Signed-off-by: Wim Van Sebroeck <wim(a)iguana.be> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/watchdog/watchdog_dev.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) --- a/drivers/watchdog/watchdog_dev.c +++ b/drivers/watchdog/watchdog_dev.c @@ -768,6 +768,7 @@ static int watchdog_open(struct inode *i { struct watchdog_core_data *wd_data; struct watchdog_device *wdd; + bool hw_running; int err; /* Get the corresponding watchdog device */ @@ -787,7 +788,8 @@ static int watchdog_open(struct inode *i * If the /dev/watchdog device is open, we don't want the module * to be unloaded. */ - if (!watchdog_hw_running(wdd) && !try_module_get(wdd->ops->owner)) { + hw_running = watchdog_hw_running(wdd); + if (!hw_running && !try_module_get(wdd->ops->owner)) { err = -EBUSY; goto out_clear; } @@ -798,7 +800,7 @@ static int watchdog_open(struct inode *i file->private_data = wd_data; - if (!watchdog_hw_running(wdd)) + if (!hw_running) kref_get(&wd_data->kref); /* dev/watchdog is a virtual (and thus non-seekable) filesystem */ Patches currently in stable-queue which might be from linux(a)roeck-us.net are queue-4.14/watchdog-fix-potential-kref-imbalance-when-opening-watchdog.patch queue-4.14/watchdog-fix-kref-imbalance-seen-if-handle_boot_enabled-0.patch

7 years, 6 months

1
0
0 0

Patch "watchdog: Fix kref imbalance seen if handle_boot_enabled=0" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled watchdog: Fix kref imbalance seen if handle_boot_enabled=0 to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: watchdog-fix-kref-imbalance-seen-if-handle_boot_enabled-0.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Thu Mar 22 14:26:48 CET 2018 From: Guenter Roeck <linux(a)roeck-us.net> Date: Mon, 25 Sep 2017 09:17:02 -0700 Subject: watchdog: Fix kref imbalance seen if handle_boot_enabled=0 From: Guenter Roeck <linux(a)roeck-us.net> [ Upstream commit 914d65f3f013ba2556c7beec5d3baac7b3292504 ] If handle_boot_enabled is set to 0, the watchdog driver module use counter will not be increased and kref_get() will not be called when registering the watchdog. Subsequently, on open, this does not happen either because the code believes that it was already done because the hardware watchdog is marked as running. We could introduce a state variable to indicate this state, but let's just increase the module use counter and call kref_get() unconditionally if the hardware watchdog is running when a driver is registering itself to keep the code simple. Fixes: 2501b015313fe ("watchdog: core: add option to avoid early ...") Cc: Sebastian Reichel <sebastian.reichel(a)collabora.co.uk> Signed-off-by: Guenter Roeck <linux(a)roeck-us.net> Signed-off-by: Wim Van Sebroeck <wim(a)iguana.be> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/watchdog/watchdog_dev.c | 11 +++++------ 1 file changed, 5 insertions(+), 6 deletions(-) --- a/drivers/watchdog/watchdog_dev.c +++ b/drivers/watchdog/watchdog_dev.c @@ -966,14 +966,13 @@ static int watchdog_cdev_register(struct * and schedule an immediate ping. */ if (watchdog_hw_running(wdd)) { - if (handle_boot_enabled) { - __module_get(wdd->ops->owner); - kref_get(&wd_data->kref); + __module_get(wdd->ops->owner); + kref_get(&wd_data->kref); + if (handle_boot_enabled) queue_delayed_work(watchdog_wq, &wd_data->work, 0); - } else { + else pr_info("watchdog%d running and kernel based pre-userspace handler disabled\n", - wdd->id); - } + wdd->id); } return 0; Patches currently in stable-queue which might be from linux(a)roeck-us.net are queue-4.14/watchdog-fix-potential-kref-imbalance-when-opening-watchdog.patch queue-4.14/watchdog-fix-kref-imbalance-seen-if-handle_boot_enabled-0.patch

7 years, 6 months

1
0
0 0

Patch "vgacon: Set VGA struct resource types" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled vgacon: Set VGA struct resource types to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: vgacon-set-vga-struct-resource-types.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Thu Mar 22 14:26:48 CET 2018 From: Bjorn Helgaas <bhelgaas(a)google.com> Date: Fri, 1 Dec 2017 11:06:39 -0600 Subject: vgacon: Set VGA struct resource types From: Bjorn Helgaas <bhelgaas(a)google.com> [ Upstream commit c82084117f79bcae085e40da526253736a247120 ] Set the resource type when we reserve VGA-related I/O port resources. The resource code doesn't actually look at the type, so it inserts resources without a type in the tree correctly even without this change. But if we ever print a resource without a type, it looks like this: vga+ [??? 0x000003c0-0x000003df flags 0x0] Setting the type means it will be printed correctly as: vga+ [io 0x000003c0-0x000003df] Signed-off-by: Bjorn Helgaas <bhelgaas(a)google.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/alpha/kernel/console.c | 1 + drivers/video/console/vgacon.c | 34 ++++++++++++++++++++++++++-------- 2 files changed, 27 insertions(+), 8 deletions(-) --- a/arch/alpha/kernel/console.c +++ b/arch/alpha/kernel/console.c @@ -21,6 +21,7 @@ struct pci_controller *pci_vga_hose; static struct resource alpha_vga = { .name = "alpha-vga+", + .flags = IORESOURCE_IO, .start = 0x3C0, .end = 0x3DF }; --- a/drivers/video/console/vgacon.c +++ b/drivers/video/console/vgacon.c @@ -422,7 +422,10 @@ static const char *vgacon_startup(void) vga_video_port_val = VGA_CRT_DM; if ((screen_info.orig_video_ega_bx & 0xff) != 0x10) { static struct resource ega_console_resource = - { .name = "ega", .start = 0x3B0, .end = 0x3BF }; + { .name = "ega", + .flags = IORESOURCE_IO, + .start = 0x3B0, + .end = 0x3BF }; vga_video_type = VIDEO_TYPE_EGAM; vga_vram_size = 0x8000; display_desc = "EGA+"; @@ -430,9 +433,15 @@ static const char *vgacon_startup(void) &ega_console_resource); } else { static struct resource mda1_console_resource = - { .name = "mda", .start = 0x3B0, .end = 0x3BB }; + { .name = "mda", + .flags = IORESOURCE_IO, + .start = 0x3B0, + .end = 0x3BB }; static struct resource mda2_console_resource = - { .name = "mda", .start = 0x3BF, .end = 0x3BF }; + { .name = "mda", + .flags = IORESOURCE_IO, + .start = 0x3BF, + .end = 0x3BF }; vga_video_type = VIDEO_TYPE_MDA; vga_vram_size = 0x2000; display_desc = "*MDA"; @@ -454,15 +463,21 @@ static const char *vgacon_startup(void) vga_vram_size = 0x8000; if (!screen_info.orig_video_isVGA) { - static struct resource ega_console_resource - = { .name = "ega", .start = 0x3C0, .end = 0x3DF }; + static struct resource ega_console_resource = + { .name = "ega", + .flags = IORESOURCE_IO, + .start = 0x3C0, + .end = 0x3DF }; vga_video_type = VIDEO_TYPE_EGAC; display_desc = "EGA"; request_resource(&ioport_resource, &ega_console_resource); } else { - static struct resource vga_console_resource - = { .name = "vga+", .start = 0x3C0, .end = 0x3DF }; + static struct resource vga_console_resource = + { .name = "vga+", + .flags = IORESOURCE_IO, + .start = 0x3C0, + .end = 0x3DF }; vga_video_type = VIDEO_TYPE_VGAC; display_desc = "VGA+"; request_resource(&ioport_resource, @@ -494,7 +509,10 @@ static const char *vgacon_startup(void) } } else { static struct resource cga_console_resource = - { .name = "cga", .start = 0x3D4, .end = 0x3D5 }; + { .name = "cga", + .flags = IORESOURCE_IO, + .start = 0x3D4, + .end = 0x3D5 }; vga_video_type = VIDEO_TYPE_CGA; vga_vram_size = 0x2000; display_desc = "*CGA"; Patches currently in stable-queue which might be from bhelgaas(a)google.com are queue-4.14/vgacon-set-vga-struct-resource-types.patch

7 years, 6 months

1
0
0 0

Patch "tty: goldfish: Enable 'earlycon' only if built-in" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled tty: goldfish: Enable 'earlycon' only if built-in to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: tty-goldfish-enable-earlycon-only-if-built-in.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Thu Mar 22 14:26:48 CET 2018 From: Sebastian Andrzej Siewior <bigeasy(a)linutronix.de> Date: Thu, 30 Nov 2017 09:16:31 +0100 Subject: tty: goldfish: Enable 'earlycon' only if built-in From: Sebastian Andrzej Siewior <bigeasy(a)linutronix.de> [ Upstream commit 6a28fd2bbc94bfca105632e5ef8a9dbe63ba0b39 ] Commit 3840ed9548f7 ("tty: goldfish: Implement support for kernel 'earlycon' parameter") breaks an allmodconfig config on x86: | LD vmlinux.o | MODPOST vmlinux.o |drivers/tty/serial/earlycon.o: In function `parse_options': |drivers/tty/serial/earlycon.c:97: undefined reference to `uart_parse_earlycon' |Makefile:1005: recipe for target 'vmlinux' failed earlycon.c::parse_options() invokes uart_parse_earlycon() from serial_core.c which is compiled=m because GOLDFISH_TTY itself (and most others) are =m. To avoid that, I'm adding the _CONSOLE config option which is selected if the GOLDFISH module itself is =y since it doesn't need the early bits for the =m case (other drivers do the same dance). The alternative would be to move uart_parse_earlycon() from serial_core.c to earlycon.c (we don't have that many users of that function). Fixes: 3840ed9548f7 ("tty: goldfish: Implement support for kernel 'earlycon' parameter") Signed-off-by: Sebastian Andrzej Siewior <bigeasy(a)linutronix.de> Reviewed-by: Miodrag Dinic <miodrag.dinic(a)mips.com> Acked-by: Miodrag Dinic <miodrag.dinic(a)mips.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/tty/Kconfig | 6 +++++- drivers/tty/goldfish.c | 2 ++ 2 files changed, 7 insertions(+), 1 deletion(-) --- a/drivers/tty/Kconfig +++ b/drivers/tty/Kconfig @@ -394,10 +394,14 @@ config GOLDFISH_TTY depends on GOLDFISH select SERIAL_CORE select SERIAL_CORE_CONSOLE - select SERIAL_EARLYCON help Console and system TTY driver for the Goldfish virtual platform. +config GOLDFISH_TTY_EARLY_CONSOLE + bool + default y if GOLDFISH_TTY=y + select SERIAL_EARLYCON + config DA_TTY bool "DA TTY" depends on METAG_DA --- a/drivers/tty/goldfish.c +++ b/drivers/tty/goldfish.c @@ -442,6 +442,7 @@ static int goldfish_tty_remove(struct pl return 0; } +#ifdef CONFIG_GOLDFISH_TTY_EARLY_CONSOLE static void gf_early_console_putchar(struct uart_port *port, int ch) { __raw_writel(ch, port->membase); @@ -465,6 +466,7 @@ static int __init gf_earlycon_setup(stru } OF_EARLYCON_DECLARE(early_gf_tty, "google,goldfish-tty", gf_earlycon_setup); +#endif static const struct of_device_id goldfish_tty_of_match[] = { { .compatible = "google,goldfish-tty", }, Patches currently in stable-queue which might be from bigeasy(a)linutronix.de are queue-4.14/tty-goldfish-enable-earlycon-only-if-built-in.patch

7 years, 6 months

1
0
0 0

Patch "spi: sh-msiof: Avoid writing to registers from spi_master.setup()" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled spi: sh-msiof: Avoid writing to registers from spi_master.setup() to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: spi-sh-msiof-avoid-writing-to-registers-from-spi_master.setup.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Thu Mar 22 14:26:48 CET 2018 From: Geert Uytterhoeven <geert+renesas(a)glider.be> Date: Wed, 13 Dec 2017 20:05:10 +0100 Subject: spi: sh-msiof: Avoid writing to registers from spi_master.setup() From: Geert Uytterhoeven <geert+renesas(a)glider.be> [ Upstream commit 7ff0b53c4051145d1cf992d2f60987e6447eed4f ] The spi_master.setup() callback must not change configuration registers, as that could corrupt I/O that is in progress for other SPI slaves. The only exception is the configuration of the native chip select polarity in SPI master mode, as a wrong chip select polarity will cause havoc during all future transfers to any other SPI slave. Hence stop writing to registers in sh_msiof_spi_setup(), unless it is the first call for a controller using a native chip select, or unless native chip select polarity has changed (note that you'll loose anyway if I/O is in progress). Even then, only do what is strictly necessary, instead of calling sh_msiof_spi_set_pin_regs(). Signed-off-by: Geert Uytterhoeven <geert+renesas(a)glider.be> Signed-off-by: Mark Brown <broonie(a)kernel.org> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/spi/spi-sh-msiof.c | 35 ++++++++++++++++++++++++----------- 1 file changed, 24 insertions(+), 11 deletions(-) --- a/drivers/spi/spi-sh-msiof.c +++ b/drivers/spi/spi-sh-msiof.c @@ -55,6 +55,8 @@ struct sh_msiof_spi_priv { void *rx_dma_page; dma_addr_t tx_dma_addr; dma_addr_t rx_dma_addr; + bool native_cs_inited; + bool native_cs_high; bool slave_aborted; }; @@ -528,8 +530,7 @@ static int sh_msiof_spi_setup(struct spi { struct device_node *np = spi->master->dev.of_node; struct sh_msiof_spi_priv *p = spi_master_get_devdata(spi->master); - - pm_runtime_get_sync(&p->pdev->dev); + u32 clr, set, tmp; if (!np) { /* @@ -539,19 +540,31 @@ static int sh_msiof_spi_setup(struct spi spi->cs_gpio = (uintptr_t)spi->controller_data; } - /* Configure pins before deasserting CS */ - sh_msiof_spi_set_pin_regs(p, !!(spi->mode & SPI_CPOL), - !!(spi->mode & SPI_CPHA), - !!(spi->mode & SPI_3WIRE), - !!(spi->mode & SPI_LSB_FIRST), - !!(spi->mode & SPI_CS_HIGH)); - - if (spi->cs_gpio >= 0) + if (spi->cs_gpio >= 0) { gpio_set_value(spi->cs_gpio, !(spi->mode & SPI_CS_HIGH)); + return 0; + } + + if (spi_controller_is_slave(p->master)) + return 0; + if (p->native_cs_inited && + (p->native_cs_high == !!(spi->mode & SPI_CS_HIGH))) + return 0; + /* Configure native chip select mode/polarity early */ + clr = MDR1_SYNCMD_MASK; + set = MDR1_TRMD | TMDR1_PCON | MDR1_SYNCMD_SPI; + if (spi->mode & SPI_CS_HIGH) + clr |= BIT(MDR1_SYNCAC_SHIFT); + else + set |= BIT(MDR1_SYNCAC_SHIFT); + pm_runtime_get_sync(&p->pdev->dev); + tmp = sh_msiof_read(p, TMDR1) & ~clr; + sh_msiof_write(p, TMDR1, tmp | set); pm_runtime_put(&p->pdev->dev); - + p->native_cs_high = spi->mode & SPI_CS_HIGH; + p->native_cs_inited = true; return 0; } Patches currently in stable-queue which might be from geert+renesas(a)glider.be are queue-4.14/spi-sh-msiof-avoid-writing-to-registers-from-spi_master.setup.patch queue-4.14/pci-rcar-handle-rcar_pcie_parse_request_of_pci_ranges-failures.patch

7 years, 6 months

1
0
0 0

Patch "soc: qcom: smsm: fix child-node lookup" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled soc: qcom: smsm: fix child-node lookup to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: soc-qcom-smsm-fix-child-node-lookup.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Thu Mar 22 14:26:48 CET 2018 From: Johan Hovold <johan(a)kernel.org> Date: Wed, 15 Nov 2017 12:07:24 +0100 Subject: soc: qcom: smsm: fix child-node lookup From: Johan Hovold <johan(a)kernel.org> [ Upstream commit 8804517e9fc16c10081ff5e42e7d80704973a8e2 ] Fix child-node lookup during probe, which ended up searching the whole device tree depth-first starting at the parent rather than just matching on its children. Note that the original premature free of the parent node has already been fixed separately. Also note that this pattern of looking up the first child node with a given property is rare enough that a generic helper is probably not warranted. Fixes: c97c4090ff72 ("soc: qcom: smsm: Add driver for Qualcomm SMSM") Fixes: 3e8b55411468 ("soc: qcom: smsm: fix of_node refcnting problem") Cc: Bjorn Andersson <bjorn.andersson(a)linaro.org> Cc: Rob Clark <robdclark(a)gmail.com> Signed-off-by: Johan Hovold <johan(a)kernel.org> Reviewed-by: Bjorn Andersson <bjorn.andersson(a)linaro.org> Signed-off-by: Andy Gross <andy.gross(a)linaro.org> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/soc/qcom/smsm.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) --- a/drivers/soc/qcom/smsm.c +++ b/drivers/soc/qcom/smsm.c @@ -496,8 +496,10 @@ static int qcom_smsm_probe(struct platfo if (!smsm->hosts) return -ENOMEM; - local_node = of_find_node_with_property(of_node_get(pdev->dev.of_node), - "#qcom,smem-state-cells"); + for_each_child_of_node(pdev->dev.of_node, local_node) { + if (of_find_property(local_node, "#qcom,smem-state-cells", NULL)) + break; + } if (!local_node) { dev_err(&pdev->dev, "no state entry\n"); return -EINVAL; Patches currently in stable-queue which might be from johan(a)kernel.org are queue-4.14/soc-qcom-smsm-fix-child-node-lookup.patch

7 years, 6 months

1
0
0 0

Patch "sfp: fix non-detection of PHY" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled sfp: fix non-detection of PHY to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: sfp-fix-non-detection-of-phy.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Thu Mar 22 14:26:48 CET 2018 From: Russell King <rmk+kernel(a)armlinux.org.uk> Date: Fri, 15 Dec 2017 16:09:36 +0000 Subject: sfp: fix non-detection of PHY From: Russell King <rmk+kernel(a)armlinux.org.uk> [ Upstream commit 20b56ed9f8adfb9a7fb1c878878c54aa4ed645c1 ] The detection of a PHY changed in commit e98a3aabf85f ("mdio_bus: don't return NULL from mdiobus_scan()") which now causes sfp to print an error message. Update for this change. Fixes: 73970055450e ("sfp: add SFP module support") Signed-off-by: Russell King <rmk+kernel(a)armlinux.org.uk> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/net/phy/sfp.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) --- a/drivers/net/phy/sfp.c +++ b/drivers/net/phy/sfp.c @@ -318,12 +318,12 @@ static void sfp_sm_probe_phy(struct sfp msleep(T_PHY_RESET_MS); phy = mdiobus_scan(sfp->i2c_mii, SFP_PHY_ADDR); - if (IS_ERR(phy)) { - dev_err(sfp->dev, "mdiobus scan returned %ld\n", PTR_ERR(phy)); + if (phy == ERR_PTR(-ENODEV)) { + dev_info(sfp->dev, "no PHY detected\n"); return; } - if (!phy) { - dev_info(sfp->dev, "no PHY detected\n"); + if (IS_ERR(phy)) { + dev_err(sfp->dev, "mdiobus scan returned %ld\n", PTR_ERR(phy)); return; } Patches currently in stable-queue which might be from rmk+kernel(a)armlinux.org.uk are queue-4.14/sfp-fix-non-detection-of-phy.patch queue-4.14/sfp-fix-eeprom-reading-in-the-case-of-non-sff8472-sfps.patch

7 years, 6 months

1
0
0 0

Patch "sfp: fix EEPROM reading in the case of non-SFF8472 SFPs" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled sfp: fix EEPROM reading in the case of non-SFF8472 SFPs to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: sfp-fix-eeprom-reading-in-the-case-of-non-sff8472-sfps.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Thu Mar 22 14:26:48 CET 2018 From: Russell King <rmk+kernel(a)armlinux.org.uk> Date: Fri, 15 Dec 2017 16:09:41 +0000 Subject: sfp: fix EEPROM reading in the case of non-SFF8472 SFPs From: Russell King <rmk+kernel(a)armlinux.org.uk> [ Upstream commit 2794ffc441dde3109804085dc745e8014a4de224 ] The EEPROM reading was trying to read from the second EEPROM address if we requested the last byte from the SFF8079 EEPROM, which caused a failure when the second EEPROM is not present. Discovered with a S-RJ01 SFP module. Fix this. Fixes: 73970055450e ("sfp: add SFP module support") Signed-off-by: Russell King <rmk+kernel(a)armlinux.org.uk> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/net/phy/sfp.c | 7 +++---- 1 file changed, 3 insertions(+), 4 deletions(-) --- a/drivers/net/phy/sfp.c +++ b/drivers/net/phy/sfp.c @@ -667,20 +667,19 @@ static int sfp_module_eeprom(struct sfp len = min_t(unsigned int, last, ETH_MODULE_SFF_8079_LEN); len -= first; - ret = sfp->read(sfp, false, first, data, len); + ret = sfp_read(sfp, false, first, data, len); if (ret < 0) return ret; first += len; data += len; } - if (first >= ETH_MODULE_SFF_8079_LEN && - first < ETH_MODULE_SFF_8472_LEN) { + if (first < ETH_MODULE_SFF_8472_LEN && last > ETH_MODULE_SFF_8079_LEN) { len = min_t(unsigned int, last, ETH_MODULE_SFF_8472_LEN); len -= first; first -= ETH_MODULE_SFF_8079_LEN; - ret = sfp->read(sfp, true, first, data, len); + ret = sfp_read(sfp, true, first, data, len); if (ret < 0) return ret; } Patches currently in stable-queue which might be from rmk+kernel(a)armlinux.org.uk are queue-4.14/sfp-fix-non-detection-of-phy.patch queue-4.14/sfp-fix-eeprom-reading-in-the-case-of-non-sff8472-sfps.patch

7 years, 6 months

1
0
0 0

Patch "serial: 8250_dw: Disable clock on error" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled serial: 8250_dw: Disable clock on error to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: serial-8250_dw-disable-clock-on-error.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Thu Mar 22 14:26:48 CET 2018 From: Stefan Potyra <Stefan.Potyra(a)elektrobit.com> Date: Wed, 6 Dec 2017 16:46:12 +0100 Subject: serial: 8250_dw: Disable clock on error From: Stefan Potyra <Stefan.Potyra(a)elektrobit.com> [ Upstream commit 8af016aa5a27c6a2505460eb4d83f1e70c38dc43 ] If there is no clock rate for uartclk defined, disable the previously enabled clock again. Found by Linux Driver Verification project (linuxtesting.org). Fixes: 23f5b3fdd04e serial: 8250_dw: only get the clock rate in one place Signed-off-by: Stefan Potyra <Stefan.Potyra(a)elektrobit.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/tty/serial/8250/8250_dw.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) --- a/drivers/tty/serial/8250/8250_dw.c +++ b/drivers/tty/serial/8250/8250_dw.c @@ -513,7 +513,8 @@ static int dw8250_probe(struct platform_ /* If no clock rate is defined, fail. */ if (!p->uartclk) { dev_err(dev, "clock rate not defined\n"); - return -EINVAL; + err = -EINVAL; + goto err_clk; } data->pclk = devm_clk_get(dev, "apb_pclk"); Patches currently in stable-queue which might be from Stefan.Potyra(a)elektrobit.com are queue-4.14/serial-8250_dw-disable-clock-on-error.patch

7 years, 6 months

1
0
0 0

Patch "scsi: lpfc: Fix SCSI LUN discovery when SCSI and NVME enabled" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled scsi: lpfc: Fix SCSI LUN discovery when SCSI and NVME enabled to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: scsi-lpfc-fix-scsi-lun-discovery-when-scsi-and-nvme-enabled.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Thu Mar 22 14:26:48 CET 2018 From: James Smart <jsmart2021(a)gmail.com> Date: Fri, 8 Dec 2017 17:18:07 -0800 Subject: scsi: lpfc: Fix SCSI LUN discovery when SCSI and NVME enabled From: James Smart <jsmart2021(a)gmail.com> [ Upstream commit 9de416ac67b54d666327ba927a190f4b7259f4a0 ] When enabled for both SCSI and NVME support, and connected pt2pt to a SCSI only target, the driver nodelist entry for the remote port is left in PRLI_ISSUE state and no SCSI LUNs are discovered. Works fine if only configured for SCSI support. Error was due to some of the prli points still reflecting the need to send only 1 PRLI. On a lot of fabric configs, targets were NVME only, which meant the fabric-reported protocol attributes were only telling the driver one protocol or the other. Thus things worked fine. With pt2pt, the driver must send a PRLI for both protocols as there are no hints on what the target supports. Thus pt2pt targets were hitting the multiple PRLI issues. Complete the dual PRLI support. Track explicitly whether scsi (fcp) or nvme prli's have been sent. Accurately track protocol support detected on each node as reported by the fabric or probed by PRLI traffic. Signed-off-by: Dick Kennedy <dick.kennedy(a)broadcom.com> Signed-off-by: James Smart <james.smart(a)broadcom.com> Reviewed-by: Hannes Reinecke <hare(a)suse.com> Signed-off-by: Martin K. Petersen <martin.petersen(a)oracle.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/scsi/lpfc/lpfc_ct.c | 1 + drivers/scsi/lpfc/lpfc_els.c | 30 ++++++++++++++++++++---------- drivers/scsi/lpfc/lpfc_nportdisc.c | 30 +++++++++++++----------------- 3 files changed, 34 insertions(+), 27 deletions(-) --- a/drivers/scsi/lpfc/lpfc_ct.c +++ b/drivers/scsi/lpfc/lpfc_ct.c @@ -471,6 +471,7 @@ lpfc_prep_node_fc4type(struct lpfc_vport "Parse GID_FTrsp: did:x%x flg:x%x x%x", Did, ndlp->nlp_flag, vport->fc_flag); + ndlp->nlp_fc4_type &= ~(NLP_FC4_FCP | NLP_FC4_NVME); /* By default, the driver expects to support FCP FC4 */ if (fc4_type == FC_TYPE_FCP) ndlp->nlp_fc4_type |= NLP_FC4_FCP; --- a/drivers/scsi/lpfc/lpfc_els.c +++ b/drivers/scsi/lpfc/lpfc_els.c @@ -2088,6 +2088,10 @@ lpfc_cmpl_els_prli(struct lpfc_hba *phba ndlp = (struct lpfc_nodelist *) cmdiocb->context1; spin_lock_irq(shost->host_lock); ndlp->nlp_flag &= ~NLP_PRLI_SND; + + /* Driver supports multiple FC4 types. Counters matter. */ + vport->fc_prli_sent--; + ndlp->fc4_prli_sent--; spin_unlock_irq(shost->host_lock); lpfc_debugfs_disc_trc(vport, LPFC_DISC_TRC_ELS_CMD, @@ -2095,9 +2099,6 @@ lpfc_cmpl_els_prli(struct lpfc_hba *phba irsp->ulpStatus, irsp->un.ulpWord[4], ndlp->nlp_DID); - /* Ddriver supports multiple FC4 types. Counters matter. */ - vport->fc_prli_sent--; - /* PRLI completes to NPort <nlp_DID> */ lpfc_printf_vlog(vport, KERN_INFO, LOG_ELS, "0103 PRLI completes to NPort x%06x " @@ -2111,7 +2112,6 @@ lpfc_cmpl_els_prli(struct lpfc_hba *phba if (irsp->ulpStatus) { /* Check for retry */ - ndlp->fc4_prli_sent--; if (lpfc_els_retry(phba, cmdiocb, rspiocb)) { /* ELS command is being retried */ goto out; @@ -2190,6 +2190,15 @@ lpfc_issue_els_prli(struct lpfc_vport *v ndlp->nlp_fc4_type |= NLP_FC4_NVME; local_nlp_type = ndlp->nlp_fc4_type; + /* This routine will issue 1 or 2 PRLIs, so zero all the ndlp + * fields here before any of them can complete. + */ + ndlp->nlp_type &= ~(NLP_FCP_TARGET | NLP_FCP_INITIATOR); + ndlp->nlp_type &= ~(NLP_NVME_TARGET | NLP_NVME_INITIATOR); + ndlp->nlp_fcp_info &= ~NLP_FCP_2_DEVICE; + ndlp->nlp_flag &= ~NLP_FIRSTBURST; + ndlp->nvme_fb_size = 0; + send_next_prli: if (local_nlp_type & NLP_FC4_FCP) { /* Payload is 4 + 16 = 20 x14 bytes. */ @@ -2298,6 +2307,13 @@ lpfc_issue_els_prli(struct lpfc_vport *v elsiocb->iocb_cmpl = lpfc_cmpl_els_prli; spin_lock_irq(shost->host_lock); ndlp->nlp_flag |= NLP_PRLI_SND; + + /* The vport counters are used for lpfc_scan_finished, but + * the ndlp is used to track outstanding PRLIs for different + * FC4 types. + */ + vport->fc_prli_sent++; + ndlp->fc4_prli_sent++; spin_unlock_irq(shost->host_lock); if (lpfc_sli_issue_iocb(phba, LPFC_ELS_RING, elsiocb, 0) == IOCB_ERROR) { @@ -2308,12 +2324,6 @@ lpfc_issue_els_prli(struct lpfc_vport *v return 1; } - /* The vport counters are used for lpfc_scan_finished, but - * the ndlp is used to track outstanding PRLIs for different - * FC4 types. - */ - vport->fc_prli_sent++; - ndlp->fc4_prli_sent++; /* The driver supports 2 FC4 types. Make sure * a PRLI is issued for all types before exiting. --- a/drivers/scsi/lpfc/lpfc_nportdisc.c +++ b/drivers/scsi/lpfc/lpfc_nportdisc.c @@ -390,6 +390,11 @@ lpfc_rcv_plogi(struct lpfc_vport *vport, break; } + ndlp->nlp_type &= ~(NLP_FCP_TARGET | NLP_FCP_INITIATOR); + ndlp->nlp_type &= ~(NLP_NVME_TARGET | NLP_NVME_INITIATOR); + ndlp->nlp_fcp_info &= ~NLP_FCP_2_DEVICE; + ndlp->nlp_flag &= ~NLP_FIRSTBURST; + /* Check for Nport to NPort pt2pt protocol */ if ((vport->fc_flag & FC_PT2PT) && !(vport->fc_flag & FC_PT2PT_PLOGI)) { @@ -742,9 +747,6 @@ lpfc_rcv_prli(struct lpfc_vport *vport, lp = (uint32_t *) pcmd->virt; npr = (PRLI *) ((uint8_t *) lp + sizeof (uint32_t)); - ndlp->nlp_type &= ~(NLP_FCP_TARGET | NLP_FCP_INITIATOR); - ndlp->nlp_fcp_info &= ~NLP_FCP_2_DEVICE; - ndlp->nlp_flag &= ~NLP_FIRSTBURST; if ((npr->prliType == PRLI_FCP_TYPE) || (npr->prliType == PRLI_NVME_TYPE)) { if (npr->initiatorFunc) { @@ -769,8 +771,12 @@ lpfc_rcv_prli(struct lpfc_vport *vport, * type. Target mode does not issue gft_id so doesn't get * the fc4 type set until now. */ - if ((phba->nvmet_support) && (npr->prliType == PRLI_NVME_TYPE)) + if (phba->nvmet_support && (npr->prliType == PRLI_NVME_TYPE)) { ndlp->nlp_fc4_type |= NLP_FC4_NVME; + lpfc_nlp_set_state(vport, ndlp, NLP_STE_UNMAPPED_NODE); + } + if (npr->prliType == PRLI_FCP_TYPE) + ndlp->nlp_fc4_type |= NLP_FC4_FCP; } if (rport) { /* We need to update the rport role values */ @@ -1552,7 +1558,6 @@ lpfc_rcv_prli_reglogin_issue(struct lpfc if (ndlp->nlp_flag & NLP_RPI_REGISTERED) { lpfc_rcv_prli(vport, ndlp, cmdiocb); lpfc_els_rsp_prli_acc(vport, cmdiocb, ndlp); - lpfc_nlp_set_state(vport, ndlp, NLP_STE_UNMAPPED_NODE); } else { /* RPI registration has not completed. Reject the PRLI * to prevent an illegal state transition when the @@ -1568,6 +1573,7 @@ lpfc_rcv_prli_reglogin_issue(struct lpfc stat.un.b.lsRjtRsnCodeExp = LSEXP_CMD_IN_PROGRESS; lpfc_els_rsp_reject(vport, stat.un.lsRjtError, cmdiocb, ndlp, NULL); + return ndlp->nlp_state; } } else { /* Initiator mode. */ @@ -1922,13 +1928,6 @@ lpfc_cmpl_prli_prli_issue(struct lpfc_vp return ndlp->nlp_state; } - /* Check out PRLI rsp */ - ndlp->nlp_type &= ~(NLP_FCP_TARGET | NLP_FCP_INITIATOR); - ndlp->nlp_fcp_info &= ~NLP_FCP_2_DEVICE; - - /* NVME or FCP first burst must be negotiated for each PRLI. */ - ndlp->nlp_flag &= ~NLP_FIRSTBURST; - ndlp->nvme_fb_size = 0; if (npr && (npr->acceptRspCode == PRLI_REQ_EXECUTED) && (npr->prliType == PRLI_FCP_TYPE)) { lpfc_printf_vlog(vport, KERN_INFO, LOG_NVME_DISC, @@ -1945,8 +1944,6 @@ lpfc_cmpl_prli_prli_issue(struct lpfc_vp if (npr->Retry) ndlp->nlp_fcp_info |= NLP_FCP_2_DEVICE; - /* PRLI completed. Decrement count. */ - ndlp->fc4_prli_sent--; } else if (nvpr && (bf_get_be32(prli_acc_rsp_code, nvpr) == PRLI_REQ_EXECUTED) && @@ -1991,8 +1988,6 @@ lpfc_cmpl_prli_prli_issue(struct lpfc_vp be32_to_cpu(nvpr->word5), ndlp->nlp_flag, ndlp->nlp_fcp_info, ndlp->nlp_type); - /* PRLI completed. Decrement count. */ - ndlp->fc4_prli_sent--; } if (!(ndlp->nlp_type & NLP_FCP_TARGET) && (vport->port_type == LPFC_NPIV_PORT) && @@ -2016,7 +2011,8 @@ out_err: ndlp->nlp_prev_state = NLP_STE_PRLI_ISSUE; if (ndlp->nlp_type & (NLP_FCP_TARGET | NLP_NVME_TARGET)) lpfc_nlp_set_state(vport, ndlp, NLP_STE_MAPPED_NODE); - else + else if (ndlp->nlp_type & + (NLP_FCP_INITIATOR | NLP_NVME_INITIATOR)) lpfc_nlp_set_state(vport, ndlp, NLP_STE_UNMAPPED_NODE); } else lpfc_printf_vlog(vport, Patches currently in stable-queue which might be from jsmart2021(a)gmail.com are queue-4.14/scsi-lpfc-fix-scsi-lun-discovery-when-scsi-and-nvme-enabled.patch queue-4.14/scsi-lpfc-fix-issues-connecting-with-nvme-initiator.patch

7 years, 6 months

1
0
0 0

Patch "scsi: lpfc: Fix issues connecting with nvme initiator" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled scsi: lpfc: Fix issues connecting with nvme initiator to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: scsi-lpfc-fix-issues-connecting-with-nvme-initiator.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Thu Mar 22 14:26:48 CET 2018 From: James Smart <jsmart2021(a)gmail.com> Date: Fri, 8 Dec 2017 17:18:08 -0800 Subject: scsi: lpfc: Fix issues connecting with nvme initiator From: James Smart <jsmart2021(a)gmail.com> [ Upstream commit e06351a002214d152142906a546006e3446d1ef7 ] In the lpfc discovery engine, when as a nvme target, where the driver was performing mailbox io with the adapter for port login when a NVME PRLI is received from the host. Rather than queue and eventually get back to sending a response after the mailbox traffic, the driver rejected the io with an error response. Turns out this particular initiator didn't like the rejection values (unable to process command/command in progress) so it never attempted a retry of the PRLI. Thus the host never established nvme connectivity with the lpfc target. By changing the rejection values (to Logical Busy/nothing more), the initiator accepted the response and would retry the PRLI, resulting in nvme connectivity. Signed-off-by: Dick Kennedy <dick.kennedy(a)broadcom.com> Signed-off-by: James Smart <james.smart(a)broadcom.com> Reviewed-by: Hannes Reinecke <hare(a)suse.com> Signed-off-by: Martin K. Petersen <martin.petersen(a)oracle.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/scsi/lpfc/lpfc_nportdisc.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) --- a/drivers/scsi/lpfc/lpfc_nportdisc.c +++ b/drivers/scsi/lpfc/lpfc_nportdisc.c @@ -1569,8 +1569,8 @@ lpfc_rcv_prli_reglogin_issue(struct lpfc ndlp->nlp_rpi, ndlp->nlp_state, ndlp->nlp_flag); memset(&stat, 0, sizeof(struct ls_rjt)); - stat.un.b.lsRjtRsnCode = LSRJT_UNABLE_TPC; - stat.un.b.lsRjtRsnCodeExp = LSEXP_CMD_IN_PROGRESS; + stat.un.b.lsRjtRsnCode = LSRJT_LOGICAL_BSY; + stat.un.b.lsRjtRsnCodeExp = LSEXP_NOTHING_MORE; lpfc_els_rsp_reject(vport, stat.un.lsRjtError, cmdiocb, ndlp, NULL); return ndlp->nlp_state; Patches currently in stable-queue which might be from jsmart2021(a)gmail.com are queue-4.14/scsi-lpfc-fix-scsi-lun-discovery-when-scsi-and-nvme-enabled.patch queue-4.14/scsi-lpfc-fix-issues-connecting-with-nvme-initiator.patch

7 years, 6 months

1
0
0 0

Patch "rtlwifi: rtl_pci: Fix the bug when inactiveps is enabled." has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled rtlwifi: rtl_pci: Fix the bug when inactiveps is enabled. to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: rtlwifi-rtl_pci-fix-the-bug-when-inactiveps-is-enabled.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Thu Mar 22 14:26:48 CET 2018 From: Tsang-Shian Lin <thlin(a)realtek.com> Date: Sat, 9 Dec 2017 11:37:10 -0600 Subject: rtlwifi: rtl_pci: Fix the bug when inactiveps is enabled. From: Tsang-Shian Lin <thlin(a)realtek.com> [ Upstream commit b7573a0a27bfa8270dea9b145448f6884b7cacc1 ] Reset the driver current tx read/write index to zero when inactiveps nic out of sync with HW state. Wrong driver tx read/write index will cause Tx fail. Signed-off-by: Tsang-Shian Lin <thlin(a)realtek.com> Signed-off-by: Ping-Ke Shih <pkshih(a)realtek.com> Signed-off-by: Larry Finger <Larry.Finger(a)lwfinger.net> Cc: Yan-Hsuan Chuang <yhchuang(a)realtek.com> Cc: Birming Chiu <birming(a)realtek.com> Cc: Shaofu <shaofu(a)realtek.com> Cc: Steven Ting <steventing(a)realtek.com> Signed-off-by: Kalle Valo <kvalo(a)codeaurora.org> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/net/wireless/realtek/rtlwifi/pci.c | 7 +++++++ 1 file changed, 7 insertions(+) --- a/drivers/net/wireless/realtek/rtlwifi/pci.c +++ b/drivers/net/wireless/realtek/rtlwifi/pci.c @@ -1568,7 +1568,14 @@ int rtl_pci_reset_trx_ring(struct ieee80 dev_kfree_skb_irq(skb); ring->idx = (ring->idx + 1) % ring->entries; } + + if (rtlpriv->use_new_trx_flow) { + rtlpci->tx_ring[i].cur_tx_rp = 0; + rtlpci->tx_ring[i].cur_tx_wp = 0; + } + ring->idx = 0; + ring->entries = rtlpci->txringcount[i]; } } spin_unlock_irqrestore(&rtlpriv->locks.irq_th_lock, flags); Patches currently in stable-queue which might be from thlin(a)realtek.com are queue-4.14/rtlwifi-rtl_pci-fix-the-bug-when-inactiveps-is-enabled.patch

7 years, 6 months

1
0
0 0

Patch "rtlwifi: always initialize variables given to RT_TRACE()" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled rtlwifi: always initialize variables given to RT_TRACE() to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: rtlwifi-always-initialize-variables-given-to-rt_trace.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Thu Mar 22 14:26:48 CET 2018 From: Nicolas Iooss <nicolas.iooss_linux(a)m4x.org> Date: Sun, 10 Dec 2017 20:51:59 +0100 Subject: rtlwifi: always initialize variables given to RT_TRACE() From: Nicolas Iooss <nicolas.iooss_linux(a)m4x.org> [ Upstream commit e4779162f7377baa9fb9a044555ecaae22c3f125 ] In rtl_rx_ampdu_apply(), when rtlpriv->cfg->ops->get_btc_status() returns false, RT_TRACE() is called with the values of variables reject_agg and agg_size, which have not been initialized. Always initialize these variables in order to prevent using uninitialized values. This issue has been found with clang. The compiler reported: drivers/net/wireless/realtek/rtlwifi/base.c:1665:6: error: variable 'agg_size' is used uninitialized whenever 'if' condition is false [-Werror,-Wsometimes-uninitialized] if (rtlpriv->cfg->ops->get_btc_status()) ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ drivers/net/wireless/realtek/rtlwifi/base.c:1671:31: note: uninitialized use occurs here reject_agg, ctrl_agg_size, agg_size); ^~~~~~~~ drivers/net/wireless/realtek/rtlwifi/base.c:1665:6: error: variable 'reject_agg' is used uninitialized whenever 'if' condition is false [-Werror,-Wsometimes-uninitialized] if (rtlpriv->cfg->ops->get_btc_status()) ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ drivers/net/wireless/realtek/rtlwifi/base.c:1671:4: note: uninitialized use occurs here reject_agg, ctrl_agg_size, agg_size); ^~~~~~~~~~ Fixes: 2635664e6e4a ("rtlwifi: Add rx ampdu cfg for btcoexist.") Signed-off-by: Nicolas Iooss <nicolas.iooss_linux(a)m4x.org> Signed-off-by: Kalle Valo <kvalo(a)codeaurora.org> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/net/wireless/realtek/rtlwifi/base.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/drivers/net/wireless/realtek/rtlwifi/base.c +++ b/drivers/net/wireless/realtek/rtlwifi/base.c @@ -1664,7 +1664,7 @@ int rtl_tx_agg_oper(struct ieee80211_hw void rtl_rx_ampdu_apply(struct rtl_priv *rtlpriv) { struct rtl_btc_ops *btc_ops = rtlpriv->btcoexist.btc_ops; - u8 reject_agg, ctrl_agg_size = 0, agg_size; + u8 reject_agg = 0, ctrl_agg_size = 0, agg_size = 0; if (rtlpriv->cfg->ops->get_btc_status()) btc_ops->btc_get_ampdu_cfg(rtlpriv, &reject_agg, Patches currently in stable-queue which might be from nicolas.iooss_linux(a)m4x.org are queue-4.14/rtlwifi-always-initialize-variables-given-to-rt_trace.patch

7 years, 6 months

1
0
0 0

Patch "rtc: ac100: Fix multiple race conditions" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled rtc: ac100: Fix multiple race conditions to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: rtc-ac100-fix-multiple-race-conditions.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Thu Mar 22 14:26:48 CET 2018 From: Alexandre Belloni <alexandre.belloni(a)free-electrons.com> Date: Mon, 4 Dec 2017 14:58:33 +0100 Subject: rtc: ac100: Fix multiple race conditions From: Alexandre Belloni <alexandre.belloni(a)free-electrons.com> [ Upstream commit 994ec64c0a193940be7a6fd074668b9446d3b6c3 ] The probe function is not allowed to fail after registering the RTC because the following may happen: CPU0: CPU1: sys_load_module() do_init_module() do_one_initcall() cmos_do_probe() rtc_device_register() __register_chrdev() cdev->owner = struct module* open("/dev/rtc0") rtc_device_unregister() module_put() free_module() module_free(mod->module_core) /* struct module *module is now freed */ chrdev_open() spin_lock(cdev_lock) cdev_get() try_module_get() module_is_live() /* dereferences already freed struct module* */ Also, the interrupt handler: ac100_rtc_irq() is dereferencing chip->rtc but this may still be NULL when it is called, resulting in: Unable to handle kernel NULL pointer dereference at virtual address 00000194 pgd = (ptrval) [00000194] *pgd=00000000 Internal error: Oops: 5 [#1] SMP ARM Modules linked in: CPU: 0 PID: 72 Comm: irq/71-ac100-rt Not tainted 4.15.0-rc1-next-20171201-dirty #120 Hardware name: Allwinner sun8i Family task: (ptrval) task.stack: (ptrval) PC is at mutex_lock+0x14/0x3c LR is at ac100_rtc_irq+0x38/0xc8 pc : [<c06543a4>] lr : [<c04d9a2c>] psr: 60000053 sp : ee9c9f28 ip : 00000000 fp : ee9adfdc r10: 00000000 r9 : c0a04c48 r8 : c015ed18 r7 : ee9bd600 r6 : ee9c9f28 r5 : ee9af590 r4 : c0a04c48 r3 : ef3cb3c0 r2 : 00000000 r1 : ee9af590 r0 : 00000194 Flags: nZCv IRQs on FIQs off Mode SVC_32 ISA ARM Segment none Control: 10c5387d Table: 4000406a DAC: 00000051 Process irq/71-ac100-rt (pid: 72, stack limit = 0x(ptrval)) Stack: (0xee9c9f28 to 0xee9ca000) 9f20: 00000000 7c2fd1be c015ed18 ee9adf40 ee9c0400 ee9c0400 9f40: ee9adf40 c015ed34 ee9c8000 ee9adf64 ee9c0400 c015f040 ee9adf80 00000000 9f60: c015ee24 7c2fd1be ee9adfc0 ee9adf80 00000000 ee9c8000 ee9adf40 c015eef4 9f80: ef1eba34 c0138f14 ee9c8000 ee9adf80 c0138df4 00000000 00000000 00000000 9fa0: 00000000 00000000 00000000 c01010e8 00000000 00000000 00000000 00000000 9fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 9fe0: 00000000 00000000 00000000 00000000 00000013 00000000 ffffffff ffffffff [<c06543a4>] (mutex_lock) from [<c04d9a2c>] (ac100_rtc_irq+0x38/0xc8) [<c04d9a2c>] (ac100_rtc_irq) from [<c015ed34>] (irq_thread_fn+0x1c/0x54) [<c015ed34>] (irq_thread_fn) from [<c015f040>] (irq_thread+0x14c/0x214) [<c015f040>] (irq_thread) from [<c0138f14>] (kthread+0x120/0x150) [<c0138f14>] (kthread) from [<c01010e8>] (ret_from_fork+0x14/0x2c) Solve both issues by moving to devm_rtc_allocate_device()/rtc_register_device() Reported-by: Quentin Schulz <quentin.schulz(a)free-electrons.com> Tested-by: Quentin Schulz <quentin.schulz(a)free-electrons.com> Signed-off-by: Alexandre Belloni <alexandre.belloni(a)free-electrons.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/rtc/rtc-ac100.c | 19 ++++++++++++------- 1 file changed, 12 insertions(+), 7 deletions(-) --- a/drivers/rtc/rtc-ac100.c +++ b/drivers/rtc/rtc-ac100.c @@ -567,6 +567,12 @@ static int ac100_rtc_probe(struct platfo return chip->irq; } + chip->rtc = devm_rtc_allocate_device(&pdev->dev); + if (IS_ERR(chip->rtc)) + return PTR_ERR(chip->rtc); + + chip->rtc->ops = &ac100_rtc_ops; + ret = devm_request_threaded_irq(&pdev->dev, chip->irq, NULL, ac100_rtc_irq, IRQF_SHARED | IRQF_ONESHOT, @@ -586,17 +592,16 @@ static int ac100_rtc_probe(struct platfo /* clear counter alarm pending interrupts */ regmap_write(chip->regmap, AC100_ALM_INT_STA, AC100_ALM_INT_ENABLE); - chip->rtc = devm_rtc_device_register(&pdev->dev, "rtc-ac100", - &ac100_rtc_ops, THIS_MODULE); - if (IS_ERR(chip->rtc)) { - dev_err(&pdev->dev, "unable to register device\n"); - return PTR_ERR(chip->rtc); - } - ret = ac100_rtc_register_clks(chip); if (ret) return ret; + ret = rtc_register_device(chip->rtc); + if (ret) { + dev_err(&pdev->dev, "unable to register device\n"); + return ret; + } + dev_info(&pdev->dev, "RTC enabled\n"); return 0; Patches currently in stable-queue which might be from alexandre.belloni(a)free-electrons.com are queue-4.14/clk-at91-pmc-wait-for-clocks-when-resuming.patch queue-4.14/rtc-ac100-fix-multiple-race-conditions.patch

7 years, 6 months

1
0
0 0

Patch "RDMA/ocrdma: Fix permissions for OCRDMA_RESET_STATS" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled RDMA/ocrdma: Fix permissions for OCRDMA_RESET_STATS to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: rdma-ocrdma-fix-permissions-for-ocrdma_reset_stats.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Thu Mar 22 14:26:48 CET 2018 From: Anton Vasilyev <vasilyev(a)ispras.ru> Date: Tue, 8 Aug 2017 18:56:37 +0300 Subject: RDMA/ocrdma: Fix permissions for OCRDMA_RESET_STATS From: Anton Vasilyev <vasilyev(a)ispras.ru> [ Upstream commit 744820869166c8c78be891240cf5f66e8a333694 ] Debugfs file reset_stats is created with S_IRUSR permissions, but ocrdma_dbgfs_ops_read() doesn't support OCRDMA_RESET_STATS, whereas ocrdma_dbgfs_ops_write() supports only OCRDMA_RESET_STATS. The patch fixes misstype with permissions. Found by Linux Driver Verification project (linuxtesting.org). Signed-off-by: Anton Vasilyev <vasilyev(a)ispras.ru> Acked-by: Selvin Xavier <selvin.xavier(a)broadcom.com> Signed-off-by: Jason Gunthorpe <jgg(a)mellanox.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/infiniband/hw/ocrdma/ocrdma_stats.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/drivers/infiniband/hw/ocrdma/ocrdma_stats.c +++ b/drivers/infiniband/hw/ocrdma/ocrdma_stats.c @@ -834,7 +834,7 @@ void ocrdma_add_port_stats(struct ocrdma dev->reset_stats.type = OCRDMA_RESET_STATS; dev->reset_stats.dev = dev; - if (!debugfs_create_file("reset_stats", S_IRUSR, dev->dir, + if (!debugfs_create_file("reset_stats", 0200, dev->dir, &dev->reset_stats, &ocrdma_dbg_ops)) goto err; Patches currently in stable-queue which might be from vasilyev(a)ispras.ru are queue-4.14/rdma-ocrdma-fix-permissions-for-ocrdma_reset_stats.patch

7 years, 6 months

1
0
0 0

Patch "RDMA/iwpm: Fix uninitialized error code in iwpm_send_mapinfo()" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled RDMA/iwpm: Fix uninitialized error code in iwpm_send_mapinfo() to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: rdma-iwpm-fix-uninitialized-error-code-in-iwpm_send_mapinfo.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Thu Mar 22 14:26:48 CET 2018 From: Geert Uytterhoeven <geert(a)linux-m68k.org> Date: Wed, 29 Nov 2017 09:47:33 +0100 Subject: RDMA/iwpm: Fix uninitialized error code in iwpm_send_mapinfo() From: Geert Uytterhoeven <geert(a)linux-m68k.org> [ Upstream commit 302d6424e4a293a5761997e6c9fc3dfb1e4c355f ] With gcc-4.1.2: drivers/infiniband/core/iwpm_util.c: In function ‘iwpm_send_mapinfo’: drivers/infiniband/core/iwpm_util.c:647: warning: ‘ret’ may be used uninitialized in this function Indeed, if nl_client is not found in any of the scanned has buckets, ret will be used uninitialized. Preinitialize ret to -EINVAL to fix this. Fixes: 30dc5e63d6a5ad24 ("RDMA/core: Add support for iWARP Port Mapper user space service") Signed-off-by: Geert Uytterhoeven <geert(a)linux-m68k.org> Reviewed-by: Tatyana Nikolova <tatyana.e.nikolova(a)intel.com> Signed-off-by: Jason Gunthorpe <jgg(a)mellanox.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/infiniband/core/iwpm_util.c | 1 + 1 file changed, 1 insertion(+) --- a/drivers/infiniband/core/iwpm_util.c +++ b/drivers/infiniband/core/iwpm_util.c @@ -654,6 +654,7 @@ int iwpm_send_mapinfo(u8 nl_client, int } skb_num++; spin_lock_irqsave(&iwpm_mapinfo_lock, flags); + ret = -EINVAL; for (i = 0; i < IWPM_MAPINFO_HASH_SIZE; i++) { hlist_for_each_entry(map_info, &iwpm_hash_bucket[i], hlist_node) { Patches currently in stable-queue which might be from geert(a)linux-m68k.org are queue-4.14/rdma-iwpm-fix-uninitialized-error-code-in-iwpm_send_mapinfo.patch

7 years, 6 months

1
0
0 0

Patch "RDMA/cma: Use correct size when writing netlink stats" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled RDMA/cma: Use correct size when writing netlink stats to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: rdma-cma-use-correct-size-when-writing-netlink-stats.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Thu Mar 22 14:26:48 CET 2018 From: Parav Pandit <parav(a)mellanox.com> Date: Tue, 14 Nov 2017 14:51:55 +0200 Subject: RDMA/cma: Use correct size when writing netlink stats From: Parav Pandit <parav(a)mellanox.com> [ Upstream commit 7baaa49af3716fb31877c61f59b74d029ce15b75 ] The code was using the src size when formatting the dst. They are almost certainly the same value but it reads wrong. Fixes: ce117ffac2e9 ("RDMA/cma: Export AF_IB statistics") Signed-off-by: Parav Pandit <parav(a)mellanox.com> Reviewed-by: Daniel Jurgens <danielj(a)mellanox.com> Signed-off-by: Leon Romanovsky <leon(a)kernel.org> Signed-off-by: Jason Gunthorpe <jgg(a)mellanox.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/infiniband/core/cma.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/drivers/infiniband/core/cma.c +++ b/drivers/infiniband/core/cma.c @@ -4436,7 +4436,7 @@ static int cma_get_id_stats(struct sk_bu RDMA_NL_RDMA_CM_ATTR_SRC_ADDR)) goto out; if (ibnl_put_attr(skb, nlh, - rdma_addr_size(cma_src_addr(id_priv)), + rdma_addr_size(cma_dst_addr(id_priv)), cma_dst_addr(id_priv), RDMA_NL_RDMA_CM_ATTR_DST_ADDR)) goto out; Patches currently in stable-queue which might be from parav(a)mellanox.com are queue-4.14/rdma-cma-use-correct-size-when-writing-netlink-stats.patch

7 years, 6 months

1
0
0 0

Patch "qmi_wwan: set FLAG_SEND_ZLP to avoid network initiated disconnect" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled qmi_wwan: set FLAG_SEND_ZLP to avoid network initiated disconnect to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: qmi_wwan-set-flag_send_zlp-to-avoid-network-initiated-disconnect.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Thu Mar 22 14:26:48 CET 2018 From: "Bjørn Mork" <bjorn(a)mork.no> Date: Thu, 14 Dec 2017 19:55:50 +0100 Subject: qmi_wwan: set FLAG_SEND_ZLP to avoid network initiated disconnect From: "Bjørn Mork" <bjorn(a)mork.no> [ Upstream commit 245d21190aec547c0de64f70c0e6de871c185a24 ] It has been reported that the dummy byte we add to avoid ZLPs can be forwarded by the modem to the PGW/GGSN, and that some operators will drop the connection if this happens. In theory, QMI devices are based on CDC ECM and should as such both support ZLPs and silently ignore the dummy byte. The latter assumption failed. Let's test out the first. Signed-off-by: BjÃ¸rn Mork <bjorn(a)mork.no> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/net/usb/qmi_wwan.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) --- a/drivers/net/usb/qmi_wwan.c +++ b/drivers/net/usb/qmi_wwan.c @@ -826,7 +826,7 @@ err: static const struct driver_info qmi_wwan_info = { .description = "WWAN/QMI device", - .flags = FLAG_WWAN, + .flags = FLAG_WWAN | FLAG_SEND_ZLP, .bind = qmi_wwan_bind, .unbind = qmi_wwan_unbind, .manage_power = qmi_wwan_manage_power, @@ -835,7 +835,7 @@ static const struct driver_info qmi_wwan static const struct driver_info qmi_wwan_info_quirk_dtr = { .description = "WWAN/QMI device", - .flags = FLAG_WWAN, + .flags = FLAG_WWAN | FLAG_SEND_ZLP, .bind = qmi_wwan_bind, .unbind = qmi_wwan_unbind, .manage_power = qmi_wwan_manage_power, Patches currently in stable-queue which might be from bjorn(a)mork.no are queue-4.14/qmi_wwan-set-flag_send_zlp-to-avoid-network-initiated-disconnect.patch

7 years, 6 months

1
0
0 0

Patch "pty: cancel pty slave port buf's work in tty_release" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled pty: cancel pty slave port buf's work in tty_release to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: pty-cancel-pty-slave-port-buf-s-work-in-tty_release.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Thu Mar 22 14:26:48 CET 2018 From: Sahara <keun-o.park(a)darkmatter.ae> Date: Wed, 13 Dec 2017 09:10:48 +0400 Subject: pty: cancel pty slave port buf's work in tty_release From: Sahara <keun-o.park(a)darkmatter.ae> [ Upstream commit 2b022ab7542df60021ab57854b3faaaf42552eaf ] In case that CONFIG_SLUB_DEBUG is on and pty is used, races between release_one_tty and flush_to_ldisc work threads may happen and lead to use-after-free condition on tty->link->port. Because SLUB_DEBUG is turned on, freed tty->link->port is filled with POISON_FREE value. So far without SLUB_DEBUG, port was filled with zero and flush_to_ldisc could return without a problem by checking if tty is NULL. CPU 0 CPU 1 ----- ----- release_tty pty_write cancel_work_sync(tty) to = tty->link tty_kref_put(tty->link) tty_schedule_flip(to->port) << workqueue >> ... release_one_tty ... pty_cleanup ... kfree(tty->link->port) << workqueue >> flush_to_ldisc tty = READ_ONCE(port->itty) tty is 0x6b6b6b6b6b6b6b6b !!PANIC!! access tty->ldisc Unable to handle kernel paging request at virtual address 6b6b6b6b6b6b6b93 pgd = ffffffc0eb1c3000 [6b6b6b6b6b6b6b93] *pgd=0000000000000000, *pud=0000000000000000 ------------[ cut here ]------------ Kernel BUG at ffffff800851154c [verbose debug info unavailable] Internal error: Oops - BUG: 96000004 [#1] PREEMPT SMP CPU: 3 PID: 265 Comm: kworker/u8:9 Tainted: G W 3.18.31-g0a58eeb #1 Hardware name: Qualcomm Technologies, Inc. MSM 8996pro v1.1 + PMI8996 Carbide (DT) Workqueue: events_unbound flush_to_ldisc task: ffffffc0ed610ec0 ti: ffffffc0ed624000 task.ti: ffffffc0ed624000 PC is at ldsem_down_read_trylock+0x0/0x4c LR is at tty_ldisc_ref+0x24/0x4c pc : [<ffffff800851154c>] lr : [<ffffff800850f6c0>] pstate: 80400145 sp : ffffffc0ed627cd0 x29: ffffffc0ed627cd0 x28: 0000000000000000 x27: ffffff8009e05000 x26: ffffffc0d382cfa0 x25: 0000000000000000 x24: ffffff800a012f08 x23: 0000000000000000 x22: ffffffc0703fbc88 x21: 6b6b6b6b6b6b6b6b x20: 6b6b6b6b6b6b6b93 x19: 0000000000000000 x18: 0000000000000001 x17: 00e80000f80d6f53 x16: 0000000000000001 x15: 0000007f7d826fff x14: 00000000000000a0 x13: 0000000000000000 x12: 0000000000000109 x11: 0000000000000000 x10: 0000000000000000 x9 : ffffffc0ed624000 x8 : ffffffc0ed611580 x7 : 0000000000000000 x6 : ffffff800a42e000 x5 : 00000000000003fc x4 : 0000000003bd1201 x3 : 0000000000000001 x2 : 0000000000000001 x1 : ffffff800851004c x0 : 6b6b6b6b6b6b6b93 Signed-off-by: Sahara <keun-o.park(a)darkmatter.ae> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/tty/tty_io.c | 2 ++ 1 file changed, 2 insertions(+) --- a/drivers/tty/tty_io.c +++ b/drivers/tty/tty_io.c @@ -1481,6 +1481,8 @@ static void release_tty(struct tty_struc if (tty->link) tty->link->port->itty = NULL; tty_buffer_cancel_work(tty->port); + if (tty->link) + tty_buffer_cancel_work(tty->link->port); tty_kref_put(tty->link); tty_kref_put(tty); Patches currently in stable-queue which might be from keun-o.park(a)darkmatter.ae are queue-4.14/pty-cancel-pty-slave-port-buf-s-work-in-tty_release.patch

7 years, 6 months

1
0
0 0

Patch "platform/chrome: Use proper protocol transfer function" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled platform/chrome: Use proper protocol transfer function to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: platform-chrome-use-proper-protocol-transfer-function.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Thu Mar 22 14:26:48 CET 2018 From: Shawn Nematbakhsh <shawnn(a)chromium.org> Date: Fri, 8 Sep 2017 13:50:11 -0700 Subject: platform/chrome: Use proper protocol transfer function From: Shawn Nematbakhsh <shawnn(a)chromium.org> [ Upstream commit d48b8c58c57f6edbe2965f0a5f62c5cf9593ca96 ] pkt_xfer should be used for protocol v3, and cmd_xfer otherwise. We had one instance of these functions correct, but not the second, fall-back case. We use the fall-back only when the first command returns an IN_PROGRESS status, which is only used on some EC firmwares where we don't want to constantly poll the bus, but instead back off and sleep/retry for a little while. Fixes: 2c7589af3c4d ("mfd: cros_ec: add proto v3 skeleton") Signed-off-by: Shawn Nematbakhsh <shawnn(a)chromium.org> Signed-off-by: Brian Norris <briannorris(a)chromium.org> Reviewed-by: Javier Martinez Canillas <javier(a)osg.samsung.com> Signed-off-by: Benson Leung <bleung(a)chromium.org> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/platform/chrome/cros_ec_proto.c | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-) --- a/drivers/platform/chrome/cros_ec_proto.c +++ b/drivers/platform/chrome/cros_ec_proto.c @@ -60,12 +60,14 @@ static int send_command(struct cros_ec_d struct cros_ec_command *msg) { int ret; + int (*xfer_fxn)(struct cros_ec_device *ec, struct cros_ec_command *msg); if (ec_dev->proto_version > 2) - ret = ec_dev->pkt_xfer(ec_dev, msg); + xfer_fxn = ec_dev->pkt_xfer; else - ret = ec_dev->cmd_xfer(ec_dev, msg); + xfer_fxn = ec_dev->cmd_xfer; + ret = (*xfer_fxn)(ec_dev, msg); if (msg->result == EC_RES_IN_PROGRESS) { int i; struct cros_ec_command *status_msg; @@ -88,7 +90,7 @@ static int send_command(struct cros_ec_d for (i = 0; i < EC_COMMAND_RETRIES; i++) { usleep_range(10000, 11000); - ret = ec_dev->cmd_xfer(ec_dev, status_msg); + ret = (*xfer_fxn)(ec_dev, status_msg); if (ret < 0) break; Patches currently in stable-queue which might be from shawnn(a)chromium.org are queue-4.14/platform-chrome-use-proper-protocol-transfer-function.patch

7 years, 6 months

1
0
0 0

Patch "pinctrl: rockchip: enable clock when reading pin direction register" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled pinctrl: rockchip: enable clock when reading pin direction register to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: pinctrl-rockchip-enable-clock-when-reading-pin-direction-register.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Thu Mar 22 14:26:48 CET 2018 From: Brian Norris <briannorris(a)chromium.org> Date: Tue, 12 Dec 2017 09:43:43 -0800 Subject: pinctrl: rockchip: enable clock when reading pin direction register From: Brian Norris <briannorris(a)chromium.org> [ Upstream commit 5c9d8c4f6b8168738a26bcf288516cc3a0886810 ] We generally leave the GPIO clock disabled, unless an interrupt is requested or we're accessing IO registers. We forgot to do this for the ->get_direction() callback, which means we can sometimes [1] get incorrect results [2] from, e.g., /sys/kernel/debug/gpio. Enable the clock, so we get the right results! [1] Sometimes, because many systems have 1 or mor interrupt requested on each GPIO bank, so they always leave their clock on. [2] Incorrect, meaning the register returns 0, and so we interpret that as "input". Signed-off-by: Brian Norris <briannorris(a)chromium.org> Reviewed-by: Heiko Stuebner <heiko(a)sntech.de> Signed-off-by: Linus Walleij <linus.walleij(a)linaro.org> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/pinctrl/pinctrl-rockchip.c | 8 ++++++++ 1 file changed, 8 insertions(+) --- a/drivers/pinctrl/pinctrl-rockchip.c +++ b/drivers/pinctrl/pinctrl-rockchip.c @@ -1989,8 +1989,16 @@ static int rockchip_gpio_get_direction(s { struct rockchip_pin_bank *bank = gpiochip_get_data(chip); u32 data; + int ret; + ret = clk_enable(bank->clk); + if (ret < 0) { + dev_err(bank->drvdata->dev, + "failed to enable clock for bank %s\n", bank->name); + return ret; + } data = readl_relaxed(bank->reg_base + GPIO_SWPORT_DDR); + clk_disable(bank->clk); return !(data & BIT(offset)); } Patches currently in stable-queue which might be from briannorris(a)chromium.org are queue-4.14/pinctrl-rockchip-enable-clock-when-reading-pin-direction-register.patch queue-4.14/platform-chrome-use-proper-protocol-transfer-function.patch

7 years, 6 months

1
0
0 0

Patch "pinctrl: Really force states during suspend/resume" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled pinctrl: Really force states during suspend/resume to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: pinctrl-really-force-states-during-suspend-resume.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Thu Mar 22 14:26:48 CET 2018 From: Florian Fainelli <f.fainelli(a)gmail.com> Date: Wed, 1 Mar 2017 10:32:57 -0800 Subject: pinctrl: Really force states during suspend/resume From: Florian Fainelli <f.fainelli(a)gmail.com> [ Upstream commit 981ed1bfbc6c4660b2ddaa8392893e20a6255048 ] In case a platform only defaults a "default" set of pins, but not a "sleep" set of pins, and this particular platform suspends and resumes in a way that the pin states are not preserved by the hardware, when we resume, we would call pinctrl_single_resume() -> pinctrl_force_default() -> pinctrl_select_state() and the first thing we do is check that the pins state is the same as before, and do nothing. In order to fix this, decouple the actual state change from pinctrl_select_state() and move it pinctrl_commit_state(), while keeping the p->state == state check in pinctrl_select_state() not to change the caller assumptions. pinctrl_force_sleep() and pinctrl_force_default() are updated to bypass the state check by calling pinctrl_commit_state(). [Linus Walleij] The forced pin control states are currently only used in some pin controller drivers that grab their own reference to their own pins. This is equal to the pin control hogs: pins taken by pin control devices since there are no corresponding device in the Linux device hierarchy, such as memory controller lines or unused GPIO lines, or GPIO lines that are used orthogonally from the GPIO subsystem but pincontrol-wise managed as hogs (non-strict mode, allowing simultaneous use by GPIO and pin control). For this case forcing the state from the drivers' suspend()/resume() callbacks makes sense and should semantically match the name of the function. Fixes: 6e5e959dde0d ("pinctrl: API changes to support multiple states per device") Signed-off-by: Florian Fainelli <f.fainelli(a)gmail.com> Reviewed-by: Andy Shevchenko <andy.shevchenko(a)gmail.com> Signed-off-by: Linus Walleij <linus.walleij(a)linaro.org> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/pinctrl/core.c | 24 +++++++++++++++++------- 1 file changed, 17 insertions(+), 7 deletions(-) --- a/drivers/pinctrl/core.c +++ b/drivers/pinctrl/core.c @@ -1189,19 +1189,16 @@ struct pinctrl_state *pinctrl_lookup_sta EXPORT_SYMBOL_GPL(pinctrl_lookup_state); /** - * pinctrl_select_state() - select/activate/program a pinctrl state to HW + * pinctrl_commit_state() - select/activate/program a pinctrl state to HW * @p: the pinctrl handle for the device that requests configuration * @state: the state handle to select/activate/program */ -int pinctrl_select_state(struct pinctrl *p, struct pinctrl_state *state) +static int pinctrl_commit_state(struct pinctrl *p, struct pinctrl_state *state) { struct pinctrl_setting *setting, *setting2; struct pinctrl_state *old_state = p->state; int ret; - if (p->state == state) - return 0; - if (p->state) { /* * For each pinmux setting in the old state, forget SW's record @@ -1265,6 +1262,19 @@ unapply_new_state: return ret; } + +/** + * pinctrl_select_state() - select/activate/program a pinctrl state to HW + * @p: the pinctrl handle for the device that requests configuration + * @state: the state handle to select/activate/program + */ +int pinctrl_select_state(struct pinctrl *p, struct pinctrl_state *state) +{ + if (p->state == state) + return 0; + + return pinctrl_commit_state(p, state); +} EXPORT_SYMBOL_GPL(pinctrl_select_state); static void devm_pinctrl_release(struct device *dev, void *res) @@ -1430,7 +1440,7 @@ void pinctrl_unregister_map(const struct int pinctrl_force_sleep(struct pinctrl_dev *pctldev) { if (!IS_ERR(pctldev->p) && !IS_ERR(pctldev->hog_sleep)) - return pinctrl_select_state(pctldev->p, pctldev->hog_sleep); + return pinctrl_commit_state(pctldev->p, pctldev->hog_sleep); return 0; } EXPORT_SYMBOL_GPL(pinctrl_force_sleep); @@ -1442,7 +1452,7 @@ EXPORT_SYMBOL_GPL(pinctrl_force_sleep); int pinctrl_force_default(struct pinctrl_dev *pctldev) { if (!IS_ERR(pctldev->p) && !IS_ERR(pctldev->hog_default)) - return pinctrl_select_state(pctldev->p, pctldev->hog_default); + return pinctrl_commit_state(pctldev->p, pctldev->hog_default); return 0; } EXPORT_SYMBOL_GPL(pinctrl_force_default); Patches currently in stable-queue which might be from f.fainelli(a)gmail.com are queue-4.14/pinctrl-really-force-states-during-suspend-resume.patch

7 years, 6 months

1
0
0 0

Patch "PCI: rcar: Handle rcar_pcie_parse_request_of_pci_ranges() failures" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled PCI: rcar: Handle rcar_pcie_parse_request_of_pci_ranges() failures to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: pci-rcar-handle-rcar_pcie_parse_request_of_pci_ranges-failures.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Thu Mar 22 14:26:48 CET 2018 From: Geert Uytterhoeven <geert+renesas(a)glider.be> Date: Thu, 7 Dec 2017 11:15:20 +0100 Subject: PCI: rcar: Handle rcar_pcie_parse_request_of_pci_ranges() failures From: Geert Uytterhoeven <geert+renesas(a)glider.be> [ Upstream commit 83c75ddd816e979802bd244ad494139f28152921 ] rcar_pcie_parse_request_of_pci_ranges() can fail and return an error code, but this is not checked nor handled. Fix this by adding the missing error handling. Fixes: 5d2917d469faab72 ("PCI: rcar: Convert to DT resource parsing API") Signed-off-by: Geert Uytterhoeven <geert+renesas(a)glider.be> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi(a)arm.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/pci/host/pcie-rcar.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) --- a/drivers/pci/host/pcie-rcar.c +++ b/drivers/pci/host/pcie-rcar.c @@ -1141,7 +1141,9 @@ static int rcar_pcie_probe(struct platfo INIT_LIST_HEAD(&pcie->resources); - rcar_pcie_parse_request_of_pci_ranges(pcie); + err = rcar_pcie_parse_request_of_pci_ranges(pcie); + if (err) + goto err_free_bridge; err = rcar_pcie_get_resources(pcie); if (err < 0) { @@ -1196,6 +1198,7 @@ err_pm_disable: err_free_resource_list: pci_free_resource_list(&pcie->resources); +err_free_bridge: pci_free_host_bridge(bridge); return err; Patches currently in stable-queue which might be from geert+renesas(a)glider.be are queue-4.14/spi-sh-msiof-avoid-writing-to-registers-from-spi_master.setup.patch queue-4.14/pci-rcar-handle-rcar_pcie_parse_request_of_pci_ranges-failures.patch

7 years, 6 months

1
0
0 0

Patch "PCI: endpoint: Fix find_first_zero_bit() usage" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled PCI: endpoint: Fix find_first_zero_bit() usage to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: pci-endpoint-fix-find_first_zero_bit-usage.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Thu Mar 22 14:26:48 CET 2018 From: Niklas Cassel <niklas.cassel(a)axis.com> Date: Thu, 14 Dec 2017 14:01:46 +0100 Subject: PCI: endpoint: Fix find_first_zero_bit() usage From: Niklas Cassel <niklas.cassel(a)axis.com> [ Upstream commit 35ad61921f495ee14915d185de79478c1737b4da ] find_first_zero_bit()'s parameter 'size' is defined in bits, not in bytes. Calling find_first_zero_bit() with the wrong size unit will lead to insidious bugs. Fix this by calling find_first_zero_bit() with size BITS_PER_LONG, rather than sizeof() and add missing find_first_zero_bit() return handling. Fixes: d74679911610 ("PCI: endpoint: Introduce configfs entry for configuring EP functions") Signed-off-by: Niklas Cassel <niklas.cassel(a)axis.com> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi(a)arm.com> Acked-by: Kishon Vijay Abraham I <kishon(a)ti.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/pci/endpoint/pci-ep-cfs.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) --- a/drivers/pci/endpoint/pci-ep-cfs.c +++ b/drivers/pci/endpoint/pci-ep-cfs.c @@ -109,7 +109,10 @@ static int pci_epc_epf_link(struct confi goto err_add_epf; func_no = find_first_zero_bit(&epc_group->function_num_map, - sizeof(epc_group->function_num_map)); + BITS_PER_LONG); + if (func_no >= BITS_PER_LONG) + return -EINVAL; + set_bit(func_no, &epc_group->function_num_map); epf->func_no = func_no; Patches currently in stable-queue which might be from niklas.cassel(a)axis.com are queue-4.14/pci-endpoint-fix-find_first_zero_bit-usage.patch

7 years, 6 months

1
0
0 0

Patch "PCI: designware-ep: Fix ->get_msi() to check MSI_EN bit" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled PCI: designware-ep: Fix ->get_msi() to check MSI_EN bit to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: pci-designware-ep-fix-get_msi-to-check-msi_en-bit.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Thu Mar 22 14:26:48 CET 2018 From: Kishon Vijay Abraham I <kishon(a)ti.com> Date: Tue, 19 Dec 2017 15:25:41 +0530 Subject: PCI: designware-ep: Fix ->get_msi() to check MSI_EN bit From: Kishon Vijay Abraham I <kishon(a)ti.com> [ Upstream commit a134a457ed985dca8cce7ac4ea66129ea70eba73 ] ->get_msi() now checks MSI_EN bit in the MSI CAPABILITY register to find whether the host supports MSI instead of using the MSI ADDRESS in the MSI CAPABILITY register. This fixes the issue with the following sequence 'modprobe pci_endpoint_test' enables MSI 'rmmod pci_endpoint_test' disables MSI but MSI address (in EP's capability register) has a valid value 'modprobe pci_endpoint_test no_msi=1' - Since MSI address (in EP's capability register) has a valid value (set during the previous insertion of the module), EP thinks host supports MSI. Fixes: f8aed6ec624f ("PCI: dwc: designware: Add EP mode support") Signed-off-by: Kishon Vijay Abraham I <kishon(a)ti.com> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi(a)arm.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/pci/dwc/pcie-designware-ep.c | 12 +++--------- drivers/pci/dwc/pcie-designware.h | 1 + 2 files changed, 4 insertions(+), 9 deletions(-) --- a/drivers/pci/dwc/pcie-designware-ep.c +++ b/drivers/pci/dwc/pcie-designware-ep.c @@ -197,20 +197,14 @@ static int dw_pcie_ep_map_addr(struct pc static int dw_pcie_ep_get_msi(struct pci_epc *epc) { int val; - u32 lower_addr; - u32 upper_addr; struct dw_pcie_ep *ep = epc_get_drvdata(epc); struct dw_pcie *pci = to_dw_pcie_from_ep(ep); - val = dw_pcie_readb_dbi(pci, MSI_MESSAGE_CONTROL); - val = (val & MSI_CAP_MME_MASK) >> MSI_CAP_MME_SHIFT; - - lower_addr = dw_pcie_readl_dbi(pci, MSI_MESSAGE_ADDR_L32); - upper_addr = dw_pcie_readl_dbi(pci, MSI_MESSAGE_ADDR_U32); - - if (!(lower_addr || upper_addr)) + val = dw_pcie_readw_dbi(pci, MSI_MESSAGE_CONTROL); + if (!(val & MSI_CAP_MSI_EN_MASK)) return -EINVAL; + val = (val & MSI_CAP_MME_MASK) >> MSI_CAP_MME_SHIFT; return val; } --- a/drivers/pci/dwc/pcie-designware.h +++ b/drivers/pci/dwc/pcie-designware.h @@ -101,6 +101,7 @@ #define MSI_MESSAGE_CONTROL 0x52 #define MSI_CAP_MMC_SHIFT 1 #define MSI_CAP_MME_SHIFT 4 +#define MSI_CAP_MSI_EN_MASK 0x1 #define MSI_CAP_MME_MASK (7 << MSI_CAP_MME_SHIFT) #define MSI_MESSAGE_ADDR_L32 0x54 #define MSI_MESSAGE_ADDR_U32 0x58 Patches currently in stable-queue which might be from kishon(a)ti.com are queue-4.14/pci-endpoint-fix-find_first_zero_bit-usage.patch queue-4.14/pci-designware-ep-fix-get_msi-to-check-msi_en-bit.patch

7 years, 6 months

1
0
0 0

Patch "omapdrm: panel: fix compatible vendor string for td028ttec1" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled omapdrm: panel: fix compatible vendor string for td028ttec1 to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: omapdrm-panel-fix-compatible-vendor-string-for-td028ttec1.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Thu Mar 22 14:26:48 CET 2018 From: "H. Nikolaus Schaller" <hns(a)goldelico.com> Date: Tue, 28 Nov 2017 16:48:54 +0100 Subject: omapdrm: panel: fix compatible vendor string for td028ttec1 From: "H. Nikolaus Schaller" <hns(a)goldelico.com> [ Upstream commit c1b9d4c75cd549e08bd0596d7f9dcc20f7f6e8fa ] The vendor name was "toppoly" but other panels and the vendor list have defined it as "tpo". So let's fix it in driver and bindings. We keep the old definition in parallel to stay compatible with potential older DTB setup. Signed-off-by: H. Nikolaus Schaller <hns(a)goldelico.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen(a)ti.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- Documentation/devicetree/bindings/display/panel/toppoly,td028ttec1.txt | 30 ---------- Documentation/devicetree/bindings/display/panel/tpo,td028ttec1.txt | 30 ++++++++++ drivers/gpu/drm/omapdrm/displays/panel-tpo-td028ttec1.c | 3 + drivers/video/fbdev/omap2/omapfb/displays/panel-tpo-td028ttec1.c | 3 + 4 files changed, 36 insertions(+), 30 deletions(-) rename Documentation/devicetree/bindings/display/panel/{toppoly,td028ttec1.txt => tpo,td028ttec1.txt} (84%) --- a/Documentation/devicetree/bindings/display/panel/toppoly,td028ttec1.txt +++ /dev/null @@ -1,30 +0,0 @@ -Toppoly TD028TTEC1 Panel -======================== - -Required properties: -- compatible: "toppoly,td028ttec1" - -Optional properties: -- label: a symbolic name for the panel - -Required nodes: -- Video port for DPI input - -Example -------- - -lcd-panel: td028ttec1@0 { - compatible = "toppoly,td028ttec1"; - reg = <0>; - spi-max-frequency = <100000>; - spi-cpol; - spi-cpha; - - label = "lcd"; - port { - lcd_in: endpoint { - remote-endpoint = <&dpi_out>; - }; - }; -}; - --- /dev/null +++ b/Documentation/devicetree/bindings/display/panel/tpo,td028ttec1.txt @@ -0,0 +1,30 @@ +Toppoly TD028TTEC1 Panel +======================== + +Required properties: +- compatible: "tpo,td028ttec1" + +Optional properties: +- label: a symbolic name for the panel + +Required nodes: +- Video port for DPI input + +Example +------- + +lcd-panel: td028ttec1@0 { + compatible = "tpo,td028ttec1"; + reg = <0>; + spi-max-frequency = <100000>; + spi-cpol; + spi-cpha; + + label = "lcd"; + port { + lcd_in: endpoint { + remote-endpoint = <&dpi_out>; + }; + }; +}; + --- a/drivers/gpu/drm/omapdrm/displays/panel-tpo-td028ttec1.c +++ b/drivers/gpu/drm/omapdrm/displays/panel-tpo-td028ttec1.c @@ -452,6 +452,8 @@ static int td028ttec1_panel_remove(struc } static const struct of_device_id td028ttec1_of_match[] = { + { .compatible = "omapdss,tpo,td028ttec1", }, + /* keep to not break older DTB */ { .compatible = "omapdss,toppoly,td028ttec1", }, {}, }; @@ -471,6 +473,7 @@ static struct spi_driver td028ttec1_spi_ module_spi_driver(td028ttec1_spi_driver); +MODULE_ALIAS("spi:tpo,td028ttec1"); MODULE_ALIAS("spi:toppoly,td028ttec1"); MODULE_AUTHOR("H. Nikolaus Schaller <hns(a)goldelico.com>"); MODULE_DESCRIPTION("Toppoly TD028TTEC1 panel driver"); --- a/drivers/video/fbdev/omap2/omapfb/displays/panel-tpo-td028ttec1.c +++ b/drivers/video/fbdev/omap2/omapfb/displays/panel-tpo-td028ttec1.c @@ -455,6 +455,8 @@ static int td028ttec1_panel_remove(struc } static const struct of_device_id td028ttec1_of_match[] = { + { .compatible = "omapdss,tpo,td028ttec1", }, + /* keep to not break older DTB */ { .compatible = "omapdss,toppoly,td028ttec1", }, {}, }; @@ -474,6 +476,7 @@ static struct spi_driver td028ttec1_spi_ module_spi_driver(td028ttec1_spi_driver); +MODULE_ALIAS("spi:tpo,td028ttec1"); MODULE_ALIAS("spi:toppoly,td028ttec1"); MODULE_AUTHOR("H. Nikolaus Schaller <hns(a)goldelico.com>"); MODULE_DESCRIPTION("Toppoly TD028TTEC1 panel driver"); Patches currently in stable-queue which might be from hns(a)goldelico.com are queue-4.14/omapdrm-panel-fix-compatible-vendor-string-for-td028ttec1.patch

7 years, 6 months

1
0
0 0

Patch "nfsd4: permit layoutget of executable-only files" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled nfsd4: permit layoutget of executable-only files to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: nfsd4-permit-layoutget-of-executable-only-files.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Thu Mar 22 14:26:48 CET 2018 From: Benjamin Coddington <bcodding(a)redhat.com> Date: Tue, 19 Dec 2017 09:35:25 -0500 Subject: nfsd4: permit layoutget of executable-only files From: Benjamin Coddington <bcodding(a)redhat.com> [ Upstream commit 66282ec1cf004c09083c29cb5e49019037937bbd ] Clients must be able to read a file in order to execute it, and for pNFS that means the client needs to be able to perform a LAYOUTGET on the file. This behavior for executable-only files was added for OPEN in commit a043226bc140 "nfsd4: permit read opens of executable-only files". This fixes up xfstests generic/126 on block/scsi layouts. Signed-off-by: Benjamin Coddington <bcodding(a)redhat.com> Signed-off-by: J. Bruce Fields <bfields(a)redhat.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- fs/nfsd/nfs4proc.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) --- a/fs/nfsd/nfs4proc.c +++ b/fs/nfsd/nfs4proc.c @@ -1372,14 +1372,14 @@ nfsd4_layoutget(struct svc_rqst *rqstp, const struct nfsd4_layout_ops *ops; struct nfs4_layout_stateid *ls; __be32 nfserr; - int accmode; + int accmode = NFSD_MAY_READ_IF_EXEC; switch (lgp->lg_seg.iomode) { case IOMODE_READ: - accmode = NFSD_MAY_READ; + accmode |= NFSD_MAY_READ; break; case IOMODE_RW: - accmode = NFSD_MAY_READ | NFSD_MAY_WRITE; + accmode |= NFSD_MAY_READ | NFSD_MAY_WRITE; break; default: dprintk("%s: invalid iomode %d\n", Patches currently in stable-queue which might be from bcodding(a)redhat.com are queue-4.14/nfsd4-permit-layoutget-of-executable-only-files.patch

7 years, 6 months

1
0
0 0

Patch "net: phy: meson-gxl: check phy_write return value" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled net: phy: meson-gxl: check phy_write return value to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: net-phy-meson-gxl-check-phy_write-return-value.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Thu Mar 22 14:26:48 CET 2018 From: Jerome Brunet <jbrunet(a)baylibre.com> Date: Mon, 18 Dec 2017 10:44:40 +0100 Subject: net: phy: meson-gxl: check phy_write return value From: Jerome Brunet <jbrunet(a)baylibre.com> [ Upstream commit 9042b46eda33ef5db3cdfc9e12b3c8cabb196141 ] Always check phy_write return values. Better to be safe than sorry Reviewed-by: Andrew Lunn <andrew(a)lunn.ch> Signed-off-by: Jerome Brunet <jbrunet(a)baylibre.com> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/net/phy/meson-gxl.c | 50 +++++++++++++++++++++++++++++++++----------- 1 file changed, 38 insertions(+), 12 deletions(-) --- a/drivers/net/phy/meson-gxl.c +++ b/drivers/net/phy/meson-gxl.c @@ -25,27 +25,53 @@ static int meson_gxl_config_init(struct phy_device *phydev) { + int ret; + /* Enable Analog and DSP register Bank access by */ - phy_write(phydev, 0x14, 0x0000); - phy_write(phydev, 0x14, 0x0400); - phy_write(phydev, 0x14, 0x0000); - phy_write(phydev, 0x14, 0x0400); + ret = phy_write(phydev, 0x14, 0x0000); + if (ret) + return ret; + ret = phy_write(phydev, 0x14, 0x0400); + if (ret) + return ret; + ret = phy_write(phydev, 0x14, 0x0000); + if (ret) + return ret; + ret = phy_write(phydev, 0x14, 0x0400); + if (ret) + return ret; /* Write Analog register 23 */ - phy_write(phydev, 0x17, 0x8E0D); - phy_write(phydev, 0x14, 0x4417); + ret = phy_write(phydev, 0x17, 0x8E0D); + if (ret) + return ret; + ret = phy_write(phydev, 0x14, 0x4417); + if (ret) + return ret; /* Enable fractional PLL */ - phy_write(phydev, 0x17, 0x0005); - phy_write(phydev, 0x14, 0x5C1B); + ret = phy_write(phydev, 0x17, 0x0005); + if (ret) + return ret; + ret = phy_write(phydev, 0x14, 0x5C1B); + if (ret) + return ret; /* Program fraction FR_PLL_DIV1 */ - phy_write(phydev, 0x17, 0x029A); - phy_write(phydev, 0x14, 0x5C1D); + ret = phy_write(phydev, 0x17, 0x029A); + if (ret) + return ret; + ret = phy_write(phydev, 0x14, 0x5C1D); + if (ret) + return ret; /* Program fraction FR_PLL_DIV1 */ - phy_write(phydev, 0x17, 0xAAAA); - phy_write(phydev, 0x14, 0x5C1C); + ret = phy_write(phydev, 0x17, 0xAAAA); + if (ret) + return ret; + ret = phy_write(phydev, 0x14, 0x5C1C); + if (ret) + return ret; return 0; } Patches currently in stable-queue which might be from jbrunet(a)baylibre.com are queue-4.14/net-phy-meson-gxl-check-phy_write-return-value.patch

7 years, 6 months

1
0
0 0

Patch "net: fec: add phy_reset_after_clk_enable() support" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled net: fec: add phy_reset_after_clk_enable() support to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: net-fec-add-phy_reset_after_clk_enable-support.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Thu Mar 22 14:26:48 CET 2018 From: Richard Leitner <richard.leitner(a)skidata.com> Date: Mon, 11 Dec 2017 13:17:00 +0100 Subject: net: fec: add phy_reset_after_clk_enable() support From: Richard Leitner <richard.leitner(a)skidata.com> [ Upstream commit 1b0a83ac04e383e3bed21332962b90710fcf2828 ] Some PHYs (for example the SMSC LAN8710/LAN8720) doesn't allow turning the refclk on and off again during operation (according to their datasheet). Nonetheless exactly this behaviour was introduced for power saving reasons by commit e8fcfcd5684a ("net: fec: optimize the clock management to save power"). Therefore add support for the phy_reset_after_clk_enable function from phylib to mitigate this issue. Generally speaking this issue is only relevant if the ref clk for the PHY is generated by the SoC and therefore the PHY is configured to "REF_CLK In Mode". In our specific case (PCB) this problem does occur at about every 10th to 50th POR of an LAN8710 connected to an i.MX6SOLO SoC. The typical symptom of this problem is a "swinging" ethernet link. Similar issues were reported by users of the NXP forum: https://community.nxp.com/thread/389902 https://community.nxp.com/message/309354 With this patch applied the issue didn't occur for at least a few hundret PORs of our board. Fixes: e8fcfcd5684a ("net: fec: optimize the clock management to save power") Signed-off-by: Richard Leitner <richard.leitner(a)skidata.com> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/net/ethernet/freescale/fec_main.c | 20 ++++++++++++++++++++ 1 file changed, 20 insertions(+) --- a/drivers/net/ethernet/freescale/fec_main.c +++ b/drivers/net/ethernet/freescale/fec_main.c @@ -1872,6 +1872,8 @@ static int fec_enet_clk_enable(struct ne ret = clk_prepare_enable(fep->clk_ref); if (ret) goto failed_clk_ref; + + phy_reset_after_clk_enable(ndev->phydev); } else { clk_disable_unprepare(fep->clk_ahb); clk_disable_unprepare(fep->clk_enet_out); @@ -2844,6 +2846,7 @@ fec_enet_open(struct net_device *ndev) { struct fec_enet_private *fep = netdev_priv(ndev); int ret; + bool reset_again; ret = pm_runtime_get_sync(&fep->pdev->dev); if (ret < 0) @@ -2854,6 +2857,17 @@ fec_enet_open(struct net_device *ndev) if (ret) goto clk_enable; + /* During the first fec_enet_open call the PHY isn't probed at this + * point. Therefore the phy_reset_after_clk_enable() call within + * fec_enet_clk_enable() fails. As we need this reset in order to be + * sure the PHY is working correctly we check if we need to reset again + * later when the PHY is probed + */ + if (ndev->phydev && ndev->phydev->drv) + reset_again = false; + else + reset_again = true; + /* I should reset the ring buffers here, but I don't yet know * a simple way to do that. */ @@ -2870,6 +2884,12 @@ fec_enet_open(struct net_device *ndev) if (ret) goto err_enet_mii_probe; + /* Call phy_reset_after_clk_enable() again if it failed during + * phy_reset_after_clk_enable() before because the PHY wasn't probed. + */ + if (reset_again) + phy_reset_after_clk_enable(ndev->phydev); + if (fep->quirks & FEC_QUIRK_ERR006687) imx6q_cpuidle_fec_irqs_used(); Patches currently in stable-queue which might be from richard.leitner(a)skidata.com are queue-4.14/net-fec-add-phy_reset_after_clk_enable-support.patch

7 years, 6 months

1
0
0 0

Patch "mmc: sdhci-xenon: wait 5ms after set 1.8V signal enable" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled mmc: sdhci-xenon: wait 5ms after set 1.8V signal enable to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: mmc-sdhci-xenon-wait-5ms-after-set-1.8v-signal-enable.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Thu Mar 22 14:26:48 CET 2018 From: Zhoujie Wu <zjwu(a)marvell.com> Date: Mon, 18 Dec 2017 14:38:47 -0800 Subject: mmc: sdhci-xenon: wait 5ms after set 1.8V signal enable From: Zhoujie Wu <zjwu(a)marvell.com> [ Upstream commit 8d876bf472dba73c015cea9feea80dcb80626a7c ] According to SD spec 3.00 3.6.1 signal voltage switch procedure step 6~8, (6) Set 1.8V Signal Enable in the Host Control 2 register. (7) Wait 5ms. 1.8V voltage regulator shall be stable within this period. (8) If 1.8V Signal Enable is cleared by Host Controller, go to step (12). Host should wait 5ms after set 1.8V signal enable bit in Host Control 2 register and check if 1.8V is stable or not. But current code checks this bit right after set it. On some platforms with xenon controller found the bit is cleared right away and host reports "1.8V regulator output did not became stable" and 5ms delay can help. Implement voltage_switch callback for xenon controller to add 5ms delay to make sure the 1.8V signal enable bit is set by controller. Signed-off-by: Zhoujie Wu <zjwu(a)marvell.com> Acked-by: Adrian Hunter <adrian.hunter(a)intel.com> Signed-off-by: Ulf Hansson <ulf.hansson(a)linaro.org> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/mmc/host/sdhci-xenon.c | 7 +++++++ 1 file changed, 7 insertions(+) --- a/drivers/mmc/host/sdhci-xenon.c +++ b/drivers/mmc/host/sdhci-xenon.c @@ -230,7 +230,14 @@ static void xenon_set_power(struct sdhci mmc_regulator_set_ocr(mmc, mmc->supply.vmmc, vdd); } +static void xenon_voltage_switch(struct sdhci_host *host) +{ + /* Wait for 5ms after set 1.8V signal enable bit */ + usleep_range(5000, 5500); +} + static const struct sdhci_ops sdhci_xenon_ops = { + .voltage_switch = xenon_voltage_switch, .set_clock = sdhci_set_clock, .set_power = xenon_set_power, .set_bus_width = sdhci_set_bus_width, Patches currently in stable-queue which might be from zjwu(a)marvell.com are queue-4.14/mmc-sdhci-xenon-wait-5ms-after-set-1.8v-signal-enable.patch

7 years, 6 months

1
0
0 0

Patch "mmc: block: fix logical error to avoid memory leak" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled mmc: block: fix logical error to avoid memory leak to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: mmc-block-fix-logical-error-to-avoid-memory-leak.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Thu Mar 22 14:26:48 CET 2018 From: "Liu, Changcheng" <changcheng.liu(a)intel.com> Date: Sat, 16 Dec 2017 23:15:45 +0800 Subject: mmc: block: fix logical error to avoid memory leak From: "Liu, Changcheng" <changcheng.liu(a)intel.com> [ Upstream commit 0be55579a127916ebe39db2a74d906a2dfceed42 ] If the MMC_DRV_OP_GET_EXT_CSD request completes successfully, then ext_csd must be freed, but in one case it was not. Fix that. Signed-off-by: Liu Changcheng <changcheng.liu(a)intel.com> Acked-by: Adrian Hunter <adrian.hunter(a)intel.com> Acked-by: Linus Walleij <linus.walleij(a)linaro.org> Signed-off-by: Ulf Hansson <ulf.hansson(a)linaro.org> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/mmc/core/block.c | 1 + 1 file changed, 1 insertion(+) --- a/drivers/mmc/core/block.c +++ b/drivers/mmc/core/block.c @@ -2387,6 +2387,7 @@ static int mmc_ext_csd_open(struct inode if (n != EXT_CSD_STR_LEN) { err = -EINVAL; + kfree(ext_csd); goto out_free; } Patches currently in stable-queue which might be from changcheng.liu(a)intel.com are queue-4.14/mmc-block-fix-logical-error-to-avoid-memory-leak.patch

7 years, 6 months

1
0
0 0

Patch "mmc: avoid removing non-removable hosts during suspend" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled mmc: avoid removing non-removable hosts during suspend to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: mmc-avoid-removing-non-removable-hosts-during-suspend.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Thu Mar 22 14:26:48 CET 2018 From: Daniel Drake <drake(a)endlessm.com> Date: Tue, 12 Dec 2017 10:49:02 +0000 Subject: mmc: avoid removing non-removable hosts during suspend From: Daniel Drake <drake(a)endlessm.com> [ Upstream commit de8dcc3d2c0e08e5068ee1e26fc46415c15e3637 ] The Weibu F3C MiniPC has an onboard AP6255 module, presenting two SDIO functions on a single MMC host (Bluetooth/btsdio and WiFi/brcmfmac), and the mmc layer correctly detects this as non-removable. After suspend/resume, the wifi and bluetooth interfaces disappear and do not get probed again. The conditions here are: 1. During suspend, we reach mmc_pm_notify() 2. mmc_pm_notify() calls mmc_sdio_pre_suspend() to see if we can suspend the SDIO host. However, mmc_sdio_pre_suspend() returns -ENOSYS because btsdio_driver does not have a suspend method. 3. mmc_pm_notify() proceeds to remove the card 4. Upon resume, mmc_rescan() does nothing with this host, because of the rescan_entered check which aims to only scan a non-removable device a single time (i.e. during boot). Fix the loss of functionality by detecting that we are unable to suspend a non-removable host, so avoid the forced removal in that case. The comment above this function already indicates that this code was only intended for removable devices. Signed-off-by: Daniel Drake <drake(a)endlessm.com> Signed-off-by: Ulf Hansson <ulf.hansson(a)linaro.org> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/mmc/core/core.c | 8 ++++++++ 1 file changed, 8 insertions(+) --- a/drivers/mmc/core/core.c +++ b/drivers/mmc/core/core.c @@ -2751,6 +2751,14 @@ static int mmc_pm_notify(struct notifier if (!err) break; + if (!mmc_card_is_removable(host)) { + dev_warn(mmc_dev(host), + "pre_suspend failed for non-removable host: " + "%d\n", err); + /* Avoid removing non-removable hosts */ + break; + } + /* Calling bus_ops->remove() with a claimed host can deadlock */ host->bus_ops->remove(host); mmc_claim_host(host); Patches currently in stable-queue which might be from drake(a)endlessm.com are queue-4.14/mmc-avoid-removing-non-removable-hosts-during-suspend.patch

7 years, 6 months

1
0
0 0

Patch "media: s5p-mfc: Fix lock contention - request_firmware() once" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled media: s5p-mfc: Fix lock contention - request_firmware() once to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: media-s5p-mfc-fix-lock-contention-request_firmware-once.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Thu Mar 22 14:26:48 CET 2018 From: Shuah Khan <shuahkh(a)osg.samsung.com> Date: Fri, 3 Nov 2017 22:01:58 -0400 Subject: media: s5p-mfc: Fix lock contention - request_firmware() once From: Shuah Khan <shuahkh(a)osg.samsung.com> [ Upstream commit f45ce9877561044090010e0eb0fad644232ded04 ] Driver calls request_firmware() whenever the device is opened for the first time. As the device gets opened and closed, dev->num_inst == 1 is true several times. This is not necessary since the firmware is saved in the fw_buf. s5p_mfc_load_firmware() copies the buffer returned by the request_firmware() to dev->fw_buf. fw_buf sticks around until it gets released from s5p_mfc_remove(), hence there is no need to keep requesting firmware and copying it to fw_buf. This might have been overlooked when changes are made to free fw_buf from the device release interface s5p_mfc_release(). Fix s5p_mfc_load_firmware() to call request_firmware() once and keep state. Change _probe() to load firmware once fw_buf has been allocated. s5p_mfc_open() and it continues to call s5p_mfc_load_firmware() and init hardware which is the step where firmware is written to the device. This addresses the mfc_mutex contention due to repeated request_firmware() calls from open() in the following circular locking warning: [ 552.194115] qtdemux0:sink/2710 is trying to acquire lock: [ 552.199488] (&dev->mfc_mutex){+.+.}, at: [<bf145544>] s5p_mfc_mmap+0x28/0xd4 [s5p_mfc] [ 552.207459] but task is already holding lock: [ 552.213264] (&mm->mmap_sem){++++}, at: [<c01df2e4>] vm_mmap_pgoff+0x44/0xb8 [ 552.220284] which lock already depends on the new lock. [ 552.228429] the existing dependency chain (in reverse order) is: [ 552.235881] -> #2 (&mm->mmap_sem){++++}: [ 552.241259] __might_fault+0x80/0xb0 [ 552.245331] filldir64+0xc0/0x2f8 [ 552.249144] call_filldir+0xb0/0x14c [ 552.253214] ext4_readdir+0x768/0x90c [ 552.257374] iterate_dir+0x74/0x168 [ 552.261360] SyS_getdents64+0x7c/0x1a0 [ 552.265608] ret_fast_syscall+0x0/0x28 [ 552.269850] -> #1 (&type->i_mutex_dir_key#2){++++}: [ 552.276180] down_read+0x48/0x90 [ 552.279904] lookup_slow+0x74/0x178 [ 552.283889] walk_component+0x1a4/0x2e4 [ 552.288222] link_path_walk+0x174/0x4a0 [ 552.292555] path_openat+0x68/0x944 [ 552.296541] do_filp_open+0x60/0xc4 [ 552.300528] file_open_name+0xe4/0x114 [ 552.304772] filp_open+0x28/0x48 [ 552.308499] kernel_read_file_from_path+0x30/0x78 [ 552.313700] _request_firmware+0x3ec/0x78c [ 552.318291] request_firmware+0x3c/0x54 [ 552.322642] s5p_mfc_load_firmware+0x54/0x150 [s5p_mfc] [ 552.328358] s5p_mfc_open+0x4e4/0x550 [s5p_mfc] [ 552.333394] v4l2_open+0xa0/0x104 [videodev] [ 552.338137] chrdev_open+0xa4/0x18c [ 552.342121] do_dentry_open+0x208/0x310 [ 552.346454] path_openat+0x28c/0x944 [ 552.350526] do_filp_open+0x60/0xc4 [ 552.354512] do_sys_open+0x118/0x1c8 [ 552.358586] ret_fast_syscall+0x0/0x28 [ 552.362830] -> #0 (&dev->mfc_mutex){+.+.}: -> #0 (&dev->mfc_mutex){+.+.}: [ 552.368379] lock_acquire+0x6c/0x88 [ 552.372364] __mutex_lock+0x68/0xa34 [ 552.376437] mutex_lock_interruptible_nested+0x1c/0x24 [ 552.382086] s5p_mfc_mmap+0x28/0xd4 [s5p_mfc] [ 552.386939] v4l2_mmap+0x54/0x88 [videodev] [ 552.391601] mmap_region+0x3a8/0x638 [ 552.395673] do_mmap+0x330/0x3a4 [ 552.399400] vm_mmap_pgoff+0x90/0xb8 [ 552.403472] SyS_mmap_pgoff+0x90/0xc0 [ 552.407632] ret_fast_syscall+0x0/0x28 [ 552.411876] other info that might help us debug this: [ 552.419848] Chain exists of: &dev->mfc_mutex --> &type->i_mutex_dir_key#2 --> &mm->mmap_sem [ 552.431200] Possible unsafe locking scenario: [ 552.437092] CPU0 CPU1 [ 552.441598] ---- ---- [ 552.446104] lock(&mm->mmap_sem); [ 552.449484] lock(&type->i_mutex_dir_key#2); [ 552.456329] lock(&mm->mmap_sem); [ 552.462222] lock(&dev->mfc_mutex); [ 552.465775] *** DEADLOCK *** Signed-off-by: Shuah Khan <shuahkh(a)osg.samsung.com> Signed-off-by: Sylwester Nawrocki <s.nawrocki(a)samsung.com> Signed-off-by: Mauro Carvalho Chehab <mchehab(a)s-opensource.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/media/platform/s5p-mfc/s5p_mfc.c | 6 ++++++ drivers/media/platform/s5p-mfc/s5p_mfc_common.h | 3 +++ drivers/media/platform/s5p-mfc/s5p_mfc_ctrl.c | 5 +++++ 3 files changed, 14 insertions(+) --- a/drivers/media/platform/s5p-mfc/s5p_mfc.c +++ b/drivers/media/platform/s5p-mfc/s5p_mfc.c @@ -1315,6 +1315,12 @@ static int s5p_mfc_probe(struct platform goto err_dma; } + /* + * Load fails if fs isn't mounted. Try loading anyway. + * _open() will load it, it it fails now. Ignore failure. + */ + s5p_mfc_load_firmware(dev); + mutex_init(&dev->mfc_mutex); init_waitqueue_head(&dev->queue); dev->hw_lock = 0; --- a/drivers/media/platform/s5p-mfc/s5p_mfc_common.h +++ b/drivers/media/platform/s5p-mfc/s5p_mfc_common.h @@ -290,6 +290,8 @@ struct s5p_mfc_priv_buf { * @mfc_cmds: cmd structure holding HW commands function pointers * @mfc_regs: structure holding MFC registers * @fw_ver: loaded firmware sub-version + * @fw_get_done flag set when request_firmware() is complete and + * copied into fw_buf * risc_on: flag indicates RISC is on or off * */ @@ -336,6 +338,7 @@ struct s5p_mfc_dev { struct s5p_mfc_hw_cmds *mfc_cmds; const struct s5p_mfc_regs *mfc_regs; enum s5p_mfc_fw_ver fw_ver; + bool fw_get_done; bool risc_on; /* indicates if RISC is on or off */ }; --- a/drivers/media/platform/s5p-mfc/s5p_mfc_ctrl.c +++ b/drivers/media/platform/s5p-mfc/s5p_mfc_ctrl.c @@ -55,6 +55,9 @@ int s5p_mfc_load_firmware(struct s5p_mfc * into kernel. */ mfc_debug_enter(); + if (dev->fw_get_done) + return 0; + for (i = MFC_FW_MAX_VERSIONS - 1; i >= 0; i--) { if (!dev->variant->fw_name[i]) continue; @@ -82,6 +85,7 @@ int s5p_mfc_load_firmware(struct s5p_mfc } memcpy(dev->fw_buf.virt, fw_blob->data, fw_blob->size); wmb(); + dev->fw_get_done = true; release_firmware(fw_blob); mfc_debug_leave(); return 0; @@ -93,6 +97,7 @@ int s5p_mfc_release_firmware(struct s5p_ /* Before calling this function one has to make sure * that MFC is no longer processing */ s5p_mfc_release_priv_buf(dev, &dev->fw_buf); + dev->fw_get_done = false; return 0; } Patches currently in stable-queue which might be from shuahkh(a)osg.samsung.com are queue-4.14/media-s5p-mfc-fix-lock-contention-request_firmware-once.patch

7 years, 6 months

1
0
0 0

Patch "media: [RESEND] media: dvb-frontends: Add delay to Si2168 restart" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled media: [RESEND] media: dvb-frontends: Add delay to Si2168 restart to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: media-media-dvb-frontends-add-delay-to-si2168-restart.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Thu Mar 22 14:26:48 CET 2018 From: Ron Economos <w6rz(a)comcast.net> Date: Mon, 11 Dec 2017 19:51:53 -0500 Subject: media: [RESEND] media: dvb-frontends: Add delay to Si2168 restart From: Ron Economos <w6rz(a)comcast.net> [ Upstream commit 380a6c86457573aa42d27ae11e025eb25941a0b7 ] On faster CPUs a delay is required after the resume command and the restart command. Without the delay, the restart command often returns -EREMOTEIO and the Si2168 does not restart. Note that this patch fixes the same issue as https://patchwork.linuxtv.org/patch/44304/, but I believe my udelay() fix addresses the actual problem. Signed-off-by: Ron Economos <w6rz(a)comcast.net> Signed-off-by: Mauro Carvalho Chehab <mchehab(a)s-opensource.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/media/dvb-frontends/si2168.c | 3 +++ 1 file changed, 3 insertions(+) --- a/drivers/media/dvb-frontends/si2168.c +++ b/drivers/media/dvb-frontends/si2168.c @@ -14,6 +14,8 @@ * GNU General Public License for more details. */ +#include <linux/delay.h> + #include "si2168_priv.h" static const struct dvb_frontend_ops si2168_ops; @@ -435,6 +437,7 @@ static int si2168_init(struct dvb_fronte if (ret) goto err; + udelay(100); memcpy(cmd.args, "\x85", 1); cmd.wlen = 1; cmd.rlen = 1; Patches currently in stable-queue which might be from w6rz(a)comcast.net are queue-4.14/media-media-dvb-frontends-add-delay-to-si2168-restart.patch

7 years, 6 months

1
0
0 0

Patch "media: davinci: fix a debug printk" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled media: davinci: fix a debug printk to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: media-davinci-fix-a-debug-printk.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Thu Mar 22 14:26:48 CET 2018 From: Mauro Carvalho Chehab <mchehab(a)s-opensource.com> Date: Wed, 1 Nov 2017 17:05:49 -0400 Subject: media: davinci: fix a debug printk From: Mauro Carvalho Chehab <mchehab(a)s-opensource.com> [ Upstream commit 4f6c11044f512356cb63d3df0f3b38db79dc6736 ] Two orthogonal changesets caused a breakage at a printk inside davinci. Commit a2d17962c9ca ("[media] davinci: Switch from V4L2 OF to V4L2 fwnode") made davinci to use struct fwnode_handle instead of struct device_node. Commit 68d9c47b1679 ("media: Convert to using %pOF instead of full_name") changed the printk to not use ->full_name, but, instead, to rely on %pOF. With both patches applied, the Kernel will do the wrong thing, as warned by smatch: drivers/media/platform/davinci/vpif_capture.c:1399 vpif_async_bound() error: '%pOF' expects argument of type 'struct device_node*', argument 5 has type 'void*' So, change the logic to actually print the device name that was obtained before the print logic. Fixes: 68d9c47b1679 ("media: Convert to using %pOF instead of full_name") Fixes: a2d17962c9ca ("[media] davinci: Switch from V4L2 OF to V4L2 fwnode") Signed-off-by: Mauro Carvalho Chehab <mchehab(a)s-opensource.com> Acked-by: Lad, Prabhakar <prabhakar.csengg(a)gmail.com> Signed-off-by: Mauro Carvalho Chehab <mchehab(a)s-opensource.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/media/platform/davinci/vpif_capture.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) --- a/drivers/media/platform/davinci/vpif_capture.c +++ b/drivers/media/platform/davinci/vpif_capture.c @@ -1397,9 +1397,9 @@ static int vpif_async_bound(struct v4l2_ vpif_obj.config->chan_config->inputs[i].subdev_name = (char *)to_of_node(subdev->fwnode)->full_name; vpif_dbg(2, debug, - "%s: setting input %d subdev_name = %pOF\n", + "%s: setting input %d subdev_name = %s\n", __func__, i, - to_of_node(subdev->fwnode)); + vpif_obj.config->chan_config->inputs[i].subdev_name); return 0; } } Patches currently in stable-queue which might be from mchehab(a)s-opensource.com are queue-4.14/media-s5p-mfc-fix-lock-contention-request_firmware-once.patch queue-4.14/media-media-dvb-frontends-add-delay-to-si2168-restart.patch queue-4.14/media-c8sectpfe-fix-potential-null-pointer-dereference-in-c8sectpfe_timer_interrupt.patch queue-4.14/media-davinci-fix-a-debug-printk.patch queue-4.14/media-bt8xx-fix-err-bt878_probe.patch

7 years, 6 months

1
0
0 0

Patch "media: c8sectpfe: fix potential NULL pointer dereference in c8sectpfe_timer_interrupt" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled media: c8sectpfe: fix potential NULL pointer dereference in c8sectpfe_timer_interrupt to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: media-c8sectpfe-fix-potential-null-pointer-dereference-in-c8sectpfe_timer_interrupt.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Thu Mar 22 14:26:48 CET 2018 From: "Gustavo A. R. Silva" <garsilva(a)embeddedor.com> Date: Mon, 20 Nov 2017 09:00:55 -0500 Subject: media: c8sectpfe: fix potential NULL pointer dereference in c8sectpfe_timer_interrupt From: "Gustavo A. R. Silva" <garsilva(a)embeddedor.com> [ Upstream commit baed3c4bc4c13de93e0dba0a26d601411ebcb389 ] _channel_ is being dereferenced before it is null checked, hence there is a potential null pointer dereference. Fix this by moving the pointer dereference after _channel_ has been null checked. This issue was detected with the help of Coccinelle. Fixes: c5f5d0f99794 ("[media] c8sectpfe: STiH407/10 Linux DVB demux support") Signed-off-by: Gustavo A. R. Silva <garsilva(a)embeddedor.com> Acked-by: Patrice Chotard <patrice.chotard(a)st.com> Signed-off-by: Mauro Carvalho Chehab <mchehab(a)s-opensource.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/media/platform/sti/c8sectpfe/c8sectpfe-core.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) --- a/drivers/media/platform/sti/c8sectpfe/c8sectpfe-core.c +++ b/drivers/media/platform/sti/c8sectpfe/c8sectpfe-core.c @@ -83,7 +83,7 @@ static void c8sectpfe_timer_interrupt(un static void channel_swdemux_tsklet(unsigned long data) { struct channel_info *channel = (struct channel_info *)data; - struct c8sectpfei *fei = channel->fei; + struct c8sectpfei *fei; unsigned long wp, rp; int pos, num_packets, n, size; u8 *buf; @@ -91,6 +91,8 @@ static void channel_swdemux_tsklet(unsig if (unlikely(!channel || !channel->irec)) return; + fei = channel->fei; + wp = readl(channel->irec + DMA_PRDS_BUSWP_TP(0)); rp = readl(channel->irec + DMA_PRDS_BUSRP_TP(0)); Patches currently in stable-queue which might be from garsilva(a)embeddedor.com are queue-4.14/media-c8sectpfe-fix-potential-null-pointer-dereference-in-c8sectpfe_timer_interrupt.patch

7 years, 6 months

1
0
0 0

Patch "media: bt8xx: Fix err 'bt878_probe()'" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled media: bt8xx: Fix err 'bt878_probe()' to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: media-bt8xx-fix-err-bt878_probe.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Thu Mar 22 14:26:48 CET 2018 From: Christophe JAILLET <christophe.jaillet(a)wanadoo.fr> Date: Thu, 21 Sep 2017 19:23:56 -0400 Subject: media: bt8xx: Fix err 'bt878_probe()' From: Christophe JAILLET <christophe.jaillet(a)wanadoo.fr> [ Upstream commit 45392ff6881dbe56d41ef0b17c2e576065f8ffa1 ] This is odd to call 'pci_disable_device()' in an error path before a coresponding successful 'pci_enable_device()'. Return directly instead. Fixes: 77e0be12100a ("V4L/DVB (4176): Bug-fix: Fix memory overflow") Signed-off-by: Christophe JAILLET <christophe.jaillet(a)wanadoo.fr> Signed-off-by: Mauro Carvalho Chehab <mchehab(a)s-opensource.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/media/pci/bt8xx/bt878.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) --- a/drivers/media/pci/bt8xx/bt878.c +++ b/drivers/media/pci/bt8xx/bt878.c @@ -422,8 +422,7 @@ static int bt878_probe(struct pci_dev *d bt878_num); if (bt878_num >= BT878_MAX) { printk(KERN_ERR "bt878: Too many devices inserted\n"); - result = -ENOMEM; - goto fail0; + return -ENOMEM; } if (pci_enable_device(dev)) return -EIO; Patches currently in stable-queue which might be from christophe.jaillet(a)wanadoo.fr are queue-4.14/media-bt8xx-fix-err-bt878_probe.patch

7 years, 6 months

1
0
0 0

Patch "iser-target: avoid reinitializing rdma contexts for isert commands" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled iser-target: avoid reinitializing rdma contexts for isert commands to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: iser-target-avoid-reinitializing-rdma-contexts-for-isert-commands.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Thu Mar 22 14:26:48 CET 2018 From: Bharat Potnuri <bharat(a)chelsio.com> Date: Tue, 28 Nov 2017 23:58:07 +0530 Subject: iser-target: avoid reinitializing rdma contexts for isert commands From: Bharat Potnuri <bharat(a)chelsio.com> [ Upstream commit 66f53e6f5400578bae58db0c06d85a8820831f40 ] isert commands that failed during isert_rdma_rw_ctx_post() are queued to Queue-Full(QF) queue and are scheduled to be reposted during queue-full queue processing. During this reposting, the rdma contexts are initialised again in isert_rdma_rw_ctx_post(), which is leaking significant memory. unreferenced object 0xffff8830201d9640 (size 64): comm "kworker/0:2", pid 195, jiffies 4295374851 (age 4528.436s) hex dump (first 32 bytes): 00 60 8b cb 2e 00 00 00 00 10 00 00 00 00 00 00 .`.............. 00 90 e3 cb 2e 00 00 00 00 10 00 00 00 00 00 00 ................ backtrace: [<ffffffff8170711e>] kmemleak_alloc+0x4e/0xb0 [<ffffffff811f8ba5>] __kmalloc+0x125/0x2b0 [<ffffffffa046b24f>] rdma_rw_ctx_init+0x15f/0x6f0 [ib_core] [<ffffffffa07ab644>] isert_rdma_rw_ctx_post+0xc4/0x3c0 [ib_isert] [<ffffffffa07ad972>] isert_put_datain+0x112/0x1c0 [ib_isert] [<ffffffffa07dddce>] lio_queue_data_in+0x2e/0x30 [iscsi_target_mod] [<ffffffffa076c322>] target_qf_do_work+0x2b2/0x4b0 [target_core_mod] [<ffffffff81080c3b>] process_one_work+0x1db/0x5d0 [<ffffffff8108107d>] worker_thread+0x4d/0x3e0 [<ffffffff81088667>] kthread+0x117/0x150 [<ffffffff81713fa7>] ret_from_fork+0x27/0x40 [<ffffffffffffffff>] 0xffffffffffffffff Here is patch to use the older rdma contexts while reposting the isert commands intead of reinitialising them. Signed-off-by: Potnuri Bharat Teja <bharat(a)chelsio.com> Reviewed-by: Sagi Grimberg <sagi(a)grimberg.me> Signed-off-by: Jason Gunthorpe <jgg(a)mellanox.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/infiniband/ulp/isert/ib_isert.c | 7 +++++++ drivers/infiniband/ulp/isert/ib_isert.h | 1 + 2 files changed, 8 insertions(+) --- a/drivers/infiniband/ulp/isert/ib_isert.c +++ b/drivers/infiniband/ulp/isert/ib_isert.c @@ -2124,6 +2124,9 @@ isert_rdma_rw_ctx_post(struct isert_cmd u32 rkey, offset; int ret; + if (cmd->ctx_init_done) + goto rdma_ctx_post; + if (dir == DMA_FROM_DEVICE) { addr = cmd->write_va; rkey = cmd->write_stag; @@ -2151,11 +2154,15 @@ isert_rdma_rw_ctx_post(struct isert_cmd se_cmd->t_data_sg, se_cmd->t_data_nents, offset, addr, rkey, dir); } + if (ret < 0) { isert_err("Cmd: %p failed to prepare RDMA res\n", cmd); return ret; } + cmd->ctx_init_done = true; + +rdma_ctx_post: ret = rdma_rw_ctx_post(&cmd->rw, conn->qp, port_num, cqe, chain_wr); if (ret < 0) isert_err("Cmd: %p failed to post RDMA res\n", cmd); --- a/drivers/infiniband/ulp/isert/ib_isert.h +++ b/drivers/infiniband/ulp/isert/ib_isert.h @@ -126,6 +126,7 @@ struct isert_cmd { struct rdma_rw_ctx rw; struct work_struct comp_work; struct scatterlist sg; + bool ctx_init_done; }; static inline struct isert_cmd *tx_desc_to_cmd(struct iser_tx_desc *desc) Patches currently in stable-queue which might be from bharat(a)chelsio.com are queue-4.14/iser-target-avoid-reinitializing-rdma-contexts-for-isert-commands.patch

7 years, 6 months

1
0
0 0

Patch "ip_gre: fix potential memory leak in erspan_rcv" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled ip_gre: fix potential memory leak in erspan_rcv to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: ip_gre-fix-potential-memory-leak-in-erspan_rcv.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Thu Mar 22 14:26:48 CET 2018 From: Haishuang Yan <yanhaishuang(a)cmss.chinamobile.com> Date: Wed, 20 Dec 2017 10:07:00 +0800 Subject: ip_gre: fix potential memory leak in erspan_rcv From: Haishuang Yan <yanhaishuang(a)cmss.chinamobile.com> [ Upstream commit 50670b6ee9bc4ae8f9ce3112b437987adf273245 ] If md is NULL, tun_dst must be freed, otherwise it will cause memory leak. Fixes: 1a66a836da6 ("gre: add collect_md mode to ERSPAN tunnel") Cc: William Tu <u9012063(a)gmail.com> Signed-off-by: Haishuang Yan <yanhaishuang(a)cmss.chinamobile.com> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- net/ipv4/ip_gre.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) --- a/net/ipv4/ip_gre.c +++ b/net/ipv4/ip_gre.c @@ -303,8 +303,10 @@ static int erspan_rcv(struct sk_buff *sk return PACKET_REJECT; md = ip_tunnel_info_opts(&tun_dst->u.tun_info); - if (!md) + if (!md) { + dst_release((struct dst_entry *)tun_dst); return PACKET_REJECT; + } md->index = index; info = &tun_dst->u.tun_info; Patches currently in stable-queue which might be from yanhaishuang(a)cmss.chinamobile.com are queue-4.14/ip_gre-fix-error-path-when-erspan_rcv-failed.patch queue-4.14/ip_gre-fix-potential-memory-leak-in-erspan_rcv.patch

7 years, 6 months

1
0
0 0

Patch "ip_gre: fix error path when erspan_rcv failed" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled ip_gre: fix error path when erspan_rcv failed to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: ip_gre-fix-error-path-when-erspan_rcv-failed.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Thu Mar 22 14:26:48 CET 2018 From: Haishuang Yan <yanhaishuang(a)cmss.chinamobile.com> Date: Wed, 20 Dec 2017 10:21:46 +0800 Subject: ip_gre: fix error path when erspan_rcv failed From: Haishuang Yan <yanhaishuang(a)cmss.chinamobile.com> [ Upstream commit dd8d5b8c5b22e31079b259b8bfb686f1fac1080a ] When erspan_rcv call return PACKET_REJECT, we shoudn't call ipgre_rcv to process packets again, instead send icmp unreachable message in error path. Fixes: 84e54fe0a5ea ("gre: introduce native tunnel support for ERSPAN") Acked-by: William Tu <u9012063(a)gmail.com> Cc: William Tu <u9012063(a)gmail.com> Signed-off-by: Haishuang Yan <yanhaishuang(a)cmss.chinamobile.com> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- net/ipv4/ip_gre.c | 2 ++ 1 file changed, 2 insertions(+) --- a/net/ipv4/ip_gre.c +++ b/net/ipv4/ip_gre.c @@ -408,11 +408,13 @@ static int gre_rcv(struct sk_buff *skb) if (unlikely(tpi.proto == htons(ETH_P_ERSPAN))) { if (erspan_rcv(skb, &tpi, hdr_len) == PACKET_RCVD) return 0; + goto out; } if (ipgre_rcv(skb, &tpi, hdr_len) == PACKET_RCVD) return 0; +out: icmp_send(skb, ICMP_DEST_UNREACH, ICMP_PORT_UNREACH, 0); drop: kfree_skb(skb); Patches currently in stable-queue which might be from yanhaishuang(a)cmss.chinamobile.com are queue-4.14/ip_gre-fix-error-path-when-erspan_rcv-failed.patch queue-4.14/ip_gre-fix-potential-memory-leak-in-erspan_rcv.patch

7 years, 6 months

1
0
0 0

Patch "ip6_vti: adjust vti mtu according to mtu of lower device" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled ip6_vti: adjust vti mtu according to mtu of lower device to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: ip6_vti-adjust-vti-mtu-according-to-mtu-of-lower-device.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Thu Mar 22 14:26:48 CET 2018 From: Alexey Kodanev <alexey.kodanev(a)oracle.com> Date: Tue, 19 Dec 2017 16:59:21 +0300 Subject: ip6_vti: adjust vti mtu according to mtu of lower device From: Alexey Kodanev <alexey.kodanev(a)oracle.com> [ Upstream commit 53c81e95df1793933f87748d36070a721f6cb287 ] LTP/udp6_ipsec_vti tests fail when sending large UDP datagrams over ip6_vti that require fragmentation and the underlying device has an MTU smaller than 1500 plus some extra space for headers. This happens because ip6_vti, by default, sets MTU to ETH_DATA_LEN and not updating it depending on a destination address or link parameter. Further attempts to send UDP packets may succeed because pmtu gets updated on ICMPV6_PKT_TOOBIG in vti6_err(). In case the lower device has larger MTU size, e.g. 9000, ip6_vti works but not using the possible maximum size, output packets have 1500 limit. The above cases require manual MTU setup after ip6_vti creation. However ip_vti already updates MTU based on lower device with ip_tunnel_bind_dev(). Here is the example when the lower device MTU is set to 9000: # ip a sh ltp_ns_veth2 ltp_ns_veth2@if7: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 ... inet 10.0.0.2/24 scope global ltp_ns_veth2 inet6 fd00::2/64 scope global # ip li add vti6 type vti6 local fd00::2 remote fd00::1 # ip li show vti6 vti6@NONE: <POINTOPOINT,NOARP> mtu 1500 ... link/tunnel6 fd00::2 peer fd00::1 After the patch: # ip li add vti6 type vti6 local fd00::2 remote fd00::1 # ip li show vti6 vti6@NONE: <POINTOPOINT,NOARP> mtu 8832 ... link/tunnel6 fd00::2 peer fd00::1 Reported-by: Petr Vorel <pvorel(a)suse.cz> Signed-off-by: Alexey Kodanev <alexey.kodanev(a)oracle.com> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- net/ipv6/ip6_vti.c | 20 ++++++++++++++++++++ 1 file changed, 20 insertions(+) --- a/net/ipv6/ip6_vti.c +++ b/net/ipv6/ip6_vti.c @@ -626,6 +626,7 @@ static void vti6_link_config(struct ip6_ { struct net_device *dev = t->dev; struct __ip6_tnl_parm *p = &t->parms; + struct net_device *tdev = NULL; memcpy(dev->dev_addr, &p->laddr, sizeof(struct in6_addr)); memcpy(dev->broadcast, &p->raddr, sizeof(struct in6_addr)); @@ -638,6 +639,25 @@ static void vti6_link_config(struct ip6_ dev->flags |= IFF_POINTOPOINT; else dev->flags &= ~IFF_POINTOPOINT; + + if (p->flags & IP6_TNL_F_CAP_XMIT) { + int strict = (ipv6_addr_type(&p->raddr) & + (IPV6_ADDR_MULTICAST | IPV6_ADDR_LINKLOCAL)); + struct rt6_info *rt = rt6_lookup(t->net, + &p->raddr, &p->laddr, + p->link, strict); + + if (rt) + tdev = rt->dst.dev; + ip6_rt_put(rt); + } + + if (!tdev && p->link) + tdev = __dev_get_by_index(t->net, p->link); + + if (tdev) + dev->mtu = max_t(int, tdev->mtu - dev->hard_header_len, + IPV6_MIN_MTU); } /** Patches currently in stable-queue which might be from alexey.kodanev(a)oracle.com are queue-4.14/ip6_vti-adjust-vti-mtu-according-to-mtu-of-lower-device.patch

7 years, 6 months

1
0
0 0

Patch "iommu/vt-d: clean up pr_irq if request_threaded_irq fails" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled iommu/vt-d: clean up pr_irq if request_threaded_irq fails to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: iommu-vt-d-clean-up-pr_irq-if-request_threaded_irq-fails.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Thu Mar 22 14:26:48 CET 2018 From: Jerry Snitselaar <jsnitsel(a)redhat.com> Date: Wed, 20 Dec 2017 09:48:56 -0700 Subject: iommu/vt-d: clean up pr_irq if request_threaded_irq fails From: Jerry Snitselaar <jsnitsel(a)redhat.com> [ Upstream commit 72d548113881dd32bf7f0b221d031e6586468437 ] It is unlikely request_threaded_irq will fail, but if it does for some reason we should clear iommu->pr_irq in the error path. Also intel_svm_finish_prq shouldn't try to clean up the page request interrupt if pr_irq is 0. Without these, if request_threaded_irq were to fail the following occurs: fail with no fixes: [ 0.683147] ------------[ cut here ]------------ [ 0.683148] NULL pointer, cannot free irq [ 0.683158] WARNING: CPU: 1 PID: 1 at kernel/irq/irqdomain.c:1632 irq_domain_free_irqs+0x126/0x140 [ 0.683160] Modules linked in: [ 0.683163] CPU: 1 PID: 1 Comm: swapper/0 Not tainted 4.15.0-rc2 #3 [ 0.683165] Hardware name: /NUC7i3BNB, BIOS BNKBL357.86A.0036.2017.0105.1112 01/05/2017 [ 0.683168] RIP: 0010:irq_domain_free_irqs+0x126/0x140 [ 0.683169] RSP: 0000:ffffc90000037ce8 EFLAGS: 00010292 [ 0.683171] RAX: 000000000000001d RBX: ffff880276283c00 RCX: ffffffff81c5e5e8 [ 0.683172] RDX: 0000000000000001 RSI: 0000000000000096 RDI: 0000000000000246 [ 0.683174] RBP: ffff880276283c00 R08: 0000000000000000 R09: 000000000000023c [ 0.683175] R10: 0000000000000007 R11: 0000000000000000 R12: 000000000000007a [ 0.683176] R13: 0000000000000001 R14: 0000000000000000 R15: 0000010010000000 [ 0.683178] FS: 0000000000000000(0000) GS:ffff88027ec80000(0000) knlGS:0000000000000000 [ 0.683180] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 0.683181] CR2: 0000000000000000 CR3: 0000000001c09001 CR4: 00000000003606e0 [ 0.683182] Call Trace: [ 0.683189] intel_svm_finish_prq+0x3c/0x60 [ 0.683191] free_dmar_iommu+0x1ac/0x1b0 [ 0.683195] init_dmars+0xaaa/0xaea [ 0.683200] ? klist_next+0x19/0xc0 [ 0.683203] ? pci_do_find_bus+0x50/0x50 [ 0.683205] ? pci_get_dev_by_id+0x52/0x70 [ 0.683208] intel_iommu_init+0x498/0x5c7 [ 0.683211] pci_iommu_init+0x13/0x3c [ 0.683214] ? e820__memblock_setup+0x61/0x61 [ 0.683217] do_one_initcall+0x4d/0x1a0 [ 0.683220] kernel_init_freeable+0x186/0x20e [ 0.683222] ? set_debug_rodata+0x11/0x11 [ 0.683225] ? rest_init+0xb0/0xb0 [ 0.683226] kernel_init+0xa/0xff [ 0.683229] ret_from_fork+0x1f/0x30 [ 0.683259] Code: 89 ee 44 89 e7 e8 3b e8 ff ff 5b 5d 44 89 e7 44 89 ee 41 5c 41 5d 41 5e e9 a8 84 ff ff 48 c7 c7 a8 71 a7 81 31 c0 e8 6a d3 f9 ff <0f> ff 5b 5d 41 5c 41 5d 41 5 e c3 0f 1f 44 00 00 66 2e 0f 1f 84 [ 0.683285] ---[ end trace f7650e42792627ca ]--- with iommu->pr_irq = 0, but no check in intel_svm_finish_prq: [ 0.669561] ------------[ cut here ]------------ [ 0.669563] Trying to free already-free IRQ 0 [ 0.669573] WARNING: CPU: 3 PID: 1 at kernel/irq/manage.c:1546 __free_irq+0xa4/0x2c0 [ 0.669574] Modules linked in: [ 0.669577] CPU: 3 PID: 1 Comm: swapper/0 Not tainted 4.15.0-rc2 #4 [ 0.669579] Hardware name: /NUC7i3BNB, BIOS BNKBL357.86A.0036.2017.0105.1112 01/05/2017 [ 0.669581] RIP: 0010:__free_irq+0xa4/0x2c0 [ 0.669582] RSP: 0000:ffffc90000037cc0 EFLAGS: 00010082 [ 0.669584] RAX: 0000000000000021 RBX: 0000000000000000 RCX: ffffffff81c5e5e8 [ 0.669585] RDX: 0000000000000001 RSI: 0000000000000086 RDI: 0000000000000046 [ 0.669587] RBP: 0000000000000000 R08: 0000000000000000 R09: 000000000000023c [ 0.669588] R10: 0000000000000007 R11: 0000000000000000 R12: ffff880276253960 [ 0.669589] R13: ffff8802762538a4 R14: ffff880276253800 R15: ffff880276283600 [ 0.669593] FS: 0000000000000000(0000) GS:ffff88027ed80000(0000) knlGS:0000000000000000 [ 0.669594] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 0.669596] CR2: 0000000000000000 CR3: 0000000001c09001 CR4: 00000000003606e0 [ 0.669602] Call Trace: [ 0.669616] free_irq+0x30/0x60 [ 0.669620] intel_svm_finish_prq+0x34/0x60 [ 0.669623] free_dmar_iommu+0x1ac/0x1b0 [ 0.669627] init_dmars+0xaaa/0xaea [ 0.669631] ? klist_next+0x19/0xc0 [ 0.669634] ? pci_do_find_bus+0x50/0x50 [ 0.669637] ? pci_get_dev_by_id+0x52/0x70 [ 0.669639] intel_iommu_init+0x498/0x5c7 [ 0.669642] pci_iommu_init+0x13/0x3c [ 0.669645] ? e820__memblock_setup+0x61/0x61 [ 0.669648] do_one_initcall+0x4d/0x1a0 [ 0.669651] kernel_init_freeable+0x186/0x20e [ 0.669653] ? set_debug_rodata+0x11/0x11 [ 0.669656] ? rest_init+0xb0/0xb0 [ 0.669658] kernel_init+0xa/0xff [ 0.669661] ret_from_fork+0x1f/0x30 [ 0.669662] Code: 7a 08 75 0e e9 c3 01 00 00 4c 39 7b 08 74 57 48 89 da 48 8b 5a 18 48 85 db 75 ee 89 ee 48 c7 c7 78 67 a7 81 31 c0 e8 4c 37 fa ff <0f> ff 48 8b 34 24 4c 89 ef e 8 0e 4c 68 00 49 8b 46 40 48 8b 80 [ 0.669688] ---[ end trace 58a470248700f2fc ]--- Cc: Alex Williamson <alex.williamson(a)redhat.com> Cc: Joerg Roedel <joro(a)8bytes.org> Cc: Ashok Raj <ashok.raj(a)intel.com> Signed-off-by: Jerry Snitselaar <jsnitsel(a)redhat.com> Reviewed-by: Ashok Raj <ashok.raj(a)intel.com> Signed-off-by: Alex Williamson <alex.williamson(a)redhat.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/iommu/intel-svm.c | 9 ++++++--- 1 file changed, 6 insertions(+), 3 deletions(-) --- a/drivers/iommu/intel-svm.c +++ b/drivers/iommu/intel-svm.c @@ -129,6 +129,7 @@ int intel_svm_enable_prq(struct intel_io pr_err("IOMMU: %s: Failed to request IRQ for page request queue\n", iommu->name); dmar_free_hwirq(irq); + iommu->pr_irq = 0; goto err; } dmar_writeq(iommu->reg + DMAR_PQH_REG, 0ULL); @@ -144,9 +145,11 @@ int intel_svm_finish_prq(struct intel_io dmar_writeq(iommu->reg + DMAR_PQT_REG, 0ULL); dmar_writeq(iommu->reg + DMAR_PQA_REG, 0ULL); - free_irq(iommu->pr_irq, iommu); - dmar_free_hwirq(iommu->pr_irq); - iommu->pr_irq = 0; + if (iommu->pr_irq) { + free_irq(iommu->pr_irq, iommu); + dmar_free_hwirq(iommu->pr_irq); + iommu->pr_irq = 0; + } free_pages((unsigned long)iommu->prq, PRQ_ORDER); iommu->prq = NULL; Patches currently in stable-queue which might be from jsnitsel(a)redhat.com are queue-4.14/iommu-vt-d-clean-up-pr_irq-if-request_threaded_irq-fails.patch

7 years, 6 months

1
0
0 0

Patch "IB/umem: Fix use of npages/nmap fields" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled IB/umem: Fix use of npages/nmap fields to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: ib-umem-fix-use-of-npages-nmap-fields.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Thu Mar 22 14:26:48 CET 2018 From: Artemy Kovalyov <artemyko(a)mellanox.com> Date: Tue, 14 Nov 2017 14:51:59 +0200 Subject: IB/umem: Fix use of npages/nmap fields From: Artemy Kovalyov <artemyko(a)mellanox.com> [ Upstream commit edf1a84fe37c51290e2c88154ecaf48dadff3d27 ] In ib_umem structure npages holds original number of sg entries, while nmap is number of DMA blocks returned by dma_map_sg. Fixes: c5d76f130b28 ('IB/core: Add umem function to read data from user-space') Signed-off-by: Artemy Kovalyov <artemyko(a)mellanox.com> Signed-off-by: Leon Romanovsky <leon(a)kernel.org> Signed-off-by: Jason Gunthorpe <jgg(a)mellanox.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/infiniband/core/umem.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/drivers/infiniband/core/umem.c +++ b/drivers/infiniband/core/umem.c @@ -352,7 +352,7 @@ int ib_umem_copy_from(void *dst, struct return -EINVAL; } - ret = sg_pcopy_to_buffer(umem->sg_head.sgl, umem->nmap, dst, length, + ret = sg_pcopy_to_buffer(umem->sg_head.sgl, umem->npages, dst, length, offset + ib_umem_offset(umem)); if (ret < 0) Patches currently in stable-queue which might be from artemyko(a)mellanox.com are queue-4.14/ib-umem-fix-use-of-npages-nmap-fields.patch

7 years, 6 months

1
0
0 0

Patch "IB/ipoib: Avoid memory leak if the SA returns a different DGID" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled IB/ipoib: Avoid memory leak if the SA returns a different DGID to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: ib-ipoib-avoid-memory-leak-if-the-sa-returns-a-different-dgid.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Thu Mar 22 14:26:48 CET 2018 From: Erez Shitrit <erezsh(a)mellanox.com> Date: Tue, 14 Nov 2017 14:51:53 +0200 Subject: IB/ipoib: Avoid memory leak if the SA returns a different DGID From: Erez Shitrit <erezsh(a)mellanox.com> [ Upstream commit 439000892ee17a9c92f1e4297818790ef8bb4ced ] The ipoib path database is organized around DGIDs from the LLADDR, but the SA is free to return a different GID when asked for path. This causes a bug because the SA's modified DGID is copied into the database key, even though it is no longer the correct lookup key, causing a memory leak and other malfunctions. Ensure the database key does not change after the SA query completes. Demonstration of the bug is as follows ipoib wants to send to GID fe80:0000:0000:0000:0002:c903:00ef:5ee2, it creates new record in the DB with that gid as a key, and issues a new request to the SM. Now, the SM from some reason returns path-record with other SGID (for example, 2001:0000:0000:0000:0002:c903:00ef:5ee2 that contains the local subnet prefix) now ipoib will overwrite the current entry with the new one, and if new request to the original GID arrives ipoib will not find it in the DB (was overwritten) and will create new record that in its turn will also be overwritten by the response from the SM, and so on till the driver eats all the device memory. Signed-off-by: Erez Shitrit <erezsh(a)mellanox.com> Signed-off-by: Leon Romanovsky <leon(a)kernel.org> Signed-off-by: Jason Gunthorpe <jgg(a)mellanox.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/infiniband/ulp/ipoib/ipoib_main.c | 16 ++++++++++++++++ 1 file changed, 16 insertions(+) --- a/drivers/infiniband/ulp/ipoib/ipoib_main.c +++ b/drivers/infiniband/ulp/ipoib/ipoib_main.c @@ -776,6 +776,22 @@ static void path_rec_completion(int stat spin_lock_irqsave(&priv->lock, flags); if (!IS_ERR_OR_NULL(ah)) { + /* + * pathrec.dgid is used as the database key from the LLADDR, + * it must remain unchanged even if the SA returns a different + * GID to use in the AH. + */ + if (memcmp(pathrec->dgid.raw, path->pathrec.dgid.raw, + sizeof(union ib_gid))) { + ipoib_dbg( + priv, + "%s got PathRec for gid %pI6 while asked for %pI6\n", + dev->name, pathrec->dgid.raw, + path->pathrec.dgid.raw); + memcpy(pathrec->dgid.raw, path->pathrec.dgid.raw, + sizeof(union ib_gid)); + } + path->pathrec = *pathrec; old_ah = path->ah; Patches currently in stable-queue which might be from erezsh(a)mellanox.com are queue-4.14/ib-ipoib-avoid-memory-leak-if-the-sa-returns-a-different-dgid.patch

7 years, 6 months

1
0
0 0

Patch "hv_netvsc: Fix the TX/RX buffer default sizes" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled hv_netvsc: Fix the TX/RX buffer default sizes to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: hv_netvsc-fix-the-tx-rx-buffer-default-sizes.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Thu Mar 22 14:26:48 CET 2018 From: Haiyang Zhang <haiyangz(a)microsoft.com> Date: Mon, 11 Dec 2017 08:56:58 -0800 Subject: hv_netvsc: Fix the TX/RX buffer default sizes From: Haiyang Zhang <haiyangz(a)microsoft.com> [ Upstream commit 41f61db2cd24d5ad802386719cccde1479aa82a6 ] The values were not computed correctly. There are no significant visible impact, though. The intended size of RX buffer is 16 MB, and the default slot size is 1728. So, NETVSC_DEFAULT_RX should be 16*1024*1024 / 1728 = 9709. The intended size of TX buffer is 1 MB, and the slot size is 6144. So, NETVSC_DEFAULT_TX should be 1024*1024 / 6144 = 170. The patch puts the formula directly into the macro, and moves them to hyperv_net.h, together with related macros. Fixes: 5023a6db73196 ("netvsc: increase default receive buffer size") Signed-off-by: Haiyang Zhang <haiyangz(a)microsoft.com> Signed-off-by: Stephen Hemminger <sthemmin(a)microsoft.com> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/net/hyperv/hyperv_net.h | 13 ++++++++++++- drivers/net/hyperv/netvsc_drv.c | 4 ---- 2 files changed, 12 insertions(+), 5 deletions(-) --- a/drivers/net/hyperv/hyperv_net.h +++ b/drivers/net/hyperv/hyperv_net.h @@ -638,13 +638,24 @@ struct nvsp_message { /* Max buffer sizes allowed by a host */ #define NETVSC_RECEIVE_BUFFER_SIZE (1024 * 1024 * 31) /* 31MB */ #define NETVSC_RECEIVE_BUFFER_SIZE_LEGACY (1024 * 1024 * 15) /* 15MB */ -#define NETVSC_SEND_BUFFER_SIZE (1024 * 1024 * 15) /* 15MB */ +#define NETVSC_RECEIVE_BUFFER_DEFAULT (1024 * 1024 * 16) + +#define NETVSC_SEND_BUFFER_SIZE (1024 * 1024 * 15) /* 15MB */ +#define NETVSC_SEND_BUFFER_DEFAULT (1024 * 1024) #define NETVSC_INVALID_INDEX -1 #define NETVSC_SEND_SECTION_SIZE 6144 #define NETVSC_RECV_SECTION_SIZE 1728 +/* Default size of TX buf: 1MB, RX buf: 16MB */ +#define NETVSC_MIN_TX_SECTIONS 10 +#define NETVSC_DEFAULT_TX (NETVSC_SEND_BUFFER_DEFAULT \ + / NETVSC_SEND_SECTION_SIZE) +#define NETVSC_MIN_RX_SECTIONS 10 +#define NETVSC_DEFAULT_RX (NETVSC_RECEIVE_BUFFER_DEFAULT \ + / NETVSC_RECV_SECTION_SIZE) + #define NETVSC_RECEIVE_BUFFER_ID 0xcafe #define NETVSC_SEND_BUFFER_ID 0 --- a/drivers/net/hyperv/netvsc_drv.c +++ b/drivers/net/hyperv/netvsc_drv.c @@ -46,10 +46,6 @@ #include "hyperv_net.h" #define RING_SIZE_MIN 64 -#define NETVSC_MIN_TX_SECTIONS 10 -#define NETVSC_DEFAULT_TX 192 /* ~1M */ -#define NETVSC_MIN_RX_SECTIONS 10 /* ~64K */ -#define NETVSC_DEFAULT_RX 10485 /* Max ~16M */ #define LINKCHANGE_INT (2 * HZ) #define VF_TAKEOVER_INT (HZ / 10) Patches currently in stable-queue which might be from haiyangz(a)microsoft.com are queue-4.14/hv_netvsc-fix-the-tx-rx-buffer-default-sizes.patch queue-4.14/hv_netvsc-fix-the-receive-buffer-size-limit.patch

7 years, 6 months

1
0
0 0

Patch "hv_netvsc: Fix the receive buffer size limit" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled hv_netvsc: Fix the receive buffer size limit to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: hv_netvsc-fix-the-receive-buffer-size-limit.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Thu Mar 22 14:26:48 CET 2018 From: Haiyang Zhang <haiyangz(a)microsoft.com> Date: Mon, 11 Dec 2017 08:56:57 -0800 Subject: hv_netvsc: Fix the receive buffer size limit From: Haiyang Zhang <haiyangz(a)microsoft.com> [ Upstream commit 11b2b653102571ac791885324371d9a1a17b900e ] The max should be 31 MB on host with NVSP version > 2. On legacy hosts (NVSP version <=2) only 15 MB receive buffer is allowed, otherwise the buffer request will be rejected by the host, resulting vNIC not coming up. The NVSP version is only available after negotiation. So, we add the limit checking for legacy hosts in netvsc_init_buf(). Fixes: 5023a6db73196 ("netvsc: increase default receive buffer size") Signed-off-by: Haiyang Zhang <haiyangz(a)microsoft.com> Signed-off-by: Stephen Hemminger <sthemmin(a)microsoft.com> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/net/hyperv/hyperv_net.h | 6 ++++-- drivers/net/hyperv/netvsc.c | 5 +++++ 2 files changed, 9 insertions(+), 2 deletions(-) --- a/drivers/net/hyperv/hyperv_net.h +++ b/drivers/net/hyperv/hyperv_net.h @@ -635,9 +635,11 @@ struct nvsp_message { #define NETVSC_MTU 65535 #define NETVSC_MTU_MIN ETH_MIN_MTU -#define NETVSC_RECEIVE_BUFFER_SIZE (1024*1024*16) /* 16MB */ -#define NETVSC_RECEIVE_BUFFER_SIZE_LEGACY (1024*1024*15) /* 15MB */ +/* Max buffer sizes allowed by a host */ +#define NETVSC_RECEIVE_BUFFER_SIZE (1024 * 1024 * 31) /* 31MB */ +#define NETVSC_RECEIVE_BUFFER_SIZE_LEGACY (1024 * 1024 * 15) /* 15MB */ #define NETVSC_SEND_BUFFER_SIZE (1024 * 1024 * 15) /* 15MB */ + #define NETVSC_INVALID_INDEX -1 #define NETVSC_SEND_SECTION_SIZE 6144 --- a/drivers/net/hyperv/netvsc.c +++ b/drivers/net/hyperv/netvsc.c @@ -262,6 +262,11 @@ static int netvsc_init_buf(struct hv_dev buf_size = device_info->recv_sections * device_info->recv_section_size; buf_size = roundup(buf_size, PAGE_SIZE); + /* Legacy hosts only allow smaller receive buffer */ + if (net_device->nvsp_version <= NVSP_PROTOCOL_VERSION_2) + buf_size = min_t(unsigned int, buf_size, + NETVSC_RECEIVE_BUFFER_SIZE_LEGACY); + net_device->recv_buf = vzalloc(buf_size); if (!net_device->recv_buf) { netdev_err(ndev, Patches currently in stable-queue which might be from haiyangz(a)microsoft.com are queue-4.14/hv_netvsc-fix-the-tx-rx-buffer-default-sizes.patch queue-4.14/hv_netvsc-fix-the-receive-buffer-size-limit.patch

7 years, 6 months

1
0
0 0

Patch "drm/tilcdc: ensure nonatomic iowrite64 is not used" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled drm/tilcdc: ensure nonatomic iowrite64 is not used to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: drm-tilcdc-ensure-nonatomic-iowrite64-is-not-used.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Thu Mar 22 14:26:48 CET 2018 From: Logan Gunthorpe <logang(a)deltatee.com> Date: Tue, 5 Dec 2017 16:30:51 -0700 Subject: drm/tilcdc: ensure nonatomic iowrite64 is not used From: Logan Gunthorpe <logang(a)deltatee.com> [ Upstream commit 4e5ca2d930aa8714400aedf4bf1dc959cb04280f ] Add a check to ensure iowrite64 is only used if it is atomic. It was decided in [1] that the tilcdc driver should not be using an atomic operation (so it was left out of this patchset). However, it turns out that through the drm code, a nonatomic header is actually included: include/linux/io-64-nonatomic-lo-hi.h is included from include/drm/drm_os_linux.h:9:0, from include/drm/drmP.h:74, from include/drm/drm_modeset_helper.h:26, from include/drm/drm_atomic_helper.h:33, from drivers/gpu/drm/tilcdc/tilcdc_crtc.c:19: And thus, without this change, this patchset would inadvertantly change the behaviour of the tilcdc driver. [1] lkml.kernel.org/r/CAK8P3a2HhO_zCnsTzq7hmWSz5La5Thu19FWZpun16iMnyyNreQ@mail.… Signed-off-by: Logan Gunthorpe <logang(a)deltatee.com> Reviewed-by: Andy Shevchenko <andy.shevchenko(a)gmail.com> Cc: Jyri Sarha <jsarha(a)ti.com> Cc: Arnd Bergmann <arnd(a)arndb.de> Cc: Tomi Valkeinen <tomi.valkeinen(a)ti.com> Cc: David Airlie <airlied(a)linux.ie> Signed-off-by: Jyri Sarha <jsarha(a)ti.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/gpu/drm/tilcdc/tilcdc_regs.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/drivers/gpu/drm/tilcdc/tilcdc_regs.h +++ b/drivers/gpu/drm/tilcdc/tilcdc_regs.h @@ -133,7 +133,7 @@ static inline void tilcdc_write64(struct struct tilcdc_drm_private *priv = dev->dev_private; volatile void __iomem *addr = priv->mmio + reg; -#ifdef iowrite64 +#if defined(iowrite64) && !defined(iowrite64_is_nonatomic) iowrite64(data, addr); #else __iowmb(); Patches currently in stable-queue which might be from logang(a)deltatee.com are queue-4.14/drm-tilcdc-ensure-nonatomic-iowrite64-is-not-used.patch

7 years, 6 months

1
0
0 0

Patch "drm/omap: DMM: Check for DMM readiness after successful transaction commit" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled drm/omap: DMM: Check for DMM readiness after successful transaction commit to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: drm-omap-dmm-check-for-dmm-readiness-after-successful-transaction-commit.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Thu Mar 22 14:26:48 CET 2018 From: Peter Ujfalusi <peter.ujfalusi(a)ti.com> Date: Fri, 29 Sep 2017 14:49:49 +0300 Subject: drm/omap: DMM: Check for DMM readiness after successful transaction commit From: Peter Ujfalusi <peter.ujfalusi(a)ti.com> [ Upstream commit b7ea6b286c4051e043f691781785e3c4672f014a ] Check the status of the DMM engine after it is reported that the transaction was completed as in rare cases the engine might not reached a working state. The wait_status() will print information in case the DMM is not reached the expected state and the dmm_txn_commit() will return with an error code to make sure that we are not continuing with a broken setup. Signed-off-by: Peter Ujfalusi <peter.ujfalusi(a)ti.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen(a)ti.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/gpu/drm/omapdrm/omap_dmm_tiler.c | 5 +++++ 1 file changed, 5 insertions(+) --- a/drivers/gpu/drm/omapdrm/omap_dmm_tiler.c +++ b/drivers/gpu/drm/omapdrm/omap_dmm_tiler.c @@ -298,7 +298,12 @@ static int dmm_txn_commit(struct dmm_txn msecs_to_jiffies(100))) { dev_err(dmm->dev, "timed out waiting for done\n"); ret = -ETIMEDOUT; + goto cleanup; } + + /* Check the engine status before continue */ + ret = wait_status(engine, DMM_PATSTATUS_READY | + DMM_PATSTATUS_VALID | DMM_PATSTATUS_DONE); } cleanup: Patches currently in stable-queue which might be from peter.ujfalusi(a)ti.com are queue-4.14/drm-omap-dmm-check-for-dmm-readiness-after-successful-transaction-commit.patch queue-4.14/dmaengine-ti-dma-crossbar-fix-event-mapping-for-tpcc_evt_mux_60_63.patch

7 years, 6 months

1
0
0 0

Patch "drm/msm: fix leak in failed get_pages" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled drm/msm: fix leak in failed get_pages to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: drm-msm-fix-leak-in-failed-get_pages.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Thu Mar 22 14:26:48 CET 2018 From: Prakash Kamliya <pkamliya(a)codeaurora.org> Date: Mon, 4 Dec 2017 19:10:15 +0530 Subject: drm/msm: fix leak in failed get_pages From: Prakash Kamliya <pkamliya(a)codeaurora.org> [ Upstream commit 62e3a3e342af3c313ab38603811ecdb1fcc79edb ] get_pages doesn't keep a reference of the pages allocated when it fails later in the code path. This can lead to a memory leak. Keep reference of the allocated pages so that it can be freed when msm_gem_free_object gets called later during cleanup. Signed-off-by: Prakash Kamliya <pkamliya(a)codeaurora.org> Signed-off-by: Sharat Masetty <smasetty(a)codeaurora.org> Signed-off-by: Rob Clark <robdclark(a)gmail.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/gpu/drm/msm/msm_gem.c | 14 ++++++++++---- 1 file changed, 10 insertions(+), 4 deletions(-) --- a/drivers/gpu/drm/msm/msm_gem.c +++ b/drivers/gpu/drm/msm/msm_gem.c @@ -93,14 +93,17 @@ static struct page **get_pages(struct dr return p; } + msm_obj->pages = p; + msm_obj->sgt = drm_prime_pages_to_sg(p, npages); if (IS_ERR(msm_obj->sgt)) { + void *ptr = ERR_CAST(msm_obj->sgt); + dev_err(dev->dev, "failed to allocate sgt\n"); - return ERR_CAST(msm_obj->sgt); + msm_obj->sgt = NULL; + return ptr; } - msm_obj->pages = p; - /* For non-cached buffers, ensure the new pages are clean * because display controller, GPU, etc. are not coherent: */ @@ -135,7 +138,10 @@ static void put_pages(struct drm_gem_obj if (msm_obj->flags & (MSM_BO_WC|MSM_BO_UNCACHED)) dma_unmap_sg(obj->dev->dev, msm_obj->sgt->sgl, msm_obj->sgt->nents, DMA_BIDIRECTIONAL); - sg_free_table(msm_obj->sgt); + + if (msm_obj->sgt) + sg_free_table(msm_obj->sgt); + kfree(msm_obj->sgt); if (use_pages(obj)) Patches currently in stable-queue which might be from pkamliya(a)codeaurora.org are queue-4.14/drm-msm-fix-leak-in-failed-get_pages.patch

7 years, 6 months

1
0
0 0

Patch "dmaengine: zynqmp_dma: Fix race condition in the probe" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled dmaengine: zynqmp_dma: Fix race condition in the probe to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: dmaengine-zynqmp_dma-fix-race-condition-in-the-probe.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Thu Mar 22 14:26:48 CET 2018 From: Kedareswara rao Appana <appana.durga.rao(a)xilinx.com> Date: Thu, 7 Dec 2017 10:54:28 +0530 Subject: dmaengine: zynqmp_dma: Fix race condition in the probe From: Kedareswara rao Appana <appana.durga.rao(a)xilinx.com> [ Upstream commit 5ba080aada5e739165e0f38d5cc3b04c82b323c8 ] Incase of interrupt property is not present, Driver is trying to free an invalid irq, This patch fixes it by adding a check before freeing the irq. Signed-off-by: Kedareswara rao Appana <appanad(a)xilinx.com> Signed-off-by: Vinod Koul <vinod.koul(a)intel.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/dma/xilinx/zynqmp_dma.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) --- a/drivers/dma/xilinx/zynqmp_dma.c +++ b/drivers/dma/xilinx/zynqmp_dma.c @@ -838,7 +838,8 @@ static void zynqmp_dma_chan_remove(struc if (!chan) return; - devm_free_irq(chan->zdev->dev, chan->irq, chan); + if (chan->irq) + devm_free_irq(chan->zdev->dev, chan->irq, chan); tasklet_kill(&chan->tasklet); list_del(&chan->common.device_node); clk_disable_unprepare(chan->clk_apb); Patches currently in stable-queue which might be from appana.durga.rao(a)xilinx.com are queue-4.14/dmaengine-zynqmp_dma-fix-race-condition-in-the-probe.patch

7 years, 6 months

1
0
0 0

Patch "dmaengine: ti-dma-crossbar: Fix event mapping for TPCC_EVT_MUX_60_63" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled dmaengine: ti-dma-crossbar: Fix event mapping for TPCC_EVT_MUX_60_63 to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: dmaengine-ti-dma-crossbar-fix-event-mapping-for-tpcc_evt_mux_60_63.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Thu Mar 22 14:26:48 CET 2018 From: Vignesh R <vigneshr(a)ti.com> Date: Tue, 19 Dec 2017 12:51:16 +0200 Subject: dmaengine: ti-dma-crossbar: Fix event mapping for TPCC_EVT_MUX_60_63 From: Vignesh R <vigneshr(a)ti.com> [ Upstream commit d087f15786021a9605b20f4c678312510be4cac1 ] Register layout of a typical TPCC_EVT_MUX_M_N register is such that the lowest numbered event is at the lowest byte address and highest numbered event at highest byte address. But TPCC_EVT_MUX_60_63 register layout is different, in that the lowest numbered event is at the highest address and highest numbered event is at the lowest address. Therefore, modify ti_am335x_xbar_write() to handle TPCC_EVT_MUX_60_63 register accordingly. Signed-off-by: Vignesh R <vigneshr(a)ti.com> Signed-off-by: Peter Ujfalusi <peter.ujfalusi(a)ti.com> Signed-off-by: Vinod Koul <vinod.koul(a)intel.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/dma/ti-dma-crossbar.c | 10 +++++++++- 1 file changed, 9 insertions(+), 1 deletion(-) --- a/drivers/dma/ti-dma-crossbar.c +++ b/drivers/dma/ti-dma-crossbar.c @@ -54,7 +54,15 @@ struct ti_am335x_xbar_map { static inline void ti_am335x_xbar_write(void __iomem *iomem, int event, u8 val) { - writeb_relaxed(val, iomem + event); + /* + * TPCC_EVT_MUX_60_63 register layout is different than the + * rest, in the sense, that event 63 is mapped to lowest byte + * and event 60 is mapped to highest, handle it separately. + */ + if (event >= 60 && event <= 63) + writeb_relaxed(val, iomem + (63 - event % 4)); + else + writeb_relaxed(val, iomem + event); } static void ti_am335x_xbar_free(struct device *dev, void *route_data) Patches currently in stable-queue which might be from vigneshr(a)ti.com are queue-4.14/dmaengine-ti-dma-crossbar-fix-event-mapping-for-tpcc_evt_mux_60_63.patch

7 years, 6 months

1
0
0 0

Patch "/dev/mem: Add bounce buffer for copy-out" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled /dev/mem: Add bounce buffer for copy-out to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: dev-mem-add-bounce-buffer-for-copy-out.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Thu Mar 22 14:26:48 CET 2018 From: Kees Cook <keescook(a)chromium.org> Date: Fri, 1 Dec 2017 13:19:39 -0800 Subject: /dev/mem: Add bounce buffer for copy-out From: Kees Cook <keescook(a)chromium.org> [ Upstream commit 22ec1a2aea73b9dfe340dff7945bd85af4cc6280 ] As done for /proc/kcore in commit df04abfd181a ("fs/proc/kcore.c: Add bounce buffer for ktext data") this adds a bounce buffer when reading memory via /dev/mem. This is needed to allow kernel text memory to be read out when built with CONFIG_HARDENED_USERCOPY (which refuses to read out kernel text) and without CONFIG_STRICT_DEVMEM (which would have refused to read any RAM contents at all). Since this build configuration isn't common (most systems with CONFIG_HARDENED_USERCOPY also have CONFIG_STRICT_DEVMEM), this also tries to inform Kconfig about the recommended settings. This patch is modified from Brad Spengler/PaX Team's changes to /dev/mem code in the last public patch of grsecurity/PaX based on my understanding of the code. Changes or omissions from the original code are mine and don't reflect the original grsecurity/PaX code. Reported-by: Michael Holzheu <holzheu(a)linux.vnet.ibm.com> Fixes: f5509cc18daa ("mm: Hardened usercopy") Signed-off-by: Kees Cook <keescook(a)chromium.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/char/mem.c | 27 ++++++++++++++++++++++----- security/Kconfig | 1 + 2 files changed, 23 insertions(+), 5 deletions(-) --- a/drivers/char/mem.c +++ b/drivers/char/mem.c @@ -107,6 +107,8 @@ static ssize_t read_mem(struct file *fil phys_addr_t p = *ppos; ssize_t read, sz; void *ptr; + char *bounce; + int err; if (p != *ppos) return 0; @@ -129,15 +131,22 @@ static ssize_t read_mem(struct file *fil } #endif + bounce = kmalloc(PAGE_SIZE, GFP_KERNEL); + if (!bounce) + return -ENOMEM; + while (count > 0) { unsigned long remaining; int allowed; sz = size_inside_page(p, count); + err = -EPERM; allowed = page_is_allowed(p >> PAGE_SHIFT); if (!allowed) - return -EPERM; + goto failed; + + err = -EFAULT; if (allowed == 2) { /* Show zeros for restricted memory. */ remaining = clear_user(buf, sz); @@ -149,24 +158,32 @@ static ssize_t read_mem(struct file *fil */ ptr = xlate_dev_mem_ptr(p); if (!ptr) - return -EFAULT; - - remaining = copy_to_user(buf, ptr, sz); + goto failed; + err = probe_kernel_read(bounce, ptr, sz); unxlate_dev_mem_ptr(p, ptr); + if (err) + goto failed; + + remaining = copy_to_user(buf, bounce, sz); } if (remaining) - return -EFAULT; + goto failed; buf += sz; p += sz; count -= sz; read += sz; } + kfree(bounce); *ppos += read; return read; + +failed: + kfree(bounce); + return err; } static ssize_t write_mem(struct file *file, const char __user *buf, --- a/security/Kconfig +++ b/security/Kconfig @@ -154,6 +154,7 @@ config HARDENED_USERCOPY bool "Harden memory copies between kernel and userspace" depends on HAVE_HARDENED_USERCOPY_ALLOCATOR select BUG + imply STRICT_DEVMEM help This option checks for obviously wrong memory regions when copying memory to/from the kernel (via copy_to_user() and Patches currently in stable-queue which might be from keescook(a)chromium.org are queue-4.14/dev-mem-add-bounce-buffer-for-copy-out.patch

7 years, 6 months

1
0
0 0

Patch "crypto: artpec6 - set correct iv size for gcm(aes)" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled crypto: artpec6 - set correct iv size for gcm(aes) to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: crypto-artpec6-set-correct-iv-size-for-gcm-aes.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Thu Mar 22 14:26:48 CET 2018 From: Lars Persson <lars.persson(a)axis.com> Date: Tue, 12 Dec 2017 12:40:22 +0100 Subject: crypto: artpec6 - set correct iv size for gcm(aes) From: Lars Persson <lars.persson(a)axis.com> [ Upstream commit 6d6e71feb183aa588c849e20e7baa47cb162928a ] The IV size should not include the 32 bit counter. Because we had the IV size set as 16 the transform only worked when the IV input was zero padded. Fixes: a21eb94fc4d3 ("crypto: axis - add ARTPEC-6/7 crypto accelerator driver") Signed-off-by: Lars Persson <larper(a)axis.com> Signed-off-by: Herbert Xu <herbert(a)gondor.apana.org.au> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/crypto/axis/artpec6_crypto.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) --- a/drivers/crypto/axis/artpec6_crypto.c +++ b/drivers/crypto/axis/artpec6_crypto.c @@ -22,6 +22,7 @@ #include <linux/slab.h> #include <crypto/aes.h> +#include <crypto/gcm.h> #include <crypto/internal/aead.h> #include <crypto/internal/hash.h> #include <crypto/internal/skcipher.h> @@ -1934,7 +1935,7 @@ static int artpec6_crypto_prepare_aead(s memcpy(req_ctx->hw_ctx.J0, areq->iv, crypto_aead_ivsize(cipher)); // The HW omits the initial increment of the counter field. - crypto_inc(req_ctx->hw_ctx.J0+12, 4); + memcpy(req_ctx->hw_ctx.J0 + GCM_AES_IV_SIZE, "\x00\x00\x00\x01", 4); ret = artpec6_crypto_setup_out_descr(common, &req_ctx->hw_ctx, sizeof(struct artpec6_crypto_aead_hw_ctx), false, false); @@ -2956,7 +2957,7 @@ static struct aead_alg aead_algos[] = { .setkey = artpec6_crypto_aead_set_key, .encrypt = artpec6_crypto_aead_encrypt, .decrypt = artpec6_crypto_aead_decrypt, - .ivsize = AES_BLOCK_SIZE, + .ivsize = GCM_AES_IV_SIZE, .maxauthsize = AES_BLOCK_SIZE, .base = { Patches currently in stable-queue which might be from lars.persson(a)axis.com are queue-4.14/crypto-artpec6-set-correct-iv-size-for-gcm-aes.patch

7 years, 6 months

1
0
0 0

Patch "cros_ec: fix nul-termination for firmware build info" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled cros_ec: fix nul-termination for firmware build info to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: cros_ec-fix-nul-termination-for-firmware-build-info.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Thu Mar 22 14:26:48 CET 2018 From: Arnd Bergmann <arnd(a)arndb.de> Date: Mon, 4 Dec 2017 15:49:48 +0100 Subject: cros_ec: fix nul-termination for firmware build info From: Arnd Bergmann <arnd(a)arndb.de> [ Upstream commit 50a0d71a5d20e1d3eff1d974fdc8559ad6d74892 ] As gcc-8 reports, we zero out the wrong byte: drivers/platform/chrome/cros_ec_sysfs.c: In function 'show_ec_version': drivers/platform/chrome/cros_ec_sysfs.c:190:12: error: array subscript 4294967295 is above array bounds of 'uint8_t[]' [-Werror=array-bounds] This changes the code back to what it did before changing to a zero-length array structure. Fixes: a841178445bb ("mfd: cros_ec: Use a zero-length array for command data") Signed-off-by: Arnd Bergmann <arnd(a)arndb.de> Signed-off-by: Benson Leung <bleung(a)chromium.org> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/platform/chrome/cros_ec_sysfs.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/drivers/platform/chrome/cros_ec_sysfs.c +++ b/drivers/platform/chrome/cros_ec_sysfs.c @@ -187,7 +187,7 @@ static ssize_t show_ec_version(struct de count += scnprintf(buf + count, PAGE_SIZE - count, "Build info: EC error %d\n", msg->result); else { - msg->data[sizeof(msg->data) - 1] = '\0'; + msg->data[EC_HOST_PARAM_SIZE - 1] = '\0'; count += scnprintf(buf + count, PAGE_SIZE - count, "Build info: %s\n", msg->data); } Patches currently in stable-queue which might be from arnd(a)arndb.de are queue-4.14/drm-tilcdc-ensure-nonatomic-iowrite64-is-not-used.patch queue-4.14/cros_ec-fix-nul-termination-for-firmware-build-info.patch

7 years, 6 months

1
0
0 0

Patch "cpufreq: longhaul: Revert transition_delay_us to 200 ms" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled cpufreq: longhaul: Revert transition_delay_us to 200 ms to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: cpufreq-longhaul-revert-transition_delay_us-to-200-ms.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Thu Mar 22 14:26:48 CET 2018 From: Viresh Kumar <viresh.kumar(a)linaro.org> Date: Thu, 7 Dec 2017 15:15:19 +0530 Subject: cpufreq: longhaul: Revert transition_delay_us to 200 ms From: Viresh Kumar <viresh.kumar(a)linaro.org> [ Upstream commit 1d0d064307cbfd8546841f6e9d94d02c55e45e1e ] The commit e948bc8fbee0 ("cpufreq: Cap the default transition delay value to 10 ms") caused a regression on EPIA-M min-ITX computer where shutdown or reboot hangs occasionally with a print message like: longhaul: Warning: Timeout while waiting for idle PCI bus cpufreq: __target_index: Failed to change cpu frequency: -16 This probably happens because the cpufreq governor tries to change the frequency of the CPU faster than allowed by the hardware. Before the above commit, the default transition delay was set to 200 ms for a transition_latency of 200000 ns. Lets revert back to that transition delay value to fix it. Note that several other transition delay values were tested like 20 ms and 30 ms and none of them have resolved system hang issue completely. Fixes: e948bc8fbee0 (cpufreq: Cap the default transition delay value to 10 ms) Reported-by: Meelis Roos <mroos(a)linux.ee> Suggested-by: Rafael J. Wysocki <rjw(a)rjwysocki.net> Signed-off-by: Viresh Kumar <viresh.kumar(a)linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki(a)intel.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/cpufreq/longhaul.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/drivers/cpufreq/longhaul.c +++ b/drivers/cpufreq/longhaul.c @@ -894,7 +894,7 @@ static int longhaul_cpu_init(struct cpuf if ((longhaul_version != TYPE_LONGHAUL_V1) && (scale_voltage != 0)) longhaul_setup_voltagescaling(); - policy->cpuinfo.transition_latency = 200000; /* nsec */ + policy->transition_delay_us = 200000; /* usec */ return cpufreq_table_validate_and_show(policy, longhaul_table); } Patches currently in stable-queue which might be from viresh.kumar(a)linaro.org are queue-4.14/cpufreq-longhaul-revert-transition_delay_us-to-200-ms.patch

7 years, 6 months

1
0
0 0

Patch "coresight: Fix disabling of CoreSight TPIU" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled coresight: Fix disabling of CoreSight TPIU to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: coresight-fix-disabling-of-coresight-tpiu.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Thu Mar 22 14:26:48 CET 2018 From: Robert Walker <robert.walker(a)arm.com> Date: Mon, 18 Dec 2017 11:05:44 -0700 Subject: coresight: Fix disabling of CoreSight TPIU From: Robert Walker <robert.walker(a)arm.com> [ Upstream commit 11595db8e17faaa05fadc25746c870e31276962f ] The CoreSight TPIU should be disabled when tracing to other sinks to allow them to operate at full bandwidth. This patch fixes tpiu_disable_hw() to correctly disable the TPIU by configuring the TPIU to stop on flush, initiating a manual flush, waiting for the flush to complete and then waits for the TPIU to indicate it has stopped. Signed-off-by: Robert Walker <robert.walker(a)arm.com> Tested-by: Mike Leach <mike.leach(a)linaro.org> Signed-off-by: Mathieu Poirier <mathieu.poirier(a)linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/hwtracing/coresight/coresight-tpiu.c | 13 ++++++++++--- 1 file changed, 10 insertions(+), 3 deletions(-) --- a/drivers/hwtracing/coresight/coresight-tpiu.c +++ b/drivers/hwtracing/coresight/coresight-tpiu.c @@ -46,8 +46,11 @@ #define TPIU_ITATBCTR0 0xef8 /** register definition **/ +/* FFSR - 0x300 */ +#define FFSR_FT_STOPPED BIT(1) /* FFCR - 0x304 */ #define FFCR_FON_MAN BIT(6) +#define FFCR_STOP_FI BIT(12) /** * @base: memory mapped base address for this component. @@ -85,10 +88,14 @@ static void tpiu_disable_hw(struct tpiu_ { CS_UNLOCK(drvdata->base); - /* Clear formatter controle reg. */ - writel_relaxed(0x0, drvdata->base + TPIU_FFCR); + /* Clear formatter and stop on flush */ + writel_relaxed(FFCR_STOP_FI, drvdata->base + TPIU_FFCR); /* Generate manual flush */ - writel_relaxed(FFCR_FON_MAN, drvdata->base + TPIU_FFCR); + writel_relaxed(FFCR_STOP_FI | FFCR_FON_MAN, drvdata->base + TPIU_FFCR); + /* Wait for flush to complete */ + coresight_timeout(drvdata->base, TPIU_FFCR, FFCR_FON_MAN, 0); + /* Wait for formatter to stop */ + coresight_timeout(drvdata->base, TPIU_FFSR, FFSR_FT_STOPPED, 1); CS_LOCK(drvdata->base); } Patches currently in stable-queue which might be from robert.walker(a)arm.com are queue-4.14/coresight-fix-disabling-of-coresight-tpiu.patch

7 years, 6 months

1
0
0 0

Patch "clk: si5351: Rename internal plls to avoid name collisions" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled clk: si5351: Rename internal plls to avoid name collisions to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: clk-si5351-rename-internal-plls-to-avoid-name-collisions.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Thu Mar 22 14:26:48 CET 2018 From: Sergej Sawazki <sergej(a)taudac.com> Date: Tue, 25 Jul 2017 23:21:02 +0200 Subject: clk: si5351: Rename internal plls to avoid name collisions From: Sergej Sawazki <sergej(a)taudac.com> [ Upstream commit cdba9a4fb0b53703959ac861e415816cb61aded4 ] This drivers probe fails due to a clock name collision if a clock named 'plla' or 'pllb' is already registered when registering this drivers internal plls. Fix it by renaming internal plls to avoid name collisions. Cc: Sebastian Hesselbarth <sebastian.hesselbarth(a)gmail.com> Cc: Rabeeh Khoury <rabeeh(a)solid-run.com> Signed-off-by: Sergej Sawazki <sergej(a)taudac.com> Signed-off-by: Stephen Boyd <sboyd(a)codeaurora.org> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/clk/clk-si5351.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/drivers/clk/clk-si5351.c +++ b/drivers/clk/clk-si5351.c @@ -72,7 +72,7 @@ static const char * const si5351_input_n "xtal", "clkin" }; static const char * const si5351_pll_names[] = { - "plla", "pllb", "vxco" + "si5351_plla", "si5351_pllb", "si5351_vxco" }; static const char * const si5351_msynth_names[] = { "ms0", "ms1", "ms2", "ms3", "ms4", "ms5", "ms6", "ms7" Patches currently in stable-queue which might be from sergej(a)taudac.com are queue-4.14/clk-si5351-rename-internal-plls-to-avoid-name-collisions.patch

7 years, 6 months

1
0
0 0

Patch "clk: Don't touch hardware when reparenting during registration" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled clk: Don't touch hardware when reparenting during registration to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: clk-don-t-touch-hardware-when-reparenting-during-registration.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Thu Mar 22 14:26:48 CET 2018 From: Stephen Boyd <sboyd(a)codeaurora.org> Date: Thu, 2 Nov 2017 00:36:09 -0700 Subject: clk: Don't touch hardware when reparenting during registration From: Stephen Boyd <sboyd(a)codeaurora.org> [ Upstream commit f8f8f1d04494d3a6546bee3f0618c4dba31d7b72 ] The orphan clocks reparent operation shouldn't touch the hardware if clocks are enabled, otherwise it may get a chance to disable a newly registered critical clock which triggers the warning below. Assuming we have two clocks: A and B, B is the parent of A. Clock A has flag: CLK_OPS_PARENT_ENABLE Clock B has flag: CLK_IS_CRITICAL Step 1: Clock A is registered, then it becomes orphan. Step 2: Clock B is registered. Before clock B reach the critical clock enable operation, orphan A will find the newly registered parent B and do reparent operation, then parent B will be finally disabled in __clk_set_parent_after() due to CLK_OPS_PARENT_ENABLE flag as there's still no users of B which will then trigger the following warning. WARNING: CPU: 0 PID: 0 at drivers/clk/clk.c:597 clk_core_disable+0xb4/0xe0 Modules linked in: CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.11.0-rc1-00056-gdff1f66-dirty #1373 Hardware name: Generic DT based system Backtrace: [<c010c4bc>] (dump_backtrace) from [<c010c764>] (show_stack+0x18/0x1c) r6:600000d3 r5:00000000 r4:c0e26358 r3:00000000 [<c010c74c>] (show_stack) from [<c040599c>] (dump_stack+0xb4/0xe8) [<c04058e8>] (dump_stack) from [<c0125c94>] (__warn+0xd8/0x104) r10:c0c21cd0 r9:c048aa78 r8:00000255 r7:00000009 r6:c0c1cd90 r5:00000000 r4:00000000 r3:c0e01d34 [<c0125bbc>] (__warn) from [<c0125d74>] (warn_slowpath_null+0x28/0x30) r9:00000000 r8:ef00bf80 r7:c165ac4c r6:ef00bf80 r5:ef00bf80 r4:ef00bf80 [<c0125d4c>] (warn_slowpath_null) from [<c048aa78>] (clk_core_disable+0xb4/0xe0) [<c048a9c4>] (clk_core_disable) from [<c048be88>] (clk_core_disable_lock+0x20/0x2c) r4:000000d3 r3:c0e0af00 [<c048be68>] (clk_core_disable_lock) from [<c048c224>] (clk_core_disable_unprepare+0x14/0x28) r5:00000000 r4:ef00bf80 [<c048c210>] (clk_core_disable_unprepare) from [<c048c270>] (__clk_set_parent_after+0x38/0x54) r4:ef00bd80 r3:000010a0 [<c048c238>] (__clk_set_parent_after) from [<c048daa8>] (clk_register+0x4d0/0x648) r6:ef00d500 r5:ef00bf80 r4:ef00bd80 r3:ef00bfd4 [<c048d5d8>] (clk_register) from [<c048dc30>] (clk_hw_register+0x10/0x1c) r9:00000000 r8:00000003 r7:00000000 r6:00000824 r5:00000001 r4:ef00d500 [<c048dc20>] (clk_hw_register) from [<c048e698>] (_register_divider+0xcc/0x120) [<c048e5cc>] (_register_divider) from [<c048e730>] (clk_register_divider+0x44/0x54) r10:00000004 r9:00000003 r8:00000001 r7:00000000 r6:00000003 r5:00000001 r4:f0810030 [<c048e6ec>] (clk_register_divider) from [<c0d3ff58>] (imx7ulp_clocks_init+0x558/0xe98) r7:c0e296f8 r6:c165c808 r5:00000000 r4:c165c808 [<c0d3fa00>] (imx7ulp_clocks_init) from [<c0d24db0>] (of_clk_init+0x118/0x1e0) r10:00000001 r9:c0e01f68 r8:00000000 r7:c0e01f60 r6:ef7f8974 r5:ef0035c0 r4:00000006 [<c0d24c98>] (of_clk_init) from [<c0d04a50>] (time_init+0x2c/0x38) r10:efffed40 r9:c0d61a48 r8:c0e78000 r7:c0e07900 r6:ffffffff r5:c0e78000 r4:00000000 [<c0d04a24>] (time_init) from [<c0d00b8c>] (start_kernel+0x218/0x394) [<c0d00974>] (start_kernel) from [<6000807c>] (0x6000807c) r10:00000000 r9:410fc075 r8:6000406a r7:c0e0c930 r6:c0d61a44 r5:c0e07918 r4:c0e78294 We know that the clk isn't enabled with any sort of prepare_count here so we don't need to enable anything to prevent a race. And we're holding the prepare mutex so set_rate/set_parent can't race here either. Based on an earlier patch by Dong Aisheng. Fixes: fc8726a2c021 ("clk: core: support clocks which requires parents enable (part 2)") Cc: Michael Turquette <mturquette(a)baylibre.com> Cc: Shawn Guo <shawnguo(a)kernel.org> Reported-by: Dong Aisheng <aisheng.dong(a)nxp.com> Signed-off-by: Stephen Boyd <sboyd(a)codeaurora.org> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/clk/clk.c | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) --- a/drivers/clk/clk.c +++ b/drivers/clk/clk.c @@ -2476,14 +2476,17 @@ static int __clk_core_init(struct clk_co */ hlist_for_each_entry_safe(orphan, tmp2, &clk_orphan_list, child_node) { struct clk_core *parent = __clk_init_parent(orphan); + unsigned long flags; /* * we could call __clk_set_parent, but that would result in a * redundant call to the .set_rate op, if it exists */ if (parent) { - __clk_set_parent_before(orphan, parent); - __clk_set_parent_after(orphan, parent, NULL); + /* update the clk tree topology */ + flags = clk_enable_lock(); + clk_reparent(orphan, parent); + clk_enable_unlock(flags); __clk_recalc_accuracies(orphan); __clk_recalc_rates(orphan, 0); } Patches currently in stable-queue which might be from sboyd(a)codeaurora.org are queue-4.14/clk-at91-pmc-wait-for-clocks-when-resuming.patch queue-4.14/clk-si5351-rename-internal-plls-to-avoid-name-collisions.patch queue-4.14/clk-don-t-touch-hardware-when-reparenting-during-registration.patch queue-4.14/clk-axi-clkgen-correctly-handle-nocount-bit-in-recalc_rate.patch

7 years, 6 months

1
0
0 0

Patch "clk: axi-clkgen: Correctly handle nocount bit in recalc_rate()" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled clk: axi-clkgen: Correctly handle nocount bit in recalc_rate() to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: clk-axi-clkgen-correctly-handle-nocount-bit-in-recalc_rate.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Thu Mar 22 14:26:48 CET 2018 From: Lars-Peter Clausen <lars(a)metafoo.de> Date: Tue, 5 Sep 2017 11:32:40 +0200 Subject: clk: axi-clkgen: Correctly handle nocount bit in recalc_rate() From: Lars-Peter Clausen <lars(a)metafoo.de> [ Upstream commit 063578dc5f407f67d149133818efabe457daafda ] If the nocount bit is set the divider is bypassed and the settings for the divider count should be ignored and a divider value of 1 should be assumed. Handle this correctly in the driver recalc_rate() callback. While the driver sets up the part so that the read back dividers values yield the correct result the power-on reset settings of the part might not reflect this and hence calling e.g. clk_get_rate() without prior calls to clk_set_rate() will yield the wrong result. Signed-off-by: Lars-Peter Clausen <lars(a)metafoo.de> Signed-off-by: Stephen Boyd <sboyd(a)codeaurora.org> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/clk/clk-axi-clkgen.c | 29 ++++++++++++++++++++++++----- 1 file changed, 24 insertions(+), 5 deletions(-) --- a/drivers/clk/clk-axi-clkgen.c +++ b/drivers/clk/clk-axi-clkgen.c @@ -40,6 +40,10 @@ #define MMCM_REG_FILTER1 0x4e #define MMCM_REG_FILTER2 0x4f +#define MMCM_CLKOUT_NOCOUNT BIT(6) + +#define MMCM_CLK_DIV_NOCOUNT BIT(12) + struct axi_clkgen { void __iomem *base; struct clk_hw clk_hw; @@ -315,12 +319,27 @@ static unsigned long axi_clkgen_recalc_r unsigned int reg; unsigned long long tmp; - axi_clkgen_mmcm_read(axi_clkgen, MMCM_REG_CLKOUT0_1, &reg); - dout = (reg & 0x3f) + ((reg >> 6) & 0x3f); + axi_clkgen_mmcm_read(axi_clkgen, MMCM_REG_CLKOUT0_2, &reg); + if (reg & MMCM_CLKOUT_NOCOUNT) { + dout = 1; + } else { + axi_clkgen_mmcm_read(axi_clkgen, MMCM_REG_CLKOUT0_1, &reg); + dout = (reg & 0x3f) + ((reg >> 6) & 0x3f); + } + axi_clkgen_mmcm_read(axi_clkgen, MMCM_REG_CLK_DIV, &reg); - d = (reg & 0x3f) + ((reg >> 6) & 0x3f); - axi_clkgen_mmcm_read(axi_clkgen, MMCM_REG_CLK_FB1, &reg); - m = (reg & 0x3f) + ((reg >> 6) & 0x3f); + if (reg & MMCM_CLK_DIV_NOCOUNT) + d = 1; + else + d = (reg & 0x3f) + ((reg >> 6) & 0x3f); + + axi_clkgen_mmcm_read(axi_clkgen, MMCM_REG_CLK_FB2, &reg); + if (reg & MMCM_CLKOUT_NOCOUNT) { + m = 1; + } else { + axi_clkgen_mmcm_read(axi_clkgen, MMCM_REG_CLK_FB1, &reg); + m = (reg & 0x3f) + ((reg >> 6) & 0x3f); + } if (d == 0 || dout == 0) return 0; Patches currently in stable-queue which might be from lars(a)metafoo.de are queue-4.14/clk-axi-clkgen-correctly-handle-nocount-bit-in-recalc_rate.patch

7 years, 6 months

1
0
0 0

Patch "clk: at91: pmc: Wait for clocks when resuming" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled clk: at91: pmc: Wait for clocks when resuming to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: clk-at91-pmc-wait-for-clocks-when-resuming.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Thu Mar 22 14:26:48 CET 2018 From: Romain Izard <romain.izard.pro(a)gmail.com> Date: Mon, 11 Dec 2017 17:55:33 +0100 Subject: clk: at91: pmc: Wait for clocks when resuming From: Romain Izard <romain.izard.pro(a)gmail.com> [ Upstream commit 960e1c4d93be86d3b118fe22d4edc69e401b28b5 ] Wait for the syncronization of all clocks when resuming, not only the UPLL clock. Do not use regmap_read_poll_timeout, as it will call BUG() when interrupts are masked, which is the case in here. Signed-off-by: Romain Izard <romain.izard.pro(a)gmail.com> Acked-by: Ludovic Desroches <ludovic.desroches(a)microchip.com> Acked-by: Nicolas Ferre <nicolas.ferre(a)microchip.com> Acked-by: Alexandre Belloni <alexandre.belloni(a)free-electrons.com> Signed-off-by: Stephen Boyd <sboyd(a)codeaurora.org> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/clk/at91/pmc.c | 24 ++++++++++++++++-------- 1 file changed, 16 insertions(+), 8 deletions(-) --- a/drivers/clk/at91/pmc.c +++ b/drivers/clk/at91/pmc.c @@ -107,10 +107,20 @@ static int pmc_suspend(void) return 0; } +static bool pmc_ready(unsigned int mask) +{ + unsigned int status; + + regmap_read(pmcreg, AT91_PMC_SR, &status); + + return ((status & mask) == mask) ? 1 : 0; +} + static void pmc_resume(void) { - int i, ret = 0; + int i; u32 tmp; + u32 mask = AT91_PMC_MCKRDY | AT91_PMC_LOCKA; regmap_read(pmcreg, AT91_PMC_MCKR, &tmp); if (pmc_cache.mckr != tmp) @@ -134,13 +144,11 @@ static void pmc_resume(void) AT91_PMC_PCR_CMD); } - if (pmc_cache.uckr & AT91_PMC_UPLLEN) { - ret = regmap_read_poll_timeout(pmcreg, AT91_PMC_SR, tmp, - !(tmp & AT91_PMC_LOCKU), - 10, 5000); - if (ret) - pr_crit("USB PLL didn't lock when resuming\n"); - } + if (pmc_cache.uckr & AT91_PMC_UPLLEN) + mask |= AT91_PMC_LOCKU; + + while (!pmc_ready(mask)) + cpu_relax(); } static struct syscore_ops pmc_syscore_ops = { Patches currently in stable-queue which might be from romain.izard.pro(a)gmail.com are queue-4.14/clk-at91-pmc-wait-for-clocks-when-resuming.patch

7 years, 6 months

1
0
0 0

Patch "Bluetooth: hci_qca: Avoid setup failure on missing rampatch" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled Bluetooth: hci_qca: Avoid setup failure on missing rampatch to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: bluetooth-hci_qca-avoid-setup-failure-on-missing-rampatch.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Thu Mar 22 14:26:48 CET 2018 From: Loic Poulain <loic.poulain(a)linaro.org> Date: Mon, 6 Nov 2017 12:16:56 +0100 Subject: Bluetooth: hci_qca: Avoid setup failure on missing rampatch From: Loic Poulain <loic.poulain(a)linaro.org> [ Upstream commit ba8f3597900291a93604643017fff66a14546015 ] Assuming that the original code idea was to enable in-band sleeping only if the setup_rome method returns succes and run in 'standard' mode otherwise, we should not return setup_rome return value which makes qca_setup fail if no rampatch/nvm file found. This fixes BT issue on the dragonboard-820C p4 which includes the following QCA controller: hci0: Product:0x00000008 hci0: Patch :0x00000111 hci0: ROM :0x00000302 hci0: SOC :0x00000044 Since there is no rampatch for this controller revision, just make it work as is. Signed-off-by: Loic Poulain <loic.poulain(a)linaro.org> Signed-off-by: Marcel Holtmann <marcel(a)holtmann.org> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/bluetooth/hci_qca.c | 3 +++ 1 file changed, 3 insertions(+) --- a/drivers/bluetooth/hci_qca.c +++ b/drivers/bluetooth/hci_qca.c @@ -933,6 +933,9 @@ static int qca_setup(struct hci_uart *hu if (!ret) { set_bit(STATE_IN_BAND_SLEEP_ENABLED, &qca->flags); qca_debugfs_init(hdev); + } else if (ret == -ENOENT) { + /* No patch/nvm-config found, run with original fw/config */ + ret = 0; } /* Setup bdaddr */ Patches currently in stable-queue which might be from loic.poulain(a)linaro.org are queue-4.14/bluetooth-btqcomsmd-fix-skb-double-free-corruption.patch queue-4.14/bluetooth-hci_qca-avoid-setup-failure-on-missing-rampatch.patch

7 years, 6 months

1
0
0 0

Patch "Bluetooth: btqcomsmd: Fix skb double free corruption" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled Bluetooth: btqcomsmd: Fix skb double free corruption to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: bluetooth-btqcomsmd-fix-skb-double-free-corruption.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Thu Mar 22 14:26:48 CET 2018 From: Loic Poulain <loic.poulain(a)linaro.org> Date: Wed, 22 Nov 2017 15:03:17 +0100 Subject: Bluetooth: btqcomsmd: Fix skb double free corruption From: Loic Poulain <loic.poulain(a)linaro.org> [ Upstream commit 67b8fbead4685b36d290a0ef91c6ddffc4920ec9 ] In case of hci send frame failure, skb is still owned by the caller (hci_core) and then should not be freed. This fixes crash on dragonboard-410c when sending SCO packet. skb is freed by both btqcomsmd and hci_core. Fixes: 1511cc750c3d ("Bluetooth: Introduce Qualcomm WCNSS SMD based HCI driver") Signed-off-by: Loic Poulain <loic.poulain(a)linaro.org> Signed-off-by: Marcel Holtmann <marcel(a)holtmann.org> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/bluetooth/btqcomsmd.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) --- a/drivers/bluetooth/btqcomsmd.c +++ b/drivers/bluetooth/btqcomsmd.c @@ -86,7 +86,8 @@ static int btqcomsmd_send(struct hci_dev break; } - kfree_skb(skb); + if (!ret) + kfree_skb(skb); return ret; } Patches currently in stable-queue which might be from loic.poulain(a)linaro.org are queue-4.14/bluetooth-btqcomsmd-fix-skb-double-free-corruption.patch queue-4.14/bluetooth-hci_qca-avoid-setup-failure-on-missing-rampatch.patch

7 years, 6 months

1
0
0 0

Patch "ath10k: handling qos at STA side based on AP WMM enable/disable" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled ath10k: handling qos at STA side based on AP WMM enable/disable to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: ath10k-handling-qos-at-sta-side-based-on-ap-wmm-enable-disable.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Thu Mar 22 14:26:48 CET 2018 From: Balaji Pothunoori <bpothuno(a)qti.qualcomm.com> Date: Thu, 7 Dec 2017 16:58:04 +0200 Subject: ath10k: handling qos at STA side based on AP WMM enable/disable From: Balaji Pothunoori <bpothuno(a)qti.qualcomm.com> [ Upstream commit 07ffb4497360ae8789f05555fec8171ee952304d ] Data packets are not sent by STA in case of STA joined to non QOS AP (WMM disabled AP). This is happening because of STA is sending data packets to firmware from host with qos enabled along with non qos queue value(TID = 16). Due to qos enabled, firmware is discarding the packet. This patch fixes this issue by updating the qos based on station WME capability field if WMM is disabled in AP. This patch is required by 10.4 family chipsets like QCA4019/QCA9888/QCA9884/QCA99X0. Firmware Versoin : 10.4-3.5.1-00018. For 10.2.4 family chipsets QCA988X/QCA9887 and QCA6174 this patch has no effect. Signed-off-by: Balaji Pothunoori <bpothuno(a)qti.qualcomm.com> Signed-off-by: Kalle Valo <kvalo(a)qca.qualcomm.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/net/wireless/ath/ath10k/mac.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/drivers/net/wireless/ath/ath10k/mac.c +++ b/drivers/net/wireless/ath/ath10k/mac.c @@ -2553,7 +2553,7 @@ static void ath10k_peer_assoc_h_qos(stru } break; case WMI_VDEV_TYPE_STA: - if (vif->bss_conf.qos) + if (sta->wme) arg->peer_flags |= arvif->ar->wmi.peer_flags->qos; break; case WMI_VDEV_TYPE_IBSS: Patches currently in stable-queue which might be from bpothuno(a)qti.qualcomm.com are queue-4.14/ath10k-handling-qos-at-sta-side-based-on-ap-wmm-enable-disable.patch

7 years, 6 months

1
0
0 0

Patch "ARM: dts: aspeed-evb: Add unit name to memory node" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled ARM: dts: aspeed-evb: Add unit name to memory node to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: arm-dts-aspeed-evb-add-unit-name-to-memory-node.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Thu Mar 22 14:26:48 CET 2018 From: Joel Stanley <joel(a)jms.id.au> Date: Mon, 18 Dec 2017 23:27:03 +1030 Subject: ARM: dts: aspeed-evb: Add unit name to memory node From: Joel Stanley <joel(a)jms.id.au> [ Upstream commit e40ed274489a5f516da120186578eb379b452ac6 ] Fixes a warning when building with W=1. All of the ASPEED device trees build without warnings now. Signed-off-by: Joel Stanley <joel(a)jms.id.au> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/arm/boot/dts/aspeed-ast2500-evb.dts | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/arch/arm/boot/dts/aspeed-ast2500-evb.dts +++ b/arch/arm/boot/dts/aspeed-ast2500-evb.dts @@ -16,7 +16,7 @@ bootargs = "console=ttyS4,115200 earlyprintk"; }; - memory { + memory@80000000 { reg = <0x80000000 0x20000000>; }; }; Patches currently in stable-queue which might be from joel(a)jms.id.au are queue-4.14/arm-dts-aspeed-evb-add-unit-name-to-memory-node.patch

7 years, 6 months

1
0
0 0

Patch "watchdog: Fix potential kref imbalance when opening watchdog" has been added to the 4.15-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled watchdog: Fix potential kref imbalance when opening watchdog to the 4.15-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: watchdog-fix-potential-kref-imbalance-when-opening-watchdog.patch and it can be found in the queue-4.15 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Thu Mar 22 14:03:39 CET 2018 From: Guenter Roeck <linux(a)roeck-us.net> Date: Mon, 25 Sep 2017 09:17:01 -0700 Subject: watchdog: Fix potential kref imbalance when opening watchdog From: Guenter Roeck <linux(a)roeck-us.net> [ Upstream commit 4bcd615fad6adddc68b058d498b30a9e0e0db77a ] If a watchdog driver's open function sets WDOG_HW_RUNNING with the expectation that the watchdog can not be stopped, but then stops the watchdog anyway in its stop function, kref_get() wil not be called in watchdog_open(). If the watchdog then stops on close, WDOG_HW_RUNNING will be cleared and kref_put() will be called, causing a kref imbalance. As result the character device data structure will be released, which in turn will cause the system to crash on the next call to watchdog_open(). Fixes: ee142889e32f5 ("watchdog: Introduce WDOG_HW_RUNNING flag") Signed-off-by: Guenter Roeck <linux(a)roeck-us.net> Signed-off-by: Wim Van Sebroeck <wim(a)iguana.be> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/watchdog/watchdog_dev.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) --- a/drivers/watchdog/watchdog_dev.c +++ b/drivers/watchdog/watchdog_dev.c @@ -769,6 +769,7 @@ static int watchdog_open(struct inode *i { struct watchdog_core_data *wd_data; struct watchdog_device *wdd; + bool hw_running; int err; /* Get the corresponding watchdog device */ @@ -788,7 +789,8 @@ static int watchdog_open(struct inode *i * If the /dev/watchdog device is open, we don't want the module * to be unloaded. */ - if (!watchdog_hw_running(wdd) && !try_module_get(wdd->ops->owner)) { + hw_running = watchdog_hw_running(wdd); + if (!hw_running && !try_module_get(wdd->ops->owner)) { err = -EBUSY; goto out_clear; } @@ -799,7 +801,7 @@ static int watchdog_open(struct inode *i file->private_data = wd_data; - if (!watchdog_hw_running(wdd)) + if (!hw_running) kref_get(&wd_data->kref); /* dev/watchdog is a virtual (and thus non-seekable) filesystem */ Patches currently in stable-queue which might be from linux(a)roeck-us.net are queue-4.15/watchdog-fix-potential-kref-imbalance-when-opening-watchdog.patch queue-4.15/watchdog-fix-kref-imbalance-seen-if-handle_boot_enabled-0.patch

7 years, 6 months

1
0
0 0

Patch "watchdog: Fix kref imbalance seen if handle_boot_enabled=0" has been added to the 4.15-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled watchdog: Fix kref imbalance seen if handle_boot_enabled=0 to the 4.15-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: watchdog-fix-kref-imbalance-seen-if-handle_boot_enabled-0.patch and it can be found in the queue-4.15 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Thu Mar 22 14:03:39 CET 2018 From: Guenter Roeck <linux(a)roeck-us.net> Date: Mon, 25 Sep 2017 09:17:02 -0700 Subject: watchdog: Fix kref imbalance seen if handle_boot_enabled=0 From: Guenter Roeck <linux(a)roeck-us.net> [ Upstream commit 914d65f3f013ba2556c7beec5d3baac7b3292504 ] If handle_boot_enabled is set to 0, the watchdog driver module use counter will not be increased and kref_get() will not be called when registering the watchdog. Subsequently, on open, this does not happen either because the code believes that it was already done because the hardware watchdog is marked as running. We could introduce a state variable to indicate this state, but let's just increase the module use counter and call kref_get() unconditionally if the hardware watchdog is running when a driver is registering itself to keep the code simple. Fixes: 2501b015313fe ("watchdog: core: add option to avoid early ...") Cc: Sebastian Reichel <sebastian.reichel(a)collabora.co.uk> Signed-off-by: Guenter Roeck <linux(a)roeck-us.net> Signed-off-by: Wim Van Sebroeck <wim(a)iguana.be> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/watchdog/watchdog_dev.c | 11 +++++------ 1 file changed, 5 insertions(+), 6 deletions(-) --- a/drivers/watchdog/watchdog_dev.c +++ b/drivers/watchdog/watchdog_dev.c @@ -967,14 +967,13 @@ static int watchdog_cdev_register(struct * and schedule an immediate ping. */ if (watchdog_hw_running(wdd)) { - if (handle_boot_enabled) { - __module_get(wdd->ops->owner); - kref_get(&wd_data->kref); + __module_get(wdd->ops->owner); + kref_get(&wd_data->kref); + if (handle_boot_enabled) queue_delayed_work(watchdog_wq, &wd_data->work, 0); - } else { + else pr_info("watchdog%d running and kernel based pre-userspace handler disabled\n", - wdd->id); - } + wdd->id); } return 0; Patches currently in stable-queue which might be from linux(a)roeck-us.net are queue-4.15/watchdog-fix-potential-kref-imbalance-when-opening-watchdog.patch queue-4.15/watchdog-fix-kref-imbalance-seen-if-handle_boot_enabled-0.patch

7 years, 6 months

1
0
0 0

Patch "vgacon: Set VGA struct resource types" has been added to the 4.15-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled vgacon: Set VGA struct resource types to the 4.15-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: vgacon-set-vga-struct-resource-types.patch and it can be found in the queue-4.15 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Thu Mar 22 14:03:39 CET 2018 From: Bjorn Helgaas <bhelgaas(a)google.com> Date: Fri, 1 Dec 2017 11:06:39 -0600 Subject: vgacon: Set VGA struct resource types From: Bjorn Helgaas <bhelgaas(a)google.com> [ Upstream commit c82084117f79bcae085e40da526253736a247120 ] Set the resource type when we reserve VGA-related I/O port resources. The resource code doesn't actually look at the type, so it inserts resources without a type in the tree correctly even without this change. But if we ever print a resource without a type, it looks like this: vga+ [??? 0x000003c0-0x000003df flags 0x0] Setting the type means it will be printed correctly as: vga+ [io 0x000003c0-0x000003df] Signed-off-by: Bjorn Helgaas <bhelgaas(a)google.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/alpha/kernel/console.c | 1 + drivers/video/console/vgacon.c | 34 ++++++++++++++++++++++++++-------- 2 files changed, 27 insertions(+), 8 deletions(-) --- a/arch/alpha/kernel/console.c +++ b/arch/alpha/kernel/console.c @@ -21,6 +21,7 @@ struct pci_controller *pci_vga_hose; static struct resource alpha_vga = { .name = "alpha-vga+", + .flags = IORESOURCE_IO, .start = 0x3C0, .end = 0x3DF }; --- a/drivers/video/console/vgacon.c +++ b/drivers/video/console/vgacon.c @@ -422,7 +422,10 @@ static const char *vgacon_startup(void) vga_video_port_val = VGA_CRT_DM; if ((screen_info.orig_video_ega_bx & 0xff) != 0x10) { static struct resource ega_console_resource = - { .name = "ega", .start = 0x3B0, .end = 0x3BF }; + { .name = "ega", + .flags = IORESOURCE_IO, + .start = 0x3B0, + .end = 0x3BF }; vga_video_type = VIDEO_TYPE_EGAM; vga_vram_size = 0x8000; display_desc = "EGA+"; @@ -430,9 +433,15 @@ static const char *vgacon_startup(void) &ega_console_resource); } else { static struct resource mda1_console_resource = - { .name = "mda", .start = 0x3B0, .end = 0x3BB }; + { .name = "mda", + .flags = IORESOURCE_IO, + .start = 0x3B0, + .end = 0x3BB }; static struct resource mda2_console_resource = - { .name = "mda", .start = 0x3BF, .end = 0x3BF }; + { .name = "mda", + .flags = IORESOURCE_IO, + .start = 0x3BF, + .end = 0x3BF }; vga_video_type = VIDEO_TYPE_MDA; vga_vram_size = 0x2000; display_desc = "*MDA"; @@ -454,15 +463,21 @@ static const char *vgacon_startup(void) vga_vram_size = 0x8000; if (!screen_info.orig_video_isVGA) { - static struct resource ega_console_resource - = { .name = "ega", .start = 0x3C0, .end = 0x3DF }; + static struct resource ega_console_resource = + { .name = "ega", + .flags = IORESOURCE_IO, + .start = 0x3C0, + .end = 0x3DF }; vga_video_type = VIDEO_TYPE_EGAC; display_desc = "EGA"; request_resource(&ioport_resource, &ega_console_resource); } else { - static struct resource vga_console_resource - = { .name = "vga+", .start = 0x3C0, .end = 0x3DF }; + static struct resource vga_console_resource = + { .name = "vga+", + .flags = IORESOURCE_IO, + .start = 0x3C0, + .end = 0x3DF }; vga_video_type = VIDEO_TYPE_VGAC; display_desc = "VGA+"; request_resource(&ioport_resource, @@ -494,7 +509,10 @@ static const char *vgacon_startup(void) } } else { static struct resource cga_console_resource = - { .name = "cga", .start = 0x3D4, .end = 0x3D5 }; + { .name = "cga", + .flags = IORESOURCE_IO, + .start = 0x3D4, + .end = 0x3D5 }; vga_video_type = VIDEO_TYPE_CGA; vga_vram_size = 0x2000; display_desc = "*CGA"; Patches currently in stable-queue which might be from bhelgaas(a)google.com are queue-4.15/vgacon-set-vga-struct-resource-types.patch queue-4.15/pci-aspm-calculate-ltr_l1.2_threshold-from-device-characteristics.patch

7 years, 6 months

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror