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
ions or says otherwise). Meantime
I'll investigate the kprobes test failures I see (which actually looks
like cache/TLB issues and not test code problems after all).
BTW, I added the ARM kernel list to the CC. I spotted you didn't add it
to you patch postings, which means people interested in ARM (other than
Russell) wouldn't have seen them.
Thanks
--
Tixy
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
lues need to come from device-tree
to allow for other hardware or SCP implementations?
--
Tixy
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
&
g symbols.
I think you need to select PM_GENERIC_DOMAINS as well. Or perhaps just
instead of, as PM_GENERIC_DOMAINS_OF defaults 'y' and isn't user
selectable. From kernel/power/Kconfig ...
config PM_GENERIC_DOMAINS_OF
def_bool y
depends on PM_GENERIC_DOMAINS && OF
[...]
--
Tixy
t dev_pstate_set dev_set = {
> + .dev_id = cpu_to_le16(dev_id),
> + .pstate = pstate,
> + };
> +
> + return scpi_send_message(SCPI_CMD_SET_DEVICE_PWR_STATE, &dev_set,
> + sizeof(dev_set), &stat, sizeof(stat));
> +}
> +
[...]
--
Tixy
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 +, 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 +, 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 +, 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
>
g to do, depending on the firmware used
to boot Linux.
> [4] Drop "arm,amba-bus" from of_default_bus_match_table
--
Tixy
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,
ter_del(), which take care of
updating the relevant references between components and master.
For component_master_del this is not immediately obvious, but
take_down_master calls devres_release_group which causes
devm_component_match_release to be called.
--
Tixy
> ---
> drivers/base/component.c
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
(Looks like we'd need to
stash the number of used hardware channels in struct dw_i2s_dev).
--
Tixy
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
I
don't believe you can reliably measure such minor changes.
It doesn't mean that the proposed change isn't a good addition though,
it obviously results in less code getting executed for the cost of one
or two instructions for a compare and branch.
--
Tixy
On Fri, 2015-12-11 at 10:34 +, Russell King - ARM Linux wrote:
> On Fri, Dec 11, 2015 at 10:27:13AM +, 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
e
fortest==false. But if it decides to use conditional instructions it
will (on some CPU implementations). And the choice between
branch/conditional instructions probably varies between GCC version and
kernel configs.
So again, IMO, the current kprobes implementation leads to consistency.
--
T
}
>
> pr_debug("%s: cpu: %d, old cluster: %d, new cluster: %d, freq: %d\n",
> @@ -236,7 +236,7 @@ bL_cpufreq_set_rate(u32 cpu, u32 old_cluster, u32
> new_cluster, u32 rate)
> } else if (ret && bLs) {
> per_cpu(cpu_last_req_freq
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"
can even participate as an AXI master with
> full coherency. The FPGA
> has local memory that we want to share with the HDLCD to be used as a
> framebuffer.
The HDLCD on the Juno chip or one implemented in the FPGA? I assume you
mean the latter but just wanted to check.
--
Tixy
--
To
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
space have holes? Or are they always contiguous?
>
> The way the SCP interface is defined, the sensor identifiers are
> contiguous,
Is there any documentation other than DUI0922A? [1] From what I can seen
that just says it's a 16-bit value and doesn't put any pa
ope for
incorrect addresses being calculated leading to a nasty glitch on the
screen for one frame. And in the worst case, possibly invalid pointer
being dereferenced.
So, if scanout needs to be set on every vsync, would it not be safer
(and more efficient) to have a single variable storing the
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)
>
e for the device-tree blob?
--
Tixy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
if you like.
That would be good. Especially as from what I see on the arm kernel
lists you are already working in that area... And my inbox has just
pinged with that patch from you, so I'll add a reference here [2] so
people coming across this thread can find it easily.
For 32-bit arm my $sub
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
ashes from outside of the
mainline Linux tree and the values I added to that commit were probably
copied from some patch originating from ARM or elsewhere anyway. So the
second paragraph is this commit message is probably superfluous. But
this is nitpicking I guess :-)
--
Tixy
--
To unsubscribe fr
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.
is
one being currently used by the out-of-tree code).
Also, I believe that both display outputs share the same clock, and so
pxlclk0 and pxlclk1 can't be controlled independently. But I guess these
device-tree entries are for the interface to the SCP firmware, not the
hardware, and if that p
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
her than what
they currently propose [2].
[1] https://lists.linaro.org/pipermail/linaro-android/2015-April/002743.html
[2] https://lists.linaro.org/pipermail/linaro-android/2015-April/002742.html
--
Tixy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
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
avoids duplication of source code.
I can only assume there are come non-public differences between r0 and
r1?
--
Tixy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
hub.com/ARM-software/linux/commit/29c33a5865437f0745e8e3a9beb5f82694257b4d
With that, and device-tree updates [1], I've finally managed to get this
patch series running on Juno with v4.1-rc1 and they pass some basic
smoke testing.
--
Tixy
--
To unsubscribe from this list: send the line "uns
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
x-linaro-tracking.git/commit/4b5dd8ff98613b7e90c8f3214522a00ab6900fe9
http://git.linaro.org/kernel/linux-linaro-tracking.git/commit/8641dbfe253f6a9061742ca11f769fc1d82c2aaa
Any reason why the above two aren't suitable for mainline Linux? The
second was actually committed then reverted because it brok
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
istency between driver and a draft doc I have
but before commenting on things like that it would be good to have the
final version of the document instead.
--
Tixy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kerne
e situations and that
the version of GCC that I use (4.9.1) doesn't complain about it.
If it's valid C, I've no idea what that syntax that might represent.
--
Tixy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
patch applies my review comments on "[PATCH v19 10/11] ARM:
kprobes: check register usage for probed instruction."
It is also rebased on top of the kprobes-opt branch at
git://git.linaro.org/people/tixy/kernel.git
arch/arm/include/asm/probes.h | 1 +
arch/arm/probe
egs_normal},
> + [PROBES_BITFIELD] = {.checker = arm_check_regs_normal},
> + [PROBES_LDMSTM] = {.checker = arm_check_regs_ldmstm},
> + [PROBES_MOV_IP_SP] = {.checker = arm_check_regs_mov_ip_sp},
> + [PROBES_LDRSTRD] = {.checker = arm_check_regs_ldrdstrd},
> +
intainer's tree with our other work.
[1] http://marc.info/?l=linux-kernel&m=142045769001242&w=2
(kprobes: Pass the original kprobe for preparing optimized kprobe)
Thanks
--
Tixy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" i
x?
I guess the answer is yes if we want to catch uses of BX in inline
assembly. A quick and not very thorough grep of arch/arm for 'bx'
doesn't seem to turn up any existing dodgy uses, except in the kprobes
test code I wrote :-(
--
Tixy
--
To unsubscribe from this list: send the
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"
> > > +
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
t;
> #include
>
> -#include "patch.h"
> +#include
To keep alphabetical ordering of headers this should be above the
#include
Don't bother resending the patch, I'll just update the patch in the git
branch I'm putting together.
--
Tixy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
her a branch in a
git repository for those patches, or I'm more than happy to do that if
you like. Then I can give the series a final test and we can send a pull
request to Russell King.
Thanks all
--
Tixy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
t
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
ps non-secure mode will always read FIQ flag as zero in such a
case?)
So in the end I thought the only robust way of writing the tests would
be to ignore the values of the A and F flags.
--
Tixy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of
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
>
> Pas
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@ e10
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
567bfab 4567c0ab
4567c1ab 4567c2ab 4567c3ab 4567c4ab
4567c5ab 4567c6ab 4567c7ab 4567c8ab
strh r3, [r13, #-64-8]! @ e16d34b8
strhr4, [r14, #-64-8]! @ e16e44b8
--
Tixy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@
; 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
un the tests on an A9 CPU and get the Oops on the nop
after the 'wfi' instruction test. So looks like the problem isn't
related to particular test cases.
--
Tixy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord..
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 207 matches
Mail list logo
