If DCACHE_WORD_ACCESS is enabled big endian image failed to
boot. commit 7bc13fd33adb9536bd73965cd46bbf7377df097c
"arm64: dcache: select DCACHE_WORD_ACCESS for little-endian CPUs"
enabled this setting for both big endian and little endian
cpus. And code in commit itself seems to be endian agnostic,
however other, i.e C, code that sits under DCACHE_WORD_ACCESS
seems to be not endian agnostic, I could not figure out where
though.
Solution is to enable DCACHE_WORD_ACCESS only if little
endian mode is enabled (default).
Signed-off-by: Victor Kamensky <victor.kamensky(a)linaro.org>
---
arch/arm64/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index e6e4d37..106ac4f 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -13,7 +13,7 @@ config ARM64
select CLONE_BACKWARDS
select COMMON_CLK
select CPU_PM if (SUSPEND || CPU_IDLE)
- select DCACHE_WORD_ACCESS
+ select DCACHE_WORD_ACCESS if !CPU_BIG_ENDIAN
select GENERIC_CLOCKEVENTS
select GENERIC_CLOCKEVENTS_BROADCAST if SMP
select GENERIC_CPU_AUTOPROBE
--
1.8.1.4
Hi Guys,
This second version of patch to flush icache and dcache after
uprobes xol write to make written instruction available in icache.
Please see [1] for initial discussion.
This patch follows Russell's suggestion, and function that does
cache flush after xol slot instruction write is shared/reused
with similar one implemented already for ptrace code.
In order to reuse common implementation but to avoid vma use
by xol_get_insn_slot I split flush_ptrace_access into two
functions. Where first part retrieves all required conditions
from vma and places them into flags variable and then calls
second function which is common code.
Also I had to change xol_get_insn_slot function to map page
into kernel explicitly within function without use of
copy_to_page helper because ARM cache flush code need both
kernel address through which instruction write happens and
virtual address of user-land process where instruction will
end up. I hope this call back is universal enough so other
CPU could implement their cache invalidation/sync after
uprobes xol instruction write logic based on provided
parameters.
I've tested it on Arndale board with my SystemTap test case
that had cache problem before. Disassemble of
flush_uprobe_xol_access in case of Arndale shows that compiler
does good job and optimizes out all flags check effectively
leaving on this cpu call to flush_icache_alias or call to
v7_coherent_user_range (__cpuc_coherent_kern_range).
Also tested basic user-level debugging.
Wondering on what ARM boards/cpus could we test cache_is_vivt()
and cache_is_vipt_aliasing cases ...
Just to summarize, please note on [1] there were couple other
suggestions:
Oleg suggested to use flush_icache_user_range but Russell
argument was that meaning of the function is lost and on ARM
it is not implemented in such way that it could address the
issue anyway. Please see [2] for details. Note it would has
vma problem use or not, that should be hacked.
Dave Martin suggested to use flush_icache_range, which is
effectively better way to call
__cpuc_coherent_[kern|user]_range(s,e), that was originally
suggested. But Russell explained that it won't be enough in
case of user-land process pages and variety of cache types have
to be covered. Note for kernel pages it would be OK and it is
used in multiple places like kprobes, modules, etc.
Thanks,
Victor
[1] http://lists.infradead.org/pipermail/linux-arm-kernel/2014-April/245595.htmlhttp://lists.infradead.org/pipermail/linux-arm-kernel/2014-April/245427.html
[2] http://lists.infradead.org/pipermail/linux-arm-kernel/2014-April/245605.html
Victor Kamensky (1):
ARM: uprobes need icache flush after xol write
arch/arm/include/asm/cacheflush.h | 2 ++
arch/arm/kernel/uprobes.c | 6 ++++++
arch/arm/mm/flush.c | 41 +++++++++++++++++++++++++++++++++------
include/linux/uprobes.h | 3 +++
kernel/events/uprobes.c | 33 +++++++++++++++++++++++++------
5 files changed, 73 insertions(+), 12 deletions(-)
--
1.8.1.4
On Tue, Apr 22, 2014 at 05:39:28PM -0700, Dmitry Torokhov wrote:
> On Tue, Apr 22, 2014 at 10:18:21PM +0100, Mark Brown wrote:
> > Remove the bitrotted comment, though in actual fact the use case mentioned
> > is a great use for spi_async() since it would cut down on latency handling
> > the interrupt by saving us a context switch before we start SPI.
> > This was previously implemented, it was removed in commit b534422b2d11
> > (Input: ad7877 - switch to using threaded IRQ) for code complexity reasons.
> > It may be better to revert that commit instead.
> Hmm, maybe.. although I think original would cause device 'stuck' if
> call to spi_async() fails, so probably not a straight revert...
Probably best just to apply this, then - someone can always reimplement
if they need to.
Hello, hopefully this is the correct mailing list for this question:
I'm working on a derivative of the mainline Linux 3.8 kernel and I'm trying
to enable ARM kdump functionality to collect crashdumps when we have kernel
problems. But, there's some kind of unresolved issue in
arch/arm/mm/ioremap.c which prevents /proc/vmcore from being able to
function properly. I checked and this appears to still be in kernel.org
Linux 3.13. The target is a normal, recent ARMv7 chip.
Has this issue been addressed in any version of Linaro's kernel? Or, is
there a work-around? If not, how does a crashdump file get generated when/if
the Linaro kernel crashes or a driver faults?
>> WARNING: at arch/arm/mm/ioremap.c:244
__arm_ioremap_pfn_caller+0x1d8/0x1f0()
>> Modules linked in:
>> [<c0016660>] (unwind_backtrace+0x0/0x138) from [<c0020480>]
(warn_slowpath_common+0x4c/0x64)
>> [<c0020480>] (warn_slowpath_common+0x4c/0x64) from [<c00204b4>]
(warn_slowpath_null+0x1c/0x24)
>> [<c00204b4>] (warn_slowpath_null+0x1c/0x24) from [<c0018e9c>]
(__arm_ioremap_pfn_caller+0x1d8/0x1f0)
>> [<c0018e9c>] (__arm_ioremap_pfn_caller+0x1d8/0x1f0) from [<c0018f20>]
(__arm_ioremap_caller+0x54/0x5c)
>> [<c0018f20>] (__arm_ioremap_caller+0x54/0x5c) from [<c0018c58>]
(__arm_ioremap+0x18/0x1c)
>> [<c0018c58>] (__arm_ioremap+0x18/0x1c) from [<c00168fc>]
(copy_oldmem_page+0x34/0xc0)
>> [<c00168fc>] (copy_oldmem_page+0x34/0xc0) from [<c010350c>]
(read_from_oldmem+0xb8/0xe4)
>> [<c010350c>] (read_from_oldmem+0xb8/0xe4) from [<c05c37e0>]
(parse_crash_elf32_headers+0x184/0x43c)
>> [<c05c37e0>] (parse_crash_elf32_headers+0x184/0x43c) from [<c05c3b64>]
(vmcore_init+0xcc/0x198)
>> [<c05c3b64>] (vmcore_init+0xcc/0x198) from [<c000863c>]
(do_one_initcall+0x34/0x184)
>> [<c000863c>] (do_one_initcall+0x34/0x184) from [<c05b28dc>]
(kernel_init_freeable+0xfc/0x1c8)
>> [<c05b28dc>] (kernel_init_freeable+0xfc/0x1c8) from [<c04326d4>]
(kernel_init+0x8/0xe4)
>> [<c04326d4>] (kernel_init+0x8/0xe4) from [<c000ec58>]
(ret_from_fork+0x14/0x3c)
>>
>> arch/arm/mm/ioremap.c:244
>> /*
>> * Don't allow RAM to be mapped - this causes problems with
ARMv6+
>> */
>> if (WARN_ON(pfn_valid(pfn)))
>> return NULL;
Thanks in advance for any help.
-andy
From: Mark Brown <broonie(a)linaro.org>
While searching for users of spi_async() I found a reference in the ad7877
driver to using it to initiate data transfer from the interrupt handler.
However there is no code for this, instead the interrupt handler is a
threaded handler and uses spi_sync() instead.
Remove the bitrotted comment, though in actual fact the use case mentioned
is a great use for spi_async() since it would cut down on latency handling
the interrupt by saving us a context switch before we start SPI.
This was previously implemented, it was removed in commit b534422b2d11
(Input: ad7877 - switch to using threaded IRQ) for code complexity reasons.
It may be better to revert that commit instead.
Signed-off-by: Mark Brown <broonie(a)linaro.org>
---
drivers/input/touchscreen/ad7877.c | 5 -----
1 file changed, 5 deletions(-)
diff --git a/drivers/input/touchscreen/ad7877.c b/drivers/input/touchscreen/ad7877.c
index 6793c85903ae..523865daa1d3 100644
--- a/drivers/input/touchscreen/ad7877.c
+++ b/drivers/input/touchscreen/ad7877.c
@@ -210,11 +210,6 @@ static bool gpio3;
module_param(gpio3, bool, 0);
MODULE_PARM_DESC(gpio3, "If gpio3 is set to 1 AUX3 acts as GPIO3");
-/*
- * ad7877_read/write are only used for initial setup and for sysfs controls.
- * The main traffic is done using spi_async() in the interrupt handler.
- */
-
static int ad7877_read(struct spi_device *spi, u16 reg)
{
struct ser_req *req;
--
1.9.2
This is a note to let you know that I have just added a patch titled
tick-common: Fix wrong check in tick_check_replacement()
to the linux-3.11.y-queue branch of the 3.11.y.z extended stable tree
which can be found at:
http://kernel.ubuntu.com/git?p=ubuntu/linux.git;a=shortlog;h=refs/heads/lin…
If you, or anyone else, feels it should not be added to this tree, please
reply to this email.
For more information about the 3.11.y.z tree, see
https://wiki.ubuntu.com/Kernel/Dev/ExtendedStable
Thanks.
-Luis
------
>From 39bbe41d9e322c01c6c67cf71763dd66d9172a94 Mon Sep 17 00:00:00 2001
From: Viresh Kumar <viresh.kumar(a)linaro.org>
Date: Tue, 15 Apr 2014 10:54:37 +0530
Subject: tick-common: Fix wrong check in tick_check_replacement()
commit 521c42990e9d561ed5ed9f501f07639d0512b3c9 upstream.
tick_check_replacement() returns if a replacement of clock_event_device is
possible or not. It does this as the first check:
if (tick_check_percpu(curdev, newdev, smp_processor_id()))
return false;
Thats wrong. tick_check_percpu() returns true when the device is
useable. Check for false instead.
[ tglx: Massaged changelog ]
Signed-off-by: Viresh Kumar <viresh.kumar(a)linaro.org>
Cc: linaro-kernel(a)lists.linaro.org
Cc: fweisbec(a)gmail.com
Cc: Arvind.Chauhan(a)arm.com
Cc: linaro-networking(a)linaro.org
Link: http://lkml.kernel.org/r/486a02efe0246635aaba786e24b42d316438bf3b.139753798…
Signed-off-by: Thomas Gleixner <tglx(a)linutronix.de>
Signed-off-by: Luis Henriques <luis.henriques(a)canonical.com>
---
kernel/time/tick-common.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/time/tick-common.c b/kernel/time/tick-common.c
index 64522ec..271ce26 100644
--- a/kernel/time/tick-common.c
+++ b/kernel/time/tick-common.c
@@ -260,7 +260,7 @@ static bool tick_check_preferred(struct clock_event_device *curdev,
bool tick_check_replacement(struct clock_event_device *curdev,
struct clock_event_device *newdev)
{
- if (tick_check_percpu(curdev, newdev, smp_processor_id()))
+ if (!tick_check_percpu(curdev, newdev, smp_processor_id()))
return false;
return tick_check_preferred(curdev, newdev);
--
1.9.1
There have been confusion all the time about which mailing list to follow for
cpufreq activities, linux-pm(a)vger.kernel.org or cpufreq(a)vger.kernel.org.
As Maintainers always wanted people to send patches to linux-pm(a)vger.kernel.org
and kernel source asked them to use cpufreq(a)vger.kernel.org.
Lets make linux-pm(a)vger.kernel.org the official mailing list for cpufreq stuff
and remove all references of cpufreq(a)vger.kernel.org from kernel source.
Later, we can remove the list as well from vger.kernel.org.
Signed-off-by: Viresh Kumar <viresh.kumar(a)linaro.org>
---
Documentation/ABI/testing/sysfs-devices-system-cpu | 4 ++--
Documentation/cpu-freq/index.txt | 4 ++--
MAINTAINERS | 2 --
drivers/cpufreq/speedstep-centrino.c | 2 +-
tools/power/cpupower/Makefile | 2 +-
tools/power/cpupower/debug/kernel/cpufreq-test_tsc.c | 2 +-
6 files changed, 7 insertions(+), 9 deletions(-)
diff --git a/Documentation/ABI/testing/sysfs-devices-system-cpu b/Documentation/ABI/testing/sysfs-devices-system-cpu
index d5a0d33..acb9bfc 100644
--- a/Documentation/ABI/testing/sysfs-devices-system-cpu
+++ b/Documentation/ABI/testing/sysfs-devices-system-cpu
@@ -128,7 +128,7 @@ Description: Discover cpuidle policy and mechanism
What: /sys/devices/system/cpu/cpu#/cpufreq/*
Date: pre-git history
-Contact: cpufreq(a)vger.kernel.org
+Contact: linux-pm(a)vger.kernel.org
Description: Discover and change clock speed of CPUs
Clock scaling allows you to change the clock speed of the
@@ -146,7 +146,7 @@ Description: Discover and change clock speed of CPUs
What: /sys/devices/system/cpu/cpu#/cpufreq/freqdomain_cpus
Date: June 2013
-Contact: cpufreq(a)vger.kernel.org
+Contact: linux-pm(a)vger.kernel.org
Description: Discover CPUs in the same CPU frequency coordination domain
freqdomain_cpus is the list of CPUs (online+offline) that share
diff --git a/Documentation/cpu-freq/index.txt b/Documentation/cpu-freq/index.txt
index 3d0b915..dc024ab 100644
--- a/Documentation/cpu-freq/index.txt
+++ b/Documentation/cpu-freq/index.txt
@@ -35,8 +35,8 @@ Mailing List
------------
There is a CPU frequency changing CVS commit and general list where
you can report bugs, problems or submit patches. To post a message,
-send an email to cpufreq(a)vger.kernel.org, to subscribe go to
-http://vger.kernel.org/vger-lists.html#cpufreq and follow the
+send an email to linux-pm(a)vger.kernel.org, to subscribe go to
+http://vger.kernel.org/vger-lists.html#linux-pm and follow the
instructions there.
Links
diff --git a/MAINTAINERS b/MAINTAINERS
index 6dc67b1..88b60d9 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2415,7 +2415,6 @@ F: drivers/net/ethernet/ti/cpmac.c
CPU FREQUENCY DRIVERS
M: Rafael J. Wysocki <rjw(a)rjwysocki.net>
M: Viresh Kumar <viresh.kumar(a)linaro.org>
-L: cpufreq(a)vger.kernel.org
L: linux-pm(a)vger.kernel.org
S: Maintained
T: git git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git
@@ -2426,7 +2425,6 @@ F: include/linux/cpufreq.h
CPU FREQUENCY DRIVERS - ARM BIG LITTLE
M: Viresh Kumar <viresh.kumar(a)linaro.org>
M: Sudeep Holla <sudeep.holla(a)arm.com>
-L: cpufreq(a)vger.kernel.org
L: linux-pm(a)vger.kernel.org
W: http://www.arm.com/products/processors/technologies/biglittleprocessing.php
S: Maintained
diff --git a/drivers/cpufreq/speedstep-centrino.c b/drivers/cpufreq/speedstep-centrino.c
index 6723f03..7d4a315 100644
--- a/drivers/cpufreq/speedstep-centrino.c
+++ b/drivers/cpufreq/speedstep-centrino.c
@@ -28,7 +28,7 @@
#include <asm/cpu_device_id.h>
#define PFX "speedstep-centrino: "
-#define MAINTAINER "cpufreq(a)vger.kernel.org"
+#define MAINTAINER "linux-pm(a)vger.kernel.org"
#define INTEL_MSR_RANGE (0xffff)
diff --git a/tools/power/cpupower/Makefile b/tools/power/cpupower/Makefile
index cbfec92..3651db7 100644
--- a/tools/power/cpupower/Makefile
+++ b/tools/power/cpupower/Makefile
@@ -62,7 +62,7 @@ LIB_MAJ= 0.0.0
LIB_MIN= 0
PACKAGE = cpupower
-PACKAGE_BUGREPORT = cpufreq(a)vger.kernel.org
+PACKAGE_BUGREPORT = linux-pm(a)vger.kernel.org
LANGUAGES = de fr it cs pt
diff --git a/tools/power/cpupower/debug/kernel/cpufreq-test_tsc.c b/tools/power/cpupower/debug/kernel/cpufreq-test_tsc.c
index 0f10b81..5224ee5 100644
--- a/tools/power/cpupower/debug/kernel/cpufreq-test_tsc.c
+++ b/tools/power/cpupower/debug/kernel/cpufreq-test_tsc.c
@@ -18,7 +18,7 @@
* 5.) if the third value, "diff_pmtmr", changes between 2. and 4., the
* TSC-based delay routine on the Linux kernel does not correctly
* handle the cpufreq transition. Please report this to
- * cpufreq(a)vger.kernel.org
+ * linux-pm(a)vger.kernel.org
*/
#include <linux/kernel.h>
--
1.7.12.rc2.18.g61b472e