* Re: [PATCH 3/5] dma-direct: refine dma_direct_alloc zone selection
From: Christoph Hellwig @ 2018-09-28 15:46 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Greg Kroah-Hartman, linuxppc-dev, linux-kernel, iommu,
Robin Murphy, Christoph Hellwig, Marek Szyprowski
In-Reply-To: <514bd29960cb1573ead2f3956f18e1cbaa5f32f7.camel@kernel.crashing.org>
On Fri, Sep 28, 2018 at 10:06:48AM +1000, Benjamin Herrenschmidt wrote:
> On Thu, 2018-09-27 at 15:49 +0200, Christoph Hellwig wrote:
> > On Thu, Sep 27, 2018 at 11:45:15AM +1000, Benjamin Herrenschmidt wrote:
> > > I'm not sure this is entirely right.
> > >
> > > Let's say the mask is 30 bits. You will return GFP_DMA32, which will
> > > fail if you allocate something above 1G (which is legit for
> > > ZONE_DMA32).
> >
> > And then we will try GFP_DMA further down in the function:
> >
> > if (IS_ENABLED(CONFIG_ZONE_DMA) &&
> > dev->coherent_dma_mask < DMA_BIT_MASK(32) &&
> > !(gfp & GFP_DMA)) {
> > gfp = (gfp & ~GFP_DMA32) | GFP_DMA;
> > goto again;
> > }
> >
> > This is and old optimization from x86, because chances are high that
> > GFP_DMA32 will give you suitable memory for the infamous 31-bit
> > dma mask devices (at least at boot time) and thus we don't have
> > to deplete the tiny ZONE_DMA pool.
>
> I see, it's rather confusing :-) Wouldn't it be better to check against
> top of 32-bit memory instead here too ?
Where is here? In __dma_direct_optimal_gfp_mask we already handled
it due to the optimistic zone selection we are discussing.
In the fallback quoted above there is no point for it, as with a
physical memory size smaller than ZONE_DMA32 (or ZONE_DMA for that matter)
we will have succeeded with the optimistic zone selection and not hit
the fallback path.
Either way this code probably needs much better comments. I'll send
a patch on top of the recent series.
^ permalink raw reply
* [PATCH 0/4] Fixes for SLB to C series
From: Nicholas Piggin @ 2018-09-28 16:00 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Aneesh Kumar K . V, Nicholas Piggin
These are some fixes I've got so far to sovle hangs and multi hits
particularly on P8 with 256MB segments (but can also be reproduced
on P9).
I'm not yet sure these solve all the problems, and they need some
good review and testing. So far they have been solid for me.
Thanks,
Nick
Nicholas Piggin (4):
powerpc/64: add struct int_regs to save additional registers on stack
powerpc/64: interrupts save PPR on stack rather than thread_struct
powerpc/64s/hash: Fix preloading of SLB entries
powerpc/64s/hash: add more barriers for slb preloading
arch/powerpc/include/asm/exception-64s.h | 9 ++--
arch/powerpc/include/asm/processor.h | 12 +++---
arch/powerpc/include/asm/ptrace.h | 18 +++++---
arch/powerpc/kernel/asm-offsets.c | 23 ++++++----
arch/powerpc/kernel/entry_64.S | 15 +++----
arch/powerpc/kernel/process.c | 54 ++++++++++++------------
arch/powerpc/kernel/ptrace.c | 4 +-
arch/powerpc/kernel/stacktrace.c | 2 +-
arch/powerpc/mm/slb.c | 48 ++++++++++++++++++---
9 files changed, 116 insertions(+), 69 deletions(-)
--
2.18.0
^ permalink raw reply
* [PATCH 1/4] powerpc/64: add struct int_regs to save additional registers on stack
From: Nicholas Piggin @ 2018-09-28 16:00 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Aneesh Kumar K . V, Nicholas Piggin
In-Reply-To: <20180928160058.18700-1-npiggin@gmail.com>
struct pt_regs is part of the user ABI and also the fundametal
structure for saving registers at interrupt.
The generic kernel code makes it difficult to completely decouple
these, but it's easy enough to add additional space required to save
more registers. Create a struct int_stack with struct pt_regs at
offset 0.
This is required for a following fix to save the PPR SPR on stack.
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
---
arch/powerpc/include/asm/ptrace.h | 17 +++++++---
arch/powerpc/kernel/asm-offsets.c | 21 ++++++++-----
arch/powerpc/kernel/process.c | 52 ++++++++++++++++---------------
arch/powerpc/kernel/stacktrace.c | 2 +-
4 files changed, 53 insertions(+), 39 deletions(-)
diff --git a/arch/powerpc/include/asm/ptrace.h b/arch/powerpc/include/asm/ptrace.h
index 447cbd1bee99..1a98cd8c49f6 100644
--- a/arch/powerpc/include/asm/ptrace.h
+++ b/arch/powerpc/include/asm/ptrace.h
@@ -26,7 +26,6 @@
#include <uapi/asm/ptrace.h>
#include <asm/asm-const.h>
-
#ifdef __powerpc64__
/*
@@ -44,7 +43,7 @@
#define STACK_FRAME_OVERHEAD 112 /* size of minimum stack frame */
#define STACK_FRAME_LR_SAVE 2 /* Location of LR in stack frame */
#define STACK_FRAME_REGS_MARKER ASM_CONST(0x7265677368657265)
-#define STACK_INT_FRAME_SIZE (sizeof(struct pt_regs) + \
+#define STACK_INT_FRAME_SIZE (sizeof(struct int_regs) + \
STACK_FRAME_OVERHEAD + KERNEL_REDZONE_SIZE)
#define STACK_FRAME_MARKER 12
@@ -76,6 +75,11 @@
#ifndef __ASSEMBLY__
+struct int_regs {
+ /* pt_regs must be offset 0 so r1 + STACK_FRAME_OVERHEAD points to it */
+ struct pt_regs pt_regs;
+};
+
#define GET_IP(regs) ((regs)->nip)
#define GET_USP(regs) ((regs)->gpr[1])
#define GET_FP(regs) (0)
@@ -119,8 +123,11 @@ extern int ptrace_get_reg(struct task_struct *task, int regno,
extern int ptrace_put_reg(struct task_struct *task, int regno,
unsigned long data);
-#define current_pt_regs() \
- ((struct pt_regs *)((unsigned long)current_thread_info() + THREAD_SIZE) - 1)
+#define current_int_regs() \
+ ((struct int_regs *)((unsigned long)current_thread_info() + THREAD_SIZE) - 1)
+
+#define current_pt_regs() (¤t_int_regs()->pt_regs)
+
/*
* We use the least-significant bit of the trap field to indicate
* whether we have saved the full set of registers, or only a
@@ -137,7 +144,7 @@ extern int ptrace_put_reg(struct task_struct *task, int regno,
#define TRAP(regs) ((regs)->trap & ~0xF)
#ifdef __powerpc64__
#define NV_REG_POISON 0xdeadbeefdeadbeefUL
-#define CHECK_FULL_REGS(regs) BUG_ON(regs->trap & 1)
+#define CHECK_FULL_REGS(regs) BUG_ON((regs)->trap & 1)
#else
#define NV_REG_POISON 0xdeadbeef
#define CHECK_FULL_REGS(regs) \
diff --git a/arch/powerpc/kernel/asm-offsets.c b/arch/powerpc/kernel/asm-offsets.c
index ba9d0fc98730..8db740a3a8c7 100644
--- a/arch/powerpc/kernel/asm-offsets.c
+++ b/arch/powerpc/kernel/asm-offsets.c
@@ -72,8 +72,13 @@
#include <asm/fixmap.h>
#endif
-#define STACK_PT_REGS_OFFSET(sym, val) \
- DEFINE(sym, STACK_FRAME_OVERHEAD + offsetof(struct pt_regs, val))
+#define STACK_INT_REGS_OFFSET(sym, val) \
+ DEFINE(sym, STACK_FRAME_OVERHEAD + offsetof(struct int_regs, val))
+
+#define STACK_PT_REGS_OFFSET(sym, val) \
+ DEFINE(sym, STACK_FRAME_OVERHEAD + \
+ offsetof(struct int_regs, pt_regs) + \
+ offsetof(struct pt_regs, val))
int main(void)
{
@@ -150,7 +155,7 @@ int main(void)
OFFSET(THREAD_CKFPSTATE, thread_struct, ckfp_state.fpr);
/* Local pt_regs on stack for Transactional Memory funcs. */
DEFINE(TM_FRAME_SIZE, STACK_FRAME_OVERHEAD +
- sizeof(struct pt_regs) + 16);
+ sizeof(struct int_regs) + 16);
#endif /* CONFIG_PPC_TRANSACTIONAL_MEM */
OFFSET(TI_FLAGS, thread_info, flags);
@@ -264,11 +269,11 @@ int main(void)
/* Interrupt register frame */
DEFINE(INT_FRAME_SIZE, STACK_INT_FRAME_SIZE);
- DEFINE(SWITCH_FRAME_SIZE, STACK_FRAME_OVERHEAD + sizeof(struct pt_regs));
+ DEFINE(SWITCH_FRAME_SIZE, STACK_FRAME_OVERHEAD + sizeof(struct int_regs));
#ifdef CONFIG_PPC64
/* Create extra stack space for SRR0 and SRR1 when calling prom/rtas. */
- DEFINE(PROM_FRAME_SIZE, STACK_FRAME_OVERHEAD + sizeof(struct pt_regs) + 16);
- DEFINE(RTAS_FRAME_SIZE, STACK_FRAME_OVERHEAD + sizeof(struct pt_regs) + 16);
+ DEFINE(PROM_FRAME_SIZE, STACK_FRAME_OVERHEAD + sizeof(struct int_regs) + 16);
+ DEFINE(RTAS_FRAME_SIZE, STACK_FRAME_OVERHEAD + sizeof(struct int_regs) + 16);
#endif /* CONFIG_PPC64 */
STACK_PT_REGS_OFFSET(GPR0, gpr[0]);
STACK_PT_REGS_OFFSET(GPR1, gpr[1]);
@@ -315,8 +320,8 @@ int main(void)
STACK_PT_REGS_OFFSET(SOFTE, softe);
/* These _only_ to be used with {PROM,RTAS}_FRAME_SIZE!!! */
- DEFINE(_SRR0, STACK_FRAME_OVERHEAD+sizeof(struct pt_regs));
- DEFINE(_SRR1, STACK_FRAME_OVERHEAD+sizeof(struct pt_regs)+8);
+ DEFINE(_SRR0, STACK_FRAME_OVERHEAD+sizeof(struct int_regs));
+ DEFINE(_SRR1, STACK_FRAME_OVERHEAD+sizeof(struct int_regs)+8);
#endif /* CONFIG_PPC64 */
#if defined(CONFIG_PPC32)
diff --git a/arch/powerpc/kernel/process.c b/arch/powerpc/kernel/process.c
index 03c2e1f134bc..532e9a83e526 100644
--- a/arch/powerpc/kernel/process.c
+++ b/arch/powerpc/kernel/process.c
@@ -1627,7 +1627,7 @@ static void setup_ksp_vsid(struct task_struct *p, unsigned long sp)
int copy_thread(unsigned long clone_flags, unsigned long usp,
unsigned long kthread_arg, struct task_struct *p)
{
- struct pt_regs *childregs, *kregs;
+ struct int_regs *childregs, *kregs;
extern void ret_from_fork(void);
extern void ret_from_kernel_thread(void);
void (*f)(void);
@@ -1637,44 +1637,44 @@ int copy_thread(unsigned long clone_flags, unsigned long usp,
klp_init_thread_info(ti);
/* Copy registers */
- sp -= sizeof(struct pt_regs);
- childregs = (struct pt_regs *) sp;
+ sp -= sizeof(struct int_regs);
+ childregs = (struct int_regs *) sp;
if (unlikely(p->flags & PF_KTHREAD)) {
/* kernel thread */
- memset(childregs, 0, sizeof(struct pt_regs));
- childregs->gpr[1] = sp + sizeof(struct pt_regs);
+ memset(childregs, 0, sizeof(struct int_regs));
+ childregs->pt_regs.gpr[1] = sp + sizeof(struct int_regs);
/* function */
if (usp)
- childregs->gpr[14] = ppc_function_entry((void *)usp);
+ childregs->pt_regs.gpr[14] = ppc_function_entry((void *)usp);
#ifdef CONFIG_PPC64
clear_tsk_thread_flag(p, TIF_32BIT);
- childregs->softe = IRQS_ENABLED;
+ childregs->pt_regs.softe = IRQS_ENABLED;
#endif
- childregs->gpr[15] = kthread_arg;
+ childregs->pt_regs.gpr[15] = kthread_arg;
p->thread.regs = NULL; /* no user register state */
ti->flags |= _TIF_RESTOREALL;
f = ret_from_kernel_thread;
} else {
/* user thread */
- struct pt_regs *regs = current_pt_regs();
- CHECK_FULL_REGS(regs);
+ struct int_regs *regs = current_int_regs();
+ CHECK_FULL_REGS(®s->pt_regs);
*childregs = *regs;
if (usp)
- childregs->gpr[1] = usp;
- p->thread.regs = childregs;
- childregs->gpr[3] = 0; /* Result from fork() */
+ childregs->pt_regs.gpr[1] = usp;
+ p->thread.regs = &childregs->pt_regs;
+ childregs->pt_regs.gpr[3] = 0; /* Result from fork() */
if (clone_flags & CLONE_SETTLS) {
#ifdef CONFIG_PPC64
if (!is_32bit_task())
- childregs->gpr[13] = childregs->gpr[6];
+ childregs->pt_regs.gpr[13] = childregs->pt_regs.gpr[6];
else
#endif
- childregs->gpr[2] = childregs->gpr[6];
+ childregs->pt_regs.gpr[2] = childregs->pt_regs.gpr[6];
}
f = ret_from_fork;
}
- childregs->msr &= ~(MSR_FP|MSR_VEC|MSR_VSX);
+ childregs->pt_regs.msr &= ~(MSR_FP|MSR_VEC|MSR_VSX);
sp -= STACK_FRAME_OVERHEAD;
/*
@@ -1686,8 +1686,8 @@ int copy_thread(unsigned long clone_flags, unsigned long usp,
* system call, using the stack frame created above.
*/
((unsigned long *)sp)[0] = 0;
- sp -= sizeof(struct pt_regs);
- kregs = (struct pt_regs *) sp;
+ sp -= sizeof(struct int_regs);
+ kregs = (struct int_regs *) sp;
sp -= STACK_FRAME_OVERHEAD;
p->thread.ksp = sp;
#ifdef CONFIG_PPC32
@@ -1715,7 +1715,7 @@ int copy_thread(unsigned long clone_flags, unsigned long usp,
p->thread.tidr = 0;
#endif
- kregs->nip = ppc_function_entry(f);
+ kregs->pt_regs.nip = ppc_function_entry(f);
return 0;
}
@@ -1739,8 +1739,8 @@ void start_thread(struct pt_regs *regs, unsigned long start, unsigned long sp)
* set. Do it now.
*/
if (!current->thread.regs) {
- struct pt_regs *regs = task_stack_page(current) + THREAD_SIZE;
- current->thread.regs = regs - 1;
+ struct int_regs *iregs = task_stack_page(current) + THREAD_SIZE;
+ current->thread.regs = &(iregs - 1)->pt_regs;
}
#ifdef CONFIG_PPC_TRANSACTIONAL_MEM
@@ -2106,11 +2106,13 @@ void show_stack(struct task_struct *tsk, unsigned long *stack)
*/
if (validate_sp(sp, tsk, STACK_INT_FRAME_SIZE)
&& stack[STACK_FRAME_MARKER] == STACK_FRAME_REGS_MARKER) {
- struct pt_regs *regs = (struct pt_regs *)
- (sp + STACK_FRAME_OVERHEAD);
- lr = regs->link;
+ struct int_regs *regs;
+ regs = (struct int_regs *)(sp + STACK_FRAME_OVERHEAD);
+ lr = regs->pt_regs.link;
printk("--- interrupt: %lx at %pS\n LR = %pS\n",
- regs->trap, (void *)regs->nip, (void *)lr);
+ regs->pt_regs.trap,
+ (void *)regs->pt_regs.nip,
+ (void *)lr);
firstframe = 1;
}
diff --git a/arch/powerpc/kernel/stacktrace.c b/arch/powerpc/kernel/stacktrace.c
index e2c50b55138f..463dedc4d664 100644
--- a/arch/powerpc/kernel/stacktrace.c
+++ b/arch/powerpc/kernel/stacktrace.c
@@ -120,7 +120,7 @@ save_stack_trace_tsk_reliable(struct task_struct *tsk,
* an unreliable stack trace until it's been
* _switch()'ed to for the first time.
*/
- stack_end -= STACK_FRAME_OVERHEAD + sizeof(struct pt_regs);
+ stack_end -= STACK_FRAME_OVERHEAD + sizeof(struct int_regs);
} else {
/*
* idle tasks have a custom stack layout,
--
2.18.0
^ permalink raw reply related
* [PATCH 2/4] powerpc/64: interrupts save PPR on stack rather than thread_struct
From: Nicholas Piggin @ 2018-09-28 16:00 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Aneesh Kumar K . V, Nicholas Piggin
In-Reply-To: <20180928160058.18700-1-npiggin@gmail.com>
PPR is the odd register out when it comes to interrupt handling,
it is saved in current->thread.ppr while all others are saved on
the stack.
The difficulty with this is that accessing thread.ppr can cause a
SLB fault, but the SLB fault handler implementation in C change had
assumed the normal exception entry handlers would not cause an SLB
fault.
Fix this by allocating room in the interrupt stack to save PPR.
Fixes: 5e46e29e6a97 ("powerpc/64s/hash: convert SLB miss handlers to C")
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
---
arch/powerpc/include/asm/exception-64s.h | 9 ++++-----
arch/powerpc/include/asm/processor.h | 12 +++++++-----
arch/powerpc/include/asm/ptrace.h | 1 +
arch/powerpc/kernel/asm-offsets.c | 2 +-
arch/powerpc/kernel/entry_64.S | 15 +++++----------
arch/powerpc/kernel/process.c | 2 +-
arch/powerpc/kernel/ptrace.c | 4 ++--
7 files changed, 21 insertions(+), 24 deletions(-)
diff --git a/arch/powerpc/include/asm/exception-64s.h b/arch/powerpc/include/asm/exception-64s.h
index 47578b79f0fb..3b4767ed3ec5 100644
--- a/arch/powerpc/include/asm/exception-64s.h
+++ b/arch/powerpc/include/asm/exception-64s.h
@@ -228,11 +228,10 @@
* PPR save/restore macros used in exceptions_64s.S
* Used for P7 or later processors
*/
-#define SAVE_PPR(area, ra, rb) \
+#define SAVE_PPR(area, ra) \
BEGIN_FTR_SECTION_NESTED(940) \
- ld ra,PACACURRENT(r13); \
- ld rb,area+EX_PPR(r13); /* Read PPR from paca */ \
- std rb,TASKTHREADPPR(ra); \
+ ld ra,area+EX_PPR(r13); /* Read PPR from paca */ \
+ std ra,_PPR(r1); \
END_FTR_SECTION_NESTED(CPU_FTR_HAS_PPR,CPU_FTR_HAS_PPR,940)
#define RESTORE_PPR_PACA(area, ra) \
@@ -500,7 +499,7 @@ END_FTR_SECTION_NESTED(ftr,ftr,943)
3: EXCEPTION_PROLOG_COMMON_1(); \
beq 4f; /* if from kernel mode */ \
ACCOUNT_CPU_USER_ENTRY(r13, r9, r10); \
- SAVE_PPR(area, r9, r10); \
+ SAVE_PPR(area, r9); \
4: EXCEPTION_PROLOG_COMMON_2(area) \
EXCEPTION_PROLOG_COMMON_3(n) \
ACCOUNT_STOLEN_TIME
diff --git a/arch/powerpc/include/asm/processor.h b/arch/powerpc/include/asm/processor.h
index 350c584ca179..07251598056c 100644
--- a/arch/powerpc/include/asm/processor.h
+++ b/arch/powerpc/include/asm/processor.h
@@ -32,9 +32,9 @@
/* Default SMT priority is set to 3. Use 11- 13bits to save priority. */
#define PPR_PRIORITY 3
#ifdef __ASSEMBLY__
-#define INIT_PPR (PPR_PRIORITY << 50)
+#define DEFAULT_PPR (PPR_PRIORITY << 50)
#else
-#define INIT_PPR ((u64)PPR_PRIORITY << 50)
+#define DEFAULT_PPR ((u64)PPR_PRIORITY << 50)
#endif /* __ASSEMBLY__ */
#endif /* CONFIG_PPC64 */
@@ -247,7 +247,11 @@ struct thread_struct {
#ifdef CONFIG_PPC64
unsigned long ksp_vsid;
#endif
- struct pt_regs *regs; /* Pointer to saved register state */
+ union {
+ struct int_regs *iregs; /* Pointer to saved register state */
+ struct pt_regs *regs; /* Pointer to saved register state */
+ };
+
mm_segment_t addr_limit; /* for get_fs() validation */
#ifdef CONFIG_BOOKE
/* BookE base exception scratch space; align on cacheline */
@@ -342,7 +346,6 @@ struct thread_struct {
* onwards.
*/
int dscr_inherit;
- unsigned long ppr; /* used to save/restore SMT priority */
unsigned long tidr;
#endif
#ifdef CONFIG_PPC_BOOK3S_64
@@ -390,7 +393,6 @@ struct thread_struct {
.regs = (struct pt_regs *)INIT_SP - 1, /* XXX bogus, I think */ \
.addr_limit = KERNEL_DS, \
.fpexc_mode = 0, \
- .ppr = INIT_PPR, \
.fscr = FSCR_TAR | FSCR_EBB \
}
#endif
diff --git a/arch/powerpc/include/asm/ptrace.h b/arch/powerpc/include/asm/ptrace.h
index 1a98cd8c49f6..9a5a1cc85bd0 100644
--- a/arch/powerpc/include/asm/ptrace.h
+++ b/arch/powerpc/include/asm/ptrace.h
@@ -78,6 +78,7 @@
struct int_regs {
/* pt_regs must be offset 0 so r1 + STACK_FRAME_OVERHEAD points to it */
struct pt_regs pt_regs;
+ unsigned long ppr;
};
#define GET_IP(regs) ((regs)->nip)
diff --git a/arch/powerpc/kernel/asm-offsets.c b/arch/powerpc/kernel/asm-offsets.c
index 8db740a3a8c7..32908a08908b 100644
--- a/arch/powerpc/kernel/asm-offsets.c
+++ b/arch/powerpc/kernel/asm-offsets.c
@@ -88,7 +88,6 @@ int main(void)
#ifdef CONFIG_PPC64
DEFINE(SIGSEGV, SIGSEGV);
DEFINE(NMI_MASK, NMI_MASK);
- OFFSET(TASKTHREADPPR, task_struct, thread.ppr);
#else
OFFSET(THREAD_INFO, task_struct, stack);
DEFINE(THREAD_INFO_GAP, _ALIGN_UP(sizeof(struct thread_info), 16));
@@ -274,6 +273,7 @@ int main(void)
/* Create extra stack space for SRR0 and SRR1 when calling prom/rtas. */
DEFINE(PROM_FRAME_SIZE, STACK_FRAME_OVERHEAD + sizeof(struct int_regs) + 16);
DEFINE(RTAS_FRAME_SIZE, STACK_FRAME_OVERHEAD + sizeof(struct int_regs) + 16);
+ STACK_INT_REGS_OFFSET(_PPR, ppr);
#endif /* CONFIG_PPC64 */
STACK_PT_REGS_OFFSET(GPR0, gpr[0]);
STACK_PT_REGS_OFFSET(GPR1, gpr[1]);
diff --git a/arch/powerpc/kernel/entry_64.S b/arch/powerpc/kernel/entry_64.S
index 77a888bfcb53..ce448f753d2e 100644
--- a/arch/powerpc/kernel/entry_64.S
+++ b/arch/powerpc/kernel/entry_64.S
@@ -386,10 +386,9 @@ END_FTR_SECTION_IFSET(CPU_FTR_HAS_PPR)
4: /* Anything else left to do? */
BEGIN_FTR_SECTION
- lis r3,INIT_PPR@highest /* Set thread.ppr = 3 */
- ld r10,PACACURRENT(r13)
+ lis r3,DEFAULT_PPR@highest /* Set default PPR */
sldi r3,r3,32 /* bits 11-13 are used for ppr */
- std r3,TASKTHREADPPR(r10)
+ std r3,_PPR(r1)
END_FTR_SECTION_IFSET(CPU_FTR_HAS_PPR)
andi. r0,r9,(_TIF_SYSCALL_DOTRACE|_TIF_SINGLESTEP)
@@ -938,12 +937,6 @@ fast_exception_return:
andi. r0,r3,MSR_RI
beq- .Lunrecov_restore
- /* Load PPR from thread struct before we clear MSR:RI */
-BEGIN_FTR_SECTION
- ld r2,PACACURRENT(r13)
- ld r2,TASKTHREADPPR(r2)
-END_FTR_SECTION_IFSET(CPU_FTR_HAS_PPR)
-
/*
* Clear RI before restoring r13. If we are returning to
* userspace and we take an exception after restoring r13,
@@ -964,7 +957,9 @@ END_FTR_SECTION_IFSET(CPU_FTR_HAS_PPR)
andi. r0,r3,MSR_PR
beq 1f
BEGIN_FTR_SECTION
- mtspr SPRN_PPR,r2 /* Restore PPR */
+ /* Restore PPR */
+ ld r2,_PPR(r1)
+ mtspr SPRN_PPR,r2
END_FTR_SECTION_IFSET(CPU_FTR_HAS_PPR)
ACCOUNT_CPU_USER_EXIT(r13, r2, r4)
REST_GPR(13, r1)
diff --git a/arch/powerpc/kernel/process.c b/arch/powerpc/kernel/process.c
index 532e9a83e526..18a14fb8f759 100644
--- a/arch/powerpc/kernel/process.c
+++ b/arch/powerpc/kernel/process.c
@@ -1711,7 +1711,7 @@ int copy_thread(unsigned long clone_flags, unsigned long usp,
p->thread.dscr = mfspr(SPRN_DSCR);
}
if (cpu_has_feature(CPU_FTR_HAS_PPR))
- p->thread.ppr = INIT_PPR;
+ childregs->ppr = DEFAULT_PPR;
p->thread.tidr = 0;
#endif
diff --git a/arch/powerpc/kernel/ptrace.c b/arch/powerpc/kernel/ptrace.c
index 9667666eb18e..57c04176f686 100644
--- a/arch/powerpc/kernel/ptrace.c
+++ b/arch/powerpc/kernel/ptrace.c
@@ -1609,7 +1609,7 @@ static int ppr_get(struct task_struct *target,
void *kbuf, void __user *ubuf)
{
return user_regset_copyout(&pos, &count, &kbuf, &ubuf,
- &target->thread.ppr, 0, sizeof(u64));
+ &target->thread.iregs->ppr, 0, sizeof(u64));
}
static int ppr_set(struct task_struct *target,
@@ -1618,7 +1618,7 @@ static int ppr_set(struct task_struct *target,
const void *kbuf, const void __user *ubuf)
{
return user_regset_copyin(&pos, &count, &kbuf, &ubuf,
- &target->thread.ppr, 0, sizeof(u64));
+ &target->thread.iregs->ppr, 0, sizeof(u64));
}
static int dscr_get(struct task_struct *target,
--
2.18.0
^ permalink raw reply related
* [PATCH 3/4] powerpc/64s/hash: Fix preloading of SLB entries
From: Nicholas Piggin @ 2018-09-28 16:00 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Aneesh Kumar K . V, Nicholas Piggin
In-Reply-To: <20180928160058.18700-1-npiggin@gmail.com>
slb_setup_new_exec and preload_new_slb_context assumed if an address
missed the preload cache, then it would not be in the SLB and could
be added. This is wrong if the preload cache has started to overflow.
This can cause SLB multi-hits on user addresses.
That assumption came from an earlier version of the patch which
cleared the preload cache when copying the task, but even that was
technically wrong because some user accesses occur before these
preloads, and the preloads themselves could overflow the cache
depending on the size.
Fixes: 89ca4e126a3f ("powerpc/64s/hash: Add a SLB preload cache")
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
---
arch/powerpc/mm/slb.c | 11 +++++++++++
1 file changed, 11 insertions(+)
diff --git a/arch/powerpc/mm/slb.c b/arch/powerpc/mm/slb.c
index b438220c4336..c1425853af5d 100644
--- a/arch/powerpc/mm/slb.c
+++ b/arch/powerpc/mm/slb.c
@@ -311,6 +311,13 @@ void slb_setup_new_exec(void)
struct mm_struct *mm = current->mm;
unsigned long exec = 0x10000000;
+ /*
+ * preload cache can only be used to determine whether a SLB
+ * entry exists if it does not start to overflow.
+ */
+ if (ti->slb_preload_nr + 2 > SLB_PRELOAD_NR)
+ return;
+
/*
* We have no good place to clear the slb preload cache on exec,
* flush_thread is about the earliest arch hook but that happens
@@ -345,6 +352,10 @@ void preload_new_slb_context(unsigned long start, unsigned long sp)
struct mm_struct *mm = current->mm;
unsigned long heap = mm->start_brk;
+ /* see above */
+ if (ti->slb_preload_nr + 3 > SLB_PRELOAD_NR)
+ return;
+
/* Userspace entry address. */
if (!is_kernel_addr(start)) {
if (preload_add(ti, start))
--
2.18.0
^ permalink raw reply related
* [PATCH 4/4] powerpc/64s/hash: add more barriers for slb preloading
From: Nicholas Piggin @ 2018-09-28 16:00 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Aneesh Kumar K . V, Nicholas Piggin
In-Reply-To: <20180928160058.18700-1-npiggin@gmail.com>
In several places, more care has to be taken to prevent compiler or
CPU re-ordering of memory accesses into critical sections that must
not take SLB faults.
Fixes: 5e46e29e6a97 ("powerpc/64s/hash: convert SLB miss handlers to C")
Fixes: 89ca4e126a3f ("powerpc/64s/hash: Add a SLB preload cache")
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
---
arch/powerpc/mm/slb.c | 37 +++++++++++++++++++++++++++++++------
1 file changed, 31 insertions(+), 6 deletions(-)
diff --git a/arch/powerpc/mm/slb.c b/arch/powerpc/mm/slb.c
index c1425853af5d..f93ed8afbac6 100644
--- a/arch/powerpc/mm/slb.c
+++ b/arch/powerpc/mm/slb.c
@@ -344,6 +344,9 @@ void slb_setup_new_exec(void)
if (preload_add(ti, mm->mmap_base))
slb_allocate_user(mm, mm->mmap_base);
}
+
+ /* see switch_slb */
+ asm volatile("isync" : : : "memory");
}
void preload_new_slb_context(unsigned long start, unsigned long sp)
@@ -373,6 +376,9 @@ void preload_new_slb_context(unsigned long start, unsigned long sp)
if (preload_add(ti, heap))
slb_allocate_user(mm, heap);
}
+
+ /* see switch_slb */
+ asm volatile("isync" : : : "memory");
}
@@ -389,6 +395,7 @@ void switch_slb(struct task_struct *tsk, struct mm_struct *mm)
* which would update the slb_cache/slb_cache_ptr fields in the PACA.
*/
hard_irq_disable();
+ asm volatile("isync" : : : "memory");
if (cpu_has_feature(CPU_FTR_ARCH_300)) {
/*
* SLBIA IH=3 invalidates all Class=1 SLBEs and their
@@ -396,7 +403,7 @@ void switch_slb(struct task_struct *tsk, struct mm_struct *mm)
* switch_slb wants. So ARCH_300 does not use the slb
* cache.
*/
- asm volatile("isync ; " PPC_SLBIA(3)" ; isync");
+ asm volatile(PPC_SLBIA(3));
} else {
unsigned long offset = get_paca()->slb_cache_ptr;
@@ -404,7 +411,6 @@ void switch_slb(struct task_struct *tsk, struct mm_struct *mm)
offset <= SLB_CACHE_ENTRIES) {
unsigned long slbie_data = 0;
- asm volatile("isync" : : : "memory");
for (i = 0; i < offset; i++) {
/* EA */
slbie_data = (unsigned long)
@@ -419,7 +425,6 @@ void switch_slb(struct task_struct *tsk, struct mm_struct *mm)
if (!cpu_has_feature(CPU_FTR_ARCH_207S) && offset == 1)
asm volatile("slbie %0" : : "r" (slbie_data));
- asm volatile("isync" : : : "memory");
} else {
struct slb_shadow *p = get_slb_shadow();
unsigned long ksp_esid_data =
@@ -427,8 +432,7 @@ void switch_slb(struct task_struct *tsk, struct mm_struct *mm)
unsigned long ksp_vsid_data =
be64_to_cpu(p->save_area[KSTACK_INDEX].vsid);
- asm volatile("isync\n"
- PPC_SLBIA(1) "\n"
+ asm volatile(PPC_SLBIA(1) "\n"
"slbmte %0,%1\n"
"isync"
:: "r"(ksp_vsid_data),
@@ -464,6 +468,13 @@ void switch_slb(struct task_struct *tsk, struct mm_struct *mm)
slb_allocate_user(mm, ea);
}
+
+ /*
+ * Synchronize slbmte preloads with possible subsequent user memory
+ * address accesses by the kernel (user mode won't happen until
+ * rfid, which is safe).
+ */
+ asm volatile("isync" : : : "memory");
}
void slb_set_size(u16 size)
@@ -625,6 +636,17 @@ static long slb_insert_entry(unsigned long ea, unsigned long context,
if (!vsid)
return -EFAULT;
+ /*
+ * There must not be a kernel SLB fault in alloc_slb_index or before
+ * slbmte here or the allocation bitmaps could get out of whack with
+ * the SLB.
+ *
+ * User SLB faults or preloads take this path which might get inlined
+ * into the caller, so add compiler barriers here to ensure unsafe
+ * memory accesses do not come between
+ */
+ barrier();
+
index = alloc_slb_index(kernel);
vsid_data = __mk_vsid_data(vsid, ssize, flags);
@@ -633,10 +655,13 @@ static long slb_insert_entry(unsigned long ea, unsigned long context,
/*
* No need for an isync before or after this slbmte. The exception
* we enter with and the rfid we exit with are context synchronizing.
- * Also we only handle user segments here.
+ * User preloads should add isync afterwards in case the kernel
+ * accesses user memory before it returns to userspace with rfid.
*/
asm volatile("slbmte %0, %1" : : "r" (vsid_data), "r" (esid_data));
+ barrier();
+
if (!kernel)
slb_cache_update(esid_data);
--
2.18.0
^ permalink raw reply related
* RE: Many random crashes in 2.2.0 (and previous kernels)
From: frank.pierce @ 2018-09-28 16:27 UTC (permalink / raw)
To: Marcus H. Mendenhall; +Cc: linuxppc-dev
In-Reply-To: <v03110700b2e0568f1bac@[129.59.235.1]>
Yeah thats the problem I have 1MB L2 cache.
Im not sure if it is the cache thats causing me problems,
but it cant be good that its there but not registered.
On 05-Feb-99 Marcus H. Mendenhall wrote:
> OK, I checked. On my machine the cache is fine,
> according to cpuinfo :
>
> here is cat /proc/cpuinfo:
>
> processor : 0
> cpu : 750
> temperature : 0 C
> clock : 300MHz
> revision : 2.2
> bogomips : 601.29
> zero pages : total 0 (0Kb) current: 0 (0Kb) hits: 0/148
> (0%)
> machine : Power Macintosh
> motherboard : AAPL,Gossamer MacRISC
> L2 cache : 1024K unified pipelined-syncro-burst
> memory : 128MB
>
> Does you machine actually have an L2 cache? It seems as
> if the cache
> problem on your PCPro machine may be a red herring with
> respect to the
> crashing.
>
> Has anyone else out these been having this problem? From
> the lack of any
> other responses, it seems that I am almost the only one.
> Are other people
> running on machines similar to this one (rev 2 G3 300
> MHz) successfully? I
> would like some feed back from successes and failures so
> that I can try to
> isolate what it is that is different about my machine and
> poke directly at
> that part of the kernel. The crashes are just infrequent
> enough to make
> debugging difficult (low data rate), but frequent enough
> to make serious
> use difficult.
>
> Thanks.
>
> Marcus Mendenhall
>
>
>>I have had the same craches on a PowerCenterPro. Looking
>>in
>>/proc/cpuinfo I see that the L2 cache is not registered.
>>I
>>was thinking it could have something to do with that
>>since
>>the I have virtually the same system on the pb3400c which
>>works just fine.
>>
>>
>>Im running the 2.2.0 kernel from kernel.org and R5
>>
>>
>>On
>>03-Feb-99 Marcus H. Mendenhall wrote:
>>>
>>> To the list:
>>>
>>> I have been experiencing many random kernel panics in
>>> all
>>> kernels since
>>> sometime around the 2.1.100's. The panics happen at
>>> times of high disk
>>> activity (process creation, termination, system startup
>>> &
>>> shutdown).
>>> Kernels which have exhibited this have been both stock,
>>> precompiled kernels
>>> from samba.anu.edu.au and home built kernels, using
>>> vger
>>> and kernel.org
>>> sources. I have applied Loic Prylli's
>>> arch/ppc/mm/init.c
>>> patch, which made
>>> no obvious difference.
>>>
>>> Here is my system:
>>> PowerMac G3 rev 2 300 MHz, BMAC ethernet, 128 MB RAM,
>>> 64
>>> MB swap, using
>>> internal IDE disk, Mac keyboard, 19" monitor on
>>> ATY,Mach3DUPro display.
>>> The machine shows no signs of instability running
>>> MacOS.
>>>
>>> The errors have happened using older non-fb video and
>>> current fb video,
>>> with or without X running, with or without atalkd &
>>> papd
>>> running.
>>>
>>> The error often occurs as a bad object or bad area
>>> panic.
>>> Often, the bad
>>> object is mm->pgd. For the last few days I have been
>>> looking into the
>>> slices of the kernel from which most of these emanate.
>>> Unfortunately, I
>>> have only collected partial tracebacks since the 180
>>> second autoreboot
>>> doesn't give be time to write everything down. I don't
>>> have another
>>> machine handy to use a serial console. I may have to
>>> lengthen the time
>>> before autoreboot soon. :-(
>>>
>>> One of the faults comes from mm/slab.c kmem_cache_free.
>>> It is called from
>>> mm_put, which is called from release_task. This error
>>> often occurs during
>>> system shutdown. I have turned on debugging features
>>> in
>>> slab.c, but
>>> haven't gotten any useful information from it yet.
>>>
>>> Another, which I generated today while trying to force
>>> crashes with X off
>>> so I could at least see the backtrace, was as quite
>>> interesting. I did
>>> find / -type f -size -50 -exec grep "mm->pgd" \{\} \;
>>> -print
>>> which heavily excercises all kinds of i/o, especially
>>> process creation and
>>> destruction (since every file less than 50 blocks found
>>> launches grep!).
>>> The failure I got while running this generated two
>>> backtraces.
>>>
>>> The first backtrace started in (reading in most-recent
>>> to
>>> older order)
>>> do_rw_proc, to sys_read, to syscall_ret_1, and then
>>> into
>>> user space in grep.
>>>
>>> This backtrace was interrupted by other which went
>>> (same
>>> order)
>>> instruction_dump, bad_page_fault, do_page_fault,
>>> int_return, do_rw_proc,
>>> sys_read, syscall_ret_1, and then again to userland.
>>>
>>> This never happens on my home 7300/180, using the same
>>> kernels, but happens
>>> to frequently on my G3 at work as to make heavy use
>>> very
>>> difficult. I can
>>> certainly use LyX and other "light-duty" programs for
>>> extended periods
>>> without any problem, but as soon as I create a lot of
>>> disk activity and
>>> process creation/destruction activity, the system
>>> melts.
>>>
>>> I have in the past reported much smaller pieces of this
>>> to the group,
>>> thinking it might be related to the old "ide device i/o
>>> slowdown" problem,
>>> or the bad interrupts problem, but I see no sign of
>>> these
>>> happening
>>> (although sometines at the time of the panic, I see a
>>> message something of
>>> order "in interrupt... not syncing". This message is
>>> sufficiently
>>> infrequently observed that I can't provide
>>> furtherinformation on it).
>>>
>>> If anyone else is seeing this kind of behavior, or has
>>> any idea of a
>>> solution, please let me know. At present I have looked
>>> into just about
>>> everything except an exorcist.
>>>
>>> Thanks.
>>>
>>> Marcus Mendenhall
>>>
>>>
>>>
>>>
>>> [[ This message was sent via the linuxppc-user mailing
>>> list. Replies are ]]
>>> [[ not forced back to the list, so be sure to Cc
>>> linuxppc-user if your ]]
>>> [[ reply is of general interest. To unsubscribe from
>>> linuxppc-user, send ]]
>>> [[ the message 'unsubscribe' to
>>> linuxppc-user-request@lists.linuxppc.org ]]
>>
>>----------------------------------
>>E-Mail: frank@cmc.uib.no
>>Phone(Private):55234679
>>Phone(Work):55589279
>>Mob.: 93289455
>>Date: 04-Feb-99
>>Time: 09:10:39
>>
>>This message was sent by XFMail
>>----------------------------------
----------------------------------
E-Mail: frank@cmc.uib.no
Phone(Private):55234679
Phone(Work):55589279
Mob.: 93289455
Date: 01-Jan-04
Time: 02:11:09
This message was sent by XFMail
----------------------------------
[[ This message was sent via the linuxppc-dev mailing list. Replies are ]]
[[ not forced back to the list, so be sure to Cc linuxppc-dev if your ]]
[[ reply is of general interest. To unsubscribe from linuxppc-dev, send ]]
[[ the message 'unsubscribe' to linuxppc-dev-request@lists.linuxppc.org ]]
^ permalink raw reply
* yet another bug in atyfb.c
From: Wulf Hofbauer @ 2018-09-28 16:27 UTC (permalink / raw)
To: linuxppc-dev
ABSTRACT: atyfb.c doesn't work when compiled with gcc-2.95 due to incorrect
inline assembly code.
EXPLANATION: atyfb.c - as of Kernel 2.2.10 - uses the following constructs
for accessing little-endian words in Mach32 controller space:
asm("lwbrx %0,%1,%2" : "=r"(val) : "r" (regindex), "r" (temp));
and
asm("stwbrx %0,%1,%2" : : "r" (val), "r" (regindex), "r" (temp) :
"memory");
This is meant to access a word at address regindex+temp. If regindex
happens to be held in register r0, the address calculation is off as
r0 is defined as a null operand. This problem shows up with gcc-2.95 which
seems to use better register allocation code and _does_ keep regindex in
r0 at times.
The way of how the respective functions aty_ld_le32 and aty_st_le32
seems also strange to me, and I suspect it is incorrect.
Here's a proposed fix that works for me. I also changed the sparc code
to honour volatility of IO space, but couldn't check if this affects
the kernel. It would be nice if someone familiar with sparc could have a
look at this.
Here's the fix:
--- atyfb.c.orig Wed Jul 21 00:04:40 1999
+++ atyfb.c Tue Aug 3 12:13:42 1999
@@ -466,18 +466,18 @@
};
-static inline u32 aty_ld_le32(volatile unsigned int regindex,
+static inline u32 aty_ld_le32(unsigned int regindex,
const struct fb_info_aty *info)
{
unsigned long temp;
u32 val;
#if defined(__powerpc__)
- temp = info->ati_regbase;
- asm("lwbrx %0,%1,%2" : "=r"(val) : "r" (regindex), "r" (temp));
+ temp = info->ati_regbase+regindex;
+ asm("lwbrx %0,0,%1" : "=r" (val) : "r" ((volatile u32*)temp), "m" (*(volatile u32*)temp));
#elif defined(__sparc_v9__)
temp = info->ati_regbase + regindex;
- asm("lduwa [%1] %2, %0" : "=r" (val) : "r" (temp), "i" (ASI_PL));
+ asm("lduwa [%1] %2, %0" : "=r" (val) : "r" ((volatile u32*)temp), "i" (ASI_PL));
#else
temp = info->ati_regbase+regindex;
val = le32_to_cpu(*((volatile u32 *)(temp)));
@@ -485,18 +485,17 @@
return val;
}
-static inline void aty_st_le32(volatile unsigned int regindex, u32 val,
+static inline void aty_st_le32(unsigned int regindex, u32 val,
const struct fb_info_aty *info)
{
unsigned long temp;
#if defined(__powerpc__)
- temp = info->ati_regbase;
- asm("stwbrx %0,%1,%2" : : "r" (val), "r" (regindex), "r" (temp) :
- "memory");
+ temp = info->ati_regbase+regindex;
+ asm("stwbrx %1,0,%2" : "=m" (*(volatile u32*)temp) : "r" (val) , "r" ((volatile u32*)temp));
#elif defined(__sparc_v9__)
temp = info->ati_regbase + regindex;
- asm("stwa %0, [%1] %2" : : "r" (val), "r" (temp), "i" (ASI_PL) : "memory");
+ asm("stwa %0, [%1] %2" : : "r" (val), "r" ((volatile u32*)temp), "i" (ASI_PL) : "memory");
#else
temp = info->ati_regbase+regindex;
*((volatile u32 *)(temp)) = cpu_to_le32(val);
- Wulf
--
________________________________________________________
! Dipl. Phys. Wulf Hofbauer (wh@echo.chem.tu-berlin.de) !
! Max-Volmer-Institut Technische Universitaet Berlin !
! Strasse des 17. Juni 135 10623 Berlin Germany !
!________________________________________________________!
[[ This message was sent via the linuxppc-dev mailing list. Replies are ]]
[[ not forced back to the list, so be sure to Cc linuxppc-dev if your ]]
[[ reply is of general interest. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting. ]]
^ permalink raw reply
* EP8260
From: deepesh @ 2018-09-28 16:27 UTC (permalink / raw)
To: wd; +Cc: linuxppc-dev
Hi,
I am having an EP8260 Board. The board comes with a PlanetCore BootLoader
and a diagnostics. I want to boot kernel using this bootloader. TimeSys
people claim to have released a kernel binary for EP8260. I am not able to
boot this kernel. What is clear is that the board info structure is passed
correctly from the planetcore boot loader to the kernel arch/ppc/boot/.
This is because I found that the decompress_kernel function is working. I
dumped the first few bytes of memory, starting at 0(zero). They are exactly
same as the "dissembled vmlinux".
But there is a problem in entering from the arch/ppc/boot code to
arch/ppc/kernel code. The board goes for a reset.
Kindly help.
Please give me a reference to a kernel which would come up with this
bootloader(PlanetCore)
Thank you,
Deepesh
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
^ permalink raw reply
* EP8260
From: deepesh @ 2018-09-28 16:27 UTC (permalink / raw)
To: linuxppc-dev
Hi,
I loaded my EP8260 board with UBOOT. This was working fine. Then I loaded a
binary into RAM using tftp. Then tried copying the stuff to flash. When I could
not copy things into flash directly, I erased a few sectors randomly and then
copied the binary to flash. Then when I reset the board, it did not come up.
I put back the u-boot into the flash using BDI2000. But now I am getting weird
characters on the screen. I have looked at the minicom settings-- It is 115200
and 8N1. These were the settings with which I was working before also. What I am
not able to understand is the reason for the weird characters.
I am attaching the weird character file. The last line seems to be the U-BOOT
prompt. I tried changing the TERMINAL SETTINGS to ANSI from VT100, but it did
not help.
------------------------------------------------------------------------
?åêáó`*m,ïïô`0nsnp`hSõì rr`r0ps`m@qrzs2zrvi
??fxrv0`?åóåô`?ôáôõóz@?øôåòîáì`?ïæôl ?øôåòîáì`Èáòä
??fxrvp fìïãë`fïîæéçõòáôéïî
`m`,õómôïmfïòå`?õìô`snuøl`-f?`?éö rl`v0ø`,õó`?òåñ``sp-xu`l fïòå ?òåñ qppm3pp
`m`äæâòç`q,`ãïòåãîæ`0øqål`âõóäæ`rl`ãðíäæ`ql`ðììäæ`ql`ðììíæ`r
`m`öãïYïõô``qyxppp0ppl`óããYãìë```tyupppppl`âòçYãìë```1rswup0p
`m`ãðõYãìë` rsqpppppp,`ãðíYãìë`@`yyp0ppppL`âõóYãìë```vvp0pppp
f?*z`` ??fxrvp`h?åö`q4l`?áóë`?n0h?i`r<ru?)`áô`2sq`?Èú
,ïáòäz ?íâåääåä`?ìáîåô`??x2vpl`?åöéóéïî`p.p
?2fz`` òåáäù
????z `vt`?,
????^:`qv ?,
jjj`-áòîéîç`m`âáä`f?fl`õóéîç`äåæáõìô`åîöéòïîíåîô
?îz` ``óåòéáì
?õôz ``óåòéáì
?òòz ``óåòéáì
?Åôz```?ffs`??^?????
,??,*?zòåÁäù
}~`
--------------------------------------------------------------------------
Thank you,
Deepesh
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
^ permalink raw reply
* problems in SCC-UART in mpc860
From: nbasker @ 2018-09-28 16:27 UTC (permalink / raw)
To: linuxppc-embedded
Hi:
I am trying to use a SCC configured in UART to communicate with a intel
pc via modem. The configuration is simple and shown below
target --- modem -------phoneline---- modem----i386pc
target configuration:
1. mpc860T custom board
2. scc2 configured in uart
3. linux-2-2-14 from montavista
4. patched 8xx_io/uart.c from 2.2.4 kernel from Denks
5. using mgetty/pppd to program modem and start pppd.
host configuration:
1. i368pc running 2.2.14-12 redhat kernel
2. using pppd/chat to dialup to target modem.
In this setup if use PCSO to enable RTS, CTS and CD along with
crtscts option in pppd nothing works. If I disable PCSO and use
nocrtscts option in pppd, LCP connection goes through but IPCP
exchange at target fails (it never sends ConfigAck packet towards host).
I am able to get the setup working using null modem cable enabling
RTS/CTS/CD via PCSO register as well as pppd options.
Since I am able to get SCC2/UART working with nullmodem, but not
with actual modem, should I suspect hardware signal connectivity as
a problem source?. I suspected the uart driver and went through
all the register settings described in Section 23.21 of 860T user
manual and everything seems to be fine.
Any hint or help on this issue will be greatly appreciated.
Thanks for your time,
Nicholas.
-------------------------------------------------
This mail sent through Tejasnetworks Webclient
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
^ permalink raw reply
* Re: problems in SCC-UART in mpc860
From: nbasker @ 2018-09-28 16:27 UTC (permalink / raw)
To: Paul Ruhland, mgreer; +Cc: linuxppc-embedded
In-Reply-To: <200307012248.13130.pruhland@rochester.rr.com>
Hi:
The PVR of my mpc860 says 0x00500000. I tried to
rearrange the BRGs assigned to SMCs and SCCs that I am using from
SMC1 - BRG2 (console)
SCC1 - BRG1 (hdlc)
SCC2 - BRG4 (uart)
to
SMC1 - BRG1 (console)
SCC1 - BRG1 (hdlc)
SCC2 - BRG3 (uart)
This kind of got me further ahead. Now I am able to ping (inconsistently)
via the connection, still my CTS/RTS/CD are disabled. After working for
sometime, modem hangsup and I have to reconnect to get it working again.
I am not able to explain why it was not working in the previous configuration
and why it works (though not completely) with the change. Any hints would be
helpful. Thanks.
Nicholas.
Quoting Paul Ruhland <pruhland@rochester.rr.com>:
>
> You stated you have the SCC UART CD enabled so this may be your initial
> problem.
>
> With CD enabled, SCC UART will not receive unless CD is asserted.
> Typically,
> a modem will not assert CD until it is connected and gets an aswer tone.
> Therefore, you will not be able to communicate with the modem to configure
> it
> and tell it to dial.
>
> Try enabling RTS and CTS but not CD. This may get you farther along.
>
>
> On Tuesday 01 July 2003 10:46 am, nbasker@india.tejasnetworks.com wrote:
> > Hi:
> >
> > I am trying to use a SCC configured in UART to communicate with a intel
> > pc via modem. The configuration is simple and shown below
> >
> > target --- modem -------phoneline---- modem----i386pc
> >
> > target configuration:
> > 1. mpc860T custom board
> > 2. scc2 configured in uart
> > 3. linux-2-2-14 from montavista
> > 4. patched 8xx_io/uart.c from 2.2.4 kernel from Denks
> > 5. using mgetty/pppd to program modem and start pppd.
> >
> > host configuration:
> > 1. i368pc running 2.2.14-12 redhat kernel
> > 2. using pppd/chat to dialup to target modem.
> >
> > In this setup if use PCSO to enable RTS, CTS and CD along with
> > crtscts option in pppd nothing works. If I disable PCSO and use
> > nocrtscts option in pppd, LCP connection goes through but IPCP
> > exchange at target fails (it never sends ConfigAck packet towards host).
> >
> > I am able to get the setup working using null modem cable enabling
> > RTS/CTS/CD via PCSO register as well as pppd options.
> >
> > Since I am able to get SCC2/UART working with nullmodem, but not
> > with actual modem, should I suspect hardware signal connectivity as
> > a problem source?. I suspected the uart driver and went through
> > all the register settings described in Section 23.21 of 860T user
> > manual and everything seems to be fine.
> >
> > Any hint or help on this issue will be greatly appreciated.
> >
> > Thanks for your time,
> > Nicholas.
> >
> > -------------------------------------------------
> > This mail sent through Tejasnetworks Webclient
> >
> >
>
>
>
>
-------------------------------------------------
This mail sent through Tejasnetworks Webclient
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
^ permalink raw reply
* Fwd: Problems in booting kernel from bootloader.
From: nbasker @ 2018-09-28 16:27 UTC (permalink / raw)
To: linuxppc-embedded
Hi,
I am having an EP8260 board. And I got a zImage binary from TimeSys
linux(2.4.7). The board comes with a bootloader and diagnostics.
The TimeSys linux gives me a binary called
zImage.initrd.bin-2.4.7-timesys-3.1.180-ep8260.
I am trying to boot the kernel using the bootloader given by the
PlanetCore guys. The kernel was the one which I got from TimeSys. But this
kernel doesn't come up(It hangs).
Then I tried modifying a few lines of
assembly code(arch/ppc/boot/mbx/head_8260.S) to find the problem. The
board always goes for a reset when I run my code. I get the initial prints
regarding the
loaded at: 00800000 0080C27C
relocated to: 00400000 0040C27C
board data at: F0003000 F0003034
relocated to: 0040C148 0040C17C
zimage at: 0080C27C 008C6253
avail ram: 008C7000 04000000
And then the "Uncompress kernel"and "Now booting kernel" prints are seen
and then the board goes for a reset.
The embed_config, decompress_kernel functions are run correctly. I could
come to this conclusion from the dump of the first few bytes of
memory. These were exactly identical to the "disassembled code of
vmlinux".
The head_8260.S is followed by the head.S code in arch/ppc/kernel. What I
found is that I am able to jump to the diagnostics of the PlanetCore just
before entering the "_start" of arch/ppc/kernel. But I am not able to jump
to the diagnostics just after entering the "_start" of the kernel head.S.
How do I debug this problem, I know that the first few bytes of SDRAM are
exactly what was expected. These values I dumped. Then what is the problem
in jumping to that location. With my binary, the board goes for a reset.
Please help.
Nicholas
-------------------------------------------------
This mail sent through Tejasnetworks Webclient
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
^ permalink raw reply
* Problems in the kernel for EP8260 Board.
From: deepesh @ 2018-09-28 16:27 UTC (permalink / raw)
To: linuxppc-embedded
Hi,
I am having an EP8260 Board. And the linux I am using is from TimeSys.
I made a gzipped ramdisk.image.gz. Following are the last few lines
before the board hung.
TCP: Hash tables configured (established 128 bind 210)
NET4: Unix domain sockets 1.0/SMP for Linux NET4.0.
RAMDISK: Compressed image found at block 0
Freeing initrd memory: 4389k freed
EXT2-fs warning: checktime reached, running e2fsck is recommended
VFS: Mounted root (ext2 filesystem).
Mounted devfs on /äv
Root-NFS: No NFS server available, giving up.
VFS: Unable to mount root fs via NFS, trying floppy.
modprobe: modprobe: Can't open dependencies file
/lib/modules/2.4.7-timesys-3.1.180/modules.dep
(N
)
Thank you,
Deepesh
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
^ permalink raw reply
* _PAGE_WRITETHRU option in 8xx
From: Anil Giri @ 2018-09-28 16:27 UTC (permalink / raw)
To: linuxppc-embedded
Hi,
I am using linuxppx_2_4_20 from denx and i can;t find the _PAGE_WRITETHRU
option in include/asm-ppc/pgtable.h for 8xx. Is it replaced or ommitted?
Thanks
-Anil
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
^ permalink raw reply
* Re: [PATCH v4 1/2] powerpc/32: add stack protector support
From: Segher Boessenkool @ 2018-09-28 16:26 UTC (permalink / raw)
To: Michael Ellerman; +Cc: Paul Mackerras, linuxppc-dev, linux-kernel
In-Reply-To: <8736ttu6fs.fsf@concordia.ellerman.id.au>
On Fri, Sep 28, 2018 at 10:56:07PM +1000, Michael Ellerman wrote:
> The problem of low entropy at boot on systems without a good hardware
> source is sort of unsolvable.
>
> As you say it's up to the core kernel/random code, we shouldn't be
> trying to do anything tricky in the arch code.
>
> You don't want your system to take 3 hours to boot because it's waiting
> for entropy for the stack canary.
>
> If we can update the canary later once the entropy pool is setup that
> would be ideal.
Yup, I agree with all that.
But we should *also* not say "oh, there may be cases where we cannot
do the right thing, so just do not even try, ever, anywhere".
Segher
^ permalink raw reply
* Re: [PATCH RFC] mm/memory_hotplug: Introduce memory block types
From: Dave Hansen @ 2018-09-28 17:02 UTC (permalink / raw)
To: David Hildenbrand, linux-mm
Cc: Kate Stewart, Rich Felker, linux-ia64, linux-sh, Peter Zijlstra,
Heiko Carstens, Pavel Tatashin, Michal Hocko, Paul Mackerras,
H. Peter Anvin, Rashmica Gupta, K. Y. Srinivasan, Boris Ostrovsky,
linux-s390, Michael Neuling, Stephen Hemminger, Yoshinori Sato,
linux-acpi, Ingo Molnar, xen-devel, Rob Herring, Len Brown,
Fenghua Yu, Stephen Rothwell, mike.travis@hpe.com, Haiyang Zhang,
Dan Williams, Jonathan Neuschäfer, Nicholas Piggin,
Joe Perches, Jérôme Glisse, Mike Rapoport,
Borislav Petkov, Andy Lutomirski, Thomas Gleixner, Joonsoo Kim,
Oscar Salvador, Juergen Gross, Tony Luck, Mathieu Malaterre,
Greg Kroah-Hartman, Rafael J. Wysocki, linux-kernel,
Mauricio Faria de Oliveira, Philippe Ombredanne,
Martin Schwidefsky, devel, Andrew Morton, linuxppc-dev,
Kirill A. Shutemov
In-Reply-To: <20180928150357.12942-1-david@redhat.com>
It's really nice if these kinds of things are broken up. First, replace
the old want_memblock parameter, then add the parameter to the
__add_page() calls.
> +/*
> + * NONE: No memory block is to be created (e.g. device memory).
> + * NORMAL: Memory block that represents normal (boot or hotplugged) memory
> + * (e.g. ACPI DIMMs) that should be onlined either automatically
> + * (memhp_auto_online) or manually by user space to select a
> + * specific zone.
> + * Applicable to memhp_auto_online.
> + * STANDBY: Memory block that represents standby memory that should only
> + * be onlined on demand by user space (e.g. standby memory on
> + * s390x), but never automatically by the kernel.
> + * Not applicable to memhp_auto_online.
> + * PARAVIRT: Memory block that represents memory added by
> + * paravirtualized mechanisms (e.g. hyper-v, xen) that will
> + * always automatically get onlined. Memory will be unplugged
> + * using ballooning, not by relying on the MOVABLE ZONE.
> + * Not applicable to memhp_auto_online.
> + */
> +enum {
> + MEMORY_BLOCK_NONE,
> + MEMORY_BLOCK_NORMAL,
> + MEMORY_BLOCK_STANDBY,
> + MEMORY_BLOCK_PARAVIRT,
> +};
This does not seem like the best way to expose these.
STANDBY, for instance, seems to be essentially a replacement for a check
against running on s390 in userspace to implement a _typical_ s390
policy. It seems rather weird to try to make the userspace policy
determination easier by telling userspace about the typical s390 policy
via the kernel.
As for the OOM issues, that sounds like something we need to fix by
refusing to do (or delaying) hot-add operations once we consume too much
ZONE_NORMAL from memmap[]s rather than trying to indirectly tell
userspace to hurry thing along.
So, to my eye, we need:
+enum {
+ MEMORY_BLOCK_NONE,
+ MEMORY_BLOCK_STANDBY, /* the default */
+ MEMORY_BLOCK_AUTO_ONLINE,
+};
and we can probably collapse NONE into AUTO_ONLINE because userspace
ends up doing the same thing for both: nothing.
> struct memory_block {
> unsigned long start_section_nr;
> unsigned long end_section_nr;
> @@ -34,6 +58,7 @@ struct memory_block {
> int (*phys_callback)(struct memory_block *);
> struct device dev;
> int nid; /* NID for this memory block */
> + int type; /* type of this memory block */
> };
Shouldn't we just be creating and using an actual named enum type?
^ permalink raw reply
* Re: [PATCH v3 6/9] kbuild: consolidate Devicetree dtb build rules
From: Andreas Färber @ 2018-09-28 17:21 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Linux MIPS Mailing List, linux-xtensa, Will Deacon, Max Filippov,
Paul Mackerras, Frank Rowand, Rob Herring, Yoshinori Sato,
Russell King, ley.foon.tan, Catalin Marinas, James Hogan, arcml,
H8/300 ARCHITECTURE, devicetree, linux-kbuild, Linux ARM,
Chris Zankel, Michal Simek, Michal Marek, Masahiro Yamada,
Vineet Gupta, Linux Kernel Mailing List, Ralf Baechle,
Paul Burton, nios2-dev, linuxppc-dev
In-Reply-To: <CAMuHMdWEnoh97_jiDWMq=ke4PrhSFbToYnx91CPLBuq3mOGzoQ@mail.gmail.com>
Hi Geert,
Am 13.09.18 um 17:51 schrieb Geert Uytterhoeven:
> On Wed, Sep 12, 2018 at 3:02 AM Masahiro Yamada
> <yamada.masahiro@socionext.com> wrote:
>> Even x86 can enable OF and OF_UNITTEST.
>>
>> Another solution might be,
>> guard it by 'depends on ARCH_SUPPORTS_OF'.
>>
>> This is actually what ACPI does.
>>
>> menuconfig ACPI
>> bool "ACPI (Advanced Configuration and Power Interface) Support"
>> depends on ARCH_SUPPORTS_ACPI
>> ...
>
> ACPI is a real platform feature, as it depends on firmware.
>
> CONFIG_OF can be enabled, and DT overlays can be loaded, on any platform,
> even if it has ACPI ;-)
How would loading a DT overlay work on an ACPI platform? I.e., what
would it overlay against and how to practically load such a file?
I wonder whether that could be helpful for USB devices and serdev...
Cheers,
Andreas
--
SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)
^ permalink raw reply
* Re: [PATCH -next] PCI: hotplug: Use kmemdup rather than duplicating its implementation in pnv_php_add_devtree()
From: Bjorn Helgaas @ 2018-09-28 17:29 UTC (permalink / raw)
To: YueHaibing
Cc: kernel-janitors, Paul Mackerras, linux-pci, Bjorn Helgaas,
linuxppc-dev
In-Reply-To: <1538031141-138417-1-git-send-email-yuehaibing@huawei.com>
On Thu, Sep 27, 2018 at 06:52:21AM +0000, YueHaibing wrote:
> Use kmemdup rather than duplicating its implementation
>
> Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Applied with Michael's ack to pci/hotplug for v4.20, thanks!
> ---
> drivers/pci/hotplug/pnv_php.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/drivers/pci/hotplug/pnv_php.c b/drivers/pci/hotplug/pnv_php.c
> index 5070620..ee54f5b 100644
> --- a/drivers/pci/hotplug/pnv_php.c
> +++ b/drivers/pci/hotplug/pnv_php.c
> @@ -275,14 +275,13 @@ static int pnv_php_add_devtree(struct pnv_php_slot *php_slot)
> goto free_fdt1;
> }
>
> - fdt = kzalloc(fdt_totalsize(fdt1), GFP_KERNEL);
> + fdt = kmemdup(fdt1, fdt_totalsize(fdt1), GFP_KERNEL);
> if (!fdt) {
> ret = -ENOMEM;
> goto free_fdt1;
> }
>
> /* Unflatten device tree blob */
> - memcpy(fdt, fdt1, fdt_totalsize(fdt1));
> dt = of_fdt_unflatten_tree(fdt, php_slot->dn, NULL);
> if (!dt) {
> ret = -EINVAL;
>
>
>
^ permalink raw reply
* Re: [PATCH v3 6/9] kbuild: consolidate Devicetree dtb build rules
From: Rob Herring @ 2018-09-28 18:41 UTC (permalink / raw)
To: Andreas Färber
Cc: Linux-MIPS, linux-xtensa, Will Deacon, Max Filippov,
Paul Mackerras, Frank Rowand, Yoshinori Sato, Russell King,
Ley Foon Tan, Geert Uytterhoeven, Catalin Marinas, James Hogan,
arcml, moderated list:H8/300 ARCHITECTURE, devicetree,
Linux Kbuild mailing list,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE,
Chris Zankel, Michal Simek, Michal Marek, Masahiro Yamada,
Vineet Gupta, linux-kernel@vger.kernel.org, Ralf Baechle,
Paul Burton, nios2-dev, linuxppc-dev
In-Reply-To: <75740733-d0d4-4c0c-838c-f01a5e7291d3@suse.de>
On Fri, Sep 28, 2018 at 12:21 PM Andreas Färber <afaerber@suse.de> wrote:
>
> Hi Geert,
>
> Am 13.09.18 um 17:51 schrieb Geert Uytterhoeven:
> > On Wed, Sep 12, 2018 at 3:02 AM Masahiro Yamada
> > <yamada.masahiro@socionext.com> wrote:
> >> Even x86 can enable OF and OF_UNITTEST.
> >>
> >> Another solution might be,
> >> guard it by 'depends on ARCH_SUPPORTS_OF'.
> >>
> >> This is actually what ACPI does.
> >>
> >> menuconfig ACPI
> >> bool "ACPI (Advanced Configuration and Power Interface) Support"
> >> depends on ARCH_SUPPORTS_ACPI
> >> ...
> >
> > ACPI is a real platform feature, as it depends on firmware.
> >
> > CONFIG_OF can be enabled, and DT overlays can be loaded, on any platform,
> > even if it has ACPI ;-)
>
> How would loading a DT overlay work on an ACPI platform? I.e., what
> would it overlay against and how to practically load such a file?
The DT unittests do just that. I run them on x86 and UM builds. In
this case, the loading source is built-in.
> I wonder whether that could be helpful for USB devices and serdev...
How to load the overlays is pretty orthogonal to the issues to be
solved here. It would certainly be possible to move forward with
prototyping this and just have the overlay built-in. It may not even
need to be an overlay if we can support multiple root nodes.
Rob
^ permalink raw reply
* Re: [PATCH v3 6/6] arm64: dts: add LX2160ARDB board support
From: Li Yang @ 2018-09-28 19:37 UTC (permalink / raw)
To: vabhav.sharma
Cc: Mark Rutland, Kate Stewart, linux-kernel-owner, Catalin Marinas,
Michael Turquette, Will Deacon, yamada.masahiro, Sriram Dash,
linux-clk, udit.kumar, Russell King, Priyanka Jain, Viresh Kumar,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Arnd Bergmann, linux-pm, Scott Wood, Rob Herring, V.Sethi,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE, sboyd,
Greg Kroah-Hartman, Rafael J. Wysocki, lkml, Sudeep Holla,
linuxppc-dev
In-Reply-To: <1537747741-6245-7-git-send-email-vabhav.sharma@nxp.com>
On Mon, Sep 24, 2018 at 7:51 AM Vabhav Sharma <vabhav.sharma@nxp.com> wrote:
>
> LX2160A reference design board (RDB) is a high-performance
> computing, evaluation, and development platform with LX2160A
> SoC.
Please send next version with Shawn Guo and me in the "to" recipient
so that its less likely we will miss it.
>
> Signed-off-by: Priyanka Jain <priyanka.jain@nxp.com>
> Signed-off-by: Sriram Dash <sriram.dash@nxp.com>
> Signed-off-by: Vabhav Sharma <vabhav.sharma@nxp.com>
> ---
> arch/arm64/boot/dts/freescale/Makefile | 1 +
> arch/arm64/boot/dts/freescale/fsl-lx2160a-rdb.dts | 88 +++++++++++++++++++++++
> 2 files changed, 89 insertions(+)
> create mode 100644 arch/arm64/boot/dts/freescale/fsl-lx2160a-rdb.dts
>
> diff --git a/arch/arm64/boot/dts/freescale/Makefile b/arch/arm64/boot/dts/freescale/Makefile
> index 86e18ad..445b72b 100644
> --- a/arch/arm64/boot/dts/freescale/Makefile
> +++ b/arch/arm64/boot/dts/freescale/Makefile
> @@ -13,3 +13,4 @@ dtb-$(CONFIG_ARCH_LAYERSCAPE) += fsl-ls2080a-rdb.dtb
> dtb-$(CONFIG_ARCH_LAYERSCAPE) += fsl-ls2080a-simu.dtb
> dtb-$(CONFIG_ARCH_LAYERSCAPE) += fsl-ls2088a-qds.dtb
> dtb-$(CONFIG_ARCH_LAYERSCAPE) += fsl-ls2088a-rdb.dtb
> +dtb-$(CONFIG_ARCH_LAYERSCAPE) += fsl-lx2160a-rdb.dtb
> diff --git a/arch/arm64/boot/dts/freescale/fsl-lx2160a-rdb.dts b/arch/arm64/boot/dts/freescale/fsl-lx2160a-rdb.dts
> new file mode 100644
> index 0000000..1bbe663
> --- /dev/null
> +++ b/arch/arm64/boot/dts/freescale/fsl-lx2160a-rdb.dts
> @@ -0,0 +1,88 @@
> +// SPDX-License-Identifier: (GPL-2.0 OR MIT)
> +//
> +// Device Tree file for LX2160ARDB
> +//
> +// Copyright 2018 NXP
> +
> +/dts-v1/;
> +
> +#include "fsl-lx2160a.dtsi"
> +
> +/ {
> + model = "NXP Layerscape LX2160ARDB";
> + compatible = "fsl,lx2160a-rdb", "fsl,lx2160a";
> +
> + chosen {
> + stdout-path = "serial0:115200n8";
> + };
> +};
> +
> +&uart0 {
> + status = "okay";
> +};
> +
> +&uart1 {
> + status = "okay";
> +};
> +
> +&i2c0 {
> + status = "okay";
> + i2c-mux@77 {
> + compatible = "nxp,pca9547";
> + reg = <0x77>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + i2c@2 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + reg = <0x2>;
> +
> + power-monitor@40 {
> + compatible = "ti,ina220";
> + reg = <0x40>;
> + shunt-resistor = <1000>;
> + };
> + };
> +
> + i2c@3 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + reg = <0x3>;
> +
> + temperature-sensor@4c {
> + compatible = "nxp,sa56004";
> + reg = <0x4c>;
Need a vcc-supply property according to the binding.
> + };
> +
> + temperature-sensor@4d {
> + compatible = "nxp,sa56004";
> + reg = <0x4d>;
Ditto.
> + };
> + };
> + };
> +};
> +
> +&i2c4 {
> + status = "okay";
> +
> + rtc@51 {
> + compatible = "nxp,pcf2129";
> + reg = <0x51>;
> + // IRQ10_B
> + interrupts = <0 150 0x4>;
> + };
> +
> +};
> +
> +&usb0 {
> + status = "okay";
> +};
> +
> +&usb1 {
> + status = "okay";
> +};
> +
> +&crypto {
> + status = "okay";
> +};
> --
> 2.7.4
>
^ permalink raw reply
* Re: drivers binding to device node with multiple compatible strings
From: Frank Rowand @ 2018-09-28 19:43 UTC (permalink / raw)
To: Li Yang, Rob Herring, Grant Likely,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS, lkml,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE,
linuxppc-dev, Frank Rowand
In-Reply-To: <CADRPPNT0QiBkJtJnxjW95Yf-mirL5OzRrvqj8rC-O8fiz17VnA@mail.gmail.com>
+ Frank
On 09/27/18 15:25, Li Yang wrote:
> Hi Rob and Grant,
>
> Various device tree specs are recommending to include all the
> potential compatible strings in the device node, with the order from
> most specific to most general. But it looks like Linux kernel doesn't
> provide a way to bind the device to the most specific driver, however,
> the first registered compatible driver will be bound.
>
> As more and more generic drivers are added to the Linux kernel, they
> are competing with the more specific vendor drivers and causes problem
> when both are built into the kernel. I'm wondering if there is a
> generic solution (or in plan) to make the most specific driver bound
> to the device. Or we have to disable the more general driver or
> remove the more general compatible string from the device tree?
>
> Regards,
> Leo
>
^ permalink raw reply
* Re: drivers binding to device node with multiple compatible strings
From: Rob Herring @ 2018-09-28 20:07 UTC (permalink / raw)
To: Yang-Leo Li
Cc: devicetree, linuxppc-dev, linux-kernel@vger.kernel.org,
Frank Rowand,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE
In-Reply-To: <CADRPPNT0QiBkJtJnxjW95Yf-mirL5OzRrvqj8rC-O8fiz17VnA@mail.gmail.com>
On Thu, Sep 27, 2018 at 5:25 PM Li Yang <leoyang.li@nxp.com> wrote:
>
> Hi Rob and Grant,
>
> Various device tree specs are recommending to include all the
> potential compatible strings in the device node, with the order from
> most specific to most general. But it looks like Linux kernel doesn't
> provide a way to bind the device to the most specific driver, however,
> the first registered compatible driver will be bound.
>
> As more and more generic drivers are added to the Linux kernel, they
> are competing with the more specific vendor drivers and causes problem
> when both are built into the kernel. I'm wondering if there is a
> generic solution (or in plan) to make the most specific driver bound
> to the device. Or we have to disable the more general driver or
> remove the more general compatible string from the device tree?
It's been a known limitation for a long time. However, in practice it
doesn't seem to be a common problem. Perhaps folks just remove the
less specific compatible from their DT (though that's not ideal). For
most modern bindings, there's so many other resources beyond
compatible (clocks, resets, pinctrl, etc.) that there are few generic
drivers that can work.
I guess if we want to fix this, we'd need to have weighted matching in
the driver core and unbind drivers when we get a better match. Though
it could get messy if the better driver probe fails. Then we've got to
rebind to the original driver.
Do you have a specific case where you hit this?
Rob
^ permalink raw reply
* Re: drivers binding to device node with multiple compatible strings
From: Lucas Stach @ 2018-09-28 20:06 UTC (permalink / raw)
To: Frank Rowand, Li Yang, Rob Herring, Grant Likely,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS, lkml,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE,
linuxppc-dev
In-Reply-To: <ecbf11cd-a140-fe7e-392a-bccbf8224d14@gmail.com>
Hi,
Am Freitag, den 28.09.2018, 12:43 -0700 schrieb Frank Rowand:
> + Frank
>
> On 09/27/18 15:25, Li Yang wrote:
> > Hi Rob and Grant,
> >
> > Various device tree specs are recommending to include all the
> > potential compatible strings in the device node, with the order from
> > most specific to most general. But it looks like Linux kernel doesn't
> > provide a way to bind the device to the most specific driver, however,
> > the first registered compatible driver will be bound.
> >
> > As more and more generic drivers are added to the Linux kernel, they
> > are competing with the more specific vendor drivers and causes problem
> > when both are built into the kernel. I'm wondering if there is a
> > generic solution (or in plan) to make the most specific driver bound
> > to the device. Or we have to disable the more general driver or
> > remove the more general compatible string from the device tree?
Not really contributing to the solution, but the hard question to
answer is when do you know what the most specific driver is? The most
specific driver might well be a module that can be loaded at any time,
while there might already be other less specific drivers around.
In general I would say that if your device is specific enough to
warrant a whole new driver, it should not declare compatibility with
the generic thing in the compatible, but then this is kind of exporting
an Linux implementation detail to DT.
Regards,
Lucas
^ permalink raw reply
* Re: [PATCH -next] powerpc/pseries/memory-hotplug: Fix return value type of find_aa_index
From: Nathan Fontenot @ 2018-09-28 20:25 UTC (permalink / raw)
To: YueHaibing, benh, paulus, mpe; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <20180921103759.24976-1-yuehaibing@huawei.com>
On 09/21/2018 05:37 AM, YueHaibing wrote:
> find_aa_index will return -1 when dlpar_clone_property fails,
> its return value type should be int. Also the caller
> update_lmb_associativity_index should use a int variable to
> get it,then compared with 0.
The aa_index that we are handling here is defined as an unsigned value
in the PAPR so I'm a little hesitant in changing it to a signed value.
Also, changing the aa_index to be signed, we still assign it to the
u32 lmb->aa_index.
There are some other places where the aa_index is treated as a signed value
in finc_aa_index(). Perhaps the better solution is use an rc value to track
the validation of finding the aa_index instead of the aa_index value itself.
-Nathan
>
> Fixes: c05a5a40969e ("powerpc/pseries: Dynamic add entires to associativity lookup array")
> Signed-off-by: YueHaibing <yuehaibing@huawei.com>
> ---
> arch/powerpc/platforms/pseries/hotplug-memory.c | 7 +++----
> 1 file changed, 3 insertions(+), 4 deletions(-)
>
> diff --git a/arch/powerpc/platforms/pseries/hotplug-memory.c b/arch/powerpc/platforms/pseries/hotplug-memory.c
> index 9a15d39..6aad17c 100644
> --- a/arch/powerpc/platforms/pseries/hotplug-memory.c
> +++ b/arch/powerpc/platforms/pseries/hotplug-memory.c
> @@ -101,13 +101,12 @@ static struct property *dlpar_clone_property(struct property *prop,
> return new_prop;
> }
>
> -static u32 find_aa_index(struct device_node *dr_node,
> +static int find_aa_index(struct device_node *dr_node,
> struct property *ala_prop, const u32 *lmb_assoc)
> {
> u32 *assoc_arrays;
> - u32 aa_index;
> int aa_arrays, aa_array_entries, aa_array_sz;
> - int i, index;
> + int i, index, aa_index;
>
> /*
> * The ibm,associativity-lookup-arrays property is defined to be
> @@ -168,7 +167,7 @@ static int update_lmb_associativity_index(struct drmem_lmb *lmb)
> struct device_node *parent, *lmb_node, *dr_node;
> struct property *ala_prop;
> const u32 *lmb_assoc;
> - u32 aa_index;
> + int aa_index;
>
> parent = of_find_node_by_path("/");
> if (!parent)
>
^ 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