On 05/23/2014 08:45 PM, Anshuman Khandual wrote:
This patch series adds five new ELF core note sections which can be
used with existing ptrace request PTRACE_GETREGSET/SETREGSET for accessing
various transactional memory and miscellaneous register sets on PowerPC
platform. Please find a
On Wed, Sep 10, 2014 at 10:42:04AM -0700, Nicolin Chen wrote:
On Wed, Sep 10, 2014 at 04:12:53PM +0800, Shengjiu Wang wrote:
Then we can get a patch like:
open() {
+ clk_prepare_enable();
}
close() {
+ clk_disable_unprepare()
}
what is the open()
On Thu, Sep 11, 2014 at 08:36:51AM +0200, Markus Pargmann wrote:
On Wed, Sep 10, 2014 at 10:42:04AM -0700, Nicolin Chen wrote:
On Wed, Sep 10, 2014 at 04:12:53PM +0800, Shengjiu Wang wrote:
Then we can get a patch like:
open() {
+ clk_prepare_enable();
}
Is *that* what we are talking about? I was added to this conversation
in the middle where it had already generalized, so I had no idea.
No, this is just what brought this craziness to my attention.
None of it is craziness. It's the real world leaking into the crazy
delusional world of
This patch ensures the cpus to kexec/reboot at nominal frequency.
Nominal frequency is the highest cpu frequency on PowerPC at
which the cores can run without getting throttled.
If the host kernel had set the cpus to a low pstate and then it
kexecs/reboots to a cpufreq disabled kernel it would
On Wed, Sep 10, 2014 at 10:48:06PM +0100, James Bottomley wrote:
On Tue, 2014-09-09 at 06:40 -0400, Peter Hurley wrote:
The processor is free to re-order this to:
STORE C
STORE B
UNLOCK
That's because the unlock() only guarantees that:
Stores before the unlock in
On 11 September 2014 15:43, Shilpasri G Bhat
shilpa.b...@linux.vnet.ibm.com wrote:
This patch ensures the cpus to kexec/reboot at nominal frequency.
Nominal frequency is the highest cpu frequency on PowerPC at
which the cores can run without getting throttled.
If the host kernel had set the
On Wed, 10 Sep 2014 14:29:33 +0100
Aaron Tomlin atom...@redhat.com wrote:
On Wed, Sep 10, 2014 at 02:26:54AM -0500, Chuck Ebbert wrote:
And has this been tested on parisc and metag, which use STACK_GROWSUP ?
I can't see how end_of_stack() as it's defined now could work on those
archs.
On 11/09/14 02:22, Yijing Wang wrote:
On 2014/9/10 20:36, David Vrabel wrote:
On 05/09/14 11:09, Yijing Wang wrote:
Commit 0e4ccb150 added two __weak arch functions arch_msix_mask_irq()
and arch_msi_mask_irq() to fix a bug found when running xen in x86.
Introduced these two funcntions make
On Thu, Sep 11, 2014 at 07:23:45AM -0500, Chuck Ebbert wrote:
On Wed, 10 Sep 2014 14:29:33 +0100
Aaron Tomlin atom...@redhat.com wrote:
On Wed, Sep 10, 2014 at 02:26:54AM -0500, Chuck Ebbert wrote:
And has this been tested on parisc and metag, which use STACK_GROWSUP ?
I can't see how
Hi,
Any updates on this patch series?
On Monday 25 August 2014 11:31 PM, Shreyas B. Prabhu wrote:
Fast sleep is an idle state, where the core and the L1 and L2
caches are brought down to a threshold voltage. This also means that
the communication between L2 and L3 caches have to be fenced.
This facility is used in a few places so let's introduce
a helper function to improve code readability.
Signed-off-by: Aaron Tomlin atom...@redhat.com
---
arch/powerpc/mm/fault.c| 4 +---
arch/x86/mm/fault.c| 4 +---
include/linux/sched.h | 2 ++
kernel/trace/trace_stack.c | 2
Currently in the event of a stack overrun a call to schedule()
does not check for this type of corruption. This corruption is
often silent and can go unnoticed. However once the corrupted
region is examined at a later stage, the outcome is undefined
and often results in a sporadic page fault which
Tasks get their end of stack set to STACK_END_MAGIC with the
aim to catch stack overruns. Currently this feature does not
apply to init_task. This patch removes this restriction.
Note that a similar patch was posted by Prarit Bhargava [1]
some time ago but was never merged.
[1]:
Hi Peter,
Please let me know if this iteration is satisfactory. Thanks.
Currently in the event of a stack overrun a call to schedule()
does not check for this type of corruption. This corruption is
often silent and can go unnoticed. However once the corrupted
region is examined at a later
What's with the threading all versions together? Please don't do that --
also don't post a new version just for this though.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
On Thu, Sep 11, 2014 at 05:53:03PM +0200, Peter Zijlstra wrote:
What's with the threading all versions together? Please don't do that --
also don't post a new version just for this though.
Sorry about that. Noted.
--
Aaron Tomlin
___
Linuxppc-dev
From: Aaron Tomlin
Currently in the event of a stack overrun a call to schedule()
does not check for this type of corruption. This corruption is
often silent and can go unnoticed. However once the corrupted
region is examined at a later stage, the outcome is undefined
and often results in a
On Thu, Sep 11, 2014 at 11:04:11AM +0100, One Thousand Gnomes wrote:
Is *that* what we are talking about? I was added to this conversation
in the middle where it had already generalized, so I had no idea.
No, this is just what brought this craziness to my attention.
None of it is
On Thu, 11 Sep 2014 16:02:45 +
David Laight david.lai...@aculab.com wrote:
From: Aaron Tomlin
Currently in the event of a stack overrun a call to schedule()
does not check for this type of corruption. This corruption is
often silent and can go unnoticed. However once the corrupted
On Thu, Sep 11, 2014 at 04:02:45PM +, David Laight wrote:
From: Aaron Tomlin
Currently in the event of a stack overrun a call to schedule()
does not check for this type of corruption. This corruption is
often silent and can go unnoticed. However once the corrupted
region is examined
On 09/11/2014 06:04 AM, One Thousand Gnomes wrote:
Is *that* what we are talking about? I was added to this conversation
in the middle where it had already generalized, so I had no idea.
No, this is just what brought this craziness to my attention.
None of it is craziness. It's the real
Hi Stephen,
You removed export.h ...
+EXPORT_SYMBOL(flush_dcache_range);
+EXPORT_SYMBOL(flush_icache_range);
But still use EXPORT_SYMBOL ...
Thanks, fixed!
Anton
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
Hi Stephen,
Please be consistent about extern use (unless this file is already
inconsistent, I guess). (I know that the current trend is to remove
extern in header files - I just happen to disagree with that
trend. :-))
Good idea, fixed this for the next rev.
Anton
On Thu, Sep 11, 2014 at 01:38:29PM +0800, Shengjiu Wang wrote:
Move the ipg clock enable and disable operation to startup and shutdown,
that is only enable ipg clock when ssi is working. Keep clock is disabled
when ssi is in idle.
otherwise, _fsl_ssi_set_dai_fmt function need to be called in
On Thu, Sep 11, 2014 at 03:57:37PM -0700, Nicolin Chen wrote:
On Thu, Sep 11, 2014 at 01:38:29PM +0800, Shengjiu Wang wrote:
Move the ipg clock enable and disable operation to startup and shutdown,
that is only enable ipg clock when ssi is working. Keep clock is disabled
when ssi is in
Shengjiu Wang wrote:
+ ret = clk_prepare_enable(ssi_private-clk);
+ if (ret)
+ return ret;
Will this work on PowerPC, where ssi_private-clk is always NULL?
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
On Thu, 2014-09-11 at 11:42 +0800, Wei Yang wrote:
diff --git a/arch/powerpc/kernel/eeh.c b/arch/powerpc/kernel/eeh.c
index 4a45ba8..403445e 100644
--- a/arch/powerpc/kernel/eeh.c
+++ b/arch/powerpc/kernel/eeh.c
@@ -625,7 +625,7 @@ int eeh_pci_enable(struct eeh_pe *pe, int function)
int
On Thu, 2014-09-11 at 16:41 +0100, Aaron Tomlin wrote:
diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
index a285900..2a8280a 100644
--- a/lib/Kconfig.debug
+++ b/lib/Kconfig.debug
@@ -824,6 +824,18 @@ config SCHEDSTATS
application, you can say N to avoid the very slight overhead
On Fri, Sep 12, 2014 at 01:55:23PM +1000, Michael Ellerman wrote:
On Thu, 2014-09-11 at 11:42 +0800, Wei Yang wrote:
diff --git a/arch/powerpc/kernel/eeh.c b/arch/powerpc/kernel/eeh.c
index 4a45ba8..403445e 100644
--- a/arch/powerpc/kernel/eeh.c
+++ b/arch/powerpc/kernel/eeh.c
@@ -625,7
On Thu, Sep 11, 2014 at 09:43:59PM -0500, Timur Tabi wrote:
Shengjiu Wang wrote:
+ret = clk_prepare_enable(ssi_private-clk);
+if (ret)
+return ret;
Will this work on PowerPC, where ssi_private-clk is always NULL?
When ssi_private-clk is NULL, then ret = 0, so here will
31 matches
Mail list logo
