On Sat, 2017-02-18 at 06:43 +0900, Masami Hiramatsu wrote:
> On Fri, 17 Feb 2017 11:01:10 +
> "Jon Medhurst (Tixy)" wrote:
[...]
> > Meantime
> > I'll investigate the kprobes test failures I see (which actually looks
> > like cache/TLB issues and not
On Wed, 2017-02-15 at 09:27 +0900, Masami Hiramatsu wrote:
> Hi,
>
> Here is the 2nd version of the patches which improve kprobe
> on arm implementation (a kind of bugfix). Version 1 is here;
>
> https://lkml.org/lkml/2017/2/13/538
>
> In this version I didn't update the code, just update the
>
On Wed, 2017-02-15 at 01:01 +0900, Masami Hiramatsu wrote:
> On Tue, 14 Feb 2017 13:47:07 +
> "Jon Medhurst (Tixy)" wrote:
>
> > On Tue, 2017-02-14 at 10:32 +, Jon Medhurst (Tixy) wrote:
> > > On Tue, 2017-02-14 at 00:05 +0900, Masami Hiramatsu wrote:
On Tue, 2017-02-14 at 10:32 +, Jon Medhurst (Tixy) wrote:
> On Tue, 2017-02-14 at 00:05 +0900, Masami Hiramatsu wrote:
> > This is arm port of commit 737480a0d525 ("kprobes/x86:
> > Fix the return address of multiple kretprobes").
> >
> > Fix the return
On Tue, 2017-02-14 at 00:05 +0900, Masami Hiramatsu wrote:
> This is arm port of commit 737480a0d525 ("kprobes/x86:
> Fix the return address of multiple kretprobes").
>
> Fix the return address of subsequent kretprobes when multiple
> kretprobes are set on the same function.
>
> For example:
>
>
On Tue, 2017-02-14 at 00:03 +0900, Masami Hiramatsu wrote:
> This is arm port of commit 6a5022a56ac3 ("kprobes/x86: Allow to
> handle reentered kprobe on single-stepping")
>
> Since the FIQ handlers can interrupt in the single stepping
> (or preparing the single stepping, do_debug etc.), we should
On Tue, 2017-02-14 at 00:04 +0900, Masami Hiramatsu wrote:
> Kprobes/arm skips single-stepping (moreover handling the event)
> if the conditional instruction must not be executed. This
> also apply the rule when we hit the recursing kprobe, so
> that kprobe does not count nmissed up in that case.
If a DAI specifies "#sound-dai-cells = <0>" in device-tree then
hdmi_of_xlate_dai_name() will be called with zero args, which it isn't
implemented to cope with. The resulting use of an uninitialised variable
for the id will usually result in an error like:
asoc-simple-card sound: parse error -11
If a DAI specifies "#sound-dai-cells = <0>" in device-tree then
hdmi_of_xlate_dai_name() will be called with zero args, which it isn't
implemented to cope with. The resulting use of an uninitialised variable
for the id will usually result in an error like:
asoc-simple-card sound: parse error -11
On Thu, 2016-06-16 at 18:59 +0100, Sudeep Holla wrote:
>
> On 16/06/16 18:47, Jon Medhurst (Tixy) wrote:
> > On Thu, 2016-06-16 at 11:38 +0100, Sudeep Holla wrote:
> > [...]
> >> +enum scpi_power_domain_state {
> >> + SCPI_PD_STATE_ON = 0,
> >> + SCP
On Thu, 2016-06-16 at 11:37 +0100, Sudeep Holla wrote:
> SCPI protocol supports device power state management. This deals with
> power states of various peripheral devices in the system other than the
> core compute subsystem.
>
> This patch adds support for the power state management of those
> p
On Thu, 2016-06-16 at 11:38 +0100, Sudeep Holla wrote:
[...]
> +enum scpi_power_domain_state {
> + SCPI_PD_STATE_ON = 0,
> + SCPI_PD_STATE_OFF = 3,
> +};
The SCPI doc defines the meaning of these numbers (0 and 3) in the 'Juno
specifics' chapter. So does these values need to come from devi
On Thu, 2016-06-16 at 11:37 +0100, Sudeep Holla wrote:
> This series add support for SCPI based device device power state
> management using genpd.
>
> Regards,
> Sudeep
>
> v1[1]->v2:
> - Fixed the endianness handling in scpi_device_get_power_state
> as spotted by Tixy
> - Re
On Mon, 2016-06-06 at 16:53 +0100, Sudeep Holla wrote:
> This patch hooks up the support for device power domain provided by
> SCPI using the Linux generic power domain infrastructure.
>
> Cc: "Rafael J. Wysocki"
> Cc: Kevin Hilman
> Cc: Ulf Hansson
> Cc: linux...@vger.kernel.org
> Signed-off-b
On Mon, 2016-06-06 at 16:53 +0100, Sudeep Holla wrote:
> SCPI protocol supports device power state management. This deals with
> power states of various peripheral devices in the system other than the
> core compute subsystem.
>
> This patch adds support for the power state management of those
> p
On Mon, 2016-05-16 at 18:14 -0700, Greg Kroah-Hartman wrote:
> 3.14-stable review patch. If anyone has any objections, please let me know.
As reported by Guenter Roeck, this patch doesn't compile on 3.14 because
it deleted randomize_base which is still used by the macro
ELF_ET_DYN_BASE. That use
On Tue, 2016-05-10 at 10:55 -0700, Kees Cook wrote:
> This fixes two issues with the arm64 brk randomziation. First, the
> STACK_RND_MASK was being used incorrectly. The original code was:
>
> unsigned long range_end = base + (STACK_RND_MASK << PAGE_SHIFT) + 1;
>
> STACK_RND_MASK is 0x7ff (
On Fri, 2016-03-11 at 13:13 +0530, Vinod Koul wrote:
> On Tue, Mar 08, 2016 at 03:50:41PM +0000, Jon Medhurst (Tixy) wrote:
>
> > > The reside is requested for "a descriptor". For example if you have
> > > prepared
> > > two descriptors A and B and
On Tue, 2016-03-08 at 19:45 +0530, Vinod Koul wrote:
> On Tue, Mar 08, 2016 at 10:40:11AM +0000, Jon Medhurst (Tixy) wrote:
> > On Tue, 2016-03-08 at 09:42 +0530, Vinod Koul wrote:
> > > On Wed, Feb 24, 2016 at 01:14:34PM +0000, Jon Medhurst (Tixy) wrote:
> > > &
On Tue, 2016-03-08 at 09:42 +0530, Vinod Koul wrote:
> On Wed, Feb 24, 2016 at 01:14:34PM +0000, Jon Medhurst (Tixy) wrote:
> > The residue calculation in pl330_tx_status doesn't handle transitional
> > states that occur at the time one descriptor (A) is completed and the
>
On Thu, 2016-03-03 at 12:07 +0900, Masahiro Yamada wrote:
[...]
> This patch is derived from Rob Herring' comment
> "BTW, we should also kill off "amba-bus" which is an ambiguous term"
> in the following thread:
> http://lkml.iu.edu/hypermail/linux/kernel/1601.0/01822.html
>
>
> So, the plan woul
The residue calculation in pl330_tx_status doesn't handle transitional
states that occur at the time one descriptor (A) is completed and the
next (B) is started. Specifically, both A and B can simultaneously be in
the BUSY state and at this time the thread's 'req_running' may (or may
not) be -1.
T
On Thu, 2016-02-18 at 18:59 +, Robin Murphy wrote:
> On 18/02/16 18:12, Jon Medhurst (Tixy) wrote:
> > On Thu, 2016-02-18 at 18:05 +0100, Arnd Bergmann wrote:
> >> build-testing with clang showed that the "J" constraint does not take
> >> positive argument
On Thu, 2016-02-18 at 18:05 +0100, Arnd Bergmann wrote:
> build-testing with clang showed that the "J" constraint does not take
> positive arguments on clang when building in for Thumb-2:
>
> core.c:540:3: error: invalid operand for inline asm constraint 'J'
>
> This has been reported as llvm bug
On Thu, 2016-02-18 at 15:02 +0100, Arnd Bergmann wrote:
> ARMv3 did not have 16-bit load/store or 32-bit multiply instructions,
> so building the kprobe test code fails with lots of warnings about
> these:
>
> /tmp/ccI4SKHx.s:19585: Error: selected processor does not support ARM mode
> `umull r0,
On Thu, 2016-02-11 at 15:05 +0530, Archit Taneja wrote:
> component_master_add_with_match can fail if the master's bind op doesn't
> go through successfully. In such a scenario, all the components in the
> master's match array have their 'master' pointer set to the given master.
> These pointers ne
In the case that the driver is configured from device-tree
i2s_reg_comp1 and i2s_reg_comp2 aren't initialised, breaking the driver.
Fix this by unconditionally setting these values before checking for quirks.
Fixes: a242cac1d3aa ("ASoC: dwc: add quirk to override COMP_PARAM_1 register")
Signed-of
On Thu, 2016-01-21 at 16:58 -0800, Laura Abbott wrote:
> On 01/21/2016 12:19 PM, Jon Medhurst (Tixy) wrote:
[...]
> > If sg_dma_len() is correct or acceptable then it seems to me that the
> > ION code should set that length. Especially as the comment in the code
> > implies
On Thu, 2016-01-21 at 09:39 -0800, Laura Abbott wrote:
> On 01/21/2016 03:57 AM, Jon Medhurst (Tixy) wrote:
> > From: Liviu Dudau
> >
> > ion_buffer_create() will allocate a buffer and then create a DMA
> > mapping for it, but it forgot to set the length of the page ent
Hi
In trying to work out why audio stopped working on ARM's Juno board I
bisected the problem to $subject commit and reverting this fixed things.
The symptoms of broken audio was that alsa-utils' speaker-test produced
very short duration 'churps' rather than the voice sample naming each
speaker ch
From: Liviu Dudau
ion_buffer_create() will allocate a buffer and then create a DMA
mapping for it, but it forgot to set the length of the page entries.
Signed-off-by: Liviu Dudau
Signed-off-by: Jon Medhurst
---
drivers/staging/android/ion/ion.c | 4 +++-
1 file changed, 3 insertions(+), 1 del
On Wed, 2016-01-20 at 14:46 +, Robin Murphy wrote:
> > Of course, the 0.004014s maybe not accurate enough, it is just an
> > approximate number.
>
> A mean and standard deviation of at least, say, 5 runs each with and
> without the patch would be considerably more meaningful (even if
> still
On Fri, 2015-12-11 at 10:34 +, Russell King - ARM Linux wrote:
> On Fri, Dec 11, 2015 at 10:27:13AM +0000, Jon Medhurst (Tixy) wrote:
> > On Fri, 2015-12-11 at 00:05 -0500, David Long wrote:
> > > There is a moderate amount of code already in kprobes on ARM and the
> &g
On Fri, 2015-12-11 at 00:05 -0500, David Long wrote:
> There is a moderate amount of code already in kprobes on ARM and the
> current ARMv8 patch to deal with conditional execution of instructions.
> One aspect of how this is handled is that instructions that fail their
> predicate and are not (
On Wed, 2015-12-02 at 22:19 +0100, Ben Gamari wrote:
> The frequency units are very confusing in this area as OPPs use Hz
> whereas cpufreq uses kHz. Be explicit about this in variable naming.
>
> Cc: Javier Martinez Canillas
> Signed-off-by: Ben Gamari
> ---
> drivers/cpufreq/arm_big_little.c
On Wed, 2015-11-25 at 13:09 -0500, Nicolas Pitre wrote:
> But CPU MHz, when available, has the merit of not being open to
> interpretation.
Current MHz, maximum MHz or 'turbo' MHz? ;-)
--
Tixy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message
On Thu, 2015-11-12 at 10:42 +, Liviu Dudau wrote:
> > This is on-chip RAM or nornal system RAM? We already have bindings
> for
> > both.
>
> Juno has a set of TLX (ThinLinks) connectors on the board where an
> FPGA can be attached. On r1
> the code running on FPGA can even participate as an AX
On Wed, 2015-10-21 at 15:27 +0530, Viresh Kumar wrote:
> On 21-10-15, 10:55, Jon Medhurst (Tixy) wrote:
> > The check for correct frequency being set in bL_cpufreq_set_rate is
> > broken when the big.LITTLE switcher is active, for two reasons.
> >
> > 1. The 'new
The check for correct frequency being set in bL_cpufreq_set_rate is
broken when the big.LITTLE switcher is active, for two reasons.
1. The 'new_rate' variable gets overwritten before the test by the
code calculating the frequency of the old cluster.
2. The frequency returned by bL_cpufreq_get_rat
On Wed, 2015-10-14 at 09:48 +0100, Sudeep Holla wrote:
>
> On 14/10/15 08:12, Jon Medhurst (Tixy) wrote:
> > On Tue, 2015-10-13 at 11:36 +0100, Sudeep Holla wrote:
> >>
> >> On 13/10/15 08:19, Jon Medhurst (Tixy) wrote:
> > [...]
> >>> But then
On Tue, 2015-10-13 at 11:36 +0100, Sudeep Holla wrote:
>
> On 13/10/15 08:19, Jon Medhurst (Tixy) wrote:
[...]
> > But then we wouldn't get the WARN_ON and pr_err triggered when we detect
> > the clock rate isn't set, which surely is half the reason for the
On Mon, 2015-10-12 at 14:20 +0100, Sudeep Holla wrote:
>
> On 08/10/15 10:23, Jon Medhurst (Tixy) wrote:
> [...]
>
> > diff --git a/drivers/cpufreq/arm_big_little.c
> > b/drivers/cpufreq/arm_big_little.c
> > index f1e42f8..59115a4 100644
> > --- a/driver
On Thu, 2015-10-08 at 16:54 +0530, Viresh Kumar wrote:
> On 08-10-15, 10:23, Jon Medhurst (Tixy) wrote:
> > On Wed, 2015-10-07 at 23:09 +0530, Viresh Kumar wrote:
[...]
> > > @@ -140,9 +140,11 @@ bL_cpufreq_set_rate(u32 cpu, u32 old_cluster, u32
> >
On Wed, 2015-10-07 at 23:09 +0530, Viresh Kumar wrote:
[...]
> And why not fix it properly by doing this:
>
> diff --git a/drivers/cpufreq/arm_big_little.c
> b/drivers/cpufreq/arm_big_little.c
> index f1e42f8ce0fc..5b36657a76d6 100644
> --- a/drivers/cpufreq/arm_big_little.c
> +++ b/drivers/cpufr
The check for correct frequency being set in bL_cpufreq_set_rate is
broken when the big.LITTLE switcher is active, for two reasons.
1. The 'new_rate' variable gets overwritten before the test by the
code calculating the frequency of the old cluster.
2. The frequency returned by bL_cpufreq_get_rat
On Tue, 2015-09-15 at 17:04 +0100, Punit Agrawal wrote:
> "Jon Medhurst (Tixy)" writes:
>
> > On Tue, 2015-09-15 at 10:37 +0100, Punit Agrawal wrote:
> >> "Jon Medhurst (Tixy)" writes:
> >>
> >> > On Mon, 2015-09-14 at
On Tue, 2015-09-15 at 12:03 +0100, Mark Rutland wrote:
> On Tue, Sep 15, 2015 at 11:46:02AM +0100, Jon Medhurst (Tixy) wrote:
> > On Tue, 2015-09-15 at 10:37 +0100, Punit Agrawal wrote:
> > > "Jon Medhurst (Tixy)" writes:
> > >
> > > > On Mo
On Tue, 2015-09-15 at 10:37 +0100, Punit Agrawal wrote:
> "Jon Medhurst (Tixy)" writes:
>
> > On Mon, 2015-09-14 at 15:38 +0100, Punit Agrawal wrote:
> >> Mark Rutland writes:
> >>
[...]
> >> The way the SCP interface is defined, the sensor iden
On Mon, 2015-09-14 at 15:38 +0100, Punit Agrawal wrote:
> Mark Rutland writes:
>
> >> >> +Sensor bindings for the sensors based on SCPI Message Protocol
> >> >> +--
> >> >> +SCPI provides an API to access the various sensors on the SoC.
I haven't reviewed the code in detail, just had one comment I alluded to
in a private email the other day...
On Wed, 2015-08-05 at 15:28 +0100, Liviu Dudau wrote:
> diff --git a/drivers/gpu/drm/arm/hdlcd_crtc.c
> b/drivers/gpu/drm/arm/hdlcd_crtc.c
[...]
> +void hdlcd_set_scanout(struct hdlcd_drm
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)
>
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 devi
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 d
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 to
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 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)&
ng the policy.
>
> 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.
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";
> +
> +
iver 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 th
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 be
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 doma
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 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? ;-) ...
https://github.com/ARM-softwa
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 pat
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 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
iver 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 (Ti
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 dr
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
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 pa
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 an
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 tr
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 +0000, Jon Medhurst (Tixy) wrote:
> > On Fri, 2015-01-09 at 14:37 +0800, Wang Nan wrote:
> > > + " and r4, sp, #4\n"
> > > +
branch instruction 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
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 t
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 gen
branch instruction 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: Wan
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 ins
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 tho
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 kpro
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] FA
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
setup_test_context
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
setup_test_context
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 arise
; reexecute 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:
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
branch instruction 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
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
&g
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 CP
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
1 - 100 of 204 matches
Mail list logo
