On Fri, Jan 23, 2015 at 05:54:45PM +, Russell King - ARM Linux wrote:
> On Fri, Jan 23, 2015 at 05:50:39PM +0000, Will Deacon wrote:
> > On Fri, Jan 23, 2015 at 05:31:54PM +, Andy Whitcroft wrote:
> > > diff --git a/arch/arm64/kernel/psci.c b/arch/arm64/kernel/psci.c
&
On Sun, Jan 25, 2015 at 03:56:52PM +, Russell King - ARM Linux wrote:
> On Sat, Jan 24, 2015 at 04:23:42PM -0600, Felipe Balbi wrote:
> > yeah, I'll try a few older kernels, also see if I can reproduce on other
> > boards.
>
> Perf works for me with CONFIG_FRAME_POINTER=y, but that's only for
On Mon, Jan 26, 2015 at 12:12:43PM +, Arnaldo Carvalho de Melo wrote:
> Em Mon, Jan 26, 2015 at 10:27:11AM +0000, Will Deacon escreveu:
> > On Sun, Jan 25, 2015 at 03:56:52PM +, Russell King - ARM Linux wrote:
> > > On Sat, Jan 24, 2015 at 04:23:42PM -0600, Felipe Balbi w
Hi Paul,
I started dusting off a series I've been working to implement a relaxed
atomic API in Linux (i.e. things like atomic_read(v, ACQUIRE)) but I'm
having trouble making sense of the ordering semantics we have in mainline
today:
1. Does smp_mb__before_spinlock actually have to order prior l
Melo
> Cc: Adrian Hunter
> Cc: Jiri Olsa
> Cc: Namhyung Kim
> Cc: Avi Kivity
> Cc: Masami Hiramatsu
> Cc: Anton Blanchard
> Cc: David Ahern
> Cc: Will Deacon
> Cc: Dave Martin
> ---
> tools/perf/util/symbol-elf.c | 8
> 1 file changed, 8 in
Hi Oleg,
On Tue, Jan 13, 2015 at 06:45:10PM +, Oleg Nesterov wrote:
> On 01/13, Will Deacon wrote:
> >
> > 1. Does smp_mb__before_spinlock actually have to order prior loads
> > against later loads and stores? Documentation/memory-barriers.txt
> > say
On Wed, Jan 14, 2015 at 07:42:53PM +, Mitchel Humpherys wrote:
> On Tue, Dec 16 2014 at 01:45:27 AM, Will Deacon wrote:
> > On Mon, Dec 15, 2014 at 11:47:23PM +, Mitchel Humpherys wrote:
> >> From: Matt Wagantall
> >>
> >> It is sometimes necessary to
On Tue, Jan 06, 2015 at 09:51:15PM +, Michael S. Tsirkin wrote:
> On Tue, Jan 06, 2015 at 11:48:20PM +0200, Michael S. Tsirkin wrote:
> > On Tue, Jan 06, 2015 at 07:14:32PM +0000, Will Deacon wrote:
> > > Hi Michael,
> > >
> > > On Tue, Jan 06, 2015 at
;
> Signed-off-by: Michael S. Tsirkin
> ---
Acked-by: Will Deacon
Will
> arch/arm64/include/asm/uaccess.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm64/include/asm/uaccess.h
> b/arch/arm64/include/asm/uaccess.h
> index 9a2069b..
On Wed, Jan 07, 2015 at 10:10:34AM +, Suzuki K. Poulose wrote:
> On 07/01/15 05:52, Leo Yan wrote:
> > Currently kernel has set the bit SCTLR_EL1.SED, so the SETEND
> > instruction will be treated as UNALLOCATED; this error can be
> > reproduced when ARMv8 cpu runs with EL1/aarch64 and EL0/aarc
On Wed, Jan 07, 2015 at 10:58:24AM +, Leo Yan wrote:
> On Wed, Jan 07, 2015 at 10:10:34AM +, Suzuki K. Poulose wrote:
> > On 07/01/15 05:52, Leo Yan wrote:
> > >Currently kernel has set the bit SCTLR_EL1.SED, so the SETEND
> > >instruction will be treated as UNALLOCATED; this error can be
>
ey)
> @@ -39,8 +40,6 @@ l_yes:
> return true;
> }
>
> -#endif /* __KERNEL__ */
> -
> typedef u64 jump_label_t;
>
> struct jump_entry {
> @@ -49,4 +48,5 @@ struct jump_entry {
> jump_label_t key;
> };
>
> +#endif /* __ASSEMBLY__ */
> #endi
_get is removed from the search case, this is handled
> by the remaining return when ret is not -ENOENT.
>
> Signed-off-by: Mark Rutland
> Cc: Will Deacon
> Cc: Peter Zijlstra
> Cc: Paul Mackerras
> Cc: Ingo Molnar
> Cc: Arnaldo Carvalho de Melo
> ---
> ke
On Thu, Jan 08, 2015 at 08:56:39AM +, Arnd Bergmann wrote:
> On Wednesday 07 January 2015 18:04:41 Murali Karicheri wrote:
> > On 01/07/2015 04:18 PM, Arnd Bergmann wrote:
> > > On Wednesday 07 January 2015 13:49:50 Murali Karicheri wrote:
> > >> PCI devices on Keystone doesn't have correct dma
On Wed, Jan 07, 2015 at 06:49:53PM +, Murali Karicheri wrote:
> Add of_pci_dma_configure() to allow updating the dma configuration
> of the pci device using the configuration from DT of the parent of
> the root bridge device.
>
> Signed-off-by: Murali Karicheri
> ---
> drivers/of/of_pci.c
On Wed, Dec 31, 2014 at 03:21:17PM +, Pratyush Anand wrote:
> Its better to keep all BRK opcodes used by kprobes and uprobes at one
> place. Therefore move these defines to asm/insn.h.
>
> Signed-off-by: Pratyush Anand
> ---
> arch/arm64/include/asm/insn.h | 6 ++
> arch/arm64/kernel/kpr
On Wed, Dec 31, 2014 at 03:21:18PM +, Pratyush Anand wrote:
> Most of the stuff of kprobes-arm64.c can also be used by uprobes.c. So
> move all those part to common code area. In the process rename kprobe to
> probe whereever possible.
>
> No functional change.
In which case, can you merge th
On Wed, Dec 31, 2014 at 03:21:20PM +, Pratyush Anand wrote:
> instruction_pointer_set is needed for uprobe implementation. Hence
> define it for ARM64.
>
> Signed-off-by: Pratyush Anand
> ---
> arch/arm64/include/asm/ptrace.h | 6 ++
> 1 file changed, 6 insertions(+)
>
> diff --git a/ar
On Fri, Jan 02, 2015 at 06:05:23PM +, Oleg Nesterov wrote:
> Let me repeat once again that I know absolutely nothing about arm* ;)
>
> On 12/31, Pratyush Anand wrote:
> >
> > uprobe registers a handler at step_hook. So, single_step_handler now
> > checks for user mode as well if there is a val
On Wed, Dec 31, 2014 at 03:21:24PM +, Pratyush Anand wrote:
> This patch adds support for uprobe on ARM64 architecture.
>
> Unit test for following has been done so far and they have been found
> working
> 1. Normal instruction, which can be probed like sub, ldr, add etc.
> 2. Instructions whi
Hi Daniel,
Some minor comments below...
On Wed, Jan 07, 2015 at 12:28:18PM +, Daniel Thompson wrote:
> Some ARM platforms mux the PMU interrupt of every core into a single
> SPI. On such platforms if the PMU of any core except 0 raises an interrupt
> then it cannot be serviced and eventually,
On Thu, Jan 08, 2015 at 05:33:08PM +, Pratyush Anand wrote:
> On Thursday 08 January 2015 10:25 PM, Will Deacon wrote:
> > On Wed, Dec 31, 2014 at 03:21:18PM +, Pratyush Anand wrote:
> >> Most of the stuff of kprobes-arm64.c can also be used by uprobes.c. So
> >
On Thu, Jan 08, 2015 at 10:25:15PM +, Arnd Bergmann wrote:
> On Thursday 08 January 2015 14:52:13 Murali Karicheri wrote:
> >
> > Could you add this as as a follow up patch as I don't have a platformm
> > that support IOMMU and as such my understanding of the IOMMU is limited?
> >
> > I can
Hi Linus,
Here is a handful of minor arm64 fixes discovered and fixed over the
Christmas break. The main part is adding some missing #includes that we
seem to be getting transitively but have started causing problems in
-next. Please pull.
Thanks,
Will
--->8
The following changes since commit
h_efi_memory_desc(&memmap, md) {
> - u64 paddr, npages, size;
I'm glad to see the back of this function, thanks.
Acked-by: Will Deacon
Will
--
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/
t; 5 files changed, 1 insertion(+), 48 deletions(-)
Looks like a good cleanup!
Acked-by: Will Deacon
Will
> diff --git a/arch/arm64/include/asm/efi.h b/arch/arm64/include/asm/efi.h
> index effef3713c5a..7baf2cc04e1e 100644
> --- a/arch/arm64/include/asm/efi.h
> +++ b/arch/arm64
On Fri, Jan 09, 2015 at 06:37:36PM +, Marc Zyngier wrote:
> On 09/01/15 17:57, Mark Rutland wrote:
> > On Fri, Jan 09, 2015 at 02:27:06PM +, Mark Langsdorf wrote:
> >> On 01/09/2015 08:19 AM, Steve Capper wrote:
> >>> On 9 January 2015 at 12:13, Mark Rutland wrote:
> On Thu, Jan 08, 2
Hi Linus, Laszlo,
On Sat, Jan 10, 2015 at 04:39:05AM +, Linus Torvalds wrote:
> On Fri, Jan 9, 2015 at 7:29 PM, Laszlo Ersek wrote:
> > I've bisected this issue to
Thanks for bisecting this!
> .. commit f045bbb9fa1b ("mmu_gather: fix over-eager
> tlb_flush_mmu_free() calling")
>
> Hmm. Tha
On Sat, Jan 10, 2015 at 07:51:03PM +, Linus Torvalds wrote:
> On Sat, Jan 10, 2015 at 5:37 AM, Will Deacon wrote:
> >>
> >> Will?
> >
> > I'm wondering if this is now broken in the fullmm case, because tlb->end
> > will be zero and we won't
On Fri, Jan 09, 2015 at 07:45:49PM +, Arnd Bergmann wrote:
> On Friday 09 January 2015 16:56:03 Robin Murphy wrote:
> >
> > This one's a bit tricky to find a home for - I think technically it's
> > probably an IOMMU patch, but then the long-underlying problem doesn't
> > seem to have blown up
On Mon, Jan 12, 2015 at 04:55:11PM +, Mark Salter wrote:
> Commit 0e63ea48b4d8 (arm64/efi: add missing call to early_ioremap_reset())
> added a missing call to early_ioremap_reset(). This triggers a BUG if code
> tries using early_ioremap() after the early_ioremap_reset(). This is a
> problem f
On Fri, Jan 09, 2015 at 05:13:29PM +, Pratyush Anand wrote:
>
>
> On Friday 09 January 2015 09:16 PM, Will Deacon wrote:
> > On Thu, Jan 08, 2015 at 05:28:37PM +, Pratyush Anand wrote:
> >> On Thursday 08 January 2015 09:53 PM, Will Deacon wrote:
> >>>
On Sat, Jan 10, 2015 at 02:34:46AM +, Rob Herring wrote:
> Convert the generic host PCI driver to use the generic config access
> functions.
>
> Signed-off-by: Rob Herring
> Cc: Will Deacon
> Cc: Bjorn Helgaas
> Cc: linux-...@vger.kernel.org
> Cc: linux-arm-ke
On Sun, Jan 11, 2015 at 02:32:30PM +, Roman Pen wrote:
> thread_info->syscall is used only for ptrace, but syscall number
> is also used by syscall_get_nr and returned to userspace by the
> following proc file access:
>
> $ cat /proc/self/syscall
> 0 0x3 0xbe928bd8 0x1000 0x0 0xac9e0 0x3 0xb
radar, it'd be quicke
if you just take the patch. I added a commit log/SoB below.
Cheers,
Will
--->8
>From bcf792ffc9ce29415261d2055954b883c5bec978 Mon Sep 17 00:00:00 2001
From: Will Deacon
Date: Mon, 12 Jan 2015 19:10:55 +
Subject: [PATCH] mm: mmu_gather: use tlb->end != 0 only
> >> either "$d" or "$d.". But current code that handles mapping
> >> symbols only deals with the first, dollar character and a single
> >> letter, case.
> >>
> >> The patch adds handling of the second case with period
> >>
On Fri, Jan 09, 2015 at 04:16:10PM +, Daniel Thompson wrote:
> Some ARM platforms mux the PMU interrupt of every core into a single
> SPI. On such platforms if the PMU of any core except 0 raises an interrupt
> then it cannot be serviced and eventually, if you are lucky, the spurious
> irq dete
On Thu, Jan 15, 2015 at 12:54:56PM +, Jiri Olsa wrote:
> hi,
> I'm following up on latest post from Alexis:
> http://marc.info/?l=linux-kernel&m=141427580405357&w=2
>
> v2 changes:
> - build Makefiles librarized and moved to 'tools/build' [Ingo]
> - several minor fixies [Namhyung]
> -
On Fri, Jan 16, 2015 at 12:12:14PM +, Mark Rutland wrote:
> On Fri, Jan 16, 2015 at 11:39:22AM +0000, Will Deacon wrote:
> > On Thu, Jan 15, 2015 at 12:54:56PM +, Jiri Olsa wrote:
> > > hi,
> > > I'm following up on latest post from Alexis:
> >
On Fri, Jan 16, 2015 at 12:05:18PM +, Mark Brown wrote:
> On Fri, Jan 16, 2015 at 10:10:34AM +, Catalin Marinas wrote:
>
> > Indeed, keeping the series as one thread is better. Apart from a
> > slightly less misleading subject, I suggest Hanjun that he passes each
> > patch via get_maintai
On Fri, Jan 16, 2015 at 12:43:49PM +, Jiri Olsa wrote:
> On Fri, Jan 16, 2015 at 01:30:13PM +0100, Jiri Olsa wrote:
> > On Fri, Jan 16, 2015 at 12:22:21PM +0000, Will Deacon wrote:
> > > On Fri, Jan 16, 2015 at 12:12:14PM +, Mark Rutland wrote:
> > > > I ju
Hi Tom,
On Fri, Jan 16, 2015 at 02:45:30PM +, Tom Lendacky wrote:
> I have tested ACPI-enablement patches for the amd-xgbe/amd-xgbe-phy
> drivers that I'm about to submit upstream with the V7 patch series
> on the AMD Seattle server platform. There does not appear to be support
> for the _CCA
On Fri, Jan 16, 2015 at 03:14:13PM +, Arnd Bergmann wrote:
> On Friday 16 January 2015 14:55:45 Will Deacon wrote:
> > On Fri, Jan 16, 2015 at 02:45:30PM +, Tom Lendacky wrote:
> > > I have tested ACPI-enablement patches for the amd-xgbe/amd-xgbe-phy
> > > drive
On Fri, Jan 16, 2015 at 03:40:28PM +, Arnd Bergmann wrote:
> On Friday 16 January 2015 15:33:20 Will Deacon wrote:
> > On Fri, Jan 16, 2015 at 03:14:13PM +, Arnd Bergmann wrote:
> > > On Friday 16 January 2015 14:55:45 Will Deacon wrote:
> > > > On Fri, Ja
On Thu, Jan 15, 2015 at 12:36:04PM +, Suzuki K. Poulose wrote:
> From: "Suzuki K. Poulose"
>
> This patch keeps track of the mixed endian EL0 support across
> the system and provides helper functions to export it. The status
> is a boolean indicating whether all the CPUs on the system support
On Thu, Jan 15, 2015 at 12:36:05PM +, Suzuki K. Poulose wrote:
> From: "Suzuki K. Poulose"
>
> As of now each insn_emulation has a cpu hotplug notifier that
> enables/disables the CPU feature bit for the functionality. This
> patch re-arranges the code, such that there is only one notifier
>
On Fri, Jan 16, 2015 at 12:00:09PM +, Pratyush Anand wrote:
> On Thursday 15 January 2015 10:17 PM, Pratyush Anand wrote:
> > On Tuesday 13 January 2015 11:23 PM, Pratyush Anand wrote:
> >> I will still try to find some way to capture enable_dbg macro path.H
> >
> > I did instrumented debug tap
On Fri, Jan 16, 2015 at 04:32:54PM +, Mark Rutland wrote:
> On Fri, Jan 16, 2015 at 04:07:30PM +0000, Will Deacon wrote:
> > On Thu, Jan 15, 2015 at 12:36:05PM +, Suzuki K. Poulose wrote:
> > > From: "Suzuki K. Poulose"
> > >
> > > As of now
r side of the boot protocol
Catalin Marinas (1):
arm64: partially revert "ARM: 8167/1: extend the reserved memory for
initrd to be page aligned"
Will Deacon (1):
arm64: compat: wire up compat_sys_execveat
On Fri, Jan 16, 2015 at 11:54:45PM +, Kees Cook wrote:
> On Fri, Jan 16, 2015 at 11:57 AM, Kees Cook wrote:
> > On Fri, Jan 16, 2015 at 8:17 AM, Russell King - ARM Linux
> > wrote:
> >> On Sat, Jan 17, 2015 at 01:08:11AM +0900, Roman Peniaev wrote:
> >>> On Sat, Jan 17, 2015 at 12:59 AM, Russ
On Mon, Jan 19, 2015 at 06:10:08AM +, Pratyush Anand wrote:
> On Friday 16 January 2015 09:52 PM, Will Deacon wrote:
> > Perhaps you're not removing the BRK instruction properly, and so you try to
> > single-step a trapping instruction and end up stepping into the exceptio
On Mon, Jan 19, 2015 at 12:43:48PM +, Joerg Roedel wrote:
> On Thu, Jan 15, 2015 at 10:25:11AM +0000, Will Deacon wrote:
> > If you get an Ack from any of Arnd/Joerg/akpm then I'm happy to take it via
> > the arm-smmu pull (along with the patch making use of it).
> >
Hi Joerg,
Thanks for posting this!
On Mon, Jan 26, 2015 at 11:51:32PM +, Joerg Roedel wrote:
> From: Joerg Roedel
>
> This allows to handle domains differently based on their
> type in the future. An IOMMU driver can implement certain
> optimizations for DMA-API domains for example.
>
> Si
nly dma-range is used for PCI and iommu is not
> >> supported. So return error if the device is PCI.
> >>
> >> Cc: Joerg Roedel
> >> Cc: Grant Likely
> >> Cc: Rob Herring
> >> Cc: Bjorn Helgaas
> >> Cc: Will Deacon
> >> Cc: Russ
On Tue, Jan 27, 2015 at 12:08:56AM +, Joerg Roedel wrote:
> From: Joerg Roedel
>
> The default domain will be used (if supported by the iommu
> driver) when the devices in the iommu group are not attached
> to any other domain.
>
> Signed-off-by: Joerg Roedel
> ---
> drivers/iommu/iommu.c
On Tue, Jan 27, 2015 at 12:08:58AM +, Joerg Roedel wrote:
> From: Joerg Roedel
>
> Make use of the default domain and re-attach a device to it
> when it is detached from another domain. Also enforce that a
> device has to be in the default domain before it can be
> attached to a different dom
On Wed, Jan 28, 2015 at 12:23:03PM +, Laurent Pinchart wrote:
> On Wednesday 28 January 2015 11:33:00 Will Deacon wrote:
> > On Mon, Jan 26, 2015 at 06:49:01PM +, Murali Karicheri wrote:
> > > On 01/25/2015 08:32 AM, Laurent Pinchart wrote:
> > >> On Friday 2
nx.c |4 ++--
> drivers/pci/probe.c | 10 +-
> include/linux/pci.h |9 ++---
> 9 files changed, 27 insertions(+), 39 deletions(-)
The arch/arm/ and drivers/pci/host/pci-host-generic.c bits look fine to
me:
Acked-by: Will Deacon
Wi
On Tue, Jan 27, 2015 at 12:08:57AM +, Joerg Roedel wrote:
> From: Joerg Roedel
>
> This patch changes the behavior of the iommu_attach_device
> and iommu_detach_device functions. With this change these
> functions only work on devices that have their own group.
> For all other devices the iom
On Wed, Jan 28, 2015 at 01:15:10PM +, Laurent Pinchart wrote:
> On Wednesday 28 January 2015 12:29:42 Will Deacon wrote:
> > On Wed, Jan 28, 2015 at 12:23:03PM +, Laurent Pinchart wrote:
> > > On Wednesday 28 January 2015 11:33:00 Will Deacon wrote:
> > >>
On Wed, Jan 28, 2015 at 04:13:17PM +, Russell King - ARM Linux wrote:
> On Wed, Jan 28, 2015 at 09:57:18AM -0600, Rob Herring wrote:
> > I'm fine with that, but we just need to have a standard kernel
> > userspace interface in addition to something like
> > /proc/device-tree/bootreason. Perhaps
On Thu, Mar 19, 2015 at 10:12:05AM +, Lorenzo Pieralisi wrote:
> On Thu, Mar 19, 2015 at 03:45:35AM +, Hanjun Guo wrote:
> > >> +if (trigger == ACPI_EDGE_SENSITIVE &&
> > >> +polarity == ACPI_ACTIVE_LOW)
> > >> +irq_type = IRQ_TYPE_EDG
On Thu, Mar 19, 2015 at 10:17:27AM +, Lorenzo Pieralisi wrote:
> On Thu, Mar 19, 2015 at 04:09:33AM +, Hanjun Guo wrote:
> > On 2015/3/19 3:05, Will Deacon wrote:
> > > On Wed, Mar 11, 2015 at 12:39:26PM +, Hanjun Guo wrote:
> > >> This patch set alr
On Thu, Mar 19, 2015 at 04:09:33AM +, Hanjun Guo wrote:
> On 2015/3/19 3:05, Will Deacon wrote:
> > If you can get that in place, I'm not opposed to putting this into
> > linux-next ahead of the firmware summit in San Jose next week. Note that
> > this is not a com
i: refactor ACPI tables init and checks
ARM64: kernel: acpi: honour acpi=force command line parameter
Mark Salter (2):
ARM64: allow late use of early_ioremap
ACPI: fix acpi_os_ioremap for arm64
Tomasz Nowicki (1):
irqchip: Add GICv2 specific ACPI boot support
W
t; arch/arm64/kernel/perf_event.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Acked-by: Will Deacon
Catalin can queue this for 4.2.
Cheers,
Will
> diff --git a/arch/arm64/kernel/perf_event.c b/arch/arm64/kernel/perf_event.c
> index 195991d..7db5c84 100644
> --- a/arch/
Hi all,
Commit 6428c59a97de ("perf tools: Set JOBS based on CPU or processor")
causes weird behaviour on arm/arm64 platforms because we use the "CPU"
prefix for things like:
CPU implementer : 0x41
CPU architecture: 8
CPU variant : 0x0
CPU part: 0xd03
CPU revision: 0
in /proc/cpui
: Arnaldo Carvalho de Melo
Signed-off-by: Will Deacon
---
tools/perf/builtin-kmem.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/tools/perf/builtin-kmem.c b/tools/perf/builtin-kmem.c
index 63ea01349b6e..a1915b430044 100644
--- a/tools/perf/builtin-kmem.c
+++ b/tools/perf
On Thu, Apr 23, 2015 at 12:29:16PM +0100, Will Deacon wrote:
> Hi all,
>
> Commit 6428c59a97de ("perf tools: Set JOBS based on CPU or processor")
> causes weird behaviour on arm/arm64 platforms because we use the "CPU"
> prefix for things like:
>
> CPU
On Fri, Apr 24, 2015 at 05:02:17PM +0100, Arnaldo Carvalho de Melo wrote:
> Em Fri, Apr 24, 2015 at 09:59:18AM +0100, Javi Merino escreveu:
> > On Fri, Apr 24, 2015 at 03:02:18AM +0100, Namhyung Kim wrote:
> > > Hi Arnaldo,
> > >
> > > I've set up some docker containers for build test, and found a
On Fri, Apr 24, 2015 at 05:10:58PM +0100, Arnaldo Carvalho de Melo wrote:
> Em Thu, Apr 23, 2015 at 08:16:15AM -0600, David Ahern escreveu:
> > On 4/23/15 8:04 AM, Will Deacon wrote:
> > >+++ b/tools/perf/Makefile
> > >@@ -24,7 +24,7 @@ unexport MAKEFLAGS
> > >
n
> Reported-by: Thierry Reding
> Signed-off-by: Richard Weinberger
> ---
> Will be applied on top of my execdomain removal series.
Sounds good, feel free to add my ack:
Acked-by: Will Deacon
Will
> Thanks,
> //richard
> ---
> arch/arm64/kernel/signal.c | 1 -
> 1 f
On Wed, Apr 15, 2015 at 11:44:06AM +0100, Suzuki K. Poulose wrote:
> On 09/04/15 15:57, Mark Salter wrote:
> > Currently in validate_group(), there is a static initializer
> > for fake_pmu.used_mask which is based on CPU_BITS_NONE but
> > the used_mask array size is based on CCI_PMU_MAX_HW_EVENTS.
d
Steve Capper (1):
arm64: Adjust EFI libstub object include logic
Suzuki K. Poulose (1):
arm64: perf: reject groups spanning multiple HW PMUs
Will Deacon (8):
arm64: proc: remove unused cpu_get_pgd macro
Merge branch 'aarch64/kvm-bounce-page' into aarch64/for-
rrently are.
So, for the arm-smmu patch and the core IOMMU changes:
Acked-by: Will Deacon
Hopefully this doesn't conflict too badly with my outstanding arm-smmu
pull requests to you, but do shout if you have any trouble.
Will
--
To unsubscribe from this list: send the line "un
.
Cc: Oleg Nesterov
Cc: "Paul E. McKenney"
Cc: Peter Zijlstra
Signed-off-by: Will Deacon
---
Could somebody pick this up please? I guess I could route it via the arm64
tree with an Ack, but I'd rather it went through Paul or -tip.
Documentation/memory-barriers.txt | 7 +++---
On Tue, Mar 31, 2015 at 12:46:00AM +0100, Joe Perches wrote:
> Use the normal return values for bool functions
>
> Signed-off-by: Joe Perches
> ---
> arch/arm64/include/asm/dma-mapping.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm64/include/asm/dma-mapping.
Hi Daniel,
On Wed, Mar 04, 2015 at 01:25:45PM +, Daniel Thompson wrote:
> Some ARM platforms mux the PMU interrupt of every core into a single
> SPI. On such platforms if the PMU of any core except 0 raises an interrupt
> then it cannot be serviced and eventually, if you are lucky, the spuriou
On Wed, Apr 01, 2015 at 04:50:55PM +0100, Oleg Nesterov wrote:
> On 04/01, Paul E. McKenney wrote:
> >
> > If Will agrees, like the following?
>
> Looks good to me, thanks ;)
Same here, thanks for sorting that out Paul.
Will
--
To unsubscribe from this list: send the line "unsubscribe linux-kern
On Fri, Apr 24, 2015 at 10:43:20PM +0100, Nathan Lynch wrote:
> The 32-bit ARM VDSO needs to know whether a generic timer is present
> and whether it is suitable for use by user space. The VDSO
> initialization code currently duplicates some of the logic from the
> driver to make this determinatio
On Thu, Mar 26, 2015 at 12:10:55AM +, Stephen Rothwell wrote:
> Hi Will,
Hi again Stephen,
> On Wed, 25 Mar 2015 17:20:03 +0000 Will Deacon wrote:
> >
> > We've got a series of patches introducing ACPI support for arm64 that
> > are tentatively targetting the 4
Hello,
On Tue, Apr 28, 2015 at 02:20:48PM +0100, Hou Pengyang wrote:
> For ARM64, when tracing with tracepoint events, the IP and cpsr are set
> to 0, preventing the perf code parsing the callchain and resolving the
> symbols correctly.
>
> ./perf record -e sched:sched_switch -g --call-graph dwa
On Tue, Apr 28, 2015 at 03:58:21AM +0100, William Cohen wrote:
> Hi All,
Hi Will,
> I have been experimenting with the patches for arm64 kprobes support.
> On occasion the kernel gets stuck in a loop printing output:
>
> Unexpected kernel single-step exception at EL1
>
> This message by itself
On Thu, Apr 30, 2015 at 02:50:05AM +0100, Hou Pengyang wrote:
> On 2015/4/29 18:12, Will Deacon wrote:
> > On Tue, Apr 28, 2015 at 02:20:48PM +0100, Hou Pengyang wrote:
> >> diff --git a/arch/arm64/include/asm/perf_event.h
> >> b/arch/arm64/include/asm/perf_event.h
Hi Arnd,
On Thu, Apr 30, 2015 at 09:23:59AM +0100, Arnd Bergmann wrote:
> On Wednesday 29 April 2015 16:53:10 Suravee Suthikulpanit wrote:
> > As for the case where _CCA=0, I think the ACPI driver should essentially
> > communicate the information as HW is non-coherent as described in the
> > sp
On Thu, Apr 30, 2015 at 11:47:46AM +0100, Arnd Bergmann wrote:
> On Thursday 30 April 2015 11:41:02 Will Deacon wrote:
> >- 0x0: The device is not coherent. Therefore:
> > * Cache maintenance is required for memory shared with the
> >device that is mapped o
On Thu, Apr 30, 2015 at 12:24:12PM +0100, Arnd Bergmann wrote:
> On Thursday 30 April 2015 12:07:18 Will Deacon wrote:
> > So for the CPU caches we'd do the usual clean to push dirty lines to the
> > device
> > and (clean+)invalidate before reading data from the device.
On Thu, Apr 30, 2015 at 02:03:00PM +0100, Arnd Bergmann wrote:
> On Thursday 30 April 2015 12:46:15 Will Deacon wrote:
> > On Thu, Apr 30, 2015 at 12:24:12PM +0100, Arnd Bergmann wrote:
> > > In particular, there are two common models that we support in Linux:
> > >
On Thu, Apr 30, 2015 at 02:47:13PM +0100, Hanjun Guo wrote:
> On 2015年04月29日 22:42, Catalin Marinas wrote:
> > On Wed, Apr 29, 2015 at 09:31:03AM -0500, Suravee Suthikulpanit wrote:
> >> On 04/29/2015 09:04 AM, Catalin Marinas wrote:
> >>> On Wed, Apr 29, 2015 at 08:44:08AM -0500, Suravee Suthikulp
Hi Andrey,
On Mon, Apr 20, 2015 at 04:45:53PM +0100, Andrey Ryabinin wrote:
> commit 47933ad41a86 ("arch: Introduce smp_load_acquire(),
> smp_store_release()")
> allowed only 4- and 8-byte smp_load_acquire, smp_store_release.
> So 1- and 2-byte cases weren't implemented in arm64.
> Later commit 5
On Mon, Apr 20, 2015 at 05:08:37PM +0100, Linus Torvalds wrote:
> On Mon, Apr 20, 2015 at 8:45 AM, Andrey Ryabinin
> wrote:
> >
> > Commit 8053871d0f7f ("smp: Fix smp_call_function_single_async() locking")
> > started to use smp_load_acquire() to load 2-bytes csd->flags.
> > That crashes arm64 ke
On Thu, Apr 09, 2015 at 04:36:29PM +0100, Mark Rutland wrote:
> On Thu, Apr 09, 2015 at 03:57:05PM +0100, Mark Salter wrote:
> > Currently in validate_group(), there is a static initializer
> > for fake_pmu.used_mask which is based on CPU_BITS_NONE but
> > the used_mask array size is based on CCI_P
On Fri, Jul 13, 2012 at 08:59:39AM +0100, Shawn Guo wrote:
> > diff --git a/arch/arm/kernel/smp.c b/arch/arm/kernel/smp.c
> > index 8f46446..7babc3f 100644
> > --- a/arch/arm/kernel/smp.c
> > +++ b/arch/arm/kernel/smp.c
> > @@ -590,7 +590,8 @@ void smp_send_stop(void)
> >
> > cpumask_copy(&ma
On Wed, Jul 18, 2012 at 06:53:34AM +0100, Jon Masters wrote:
> On 07/06/2012 05:05 PM, Catalin Marinas wrote:
>
> > The reason for this patch is that we want SHMLBA to be 64K on AArch64
>
> Presumably this is to obviate differences between 64K or 4K pages?
Right, we don't have D-side aliasing wi
On Wed, Jul 18, 2012 at 07:57:47AM +0100, Jon Masters wrote:
> On 07/06/2012 05:05 PM, Catalin Marinas wrote:
>
> > +- CPU mode
> > + All forms of interrupts must be masked in PSTATE.DAIF (Debug, SError,
> > + IRQ and FIQ).
> > + The CPU must be in either EL2 (RECOMMENDED) or non-secure EL1.
>
file if it exists (which in
turn causes linux/kvm_para.h to be exported), we can just remove the
unconditional header export.
Cc: Arnd Bergmann
Cc: Avi Kivity
Cc: Geert Uytterhoeven
Signed-off-by: Will Deacon
---
I'm not sure what specific problem the original commit was fixing, so we
may
Hi Arnd,
On Wed, Jul 18, 2012 at 12:58:06PM +0100, Arnd Bergmann wrote:
> On Wednesday 18 July 2012, Will Deacon wrote:
> > This reverts commit 56457f38f212344fb38b250cfa7e7311c065022f.
> >
> > For architectures without asm/kvm_para.h, asm-generic/Kbuild
> > uncondit
Hi Geert,
On Wed, Jul 18, 2012 at 01:33:01PM +0100, Geert Uytterhoeven wrote:
> > On Wednesday 18 July 2012, Will Deacon wrote:
> >
> >> I'm not sure what specific problem the original commit was fixing, so we
> >> may need to solve this another way if ther
On Tue, May 26, 2015 at 05:27:33PM +0100, Fu Wei wrote:
> On 26 May 2015 at 23:36, Guenter Roeck wrote:
> > On Tue, May 26, 2015 at 04:18:42PM +0100, Will Deacon wrote:
> >> Sure, the device it describes may only ever exist on ARM systems, but by
> >> that logic then
ut for compat mode on ARM64.
>
> Signed-off-by: André Hentschel
> Cc: Will Deacon
> Cc: Catalin Marinas
>
> ---
> This patch is against Linux 4.1-rc1 (b787f68c36d49bb1d9236f403813641efa74a031)
>
> v2: Trying to address suggestions by Will Deacon
>
> @Will Dea
1201 - 1300 of 6344 matches
Mail list logo
