March 2018 - Linux-stable-mirror

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

6 years, 9 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

6 years, 9 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

6 years, 9 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

6 years, 9 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

6 years, 9 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

6 years, 9 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

6 years, 9 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

6 years, 9 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

6 years, 9 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

6 years, 9 months

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror March 2018