* Re: [PATCH 4/4] powerpc: Remove CONFIG_POWER4_ONLY
From: Anton Blanchard @ 2012-04-18 6:51 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, paulus
In-Reply-To: <1334731564.1159.2.camel@pasglop>
Hi Ben,
> So if I remember properly, this means you key off if both
> CPU_FTR_NOEXECUTE and CPU_FTR_NODISRALIGN are clear... is
> there a point ? You make the patch simpler by only keying
> on NO_EXECUTE which afaik is a power4 or later only feature no ?
Was going to do that, but noticed ARCH_V2 was used elsewhere:
arch/powerpc/kernel/sysfs.c: if (cpu_has_feature(CPU_FTR_PPCAS_ARCH_V2))
I'm ok either way, should I respin to use CPU_FTR_NO_EXECUTE?
Anton
^ permalink raw reply
* Re: [PATCH 4/4] powerpc: Remove CONFIG_POWER4_ONLY
From: Benjamin Herrenschmidt @ 2012-04-18 6:46 UTC (permalink / raw)
To: Anton Blanchard; +Cc: linuxppc-dev, paulus
In-Reply-To: <20120418144629.3f02e897@kryten>
On Wed, 2012-04-18 at 14:46 +1000, Anton Blanchard wrote:
> + ALT_FTR_SECTION_END_NESTED_IFCLR((CPU_FTR_PPCAS_ARCH_V2), 487)
So if I remember properly, this means you key off if both
CPU_FTR_NOEXECUTE and CPU_FTR_NODISRALIGN are clear... is
there a point ? You make the patch simpler by only keying
on NO_EXECUTE which afaik is a power4 or later only feature no ?
Cheers,
Ben.
^ permalink raw reply
* Re: PowerPC radeon KMS - is it possible?
From: Michel Dänzer @ 2012-04-18 6:35 UTC (permalink / raw)
To: o jordan; +Cc: linuxppc-dev
In-Reply-To: <BAY163-W54EBB2437ED2068EF5AF5D03F0@phx.gbl>
On Die, 2012-04-17 at 20:49 +0100, o jordan wrote:=20
>=20
> I've been trying to get Kernel Mode Setting working on my iBook with
> Ubuntu 12.04. I can only get it working by forcing PCI mode
> (agpmode=3D-1). Setting agpmode=3D1 or a higher number just results in
> freezing and a flashing screen.
At which point? When radeon KMS initializes, or only when X starts?
> I've tried the Debian experimental kernel with the same results. I
> notice with Fedora 16 they also recommend setting agpmode=3D-1 with a
> radeon card. So I'm guessing there is no easy fix??
Probably not (AGP is flaky in general, but in particular with older
UniNorth bridges), but it might be interesting to see some kernel output
from booting without agpmode=3D-1. If you can't get it via ssh, maybe you
can via netconsole or so.
> With Userspace Mode Setting there is nolonger any 3D hardware
> acceleration
> (https://bugs.launchpad.net/ubuntu/+source/mesa/+bug/946677 )
=46rom the Mesa upstream POV, the drivers from the 7.11 branch could be
used for this.
> CONFIG_DRM_RADEON_KMS=3Dy
> CONFIG_FB_RADEON=3Dy
Not sure it's a good idea to set both of these =3Dy: It will prevent the
radeon driver from initializing at all by default if radeonfb is active.
If you want CONFIG_FB_RADEON=3Dy, I'd suggest leaving
CONFIG_DRM_RADEON_KMS disabled. KMS can always be enabled at boot time
with radeon.modeset=3D1.
> CONFIG_FB_ATY128=3Dy
> CONFIG_FB_ATY=3Dy
There's no KMS for pre-Radeon ATI cards yet, so these are not directly
related.
> I'm not sure if CONFIG_AGP_UNINORTH should be compiled as a module or
> built in. =20
I think it would only need to be built in if the radeon driver was built
in, which is not recommended.
P.S. The dri-devel list at freedesktop.org might be better for this, at
least in addition to linuxppc-dev.
--=20
Earthling Michel D=C3=A4nzer | http://www.amd.c=
om
Libre software enthusiast | Debian, X and DRI developer
^ permalink raw reply
* [PATCH] powerpc: Remove old powerpc specific ptrace getregs/setregs calls
From: Anton Blanchard @ 2012-04-18 5:36 UTC (permalink / raw)
To: benh, paulus; +Cc: linuxppc-dev
PowerPC has non standard getregs calls that only dump the GPRs or
FPRs and have their arguments reversed. commit e17666ba48f7 (ptrace
updates & new, better requests) in 2.6.3 deprecated them and introduced
more standard versions.
It's been about 5 years and I know of no users of the old calls so
lets remove them.
Signed-off-by: Anton Blanchard <anton@samba.org>
---
Index: linux-build/arch/powerpc/include/asm/ptrace.h
===================================================================
--- linux-build.orig/arch/powerpc/include/asm/ptrace.h 2012-04-12 11:36:25.784215556 +1000
+++ linux-build/arch/powerpc/include/asm/ptrace.h 2012-04-12 11:36:48.000619966 +1000
@@ -354,12 +354,6 @@ static inline unsigned long regs_get_ker
#define PTRACE_GETREGS64 22
#define PTRACE_SETREGS64 23
-/* (old) PTRACE requests with inverted arguments */
-#define PPC_PTRACE_GETREGS 0x99 /* Get GPRs 0 - 31 */
-#define PPC_PTRACE_SETREGS 0x98 /* Set GPRs 0 - 31 */
-#define PPC_PTRACE_GETFPREGS 0x97 /* Get FPRs 0 - 31 */
-#define PPC_PTRACE_SETFPREGS 0x96 /* Set FPRs 0 - 31 */
-
/* Calls to trace a 64bit program from a 32bit program */
#define PPC_PTRACE_PEEKTEXT_3264 0x95
#define PPC_PTRACE_PEEKDATA_3264 0x94
Index: linux-build/arch/powerpc/kernel/ptrace.c
===================================================================
--- linux-build.orig/arch/powerpc/kernel/ptrace.c 2012-04-12 11:36:25.796215776 +1000
+++ linux-build/arch/powerpc/kernel/ptrace.c 2012-04-12 11:36:48.004620039 +1000
@@ -1432,40 +1432,6 @@ static long ppc_del_hwdebug(struct task_
#endif
}
-/*
- * Here are the old "legacy" powerpc specific getregs/setregs ptrace calls,
- * we mark them as obsolete now, they will be removed in a future version
- */
-static long arch_ptrace_old(struct task_struct *child, long request,
- unsigned long addr, unsigned long data)
-{
- void __user *datavp = (void __user *) data;
-
- switch (request) {
- case PPC_PTRACE_GETREGS: /* Get GPRs 0 - 31. */
- return copy_regset_to_user(child, &user_ppc_native_view,
- REGSET_GPR, 0, 32 * sizeof(long),
- datavp);
-
- case PPC_PTRACE_SETREGS: /* Set GPRs 0 - 31. */
- return copy_regset_from_user(child, &user_ppc_native_view,
- REGSET_GPR, 0, 32 * sizeof(long),
- datavp);
-
- case PPC_PTRACE_GETFPREGS: /* Get FPRs 0 - 31. */
- return copy_regset_to_user(child, &user_ppc_native_view,
- REGSET_FPR, 0, 32 * sizeof(double),
- datavp);
-
- case PPC_PTRACE_SETFPREGS: /* Set FPRs 0 - 31. */
- return copy_regset_from_user(child, &user_ppc_native_view,
- REGSET_FPR, 0, 32 * sizeof(double),
- datavp);
- }
-
- return -EPERM;
-}
-
long arch_ptrace(struct task_struct *child, long request,
unsigned long addr, unsigned long data)
{
@@ -1687,14 +1653,6 @@ long arch_ptrace(struct task_struct *chi
datavp);
#endif
- /* Old reverse args ptrace callss */
- case PPC_PTRACE_GETREGS: /* Get GPRs 0 - 31. */
- case PPC_PTRACE_SETREGS: /* Set GPRs 0 - 31. */
- case PPC_PTRACE_GETFPREGS: /* Get FPRs 0 - 31. */
- case PPC_PTRACE_SETFPREGS: /* Get FPRs 0 - 31. */
- ret = arch_ptrace_old(child, request, addr, data);
- break;
-
default:
ret = ptrace_request(child, request, addr, data);
break;
Index: linux-build/arch/powerpc/kernel/ptrace32.c
===================================================================
--- linux-build.orig/arch/powerpc/kernel/ptrace32.c 2012-04-12 11:36:25.816216138 +1000
+++ linux-build/arch/powerpc/kernel/ptrace32.c 2012-04-12 11:37:33.725452160 +1000
@@ -39,30 +39,6 @@
* in exit.c or in signal.c.
*/
-/*
- * Here are the old "legacy" powerpc specific getregs/setregs ptrace calls,
- * we mark them as obsolete now, they will be removed in a future version
- */
-static long compat_ptrace_old(struct task_struct *child, long request,
- long addr, long data)
-{
- switch (request) {
- case PPC_PTRACE_GETREGS: /* Get GPRs 0 - 31. */
- return copy_regset_to_user(child,
- task_user_regset_view(current), 0,
- 0, 32 * sizeof(compat_long_t),
- compat_ptr(data));
-
- case PPC_PTRACE_SETREGS: /* Set GPRs 0 - 31. */
- return copy_regset_from_user(child,
- task_user_regset_view(current), 0,
- 0, 32 * sizeof(compat_long_t),
- compat_ptr(data));
- }
-
- return -EPERM;
-}
-
/* Macros to workout the correct index for the FPR in the thread struct */
#define FPRNUMBER(i) (((i) - PT_FPR0) >> 1)
#define FPRHALF(i) (((i) - PT_FPR0) & 1)
@@ -308,8 +284,6 @@ long compat_arch_ptrace(struct task_stru
case PTRACE_SETVSRREGS:
case PTRACE_GETREGS64:
case PTRACE_SETREGS64:
- case PPC_PTRACE_GETFPREGS:
- case PPC_PTRACE_SETFPREGS:
case PTRACE_KILL:
case PTRACE_SINGLESTEP:
case PTRACE_DETACH:
@@ -322,12 +296,6 @@ long compat_arch_ptrace(struct task_stru
ret = arch_ptrace(child, request, addr, data);
break;
- /* Old reverse args ptrace callss */
- case PPC_PTRACE_GETREGS: /* Get GPRs 0 - 31. */
- case PPC_PTRACE_SETREGS: /* Set GPRs 0 - 31. */
- ret = compat_ptrace_old(child, request, addr, data);
- break;
-
default:
ret = compat_ptrace_request(child, request, addr, data);
break;
^ permalink raw reply
* [PATCH] powerpc: Use WARN instead of dump_stack when printing EEH error backtrace
From: Anton Blanchard @ 2012-04-18 5:16 UTC (permalink / raw)
To: benh, paulus, shangw, linuxppc-dev
When we get an EEH error we just print a backtrace with dump_stack
which is rather cryptic. We really should print something before
spewing out the backtrace.
Also switch from dump_stack to WARN so we get more information about
the fail - what modules were loaded, what process was running etc.
This was useful information when debugging a recent EEH subsystem bug.
The standard WARN output should also get picked up by monitoring
tools like kerneloops.
The register dump is of questionable value here but I figured it was
better to use something standard and not roll my own.
Signed-off-by: Anton Blanchard <anton@samba.org>
---
Index: linux-build/arch/powerpc/platforms/pseries/eeh.c
===================================================================
--- linux-build.orig/arch/powerpc/platforms/pseries/eeh.c 2012-04-13 10:29:53.576534339 +1000
+++ linux-build/arch/powerpc/platforms/pseries/eeh.c 2012-04-13 10:51:22.592822459 +1000
@@ -489,7 +489,7 @@ int eeh_dn_check_failure(struct device_n
* a stack trace will help the device-driver authors figure
* out what happened. So print that out.
*/
- dump_stack();
+ WARN(1, "EEH: failure detected\n");
return 1;
dn_unlock:
^ permalink raw reply
* [PATCH 4/4] powerpc: Remove CONFIG_POWER4_ONLY
From: Anton Blanchard @ 2012-04-18 4:46 UTC (permalink / raw)
To: benh, paulus; +Cc: linuxppc-dev
In-Reply-To: <20120418144254.3286ce94@kryten>
Remove CONFIG_POWER4_ONLY, the option is badly named and only does two
things:
- It wraps the MMU segment table code. With feature fixups there is
little downside to compiling this in.
- It uses the newer mtocrf instruction in various assembly functions.
Instead of making this a compile option just do it at runtime via
a feature fixup.
I had to expose CPU_FTR_PPCAS_ARCH_V2 to assembly since I key off
that.
Signed-off-by: Anton Blanchard <anton@samba.org>
---
Index: linux-build/arch/powerpc/configs/g5_defconfig
===================================================================
--- linux-build.orig/arch/powerpc/configs/g5_defconfig 2012-04-18 14:36:40.568207687 +1000
+++ linux-build/arch/powerpc/configs/g5_defconfig 2012-04-18 14:37:46.125376070 +1000
@@ -1,5 +1,4 @@
CONFIG_PPC64=y
-CONFIG_POWER4_ONLY=y
CONFIG_ALTIVEC=y
CONFIG_SMP=y
CONFIG_NR_CPUS=4
Index: linux-build/arch/powerpc/configs/maple_defconfig
===================================================================
--- linux-build.orig/arch/powerpc/configs/maple_defconfig 2012-04-18 14:36:40.556207473 +1000
+++ linux-build/arch/powerpc/configs/maple_defconfig 2012-04-18 14:37:46.125376070 +1000
@@ -1,5 +1,4 @@
CONFIG_PPC64=y
-CONFIG_POWER4_ONLY=y
CONFIG_SMP=y
CONFIG_NR_CPUS=4
CONFIG_EXPERIMENTAL=y
Index: linux-build/arch/powerpc/configs/pasemi_defconfig
===================================================================
--- linux-build.orig/arch/powerpc/configs/pasemi_defconfig 2012-04-18 14:36:40.560207544 +1000
+++ linux-build/arch/powerpc/configs/pasemi_defconfig 2012-04-18 14:37:46.125376070 +1000
@@ -1,5 +1,4 @@
CONFIG_PPC64=y
-CONFIG_POWER4_ONLY=y
CONFIG_ALTIVEC=y
# CONFIG_VIRT_CPU_ACCOUNTING is not set
CONFIG_SMP=y
Index: linux-build/arch/powerpc/kernel/exceptions-64s.S
===================================================================
--- linux-build.orig/arch/powerpc/kernel/exceptions-64s.S 2012-04-18 14:36:40.548207330 +1000
+++ linux-build/arch/powerpc/kernel/exceptions-64s.S 2012-04-18 14:37:46.125376070 +1000
@@ -94,12 +94,10 @@ machine_check_pSeries_1:
data_access_pSeries:
HMT_MEDIUM
SET_SCRATCH0(r13)
-#ifndef CONFIG_POWER4_ONLY
BEGIN_FTR_SECTION
b data_access_check_stab
data_access_not_stab:
END_MMU_FTR_SECTION_IFCLR(MMU_FTR_SLB)
-#endif
EXCEPTION_PROLOG_PSERIES(PACA_EXGEN, data_access_common, EXC_STD,
KVMTEST, 0x300)
@@ -301,7 +299,6 @@ machine_check_fwnmi:
EXC_STD, KVMTEST, 0x200)
KVM_HANDLER_SKIP(PACA_EXMC, EXC_STD, 0x200)
-#ifndef CONFIG_POWER4_ONLY
/* moved from 0x300 */
data_access_check_stab:
GET_PACA(r13)
@@ -328,7 +325,6 @@ do_stab_bolted_pSeries:
GET_SCRATCH0(r10)
std r10,PACA_EXSLB+EX_R13(r13)
EXCEPTION_PROLOG_PSERIES_1(.do_stab_bolted, EXC_STD)
-#endif /* CONFIG_POWER4_ONLY */
KVM_HANDLER_SKIP(PACA_EXGEN, EXC_STD, 0x300)
KVM_HANDLER_SKIP(PACA_EXSLB, EXC_STD, 0x380)
Index: linux-build/arch/powerpc/platforms/Kconfig.cputype
===================================================================
--- linux-build.orig/arch/powerpc/platforms/Kconfig.cputype 2012-04-18 14:36:40.576207829 +1000
+++ linux-build/arch/powerpc/platforms/Kconfig.cputype 2012-04-18 14:37:46.125376070 +1000
@@ -116,15 +116,6 @@ config PPC_BOOK3E
def_bool y
depends on PPC_BOOK3E_64
-config POWER4_ONLY
- bool "Optimize for POWER4"
- depends on PPC64 && PPC_BOOK3S
- default n
- ---help---
- Cause the compiler to optimize for POWER4/POWER5/PPC970 processors.
- The resulting binary will not work on POWER3 or RS64 processors
- when compiled with binutils 2.15 or later.
-
config 6xx
def_bool y
depends on PPC32 && PPC_BOOK3S
Index: linux-build/arch/powerpc/include/asm/asm-compat.h
===================================================================
--- linux-build.orig/arch/powerpc/include/asm/asm-compat.h 2012-04-18 14:36:40.540207188 +1000
+++ linux-build/arch/powerpc/include/asm/asm-compat.h 2012-04-18 14:37:46.125376070 +1000
@@ -29,18 +29,9 @@
#define PPC_LLARX(t, a, b, eh) PPC_LDARX(t, a, b, eh)
#define PPC_STLCX stringify_in_c(stdcx.)
#define PPC_CNTLZL stringify_in_c(cntlzd)
+#define PPC_MTOCRF(FXM, RS) MTOCRF((FXM), (RS))
#define PPC_LR_STKOFF 16
#define PPC_MIN_STKFRM 112
-
-/* Move to CR, single-entry optimized version. Only available
- * on POWER4 and later.
- */
-#ifdef CONFIG_POWER4_ONLY
-#define PPC_MTOCRF stringify_in_c(mtocrf)
-#else
-#define PPC_MTOCRF stringify_in_c(mtcrf)
-#endif
-
#else /* 32-bit */
/* operations for longs and pointers */
Index: linux-build/arch/powerpc/lib/copyuser_64.S
===================================================================
--- linux-build.orig/arch/powerpc/lib/copyuser_64.S 2012-04-18 14:36:40.504206546 +1000
+++ linux-build/arch/powerpc/lib/copyuser_64.S 2012-04-18 14:37:46.125376070 +1000
@@ -30,7 +30,7 @@ _GLOBAL(__copy_tofrom_user_base)
dcbt 0,r4
beq .Lcopy_page_4K
andi. r6,r6,7
- PPC_MTOCRF 0x01,r5
+ PPC_MTOCRF(0x01,r5)
blt cr1,.Lshort_copy
/* Below we want to nop out the bne if we're on a CPU that has the
* CPU_FTR_UNALIGNED_LD_STD bit set and the CPU_FTR_CP_USE_DCBTZ bit
@@ -186,7 +186,7 @@ END_FTR_SECTION_IFCLR(CPU_FTR_UNALIGNED_
blr
.Ldst_unaligned:
- PPC_MTOCRF 0x01,r6 /* put #bytes to 8B bdry into cr7 */
+ PPC_MTOCRF(0x01,r6) /* put #bytes to 8B bdry into cr7 */
subf r5,r6,r5
li r7,0
cmpldi cr1,r5,16
@@ -201,7 +201,7 @@ END_FTR_SECTION_IFCLR(CPU_FTR_UNALIGNED_
2: bf cr7*4+1,3f
37: lwzx r0,r7,r4
83: stwx r0,r7,r3
-3: PPC_MTOCRF 0x01,r5
+3: PPC_MTOCRF(0x01,r5)
add r4,r6,r4
add r3,r6,r3
b .Ldst_aligned
Index: linux-build/arch/powerpc/lib/memcpy_64.S
===================================================================
--- linux-build.orig/arch/powerpc/lib/memcpy_64.S 2012-04-18 14:36:40.512206689 +1000
+++ linux-build/arch/powerpc/lib/memcpy_64.S 2012-04-18 14:37:46.129376142 +1000
@@ -12,7 +12,7 @@
.align 7
_GLOBAL(memcpy)
std r3,48(r1) /* save destination pointer for return value */
- PPC_MTOCRF 0x01,r5
+ PPC_MTOCRF(0x01,r5)
cmpldi cr1,r5,16
neg r6,r3 # LS 3 bits = # bytes to 8-byte dest bdry
andi. r6,r6,7
@@ -154,7 +154,7 @@ END_FTR_SECTION_IFCLR(CPU_FTR_UNALIGNED_
blr
.Ldst_unaligned:
- PPC_MTOCRF 0x01,r6 # put #bytes to 8B bdry into cr7
+ PPC_MTOCRF(0x01,r6) # put #bytes to 8B bdry into cr7
subf r5,r6,r5
li r7,0
cmpldi cr1,r5,16
@@ -169,7 +169,7 @@ END_FTR_SECTION_IFCLR(CPU_FTR_UNALIGNED_
2: bf cr7*4+1,3f
lwzx r0,r7,r4
stwx r0,r7,r3
-3: PPC_MTOCRF 0x01,r5
+3: PPC_MTOCRF(0x01,r5)
add r4,r6,r4
add r3,r6,r3
b .Ldst_aligned
Index: linux-build/arch/powerpc/lib/mem_64.S
===================================================================
--- linux-build.orig/arch/powerpc/lib/mem_64.S 2012-04-18 14:36:40.508206617 +1000
+++ linux-build/arch/powerpc/lib/mem_64.S 2012-04-18 14:37:46.129376142 +1000
@@ -19,7 +19,7 @@ _GLOBAL(memset)
rlwimi r4,r4,16,0,15
cmplw cr1,r5,r0 /* do we get that far? */
rldimi r4,r4,32,0
- PPC_MTOCRF 1,r0
+ PPC_MTOCRF(1,r0)
mr r6,r3
blt cr1,8f
beq+ 3f /* if already 8-byte aligned */
@@ -49,7 +49,7 @@ _GLOBAL(memset)
bdnz 4b
5: srwi. r0,r5,3
clrlwi r5,r5,29
- PPC_MTOCRF 1,r0
+ PPC_MTOCRF(1,r0)
beq 8f
bf 29,6f
std r4,0(r6)
@@ -65,7 +65,7 @@ _GLOBAL(memset)
std r4,0(r6)
addi r6,r6,8
8: cmpwi r5,0
- PPC_MTOCRF 1,r5
+ PPC_MTOCRF(1,r5)
beqlr+
bf 29,9f
stw r4,0(r6)
Index: linux-build/arch/powerpc/include/asm/ppc_asm.h
===================================================================
--- linux-build.orig/arch/powerpc/include/asm/ppc_asm.h 2012-04-18 14:36:40.532207045 +1000
+++ linux-build/arch/powerpc/include/asm/ppc_asm.h 2012-04-18 14:37:46.129376142 +1000
@@ -369,7 +369,15 @@ BEGIN_FTR_SECTION \
END_FTR_SECTION_IFCLR(CPU_FTR_601)
#endif
-
+#ifdef CONFIG_PPC64
+#define MTOCRF(FXM, RS) \
+ BEGIN_FTR_SECTION_NESTED(487); \
+ mtcrf (FXM), (RS); \
+ FTR_SECTION_ELSE_NESTED(487); \
+ mtocrf (FXM), (RS); \
+ ALT_FTR_SECTION_END_NESTED_IFCLR((CPU_FTR_PPCAS_ARCH_V2), 487)
+#endif
+
/*
* This instruction is not implemented on the PPC 603 or 601; however, on
* the 403GCX and 405GP tlbia IS defined and tlbie is not.
Index: linux-build/arch/powerpc/include/asm/cputable.h
===================================================================
--- linux-build.orig/arch/powerpc/include/asm/cputable.h 2012-04-18 14:36:40.520206831 +1000
+++ linux-build/arch/powerpc/include/asm/cputable.h 2012-04-18 14:37:46.129376142 +1000
@@ -203,10 +203,10 @@ extern const char *powerpc_base_platform
#define CPU_FTR_ICSWX LONG_ASM_CONST(0x1000000000000000)
#define CPU_FTR_VMX_COPY LONG_ASM_CONST(0x2000000000000000)
-#ifndef __ASSEMBLY__
-
#define CPU_FTR_PPCAS_ARCH_V2 (CPU_FTR_NOEXECUTE | CPU_FTR_NODSISRALIGN)
+#ifndef __ASSEMBLY__
+
#define MMU_FTR_PPCAS_ARCH_V2 (MMU_FTR_SLB | MMU_FTR_TLBIEL | \
MMU_FTR_16M_PAGE)
^ permalink raw reply
* [PATCH 3/4] powerpc: Add 64-bit CPU targets for gcc
From: Anton Blanchard @ 2012-04-18 4:45 UTC (permalink / raw)
To: benh, paulus; +Cc: linuxppc-dev
In-Reply-To: <20120418144254.3286ce94@kryten>
Add a menu to select various 64-bit CPU targets for gcc. We
default to -mtune=power7 and if gcc doesn't understand that we
fallback to -mtune=power4.
Signed-off-by: Anton Blanchard <anton@samba.org>
---
Index: linux-build/arch/powerpc/Makefile
===================================================================
--- linux-build.orig/arch/powerpc/Makefile 2012-04-18 14:31:31.614666419 +1000
+++ linux-build/arch/powerpc/Makefile 2012-04-18 14:37:08.680708678 +1000
@@ -69,6 +69,16 @@ LDFLAGS_vmlinux := $(LDFLAGS_vmlinux-y)
CFLAGS-$(CONFIG_PPC64) := -mminimal-toc -mtraceback=no -mcall-aixdesc
CFLAGS-$(CONFIG_PPC32) := -ffixed-r2 -mmultiple
+
+CFLAGS-$(CONFIG_GENERIC_CPU) += $(call cc-option,-mtune=power7,-mtune=power4)
+CFLAGS-$(CONFIG_CELL_CPU) += $(call cc-option,-mcpu=cell)
+CFLAGS-$(CONFIG_POWER4_CPU) += $(call cc-option,-mcpu=power4)
+CFLAGS-$(CONFIG_POWER5_CPU) += $(call cc-option,-mcpu=power5)
+CFLAGS-$(CONFIG_POWER6_CPU) += $(call cc-option,-mcpu=power6)
+CFLAGS-$(CONFIG_POWER7_CPU) += $(call cc-option,-mcpu=power7)
+
+CFLAGS-$(CONFIG_TUNE_CELL) += $(call cc-option,-mtune=cell)
+
KBUILD_CPPFLAGS += -Iarch/$(ARCH)
KBUILD_AFLAGS += -Iarch/$(ARCH)
KBUILD_CFLAGS += -msoft-float -pipe -Iarch/$(ARCH) $(CFLAGS-y)
@@ -76,22 +86,11 @@ CPP = $(CC) -E $(KBUILD_CFLAGS)
CHECKFLAGS += -m$(CONFIG_WORD_SIZE) -D__powerpc__ -D__powerpc$(CONFIG_WORD_SIZE)__
-ifeq ($(CONFIG_PPC64),y)
-ifeq ($(CONFIG_POWER4_ONLY),y)
- KBUILD_CFLAGS += $(call cc-option,-mcpu=power4)
-else
- KBUILD_CFLAGS += $(call cc-option,-mtune=power4)
-endif
-endif
-
KBUILD_LDFLAGS_MODULE += arch/powerpc/lib/crtsavres.o
-ifeq ($(CONFIG_TUNE_CELL),y)
- KBUILD_CFLAGS += $(call cc-option,-mtune=cell)
-endif
-
-# No AltiVec instruction when building kernel
+# No AltiVec or VSX instructions when building kernel
KBUILD_CFLAGS += $(call cc-option,-mno-altivec)
+KBUILD_CFLAGS += $(call cc-option,-mno-vsx)
# No SPE instruction when building kernel
# (We use all available options to help semi-broken compilers)
Index: linux-build/arch/powerpc/platforms/Kconfig.cputype
===================================================================
--- linux-build.orig/arch/powerpc/platforms/Kconfig.cputype 2012-04-18 14:31:25.134549903 +1000
+++ linux-build/arch/powerpc/platforms/Kconfig.cputype 2012-04-18 14:36:40.576207829 +1000
@@ -78,6 +78,36 @@ config PPC_BOOK3E_64
endchoice
+choice
+ prompt "CPU selection"
+ depends on PPC64
+ default GENERIC_CPU
+ help
+ This will create a kernel which is optimised for a particular CPU.
+ The resulting kernel may not run on other CPUs, so use this with care.
+
+ If unsure, select Generic.
+
+config GENERIC_CPU
+ bool "Generic"
+
+config CELL_CPU
+ bool "Cell Broadband Engine"
+
+config POWER4_CPU
+ bool "POWER4"
+
+config POWER5_CPU
+ bool "POWER5"
+
+config POWER6_CPU
+ bool "POWER6"
+
+config POWER7_CPU
+ bool "POWER7"
+
+endchoice
+
config PPC_BOOK3S
def_bool y
depends on PPC_BOOK3S_32 || PPC_BOOK3S_64
^ permalink raw reply
* [PATCH 2/4] powerpc: Remove altivec fix for gcc versions before 4.0
From: Anton Blanchard @ 2012-04-18 4:44 UTC (permalink / raw)
To: benh, paulus; +Cc: linuxppc-dev
In-Reply-To: <20120418144254.3286ce94@kryten>
Now we require gcc 4.0 on 64-bit we can remove the pre gcc 4.0
-maltivec workaround.
Signed-off-by: Anton Blanchard <anton@samba.org>
---
Index: linux-build/arch/powerpc/Makefile
===================================================================
--- linux-build.orig/arch/powerpc/Makefile 2012-04-18 07:49:24.024963656 +1000
+++ linux-build/arch/powerpc/Makefile 2012-04-18 11:58:18.278885496 +1000
@@ -77,18 +77,8 @@ CPP = $(CC) -E $(KBUILD_CFLAGS)
CHECKFLAGS += -m$(CONFIG_WORD_SIZE) -D__powerpc__ -D__powerpc$(CONFIG_WORD_SIZE)__
ifeq ($(CONFIG_PPC64),y)
-GCC_BROKEN_VEC := $(call cc-ifversion, -lt, 0400, y)
-
ifeq ($(CONFIG_POWER4_ONLY),y)
-ifeq ($(CONFIG_ALTIVEC),y)
-ifeq ($(GCC_BROKEN_VEC),y)
- KBUILD_CFLAGS += $(call cc-option,-mcpu=970)
-else
- KBUILD_CFLAGS += $(call cc-option,-mcpu=power4)
-endif
-else
KBUILD_CFLAGS += $(call cc-option,-mcpu=power4)
-endif
else
KBUILD_CFLAGS += $(call cc-option,-mtune=power4)
endif
^ permalink raw reply
* [PATCH 1/4] powerpc: Require gcc 4.0 on 64-bit
From: Anton Blanchard @ 2012-04-18 4:42 UTC (permalink / raw)
To: benh, paulus; +Cc: linuxppc-dev
Older versions of gcc had issues with using -maltivec together with
-mcpu of a non altivec capable CPU. We work around it by specifying
-mcpu=970, but the logic is complicated.
In preparation for adding more -mcpu targets, remove the workaround
and just require gcc 4.0 for 64-bit builds.
Signed-off-by: Anton Blanchard <anton@samba.org>
---
4.0 came out in 2005 and the gcc on RHEL5 and SLES10 looks to be 4.1.
I highly doubt a ppc64 kernel will build these days on either RHEL4 or
SLES9.
Anything else we have to worry about?
Index: linux-build/arch/powerpc/Makefile
===================================================================
--- linux-build.orig/arch/powerpc/Makefile 2012-04-18 11:59:31.444220933 +1000
+++ linux-build/arch/powerpc/Makefile 2012-04-18 11:59:58.860721391 +1000
@@ -234,10 +234,11 @@ archprepare: checkbin
# Use the file '.tmp_gas_check' for binutils tests, as gas won't output
# to stdout and these checks are run even on install targets.
TOUT := .tmp_gas_check
-# Ensure this is binutils 2.12.1 (or 2.12.90.0.7) or later for altivec
-# instructions.
-# gcc-3.4 and binutils-2.14 are a fatal combination.
+# Check gcc and binutils versions:
+# - gcc-3.4 and binutils-2.14 are a fatal combination
+# - Require gcc 4.0 or above on 64-bit
+# - gcc-4.2.0 has issues compiling modules on 64-bit
checkbin:
@if test "$(call cc-version)" = "0304" ; then \
if ! /bin/echo mftb 5 | $(AS) -v -mppc -many -o $(TOUT) >/dev/null 2>&1 ; then \
@@ -247,6 +248,12 @@ checkbin:
false; \
fi ; \
fi
+ @if test "$(call cc-version)" -lt "0400" \
+ && test "x${CONFIG_PPC64}" = "xy" ; then \
+ echo -n "Sorry, GCC v4.0 or above is required to build " ; \
+ echo "the 64-bit powerpc kernel." ; \
+ false ; \
+ fi
@if test "$(call cc-fullversion)" = "040200" \
&& test "x${CONFIG_MODULES}${CONFIG_PPC64}" = "xyy" ; then \
echo -n '*** GCC-4.2.0 cannot compile the 64-bit powerpc ' ; \
^ permalink raw reply
* Re: [PATCH] powerpc/eeh: crash caused by null eeh_dev
From: Anton Blanchard @ 2012-04-18 1:16 UTC (permalink / raw)
To: Gavin Shan; +Cc: linuxppc-dev
In-Reply-To: <1334642139-25447-1-git-send-email-shangw@linux.vnet.ibm.com>
Hi Gavin,
> The problem was reported by Anton Blanchard. While EEH error
> happened to the PCI device without the corresponding device
> driver, kernel crash was seen. Eventually, I successfully
> reproduced the problem on Firebird-L machine with utility
> "errinjct". Initially, the device driver for Emulex ethernet
> MAC has been disabled from .config and force data parity on
> the Emulex ethernet MAC with help of "errinjct". Eventually,
> I saw the kernel crash after issueing couple of "lspci -v"
> command.
>
> The root cause behind is that the PCI device, including the
> reference to the corresponding eeh device, will be removed
> from the system while EEH does recovery. Afterwards, the
> PCI device will be probed again and added into the system
> accordingly. So it's not safe to retrieve the eeh device from
> the corresponding PCI device after the PCI device has been removed
> and not added again.
>
> The patch fixes the issue and retrieve the eeh device from OF node
> instead of PCI device after the PCI device has been removed.
Thanks, this does fix the oops I see.
Tested-by: Anton Blanchard <anton@samba.org>
Anton
> Signed-off-by: Gavin Shan <shangw@linux.vnet.ibm.com>
> ---
> arch/powerpc/platforms/pseries/eeh.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/arch/powerpc/platforms/pseries/eeh.c
> b/arch/powerpc/platforms/pseries/eeh.c index 309d38e..a75e37d 100644
> --- a/arch/powerpc/platforms/pseries/eeh.c
> +++ b/arch/powerpc/platforms/pseries/eeh.c
> @@ -1076,7 +1076,7 @@ static void eeh_add_device_late(struct pci_dev
> *dev) pr_debug("EEH: Adding device %s\n", pci_name(dev));
>
> dn = pci_device_to_OF_node(dev);
> - edev = pci_dev_to_eeh_dev(dev);
> + edev = of_node_to_eeh_dev(dn);
> if (edev->pdev == dev) {
> pr_debug("EEH: Already referenced !\n");
> return;
^ permalink raw reply
* Re: [PATCH] powerpc/85xx: Add back condition for smp
From: Scott Wood @ 2012-04-17 22:17 UTC (permalink / raw)
To: York Sun; +Cc: PPC list
In-Reply-To: <1334698746-11529-1-git-send-email-yorksun@freescale.com>
On 04/17/2012 04:39 PM, York Sun wrote:
> The timebase synchronization is only necessary if we need to reset a
> separate core. Currently only KEXEC and CPU hotplug require resetting
> a single core. The following code should be in the condition of
> CONFIG_KEXEC or CONFIG_HOTPLUG_CPU
>
> .give_timebase = smp_generic_give_timebase,
> .take_timebase = smp_generic_take_timebase,
>
> Signed-off-by: York Sun <yorksun@freescale.com>
> Acked-by: Li Yang <leoli@freescale.com>
> ---
> arch/powerpc/platforms/85xx/smp.c | 2 ++
> 1 files changed, 2 insertions(+), 0 deletions(-)
>
> diff --git a/arch/powerpc/platforms/85xx/smp.c b/arch/powerpc/platforms/85xx/smp.c
> index 56942af..868c6d7 100644
> --- a/arch/powerpc/platforms/85xx/smp.c
> +++ b/arch/powerpc/platforms/85xx/smp.c
> @@ -192,8 +192,10 @@ struct smp_ops_t smp_85xx_ops = {
> .cpu_disable = generic_cpu_disable,
> .cpu_die = generic_cpu_die,
> #endif
> +#if defined(CONFIG_KEXEC) || defined(CONFIG_HOTPLUG_CPU)
> .give_timebase = smp_generic_give_timebase,
> .take_timebase = smp_generic_take_timebase,
> +#endif
> };
>
> #ifdef CONFIG_KEXEC
Note that this is only a temporary fix, that assumes the environments
where tbsync is problematic[1] (virtualization and simulation) do not
enable CONFIG_KEXEC or CONFIG_HOTPLUG_CPU. Eventually the sync should
be done via CCSR like in U-Boot, and the decision on whether to do it
should be runtime.
-Scott
[1] More so than usual.
^ permalink raw reply
* Re: [EDAC PATCH v13 4/7] edac: move nr_pages to dimm struct
From: Borislav Petkov @ 2012-04-17 21:40 UTC (permalink / raw)
To: Mauro Carvalho Chehab
Cc: Shaohui Xie, Jason Uhlenkott, Hitoshi Mitake, Mark Gross,
Dmitry Eremin-Solenikov, Ranganathan Desikan, Borislav Petkov,
Egor Martovetsky, Niklas Söderlund, Tim Small, Arvind R.,
Chris Metcalf, Olof Johansson, Doug Thompson,
Linux Edac Mailing List, Michal Marek, Jiri Kosina,
Linux Kernel Mailing List, Joe Perches, Andrew Morton,
linuxppc-dev
In-Reply-To: <4F8DC471.3050809@redhat.com>
On Tue, Apr 17, 2012 at 04:28:49PM -0300, Mauro Carvalho Chehab wrote:
> Ok. well, we can either multiply nr_pages by channel_count or to let it
> clear that this is per channel. I prefer the last option (see the enclosed
> patch).
>
> >> @@ -2152,6 +2146,7 @@ static int init_csrows(struct mem_ctl_info *mci)
> >> int i, j, empty = 1;
> >> enum mem_type mtype;
> >> enum edac_type edac_mode;
> >> + int nr_pages;
> >>
> >> amd64_read_pci_cfg(pvt->F3, NBCFG, &val);
> >>
> >> @@ -2174,14 +2169,14 @@ static int init_csrows(struct mem_ctl_info *mci)
> >> i, pvt->mc_node_id);
> >>
> >> empty = 0;
> >> - csrow->nr_pages = amd64_csrow_nr_pages(pvt, 0, i);
> >> + nr_pages = amd64_csrow_nr_pages(pvt, 0, i);
> >> get_cs_base_and_mask(pvt, i, 0, &base, &mask);
> >> /* 8 bytes of resolution */
> >>
> >> mtype = amd64_determine_memory_type(pvt, i);
> >>
> >> debugf1(" for MC node %d csrow %d:\n", pvt->mc_node_id, i);
> >> - debugf1(" nr_pages: %u\n", csrow->nr_pages);
> >> + debugf1(" nr_pages: %u\n", nr_pages);
> >>
> >> /*
> >> * determine whether CHIPKILL or JUST ECC or NO ECC is operating
> >> @@ -2195,6 +2190,7 @@ static int init_csrows(struct mem_ctl_info *mci)
> >> for (j = 0; j < pvt->channel_count; j++) {
> >> csrow->channels[j].dimm->mtype = mtype;
> >> csrow->channels[j].dimm->edac_mode = edac_mode;
> >> + csrow->channels[j].dimm->nr_pages = nr_pages;
> >
> > I'm guessing you want to accumulate the nr_pages for all channels here
> > and dump it properly?
> >
>
> As you've requested to not move the debugf0() to be after the loop, it is
> easier to just multiply it at the printk. As an advantage, when the kernel
> is compiled without debug, no code will be produced.
>
> IMO, the best way to solve it is with this small patch. If you're ok, I'll
> fold it with this one and add your ack.
>
> Regards,
> Mauro
>
> diff --git a/drivers/edac/amd64_edac.c b/drivers/edac/amd64_edac.c
> index 8804ac8..6d6ec68 100644
> --- a/drivers/edac/amd64_edac.c
> +++ b/drivers/edac/amd64_edac.c
> @@ -2127,7 +2127,7 @@ static u32 amd64_csrow_nr_pages(struct amd64_pvt *pvt, u8 dct, int csrow_nr)
> nr_pages = pvt->ops->dbam_to_cs(pvt, dct, cs_mode) << (20 - PAGE_SHIFT);
>
> debugf0(" (csrow=%d) DBAM map index= %d\n", csrow_nr, cs_mode);
> - debugf0(" nr_pages= %u channel-count = %d\n",
> + debugf0(" nr_pages/channel= %u channel-count = %d\n",
> nr_pages, pvt->channel_count);
>
> return nr_pages;
> @@ -2176,7 +2176,7 @@ static int init_csrows(struct mem_ctl_info *mci)
> mtype = amd64_determine_memory_type(pvt, i);
>
> debugf1(" for MC node %d csrow %d:\n", pvt->mc_node_id, i);
> - debugf1(" nr_pages: %u\n", nr_pages);
> + debugf1(" nr_pages: %u\n", nr_pages * pvt->channel_count);
>
> /*
> * determine whether CHIPKILL or JUST ECC or NO ECC is operating
Yeah, this is basically what the code did anyway, so yes, please fold it
in and you can add my ACK. I'll continue reviewing the rest tomorrow.
Thanks.
--
Regards/Gruss,
Boris.
Advanced Micro Devices GmbH
Einsteinring 24, 85609 Dornach
GM: Alberto Bozzo
Reg: Dornach, Landkreis Muenchen
HRB Nr. 43632 WEEE Registernr: 129 19551
^ permalink raw reply
* [PATCH] powerpc/85xx: Add back condition for smp
From: York Sun @ 2012-04-17 21:39 UTC (permalink / raw)
To: linuxppc-dev
The timebase synchronization is only necessary if we need to reset a
separate core. Currently only KEXEC and CPU hotplug require resetting
a single core. The following code should be in the condition of
CONFIG_KEXEC or CONFIG_HOTPLUG_CPU
.give_timebase = smp_generic_give_timebase,
.take_timebase = smp_generic_take_timebase,
Signed-off-by: York Sun <yorksun@freescale.com>
Acked-by: Li Yang <leoli@freescale.com>
---
arch/powerpc/platforms/85xx/smp.c | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/platforms/85xx/smp.c b/arch/powerpc/platforms/85xx/smp.c
index 56942af..868c6d7 100644
--- a/arch/powerpc/platforms/85xx/smp.c
+++ b/arch/powerpc/platforms/85xx/smp.c
@@ -192,8 +192,10 @@ struct smp_ops_t smp_85xx_ops = {
.cpu_disable = generic_cpu_disable,
.cpu_die = generic_cpu_die,
#endif
+#if defined(CONFIG_KEXEC) || defined(CONFIG_HOTPLUG_CPU)
.give_timebase = smp_generic_give_timebase,
.take_timebase = smp_generic_take_timebase,
+#endif
};
#ifdef CONFIG_KEXEC
--
1.7.0.4
^ permalink raw reply related
* PowerPC radeon KMS - is it possible?
From: o jordan @ 2012-04-17 19:49 UTC (permalink / raw)
To: linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 1579 bytes --]
Hi list,
Firstly let me say thanks for the great work you do!!!
I've been trying to get Kernel Mode Setting working on my iBook with Ubuntu 12.04. I can only get it working by forcing PCI mode (agpmode=-1). Setting agpmode=1 or a higher number just results in freezing and a flashing screen. Does anybody know how to get it working fully with agp?
I've tried the Debian experimental kernel with the same results. I notice with Fedora 16 they also recommend setting agpmode=-1 with a radeon card. So I'm guessing there is no easy fix??
I've been trying to sort out the kernel configuration for ati/radeon cards with Ubuntu. I raised a bug to build back in the framebuffers https://bugs.launchpad.net/ubuntu/+source/linux/+bug/949288 . I'd appreciate any help with that bug report.
With Userspace Mode Setting there is nolonger any 3D hardware acceleration (https://bugs.launchpad.net/ubuntu/+source/mesa/+bug/946677 ) so this is why I'm interested in getting KMS working properly. However, some people seem to really want suspend which currently requires radeonfb. So I'm trying to find a kernel configuration that works well for UMS and KMS!!!
This is what I proposed:
CONFIG_DRM_RADEON_KMS=y
CONFIG_FB_RADEON=y
CONFIG_FB_ATY128=y
CONFIG_FB_ATY=y
So people can disable radeonfb from the yaboot prompt/conf if they want fully working KMS. I'm not sure if CONFIG_AGP_UNINORTH should be compiled as a module or built in. We are now in kernel freeze for 12.04 so to get any changes is going to take some serious begging!!!
Cheers
Adam
[-- Attachment #2: Type: text/html, Size: 2180 bytes --]
^ permalink raw reply
* [PATCH 1/2] seccomp: ignore secure_computing return values
From: Will Drewry @ 2012-04-17 19:48 UTC (permalink / raw)
To: jmorris
Cc: linux-mips, linux-sh, Heiko Carstens, David Howells,
Paul Mackerras, Eric Paris, H. Peter Anvin, sparclinux, Kees Cook,
sfr, Richard Weinberger, Avi Kivity, Frederic Weisbecker,
Ingo Molnar, Serge Hallyn, Peter Zijlstra, linux-s390,
microblaze-uclinux, James Morris, Michal Simek, Tony Luck,
Will Drewry, linux-kernel, Ralf Baechle, linux-security-module,
Paul Mundt, Martin Schwidefsky, linux390, linuxppc-dev,
David S. Miller
This change is inspired by
https://lkml.org/lkml/2012/4/16/14
which fixes the build warnings for arches that don't support
CONFIG_HAVE_ARCH_SECCOMP_FILTER.
In particular, there is no requirement for the return value of
secure_computing() to be checked unless the architecture supports
seccomp filter. Instead of silencing the warnings with (void)
a new static inline is added to encode the expected behavior
in a compiler and human friendly way.
v2: - cleans things up with a static inline
- removes sfr's signed-off-by since it is a different approach
v1: - matches sfr's original change
Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: Will Drewry <wad@chromium.org>
Acked-by: Kees Cook <keescook@chromium.org>
---
arch/microblaze/kernel/ptrace.c | 2 +-
arch/mips/kernel/ptrace.c | 2 +-
arch/powerpc/kernel/ptrace.c | 2 +-
arch/s390/kernel/ptrace.c | 2 +-
arch/sh/kernel/ptrace_32.c | 2 +-
arch/sh/kernel/ptrace_64.c | 2 +-
arch/sparc/kernel/ptrace_64.c | 2 +-
include/linux/seccomp.h | 7 +++++++
8 files changed, 14 insertions(+), 7 deletions(-)
diff --git a/arch/microblaze/kernel/ptrace.c b/arch/microblaze/kernel/ptrace.c
index 6eb2aa9..ab1b9db 100644
--- a/arch/microblaze/kernel/ptrace.c
+++ b/arch/microblaze/kernel/ptrace.c
@@ -136,7 +136,7 @@ asmlinkage long do_syscall_trace_enter(struct pt_regs *regs)
{
long ret = 0;
- secure_computing(regs->r12);
+ secure_computing_strict(regs->r12);
if (test_thread_flag(TIF_SYSCALL_TRACE) &&
tracehook_report_syscall_entry(regs))
diff --git a/arch/mips/kernel/ptrace.c b/arch/mips/kernel/ptrace.c
index 7c24c29..4812c6d 100644
--- a/arch/mips/kernel/ptrace.c
+++ b/arch/mips/kernel/ptrace.c
@@ -535,7 +535,7 @@ static inline int audit_arch(void)
asmlinkage void syscall_trace_enter(struct pt_regs *regs)
{
/* do the secure computing check first */
- secure_computing(regs->regs[2]);
+ secure_computing_strict(regs->regs[2]);
if (!(current->ptrace & PT_PTRACED))
goto out;
diff --git a/arch/powerpc/kernel/ptrace.c b/arch/powerpc/kernel/ptrace.c
index 8d8e028..dd5e214 100644
--- a/arch/powerpc/kernel/ptrace.c
+++ b/arch/powerpc/kernel/ptrace.c
@@ -1710,7 +1710,7 @@ long do_syscall_trace_enter(struct pt_regs *regs)
{
long ret = 0;
- secure_computing(regs->gpr[0]);
+ secure_computing_strict(regs->gpr[0]);
if (test_thread_flag(TIF_SYSCALL_TRACE) &&
tracehook_report_syscall_entry(regs))
diff --git a/arch/s390/kernel/ptrace.c b/arch/s390/kernel/ptrace.c
index 02f300f..4993e68 100644
--- a/arch/s390/kernel/ptrace.c
+++ b/arch/s390/kernel/ptrace.c
@@ -719,7 +719,7 @@ asmlinkage long do_syscall_trace_enter(struct pt_regs *regs)
long ret = 0;
/* Do the secure computing check first. */
- secure_computing(regs->gprs[2]);
+ secure_computing_strict(regs->gprs[2]);
/*
* The sysc_tracesys code in entry.S stored the system
diff --git a/arch/sh/kernel/ptrace_32.c b/arch/sh/kernel/ptrace_32.c
index 9698671..81f999a 100644
--- a/arch/sh/kernel/ptrace_32.c
+++ b/arch/sh/kernel/ptrace_32.c
@@ -503,7 +503,7 @@ asmlinkage long do_syscall_trace_enter(struct pt_regs *regs)
{
long ret = 0;
- secure_computing(regs->regs[0]);
+ secure_computing_strict(regs->regs[0]);
if (test_thread_flag(TIF_SYSCALL_TRACE) &&
tracehook_report_syscall_entry(regs))
diff --git a/arch/sh/kernel/ptrace_64.c b/arch/sh/kernel/ptrace_64.c
index bc81e07..af90339 100644
--- a/arch/sh/kernel/ptrace_64.c
+++ b/arch/sh/kernel/ptrace_64.c
@@ -522,7 +522,7 @@ asmlinkage long long do_syscall_trace_enter(struct pt_regs *regs)
{
long long ret = 0;
- secure_computing(regs->regs[9]);
+ secure_computing_strict(regs->regs[9]);
if (test_thread_flag(TIF_SYSCALL_TRACE) &&
tracehook_report_syscall_entry(regs))
diff --git a/arch/sparc/kernel/ptrace_64.c b/arch/sparc/kernel/ptrace_64.c
index 6f97c07..484daba 100644
--- a/arch/sparc/kernel/ptrace_64.c
+++ b/arch/sparc/kernel/ptrace_64.c
@@ -1062,7 +1062,7 @@ asmlinkage int syscall_trace_enter(struct pt_regs *regs)
int ret = 0;
/* do the secure computing check first */
- secure_computing(regs->u_regs[UREG_G1]);
+ secure_computing_strict(regs->u_regs[UREG_G1]);
if (test_thread_flag(TIF_SYSCALL_TRACE))
ret = tracehook_report_syscall_entry(regs);
diff --git a/include/linux/seccomp.h b/include/linux/seccomp.h
index 60f2b35..84f6320d 100644
--- a/include/linux/seccomp.h
+++ b/include/linux/seccomp.h
@@ -75,6 +75,12 @@ static inline int secure_computing(int this_syscall)
return 0;
}
+/* A wrapper for architectures supporting only SECCOMP_MODE_STRICT. */
+static inline void secure_computing_strict(int this_syscall)
+{
+ BUG_ON(secure_computing(this_syscall) != 0);
+}
+
extern long prctl_get_seccomp(void);
extern long prctl_set_seccomp(unsigned long, char __user *);
@@ -91,6 +97,7 @@ struct seccomp { };
struct seccomp_filter { };
static inline int secure_computing(int this_syscall) { return 0; }
+static inline void secure_computing_strict(int this_syscall) { return; }
static inline long prctl_get_seccomp(void)
{
--
1.7.5.4
^ permalink raw reply related
* Re: [EDAC PATCH v13 4/7] edac: move nr_pages to dimm struct
From: Mauro Carvalho Chehab @ 2012-04-17 19:28 UTC (permalink / raw)
To: Borislav Petkov
Cc: Shaohui Xie, Jason Uhlenkott, Hitoshi Mitake, Mark Gross,
Dmitry Eremin-Solenikov, Ranganathan Desikan, Egor Martovetsky,
Niklas Söderlund, Tim Small, Arvind R., Chris Metcalf,
Olof Johansson, Doug Thompson, Linux Edac Mailing List,
Michal Marek, Jiri Kosina, Linux Kernel Mailing List, Joe Perches,
Andrew Morton, linuxppc-dev
In-Reply-To: <20120417184808.GD13989@aftab>
Em 17-04-2012 15:48, Borislav Petkov escreveu:
> On Mon, Apr 16, 2012 at 05:12:10PM -0300, Mauro Carvalho Chehab wrote:
>> The number of pages is a dimm property. Move it to the dimm struct.
>>
>> After this change, it is possible to add sysfs nodes for the DIMM's that
>
> Minor nitpick:
>
> DIMMs
>
> Please go over the rest of the commit messages because they have similar
> typos.
>
>> will properly represent the DIMM stick properties, including its size.
>>
>> A TODO fix here is to properly represent dual-rank/quad-rank DIMMs when
>> the memory controller represents the memory via chip select rows.
>>
>> Reviewed-by: Aristeu Rozanski <arozansk@redhat.com>
>> Cc: Doug Thompson <norsk5@yahoo.com>
>> Cc: Borislav Petkov <borislav.petkov@amd.com>
>> Cc: Mark Gross <mark.gross@intel.com>
>> Cc: Jason Uhlenkott <juhlenko@akamai.com>
>> Cc: Tim Small <tim@buttersideup.com>
>> Cc: Ranganathan Desikan <ravi@jetztechnologies.com>
>> Cc: "Arvind R." <arvino55@gmail.com>
>> Cc: Olof Johansson <olof@lixom.net>
>> Cc: Egor Martovetsky <egor@pasemi.com>
>> Cc: Chris Metcalf <cmetcalf@tilera.com>
>> Cc: Michal Marek <mmarek@suse.cz>
>> Cc: Jiri Kosina <jkosina@suse.cz>
>> Cc: Joe Perches <joe@perches.com>
>> Cc: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
>> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
>> Cc: Hitoshi Mitake <h.mitake@gmail.com>
>> Cc: Andrew Morton <akpm@linux-foundation.org>
>> Cc: "Niklas Söderlund" <niklas.soderlund@ericsson.com>
>> Cc: Shaohui Xie <Shaohui.Xie@freescale.com>
>> Cc: Josh Boyer <jwboyer@gmail.com>
>> Cc: linuxppc-dev@lists.ozlabs.org
>> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
>> ---
>> drivers/edac/amd64_edac.c | 12 +++------
>> drivers/edac/amd76x_edac.c | 6 ++--
>> drivers/edac/cell_edac.c | 8 ++++--
>> drivers/edac/cpc925_edac.c | 8 ++++--
>> drivers/edac/e752x_edac.c | 6 +++-
>> drivers/edac/e7xxx_edac.c | 5 ++-
>> drivers/edac/edac_mc.c | 16 ++++++++-----
>> drivers/edac/edac_mc_sysfs.c | 47 ++++++++++++++++++++++++++++------------
>> drivers/edac/i3000_edac.c | 6 +++-
>> drivers/edac/i3200_edac.c | 3 +-
>> drivers/edac/i5000_edac.c | 14 ++++++-----
>> drivers/edac/i5100_edac.c | 22 +++++++++++-------
>> drivers/edac/i5400_edac.c | 9 ++-----
>> drivers/edac/i7300_edac.c | 22 +++++-------------
>> drivers/edac/i7core_edac.c | 10 ++------
>> drivers/edac/i82443bxgx_edac.c | 2 +-
>> drivers/edac/i82860_edac.c | 2 +-
>> drivers/edac/i82875p_edac.c | 5 ++-
>> drivers/edac/i82975x_edac.c | 11 ++++++--
>> drivers/edac/mpc85xx_edac.c | 3 +-
>> drivers/edac/mv64x60_edac.c | 3 +-
>> drivers/edac/pasemi_edac.c | 14 ++++++------
>> drivers/edac/ppc4xx_edac.c | 5 ++-
>> drivers/edac/r82600_edac.c | 3 +-
>> drivers/edac/sb_edac.c | 8 +-----
>> drivers/edac/tile_edac.c | 2 +-
>> drivers/edac/x38_edac.c | 4 +-
>> include/linux/edac.h | 8 ++++--
>> 28 files changed, 144 insertions(+), 120 deletions(-)
>>
>> diff --git a/drivers/edac/amd64_edac.c b/drivers/edac/amd64_edac.c
>> index 0be3f29..8804ac8 100644
>> --- a/drivers/edac/amd64_edac.c
>> +++ b/drivers/edac/amd64_edac.c
>> @@ -2126,12 +2126,6 @@ static u32 amd64_csrow_nr_pages(struct amd64_pvt *pvt, u8 dct, int csrow_nr)
>>
>> nr_pages = pvt->ops->dbam_to_cs(pvt, dct, cs_mode) << (20 - PAGE_SHIFT);
>>
>> - /*
>> - * If dual channel then double the memory size of single channel.
>> - * Channel count is 1 or 2
>> - */
>> - nr_pages <<= (pvt->channel_count - 1);
>
> This changes DEBUG output from:
>
> EDAC DEBUG: init_csrows: ----CSROW 0 VALID for MC node 0
> EDAC DEBUG: amd64_csrow_nr_pages: (csrow=0) DBAM map index= 8
> EDAC DEBUG: amd64_csrow_nr_pages: nr_pages= 1048576 channel-count = 2
> EDAC amd64: CS0: Registered DDR3 RAM
> EDAC DEBUG: init_csrows: for MC node 0 csrow 0:
> EDAC DEBUG: init_csrows: nr_pages: 1048576
>
> to
>
> EDAC DEBUG: init_csrows: ----CSROW 0 VALID for MC node 0
> EDAC DEBUG: amd64_csrow_nr_pages: (csrow=0) DBAM map index= 8
> EDAC DEBUG: amd64_csrow_nr_pages: nr_pages= 524288 channel-count = 2
>
> which is only half the pages.
>
>> -
>> debugf0(" (csrow=%d) DBAM map index= %d\n", csrow_nr, cs_mode);
>> debugf0(" nr_pages= %u channel-count = %d\n",
>> nr_pages, pvt->channel_count);
Ok. well, we can either multiply nr_pages by channel_count or to let it
clear that this is per channel. I prefer the last option (see the enclosed
patch).
>> @@ -2152,6 +2146,7 @@ static int init_csrows(struct mem_ctl_info *mci)
>> int i, j, empty = 1;
>> enum mem_type mtype;
>> enum edac_type edac_mode;
>> + int nr_pages;
>>
>> amd64_read_pci_cfg(pvt->F3, NBCFG, &val);
>>
>> @@ -2174,14 +2169,14 @@ static int init_csrows(struct mem_ctl_info *mci)
>> i, pvt->mc_node_id);
>>
>> empty = 0;
>> - csrow->nr_pages = amd64_csrow_nr_pages(pvt, 0, i);
>> + nr_pages = amd64_csrow_nr_pages(pvt, 0, i);
>> get_cs_base_and_mask(pvt, i, 0, &base, &mask);
>> /* 8 bytes of resolution */
>>
>> mtype = amd64_determine_memory_type(pvt, i);
>>
>> debugf1(" for MC node %d csrow %d:\n", pvt->mc_node_id, i);
>> - debugf1(" nr_pages: %u\n", csrow->nr_pages);
>> + debugf1(" nr_pages: %u\n", nr_pages);
>>
>> /*
>> * determine whether CHIPKILL or JUST ECC or NO ECC is operating
>> @@ -2195,6 +2190,7 @@ static int init_csrows(struct mem_ctl_info *mci)
>> for (j = 0; j < pvt->channel_count; j++) {
>> csrow->channels[j].dimm->mtype = mtype;
>> csrow->channels[j].dimm->edac_mode = edac_mode;
>> + csrow->channels[j].dimm->nr_pages = nr_pages;
>
> I'm guessing you want to accumulate the nr_pages for all channels here
> and dump it properly?
>
As you've requested to not move the debugf0() to be after the loop, it is
easier to just multiply it at the printk. As an advantage, when the kernel
is compiled without debug, no code will be produced.
IMO, the best way to solve it is with this small patch. If you're ok, I'll
fold it with this one and add your ack.
Regards,
Mauro
diff --git a/drivers/edac/amd64_edac.c b/drivers/edac/amd64_edac.c
index 8804ac8..6d6ec68 100644
--- a/drivers/edac/amd64_edac.c
+++ b/drivers/edac/amd64_edac.c
@@ -2127,7 +2127,7 @@ static u32 amd64_csrow_nr_pages(struct amd64_pvt *pvt, u8 dct, int csrow_nr)
nr_pages = pvt->ops->dbam_to_cs(pvt, dct, cs_mode) << (20 - PAGE_SHIFT);
debugf0(" (csrow=%d) DBAM map index= %d\n", csrow_nr, cs_mode);
- debugf0(" nr_pages= %u channel-count = %d\n",
+ debugf0(" nr_pages/channel= %u channel-count = %d\n",
nr_pages, pvt->channel_count);
return nr_pages;
@@ -2176,7 +2176,7 @@ static int init_csrows(struct mem_ctl_info *mci)
mtype = amd64_determine_memory_type(pvt, i);
debugf1(" for MC node %d csrow %d:\n", pvt->mc_node_id, i);
- debugf1(" nr_pages: %u\n", nr_pages);
+ debugf1(" nr_pages: %u\n", nr_pages * pvt->channel_count);
/*
* determine whether CHIPKILL or JUST ECC or NO ECC is operating
^ permalink raw reply related
* Re: [EDAC PATCH v13 4/7] edac: move nr_pages to dimm struct
From: Borislav Petkov @ 2012-04-17 18:48 UTC (permalink / raw)
To: Mauro Carvalho Chehab
Cc: Shaohui Xie, Jason Uhlenkott, Hitoshi Mitake, Mark Gross,
Dmitry Eremin-Solenikov, Ranganathan Desikan, Egor Martovetsky,
Niklas Söderlund, Tim Small, Arvind R., Chris Metcalf,
Olof Johansson, Doug Thompson, Linux Edac Mailing List,
Michal Marek, Jiri Kosina, Linux Kernel Mailing List, Joe Perches,
Andrew Morton, linuxppc-dev
In-Reply-To: <1334607133-30039-5-git-send-email-mchehab@redhat.com>
On Mon, Apr 16, 2012 at 05:12:10PM -0300, Mauro Carvalho Chehab wrote:
> The number of pages is a dimm property. Move it to the dimm struct.
>
> After this change, it is possible to add sysfs nodes for the DIMM's that
Minor nitpick:
DIMMs
Please go over the rest of the commit messages because they have similar
typos.
> will properly represent the DIMM stick properties, including its size.
>
> A TODO fix here is to properly represent dual-rank/quad-rank DIMMs when
> the memory controller represents the memory via chip select rows.
>
> Reviewed-by: Aristeu Rozanski <arozansk@redhat.com>
> Cc: Doug Thompson <norsk5@yahoo.com>
> Cc: Borislav Petkov <borislav.petkov@amd.com>
> Cc: Mark Gross <mark.gross@intel.com>
> Cc: Jason Uhlenkott <juhlenko@akamai.com>
> Cc: Tim Small <tim@buttersideup.com>
> Cc: Ranganathan Desikan <ravi@jetztechnologies.com>
> Cc: "Arvind R." <arvino55@gmail.com>
> Cc: Olof Johansson <olof@lixom.net>
> Cc: Egor Martovetsky <egor@pasemi.com>
> Cc: Chris Metcalf <cmetcalf@tilera.com>
> Cc: Michal Marek <mmarek@suse.cz>
> Cc: Jiri Kosina <jkosina@suse.cz>
> Cc: Joe Perches <joe@perches.com>
> Cc: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> Cc: Hitoshi Mitake <h.mitake@gmail.com>
> Cc: Andrew Morton <akpm@linux-foundation.org>
> Cc: "Niklas Söderlund" <niklas.soderlund@ericsson.com>
> Cc: Shaohui Xie <Shaohui.Xie@freescale.com>
> Cc: Josh Boyer <jwboyer@gmail.com>
> Cc: linuxppc-dev@lists.ozlabs.org
> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
> ---
> drivers/edac/amd64_edac.c | 12 +++------
> drivers/edac/amd76x_edac.c | 6 ++--
> drivers/edac/cell_edac.c | 8 ++++--
> drivers/edac/cpc925_edac.c | 8 ++++--
> drivers/edac/e752x_edac.c | 6 +++-
> drivers/edac/e7xxx_edac.c | 5 ++-
> drivers/edac/edac_mc.c | 16 ++++++++-----
> drivers/edac/edac_mc_sysfs.c | 47 ++++++++++++++++++++++++++++------------
> drivers/edac/i3000_edac.c | 6 +++-
> drivers/edac/i3200_edac.c | 3 +-
> drivers/edac/i5000_edac.c | 14 ++++++-----
> drivers/edac/i5100_edac.c | 22 +++++++++++-------
> drivers/edac/i5400_edac.c | 9 ++-----
> drivers/edac/i7300_edac.c | 22 +++++-------------
> drivers/edac/i7core_edac.c | 10 ++------
> drivers/edac/i82443bxgx_edac.c | 2 +-
> drivers/edac/i82860_edac.c | 2 +-
> drivers/edac/i82875p_edac.c | 5 ++-
> drivers/edac/i82975x_edac.c | 11 ++++++--
> drivers/edac/mpc85xx_edac.c | 3 +-
> drivers/edac/mv64x60_edac.c | 3 +-
> drivers/edac/pasemi_edac.c | 14 ++++++------
> drivers/edac/ppc4xx_edac.c | 5 ++-
> drivers/edac/r82600_edac.c | 3 +-
> drivers/edac/sb_edac.c | 8 +-----
> drivers/edac/tile_edac.c | 2 +-
> drivers/edac/x38_edac.c | 4 +-
> include/linux/edac.h | 8 ++++--
> 28 files changed, 144 insertions(+), 120 deletions(-)
>
> diff --git a/drivers/edac/amd64_edac.c b/drivers/edac/amd64_edac.c
> index 0be3f29..8804ac8 100644
> --- a/drivers/edac/amd64_edac.c
> +++ b/drivers/edac/amd64_edac.c
> @@ -2126,12 +2126,6 @@ static u32 amd64_csrow_nr_pages(struct amd64_pvt *pvt, u8 dct, int csrow_nr)
>
> nr_pages = pvt->ops->dbam_to_cs(pvt, dct, cs_mode) << (20 - PAGE_SHIFT);
>
> - /*
> - * If dual channel then double the memory size of single channel.
> - * Channel count is 1 or 2
> - */
> - nr_pages <<= (pvt->channel_count - 1);
This changes DEBUG output from:
EDAC DEBUG: init_csrows: ----CSROW 0 VALID for MC node 0
EDAC DEBUG: amd64_csrow_nr_pages: (csrow=0) DBAM map index= 8
EDAC DEBUG: amd64_csrow_nr_pages: nr_pages= 1048576 channel-count = 2
EDAC amd64: CS0: Registered DDR3 RAM
EDAC DEBUG: init_csrows: for MC node 0 csrow 0:
EDAC DEBUG: init_csrows: nr_pages: 1048576
to
EDAC DEBUG: init_csrows: ----CSROW 0 VALID for MC node 0
EDAC DEBUG: amd64_csrow_nr_pages: (csrow=0) DBAM map index= 8
EDAC DEBUG: amd64_csrow_nr_pages: nr_pages= 524288 channel-count = 2
which is only half the pages.
> -
> debugf0(" (csrow=%d) DBAM map index= %d\n", csrow_nr, cs_mode);
> debugf0(" nr_pages= %u channel-count = %d\n",
> nr_pages, pvt->channel_count);
> @@ -2152,6 +2146,7 @@ static int init_csrows(struct mem_ctl_info *mci)
> int i, j, empty = 1;
> enum mem_type mtype;
> enum edac_type edac_mode;
> + int nr_pages;
>
> amd64_read_pci_cfg(pvt->F3, NBCFG, &val);
>
> @@ -2174,14 +2169,14 @@ static int init_csrows(struct mem_ctl_info *mci)
> i, pvt->mc_node_id);
>
> empty = 0;
> - csrow->nr_pages = amd64_csrow_nr_pages(pvt, 0, i);
> + nr_pages = amd64_csrow_nr_pages(pvt, 0, i);
> get_cs_base_and_mask(pvt, i, 0, &base, &mask);
> /* 8 bytes of resolution */
>
> mtype = amd64_determine_memory_type(pvt, i);
>
> debugf1(" for MC node %d csrow %d:\n", pvt->mc_node_id, i);
> - debugf1(" nr_pages: %u\n", csrow->nr_pages);
> + debugf1(" nr_pages: %u\n", nr_pages);
>
> /*
> * determine whether CHIPKILL or JUST ECC or NO ECC is operating
> @@ -2195,6 +2190,7 @@ static int init_csrows(struct mem_ctl_info *mci)
> for (j = 0; j < pvt->channel_count; j++) {
> csrow->channels[j].dimm->mtype = mtype;
> csrow->channels[j].dimm->edac_mode = edac_mode;
> + csrow->channels[j].dimm->nr_pages = nr_pages;
I'm guessing you want to accumulate the nr_pages for all channels here
and dump it properly?
--
Regards/Gruss,
Boris.
Advanced Micro Devices GmbH
Einsteinring 24, 85609 Dornach
GM: Alberto Bozzo
Reg: Dornach, Landkreis Muenchen
HRB Nr. 43632 WEEE Registernr: 129 19551
^ permalink raw reply
* Re: [PATCH v2 1/2] powerpc/mpc85xx: support the MTD for p1022ds flash
From: Tabi Timur-B04825 @ 2012-04-17 18:09 UTC (permalink / raw)
To: Huang Changming-R66093; +Cc: linuxppc-dev@lists.ozlabs.org
In-Reply-To: <1334654129-1044-1-git-send-email-Chang-Ming.Huang@freescale.com>
On Tue, Apr 17, 2012 at 4:15 AM, <Chang-Ming.Huang@freescale.com> wrote:
> diff --git a/arch/powerpc/platforms/85xx/p1022_ds.c b/arch/powerpc/platfo=
rms/85xx/p1022_ds.c
> index e74b7cd..0db3a7e 100644
> --- a/arch/powerpc/platforms/85xx/p1022_ds.c
> +++ b/arch/powerpc/platforms/85xx/p1022_ds.c
> @@ -463,6 +463,7 @@ static void __init p1022_ds_setup_arch(void)
> =A0static struct of_device_id __initdata p1022_ds_ids[] =3D {
> =A0 =A0 =A0 =A0/* So that the DMA channel nodes can be probed individuall=
y: */
> =A0 =A0 =A0 =A0{ .compatible =3D "fsl,eloplus-dma", },
> + =A0 =A0 =A0 { .compatible =3D "fsl,p1022-elbc", },
> =A0 =A0 =A0 =A0{},
> =A0};
Have you actually tested this with an upstream kernel? p1022_ds_ids[]
is broken upstream, so adding a new line won't work.
Take a look at http://patchwork.ozlabs.org/patch/128533/
--=20
Timur Tabi
Linux kernel developer at Freescale=
^ permalink raw reply
* Re: [PATCH v4 1/4] powerpc/85xx: add HOTPLUG_CPU support
From: Scott Wood @ 2012-04-17 16:25 UTC (permalink / raw)
To: Li Yang-R58472
Cc: Wood Scott-B07421, linuxppc-dev@lists.ozlabs.org,
linux-kernel@vger.kernel.org, Zhao Chenhui-B35336
In-Reply-To: <94F013E7935FF44C83EBE7784D62AD3F092D1098@039-SN2MPN1-022.039d.mgd.msft.net>
On 04/17/2012 04:51 AM, Li Yang-R58472 wrote:
>>> struct smp_ops_t smp_85xx_ops = {
>>> .kick_cpu = smp_85xx_kick_cpu,
>>> -#ifdef CONFIG_KEXEC
>>> +#ifdef CONFIG_HOTPLUG_CPU
>>> + .cpu_disable = generic_cpu_disable,
>>> + .cpu_die = generic_cpu_die,
>>> +#endif
>>> .give_timebase = smp_generic_give_timebase,
>>> .take_timebase = smp_generic_take_timebase,
>>> -#endif
>>> };
>>
>> We need to stop using smp_generic_give/take_timebase, not expand its use.
>> This stuff breaks under hypervisors where timebase can't be written. It
>> wasn't too bad before since we generally didn't enable CONFIG_KEXEC, but
>> we're more likely to want CONFIG_HOTPLUG_CPU.
>
> I understand that the guest OS shouldn't change the real timebase.
Cannot change it, and we've seen the tbsync code loop forever when it
tries (since the changes aren't taking effect).
> But no matter what timebase syncing method we are using, the timebase need to be changed anyway for certain features.
That's why I said to do it the way U-Boot does it.
> I think the better way should be trapping timebase modification in the hypervisor.
It does trap. Currently we treat it as a no-op. The only reasonable
alternative is to give the guest an exception. It is simply not allowed
for a guest to modify the timebase -- we are not going to break the
host's timebase sync. See the virtualized implementation note in
section 9.2.1 of book III-E of Power ISA 2.06B: "In virtualized
implementations, TBU and TBL are read-only."
>> Do the timebase sync the way U-Boot does -- if you find the appropriate
>> guts node in the device tree.
>
> That involves stopping timebase for a short time on all cores including the cores that are still online. Won't this be a potential issue?
I don't think it's a big deal in the contexts where you'd be doing
this -- at least not worse than the current situation. Just make sure
that you don't reset the timebase to zero or otherwise make a core see
the timebase go backward.
-Scott
^ permalink raw reply
* Re: [PATCH] Drivers: ps3: ps3av.c: fixed checkpatch warnings
From: Geert Uytterhoeven @ 2012-04-17 12:53 UTC (permalink / raw)
To: Valentin Ilie; +Cc: geoff, cbe-oss-dev, linuxppc-dev, linux-kernel
In-Reply-To: <1334661361-3699-1-git-send-email-valentin.ilie@gmail.com>
On Tue, Apr 17, 2012 at 13:16, Valentin Ilie <valentin.ilie@gmail.com> wrot=
e:
> diff --git a/drivers/ps3/ps3av.c b/drivers/ps3/ps3av.c
> index a409fa0..46136b0 100644
> --- a/drivers/ps3/ps3av.c
> +++ b/drivers/ps3/ps3av.c
> @@ -25,8 +25,8 @@
> =C2=A0#include <linux/ioctl.h>
> =C2=A0#include <linux/fb.h>
> =C2=A0#include <linux/slab.h>
> +#include <linux/firmware.h>
>
> -#include <asm/firmware.h>
NAK. It really needs <asm/firmware.h> (have you compiled the result?).
Gr{oetje,eeting}s,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k=
.org
In personal conversations with technical people, I call myself a hacker. Bu=
t
when I'm talking to journalists I just say "programmer" or something like t=
hat.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0=C2=A0 -- Linus Torvalds
^ permalink raw reply
* [PATCH] Drivers: ps3: ps3av.c: fixed checkpatch warnings
From: Valentin Ilie @ 2012-04-17 11:16 UTC (permalink / raw)
To: geoff; +Cc: cbe-oss-dev, Valentin Ilie, linuxppc-dev, linux-kernel
Fixed some indenting problems.
Signed-off-by: Valentin Ilie <valentin.ilie@gmail.com>
---
drivers/ps3/ps3av.c | 11 ++---------
1 file changed, 2 insertions(+), 9 deletions(-)
diff --git a/drivers/ps3/ps3av.c b/drivers/ps3/ps3av.c
index a409fa0..46136b0 100644
--- a/drivers/ps3/ps3av.c
+++ b/drivers/ps3/ps3av.c
@@ -25,8 +25,8 @@
#include <linux/ioctl.h>
#include <linux/fb.h>
#include <linux/slab.h>
+#include <linux/firmware.h>
-#include <asm/firmware.h>
#include <asm/ps3av.h>
#include <asm/ps3.h>
@@ -338,7 +338,7 @@ int ps3av_do_pkt(u32 cid, u16 send_len, size_t usr_buf_size,
mutex_unlock(&ps3av->mutex);
return 0;
- err:
+err:
mutex_unlock(&ps3av->mutex);
printk(KERN_ERR "%s: failed cid:%x res:%d\n", __func__, cid, res);
return res;
@@ -477,7 +477,6 @@ int ps3av_set_audio_mode(u32 ch, u32 fs, u32 word_bits, u32 format, u32 source)
return 0;
}
-
EXPORT_SYMBOL_GPL(ps3av_set_audio_mode);
static int ps3av_set_videomode(void)
@@ -870,21 +869,18 @@ int ps3av_set_video_mode(int id)
return 0;
}
-
EXPORT_SYMBOL_GPL(ps3av_set_video_mode);
int ps3av_get_auto_mode(void)
{
return ps3av_auto_videomode(&ps3av->av_hw_conf);
}
-
EXPORT_SYMBOL_GPL(ps3av_get_auto_mode);
int ps3av_get_mode(void)
{
return ps3av ? ps3av->ps3av_mode : 0;
}
-
EXPORT_SYMBOL_GPL(ps3av_get_mode);
/* get resolution by video_mode */
@@ -902,7 +898,6 @@ int ps3av_video_mode2res(u32 id, u32 *xres, u32 *yres)
*yres = video_mode_table[id].y;
return 0;
}
-
EXPORT_SYMBOL_GPL(ps3av_video_mode2res);
/* mute */
@@ -911,7 +906,6 @@ int ps3av_video_mute(int mute)
return ps3av_set_av_video_mute(mute ? PS3AV_CMD_MUTE_ON
: PS3AV_CMD_MUTE_OFF);
}
-
EXPORT_SYMBOL_GPL(ps3av_video_mute);
/* mute analog output only */
@@ -935,7 +929,6 @@ int ps3av_audio_mute(int mute)
return ps3av_set_audio_mute(mute ? PS3AV_CMD_MUTE_ON
: PS3AV_CMD_MUTE_OFF);
}
-
EXPORT_SYMBOL_GPL(ps3av_audio_mute);
static int __devinit ps3av_probe(struct ps3_system_bus_device *dev)
--
1.7.9.5
^ permalink raw reply related
* Re: [PATCH 1/7] Add support hardreset
From: Sergei Shtylyov @ 2012-04-17 11:06 UTC (permalink / raw)
To: Thang Q. Nguyen
Cc: Phong Vo, devicetree-discuss, linuxppc-dev, Rob Herring,
linux-kernel, linux-ide, Paul Mackerras, Jeff Garzik
In-Reply-To: <1334652193-10487-1-git-send-email-tqnguyen@apm.com>
Hello.
On 17-04-2012 12:43, Thang Q. Nguyen wrote:
> The hardreset operation is currently not supported. This causes sometime the SATA driver does cause kernel crash because of none-determined state.a This patch will fix the issue.
> Signed-off-by: Thang Q. Nguyen<tqnguyen@apm.com>
> ---
> drivers/ata/sata_dwc_460ex.c | 24 +++++++++++++++++++++++-
> 1 files changed, 23 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/ata/sata_dwc_460ex.c b/drivers/ata/sata_dwc_460ex.c
> index 69f7cde..ae13ef1 100644
> --- a/drivers/ata/sata_dwc_460ex.c
> +++ b/drivers/ata/sata_dwc_460ex.c
> @@ -1581,10 +1581,31 @@ static void sata_dwc_qc_prep(struct ata_queued_cmd *qc)
>
> static void sata_dwc_error_handler(struct ata_port *ap)
> {
> - ap->link.flags |= ATA_LFLAG_NO_HRST;
> ata_sff_error_handler(ap);
> }
Could eliminate this, switching to the default implementation...
MBR, Sergei
^ permalink raw reply
* RE: [PATCH v4 1/4] powerpc/85xx: add HOTPLUG_CPU support
From: Li Yang-R58472 @ 2012-04-17 9:51 UTC (permalink / raw)
To: Wood Scott-B07421, Zhao Chenhui-B35336
Cc: linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org
In-Reply-To: <4F8C78B3.1070002@freescale.com>
> > struct smp_ops_t smp_85xx_ops =3D {
> > .kick_cpu =3D smp_85xx_kick_cpu,
> > -#ifdef CONFIG_KEXEC
> > +#ifdef CONFIG_HOTPLUG_CPU
> > + .cpu_disable =3D generic_cpu_disable,
> > + .cpu_die =3D generic_cpu_die,
> > +#endif
> > .give_timebase =3D smp_generic_give_timebase,
> > .take_timebase =3D smp_generic_take_timebase,
> > -#endif
> > };
>=20
> We need to stop using smp_generic_give/take_timebase, not expand its use.
> This stuff breaks under hypervisors where timebase can't be written. It
> wasn't too bad before since we generally didn't enable CONFIG_KEXEC, but
> we're more likely to want CONFIG_HOTPLUG_CPU.
I understand that the guest OS shouldn't change the real timebase. But no =
matter what timebase syncing method we are using, the timebase need to be c=
hanged anyway for certain features. I think the better way should be trapp=
ing timebase modification in the hypervisor.
>=20
> Do the timebase sync the way U-Boot does -- if you find the appropriate
> guts node in the device tree.
That involves stopping timebase for a short time on all cores including the=
cores that are still online. Won't this be a potential issue?
- Leo=20
^ permalink raw reply
* [PATCH v2 1/2] powerpc/mpc85xx: support the MTD for p1022ds flash
From: Chang-Ming.Huang @ 2012-04-17 9:15 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Jerry Huang
From: Jerry Huang <Chang-Ming.Huang@freescale.com>
The compatilbe 'simple-bus' is removed from the latest DTS for NAND and
NOR flash partition, so we must add the new compatilbe support for p1022ds,
otherwise, the kernel can't parse the partition of NOR and NAND flash.
Signed-off-by: Jerry Huang <Chang-Ming.Huang@freescale.com>
---
changes for v2:
correct the style
arch/powerpc/platforms/85xx/p1022_ds.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/platforms/85xx/p1022_ds.c b/arch/powerpc/platforms/85xx/p1022_ds.c
index e74b7cd..0db3a7e 100644
--- a/arch/powerpc/platforms/85xx/p1022_ds.c
+++ b/arch/powerpc/platforms/85xx/p1022_ds.c
@@ -463,6 +463,7 @@ static void __init p1022_ds_setup_arch(void)
static struct of_device_id __initdata p1022_ds_ids[] = {
/* So that the DMA channel nodes can be probed individually: */
{ .compatible = "fsl,eloplus-dma", },
+ { .compatible = "fsl,p1022-elbc", },
{},
};
--
1.7.5.4
^ permalink raw reply related
* Re: [PATCH v3]KVM: PPC: Use clockevent multiplier and shifter for decrementer
From: Alexander Graf @ 2012-04-17 9:22 UTC (permalink / raw)
To: Bharat Bhushan; +Cc: Bharat Bhushan, linuxppc-dev, kvm, kvm-ppc, bharatb.yadav
In-Reply-To: <1334634909-9066-1-git-send-email-bharat.bhushan@freescale.com>
On 04/17/2012 05:55 AM, Bharat Bhushan wrote:
> Time for which the hrtimer is started for decrementer emulation is calculated using tb_ticks_per_usec. While hrtimer uses the clockevent for DEC reprogramming (if needed) and which calculate timebase ticks using the multiplier and shifter mechanism implemented within clockevent layer. It was observed that this conversion (timebase->time->timebase) are not correct because the mechanism are not consistent. In our setup it adds 2% jitter.
>
> With this patch clockevent multiplier and shifter mechanism are used when starting hrtimer for decrementer emulation. Now the jitter is< 0.5%.
>
> Signed-off-by: Bharat Bhushan<bharat.bhushan@freescale.com>
> ---
> v3:
> - decrementer_clockevent symbol exported.
>
> arch/powerpc/include/asm/time.h | 1 +
> arch/powerpc/kernel/time.c | 3 ++-
> arch/powerpc/kvm/emulate.c | 5 +++--
> 3 files changed, 6 insertions(+), 3 deletions(-)
>
> diff --git a/arch/powerpc/include/asm/time.h b/arch/powerpc/include/asm/time.h
> index 7eb10fb..b3c7959 100644
> --- a/arch/powerpc/include/asm/time.h
> +++ b/arch/powerpc/include/asm/time.h
> @@ -28,6 +28,7 @@
> extern unsigned long tb_ticks_per_jiffy;
> extern unsigned long tb_ticks_per_usec;
> extern unsigned long tb_ticks_per_sec;
> +extern struct clock_event_device decrementer_clockevent;
>
> struct rtc_time;
> extern void to_tm(int tim, struct rtc_time * tm);
> diff --git a/arch/powerpc/kernel/time.c b/arch/powerpc/kernel/time.c
> index 567dd7c..4f7a285 100644
> --- a/arch/powerpc/kernel/time.c
> +++ b/arch/powerpc/kernel/time.c
> @@ -105,7 +105,7 @@ static int decrementer_set_next_event(unsigned long evt,
> static void decrementer_set_mode(enum clock_event_mode mode,
> struct clock_event_device *dev);
>
> -static struct clock_event_device decrementer_clockevent = {
> +struct clock_event_device decrementer_clockevent = {
> .name = "decrementer",
> .rating = 200,
> .irq = 0,
> @@ -113,6 +113,7 @@ static struct clock_event_device decrementer_clockevent = {
> .set_mode = decrementer_set_mode,
> .features = CLOCK_EVT_FEAT_ONESHOT,
> };
> +EXPORT_SYMBOL(decrementer_clockevent);
>
> DEFINE_PER_CPU(u64, decrementers_next_tb);
> static DEFINE_PER_CPU(struct clock_event_device, decrementers);
> diff --git a/arch/powerpc/kvm/emulate.c b/arch/powerpc/kvm/emulate.c
> index afc9154..c8b5206 100644
> --- a/arch/powerpc/kvm/emulate.c
> +++ b/arch/powerpc/kvm/emulate.c
> @@ -23,6 +23,7 @@
> #include<linux/types.h>
> #include<linux/string.h>
> #include<linux/kvm_host.h>
> +#include<linux/clockchips.h>
>
> #include<asm/reg.h>
> #include<asm/time.h>
> @@ -104,8 +105,8 @@ void kvmppc_emulate_dec(struct kvm_vcpu *vcpu)
> */
>
> dec_time = vcpu->arch.dec;
> - dec_time *= 1000;
> - do_div(dec_time, tb_ticks_per_usec);
Sorry for the late nitpicking, but could you please add a comment here
that states that we can use the host's decrementer calculations because
the guest's timebase ticks at the same speed?
Alex
> + dec_time = dec_time<< decrementer_clockevent.shift;
> + do_div(dec_time, decrementer_clockevent.mult);
> dec_nsec = do_div(dec_time, NSEC_PER_SEC);
> hrtimer_start(&vcpu->arch.dec_timer,
> ktime_set(dec_time, dec_nsec), HRTIMER_MODE_REL);
^ 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