Hello-
Cliff Wickman wrote:
This patch would insert a preference to migrate such a task to a cpu within
its cpuset (and set its cpus_allowed to its cpuset).
With this patch, migrate the task to:
1) to any cpu on the same node as the disabled cpu, which is both online
and among that
Hi-
Ingo Molnar wrote:
* Cliff Wickman [EMAIL PROTECTED] wrote:
With this patch, migrate the task to:
1) to any cpu on the same node as the disabled cpu, which is both online
and among that task's cpus_allowed
2) to any online cpu within the task's cpuset
3) to any cpu which
Robin Holt wrote:
On Fri, Mar 09, 2007 at 05:58:59PM -0600, Nathan Lynch wrote:
Hello-
Cliff Wickman wrote:
This patch would insert a preference to migrate such a task to a cpu
within
its cpuset (and set its cpus_allowed to its cpuset).
With this patch, migrate the task
Gautham R Shenoy wrote:
This patch implements process_freezer based cpu-hotplug
core.
The sailent features are:
o No more (un)lock_cpu_hotplug.
o No more CPU_LOCK_ACQUIRE and CPU_LOCK_RELEASE. Hence no per-subsystem
hotcpu mutexes.
o Calls freeze_process/thaw_processes at the
Ingo Molnar wrote:
* Nathan Lynch [EMAIL PROTECTED] wrote:
- raw_notifier_call_chain(cpu_chain, CPU_LOCK_ACQUIRE, hcpu);
+ if (freeze_processes(FE_HOTPLUG_CPU)) {
+ thaw_processes(FE_HOTPLUG_CPU);
+ return -EBUSY;
+ }
+
If I'm understanding correctly
Ulrich Drepper wrote:
Siddha, Suresh B wrote:a
Not all of the cpu* directories in /sys/devices/system/cpu may be
online.
Apparently this information isn't needed. It's very easy to verify:
$ ls /sys/devices/system/cpu/*/online
/sys/devices/system/cpu/cpu1/online
Hi-
B. N. Poornima wrote:
On Fri, 2005-06-03 at 14:25 -0500, Nathan Lynch wrote:
Typo in prom_find_machine_type from Ben's recent patch ppc64: Fix
result code handling in prom_init prevents pSeries LPAR systems from
booting.
Hello,
Same typo has creped in again from 2.6.17 kernel
Hi Balbir-
Balbir Singh wrote:
Here's a dumb simple implementation of fake NUMA nodes for PowerPC. Fake
NUMA nodes can be specified using the following command line option
numa=fake=node range
node range is of the format range1,range2,...rangeN
Each of the rangeX parameters is
function text size changes to be accounted
to a single 'static.' entry in the output when comparing ppc64
kernels.
Change getsizes() to ignore the first character of the symbol name
when searching for '.'.
Signed-off-by: Nathan Lynch [EMAIL PROTECTED]
---
scripts/bloat-o-meter |3 ++-
1 files
Gautham R Shenoy wrote:
Hi Nathan,
Hi Gautham-
Gautham R Shenoy wrote:
Replace all lock_cpu_hotplug/unlock_cpu_hotplug from the kernel and use
get_online_cpus and put_online_cpus instead as it highlights
the refcount semantics in these operations.
Something other than
Gautham R Shenoy wrote:
On Thu, Oct 18, 2007 at 03:22:21AM -0500, Nathan Lynch wrote:
Gautham R Shenoy wrote:
Hi Nathan,
Hi Gautham-
Gautham R Shenoy wrote:
Replace all lock_cpu_hotplug/unlock_cpu_hotplug from the kernel and
use
get_online_cpus
Gautham R Shenoy wrote:
Gautham R Shenoy wrote:
On Thu, Oct 18, 2007 at 03:22:21AM -0500, Nathan Lynch wrote:
Gautham R Shenoy wrote:
Gautham R Shenoy wrote:
Replace all lock_cpu_hotplug/unlock_cpu_hotplug from the kernel
and use
get_online_cpus
similar splats during system suspend.
The mutex in struct led_trigger_cpu appears to have no function: it
resides in a per-cpu data structure which never changes after the
trigger is registered. So just remove it.
Reported-by: Miles Lane miles.l...@gmail.com
Signed-off-by: Nathan Lynch n
Hi Bryan,
On Thu, 2012-10-18 at 11:18 -0700, Bryan Wu wrote:
@@ -117,14 +117,14 @@ static int __init ledtrig_cpu_init(void)
for_each_possible_cpu(cpu) {
struct led_trigger_cpu *trig = per_cpu(cpu_trig, cpu);
- mutex_init(trig-lock);
+
Hi,
Joachim Fenkes wrote:
Signed-off-by: Joachim Fenkes [EMAIL PROTECTED]
---
drivers/infiniband/hw/ehca/ehca_tools.h | 14 +++---
1 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/infiniband/hw/ehca/ehca_tools.h
b/drivers/infiniband/hw/ehca/ehca_tools.h
Hi-
Joachim Fenkes wrote:
Previously, ibmebus derived a device's bus_id from its location code. The
location code is not guaranteed to be unique, so we might get bus_id
collisions if two devices share the same location code. The OFDT full_name,
however, is unique, so we use that instead.
Hi Joachim-
Joachim Fenkes wrote:
Nathan Lynch [EMAIL PROTECTED] wrote on 29.08.2007 20:12:32:
Will anything break?
Nope. Userspace programs should not depend on ibmebus' way of naming the
devices; especially since some overly long loc_codes tended to be
truncated and thus rendered
Hi Gautham-
Gautham R Shenoy wrote:
Replace all lock_cpu_hotplug/unlock_cpu_hotplug from the kernel and use
get_online_cpus and put_online_cpus instead as it highlights
the refcount semantics in these operations.
Something other than get_online_cpus, please? lock_cpu_hotplug()
protects
On Tue, Apr 05, 2005 at 09:55:06AM +0800, Li Shaohua wrote:
On Mon, 2005-04-04 at 23:33, Nathan Lynch wrote:
No. It should make zero difference to the scheduler whether the play
dead cpu hotplug or physical hotplug is being used.
Keeping some fields like 'cpu_load' are meanless
We already do kobject_hotplug for cpu offline; this adds a
kobject_hotplug call for the online case. This is being requested by
developers of an application which wants to be notified about both
kinds of events.
Signed-off-by: Nathan Lynch [EMAIL PROTECTED]
Index: linux-2.6.12-rc2-mm3/drivers
Hi-
With 2.6.11-rc3-bk7 on ppc64 I am seeing lots of smp_processor_id
warnings whenever I hotplug cpus:
# echo 0 /sys/devices/system/cpu/cpu1/online
cpu 1 (hwid 1) Ready to die...
BUG: using smp_processor_id() in preemptible [0001] code:
ksoftirqd/1/5
caller is .ksoftirqd+0xbc/0x1f8
Call
On Sat, Feb 12, 2005 at 12:56:54AM +0100, Matthias-Christian Ott wrote:
Nathan Lynch wrote:
With 2.6.11-rc3-bk7 on ppc64 I am seeing lots of smp_processor_id
warnings whenever I hotplug cpus:
...
Use get_cpu() (It disables preemption) or __smp_processor_id () (on a smp).
It's
On Sat, Feb 12, 2005 at 11:59:04AM -0700, Zwane Mwaikambo wrote:
How about;
Index: linux-2.6.11-rc3-mm2/kernel/softirq.c
===
RCS file: /home/cvsroot/linux-2.6.11-rc3-mm2/kernel/softirq.c,v
retrieving revision 1.1.1.1
diff -u
On Tue, Feb 15, 2005 at 08:29:33AM -0700, Zwane Mwaikambo wrote:
On Mon, 14 Feb 2005, Nathan Lynch wrote:
It looks as if we need to explicitly bind worker threads to a newly
onlined cpu. This gets rid of the smp_processor_id warnings from
cache_reap. Adding a little more instrumentation
Hi Andrew-
On Tue, Feb 15, 2005 at 08:02:17AM +0100, Ingo Molnar wrote:
* Nathan Lynch [EMAIL PROTECTED] wrote:
It looks as if we need to explicitly bind worker threads to a newly
onlined cpu. This gets rid of the smp_processor_id warnings from
cache_reap. Adding a little more
Matt Domsch wrote:
On Tue, Jul 19, 2005 at 06:07:41PM -0600, Moore, Eric Dean wrote:
On Tuesday, July 12, 2005 8:17 PM, Matt Domsch wrote:
In general, this construct:
-#if (LINUX_VERSION_CODE KERNEL_VERSION(2,6,6))
-static int inline scsi_device_online(struct scsi_device
We need some clarity on how asm-generic/topology.h is intended to be
used. I suspect that it's supposed to be unconditionally included at
the end of the architecture's topology.h so that any elements which
are undefined by the arch have sensible default definitions. Looking
at 2.6.13-rc3, this
Matthew Dobson wrote:
Nathan Lynch wrote:
We need some clarity on how asm-generic/topology.h is intended to be
used. I suspect that it's supposed to be unconditionally included at
the end of the architecture's topology.h so that any elements which
are undefined by the arch have sensible
On Thu, Apr 21, 2005 at 08:46:56PM +0200, Pavel Machek wrote:
Hi!
We already do kobject_hotplug for cpu offline; this adds a
kobject_hotplug call for the online case. This is being requested by
developers of an application which wants to be notified about both
kinds of events.
I'm
On Wed, Mar 16, 2005 at 02:21:52PM +0100, Pavel Machek wrote:
Hi!
I tried to solve long-standing uglyness in swsusp cmp code by calling
cpu hotplug... only to find out that CONFIG_CPU_HOTPLUG is not
available on i386. Is there way to enable CPU_HOTPLUG on i386?
i386 cpu hotplug has been in
Hi again-
On Wed, Mar 16, 2005 at 02:21:52PM +0100, Pavel Machek wrote:
+ int cpu, error;
+ cpus_clear(frozen_cpus);
+ printk(Freezing cpus...\n);
+ for_each_online_cpu(cpu) {
+ if (!cpu)
+ continue;
+ cpu_set(cpu, frozen_cpus);
On Mon, Mar 21, 2005 at 04:19:01PM +0100, Mikael Pettersson wrote:
Compiling 2.6.12-rc1-mm1 for ppc64 fails with:
arch/ppc64/kernel/prom.c:1691: error: syntax error before
'prom_reconfig_notifier'
arch/ppc64/kernel/prom.c:1692: error: field name not in record or union
initializer
Hi-
It seems that the pSeries reconfig patch series which Paul sent on
March 17th to Andrew on my behalf was incompletely merged into bk? It
looks like only the last two of the series are in -bk as of today
(2.6.12-rc1-mm1 has them all).
Subject lines and URLs for the series in question:
of 8
patches from Nathan Lynch but not the first 6. :-P
Actually, this one is my fault, although unless I'm really missing
something gcc 3.4.2 silently accepts the invalid syntax.
All eight of the patches from the pSeries reconfig series are present
in 2.6.12-rc1-mm1. The error Mikael reported
On Mon, Apr 04, 2005 at 01:42:18PM +0800, Li Shaohua wrote:
Hi,
On Mon, 2005-04-04 at 13:28, Nathan Lynch wrote:
On Mon, Apr 04, 2005 at 10:07:02AM +0800, Li Shaohua wrote:
Clean up all CPU states including its runqueue and idle thread,
so we can use boot time code without any changes
Hi Nigel!
On Tue, Apr 05, 2005 at 08:14:25AM +1000, Nigel Cunningham wrote:
On Tue, 2005-04-05 at 01:33, Nathan Lynch wrote:
Yes, exactly. Someone who understand do_exit please help clean up the
code. I'd like to remove the idle thread, since the smpboot code will
create a new idle
-by: Nathan Lynch [EMAIL PROTECTED]
Index: linux-2.6.11-rc5-mm1/init/main.c
===
--- linux-2.6.11-rc5-mm1.orig/init/main.c 2005-03-02 00:12:07.0
+
+++ linux-2.6.11-rc5-mm1/init/main.c2005-03-02 00:53:04.0
, a more rigorously tested fix follows.
Signed-off-by: Nathan Lynch [EMAIL PROTECTED]
---
diff -puN arch/ppc64/kernel/prom.c~fix-kref-devnode arch/ppc64/kernel/prom.c
--- linux-2.6.11-rc2-mm1/arch/ppc64/kernel/prom.c~fix-kref-devnode
2005-01-25 21:10:50.0 -0600
+++ linux-2.6.11-rc2
, and I can't think of a good reason
why any out of tree code would use them. Unless I've missed something,
can we remove them before 2.6.11?
Build-tested for ia64 and i386.
Signed-off-by: Nathan Lynch [EMAIL PROTECTED]
Index: linux-2.6.11-rc2-mm1/drivers/base/cpu.c
On Wed, 2005-01-26 at 10:22 -0800, Keshavamurthy Anil S wrote:
On Wed, Jan 26, 2005 at 12:55:47AM -0600, Nathan Lynch wrote:
http://linus.bkbits.net:8080/linux-2.5/[EMAIL
PROTECTED]|src/|src/drivers|src/drivers/base|related/drivers/base/cpu.c
This changeset introduced exports
Hi-
With both 2.6.11-rc2-mm1 and -mm2 I'm seeing this message occasionally
on a ppc64 box with ext3 filesystems:
__journal_remove_journal_head: freeing b_committed_data
Is this cause for concern?
Nathan
#
# Automatically generated make config: don't edit
# Linux kernel version:
On Tue, 2005-01-11 at 11:29 -0800, Greg KH wrote:
On Mon, Jan 10, 2005 at 09:58:03AM -0600, Nathan Lynch wrote:
On Fri, 2005-01-07 at 21:07 -0800, Greg KH wrote:
On Fri, Jan 07, 2005 at 04:28:12PM -0600, Nathan Lynch wrote:
@@ -88,6 +123,12 @@ int sysdev_class_register(struct sysdev_
On Wed, 2013-01-23 at 08:07 +, Kim, Milo wrote:
This patch removes a build warning below.(ARCH=x86_64)
drivers/leds/leds-lp5521.c: In function lp5521_firmware_loaded:
drivers/leds/leds-lp5521.c:257:4: warning: format %d expects argument of type
in
t, but argument 3 has type size_t
On Thu, 2013-01-17 at 01:06 +, Kim, Milo wrote:
@@ -242,17 +233,15 @@ EXPORT_SYMBOL_GPL(led_trigger_unregister);
void led_trigger_event(struct led_trigger *trig,
enum led_brightness brightness)
{
- struct list_head *entry;
+ struct led_classdev *led_cdev;
On Fri, 2013-01-18 at 00:00 +, Kim, Milo wrote:
-Original Message-
From: Nathan Lynch [mailto:n...@pobox.com]
On Thu, 2013-01-17 at 01:06 +, Kim, Milo wrote:
@@ -242,17 +233,15 @@ EXPORT_SYMBOL_GPL(led_trigger_unregister);
void led_trigger_event(struct led_trigger
[EMAIL PROTECTED] wrote:
+#ifdef CONFIG_HOTPLUG_CPU
+ if (cpu_online(cpu)) {
+#else
if (cpu_online(cpu) || !cpu_present(cpu)) {
+#endif
ret = -EINVAL;
goto out;
}
Why this change? I think the cpu_present check is needed for ppc64
since it has
Protasevich, Natalie wrote:
+#ifdef CONFIG_HOTPLUG_CPU
+ if (cpu_online(cpu)) {
+#else
if (cpu_online(cpu) || !cpu_present(cpu)) {
+#endif
ret = -EINVAL;
goto out;
}
Why this change? I think the cpu_present check is needed for
ppc64 since it
of cpu_possible_map instead. This
should still preserve the behavior that Nick's change intended.
Thanks to Giuliano Pochini for reporting this and testing the fix:
http://ozlabs.org/pipermail/linuxppc-dev/2006-December/029397.html
Signed-off-by: Nathan Lynch [EMAIL PROTECTED]
---
This is a regression from
Anton Blanchard wrote:
Hi,
We need some clarity on how asm-generic/topology.h is intended to be
used. I suspect that it's supposed to be unconditionally included at
the end of the architecture's topology.h so that any elements which
are undefined by the arch have sensible default
Christoph Hellwig wrote:
On Thu, Jan 11, 2007 at 08:08:36PM +0100, Hoang-Nam Nguyen wrote:
spin_lock_irqsave(ehca_cq_idr_lock, flags);
while (my_cq-nr_callbacks)
yield();
Calling yield is a very bad idea in general. You should probably
add a waitqueue that gets
Jens Axboe wrote:
On Thu, Nov 30 2006, Jens Axboe wrote:
Hi,
Just got a new notebook (Lenovo X60), setup a custom kernel and then I
noticed that suspend to ram doesn't work anymore. The machine suspends
just fine, on resume it brings back the text display but reboots after
it has
Nathan Lynch wrote:
Jens Axboe wrote:
On Thu, Nov 30 2006, Jens Axboe wrote:
Hi,
Just got a new notebook (Lenovo X60), setup a custom kernel and then I
noticed that suspend to ram doesn't work anymore. The machine suspends
just fine, on resume it brings back the text display
Greg KH wrote:
On Fri, Jan 25, 2008 at 01:10:48PM -0600, Nathan Lynch wrote:
Jan-Bernd Themann wrote:
On Thursday 10 January 2008 18:34, Greg KH wrote:
The structure device_driver(in device.h) has a member struct
driver_private which
contains the member kobj (according
Jan-Bernd Themann wrote:
Hi,
sorry for answering so late, I'm only tracking netdev and ppc mailing list.
On Thursday 10 January 2008 18:34, Greg KH wrote:
The structure device_driver(in device.h) has a member struct
driver_private which
contains the member kobj (according to
] c000c320 .do_IRQ+0x108/0x1d0
[c04d5e0b3b20] c0004790 hardware_interrupt_entry+0x18/0x1c
The memset() in sym_set_cam_result_error() would appear to be trashing
the scsi_cmnd struct instead of clearing sense_buffer.
Signed-off-by: Nathan Lynch [EMAIL PROTECTED]
---
drivers/scsi
(cc'ing linuxppc-dev, see
http://www.mail-archive.com/linux-kernel@vger.kernel.org/msg221770.html
for original post and .config)
Elimar Riesebieter wrote:
On Wed, 24 Oct 2007 the mental interface of
Elimar Riesebieter told:
[...]
The kernel is loaded from firmware but freezes at the moment
Hi Joachim-
Joachim Fenkes wrote:
idr_init(), when called for the first time, sets up the layer
cache. idr_get_new() and friends expect the cache to exist. Now, what happens
if the first call to idr_get_new() targets an idr initialized using
DEFINE_IDR() before idr_init() has been called at
Hello-
Christian Kujau wrote:
Hi there,
Since a few days I'm experiencing weird oopses on my iBook/G4 with
ubuntu's 2.6.22-7-powerpc and also with a vanilla 2.6.22-rc7-git8.
Now for the weird part: The oops happens when doing make install for
a piece of software (xine-ui media player)
aa95387774039096c11803c04011f1aa42d85758 removed the implementation of
lock_cpu_hotplug_interruptible and all users of it. This stub
definition for !CONFIG_HOTPLUG_CPU was left over -- kill it now.
Signed-off-by: Nathan Lynch [EMAIL PROTECTED]
---
include/linux/cpu.h |1 -
1 files changed
Hi Gautham-
Gautham R Shenoy wrote:
Looking at the topology_init() code, I observe that the meaning of
the cpuX/ directory entries in /sys/devices/system/cpu/ might be
different for different architectures.
Looks like, in case of i386, ia64, m32, mips etc, the cpuX directory entries
On 04/23/2014 11:30 AM, H. Peter Anvin wrote:
On 04/21/2014 09:52 AM, Nathan Lynch wrote:
Hi x86/vdso people,
I've been working on adding a vDSO to 32-bit ARM, and Kees suggested I
look at x86_64's algorithm for placing the vDSO at a randomized offset
above the stack VMA. I found that when
Hi x86/vdso people,
I've been working on adding a vDSO to 32-bit ARM, and Kees suggested I
look at x86_64's algorithm for placing the vDSO at a randomized offset
above the stack VMA. I found that when the stack top occupies the
last slot in the PTE (is that the right term?), the vdso_addr
On 06/30/2014 07:30 AM, Fredrik Noring wrote:
On Fri, Jun 27, 2014 at 04:16:57PM +, Fredrik Noring wrote:
Please find below a trace that appeared once with 3.16-rc2. Perhaps it
is of some interest?
It's not that serious... I know that the FEC ethernet driver is horrendously
racy (I have
On 09/22/2014 10:39 AM, Will Deacon wrote:
On Thu, Sep 18, 2014 at 03:59:32PM +0100, Nathan Lynch wrote:
This series contains the necessary changes to allow architected timer
access from user-space on 32-bit ARM. This allows the VDSO to support
high resolution timestamps for clock_gettime
On 09/22/2014 05:30 PM, Russell King - ARM Linux wrote:
On Mon, Sep 22, 2014 at 04:39:19PM +0100, Will Deacon wrote:
On Thu, Sep 18, 2014 at 03:59:32PM +0100, Nathan Lynch wrote:
This series contains the necessary changes to allow architected timer
access from user-space on 32-bit ARM
On 09/11/2014 10:58 AM, Christopher Covington wrote:
On 09/11/2014 11:52 AM, Doug Anderson wrote:
diff --git a/drivers/clocksource/arm_arch_timer.c
b/drivers/clocksource/arm_arch_timer.c
index 5163ec1..8ca07a9 100644
--- a/drivers/clocksource/arm_arch_timer.c
+++
different names in one patch, then removed the unused functions in
subsequent patches for each of arm and arm64. This seemed kind of
awkward to me, so I've reorganized those changes into two patches
that should be easier to review. Patch #1 is unchanged.
Nathan Lynch (3):
clocksource
implementations.
Signed-off-by: Nathan Lynch nathan_ly...@mentor.com
---
arch/arm/include/asm/arch_timer.h| 14 --
arch/arm64/include/asm/arch_timer.h | 17 -
drivers/clocksource/arm_arch_timer.c | 17 +
3 files changed, 17 insertions(+), 31 deletions
The arm and arm64 VDSOs need CP15 access to the architected counter.
If this is unavailable (which is allowed by ARM v7), indicate this by
changing the clocksource name to arch_mem_counter before registering
the clocksource.
Suggested by Stephen Boyd.
Signed-off-by: Nathan Lynch nathan_ly
The arch_timer_evtstrm_enable hooks in arm and arm64 are substantially
similar, the only difference being a CONFIG_COMPAT-conditional section
which is relevant only for arm64. Copy the arm64 version to the
driver, removing the arch-specific hooks.
Signed-off-by: Nathan Lynch nathan_ly
Hi Daniel,
On 09/26/2014 02:04 AM, Daniel Lezcano wrote:
On 09/18/2014 04:59 PM, Nathan Lynch wrote:
The arm and arm64 VDSOs need CP15 access to the architected counter.
If this is unavailable (which is allowed by ARM v7), indicate this by
changing the clocksource name to arch_mem_counter
On 09/24/2014 09:12 AM, Christopher Covington wrote:
Hi Nathan,
On 09/22/2014 08:28 PM, Nathan Lynch wrote:
On 09/22/2014 05:30 PM, Russell King - ARM Linux wrote:
On Mon, Sep 22, 2014 at 04:39:19PM +0100, Will Deacon wrote:
On Thu, Sep 18, 2014 at 03:59:32PM +0100, Nathan Lynch wrote
On 09/24/2014 09:50 AM, Russell King - ARM Linux wrote:
On Wed, Sep 24, 2014 at 09:32:54AM -0500, Nathan Lynch wrote:
On 09/24/2014 09:12 AM, Christopher Covington wrote:
Hi Nathan,
On 09/22/2014 08:28 PM, Nathan Lynch wrote:
Hmm, this patch set is merely exposing the hardware counter when
On 10/30/2014 06:35 AM, Russell King - ARM Linux wrote:
On Thu, Oct 30, 2014 at 07:30:28AM -0400, Steven Rostedt wrote:
On Thu, 30 Oct 2014 11:14:41 +
Russell King - ARM Linux li...@arm.linux.org.uk wrote:
We have always had syscall number range of 0x90 or so. The tracing
design
On 10/10/2014 11:25 AM, Russell King - ARM Linux wrote:
Right, so GCC 4.8.{1,2} are totally unsuitable for kernel building (and
it seems that this has been known about for some time.)
Looking at http://gcc.gnu.org/PR58854 it seems that all 4.8.x for x 3
are affected, as well as 4.9.0.
We
On 10/10/2014 08:44 PM, Nathan Lynch wrote:
On 10/10/2014 11:25 AM, Russell King - ARM Linux wrote:
Right, so GCC 4.8.{1,2} are totally unsuitable for kernel building (and
it seems that this has been known about for some time.)
Looking at http://gcc.gnu.org/PR58854 it seems that all 4.8.x
On 01/19/2015 04:30 AM, Michal Simek wrote:
diff --git a/drivers/remoteproc/Kconfig b/drivers/remoteproc/Kconfig
index 5e343bab9458..3955f42e9e9c 100644
--- a/drivers/remoteproc/Kconfig
+++ b/drivers/remoteproc/Kconfig
@@ -64,4 +64,15 @@ config DA8XX_REMOTEPROC
It's safe to say n
On 03/30/2015 03:08 AM, Stephen Rothwell wrote:
Hi Russell,
On Mon, 30 Mar 2015 08:15:37 +0100 Russell King - ARM Linux
li...@arm.linux.org.uk wrote:
I'll drop the VDSO stuff from the ARM tree; I can't see a way to keep
it in my tree and keep my tree buildable without dragging in the tip
On 03/30/2015 10:08 AM, Russell King - ARM Linux wrote:
On Mon, Mar 30, 2015 at 09:57:48AM -0500, Nathan Lynch wrote:
On 03/30/2015 03:08 AM, Stephen Rothwell wrote:
Hi Russell,
On Mon, 30 Mar 2015 08:15:37 +0100 Russell King - ARM Linux
li...@arm.linux.org.uk wrote:
I'll drop the VDSO
the VDSO
init code whether the arch timer is present and usable.
Signed-off-by: Nathan Lynch nathan_ly...@mentor.com
---
drivers/clocksource/arm_arch_timer.c | 12
include/clocksource/arm_arch_timer.h | 6 ++
2 files changed, 18 insertions(+)
diff --git a/drivers/clocksource
Use the facility now provided by the arm_arch_timer driver to
determine whether there's a usable virtual counter for the VDSO.
Signed-off-by: Nathan Lynch nathan_ly...@mentor.com
---
arch/arm/kernel/vdso.c | 30 +-
1 file changed, 1 insertion(+), 29 deletions(-)
diff
On 04/27/2015 05:55 AM, Will Deacon wrote:
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
On 04/28/2015 03:32 PM, Andrey Skvortsov wrote:
After kernel is built 'git status' reports:
# Untracked files:
# (use git add file... to include in what will be committed)
#
#arch/arm/vdso/vdso.so.raw
#arch/arm/vdso/vdsomunge
These files are created during build
access the same timekeeper object which had been passed to
update_vsyscall. This is no longer the case.
Signed-off-by: Nathan Lynch nathan_ly...@mentor.com
---
arch/arm/kernel/vdso.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/arch/arm/kernel/vdso.c b/arch/arm
if they don't make 4.2 final at this late stage, since only
the (seldom-used?) coarse clocks are affected.
I'd like to collect review/acks for these now and make sure they at
least make it into 4.3-rc1 (and -stable after that).
Nathan Lynch (2):
ARM: VDSO: fix coarse clock monotonicity regression
arm64
would
access the same timekeeper object which had been passed to
update_vsyscall. This is no longer the case.
Signed-off-by: Nathan Lynch nathan_ly...@mentor.com
---
arch/arm64/kernel/vdso.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/arch/arm64/kernel/vdso.c b/arch
On 08/06/2015 05:52 PM, Andy Lutomirski wrote:
[adding lots of cc's]
On Thu, Aug 6, 2015 at 2:45 PM, Andy Lutomirski l...@kernel.org wrote:
From: Andy Lutomirski l...@amacapital.net
Some dynamic loaders may be slightly faster if a GNU hash is
available. Strangely, this seems to have no
access the same timekeeper object which had been passed to
update_vsyscall. This is no longer the case.
Signed-off-by: Nathan Lynch nathan_ly...@mentor.com
---
Changes since v1:
- Add u32 cast to nsec calculation.
arch/arm/kernel/vdso.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions
On 07/14/2015 12:18 AM, Yingjoe Chen wrote:
Add arch timer node to enable arch-timer support. MT8135 firmware
doesn't correctly setup arch-timer frequency and CNTVOFF, add
properties to workaround this.
[...]
+ timer {
+ compatible = arm,armv7-timer;
+
On 10/14/2015 07:47 AM, H. Nikolaus Schaller wrote:
>> diff --git a/arch/arm/vdso/vdsomunge.c b/arch/arm/vdso/vdsomunge.c
>> index aedec81..27a9a0b 100644
>> --- a/arch/arm/vdso/vdsomunge.c
>> +++ b/arch/arm/vdso/vdsomunge.c
>> @@ -45,7 +45,18 @@
>> * it does.
>> */
>>
>> -#include
>> +#define
On 10/15/2015 12:52 AM, H. Nikolaus Schaller wrote:
> Am 14.10.2015 um 16:16 schrieb Nathan Lynch <nathan_ly...@mentor.com>:
>> and it would be easier for me to deal with a patch that isn't
>> whitespace-damaged.
>
> You mean:
>
> ERROR: space prohibited before
On 10/15/2015 12:16 PM, H. Nikolaus Schaller wrote:
> Does this mean it is ok now in V3 in all cases? I have switched my patch
> editor
> tool from indirect git imap-send to git send-email (which appears to be more
> compatible).
v3 applied without issue, so yes, in that respect it is fine.
--
On 10/16/2015 01:38 AM, H. Nikolaus Schaller wrote:
> diff --git a/arch/arm/vdso/vdsomunge.c b/arch/arm/vdso/vdsomunge.c
> index aedec81..0cebd98 100644
> --- a/arch/arm/vdso/vdsomunge.c
> +++ b/arch/arm/vdso/vdsomunge.c
> @@ -45,7 +45,6 @@
> * it does.
> */
>
> -#include
> #include
>
On 08/26/2015 08:08 AM, Lee Jones wrote:
diff --git a/Documentation/devicetree/bindings/remoteproc/st-rproc.txt
b/Documentation/devicetree/bindings/remoteproc/st-rproc.txt
new file mode 100644
index 000..6a933c1
--- /dev/null
+++
On 08/26/2015 08:08 AM, Lee Jones wrote:
Signed-off-by: Lee Jones lee.jo...@linaro.org
---
drivers/remoteproc/remoteproc_debugfs.c | 25 +
1 file changed, 25 insertions(+)
The commit message should describe why this is needed...
diff --git
On 08/26/2015 08:08 AM, Lee Jones wrote:
--- /dev/null
+++ b/drivers/remoteproc/st_remoteproc.c
@@ -0,0 +1,300 @@
+/*
+ * ST's Remote Processor Control Driver
+ *
+ * Copyright (C) 2015 STMicroelectronics - All Rights Reserved
+ *
+ * Author: Ludovic Barre ludovic.ba...@st.com
When
On 08/27/2015 10:51 AM, Murali Karicheri wrote:
When using accumulator queue for rx side for network driver, following
warning is seen when doing a reboot command from Linux console. This
is because, affinity value is not reset before calling free_irq(). This
patch fixes this.
Deconfiguring
On 08/27/2015 01:23 PM, Murali Karicheri wrote:
On 08/27/2015 12:43 PM, Nathan Lynch wrote:
On 08/27/2015 10:51 AM, Murali Karicheri wrote:
When using accumulator queue for rx side for network driver, following
warning is seen when doing a reboot command from Linux console. This
is because
On 08/28/2015 05:31 AM, Lee Jones wrote:
+static ssize_t rproc_state_write(struct file *filp, const char __user
*userbuf,
+ size_t count, loff_t *ppos)
+{
+ struct rproc *rproc = filp-private_data;
+ char buf[2];
+ int ret;
+
+ ret =
On 08/28/2015 05:31 AM, Lee Jones wrote:
diff --git a/drivers/remoteproc/Kconfig b/drivers/remoteproc/Kconfig
index 28c711f..72e97d7 100644
--- a/drivers/remoteproc/Kconfig
+++ b/drivers/remoteproc/Kconfig
@@ -77,4 +77,13 @@ config DA8XX_REMOTEPROC
It's safe to say n here if you're
1 - 100 of 232 matches
Mail list logo
