Hi,
On Fri, Sep 12, 2014 at 10:01:12AM +0800, Shengjiu Wang wrote:
> 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 en
On Thu, 2014-09-11 at 16:41 +0100, Aaron Tomlin wrote:
> 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
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
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
>> @@ -6
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 over
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)
> 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
https:/
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 i
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 i
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
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
https://list
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
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 ex
On Thu, 11 Sep 2014 16:02:45 +
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 examine
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
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
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-de
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
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 stage,
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]: http://marc.info/
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
This facility is used in a few places so let's introduce
a helper function to improve code readability.
Signed-off-by: Aaron Tomlin
---
arch/powerpc/mm/fault.c| 4 +---
arch/x86/mm/fault.c| 4 +---
include/linux/sched.h | 2 ++
kernel/trace/trace_stack.c | 2 +-
4 files changed,
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. H
On Thu, Sep 11, 2014 at 07:23:45AM -0500, Chuck Ebbert wrote:
> On Wed, 10 Sep 2014 14:29:33 +0100
> Aaron Tomlin 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_s
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 funcnti
On Wed, 10 Sep 2014 14:29:33 +0100
Aaron Tomlin 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.
>
> AFAIU, dup
On 11 September 2014 15:43, Shilpasri G Bhat
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 cpus to a low pstate and th
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:
> > >>
>
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 cau
> > 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 o
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();
> > > >
31 matches
Mail list logo
