the CPU/system power management. It also adds the SRAM reserving the
> > shared memory and SCPI message protocol using that shared memory.
> >
> > Signed-off-by: Sudeep Holla
> > Acked-by: Liviu Dudau
> > Cc: Jon Medhurst (Tixy)
>
. It also adds the SRAM reserving the
shared memory and SCPI message protocol using that shared memory.
Signed-off-by: Sudeep Holla sudeep.ho...@arm.com
Acked-by: Liviu Dudau liviu.du...@arm.com
Cc: Jon Medhurst (Tixy) t...@linaro.org
---
arch/arm64/boot/dts/arm/juno-base.dtsi | 54
On Tue, 2015-07-28 at 10:32 -0400, Mark Salter wrote:
> When booting an arm64 kernel w/initrd using UEFI/grub, use of mem= will likely
> cut off part or all of the initrd. This leaves it outside the kernel linear
> map which leads to failure when unpacking.
Have we got a similar issue for the
On Tue, 2015-07-28 at 10:32 -0400, Mark Salter wrote:
When booting an arm64 kernel w/initrd using UEFI/grub, use of mem= will likely
cut off part or all of the initrd. This leaves it outside the kernel linear
map which leads to failure when unpacking.
Have we got a similar issue for the
On Fri, 2015-07-17 at 16:21 +0100, Robin Murphy wrote:
> This also begs the question as to what happens if the memory region _is_
> > contiguous but is in highmem or an ioremapped region. Should a device
> > always provide dma_ops for that case? Because I believe the current
> > implementation of
Use dma_get_sgtable rather than dma_common_get_sgtable so a device's
dma_ops aren't bypassed. This is essential in situations where a device
uses an IOMMU and the physical memory is not contiguous (as the common
function assumes).
Signed-off-by: Jon Medhurst
---
This also begs the question as
On Fri, 2015-07-17 at 16:21 +0100, Robin Murphy wrote:
This also begs the question as to what happens if the memory region _is_
contiguous but is in highmem or an ioremapped region. Should a device
always provide dma_ops for that case? Because I believe the current
implementation of
Use dma_get_sgtable rather than dma_common_get_sgtable so a device's
dma_ops aren't bypassed. This is essential in situations where a device
uses an IOMMU and the physical memory is not contiguous (as the common
function assumes).
Signed-off-by: Jon Medhurst t...@linaro.org
---
This also begs
On Thu, 2015-07-16 at 02:32 +0200, Rafael J. Wysocki wrote:
> On Wednesday, July 08, 2015 04:50:23 PM Viresh Kumar wrote:
> > On 08-07-15, 12:17, Jon Medhurst (Tixy) wrote:
> > > I tried these patches without the earlier "cpufreq: Initialize the
> > > governor aga
On Thu, 2015-07-16 at 02:32 +0200, Rafael J. Wysocki wrote:
On Wednesday, July 08, 2015 04:50:23 PM Viresh Kumar wrote:
On 08-07-15, 12:17, Jon Medhurst (Tixy) wrote:
I tried these patches without the earlier cpufreq: Initialize the
governor again while restoring policy patch
On Tue, 2015-07-07 at 19:23 +0100, Morten Rasmussen wrote:
> From: Dietmar Eggemann
>
> To enable the parsing of clock frequency and cpu efficiency values
> inside parse_dt_topology [arch/arm/kernel/topology.c] to scale the
> relative capacity of the cpus, this property has to be provided within
On Wed, 2015-07-08 at 15:12 +0530, Viresh Kumar wrote:
> cpufreq_init_policy() can fail, and we don't do anything except a call
> to ->exit() on that. The policy should be freed if this happens.
>
> Lets do it properly.
>
> Reported-by: "Jon Medhurst (Tixy)"
icy.
>
> Reported-by: Pi-Cheng Chen
> Reported-by: "Jon Medhurst (Tixy)"
> Fixes: 18bf3a124ef8 ("cpufreq: Mark policy->governor = NULL for inactive
> policies")
> Signed-off-by: Viresh Kumar
> ---
Tested-by: Jon Medhurst
Thanks for that.
I believe
On Tue, 2015-07-07 at 19:23 +0100, Morten Rasmussen wrote:
From: Dietmar Eggemann dietmar.eggem...@arm.com
To enable the parsing of clock frequency and cpu efficiency values
inside parse_dt_topology [arch/arm/kernel/topology.c] to scale the
relative capacity of the cpus, this property has to
On Wed, 2015-07-08 at 15:12 +0530, Viresh Kumar wrote:
cpufreq_init_policy() can fail, and we don't do anything except a call
to -exit() on that. The policy should be freed if this happens.
Lets do it properly.
Reported-by: Jon Medhurst (Tixy) t...@linaro.org
Signed-off-by: Viresh Kumar
...@linaro.org
Reported-by: Jon Medhurst (Tixy) t...@linaro.org
Fixes: 18bf3a124ef8 (cpufreq: Mark policy-governor = NULL for inactive
policies)
Signed-off-by: Viresh Kumar viresh.ku...@linaro.org
---
Tested-by: Jon Medhurst t...@linaro.org
Thanks for that.
I believe this also fixes the other
On Mon, 2015-06-08 at 11:40 +0100, Sudeep Holla wrote:
[...]
> +
> + scpi {
> + compatible = "arm,scpi";
> + mboxes = < 1>;
> + shmem = <_scp_hpri>;
> +
> + clocks {
> + compatible = "arm,scpi-clocks";
> +
> +
On Mon, 2015-06-08 at 11:40 +0100, Sudeep Holla wrote:
[...]
+
+ scpi {
+ compatible = arm,scpi;
+ mboxes = mailbox 1;
+ shmem = cpu_scp_hpri;
+
+ clocks {
+ compatible = arm,scpi-clocks;
+
+
ver provides interface for all the client drivers using
> SCPI to make use of the features offered by the SCP.
>
> Signed-off-by: Sudeep Holla
> CC: Jassi Brar
> Cc: Liviu Dudau
> Cc: Lorenzo Pieralisi
> Cc: Jon Medhurst (Tixy)
> ---
Sorry for the delay in looking at this. I
drivers using
SCPI to make use of the features offered by the SCP.
Signed-off-by: Sudeep Holla sudeep.ho...@arm.com
CC: Jassi Brar jassisinghb...@gmail.com
Cc: Liviu Dudau liviu.du...@arm.com
Cc: Lorenzo Pieralisi lorenzo.pieral...@arm.com
Cc: Jon Medhurst (Tixy) t...@linaro.org
---
Sorry
On Tue, 2015-05-19 at 12:31 +0100, Liviu Dudau wrote:
> On Tue, May 19, 2015 at 11:56:43AM +0100, Jon Medhurst (Tixy) wrote:
> > On Mon, 2015-05-18 at 18:28 +0100, Liviu Dudau wrote:
> > > Juno based boards have a memory mapped timer @ 0x2a81. This
> > > is disabled
On Mon, 2015-05-18 at 18:28 +0100, Liviu Dudau wrote:
> Juno based boards have a memory mapped timer @ 0x2a81. This
> is disabled on r0 version of the board due to an SoC errata.
So wouldn't it make more sense then to disable it in the dts for r0? As
it is, you disable it in the common file
On Mon, 2015-05-18 at 18:28 +0100, Liviu Dudau wrote:
Juno based boards have a memory mapped timer @ 0x2a81. This
is disabled on r0 version of the board due to an SoC errata.
So wouldn't it make more sense then to disable it in the dts for r0? As
it is, you disable it in the common file
On Tue, 2015-05-19 at 12:31 +0100, Liviu Dudau wrote:
On Tue, May 19, 2015 at 11:56:43AM +0100, Jon Medhurst (Tixy) wrote:
On Mon, 2015-05-18 at 18:28 +0100, Liviu Dudau wrote:
Juno based boards have a memory mapped timer @ 0x2a81. This
is disabled on r0 version of the board due
On Thu, 2015-05-14 at 15:18 +0100, Mark Rutland wrote:
> On Thu, May 14, 2015 at 03:07:31PM +0100, Jon Medhurst (Tixy) wrote:
> > On Wed, 2015-05-13 at 18:11 +0100, Liviu Dudau wrote:
> > > This board is based on Juno r0 with updated Cortex A5x revisions
> > > and
On Wed, 2015-05-13 at 18:11 +0100, Liviu Dudau wrote:
> This board is based on Juno r0 with updated Cortex A5x revisions
> and board errata fixes. It also contains coherent ThinLinks ports
> on the expansion slot that allow for an AXI master on the daughter
> card to participate in a coherency
On Thu, 2015-05-14 at 14:11 +0100, Liviu Dudau wrote:
> On Thu, May 14, 2015 at 12:04:31PM +0100, Jon Medhurst (Tixy) wrote:
> > On Thu, 2015-05-14 at 11:30 +0100, Liviu Dudau wrote:
> > > On Thu, May 14, 2015 at 10:35:42AM +0100, Jon Medhurst (Tixy) wrote:
> > [...]
> &
On Thu, 2015-05-14 at 11:30 +0100, Liviu Dudau wrote:
> On Thu, May 14, 2015 at 10:35:42AM +0100, Jon Medhurst (Tixy) wrote:
[...]
> >
> > What criteria were used to select the contents of juno-base.dtsi?
> > From what I can see, the stuff left out of base is still the same f
On Wed, 2015-05-13 at 18:11 +0100, Liviu Dudau wrote:
> Prepare the device tree for adding more boards based on Juno r0.
>
> Signed-off-by: Liviu Dudau
> ---
> arch/arm64/boot/dts/arm/juno-base.dtsi | 125
> +
> arch/arm64/boot/dts/arm/juno.dts | 122
On Wed, 2015-05-13 at 18:11 +0100, Liviu Dudau wrote:
This board is based on Juno r0 with updated Cortex A5x revisions
and board errata fixes. It also contains coherent ThinLinks ports
on the expansion slot that allow for an AXI master on the daughter
card to participate in a coherency domain.
On Thu, 2015-05-14 at 14:11 +0100, Liviu Dudau wrote:
On Thu, May 14, 2015 at 12:04:31PM +0100, Jon Medhurst (Tixy) wrote:
On Thu, 2015-05-14 at 11:30 +0100, Liviu Dudau wrote:
On Thu, May 14, 2015 at 10:35:42AM +0100, Jon Medhurst (Tixy) wrote:
[...]
What criteria were used
On Thu, 2015-05-14 at 15:18 +0100, Mark Rutland wrote:
On Thu, May 14, 2015 at 03:07:31PM +0100, Jon Medhurst (Tixy) wrote:
On Wed, 2015-05-13 at 18:11 +0100, Liviu Dudau wrote:
This board is based on Juno r0 with updated Cortex A5x revisions
and board errata fixes. It also contains
On Thu, 2015-05-14 at 11:30 +0100, Liviu Dudau wrote:
On Thu, May 14, 2015 at 10:35:42AM +0100, Jon Medhurst (Tixy) wrote:
[...]
What criteria were used to select the contents of juno-base.dtsi?
From what I can see, the stuff left out of base is still the same for r0
and r1 (cpu, pmu
On Wed, 2015-05-13 at 18:11 +0100, Liviu Dudau wrote:
Prepare the device tree for adding more boards based on Juno r0.
Signed-off-by: Liviu Dudau liviu.du...@arm.com
---
arch/arm64/boot/dts/arm/juno-base.dtsi | 125
+
arch/arm64/boot/dts/arm/juno.dts
On Fri, 2015-05-01 at 15:15 +0100, Sudeep Holla wrote:
> No issues, it's better to have remainders like this :). I plan to post
> something in the next version.
Will that also include the other piece of the puzzle to get the
big.LITTLE cpufreq driver running? ;-) ...
On Fri, 2015-05-01 at 14:32 +0100, Sudeep Holla wrote:
>
> On 01/05/15 14:19, Jon Medhurst (Tixy) wrote:
> > On Mon, 2015-04-27 at 12:40 +0100, Sudeep Holla wrote:
> >> On some ARM based systems, a separate Cortex-M based System Control
> >> Processor(SCP) provides t
On Mon, 2015-04-27 at 12:40 +0100, Sudeep Holla wrote:
> On some ARM based systems, a separate Cortex-M based System Control
> Processor(SCP) provides the overall power, clock, reset and system
> control including CPU DVFS. SCPI Message Protocol is used to
> communicate with the SCPI.
>
> This
On Fri, 2015-05-01 at 14:32 +0100, Sudeep Holla wrote:
On 01/05/15 14:19, Jon Medhurst (Tixy) wrote:
On Mon, 2015-04-27 at 12:40 +0100, Sudeep Holla wrote:
On some ARM based systems, a separate Cortex-M based System Control
Processor(SCP) provides the overall power, clock, reset
On Fri, 2015-05-01 at 15:15 +0100, Sudeep Holla wrote:
No issues, it's better to have remainders like this :). I plan to post
something in the next version.
Will that also include the other piece of the puzzle to get the
big.LITTLE cpufreq driver running? ;-) ...
On Mon, 2015-04-27 at 12:40 +0100, Sudeep Holla wrote:
On some ARM based systems, a separate Cortex-M based System Control
Processor(SCP) provides the overall power, clock, reset and system
control including CPU DVFS. SCPI Message Protocol is used to
communicate with the SCPI.
This patch
On Wed, 2015-04-29 at 13:25 +0100, Jon Medhurst (Tixy) wrote:
> diff --git a/drivers/mailbox/scpi_protocol.c
> b/drivers/mailbox/scpi_protocol.c
> index c74575b..5818d9b 100644
> --- a/drivers/mailbox/scpi_protocol.c
> +++ b/drivers/mailbox/scpi_protocol.c
> @@ -286,14 +286
On Wed, 2015-04-29 at 13:25 +0100, Jon Medhurst (Tixy) wrote:
diff --git a/drivers/mailbox/scpi_protocol.c
b/drivers/mailbox/scpi_protocol.c
index c74575b..5818d9b 100644
--- a/drivers/mailbox/scpi_protocol.c
+++ b/drivers/mailbox/scpi_protocol.c
@@ -286,14 +286,23 @@ static void
On Wed, 2015-04-29 at 12:43 +0100, Jon Medhurst (Tixy) wrote:
> On Wed, 2015-04-29 at 11:53 +0100, Sudeep Holla wrote:
> > On 28/04/15 14:54, Jon Medhurst (Tixy) wrote:
> > > On Mon, 2015-04-27 at 12:40 +0100, Sudeep Holla wrote:
> [...]
> > >> + int
On Wed, 2015-04-29 at 11:53 +0100, Sudeep Holla wrote:
> On 28/04/15 14:54, Jon Medhurst (Tixy) wrote:
> > On Mon, 2015-04-27 at 12:40 +0100, Sudeep Holla wrote:
[...]
> >> + int ret;
> >> + u8 token, chan;
> >> + struct scpi_xfer *msg;
&g
On Wed, 2015-04-29 at 11:53 +0100, Sudeep Holla wrote:
On 28/04/15 14:54, Jon Medhurst (Tixy) wrote:
On Mon, 2015-04-27 at 12:40 +0100, Sudeep Holla wrote:
[...]
+ int ret;
+ u8 token, chan;
+ struct scpi_xfer *msg;
+ struct scpi_chan *scpi_chan;
+
+ chan
On Wed, 2015-04-29 at 12:43 +0100, Jon Medhurst (Tixy) wrote:
On Wed, 2015-04-29 at 11:53 +0100, Sudeep Holla wrote:
On 28/04/15 14:54, Jon Medhurst (Tixy) wrote:
On Mon, 2015-04-27 at 12:40 +0100, Sudeep Holla wrote:
[...]
+ int ret;
+ u8 token, chan;
+ struct
ver provides interface for all the client drivers using
> SCPI to make use of the features offered by the SCP.
>
> Signed-off-by: Sudeep Holla
> Cc: Rob Herring
> Cc: Mark Rutland
> CC: Jassi Brar
> Cc: Liviu Dudau
> Cc: Lorenzo Pieralisi
> Cc: Jon Medhurst (Tixy)
lorenzo.pieral...@arm.com
Cc: Jon Medhurst (Tixy) t...@linaro.org
Cc: devicet...@vger.kernel.org
---
There are several spelling errors but I won't point out each, sure you
can find them with a spellcheck ;-) I'll just comment on the code...
[...]
+++ b/drivers/mailbox/scpi_protocol.c
@@ -0,0 +1,694
On Mon, 2015-04-27 at 12:40 +0100, Sudeep Holla wrote:
> Hi,
>
> This patch series adds support for:
> 1. SCPI(System Control and Power Interface) mailbox protocol
> driver.
Is there a public document with the final protocol specification?
I have spotted an inconsistency between
On Mon, 2015-04-27 at 12:40 +0100, Sudeep Holla wrote:
Hi,
This patch series adds support for:
1. SCPI(System Control and Power Interface) mailbox protocol
driver.
Is there a public document with the final protocol specification?
I have spotted an inconsistency between driver
Hi Janusz
On Thu, 2015-02-05 at 16:17 +0100, Janusz Użycki wrote:
> I got the compilation error on next-20150204:
>
[...]
> In file included from arch/arm/probes/kprobes/core.c:37:
> arch/arm/probes/kprobes/core.h:43: error: '[*]' not allowed in other
> than a declaration
[...]
> gcc version
Hi Janusz
On Thu, 2015-02-05 at 16:17 +0100, Janusz Użycki wrote:
I got the compilation error on next-20150204:
[...]
In file included from arch/arm/probes/kprobes/core.c:37:
arch/arm/probes/kprobes/core.h:43: error: '[*]' not allowed in other
than a declaration
[...]
gcc version 4.2.4
This patch utilizes the previously introduced checker to check
register usage for probed ARM instruction and saves it in a mask.
A further patch will use such information to avoid simulation or
emulation.
Signed-off-by: Wang Nan
Reviewed-by: Jon Medhurst
Signed-off-by: Jon Medhurst
---
This
On Mon, 2015-01-05 at 19:29 +0800, Wang Nan wrote:
> This patch utilizes previous introduced checker to check register usage
> for probed ARM instruction and saves it in a mask. Futher patch will
> use such information to avoid simuation or emulation.
There's a couple of spelling mistakes above
On Mon, 2015-01-05 at 19:29 +0800, Wang Nan wrote:
This patch utilizes previous introduced checker to check register usage
for probed ARM instruction and saves it in a mask. Futher patch will
use such information to avoid simuation or emulation.
There's a couple of spelling mistakes above and
This patch utilizes the previously introduced checker to check
register usage for probed ARM instruction and saves it in a mask.
A further patch will use such information to avoid simulation or
emulation.
Signed-off-by: Wang Nan wangn...@huawei.com
Reviewed-by: Jon Medhurst t...@linaro.org
Hi All
I'm wondering what the correct route is for getting kprobes patches into
mainline Linux. In particular I'm interested in a patch from Masami
Hiramatsu [1] which is a dependency for some ARM kprobes work we want to
merge. If acceptable, we could submit that one though the ARM
maintainer's
Hi All
I'm wondering what the correct route is for getting kprobes patches into
mainline Linux. In particular I'm interested in a patch from Masami
Hiramatsu [1] which is a dependency for some ARM kprobes work we want to
merge. If acceptable, we could submit that one though the ARM
maintainer's
On Fri, 2015-01-09 at 17:57 +, Russell King - ARM Linux wrote:
[...]
> For me:
>
> $ echo 'asm ("bx r2\n");' | arm-linux-gcc -x c -c -marm -march=armv4 -v - -o
> o.o
>
> calls the assembler thusly:
>
> /usr/local/lib/gcc/arm-linux-gnueabi/4.7.4/../../../../arm-linux-gnueabi/bin/as
> \
>
On Fri, 2015-01-09 at 16:35 +, Russell King - ARM Linux wrote:
> On Fri, Jan 09, 2015 at 10:25:54AM +0000, Jon Medhurst (Tixy) wrote:
> > On Fri, 2015-01-09 at 14:37 +0800, Wang Nan wrote:
> > > + " and r4, sp, #4\n"
> > > +
truction before optimizer is called. Different from x86_64,
> which only copy the probed insn after optprobe_template_end and
> reexecute them, this patch call singlestep to emulate/simulate the insn
> directly. Futher patch can optimize this behavior.
>
> Signed-off-by: Wang Nan
&
On Fri, 2015-01-09 at 10:19 +0800, Wang Nan wrote:
> In discussion on LKML (https://lkml.org/lkml/2014/11/28/158), Russell
> King suggests to move all probe related code to arch/arm/probes. This
> patch does the work. Due to dependency on 'arch/arm/kernel/patch.h', this
> patch also moves patch.h
On Fri, 2015-01-09 at 10:19 +0800, Wang Nan wrote:
In discussion on LKML (https://lkml.org/lkml/2014/11/28/158), Russell
King suggests to move all probe related code to arch/arm/probes. This
patch does the work. Due to dependency on 'arch/arm/kernel/patch.h', this
patch also moves patch.h to
Medhurst (Tixy) t...@linaro.org
Reviewed-by: Jon Medhurst (Tixy) t...@linaro.org
Cc: Russell King - ARM Linux li...@arm.linux.org.uk
Cc: Will Deacon will.dea...@arm.com
---
[...]
+asm (
+ .global optprobe_template_entry\n
+ optprobe_template_entry:\n
On Fri, 2015-01-09 at 17:57 +, Russell King - ARM Linux wrote:
[...]
For me:
$ echo 'asm (bx r2\n);' | arm-linux-gcc -x c -c -marm -march=armv4 -v - -o
o.o
calls the assembler thusly:
/usr/local/lib/gcc/arm-linux-gnueabi/4.7.4/../../../../arm-linux-gnueabi/bin/as
\
-v
On Fri, 2015-01-09 at 16:35 +, Russell King - ARM Linux wrote:
On Fri, Jan 09, 2015 at 10:25:54AM +, Jon Medhurst (Tixy) wrote:
On Fri, 2015-01-09 at 14:37 +0800, Wang Nan wrote:
+and r4, sp, #4\n
+sub sp, sp, r4\n
I think that the patches up to 09/11 inclusive have been though more
that enough review and revisions to think about getting them merged,
there doesn't seem much point in continuously resending them whilst new
features are built on top of them.
Masami Hiramatsu, are you happy for your patch to
truction before optimizer is called. Different from x86_64,
> which only copy the probed insn after optprobe_template_end and
> reexecute them, this patch call singlestep to emulate/simulate the insn
> directly. Futher patch can optimize this behavior.
>
> Signed-off-by: Wang Nan
On Mon, 2015-01-05 at 19:29 +0800, Wang Nan wrote:
> There are 3 actions which is never used:
>
> PROBES_MOV_HALFWORD,
> PROBES_SEV,
> PROBES_WFE,
>
> This patch removes them.
>
> Signed-off-by: Wang Nan
I think that PROBES_MOV_HALFWORD should be used, for MOVW and MOVT.
Currently those
Medhurst (Tixy) t...@linaro.org
Reviewed-by: Jon Medhurst (t...@linaro.org
Cc: Russell King - ARM Linux li...@arm.linux.org.uk
Cc: Will Deacon will.dea...@arm.com
---
arch/arm/Kconfig| 1 +
arch/arm/{kernel = include/asm}/insn.h | 0
arch/arm/include/asm/kprobes.h
I think that the patches up to 09/11 inclusive have been though more
that enough review and revisions to think about getting them merged,
there doesn't seem much point in continuously resending them whilst new
features are built on top of them.
Masami Hiramatsu, are you happy for your patch to
On Mon, 2015-01-05 at 19:29 +0800, Wang Nan wrote:
There are 3 actions which is never used:
PROBES_MOV_HALFWORD,
PROBES_SEV,
PROBES_WFE,
This patch removes them.
Signed-off-by: Wang Nan wangn...@huawei.com
I think that PROBES_MOV_HALFWORD should be used, for MOVW and MOVT.
On Wed, 2014-12-10 at 21:18 +0800, Wang Nan wrote:
[...]
> Well, I'm just working on a patch which introducing a TEST_INTOFF and disable
> interrupts
> for "MRS" testcase. Do you think it is inappropriate?
That's what I started to do, implementing in a similar way to
DONT_TEST_IN_ITBLOCK, and
Hi Masami Hiramatsu
How should this patch find its way into the mainline? Is it OK to submit
this as part of the ARM kprobe changes (which presumably will go in via
Russell's tree)?
--
Tixy
On Mon, 2014-12-08 at 22:09 +0800, Wang Nan wrote:
> From: Masami Hiramatsu
>
> Pass the original
On Wed, 2014-12-10 at 16:23 +0800, Wang Nan wrote:
> Hi Tixy,
>
> I experienced another FAIL during test:
>
> [11567.220477] Miscellaneous instructions
> [11567.265397] -
> [11567.342626] mrsr0, cpsr@ e10f
> [11568.612656]
On Wed, 2014-12-10 at 16:23 +0800, Wang Nan wrote:
Hi Tixy,
I experienced another FAIL during test:
[11567.220477] Miscellaneous instructions
[11567.265397] -
[11567.342626] mrsr0, cpsr@ e10f
[11568.612656] FAIL:
Hi Masami Hiramatsu
How should this patch find its way into the mainline? Is it OK to submit
this as part of the ARM kprobe changes (which presumably will go in via
Russell's tree)?
--
Tixy
On Mon, 2014-12-08 at 22:09 +0800, Wang Nan wrote:
From: Masami Hiramatsu
On Wed, 2014-12-10 at 21:18 +0800, Wang Nan wrote:
[...]
Well, I'm just working on a patch which introducing a TEST_INTOFF and disable
interrupts
for MRS testcase. Do you think it is inappropriate?
That's what I started to do, implementing in a similar way to
DONT_TEST_IN_ITBLOCK, and thought
These have extra 'checker' functions associated with them so lets make
sure those get covered by testing. As they may create uninitialised
space on the stack we also update the test code to ensure such space is
consistent between test runs. This is done by disabling interrupts in
These have extra 'checker' functions associated with them so lets make
sure those get covered by testing. As they may create uninitialised
space on the stack we also update the test code to ensure such space is
consistent between test runs. This is done by disabling interrupts in
On Tue, 2014-12-09 at 19:14 +0900, Masami Hiramatsu wrote:
> (2014/12/08 20:50), Jon Medhurst (Tixy) wrote:> arch_optimize_kprobes is
> calling __arch_optimize_kprobes, which is
> > iterating over a list of probes and removing each one in turn, if this
> > is happen
On Tue, 2014-12-09 at 10:14 +0800, Wang Nan wrote:
> Hi all,
>
> Looks like v15 patch solves the problems found in patch v13 and v14. I run
> Tixy's test
> cases in a loop for a whole night on two real unpublished Hisilicon ARM A15
> SoCs (I
> backported kprobes to 3.10 kernel), no problem
e them, this patch call singlestep to emulate/simulate the insn
> > directly. Futher patch can optimize this behavior.
> >
> > Signed-off-by: Wang Nan
> > Acked-by: Masami Hiramatsu
> > Cc: Jon Medhurst (Tixy)
> > Cc: Russell King - ARM Linux
> > Cc: Will Deaco
Acked-by: Masami Hiramatsu masami.hiramatsu...@hitachi.com
Cc: Jon Medhurst (Tixy) t...@linaro.org
Cc: Russell King - ARM Linux li...@arm.linux.org.uk
Cc: Will Deacon will.dea...@arm.com
---
v1 - v2:
- Improvement: if replaced instruction is conditional, generate a
conditional branch
On Tue, 2014-12-09 at 10:14 +0800, Wang Nan wrote:
Hi all,
Looks like v15 patch solves the problems found in patch v13 and v14. I run
Tixy's test
cases in a loop for a whole night on two real unpublished Hisilicon ARM A15
SoCs (I
backported kprobes to 3.10 kernel), no problem arise, they
On Tue, 2014-12-09 at 19:14 +0900, Masami Hiramatsu wrote:
(2014/12/08 20:50), Jon Medhurst (Tixy) wrote: arch_optimize_kprobes is
calling __arch_optimize_kprobes, which is
iterating over a list of probes and removing each one in turn, if this
is happening on multiple cpu's simultaneously
These have extra 'checker' functions associated with them so lets make
sure those get covered by testing. As they may create uninitialised
space on the stack we also update the test code to ensure such space is
consistent between test runs. This is done by disabling interrupts in
These have extra 'checker' functions associated with them so lets make
sure those get covered by testing. As they may create uninitialised
space on the stack we also update the test code to ensure such space is
consistent between test runs. This is done by disabling interrupts in
On Mon, 2014-12-08 at 20:31 +0800, Wang Nan wrote:
> On 2014/12/8 20:06, Wang Nan wrote:
> > On 2014/12/8 19:50, Jon Medhurst (Tixy) wrote:
> >> On Mon, 2014-12-08 at 19:15 +0800, Wang Nan wrote:
> >>> On 2014/12/8 19:04, Jon Medhurst (Tixy) wrote:
> >>>
On Mon, 2014-12-08 at 19:15 +0800, Wang Nan wrote:
> On 2014/12/8 19:04, Jon Medhurst (Tixy) wrote:
> > On Mon, 2014-12-08 at 14:28 +0800, Wang Nan wrote:
> >> This patch introduce kprobeopt for ARM 32.
> >>
> >> Limitations:
> >> - Currently o
truction before optimizer is called. Different from x86_64,
> which only copy the probed insn after optprobe_template_end and
> reexecute them, this patch call singlestep to emulate/simulate the insn
> directly. Futher patch can optimize this behavior.
>
> Signed-off-by: Wang Nan
>
Medhurst (Tixy) t...@linaro.org
Cc: Russell King - ARM Linux li...@arm.linux.org.uk
Cc: Will Deacon will.dea...@arm.com
---
[...]
v13 - v14:
- Use stop_machine to wrap arch_optimize_kprobes to avoid a racing.
Think we need to use stop_machine differently, see comments on code
below.
---
arch
On Mon, 2014-12-08 at 19:15 +0800, Wang Nan wrote:
On 2014/12/8 19:04, Jon Medhurst (Tixy) wrote:
On Mon, 2014-12-08 at 14:28 +0800, Wang Nan wrote:
This patch introduce kprobeopt for ARM 32.
Limitations:
- Currently only kernel compiled with ARM ISA is supported.
- Offset between
On Mon, 2014-12-08 at 20:31 +0800, Wang Nan wrote:
On 2014/12/8 20:06, Wang Nan wrote:
On 2014/12/8 19:50, Jon Medhurst (Tixy) wrote:
On Mon, 2014-12-08 at 19:15 +0800, Wang Nan wrote:
On 2014/12/8 19:04, Jon Medhurst (Tixy) wrote:
On Mon, 2014-12-08 at 14:28 +0800, Wang Nan wrote
On Fri, 2014-12-05 at 10:10 +, Jon Medhurst (Tixy) wrote:
[...]
> I'm worried because this whole optimised kprobes has some rather
> complicated interactions, e.g. can the background thread that changes
> breakpoints to jumps (or back again?) could occur at the same time
>
On Fri, 2014-12-05 at 18:32 +0800, Wang Nan wrote:
> Both your and mine failure are related to ldrd/h instruction. What
> about your second failed testcase?
Can't remember exactly, but it was some instruction that didn't access
memory I remember that much.
I've also just run the tests on an A9
On Fri, 2014-12-05 at 11:38 +0800, Wang Nan wrote:
> On 2014/12/5 0:21, Jon Medhurst (Tixy) wrote:
> > On Thu, 2014-12-04 at 13:36 +0800, Wang Nan wrote:
> >
>
> [trim some text]
>
> >
> > I have retested this patch and on one of the arm test cases I get an
On Fri, 2014-12-05 at 11:38 +0800, Wang Nan wrote:
On 2014/12/5 0:21, Jon Medhurst (Tixy) wrote:
On Thu, 2014-12-04 at 13:36 +0800, Wang Nan wrote:
[trim some text]
I have retested this patch and on one of the arm test cases I get an
undefined instruction exception
On Fri, 2014-12-05 at 18:32 +0800, Wang Nan wrote:
Both your and mine failure are related to ldrd/h instruction. What
about your second failed testcase?
Can't remember exactly, but it was some instruction that didn't access
memory I remember that much.
I've also just run the tests on an A9 CPU
On Fri, 2014-12-05 at 10:10 +, Jon Medhurst (Tixy) wrote:
[...]
I'm worried because this whole optimised kprobes has some rather
complicated interactions, e.g. can the background thread that changes
breakpoints to jumps (or back again?) could occur at the same time
another CPU
101 - 200 of 408 matches
Mail list logo
