* [PATCH 4/20] powerpc/mm: Add opcode definitions for tlbivax and tlbsrx.
From: Benjamin Herrenschmidt @ 2009-07-23 5:59 UTC (permalink / raw)
To: linuxppc-dev
This adds the opcode definitions to ppc-opcode.h for the two instructions
tlbivax and tlbsrx. as defined by Book3E 2.06
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
---
arch/powerpc/include/asm/ppc-opcode.h | 6 ++++++
1 file changed, 6 insertions(+)
--- linux-work.orig/arch/powerpc/include/asm/ppc-opcode.h 2009-07-22 15:25:45.000000000 +1000
+++ linux-work/arch/powerpc/include/asm/ppc-opcode.h 2009-07-22 15:26:05.000000000 +1000
@@ -48,6 +48,8 @@
#define PPC_INST_TLBIE 0x7c000264
#define PPC_INST_TLBILX 0x7c000024
#define PPC_INST_WAIT 0x7c00007c
+#define PPC_INST_TLBIVAX 0x7c000624
+#define PPC_INST_TLBSRX_DOT 0x7c0006a5
/* macros to insert fields into opcodes */
#define __PPC_RA(a) (((a) & 0x1f) << 16)
@@ -76,6 +78,10 @@
__PPC_WC(w))
#define PPC_TLBIE(lp,a) stringify_in_c(.long PPC_INST_TLBIE | \
__PPC_RB(a) | __PPC_RS(lp))
+#define PPC_TLBSRX_DOT(a,b) stringify_in_c(.long PPC_INST_TLBSRX_DOT | \
+ __PPC_RA(a) | __PPC_RB(b))
+#define PPC_TLBIVAX(a,b) stringify_in_c(.long PPC_INST_TLBIVAX | \
+ __PPC_RA(a) | __PPC_RB(b))
/*
* Define what the VSX XX1 form instructions will look like, then add
^ permalink raw reply
* [PATCH 3/20] powerpc/mm: Add HW threads support to no_hash TLB management
From: Benjamin Herrenschmidt @ 2009-07-23 5:59 UTC (permalink / raw)
To: linuxppc-dev
The current "no hash" MMU context management code is written with
the assumption that one CPU == one TLB. This is not the case on
implementations that support HW multithreading, where several
linux CPUs can share the same TLB.
This adds some basic support for this to our context management
and our TLB flushing code.
It also cleans up the optional debugging output a bit
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
---
arch/powerpc/include/asm/cputhreads.h | 16 +++++
arch/powerpc/mm/mmu_context_nohash.c | 93 ++++++++++++++++++++++------------
arch/powerpc/mm/tlb_nohash.c | 10 ++-
3 files changed, 86 insertions(+), 33 deletions(-)
--- linux-work.orig/arch/powerpc/mm/mmu_context_nohash.c 2009-07-21 12:43:27.000000000 +1000
+++ linux-work/arch/powerpc/mm/mmu_context_nohash.c 2009-07-21 12:56:16.000000000 +1000
@@ -25,10 +25,20 @@
* also clear mm->cpu_vm_mask bits when processes are migrated
*/
-#undef DEBUG
-#define DEBUG_STEAL_ONLY
-#undef DEBUG_MAP_CONSISTENCY
-/*#define DEBUG_CLAMP_LAST_CONTEXT 15 */
+#define DEBUG_MAP_CONSISTENCY
+#define DEBUG_CLAMP_LAST_CONTEXT 31
+//#define DEBUG_HARDER
+
+/* We don't use DEBUG because it tends to be compiled in always nowadays
+ * and this would generate way too much output
+ */
+#ifdef DEBUG_HARDER
+#define pr_hard(args...) printk(KERN_DEBUG args)
+#define pr_hardcont(args...) printk(KERN_CONT args)
+#else
+#define pr_hard(args...) do { } while(0)
+#define pr_hardcont(args...) do { } while(0)
+#endif
#include <linux/kernel.h>
#include <linux/mm.h>
@@ -71,7 +81,7 @@ static DEFINE_SPINLOCK(context_lock);
static unsigned int steal_context_smp(unsigned int id)
{
struct mm_struct *mm;
- unsigned int cpu, max;
+ unsigned int cpu, max, i;
max = last_context - first_context;
@@ -89,15 +99,22 @@ static unsigned int steal_context_smp(un
id = first_context;
continue;
}
- pr_devel("[%d] steal context %d from mm @%p\n",
- smp_processor_id(), id, mm);
+ pr_hardcont(" | steal %d from 0x%p", id, mm);
/* Mark this mm has having no context anymore */
mm->context.id = MMU_NO_CONTEXT;
- /* Mark it stale on all CPUs that used this mm */
- for_each_cpu(cpu, mm_cpumask(mm))
- __set_bit(id, stale_map[cpu]);
+ /* Mark it stale on all CPUs that used this mm. For threaded
+ * implementations, we set it on all threads on each core
+ * represented in the mask. A future implementation will use
+ * a core map instead but this will do for now.
+ */
+ for_each_cpu(cpu, mm_cpumask(mm)) {
+ for (i = cpu_first_thread_in_core(cpu);
+ i <= cpu_last_thread_in_core(cpu); i++)
+ __set_bit(id, stale_map[i]);
+ cpu = i - 1;
+ }
return id;
}
@@ -126,7 +143,7 @@ static unsigned int steal_context_up(uns
/* Pick up the victim mm */
mm = context_mm[id];
- pr_devel("[%d] steal context %d from mm @%p\n", cpu, id, mm);
+ pr_hardcont(" | steal %d from 0x%p", id, mm);
/* Flush the TLB for that context */
local_flush_tlb_mm(mm);
@@ -179,19 +196,14 @@ void switch_mmu_context(struct mm_struct
/* No lockless fast path .. yet */
spin_lock(&context_lock);
-#ifndef DEBUG_STEAL_ONLY
- pr_devel("[%d] activating context for mm @%p, active=%d, id=%d\n",
- cpu, next, next->context.active, next->context.id);
-#endif
+ pr_hard("[%d] activating context for mm @%p, active=%d, id=%d",
+ cpu, next, next->context.active, next->context.id);
#ifdef CONFIG_SMP
/* Mark us active and the previous one not anymore */
next->context.active++;
if (prev) {
-#ifndef DEBUG_STEAL_ONLY
- pr_devel(" old context %p active was: %d\n",
- prev, prev->context.active);
-#endif
+ pr_hardcont(" (old=0x%p a=%d)", prev, prev->context.active);
WARN_ON(prev->context.active < 1);
prev->context.active--;
}
@@ -201,8 +213,14 @@ void switch_mmu_context(struct mm_struct
/* If we already have a valid assigned context, skip all that */
id = next->context.id;
- if (likely(id != MMU_NO_CONTEXT))
+ if (likely(id != MMU_NO_CONTEXT)) {
+#ifdef DEBUG_MAP_CONSISTENCY
+ if (context_mm[id] != next)
+ pr_err("MMU: mm 0x%p has id %d but context_mm[%d] says 0x%p\n",
+ next, id, id, context_mm[id]);
+#endif
goto ctxt_ok;
+ }
/* We really don't have a context, let's try to acquire one */
id = next_context;
@@ -234,11 +252,7 @@ void switch_mmu_context(struct mm_struct
next_context = id + 1;
context_mm[id] = next;
next->context.id = id;
-
-#ifndef DEBUG_STEAL_ONLY
- pr_devel("[%d] picked up new id %d, nrf is now %d\n",
- cpu, id, nr_free_contexts);
-#endif
+ pr_hardcont(" | new id=%d,nrf=%d", id, nr_free_contexts);
context_check_map();
ctxt_ok:
@@ -247,15 +261,20 @@ void switch_mmu_context(struct mm_struct
* local TLB for it and unmark it before we use it
*/
if (test_bit(id, stale_map[cpu])) {
- pr_devel("[%d] flushing stale context %d for mm @%p !\n",
- cpu, id, next);
+ pr_hardcont(" | stale flush %d [%d..%d]",
+ id, cpu_first_thread_in_core(cpu),
+ cpu_last_thread_in_core(cpu));
+
local_flush_tlb_mm(next);
/* XXX This clear should ultimately be part of local_flush_tlb_mm */
- __clear_bit(id, stale_map[cpu]);
+ for (cpu = cpu_first_thread_in_core(cpu);
+ cpu <= cpu_last_thread_in_core(cpu); cpu++)
+ __clear_bit(id, stale_map[cpu]);
}
/* Flick the MMU and release lock */
+ pr_hardcont(" -> %d\n", id);
set_context(id, next->pgd);
spin_unlock(&context_lock);
}
@@ -265,6 +284,8 @@ void switch_mmu_context(struct mm_struct
*/
int init_new_context(struct task_struct *t, struct mm_struct *mm)
{
+ pr_hard("initing context for mm @%p\n", mm);
+
mm->context.id = MMU_NO_CONTEXT;
mm->context.active = 0;
@@ -304,7 +325,9 @@ static int __cpuinit mmu_context_cpu_not
unsigned long action, void *hcpu)
{
unsigned int cpu = (unsigned int)(long)hcpu;
-
+#ifdef CONFIG_HOTPLUG_CPU
+ struct task_struct *p;
+#endif
/* We don't touch CPU 0 map, it's allocated at aboot and kept
* around forever
*/
@@ -323,8 +346,16 @@ static int __cpuinit mmu_context_cpu_not
pr_devel("MMU: Freeing stale context map for CPU %d\n", cpu);
kfree(stale_map[cpu]);
stale_map[cpu] = NULL;
- break;
-#endif
+
+ /* We also clear the cpu_vm_mask bits of CPUs going away */
+ read_lock(&tasklist_lock);
+ for_each_process(p) {
+ if (p->mm)
+ cpu_mask_clear_cpu(cpu, mm_cpumask(p->mm));
+ }
+ read_unlock(&tasklist_lock);
+ break;
+#endif /* CONFIG_HOTPLUG_CPU */
}
return NOTIFY_OK;
}
Index: linux-work/arch/powerpc/include/asm/cputhreads.h
===================================================================
--- linux-work.orig/arch/powerpc/include/asm/cputhreads.h 2009-07-21 12:43:27.000000000 +1000
+++ linux-work/arch/powerpc/include/asm/cputhreads.h 2009-07-21 12:56:16.000000000 +1000
@@ -5,6 +5,15 @@
/*
* Mapping of threads to cores
+ *
+ * Note: This implementation is limited to a power of 2 number of
+ * threads per core and the same number for each core in the system
+ * (though it would work if some processors had less threads as long
+ * as the CPU numbers are still allocated, just not brought offline).
+ *
+ * However, the API allows for a different implementation in the future
+ * if needed, as long as you only use the functions and not the variables
+ * directly.
*/
#ifdef CONFIG_SMP
@@ -67,5 +76,12 @@ static inline int cpu_first_thread_in_co
return cpu & ~(threads_per_core - 1);
}
+static inline int cpu_last_thread_in_core(int cpu)
+{
+ return cpu | (threads_per_core - 1);
+}
+
+
+
#endif /* _ASM_POWERPC_CPUTHREADS_H */
Index: linux-work/arch/powerpc/mm/tlb_nohash.c
===================================================================
--- linux-work.orig/arch/powerpc/mm/tlb_nohash.c 2009-07-21 12:43:31.000000000 +1000
+++ linux-work/arch/powerpc/mm/tlb_nohash.c 2009-07-21 12:57:21.000000000 +1000
@@ -87,6 +87,12 @@ EXPORT_SYMBOL(local_flush_tlb_page);
static DEFINE_SPINLOCK(tlbivax_lock);
+static int mm_is_core_local(struct mm_struct *mm)
+{
+ return cpumask_subset(mm_cpumask(mm),
+ topology_thread_cpumask(smp_processor_id()));
+}
+
struct tlb_flush_param {
unsigned long addr;
unsigned int pid;
@@ -131,7 +137,7 @@ void flush_tlb_mm(struct mm_struct *mm)
pid = mm->context.id;
if (unlikely(pid == MMU_NO_CONTEXT))
goto no_context;
- if (!cpumask_equal(mm_cpumask(mm), cpumask_of(smp_processor_id()))) {
+ if (!mm_is_core_local(mm)) {
struct tlb_flush_param p = { .pid = pid };
/* Ignores smp_processor_id() even if set. */
smp_call_function_many(mm_cpumask(mm),
@@ -153,7 +159,7 @@ void flush_tlb_page(struct vm_area_struc
if (unlikely(pid == MMU_NO_CONTEXT))
goto bail;
cpu_mask = mm_cpumask(vma->vm_mm);
- if (!cpumask_equal(cpu_mask, cpumask_of(smp_processor_id()))) {
+ if (!mm_is_core_local(mm)) {
/* If broadcast tlbivax is supported, use it */
if (mmu_has_feature(MMU_FTR_USE_TLBIVAX_BCAST)) {
int lock = mmu_has_feature(MMU_FTR_LOCK_BCAST_INVAL);
^ permalink raw reply
* [PATCH 2/20] powerpc/of: Remove useless register save/restore when calling OF back
From: Benjamin Herrenschmidt @ 2009-07-23 5:59 UTC (permalink / raw)
To: linuxppc-dev
enter_prom() used to save and restore registers such as CTR, XER etc..
which are volatile, or SRR0,1... which we don't care about. This
removes a bunch of useless code and while at it turns an mtmsrd into
an MTMSRD macro which will be useful to Book3E.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
---
arch/powerpc/kernel/entry_64.S | 38 ++++++--------------------------------
1 file changed, 6 insertions(+), 32 deletions(-)
--- linux-work.orig/arch/powerpc/kernel/entry_64.S 2009-07-22 15:20:26.000000000 +1000
+++ linux-work/arch/powerpc/kernel/entry_64.S 2009-07-22 15:22:44.000000000 +1000
@@ -823,30 +823,17 @@ _GLOBAL(enter_prom)
* of all registers that it saves. We therefore save those registers
* PROM might touch to the stack. (r0, r3-r13 are caller saved)
*/
- SAVE_8GPRS(2, r1)
+ SAVE_GPR(2, r1)
SAVE_GPR(13, r1)
SAVE_8GPRS(14, r1)
SAVE_10GPRS(22, r1)
- mfcr r4
- std r4,_CCR(r1)
- mfctr r5
- std r5,_CTR(r1)
- mfspr r6,SPRN_XER
- std r6,_XER(r1)
- mfdar r7
- std r7,_DAR(r1)
- mfdsisr r8
- std r8,_DSISR(r1)
- mfsrr0 r9
- std r9,_SRR0(r1)
- mfsrr1 r10
- std r10,_SRR1(r1)
+ mfcr r10
mfmsr r11
+ std r10,_CCR(r1)
std r11,_MSR(r1)
/* Get the PROM entrypoint */
- ld r0,GPR4(r1)
- mtlr r0
+ mtlr r4
/* Switch MSR to 32 bits mode
*/
@@ -860,8 +847,7 @@ _GLOBAL(enter_prom)
mtmsrd r11
isync
- /* Restore arguments & enter PROM here... */
- ld r3,GPR3(r1)
+ /* Enter PROM here... */
blrl
/* Just make sure that r1 top 32 bits didn't get
@@ -871,7 +857,7 @@ _GLOBAL(enter_prom)
/* Restore the MSR (back to 64 bits) */
ld r0,_MSR(r1)
- mtmsrd r0
+ MTMSRD(r0)
isync
/* Restore other registers */
@@ -881,18 +867,6 @@ _GLOBAL(enter_prom)
REST_10GPRS(22, r1)
ld r4,_CCR(r1)
mtcr r4
- ld r5,_CTR(r1)
- mtctr r5
- ld r6,_XER(r1)
- mtspr SPRN_XER,r6
- ld r7,_DAR(r1)
- mtdar r7
- ld r8,_DSISR(r1)
- mtdsisr r8
- ld r9,_SRR0(r1)
- mtsrr0 r9
- ld r10,_SRR1(r1)
- mtsrr1 r10
addi r1,r1,PROM_FRAME_SIZE
ld r0,16(r1)
^ permalink raw reply
* [PATCH 1/20] powerpc/mm: Fix misplaced #endif in pgtable-ppc64-64k.h
From: Benjamin Herrenschmidt @ 2009-07-23 5:59 UTC (permalink / raw)
To: linuxppc-dev
A misplaced #endif causes more definitions than intended to be
protected by #ifndef __ASSEMBLY__. This breaks upcoming 64-bit
BookE support patch when using 64k pages.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
---
arch/powerpc/include/asm/pgtable-ppc64-64k.h | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
--- linux-work.orig/arch/powerpc/include/asm/pgtable-ppc64-64k.h 2009-07-22 11:45:34.000000000 +1000
+++ linux-work/arch/powerpc/include/asm/pgtable-ppc64-64k.h 2009-07-22 11:45:47.000000000 +1000
@@ -10,10 +10,10 @@
#define PGD_INDEX_SIZE 4
#ifndef __ASSEMBLY__
-
#define PTE_TABLE_SIZE (sizeof(real_pte_t) << PTE_INDEX_SIZE)
#define PMD_TABLE_SIZE (sizeof(pmd_t) << PMD_INDEX_SIZE)
#define PGD_TABLE_SIZE (sizeof(pgd_t) << PGD_INDEX_SIZE)
+#endif /* __ASSEMBLY__ */
#define PTRS_PER_PTE (1 << PTE_INDEX_SIZE)
#define PTRS_PER_PMD (1 << PMD_INDEX_SIZE)
@@ -32,8 +32,6 @@
#define PGDIR_SIZE (1UL << PGDIR_SHIFT)
#define PGDIR_MASK (~(PGDIR_SIZE-1))
-#endif /* __ASSEMBLY__ */
-
/* Bits to mask out from a PMD to get to the PTE page */
#define PMD_MASKED_BITS 0x1ff
/* Bits to mask out from a PGD/PUD to get to the PMD page */
^ permalink raw reply
* Re: [PATCH] Hold reference to device_node during EEH event handling
From: Michael Ellerman @ 2009-07-23 1:21 UTC (permalink / raw)
To: Mike Mason; +Cc: linuxppc-dev, linasvepstas, Paul Mackerras
In-Reply-To: <4A67A3A2.4050508@us.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 2562 bytes --]
On Wed, 2009-07-22 at 16:41 -0700, Mike Mason wrote:
> Michael Ellerman wrote:
> > On Thu, 2009-07-16 at 09:33 -0700, Mike Mason wrote:
> >> Michael Ellerman wrote:
> >>> On Wed, 2009-07-15 at 14:43 -0700, Mike Mason wrote:
> >>>> This patch increments the device_node reference counter when an EEH
> >>>> error occurs and decrements the counter when the event has been
> >>>> handled. This is to prevent the device_node from being released until
> >>>> eeh_event_handler() has had a chance to deal with the event. We've
> >>>> seen cases where the device_node is released too soon when an EEH
> >>>> event occurs during a dlpar remove, causing the event handler to
> >>>> attempt to access bad memory locations.
> >>>>
> >>>> Please review and let me know of any concerns.
> >>> Taking a reference sounds sane, but ...
> >>>
> >>>> Signed-off-by: Mike Mason <mmlnx@us.ibm.com>
> >>>>
> >>>> --- a/arch/powerpc/platforms/pseries/eeh_event.c 2008-10-09 15:13:53.000000000 -0700
> >>>> +++ b/arch/powerpc/platforms/pseries/eeh_event.c 2009-07-14 14:14:00.000000000 -0700
> >>>> @@ -75,6 +75,14 @@ static int eeh_event_handler(void * dumm
> >>>> if (event == NULL)
> >>>> return 0;
> >>>>
> >>>> + /* EEH holds a reference to the device_node, so if it
> >>>> + * equals 1 it's no longer valid and the event should
> >>>> + * be ignored */
> >>>> + if (atomic_read(&event->dn->kref.refcount) == 1) {
> >>>> + of_node_put(event->dn);
> >>>> + return 0;
> >>>> + }
> >>> That's really gross :)
> >> Agreed. I'll look for another way to determine if device is gone and
> >> the event should be ignored. Suggestions are welcome :-)
>
> Actually, it turns out the atomic_read() isn't necessary. I just need
> to take the reference to the device_node when the EEH error is
> detected and let EEH try to handle the error. EEH detects the fact
> that the device is no longer valid, aborts the recovery attempt, then
> gives the device_node reference back. Works as expected.
How does it detect that the device is no longer valid?
> I'll resubmit the patch without the atomic_read().
>
> >
> > Benh and I had a quick chat about it, and were wondering whether what
> > you really should be doing is taking a reference to the pci device
> > (perhaps as well as the device node).
>
> EEH already does that 3 lines before the of_node_get (see below).
Ah right, while you're touching the code, mind changing it to the
simpler and more obvious:
> event->dev = pci_dev_get(dev);
cheers
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [LTP] msgctl10 fails on Powerpc Linux-2.6.29.6
From: Kumar Gala @ 2009-07-23 1:03 UTC (permalink / raw)
To: srikanth krishnakar; +Cc: Linuxppc-dev, Ltp-list
In-Reply-To: <6213bc560907220932u3b771af2q743ae55dda5a2198@mail.gmail.com>
On Jul 22, 2009, at 11:32 AM, srikanth krishnakar wrote:
>
>
> On Wed, Jul 22, 2009 at 9:14 PM, Kumar Gala
> <galak@kernel.crashing.org> wrote:
>
> On Jul 22, 2009, at 10:38 AM, srikanth krishnakar wrote:
>
>
>
> On Wed, Jul 22, 2009 at 8:52 PM, Kumar Gala
> <galak@kernel.crashing.org> wrote:
> I'm not seeing any BUG* in traps.c @ line 904.
>
>
> On Jul 21, 2009, at 4:33 AM, srikanth krishnakar wrote:
>
> The LTP test case msgctl10.c fails on linux-2.6.29.6 for PowerPC
> architecture (ppc440)
>
>
> msgctl10 1 B------------[ cut here ]------------
> kernel BUG at arch/powerpc/kernel/traps.c:904!
> Oops: Exception in kernel mode, sig: 5 [#9]
>
> I'm not seeing any BUG* in traps.c @ line 904. Do you have some
> other patches on top of 2.6.29.6?
>
> - k
>
>
> I have LTTng patches on top of linux-2.6.29.6.
>
> Does it modify traps.c? Can you see what the code around line 904
> looks like and post that.
>
> - k
> 896
> 897 #if defined(CONFIG_XILINX_VIRTEX_5_FXT) &&
> defined(CONFIG_PPC_FPU)
> 898 if (reason & REASON_ILLEGAL) {
> 899 if (excep_state < 1) {
> 900 excep_state++;
> 901 return;
> 902 }
> 903 /* should never get here */
> 904 BUG();
> 905 }
> 906 #endif
> 907
> 908 /* Try to emulate it if we should. */
>
Are you sure this is coming from the LTTng patches? Which actual
patch makes this change?
- k
^ permalink raw reply
* Re: [RFC/PATCH] mm: Pass virtual address to [__]p{te, ud, md}_free_tlb()
From: Kumar Gala @ 2009-07-23 0:59 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Nick Piggin, Linux-Arch, Linux Memory Management, Hugh Dickins,
linux-kernel, linuxppc-dev, Linus Torvalds
In-Reply-To: <1248310415.3367.22.camel@pasglop>
On Jul 22, 2009, at 7:53 PM, Benjamin Herrenschmidt wrote:
> On Wed, 2009-07-22 at 09:31 -0700, Linus Torvalds wrote:
>>> CC'ing Linus here. How do you want to proceed with that merge ?
>>> (IE. so
>>> far nobody objected to the patch itself)
>>
>> Maybe you can put it as a separate branch in -next, and have it
>> merged
>> before the stuff that depends on it, and then just sending it to me
>> (as a
>> git branch or patch or whatever) in the first day of the merge
>> window?
>
> Hrm... my powerpc-next branch will contain stuff that depend on it, so
> I'll probably have to pull it in though, unless I tell all my
> sub-maintainers to also pull from that other branch first :-)
Can you not cherry pick it into powerpc-next to 'pull it through'?
- k
^ permalink raw reply
* Re: [RFC/PATCH] mm: Pass virtual address to [__]p{te,ud,md}_free_tlb()
From: Benjamin Herrenschmidt @ 2009-07-23 0:53 UTC (permalink / raw)
To: Linus Torvalds
Cc: Nick Piggin, Linux-Arch, linuxppc-dev, Hugh Dickins, linux-kernel,
Linux Memory Management
In-Reply-To: <alpine.LFD.2.01.0907220930320.19335@localhost.localdomain>
On Wed, 2009-07-22 at 09:31 -0700, Linus Torvalds wrote:
> > CC'ing Linus here. How do you want to proceed with that merge ? (IE. so
> > far nobody objected to the patch itself)
>
> Maybe you can put it as a separate branch in -next, and have it merged
> before the stuff that depends on it, and then just sending it to me (as a
> git branch or patch or whatever) in the first day of the merge window?
Hrm... my powerpc-next branch will contain stuff that depend on it, so
I'll probably have to pull it in though, unless I tell all my
sub-maintainers to also pull from that other branch first :-)
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH v3] net: Rework mdio-ofgpio driver to use of_mdio infrastructure
From: David Miller @ 2009-07-23 0:11 UTC (permalink / raw)
To: mware; +Cc: netdev, linuxppc-dev
In-Reply-To: <16861.1248307810@internode.on.net>
From: Mark Ware <mware@elphinstone.net>
Date: Thu, 23 Jul 2009 09:40:10 +0930
>
> The patch is actually attached this time. (I hope - did I mention my dislike for this webmail interface?)
No it isn't!
And anyways you have to properly provide the full commit message
and signoffs when you resubmit patches. You can't just resubmit
the patch because all of the context is lost in patchwork.
Grrr...
^ permalink raw reply
* Re: [PATCH v3] net: Rework mdio-ofgpio driver to use of_mdioinfrastructure
From: David Miller @ 2009-07-23 0:10 UTC (permalink / raw)
To: mware; +Cc: netdev, linuxppc-dev
In-Reply-To: <16811.1248307327@internode.on.net>
From: Mark Ware <mware@elphinstone.net>
Date: Thu, 23 Jul 2009 09:02:07 +0900
> Patch is attached, hopefully with correct MIME type - this webmail
> client is worse than Outlook.
Where is it attached? :-/
^ permalink raw reply
* Re: Re: [PATCH v3] net: Rework mdio-ofgpio driver to use of_mdio infrastructure
From: Mark Ware @ 2009-07-23 0:10 UTC (permalink / raw)
To: davem; +Cc: netdev, linuxppc-dev
On Thu 23/07/09 2:10 AM , David Miller davem@davemloft.net sent:
> Your email client has massively corrupted this patch, I even tried
> to fix it up but it's so bad that I just gave up half-way through.
>=20
> Please use an attachment or whatever is necessary to get this
> patch submitted cleanly and without it getting damaged. Read:
>=20
> linux/Documentation/email-clients.txt
>=20
> for tips.
>=20
> Thanks.
Dave,
The patch is actually attached this time. (I hope - did I mention my disli=
ke for this webmail interface?)
Sorry for the further noise.
Regards,
Mark
^ permalink raw reply
* Re: [PATCH v3] net: Rework mdio-ofgpio driver to use of_mdioinfrastructure
From: Mark Ware @ 2009-07-23 0:02 UTC (permalink / raw)
To: davem; +Cc: netdev, linuxppc-dev
On Thu 23/07/09 2:10 AM , David Miller davem@davemloft.net sent:
> Your email client has massively corrupted this patch, I even tried
> to fix it up but it's so bad that I just gave up half-way through.
>=20
> Please use an attachment or whatever is necessary to get this
> patch submitted cleanly and without it getting damaged. Read:
>=20
> linux/Documentation/email-clients.txt for tips.
>=20
> Thanks.
Sorry for the waste of time. I've obviously somehow broken my thunderbird =
config.
Patch is attached, hopefully with correct MIME type - this webmail client i=
s worse than Outlook.
(Incidently, I was able to apply the corrupted patch after the following tw=
o substitutions: s/^ / / and s/^$/ /)
Regards,
Mark
^ permalink raw reply
* Re: [PATCH] Hold reference to device_node during EEH event handling
From: Mike Mason @ 2009-07-22 23:41 UTC (permalink / raw)
To: michael; +Cc: linuxppc-dev, linasvepstas, Paul Mackerras
In-Reply-To: <1247790973.16836.11.camel@concordia>
Michael Ellerman wrote:
> On Thu, 2009-07-16 at 09:33 -0700, Mike Mason wrote:
>> Michael Ellerman wrote:
>>> On Wed, 2009-07-15 at 14:43 -0700, Mike Mason wrote:
>>>> This patch increments the device_node reference counter when an EEH
>>>> error occurs and decrements the counter when the event has been
>>>> handled. This is to prevent the device_node from being released until
>>>> eeh_event_handler() has had a chance to deal with the event. We've
>>>> seen cases where the device_node is released too soon when an EEH
>>>> event occurs during a dlpar remove, causing the event handler to
>>>> attempt to access bad memory locations.
>>>>
>>>> Please review and let me know of any concerns.
>>> Taking a reference sounds sane, but ...
>>>
>>>> Signed-off-by: Mike Mason <mmlnx@us.ibm.com>
>>>>
>>>> --- a/arch/powerpc/platforms/pseries/eeh_event.c 2008-10-09 15:13:53.000000000 -0700
>>>> +++ b/arch/powerpc/platforms/pseries/eeh_event.c 2009-07-14 14:14:00.000000000 -0700
>>>> @@ -75,6 +75,14 @@ static int eeh_event_handler(void * dumm
>>>> if (event == NULL)
>>>> return 0;
>>>>
>>>> + /* EEH holds a reference to the device_node, so if it
>>>> + * equals 1 it's no longer valid and the event should
>>>> + * be ignored */
>>>> + if (atomic_read(&event->dn->kref.refcount) == 1) {
>>>> + of_node_put(event->dn);
>>>> + return 0;
>>>> + }
>>> That's really gross :)
>> Agreed. I'll look for another way to determine if device is gone and
>> the event should be ignored. Suggestions are welcome :-)
Actually, it turns out the atomic_read() isn't necessary. I just need to take the reference to the device_node when the EEH error is detected and let EEH try to handle the error. EEH detects the fact that the device is no longer valid, aborts the recovery attempt, then gives the device_node reference back. Works as expected.
I'll resubmit the patch without the atomic_read().
>
> Benh and I had a quick chat about it, and were wondering whether what
> you really should be doing is taking a reference to the pci device
> (perhaps as well as the device node).
EEH already does that 3 lines before the of_node_get (see below).
>
> @@ -140,7 +149,7 @@ int eeh_send_failure_event (struct devic
> if (dev)
> pci_dev_get(dev);
>
> - event->dn = dn;
> + event->dn = of_node_get(dn);
> event->dev = dev;
>
Thanks,
Mike
^ permalink raw reply
* Re: Best hardware platform for native compiling...
From: Olof Johansson @ 2009-07-22 20:18 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, David Jander
In-Reply-To: <1248180459.31121.9.camel@pasglop>
On Tue, Jul 21, 2009 at 10:47:39PM +1000, Benjamin Herrenschmidt wrote:
> On Tue, 2009-07-21 at 14:00 +0200, Gabriel Paubert wrote:
> > Well, I got one recently here in Spain. Shipping charges are fairly
> > large (it's not exactly a light and compact machine). But the current
> > dollar exchange rate helps ;-)
> >
> > Now I have not yet found the way to install Debian on it
> > (it refuses to boot Debian's CDROM), but I have not had
> > time to investigate either.
>
> It uses SLOF which should be capable of decent netbooting, so it should
> be possible to either netboot yaboot and have it load the kernel and
> initramfs, or maybe make a zImage with both included and netboot that.
Placing the debian (netinst) installer ramdisk and kernel on the /boot
partition and booting it from there should work too (after adding it to
the yaboot config).
-Olof
^ permalink raw reply
* Re: [PATCH v3] net: Rework mdio-ofgpio driver to use of_mdio infrastructure
From: David Miller @ 2009-07-22 16:40 UTC (permalink / raw)
To: mware; +Cc: netdev, linuxppc-dev
In-Reply-To: <4A66400F.3090309@elphinstone.net>
From: Mark Ware <mware@elphinstone.net>
Date: Wed, 22 Jul 2009 08:24:15 +1000
> Changes to the fs_enet driver
> (aa73832c5a80d6c52c69b18af858d88fa595dd3c) cause kernel crashes when
> using the mdio-ofgpio driver.
>
> This patch replicates similar changes made to the fs_enet mii-bitbang
> drivers. It has been tested on a custom mpc8280 based board using an
> NFS mounted root.
>
> Signed-off-by: Mark Ware <mware@elphinstone.net>
> Acked-by: Grant Likely <grant.likely@secretlab.ca>
Your email client has massively corrupted this patch, I even tried
to fix it up but it's so bad that I just gave up half-way through.
Please use an attachment or whatever is necessary to get this
patch submitted cleanly and without it getting damaged. Read:
linux/Documentation/email-clients.txt
for tips.
Thanks.
^ permalink raw reply
* Re: [LTP] msgctl10 fails on Powerpc Linux-2.6.29.6
From: srikanth krishnakar @ 2009-07-22 16:32 UTC (permalink / raw)
To: Kumar Gala; +Cc: Linuxppc-dev, Ltp-list
In-Reply-To: <578FBC09-589D-4691-82FF-985FCFE8ADC9@kernel.crashing.org>
[-- Attachment #1: Type: text/plain, Size: 1411 bytes --]
On Wed, Jul 22, 2009 at 9:14 PM, Kumar Gala <galak@kernel.crashing.org>wrote:
>
> On Jul 22, 2009, at 10:38 AM, srikanth krishnakar wrote:
>
>
>>
>> On Wed, Jul 22, 2009 at 8:52 PM, Kumar Gala <galak@kernel.crashing.org>
>> wrote:
>> I'm not seeing any BUG* in traps.c @ line 904.
>>
>>
>> On Jul 21, 2009, at 4:33 AM, srikanth krishnakar wrote:
>>
>> The LTP test case msgctl10.c fails on linux-2.6.29.6 for PowerPC
>> architecture (ppc440)
>>
>>
>> msgctl10 1 B------------[ cut here ]------------
>> kernel BUG at arch/powerpc/kernel/traps.c:904!
>> Oops: Exception in kernel mode, sig: 5 [#9]
>>
>> I'm not seeing any BUG* in traps.c @ line 904. Do you have some other
>> patches on top of 2.6.29.6?
>>
>> - k
>>
>>
>> I have LTTng patches on top of linux-2.6.29.6.
>>
>
> Does it modify traps.c? Can you see what the code around line 904 looks
> like and post that.
>
> - k
>
896
897 #if defined(CONFIG_XILINX_VIRTEX_5_FXT) && defined(CONFIG_PPC_FPU)
898 if (reason & REASON_ILLEGAL) {
899 if (excep_state < 1) {
900 excep_state++;
901 return;
902 }
903 /* should never get here */
904 BUG();
905 }
906 #endif
907
908 /* Try to emulate it if we should. */
--
"The Good You Do, The Best You GET"
Regards
Srikanth Krishnakar
**********************
[-- Attachment #2: Type: text/html, Size: 2104 bytes --]
^ permalink raw reply
* Re: [RFC/PATCH] mm: Pass virtual address to [__]p{te,ud,md}_free_tlb()
From: Linus Torvalds @ 2009-07-22 16:31 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Nick Piggin, Linux-Arch, linuxppc-dev, Hugh Dickins, linux-kernel,
Linux Memory Management
In-Reply-To: <1248073873.13067.31.camel@pasglop>
On Mon, 20 Jul 2009, Benjamin Herrenschmidt wrote:
> On Wed, 2009-07-15 at 15:56 +0200, Nick Piggin wrote:
> > > I would like to merge the new support that depends on this in 2.6.32,
> > > so unless there's major objections, I'd like this to go in early during
> > > the merge window. We can sort out separately how to carry the patch
> > > around in -next until then since the powerpc tree will have a dependency
> > > on it.
> >
> > Can't see any problem with that.
>
> CC'ing Linus here. How do you want to proceed with that merge ? (IE. so
> far nobody objected to the patch itself)
Maybe you can put it as a separate branch in -next, and have it merged
before the stuff that depends on it, and then just sending it to me (as a
git branch or patch or whatever) in the first day of the merge window?
Linus
^ permalink raw reply
* Re: [PATCH v2 0/4] net: Revive fixed link support
From: David Miller @ 2009-07-22 16:20 UTC (permalink / raw)
To: grant.likely; +Cc: leoli, netdev, afleming, linuxppc-dev
In-Reply-To: <fa686aa40907181137v4a0ed1ednfed3194d1308296a@mail.gmail.com>
From: Grant Likely <grant.likely@secretlab.ca>
Date: Sat, 18 Jul 2009 12:37:34 -0600
> Awesome. Dave, can you please pick up this series?
Sure thing.
^ permalink raw reply
* Re: [LTP] msgctl10 fails on Powerpc Linux-2.6.29.6
From: Kumar Gala @ 2009-07-22 15:44 UTC (permalink / raw)
To: srikanth krishnakar; +Cc: Linuxppc-dev, Ltp-list
In-Reply-To: <6213bc560907220838h49e5c273qa543e538bb37923a@mail.gmail.com>
On Jul 22, 2009, at 10:38 AM, srikanth krishnakar wrote:
>
>
> On Wed, Jul 22, 2009 at 8:52 PM, Kumar Gala
> <galak@kernel.crashing.org> wrote:
> I'm not seeing any BUG* in traps.c @ line 904.
>
>
> On Jul 21, 2009, at 4:33 AM, srikanth krishnakar wrote:
>
> The LTP test case msgctl10.c fails on linux-2.6.29.6 for PowerPC
> architecture (ppc440)
>
>
> msgctl10 1 B------------[ cut here ]------------
> kernel BUG at arch/powerpc/kernel/traps.c:904!
> Oops: Exception in kernel mode, sig: 5 [#9]
>
> I'm not seeing any BUG* in traps.c @ line 904. Do you have some
> other patches on top of 2.6.29.6?
>
> - k
>
>
> I have LTTng patches on top of linux-2.6.29.6.
Does it modify traps.c? Can you see what the code around line 904
looks like and post that.
- k
^ permalink raw reply
* Re: [LTP] msgctl10 fails on Powerpc Linux-2.6.29.6
From: srikanth krishnakar @ 2009-07-22 15:38 UTC (permalink / raw)
To: Kumar Gala; +Cc: Linuxppc-dev, Ltp-list
In-Reply-To: <2A0DDADE-5C3C-43F2-9487-98A8A735DC8D@kernel.crashing.org>
[-- Attachment #1: Type: text/plain, Size: 702 bytes --]
On Wed, Jul 22, 2009 at 8:52 PM, Kumar Gala <galak@kernel.crashing.org>wrote:
> I'm not seeing any BUG* in traps.c @ line 904.
>
> On Jul 21, 2009, at 4:33 AM, srikanth krishnakar wrote:
>
> The LTP test case msgctl10.c fails on linux-2.6.29.6 for PowerPC
>> architecture (ppc440)
>>
>>
>> msgctl10 1 B------------[ cut here ]------------
>> kernel BUG at arch/powerpc/kernel/traps.c:904!
>> Oops: Exception in kernel mode, sig: 5 [#9]
>>
>
> I'm not seeing any BUG* in traps.c @ line 904. Do you have some other
> patches on top of 2.6.29.6?
>
> - k
>
>
I have LTTng patches on top of linux-2.6.29.6.
--
"The Good You Do, The Best You GET"
Regards
Srikanth Krishnakar
**********************
[-- Attachment #2: Type: text/html, Size: 1257 bytes --]
^ permalink raw reply
* [PATCH] powerpc: update wrapper to point to the new location of dtc
From: Lucian Adrian Grijincu @ 2009-07-22 15:20 UTC (permalink / raw)
To: linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 334 bytes --]
dtc was moved in 9fffb55f66127b52c937ede5196ebfa0c0d50bce from
arch/powerpc/boot/ to scripts/dtc/
This patch updates the wrapper script to point to the new location of dtc.
Signed-off-by: Lucian Adrian Grijincu <lgrijincu@ixiacom.com>
---
arch/powerpc/boot/wrapper | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
[-- Attachment #2: 0001-powerpc-update-wrapper-to-point-to-the-new-location-.patch --]
[-- Type: text/x-patch, Size: 572 bytes --]
diff --git a/arch/powerpc/boot/wrapper b/arch/powerpc/boot/wrapper
index e964489..c907540 100755
--- a/arch/powerpc/boot/wrapper
+++ b/arch/powerpc/boot/wrapper
@@ -46,6 +46,7 @@ CROSS=
# directory for object and other files used by this script
object=arch/powerpc/boot
objbin=$object
+dtc=scripts/dtc/dtc
# directory for working files
tmpdir=.
@@ -124,7 +125,7 @@ if [ -n "$dts" ]; then
if [ -z "$dtb" ]; then
dtb="$platform.dtb"
fi
- $object/dtc -O dtb -o "$dtb" -b 0 "$dts"
+ $dtc -O dtb -o "$dtb" -b 0 "$dts"
fi
if [ -z "$kernel" ]; then
^ permalink raw reply related
* Re: [LTP] msgctl10 fails on Powerpc Linux-2.6.29.6
From: Kumar Gala @ 2009-07-22 15:22 UTC (permalink / raw)
To: srikanth krishnakar; +Cc: Linuxppc-dev, Ltp-list
In-Reply-To: <6213bc560907210233l17aa3e75pcb7c20e3faa24195@mail.gmail.com>
I'm not seeing any BUG* in traps.c @ line 904.
On Jul 21, 2009, at 4:33 AM, srikanth krishnakar wrote:
> The LTP test case msgctl10.c fails on linux-2.6.29.6 for PowerPC
> architecture (ppc440)
>
>
> msgctl10 1 B------------[ cut here ]------------
> kernel BUG at arch/powerpc/kernel/traps.c:904!
> Oops: Exception in kernel mode, sig: 5 [#9]
I'm not seeing any BUG* in traps.c @ line 904. Do you have some other
patches on top of 2.6.29.6?
- k
^ permalink raw reply
* Re: [PATCH] powerpc/cell: replace strncpy by strlcpy
From: Ken Kawakami @ 2009-07-22 4:22 UTC (permalink / raw)
To: roel.kluin; +Cc: linuxppc-dev, akpm, cbe-oss-dev, arnd
In-Reply-To: <4A6595AD.9000209@gmail.com>
Arnd-san, Roel-san,
It works fine. Thanks.
---
Regards,
Ken Kawakami
> Replace strncpy() and explicit null-termination by strlcpy()
>
> Signed-off-by: Roel Kluin <roel.kluin@gmail.com>
> ---
> Arnd-san, Ken-san,
>
> Thanks for reviewing,
>
> > We prefer to take the patch which is replacing the two lines with one.
>
> Doozo.
>
> diff --git a/arch/powerpc/platforms/cell/celleb_setup.c b/arch/powerpc/platforms/cell/celleb_setup.c
> index 07c234f..e538455 100644
> --- a/arch/powerpc/platforms/cell/celleb_setup.c
> +++ b/arch/powerpc/platforms/cell/celleb_setup.c
> @@ -80,8 +80,7 @@ static void celleb_show_cpuinfo(struct seq_file *m)
>
> static int __init celleb_machine_type_hack(char *ptr)
> {
> - strncpy(celleb_machine_type, ptr, sizeof(celleb_machine_type));
> - celleb_machine_type[sizeof(celleb_machine_type)-1] = 0;
> + strlcpy(celleb_machine_type, ptr, sizeof(celleb_machine_type));
> return 0;
> }
>
>
^ permalink raw reply
* [PATCH 5/7] [powerpc] ARRAY_SIZE changes
From: Stoyan Gaydarov @ 2009-07-22 3:02 UTC (permalink / raw)
To: linux-kernel; +Cc: Stoyan Gaydarov, paulus, linuxppc-dev
In-Reply-To: <1248231753-8344-5-git-send-email-sgayda2@uiuc.edu>
These changes were a direct result of using a semantic patch
More information can be found at http://www.emn.fr/x-info/coccinelle/
Signed-off-by: Stoyan Gaydarov <sgayda2@uiuc.edu>
---
arch/powerpc/platforms/pasemi/idle.c | 2 +-
arch/powerpc/platforms/powermac/feature.c | 4 ++--
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/platforms/pasemi/idle.c b/arch/powerpc/platforms/pasemi/idle.c
index 43911d8..75b296b 100644
--- a/arch/powerpc/platforms/pasemi/idle.c
+++ b/arch/powerpc/platforms/pasemi/idle.c
@@ -90,7 +90,7 @@ machine_late_initcall(pasemi, pasemi_idle_init);
static int __init idle_param(char *p)
{
int i;
- for (i = 0; i < sizeof(modes)/sizeof(struct sleep_mode); i++) {
+ for (i = 0; i < ARRAY_SIZE(modes); i++) {
if (!strcmp(modes[i].name, p)) {
current_mode = i;
break;
diff --git a/arch/powerpc/platforms/powermac/feature.c b/arch/powerpc/platforms/powermac/feature.c
index e6c0040..095de32 100644
--- a/arch/powerpc/platforms/powermac/feature.c
+++ b/arch/powerpc/platforms/powermac/feature.c
@@ -2419,13 +2419,13 @@ static int __init probe_motherboard(void)
dt = of_find_node_by_name(NULL, "device-tree");
if (dt != NULL)
model = of_get_property(dt, "model", NULL);
- for(i=0; model && i<(sizeof(pmac_mb_defs)/sizeof(struct pmac_mb_def)); i++) {
+ for(i=0; model && i<ARRAY_SIZE(pmac_mb_defs); i++) {
if (strcmp(model, pmac_mb_defs[i].model_string) == 0) {
pmac_mb = pmac_mb_defs[i];
goto found;
}
}
- for(i=0; i<(sizeof(pmac_mb_defs)/sizeof(struct pmac_mb_def)); i++) {
+ for(i=0; i<ARRAY_SIZE(pmac_mb_defs); i++) {
if (machine_is_compatible(pmac_mb_defs[i].model_string)) {
pmac_mb = pmac_mb_defs[i];
goto found;
--
1.6.3.3
^ permalink raw reply related
* [PATCH] powerpc/mm: Fix definitions of FORCE_MAX_ZONEORDER in Kconfig
From: Benjamin Herrenschmidt @ 2009-07-22 1:25 UTC (permalink / raw)
To: linuxppc-dev
The current definitions set ranges and defaults for 32 and 64-bit
only using "PPC_STD_MMU" which means hash based MMU. This uselessly
restrict the usefulness for the upcoming 64-bit BookE port, but more
than that, it's broken on 32-bit since the only 32-bit platform
supporting multiple page sizes currently is 44x which does -not-
have PPC_STD_MMU_32 set.
This fixes it by using PPC64 and PPC32 instead.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
---
arch/powerpc/Kconfig | 20 ++++++++++----------
1 file changed, 10 insertions(+), 10 deletions(-)
--- linux-work.orig/arch/powerpc/Kconfig 2009-07-22 11:22:16.000000000 +1000
+++ linux-work/arch/powerpc/Kconfig 2009-07-22 11:22:39.000000000 +1000
@@ -492,16 +492,16 @@ endchoice
config FORCE_MAX_ZONEORDER
int "Maximum zone order"
- range 9 64 if PPC_STD_MMU_64 && PPC_64K_PAGES
- default "9" if PPC_STD_MMU_64 && PPC_64K_PAGES
- range 13 64 if PPC_STD_MMU_64 && !PPC_64K_PAGES
- default "13" if PPC_STD_MMU_64 && !PPC_64K_PAGES
- range 9 64 if PPC_STD_MMU_32 && PPC_16K_PAGES
- default "9" if PPC_STD_MMU_32 && PPC_16K_PAGES
- range 7 64 if PPC_STD_MMU_32 && PPC_64K_PAGES
- default "7" if PPC_STD_MMU_32 && PPC_64K_PAGES
- range 5 64 if PPC_STD_MMU_32 && PPC_256K_PAGES
- default "5" if PPC_STD_MMU_32 && PPC_256K_PAGES
+ range 9 64 if PPC64 && PPC_64K_PAGES
+ default "9" if PPC64 && PPC_64K_PAGES
+ range 13 64 if PPC64 && !PPC_64K_PAGES
+ default "13" if PPC64 && !PPC_64K_PAGES
+ range 9 64 if PPC32 && PPC_16K_PAGES
+ default "9" if PPC32 && PPC_16K_PAGES
+ range 7 64 if PPC32 && PPC_64K_PAGES
+ default "7" if PPC32 && PPC_64K_PAGES
+ range 5 64 if PPC32 && PPC_256K_PAGES
+ default "5" if PPC32 && PPC_256K_PAGES
range 11 64
default "11"
help
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox