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

Patch "e1000e: fix timing for 82579 Gigabit Ethernet controller" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled e1000e: fix timing for 82579 Gigabit Ethernet controller to the 4.4-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: e1000e-fix-timing-for-82579-gigabit-ethernet-controller.patch and it can be found in the queue-4.4 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:57:32 CET 2018 From: Bernd Faust <berndfaust(a)gmail.com> Date: Thu, 16 Feb 2017 19:42:07 +0100 Subject: e1000e: fix timing for 82579 Gigabit Ethernet controller From: Bernd Faust <berndfaust(a)gmail.com> [ Upstream commit 5313eeccd2d7f486be4e5c7560e3e2be239ec8f7 ] After an upgrade to Linux kernel v4.x the hardware timestamps of the 82579 Gigabit Ethernet Controller are different than expected. The values that are being read are almost four times as big as before the kernel upgrade. The difference is that after the upgrade the driver sets the clock frequency to 25MHz, where before the upgrade it was set to 96MHz. Intel confirmed that the correct frequency for this network adapter is 96MHz. Signed-off-by: Bernd Faust <berndfaust(a)gmail.com> Acked-by: Sasha Neftin <sasha.neftin(a)intel.com> Acked-by: Jacob Keller <jacob.e.keller(a)intel.com> Tested-by: Aaron Brown <aaron.f.brown(a)intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher(a)intel.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/net/ethernet/intel/e1000e/netdev.c | 6 ++++++ 1 file changed, 6 insertions(+) --- a/drivers/net/ethernet/intel/e1000e/netdev.c +++ b/drivers/net/ethernet/intel/e1000e/netdev.c @@ -3526,6 +3526,12 @@ s32 e1000e_get_base_timinca(struct e1000 switch (hw->mac.type) { case e1000_pch2lan: + /* Stable 96MHz frequency */ + incperiod = INCPERIOD_96MHz; + incvalue = INCVALUE_96MHz; + shift = INCVALUE_SHIFT_96MHz; + adapter->cc.shift = shift + INCPERIOD_SHIFT_96MHz; + break; case e1000_pch_lpt: if (er32(TSYNCRXCTL) & E1000_TSYNCRXCTL_SYSCFI) { /* Stable 96MHz frequency */ Patches currently in stable-queue which might be from berndfaust(a)gmail.com are queue-4.4/e1000e-fix-timing-for-82579-gigabit-ethernet-controller.patch

7 years, 3 months

1
0
0 0

Patch "drm/omap: DMM: Check for DMM readiness after successful transaction commit" has been added to the 4.4-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.4-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.4 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:57:33 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 @@ -288,7 +288,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.4/drm-omap-dmm-check-for-dmm-readiness-after-successful-transaction-commit.patch queue-4.4/dmaengine-ti-dma-crossbar-fix-event-mapping-for-tpcc_evt_mux_60_63.patch

7 years, 3 months

1
0
0 0

Patch "drm/nouveau/kms: Increase max retries in scanout position queries." has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled drm/nouveau/kms: Increase max retries in scanout position queries. to the 4.4-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-nouveau-kms-increase-max-retries-in-scanout-position-queries.patch and it can be found in the queue-4.4 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:57:32 CET 2018 From: Mario Kleiner <mario.kleiner.de(a)gmail.com> Date: Mon, 24 Apr 2017 01:59:34 +0200 Subject: drm/nouveau/kms: Increase max retries in scanout position queries. From: Mario Kleiner <mario.kleiner.de(a)gmail.com> [ Upstream commit 60b95d709525e3ce1c51e1fc93175dcd1755d345 ] So far we only allowed for 1 retry and just failed the query - and thereby high precision vblank timestamping - if we did not get a reasonable result, as such a failure wasn't considered all too horrible. There are a few NVidia gpu models out there which may need a bit more than 1 retry to get a successful query result under some conditions. Since Linux 4.4 the update code for vblank counter and timestamp in drm_update_vblank_count() changed so that the implementation assumes that high precision vblank timestamping of a kms driver either consistently succeeds or consistently fails for a given video mode and encoder/connector combo. Iow. switching from success to fail or vice versa on a modeset or connector change is ok, but spurious temporary failure for a given setup can confuse the core code and potentially cause bad miscounting of vblanks and confusion or hangs in userspace clients which rely on vblank stuff, e.g., desktop compositors. Therefore change the max retry count to a larger number - more than any gpu so far is known to need to succeed, but still low enough so that these queries which do also happen in vblank interrupt are still fast enough to be not disastrously long if something would go badly wrong with them. As such sporadic retries only happen seldom even on affected gpu's, this could mean a vblank irq could take a few dozen microseconds longer every few hours of uptime -- better than a desktop compositor randomly hanging every couple of hours or days of uptime in a hard to reproduce manner. Signed-off-by: Mario Kleiner <mario.kleiner.de(a)gmail.com> Signed-off-by: Ben Skeggs <bskeggs(a)redhat.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/gpu/drm/nouveau/nouveau_display.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/drivers/gpu/drm/nouveau/nouveau_display.c +++ b/drivers/gpu/drm/nouveau/nouveau_display.c @@ -104,7 +104,7 @@ nouveau_display_scanoutpos_head(struct d }; struct nouveau_display *disp = nouveau_display(crtc->dev); struct drm_vblank_crtc *vblank = &crtc->dev->vblank[drm_crtc_index(crtc)]; - int ret, retry = 1; + int ret, retry = 20; do { ret = nvif_mthd(&disp->disp, 0, &args, sizeof(args)); Patches currently in stable-queue which might be from mario.kleiner.de(a)gmail.com are queue-4.4/drm-nouveau-kms-increase-max-retries-in-scanout-position-queries.patch

7 years, 3 months

1
0
0 0

Patch "drm/msm: fix leak in failed get_pages" has been added to the 4.4-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.4-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.4 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:57:32 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 @@ -89,14 +89,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: */ @@ -119,7 +122,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.4/drm-msm-fix-leak-in-failed-get_pages.patch

7 years, 3 months

1
0
0 0

Patch "cpufreq/sh: Replace racy task affinity logic" has been added to the 4.4-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.4-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.4 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:57:32 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.4/acpi-processor-fix-error-handling-in-__acpi_processor_start.patch queue-4.4/acpi-processor-replace-racy-task-affinity-logic.patch queue-4.4/time-change-posix-clocks-ops-interfaces-to-use-timespec64.patch queue-4.4/genirq-use-irqd_get_trigger_type-to-compare-the-trigger-type-for-shared-irqs.patch queue-4.4/cpufreq-sh-replace-racy-task-affinity-logic.patch

7 years, 3 months

1
0
0 0

Patch "cros_ec: fix nul-termination for firmware build info" has been added to the 4.4-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.4-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.4 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:57:32 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.4/time-change-posix-clocks-ops-interfaces-to-use-timespec64.patch queue-4.4/cros_ec-fix-nul-termination-for-firmware-build-info.patch

7 years, 3 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.4-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.4-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.4 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:57:33 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 @@ -51,7 +51,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.4/dmaengine-ti-dma-crossbar-fix-event-mapping-for-tpcc_evt_mux_60_63.patch

7 years, 3 months

1
0
0 0

Patch "coresight: Fix disabling of CoreSight TPIU" has been added to the 4.4-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.4-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.4 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:57:33 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 @@ -45,8 +45,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.4/coresight-fix-disabling-of-coresight-tpiu.patch

7 years, 3 months

1
0
0 0

Patch "clk: ns2: Correct SDIO bits" has been added to the 4.4-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.4-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.4 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:57:32 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.4/clk-ns2-correct-sdio-bits.patch

7 years, 3 months

1
0
0 0

Patch "clk: si5351: Rename internal plls to avoid name collisions" has been added to the 4.4-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.4-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.4 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:57:33 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.4/clk-si5351-rename-internal-plls-to-avoid-name-collisions.patch

7 years, 3 months

1
0
0 0

Patch "Btrfs: send, fix file hole not being preserved due to inline extent" has been added to the 4.4-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.4-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.4 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:57:32 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 @@ -5008,13 +5008,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); @@ -5028,6 +5034,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.4/btrfs-send-fix-file-hole-not-being-preserved-due-to-inline-extent.patch

7 years, 3 months

1
0
0 0

Patch "cifs: small underflow in cnvrtDosUnixTm()" has been added to the 4.4-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.4-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.4 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:57:32 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.4/asoc-intel-skylake-uninitialized-variable-in-probe_codec.patch queue-4.4/mmc-host-omap_hsmmc-checking-for-null-instead-of-is_err.patch queue-4.4/hsi-ssi_protocol-double-free-in-ssip_pn_xmit.patch queue-4.4/cifs-small-underflow-in-cnvrtdosunixtm.patch

7 years, 3 months

1
0
0 0

Patch "bnx2x: Align RX buffers" has been added to the 4.4-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.4-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.4 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:57:32 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 @@ -2044,6 +2044,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.4/bnx2x-align-rx-buffers.patch

7 years, 3 months

1
0
0 0

Patch "Bluetooth: hci_qca: Avoid setup failure on missing rampatch" has been added to the 4.4-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.4-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.4 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:57:32 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.4/bluetooth-hci_qca-avoid-setup-failure-on-missing-rampatch.patch

7 years, 3 months

1
0
0 0

Patch "ASoC: Intel: Skylake: Uninitialized variable in probe_codec()" has been added to the 4.4-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.4-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.4 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:57:32 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 @@ -280,7 +280,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.4/asoc-intel-skylake-uninitialized-variable-in-probe_codec.patch queue-4.4/mmc-host-omap_hsmmc-checking-for-null-instead-of-is_err.patch queue-4.4/hsi-ssi_protocol-double-free-in-ssip_pn_xmit.patch queue-4.4/cifs-small-underflow-in-cnvrtdosunixtm.patch

7 years, 3 months

1
0
0 0

Patch "ath: Fix updating radar flags for coutry code India" has been added to the 4.4-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.4-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.4 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:57:32 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.4/ath-fix-updating-radar-flags-for-coutry-code-india.patch

7 years, 3 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.4-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.4-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.4 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:57:32 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.4/arm-dra7-clockdomain-change-the-clktrctrl-of-cm_pcie_clkstctrl-to-sw_wkup.patch queue-4.4/mmc-host-omap_hsmmc-checking-for-null-instead-of-is_err.patch

7 years, 3 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.4-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.4-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.4 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:57:32 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.4/arm-8668-1-ftrace-fix-dynamic-ftrace-with-debug_rodata-and-frame_pointer.patch

7 years, 3 months

1
0
0 0

Patch "ALSA: hda - Fix headset microphone detection for ASUS N551 and N751" has been added to the 4.4-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.4-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.4 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:57:32 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 @@ -6717,6 +6717,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, }; @@ -6964,14 +6965,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, }, }; Patches currently in stable-queue which might be from me(a)mixaill.tk are queue-4.4/alsa-hda-fix-headset-microphone-detection-for-asus-n551-and-n751.patch

7 years, 3 months

1
0
0 0

Patch "ACPI/processor: Replace racy task affinity logic" has been added to the 4.4-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.4-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.4 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:57:32 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 @@ -270,11 +270,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.4/acpi-processor-fix-error-handling-in-__acpi_processor_start.patch queue-4.4/acpi-processor-replace-racy-task-affinity-logic.patch queue-4.4/time-change-posix-clocks-ops-interfaces-to-use-timespec64.patch queue-4.4/genirq-use-irqd_get_trigger_type-to-compare-the-trigger-type-for-shared-irqs.patch queue-4.4/cpufreq-sh-replace-racy-task-affinity-logic.patch

7 years, 3 months

1
0
0 0

Patch "ACPI/processor: Fix error handling in __acpi_processor_start()" has been added to the 4.4-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.4-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.4 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:57:32 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 @@ -259,6 +259,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.4/acpi-processor-fix-error-handling-in-__acpi_processor_start.patch queue-4.4/acpi-processor-replace-racy-task-affinity-logic.patch queue-4.4/time-change-posix-clocks-ops-interfaces-to-use-timespec64.patch queue-4.4/genirq-use-irqd_get_trigger_type-to-compare-the-trigger-type-for-shared-irqs.patch queue-4.4/cpufreq-sh-replace-racy-task-affinity-logic.patch

7 years, 3 months

1
0
0 0

Patch "ACPI / PMIC: xpower: Fix power_table addresses" has been added to the 4.4-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.4-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.4 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:57:32 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.4/acpi-pmic-xpower-fix-power_table-addresses.patch queue-4.4/rtc-cmos-do-not-assume-irq-8-for-rtc-when-there-are-no-legacy-irqs.patch queue-4.4/genirq-use-irqd_get_trigger_type-to-compare-the-trigger-type-for-shared-irqs.patch queue-4.4/x86-i8259-export-legacy_pic-symbol.patch

7 years, 3 months

1
0
0 0

Patch "xprtrdma: Cancel refresh worker during buffer shutdown" 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 xprtrdma: Cancel refresh worker during buffer shutdown 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: xprtrdma-cancel-refresh-worker-during-buffer-shutdown.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: Chuck Lever <chuck.lever(a)oracle.com> Date: Tue, 11 Apr 2017 13:22:29 -0400 Subject: xprtrdma: Cancel refresh worker during buffer shutdown From: Chuck Lever <chuck.lever(a)oracle.com> [ Upstream commit 9378b274e1eb6925db315e345f48850d2d5d9789 ] Trying to create MRs while the transport is being torn down can cause a crash. Fixes: e2ac236c0b65 ("xprtrdma: Allocate MRs on demand") Signed-off-by: Chuck Lever <chuck.lever(a)oracle.com> Signed-off-by: Anna Schumaker <Anna.Schumaker(a)Netapp.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- net/sunrpc/xprtrdma/verbs.c | 1 + 1 file changed, 1 insertion(+) --- a/net/sunrpc/xprtrdma/verbs.c +++ b/net/sunrpc/xprtrdma/verbs.c @@ -1054,6 +1054,7 @@ void rpcrdma_buffer_destroy(struct rpcrdma_buffer *buf) { cancel_delayed_work_sync(&buf->rb_recovery_worker); + cancel_delayed_work_sync(&buf->rb_refresh_worker); while (!list_empty(&buf->rb_recv_bufs)) { struct rpcrdma_rep *rep; Patches currently in stable-queue which might be from chuck.lever(a)oracle.com are queue-4.9/xprtrdma-cancel-refresh-worker-during-buffer-shutdown.patch

7 years, 3 months

1
0
0 0

Patch "x86/xen: split xen_smp_prepare_boot_cpu()" 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 x86/xen: split xen_smp_prepare_boot_cpu() 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: x86-xen-split-xen_smp_prepare_boot_cpu.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: Vitaly Kuznetsov <vkuznets(a)redhat.com> Date: Tue, 14 Mar 2017 18:35:43 +0100 Subject: x86/xen: split xen_smp_prepare_boot_cpu() From: Vitaly Kuznetsov <vkuznets(a)redhat.com> [ Upstream commit a2d1078a35f9a38ae888aa6147e4ca32666154a1 ] Split xen_smp_prepare_boot_cpu() into xen_pv_smp_prepare_boot_cpu() and xen_hvm_smp_prepare_boot_cpu() to support further splitting of smp.c. Signed-off-by: Vitaly Kuznetsov <vkuznets(a)redhat.com> Reviewed-by: Juergen Gross <jgross(a)suse.com> Signed-off-by: Juergen Gross <jgross(a)suse.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/x86/xen/smp.c | 49 ++++++++++++++++++++++++++++++------------------- 1 file changed, 30 insertions(+), 19 deletions(-) --- a/arch/x86/xen/smp.c +++ b/arch/x86/xen/smp.c @@ -299,35 +299,46 @@ static void __init xen_filter_cpu_maps(v } -static void __init xen_smp_prepare_boot_cpu(void) +static void __init xen_pv_smp_prepare_boot_cpu(void) { BUG_ON(smp_processor_id() != 0); native_smp_prepare_boot_cpu(); - if (xen_pv_domain()) { - if (!xen_feature(XENFEAT_writable_page_tables)) - /* We've switched to the "real" per-cpu gdt, so make - * sure the old memory can be recycled. */ - make_lowmem_page_readwrite(xen_initial_gdt); + if (!xen_feature(XENFEAT_writable_page_tables)) + /* We've switched to the "real" per-cpu gdt, so make + * sure the old memory can be recycled. */ + make_lowmem_page_readwrite(xen_initial_gdt); #ifdef CONFIG_X86_32 - /* - * Xen starts us with XEN_FLAT_RING1_DS, but linux code - * expects __USER_DS - */ - loadsegment(ds, __USER_DS); - loadsegment(es, __USER_DS); + /* + * Xen starts us with XEN_FLAT_RING1_DS, but linux code + * expects __USER_DS + */ + loadsegment(ds, __USER_DS); + loadsegment(es, __USER_DS); #endif - xen_filter_cpu_maps(); - xen_setup_vcpu_info_placement(); - } + xen_filter_cpu_maps(); + xen_setup_vcpu_info_placement(); + + /* + * The alternative logic (which patches the unlock/lock) runs before + * the smp bootup up code is activated. Hence we need to set this up + * the core kernel is being patched. Otherwise we will have only + * modules patched but not core code. + */ + xen_init_spinlocks(); +} + +static void __init xen_hvm_smp_prepare_boot_cpu(void) +{ + BUG_ON(smp_processor_id() != 0); + native_smp_prepare_boot_cpu(); /* * Setup vcpu_info for boot CPU. */ - if (xen_hvm_domain()) - xen_vcpu_setup(0); + xen_vcpu_setup(0); /* * The alternative logic (which patches the unlock/lock) runs before @@ -733,7 +744,7 @@ static irqreturn_t xen_irq_work_interrup } static const struct smp_ops xen_smp_ops __initconst = { - .smp_prepare_boot_cpu = xen_smp_prepare_boot_cpu, + .smp_prepare_boot_cpu = xen_pv_smp_prepare_boot_cpu, .smp_prepare_cpus = xen_smp_prepare_cpus, .smp_cpus_done = xen_smp_cpus_done, @@ -772,5 +783,5 @@ void __init xen_hvm_smp_init(void) smp_ops.cpu_die = xen_cpu_die; smp_ops.send_call_func_ipi = xen_smp_send_call_function_ipi; smp_ops.send_call_func_single_ipi = xen_smp_send_call_function_single_ipi; - smp_ops.smp_prepare_boot_cpu = xen_smp_prepare_boot_cpu; + smp_ops.smp_prepare_boot_cpu = xen_hvm_smp_prepare_boot_cpu; } Patches currently in stable-queue which might be from vkuznets(a)redhat.com are queue-4.9/x86-xen-split-xen_smp_prepare_boot_cpu.patch

7 years, 3 months

1
0
0 0

Patch "x86/reboot: Turn off KVM when halting a CPU" 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 x86/reboot: Turn off KVM when halting a CPU 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: x86-reboot-turn-off-kvm-when-halting-a-cpu.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: Tiantian Feng <fengtiantian(a)huawei.com> Date: Wed, 19 Apr 2017 18:18:39 +0200 Subject: x86/reboot: Turn off KVM when halting a CPU From: Tiantian Feng <fengtiantian(a)huawei.com> [ Upstream commit fba4f472b33aa81ca1836f57d005455261e9126f ] A CPU in VMX root mode will ignore INIT signals and will fail to bring up the APs after reboot. Therefore, on a panic we disable VMX on all CPUs before rebooting or triggering kdump. Do this when halting the machine as well, in case a firmware-level reboot does not perform a cold reset for all processors. Without doing this, rebooting the host may hang. Signed-off-by: Tiantian Feng <fengtiantian(a)huawei.com> Signed-off-by: Xishi Qiu <qiuxishi(a)huawei.com> [ Rewritten commit message. ] Signed-off-by: Paolo Bonzini <pbonzini(a)redhat.com> Cc: Linus Torvalds <torvalds(a)linux-foundation.org> Cc: Peter Zijlstra <peterz(a)infradead.org> Cc: Thomas Gleixner <tglx(a)linutronix.de> Cc: kvm(a)vger.kernel.org Link: http://lkml.kernel.org/r/20170419161839.30550-1-pbonzini@redhat.com Signed-off-by: Ingo Molnar <mingo(a)kernel.org> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/x86/kernel/smp.c | 3 +++ 1 file changed, 3 insertions(+) --- a/arch/x86/kernel/smp.c +++ b/arch/x86/kernel/smp.c @@ -33,6 +33,7 @@ #include <asm/mce.h> #include <asm/trace/irq_vectors.h> #include <asm/kexec.h> +#include <asm/virtext.h> /* * Some notes on x86 processor bugs affecting SMP operation: @@ -162,6 +163,7 @@ static int smp_stop_nmi_callback(unsigne if (raw_smp_processor_id() == atomic_read(&stopping_cpu)) return NMI_HANDLED; + cpu_emergency_vmxoff(); stop_this_cpu(NULL); return NMI_HANDLED; @@ -174,6 +176,7 @@ static int smp_stop_nmi_callback(unsigne asmlinkage __visible void smp_reboot_interrupt(void) { ipi_entering_ack_irq(); + cpu_emergency_vmxoff(); stop_this_cpu(NULL); irq_exit(); } Patches currently in stable-queue which might be from fengtiantian(a)huawei.com are queue-4.9/x86-reboot-turn-off-kvm-when-halting-a-cpu.patch

7 years, 3 months

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror