ready broken and, as such,
won't be further broken if the field is removed.
Cc: Nicolas Pitre
Signed-off-by: Will Deacon
---
arch/arm/kernel/setup.c | 9 -
arch/arm/kernel/smp.c | 13 ++---
2 files changed, 2 insertions(+), 20 deletions(-)
diff --git a/arch/arm/kernel/setu
tten the bullet
and removed the line altogether.
In the meantime, I've only had one complaint this month about BogoMIPs
being wrong, so perhaps the initial posting served some purpose without
even being merged!
Comments welcome,
Will
Will Deacon (2):
ARM: delay: don't bother re
On Thu, May 30, 2013 at 02:41:42AM +0100, Wang, Yalin wrote:
> Hi Will,
Hello,
> Have you received the log files?
Yep, and you seem to be completely correct: CPU0 ages the page from which
CPU1 just executed a system call, so we explode trying to load the swi
instruction in order to retrieve the
On Thu, May 30, 2013 at 09:15:26AM +0100, Po-Yu Chuang wrote:
> On Wed, May 29, 2013 at 5:34 PM, Po-Yu Chuang
> wrote:
> > Hi Will,
> >
> > On Wed, May 29, 2013 at 4:54 PM, Will Deacon wrote:
> >> On Wed, May 29, 2013 at 03:14:58AM +0100, Po-Yu Chuang wrote:
On Thu, May 30, 2013 at 10:09:49AM +0100, Will Deacon wrote:
> On Thu, May 30, 2013 at 02:41:42AM +0100, Wang, Yalin wrote:
> > If you have some patch for this issue,
> > I can do the test for it .
>
> I'll have a look at cooking something which uses an exception tabl
On Wed, May 22, 2013 at 07:03:32PM +0100, Will Deacon wrote:
> As is done for other architectures, sort the exception table at
> build-time rather than during boot.
>
> Since sortextable appears to be a standalone C program relying on the
> host elf.h to provide EM_AARCH64, I&
On Fri, May 31, 2013 at 04:54:56AM +0100, Nicolas Pitre wrote:
> On Thu, 30 May 2013, Will Deacon wrote:
>
> > On Thu, May 30, 2013 at 10:09:49AM +0100, Will Deacon wrote:
> > > On Thu, May 30, 2013 at 02:41:42AM +0100, Wang, Yalin wrote:
> > > > If you have som
On Fri, May 31, 2013 at 03:56:31AM +0100, Wang, Yalin wrote:
> Hi Will,
>
> Thanks for your patch ,
>
> But I found I don't have ct_user_exit macro
> In my arch/arm/kernel/entry-common.S
>
> My kernel version is 3.4.0
Well things have moved on this since then (we're approaching 3.10, so yo
On Fri, May 31, 2013 at 12:02:49PM +0100, Wang, Yalin wrote:
> Hi Will,
>
> I have merge your code ,
> But there is a different ,
>
> +
> + ct_user_exit
I thought you didn't have ct_user_exit? In which case, just delete this
line.
> +#ifdef CONFIG_ALIGNMENT_TRAP
> + ldr ip, __
On Fri, May 31, 2013 at 05:48:56PM +0100, Nicolas Pitre wrote:
> On Fri, 31 May 2013, Will Deacon wrote:
>
> > Hard to tell without context. You can take a look at my git tree if you
> > like (I fixed it up based on Nico's comment):
> >
> >
> > htt
On Mon, Jun 03, 2013 at 06:25:26AM +0100, Wang, Yalin wrote:
> Hi Will,
>
> I have a question about this patch .
>
> If the user space is thumb mode,
> The PC should be rewind by 2 bytes,
> So the fix_up code should be
>
> Sub lr, lr, #2 .
>
>
> Am I right ?
No, because we don't have OABI-c
Hi Russell,
On Mon, Jun 03, 2013 at 11:18:09AM +0100, Russell King - ARM Linux wrote:
> On Thu, May 30, 2013 at 12:41:12PM +0100, Will Deacon wrote:
> > +#if defined(CONFIG_OABI_COMPAT) || !defined(CONFIG_AEABI)
> > + /*
> > +* We may have faulted trying to load the S
On Mon, Jun 03, 2013 at 11:45:34AM +0100, Russell King - ARM Linux wrote:
> On Mon, Jun 03, 2013 at 11:27:23AM +0100, Will Deacon wrote:
> > On Mon, Jun 03, 2013 at 11:18:09AM +0100, Russell King - ARM Linux wrote:
> > > On Thu, May 30, 2013 at 12:41:12PM +0100, Will Deacon w
On Thu, Jun 20, 2013 at 07:54:21PM +0100, Nicolas Pitre wrote:
> On Thu, 20 Jun 2013, Will Deacon wrote:
>
> > Hi all,
> >
> > This is version two of the patches I originally posted here:
> >
> > http://lists.infradead.org/pipermail/linux-arm-kernel/20
On Sat, Jun 22, 2013 at 06:54:14AM +0100, Chen Gang wrote:
>
> If 'COMPAT' not defined, aarch32_break_handler() cannot pass compiling,
> so need add '#ifdef' for it just like the header file has done.
>
> The related make:
>
> make ARCH=arm64 randconfig
> make ARCH=arm64 menuconfig
> make
dler(struct pt_regs *regs);
> -#else
> -static int aarch32_break_handler(struct pt_regs *regs)
> -{
> - return -EFAULT;
> -}
> -#endif
Code looks fine to me:
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/
Hi Christopher,
On Mon, Jun 24, 2013 at 02:26:45PM +0100, Christopher Covington wrote:
> Using the long-descriptor translation table format changes
> the layout of the CONTEXTIDR register.
>
> Signed-off-by: Christopher Covington
> ---
> arch/arm/mm/context.c | 37 +++---
On Mon, Jun 24, 2013 at 03:39:09PM +0100, Christopher Covington wrote:
> Hi Will,
>
> On 06/24/2013 10:04 AM, Will Deacon wrote:
> [...]
>
> > What's the advantage of this approach, other than you get an extra byte's
> > worth of PID?
>
> In my view
On Sat, Jun 08, 2013 at 05:37:30AM +0100, Chen Gang wrote:
> Hello Maintainers:
>
> Please help check it, when you have time.
[...]
> >> Under arm64, we will calibrate the delay loop statically using a known
> >> timer frequency, so delete read_current_timer(), or it will cause
> >> compiling is
On Mon, Jun 24, 2013 at 04:15:06PM +0100, Christopher Covington wrote:
> On 06/24/2013 10:53 AM, Will Deacon wrote:
> > On Mon, Jun 24, 2013 at 03:39:09PM +0100, Christopher Covington wrote:
> >> Hi Will,
> >>
> >> On 06/24/2013 10:04 AM, Will Deacon wro
[adding the ARM list -- please try and remember to do that in future]
On Wed, Jun 26, 2013 at 03:41:40AM +0100, Wang, Yalin wrote:
> Hi Will,
Hello,
> I have a question about arm pagetable setting in Linux .
>
> From armV6, there is TTBR0 and TTBR1 translation base address registers in
>
On Mon, Mar 25, 2013 at 09:11:00AM +, Santosh Shilimkar wrote:
> Will,
Hi Santosh,
> Are you going to send the patch for 3.9-rcx ? As I said before without the
> patch OMAP4 CPUILDE is unusable because of that debug noise and hence it
> will be good to get that patch in
It's in Russell's tre
On Mon, Mar 18, 2013 at 04:11:15AM +, Michael Cree wrote:
> On 18/03/2013, at 10:48 AM, Will Deacon wrote:
> > Due to all of the goodness being packed into today's kernels, the
> > resulting image isn't as slim as it once was.
> >
> > In light of this,
Hi Stefano,
On Tue, Mar 26, 2013 at 02:41:15PM +, Stefano Stabellini wrote:
> Check for the presence of PSCI before setting smp_ops, use PSCI if it is
> available.
>
> This is useful because at least when running on Xen it's possible to have a
> PSCI node for example on a Versatile Express or
On Tue, Mar 26, 2013 at 03:25:55PM +, Stefano Stabellini wrote:
> On Tue, 26 Mar 2013, Will Deacon wrote:
> > On Tue, Mar 26, 2013 at 02:41:15PM +, Stefano Stabellini wrote:
> > > +struct smp_operations __initdata psci_smp_ops = {
> > > + .smp_init_cpus
Hi Jed,
On Sat, Jul 13, 2013 at 04:17:14AM +0100, Jed Davis wrote:
> We need a perf_arch_fetch_caller_regs for at least some software events
> to be able to get a callchain; even user stacks won't work without
> at least the CPSR bits for non-user-mode (see perf_callchain). In
> particular, profi
Hi Jed,
On Sat, Jul 13, 2013 at 04:18:20AM +0100, Jed Davis wrote:
> There is currently some inconsistency about the "frame pointer" on ARM.
> r11 is the register with assemblers recognize and disassemblers often
> print as "fp", and which is sufficient for stack unwinding when using
> the APCS fr
On Mon, Jul 29, 2013 at 10:46:06AM +0100, Vincent Guittot wrote:
> On 27 July 2013 12:42, Hanjun Guo wrote:
> > Power aware scheduling needs the cpu topology information to improve the
> > cpu scheduler decision making.
>
> It's not only power aware scheduling. The scheduler already uses
> topolo
On Tue, Jul 30, 2013 at 10:38:53AM +0100, Jean-Francois Moine wrote:
> BTW, kernels compiled with gcc-4.8 don't work.
Erm. Can you elaborate please? There was an issue where SLUB would get
miscompiled with 4.8 due to some per-cpu variable reordering across
barrier(), but I fixed that for ARM in 3.
[Adding Gregory, as this is a Marvell CPU]
On Wed, Jul 31, 2013 at 10:03:09AM +0100, Jean-Francois Moine wrote:
> I compiled the 3.11.0-rc3 with gcc-4.8.1 and I still get oops in ext3
> (no problem when compiled with gcc-4.6). Here is the dmesg.
There were some recent errata fixes from Gregory an
Hi Julia,
On Mon, Aug 19, 2013 at 12:20:37PM +0100, Julia Lawall wrote:
> From: Julia Lawall
>
> Use devm_ioremap_resource instead of devm_request_and_ioremap.
>
> This was partly done using the semantic patch
> scripts/coccinelle/api/devm_ioremap_resource.cocci
>
> The error-handling code on
gt; the user to detect this event stream feature.
>
> Cc: Catalin Marinas
> Reviewed-by: Lorenzo Pieralisi
> Signed-off-by: Will Deacon
> [sudeep: moving ARM/ARM64 changes into separate patches]
> Signed-off-by: Sudeep KarkadaNagesha
> ---
> arch/arm64/include/asm/arch_
Hi Mark,
On Sun, Aug 18, 2013 at 05:22:50PM +0100, Mark Salter wrote:
> The arm64 port doesn't provide a screen_info struct for console support
> which leads to a build failure with some configurations:
>
> drivers/video/console/vgacon.c:820: undefined reference to `screen_info'
>
> This patch
On Tue, Aug 20, 2013 at 03:52:00PM +0100, Ezequiel Garcia wrote:
> On Tue, Aug 20, 2013 at 09:32:13AM -0500, Matt Sealey wrote:
> > On Mon, Aug 19, 2013 at 11:59 AM, Ezequiel Garcia
> > wrote:
> > > On Mon, Aug 12, 2013 at 07:29:42PM +0100, Will Deacon wrote:
> >
On Tue, Aug 20, 2013 at 03:27:33PM +0100, Sudeep KarkadaNagesha wrote:
> On 20/08/13 14:27, Will Deacon wrote:
> > On Tue, Aug 13, 2013 at 06:29:42PM +0100, Sudeep KarkadaNagesha wrote:
> >> diff --git a/arch/arm64/include/asm/hwcap.h
> >> b/arch/arm64/include/asm
me()->nodename from nlmclnt_setlockargs"), so this patch attempts
something similar for 9pfs.
Cc: Eric Van Hensbergen
Cc: Ron Minnich
Cc: Latchesar Ionkov
Cc: Trond Myklebust
Signed-off-by: Will Deacon
---
fs/9p/vfs_file.c| 4 ++--
include/net/9p/client.h | 5 +
net/9p/cl
stream feature.
>
> Cc: Catalin Marinas
> Reviewed-by: Lorenzo Pieralisi
> Signed-off-by: Will Deacon
> [sudeep: moving ARM/ARM64 changes into separate patches]
> Signed-off-by: Sudeep KarkadaNagesha
> ---
> arch/arm64/include/asm/arch_timer.h | 15 +--
>
On Tue, Aug 06, 2013 at 12:19:32PM +0100, Mark Rutland wrote:
> On Mon, Aug 05, 2013 at 10:17:37PM +0100, Vince Weaver wrote:
> > It looks like in validate_event() we do
> >
> > struct arm_pmu *armpmu = to_arm_pmu(event->pmu);
> > ...
> > return armpmu->get_event_idx(hw_eve
On Tue, Aug 06, 2013 at 02:08:15PM +0100, Mark Rutland wrote:
> On Tue, Aug 06, 2013 at 12:59:21PM +0100, Will Deacon wrote:
> > But we already check `event->pmu != leader_pmu' in validate_event, so we
> > shouldn't get anywhere nearer calling get_event_idx in the case
On Wed, Aug 07, 2013 at 09:14:55PM +0100, Vince Weaver wrote:
> Hello
Hi Vince,
> I don't have time to come up with a test case right now, but I've
> applied the patch to fix the oops from two days ago, and re-ran
> my perf_fuzzer tool and it immediately came up with another issue on ARM.
> This
On Wed, Aug 07, 2013 at 04:30:33PM +0100, Vince Weaver wrote:
> On Wed, 7 Aug 2013, Vince Weaver wrote:
> > On Wed, 7 Aug 2013, Will Deacon wrote:
> > > diff --git a/arch/arm/kernel/perf_event.c b/arch/arm/kernel/perf_event.c
> > > index d9f5cd4..0500f10b 100644
ig];
> + int mapping;
> +
> + if (config >= PERF_COUNT_HW_MAX)
> + return -ENOENT;
> +
> + mapping = (*event_map)[config];
Well spotted, thanks. If you make that return -EINVAL instead of -ENOENT (to
match what we do for cache events) then:
Acked-by: Will De
On Thu, Aug 08, 2013 at 03:53:31AM +0100, Vince Weaver wrote:
> On Wed, 7 Aug 2013, Vince Weaver wrote:
> > On Wed, 7 Aug 2013, Stephen Boyd wrote:
> > > diff --git a/arch/arm/kernel/perf_event.c b/arch/arm/kernel/perf_event.c
> > > index d9f5cd4..21f7790 100644
> > > --- a/arch/arm/kernel/perf_eve
On Thu, Aug 08, 2013 at 10:38:10PM +0100, Tomasz Figa wrote:
> On Thursday 08 of August 2013 08:09:49 Rob Herring wrote:
> > On Thu, Aug 1, 2013 at 8:05 AM, Cho KyongHo
> wrote:
> > > Should this align with ARM System MMU bindings?
> > > System MMU in Exynos SoC is different from ARM System MMU.
me would be very fiddly to extend to
64-bit values on 32-bit architectures without cheap atomic doubleword
accesses.
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 majordom
Hello Jed,
Thanks for the reply.
On Sat, Jul 20, 2013 at 05:46:55AM +0100, Jed Davis wrote:
> On Mon, Jul 15, 2013 at 02:54:20PM +0100, Will Deacon wrote:
> > On Sat, Jul 13, 2013 at 04:18:20AM +0100, Jed Davis wrote:
> [...]
> > > Effects of this are probably limite
On Sat, Jul 20, 2013 at 04:43:21AM +0100, Jed Davis wrote:
> On Mon, Jul 15, 2013 at 02:53:42PM +0100, Will Deacon wrote:
> > > + "mov %[_pc], r15\n\t" \
> > > +
On Tue, Jul 23, 2013 at 11:23:34AM +0100, Catalin Marinas wrote:
> On Mon, Jul 22, 2013 at 12:21:20PM +0100, Sudeep KarkadaNagesha wrote:
> > From: Will Deacon
> >
> > The ARM architected timer can generate events (used for waking up
> > CPUs executing the wfe
On Sat, Aug 10, 2013 at 01:43:00PM +0100, Ezequiel Garcia wrote:
> Some SoC have MMIO regions that are shared across orthogonal
> subsystems. This commit implements a possible solution for the
> thread-safe access of such regions through a spinlock-protected API
> with clear-set semantics.
>
> Con
Hello Soren,
On Fri, Mar 01, 2013 at 06:51:26PM +, Soren Brinkmann wrote:
> Enable the 'dynamic clock stop' and 'standby mode' features in the
> l2x0 disable path.
>
> Signed-off-by: Soren Brinkmann
> ---
> Hi,
>
> we are currently implementing a suspend to RAM like low power mode for
> Zyn
_init().
> This is often because armpmu_register lacks a __init
> annotation or the annotation of armpmu_init is wrong.
>
> Just drop the __init marking on armpmu_init() because
> armpmu_register() no longer has an __init marking.
>
> Signed-off-by: Stephen Boyd
Cheers Stephen
Hi guys,
On Mon, Mar 04, 2013 at 02:45:33AM +, Rob Herring wrote:
> On 02/20/2013 05:48 AM, Ian Campbell wrote:
> > On ARM we want these to be the same size on 32- and 64-bit.
> >
> > This is an ABI change on ARM. X86 does not change.
> >
> > Signed-off-by: Ian Campbell
> > Cc: Jan Beulich
On Tue, Mar 05, 2013 at 06:55:46AM +, Rob Herring wrote:
> > I also can't immediately see why GCC would allocate oldval to an odd base
> > register. Can you share your .config please?
> >
>
> Here's a config:
[...]
Cheers Rob, that was enough to reproduce for me. The problem is likely that
C
Hi Stephen, Stepan,
On Mon, Mar 04, 2013 at 11:21:39PM +, Stephen Boyd wrote:
> From: Stepan Moskovchenko
>
> Add processor info for the Qualcomm, Inc. Krait family of
> processors, to use the generic ARMv7 initialisation
> procedure but explicitly enable the IDIV hardware
> capability flag.
On Tue, Mar 05, 2013 at 10:03:10PM +, Stephen Boyd wrote:
> On 03/05/13 00:34, Will Deacon wrote:
> > I was looking at this the other day and wondered whether we could set
> > HWCAP_IDIV in __v7_setup, depending on ID_ISAR0[27:24]. I can't immediately
> > think why th
Commit ec2212088c42 ("Disintegrate asm/system.h for Alpha") removed the
system.h include from boot/head.S, which puts the PAL_* asm constants
out of scope.
Include so we can get building again.
Cc: David Rusling
Cc: David Howells
Signed-off-by: Will Deacon
---
arch/alpha/boot/
Hi Nico,
On Wed, May 15, 2013 at 12:56:51AM +0100, Nicolas Pitre wrote:
> On Tue, 14 May 2013, Rob Herring wrote:
> > On Tue, May 14, 2013 at 2:54 PM, Nicolas Pitre wrote:
> > > Waitaminute... Didn't you just claim this would be an ABI break?
> > >
> > > So if no application can be found, where i
Hello,
I've been observing a regression in the dmatest module with 3.10-rc1. It
manifests as either:
- a spurious timeout on one or more of the channel threads
- a complete kernel lockup (loss of console)
- a panic (see below, noting that the callback [dmatest_callback] is
dereferencing a N
On Wed, May 15, 2013 at 04:28:03PM +0100, Will Deacon wrote:
> I've been observing a regression in the dmatest module with 3.10-rc1. It
> manifests as either:
>
> - a spurious timeout on one or more of the channel threads
> - a complete kernel lockup (loss of console)
>
ges
> if we are the case.
>
> Cc: Christoph Lameter
> Cc: Catalin Marinas
> Cc: Will Deacon
> Cc: Arnd Bergmann
> Cc: Tony Lindgren
> Cc: Ben Hutchings
> Cc: Andrew Morton
> Reported-by: Yasuaki Ishimatsu
> Signed-off-by: Lin Feng
> ---
> arch/arm
On Mon, Apr 08, 2013 at 03:42:24PM +0100, Christopher Covington wrote:
> On 04/03/2013 02:04 PM, Will Deacon wrote:
> > Hi Christopher,
> >
> > On Wed, Apr 03, 2013 at 07:01:01PM +0100, Christopher Covington wrote:
> >> For accurate accounting call contextidr_threa
On Tue, Apr 09, 2013 at 01:33:34PM +0100, Christopher Covington wrote:
> For accurate accounting pass contextidr_thread_switch the prev
> task pointer, since cpu_switch_to has at that point changed the
> the stack pointer.
>
> Signed-off-by: Christopher Covington
Thanks Christopher -- I assume t
Hi Christian,
Thanks for CC'ing me.
On Tue, Apr 30, 2013 at 07:38:09PM +0100, Christian Daudt wrote:
> Rev A2 SoCs have an unorthodox memory re-mapping and this needs
> to be reflected in the cache operations.
> This patch adds new outer cache functions for the l2x0 driver
> to support this SoC r
On Wed, May 01, 2013 at 07:53:49AM +0100, Anup Patel wrote:
> On Wed, May 1, 2013 at 7:37 AM, Rusty Russell wrote:
> > Alexander Graf writes:
> >> There are not device specific registers in
> >> virtio-console. Virtio-console lives behind a virtio bus which doesn't
> >> know what these registers
Hi Stefano,
On Thu, May 02, 2013 at 06:12:12PM +0100, Stefano Stabellini wrote:
> ping
Is this a ping to have this pulled into Russell's tree? If so, might be
worth sending a pull request to linux+p...@arm.linux.org.uk.
Has this been in -next?
Will
--
To unsubscribe from this list: send the lin
Hi Christian,
On Fri, May 03, 2013 at 01:57:33AM +0100, Christian Daudt wrote:
> Rev A2 SoCs have an unorthodox memory re-mapping and this needs
> to be reflected in the cache operations.
> This patch adds new outer cache functions for the l2x0 driver
> to support this SoC revision. It also adds a
On Fri, May 03, 2013 at 06:13:42PM +0100, Christian Daudt wrote:
> On 13-05-03 01:51 AM, Will Deacon wrote:
> > On Fri, May 03, 2013 at 01:57:33AM +0100, Christian Daudt wrote:
> >> Rev A2 SoCs have an unorthodox memory re-mapping and this needs
> >> to be reflec
e which is parsing that stuff, so
instead replace it with a dummy value that can be chosen in the Kconfig.
Signed-off-by: Will Deacon
---
arch/arm/Kconfig.debug | 48
arch/arm/kernel/setup.c | 16
arch/arm/kernel/sm
ret them as anything meaningful.
Comments welcome,
Will
Will Deacon (2):
ARM: delay: print dummy values for bogomips
init: calibrate: don't print out bogomips value on boot
arch/arm/Kconfig.debug | 48
arch/arm/kernel/setup.c | 16 +
BogoMIPs is a confusing concept, so allow architectures to print it only
if they find it worthwhile. The delay calibration code should stick to
lpj and avoid trying to draw any correlation with BogoMIPs, which may be
a fixed, bogus (geddit?) value.
Signed-off-by: Will Deacon
---
init
ation
to use logical operations rather than load-address instructions for
generating immediates.
Cc: Richard Henderson
Cc: Ivan Kokshaysky
Cc: Matt Turner
Signed-off-by: Will Deacon
---
arch/alpha/include/asm/spinlock.h | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --
Hi Al, Matt,
On Mon, May 06, 2013 at 09:53:30PM +0100, Al Viro wrote:
> On Mon, May 06, 2013 at 01:19:51PM -0700, Matt Turner wrote:
>
> > I'm not sure of the interpretation that LDA counts as a memory access.
> >
> > The manual says it's Ra <- Rbv + SEXT(disp).
> >
> > It's not touching memory
On Mon, May 06, 2013 at 10:12:38PM +0100, Will Deacon wrote:
> The other (hopefully also wrong) worry that I had was when the manual
> states that:
>
> `If the virtual and physical addresses for a LDx_L and STx_C sequence are
> not within the same naturally aligned 16-byte sect
On Mon, May 06, 2013 at 07:01:23PM +0100, Christopher Covington wrote:
> Hi Will,
>
> On 05/03/2013 01:35 PM, Will Deacon wrote:
> > Hi all,
> >
> > This small patch set may look a little over a month late, but there is a
> > serious reason for posting it.
&g
>
> Signed-off-by: André Hentschel
> Signed-off-by: Will Deacon
> Signed-off-by: Jonathan Austin
[...]
> diff --git a/arch/arm/include/asm/tls.h b/arch/arm/include/asm/tls.h
> index 73409e6..22756ab 100644
> --- a/arch/arm/include/asm/tls.h
> +++ b/arch/arm/inc
Hello Christopher,
On Tue, May 07, 2013 at 04:48:26PM +0100, Christopher Covington wrote:
> On 05/07/2013 05:08 AM, Will Deacon wrote:
> > That seems like a lot of effort in order to preserve something that isn't
> > even meaningful. We might be better just zeroing the v
,7 +37,7 @@ void __delay(unsigned long cycles)
> }
> EXPORT_SYMBOL(__delay);
>
> -inline void __const_udelay(unsigned long xloops)
> +void __const_udelay(unsigned long xloops)
> {
> unsigned long long loops;
Acked-by: Will Deacon
Will
--
To unsubscribe from this list: se
Hi Andrew,
On Tue, Apr 23, 2013 at 11:42:22PM +0100, André Hentschel wrote:
> Am 23.04.2013 11:15, schrieb Will Deacon:
> > You could introduce `get' tls functions, which don't do anything for CPUs
> > without the relevant registers.
>
> Before i have ano
On Tue, Apr 23, 2013 at 04:18:46PM +0100, Jacob Shin wrote:
> On Tue, Apr 23, 2013 at 04:02:40PM +0100, Will Deacon wrote:
> > On Tue, Apr 23, 2013 at 03:40:57PM +0100, Jacob Shin wrote:
> > > > perf stat -e mem:0x1000/0xf:w a.out
> >
> > Are you saying that t
On Wed, Apr 24, 2013 at 11:20:32AM +0100, Chen Gang wrote:
>
> For compiling with allmodconfig, need vga.h file, so generate it which
> just only include the asm-generic one.
>
> It is firstly used by drivers/gpu/drm/drm_irq.c.
>
> The related error:
> include/video/vga.h:22:21: fatal error: asm
; 0 on failure
> + *
> + */
Can you move these comments into psci-smp.c please? They're really specific
to the implementation there, and if we put them in a header we're lying to
ourselves about the parameters actually described by the PSCI specification.
With that change:
Acked
On Wed, Apr 24, 2013 at 07:40:19PM +0100, Stefano Stabellini wrote:
> From: Jon Medhurst
>
> Add a new 'smp_init' hook to machine_desc so platforms can specify a
> function to be used to setup smp ops instead of having a statically
> defined value. The hook must return true when smp_ops are init
On Wed, Apr 24, 2013 at 11:14:28PM +0100, Stefano Stabellini wrote:
> On Wed, 24 Apr 2013, Stefano Stabellini wrote:
> > Signed-off-by: Stefano Stabellini
> > CC: Marc Zyngier
> > CC: will.dea...@arm.com
> > CC: a...@arndb.de
> > CC: rob.herr...@calxeda.com
>
> Thinking twice about this patch, a
On Thu, Apr 25, 2013 at 09:20:44AM +0100, Paul Bolle wrote:
> On Thu, 2013-04-25 at 17:02 +0900, Jonghwan Choi wrote:
> > This patch looks like it should be in the 3.8-stable tree, should we apply
> > it?
>
> That would be only the setup.c chunk. That fixes a typo introduced in
> v3.4 (see commit
On Thu, Apr 25, 2013 at 11:12:54AM +0100, Stefano Stabellini wrote:
> On Thu, 25 Apr 2013, Will Deacon wrote:
> > > +/*
> > > + * cpu_suspend Suspend the execution on a CPU
> > > + * @statewe don't currently describe affinity levels, so just
> &
On Thu, Apr 25, 2013 at 12:08:02PM +0100, Stefano Stabellini wrote:
> On Thu, 25 Apr 2013, Will Deacon wrote:
> > On Thu, Apr 25, 2013 at 11:12:54AM +0100, Stefano Stabellini wrote:
> > > However from the Linux POV these comments should regard the functions
> > > expor
: "cpu_topology" [drivers/cpufreq/arm_big_little.ko] undefined!
Are these first two in mainline?
> ERROR: "cpu_topology" [drivers/block/mtip32xx/mtip32xx.ko] undefined!
>
> The obvious solution is to export this symbol.
>
> Signed-off-by: Arnd Bergmann
>
On Fri, Apr 26, 2013 at 04:36:26PM +0100, Stefano Stabellini wrote:
> On Thu, 25 Apr 2013, Nicolas Pitre wrote:
> > On Thu, 25 Apr 2013, Will Deacon wrote:
> > > I disagree. You're explicitly stating that we pass the `cpuid of target
> > > CPU,
> > > as f
Hi Jacob,
On Fri, Apr 26, 2013 at 12:19:11AM +0100, Jacob Shin wrote:
> On Thu, Apr 25, 2013 at 10:17:35AM -0700, H. Peter Anvin wrote:
> > On 04/25/2013 10:06 AM, Oleg Nesterov wrote:
> > >>
> > >> The downside is that in userland perf tool we need differing
> > >> documentation
> > >> on what t
LL.
>
> Signed-off-by: Stefano Stabellini
> CC: Nicolas Pitre
> CC: Rob Herring
> CC: Will Deacon
> CC: a...@arndb.de
> CC: marc.zyng...@arm.com
> CC: li...@arm.linux.org.uk
Acked-by: Will Deacon
Will
--
To unsubscribe from this list: send the line "unsubscri
On Thu, Apr 11, 2013 at 09:16:57PM +0100, Rob Herring wrote:
> On 04/11/2013 03:25 AM, Olof Johansson wrote:
> > On Mon, Apr 08, 2013 at 12:05:17PM +0100, Stefano Stabellini wrote:
> >> Arnd, Olof,
> >> do you have any thoughts on this series?
> >> Would you be happy to carry it in the arm-soc tree
On Thu, Apr 11, 2013 at 05:19:21PM +0100, Stephen Warren wrote:
> On 04/10/2013 10:46 PM, Li Haifeng wrote:
> > 2013/4/10 Stephen Warren :
> >> On 04/10/2013 03:35 AM, Li Haifeng wrote:
> >>> Hi, everyone.
> >>>
> >>> Recently, I try to run kdump on pandaboard ES with omap4460. After
> >>> load cap
On Mon, Apr 15, 2013 at 11:11:59AM +0100, Catalin Marinas wrote:
> On Tue, Apr 09, 2013 at 01:33:34PM +0100, Christopher Covington wrote:
> > For accurate accounting pass contextidr_thread_switch the prev
> > task pointer, since cpu_switch_to has at that point changed the
> > the stack pointer.
> >
On Mon, Apr 15, 2013 at 12:43:07PM +0100, Catalin Marinas wrote:
> On Mon, Apr 15, 2013 at 11:58:40AM +0100, Catalin Marinas wrote:
> > On Mon, Apr 15, 2013 at 11:45:42AM +0100, Will Deacon wrote:
> > > Really? If prev is NULL in context_switch(...), the scheduler will
> >
On Tue, Apr 16, 2013 at 01:43:09AM +0100, Colin Cross wrote:
> On Mon, Apr 15, 2013 at 4:59 PM, Rob Herring wrote:
> > Exclusive accesses still have further restrictions. From section 3.4.5:
> >
> > • It is IMPLEMENTATION DEFINED whether LDREX and STREX operations can be
> > performed to a memory
; with SIGKILL", the __TASK_TRACED tracee can't be woken up and
> ->ptrace_bps[] can't go away.
>
> Signed-off-by: Oleg Nesterov
> Cc: Russell King
> Cc: Will Deacon
> ---
> arch/arm/kernel/ptrace.c |8
> 1 files changed, 0 insertions(+), 8 deletions(
On Mon, Apr 15, 2013 at 03:37:59PM +0100, Waiman Long wrote:
> If it is confirmed that all the supported architectures can allow a
> negative mutex count without incorrect behavior, we can then back
> out the architecture specific change and allow the mutex count to
> go to any negative number. Tha
On Fri, May 17, 2013 at 03:16:40AM +0100, Ming Lei wrote:
> Hi,
Hello,
> The commit a43cb95d5(dump_stack: unify debug information printed by
> show_regs())
> caused ARM perf regression, then 'perf top' outputs mistakenly, see
> [1]. The correct
> output should be [2], which can be got after rev
On Fri, May 17, 2013 at 10:27:05AM +0100, Ming Lei wrote:
> On Fri, May 17, 2013 at 4:55 PM, Will Deacon wrote:
> >
> > So it's still the morning and I haven't had my coffee yet, but I'm really
> > struggling to see what you're getting at. Why does this
On Fri, May 17, 2013 at 10:48:23AM +0100, Ming Lei wrote:
> On Fri, May 17, 2013 at 5:36 PM, Will Deacon wrote:
> >
> > It's probably easier if you choose a workload, otherwise it's difficult to
> > see what is `correct' and what is broken. For example, your
201 - 300 of 6287 matches
Mail list logo
