* Re: [RFC 2/5]arch:powerpc:sysdev:Makefile Remove unused config in the Makefile.
From: Justin Mattock @ 2011-04-06 16:09 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev, trivial, linux-kernel, Harninder Rai
In-Reply-To: <20110406110335.0f2d5f4c@schlenkerla.am.freescale.net>
On Wed, Apr 6, 2011 at 9:03 AM, Scott Wood <scottwood@freescale.com> wrote:
> On Wed, 6 Apr 2011 08:07:58 -0700
> Justin Mattock <justinmattock@gmail.com> wrote:
>
>> ahh.. so the: =A0fsl_85xx_l2ctlr.o fsl_85xx_cache_sram.o is still in use
>> even though FSL_85XX_CACHE_SRAM is not really used, but really is used!!
>>
>> but might be wrong with this.
>
> More like there are plans to use it, or possibly out-of-tree users. =A0We
> should prod people a bit to submit the driver patches that use this befor=
e
> we just yank it out.
>
> -Scott
>
>
well if this is going to be used for something down the line, then
best leave it in..
--=20
Justin P. Mattock
^ permalink raw reply
* Re: [RFC 2/5]arch:powerpc:sysdev:Makefile Remove unused config in the Makefile.
From: Scott Wood @ 2011-04-06 16:03 UTC (permalink / raw)
To: Justin Mattock; +Cc: linuxppc-dev, trivial, linux-kernel, Harninder Rai
In-Reply-To: <BANLkTi=5A1P-WAFvCyjbT7RVva9K9d=gQQ@mail.gmail.com>
On Wed, 6 Apr 2011 08:07:58 -0700
Justin Mattock <justinmattock@gmail.com> wrote:
> ahh.. so the: fsl_85xx_l2ctlr.o fsl_85xx_cache_sram.o is still in use
> even though FSL_85XX_CACHE_SRAM is not really used, but really is used!!
>
> but might be wrong with this.
More like there are plans to use it, or possibly out-of-tree users. We
should prod people a bit to submit the driver patches that use this before
we just yank it out.
-Scott
^ permalink raw reply
* Re: [RFC 2/5]arch:powerpc:sysdev:Makefile Remove unused config in the Makefile.
From: Justin Mattock @ 2011-04-06 15:07 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev, trivial, linux-kernel, Harninder Rai
In-Reply-To: <20110405131504.1d182da4@schlenkerla.am.freescale.net>
On Tue, Apr 5, 2011 at 11:15 AM, Scott Wood <scottwood@freescale.com> wrote=
:
> On Tue, 5 Apr 2011 09:58:19 -0700
> "Justin P. Mattock" <justinmattock@gmail.com> wrote:
>
>> The patch below removes an unused config variable found by using a kerne=
l
>> cleanup script.
>> Note: I did try to cross compile these but hit erros while doing so..
>> (gcc is not setup to cross compile) and am unsure if anymore needs to be=
done.
>> Please have a look if/when anybody has free time.
>>
>> Signed-off-by: Justin P. Mattock <justinmattock@gmail.com>
>> CC: Benjamin Herrenschmidt <benh@kernel.crashing.org>
>> CC: linuxppc-dev@lists.ozlabs.org
>>
>> ---
>> =A0arch/powerpc/sysdev/Makefile | =A0 =A01 -
>> =A01 files changed, 0 insertions(+), 1 deletions(-)
>>
>> diff --git a/arch/powerpc/sysdev/Makefile b/arch/powerpc/sysdev/Makefile
>> index 1e0c933..243b6ad 100644
>> --- a/arch/powerpc/sysdev/Makefile
>> +++ b/arch/powerpc/sysdev/Makefile
>> @@ -18,7 +18,6 @@ obj-$(CONFIG_FSL_PMC) =A0 =A0 =A0 =A0 =A0 =A0 =A0 +=3D=
fsl_pmc.o
>> =A0obj-$(CONFIG_FSL_LBC) =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0+=3D fsl_lbc.o
>> =A0obj-$(CONFIG_FSL_GTM) =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0+=3D fsl_gtm.o
>> =A0obj-$(CONFIG_MPC8xxx_GPIO) =A0 +=3D mpc8xxx_gpio.o
>> -obj-$(CONFIG_FSL_85XX_CACHE_SRAM) =A0 =A0+=3D fsl_85xx_l2ctlr.o fsl_85x=
x_cache_sram.o
>> =A0obj-$(CONFIG_SIMPLE_GPIO) =A0 =A0+=3D simple_gpio.o
>> =A0obj-$(CONFIG_FSL_RIO) =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0+=3D fsl_rio.o
>> =A0obj-$(CONFIG_TSI108_BRIDGE) =A0+=3D tsi108_pci.o tsi108_dev.o
>
> Those files do exist, and aren't pulled in by any other means I can see.
> It was introduced by commit 6db92cc9d07db9f713da8554b4bcdfc8e54ad386, who=
se
> changelog says:
> =A0 =A0 =A0 =A0Drivers can do the following in Kconfig to use these APIs =
"select
> FSL_85XX_CACHE_SRAM if MPC85xx"
>
> Now, the absence of such a kconfig option[1] is a problem, but I don't th=
ink
> outright removal (labelled "trivial cleanup") is appropriate, unless nobo=
dy
> fixes it after the problem is pointed out. =A0And if it is removed, the f=
iles
> should go with it.
>
> -Scott
>
> [1] and of any drivers that select it, though this was added fairly
> recently -- perhaps such a driver change is on its way?
>
>
ahh.. so the: fsl_85xx_l2ctlr.o fsl_85xx_cache_sram.o is still in use
even though FSL_85XX_CACHE_SRAM is not really used, but really is used!!
but might be wrong with this.
--=20
Justin P. Mattock
^ permalink raw reply
* [PATCH 1/1] RapidIO: Add IDT CPS-1432 switch definitions
From: Alexandre Bounine @ 2011-04-06 14:56 UTC (permalink / raw)
To: akpm, linux-kernel, linuxppc-dev; +Cc: Alexandre Bounine
Signed-off-by: Alexandre Bounine <alexandre.bounine@idt.com>
Cc: Matt Porter <mporter@kernel.crashing.org>
Cc: Kumar Gala <galak@kernel.crashing.org>
---
drivers/rapidio/switches/idt_gen2.c | 1 +
include/linux/rio_ids.h | 1 +
2 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/drivers/rapidio/switches/idt_gen2.c b/drivers/rapidio/switches/idt_gen2.c
index 095016a..ac2701b 100644
--- a/drivers/rapidio/switches/idt_gen2.c
+++ b/drivers/rapidio/switches/idt_gen2.c
@@ -418,3 +418,4 @@ DECLARE_RIO_SWITCH_INIT(RIO_VID_IDT, RIO_DID_IDTCPS1848, idtg2_switch_init);
DECLARE_RIO_SWITCH_INIT(RIO_VID_IDT, RIO_DID_IDTCPS1616, idtg2_switch_init);
DECLARE_RIO_SWITCH_INIT(RIO_VID_IDT, RIO_DID_IDTVPS1616, idtg2_switch_init);
DECLARE_RIO_SWITCH_INIT(RIO_VID_IDT, RIO_DID_IDTSPS1616, idtg2_switch_init);
+DECLARE_RIO_SWITCH_INIT(RIO_VID_IDT, RIO_DID_IDTCPS1432, idtg2_switch_init);
diff --git a/include/linux/rio_ids.h b/include/linux/rio_ids.h
index 7410d33..0cee015 100644
--- a/include/linux/rio_ids.h
+++ b/include/linux/rio_ids.h
@@ -35,6 +35,7 @@
#define RIO_DID_IDTCPS6Q 0x035f
#define RIO_DID_IDTCPS10Q 0x035e
#define RIO_DID_IDTCPS1848 0x0374
+#define RIO_DID_IDTCPS1432 0x0375
#define RIO_DID_IDTCPS1616 0x0379
#define RIO_DID_IDTVPS1616 0x0377
#define RIO_DID_IDTSPS1616 0x0378
--
1.7.3.1
^ permalink raw reply related
* Re: halt/reset on assert?
From: Evan Lavelle @ 2011-04-06 13:01 UTC (permalink / raw)
To: Andreas Schwab; +Cc: linuxppc-dev
In-Reply-To: <m2sju1uoti.fsf@igel.home>
Hi Andreas -
that's great; thanks. I'm on 2.4.4, which doesn't have BUG_ON. The right
way for 2.4.4 turns out to be
#define MY_ASSERT(expr) if(!(expr)) BUG()
-Evan
^ permalink raw reply
* [RFC][PATCH] powerpc/fsl-booke64: Add support for Debug Level exception handler
From: Kumar Gala @ 2011-04-06 12:30 UTC (permalink / raw)
To: linuxppc-dev
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
---
arch/powerpc/include/asm/cputable.h | 4 ++-
arch/powerpc/kernel/exceptions-64e.S | 65 ++++++++++++++++++++++++++++++++--
arch/powerpc/kernel/setup_64.c | 8 ++++
3 files changed, 73 insertions(+), 4 deletions(-)
diff --git a/arch/powerpc/include/asm/cputable.h b/arch/powerpc/include/asm/cputable.h
index 9028a9e..bb9fc80 100644
--- a/arch/powerpc/include/asm/cputable.h
+++ b/arch/powerpc/include/asm/cputable.h
@@ -157,6 +157,7 @@ extern const char *powerpc_base_platform;
#define CPU_FTR_476_DD2 ASM_CONST(0x0000000000010000)
#define CPU_FTR_NEED_COHERENT ASM_CONST(0x0000000000020000)
#define CPU_FTR_NO_BTIC ASM_CONST(0x0000000000040000)
+#define CPU_FTR_DEBUG_LVL_EXC ASM_CONST(0x0000000000080000)
#define CPU_FTR_NODSISRALIGN ASM_CONST(0x0000000000100000)
#define CPU_FTR_PPC_LE ASM_CONST(0x0000000000200000)
#define CPU_FTR_REAL_LE ASM_CONST(0x0000000000400000)
@@ -389,7 +390,8 @@ extern const char *powerpc_base_platform;
#define CPU_FTRS_E5500 (CPU_FTR_MAYBE_CAN_DOZE | CPU_FTR_USE_TB | \
CPU_FTR_MAYBE_CAN_NAP | CPU_FTR_NODSISRALIGN | \
CPU_FTR_L2CSR | CPU_FTR_LWSYNC | CPU_FTR_NOEXECUTE | \
- CPU_FTR_DBELL | CPU_FTR_POPCNTB | CPU_FTR_POPCNTD)
+ CPU_FTR_DBELL | CPU_FTR_POPCNTB | CPU_FTR_POPCNTD | \
+ CPU_FTR_DEBUG_LVL_EXC)
#define CPU_FTRS_GENERIC_32 (CPU_FTR_COMMON | CPU_FTR_NODSISRALIGN)
/* 64-bit CPUs */
diff --git a/arch/powerpc/kernel/exceptions-64e.S b/arch/powerpc/kernel/exceptions-64e.S
index 5c43063..28f2223 100644
--- a/arch/powerpc/kernel/exceptions-64e.S
+++ b/arch/powerpc/kernel/exceptions-64e.S
@@ -252,9 +252,6 @@ exception_marker:
.balign 0x1000
.globl interrupt_base_book3e
interrupt_base_book3e: /* fake trap */
- /* Note: If real debug exceptions are supported by the HW, the vector
- * below will have to be patched up to point to an appropriate handler
- */
EXCEPTION_STUB(0x000, machine_check) /* 0x0200 */
EXCEPTION_STUB(0x020, critical_input) /* 0x0580 */
EXCEPTION_STUB(0x040, debug_crit) /* 0x0d00 */
@@ -454,6 +451,68 @@ interrupt_end_book3e:
kernel_dbg_exc:
b . /* NYI */
+/* Debug exception as a debug interrupt*/
+ START_EXCEPTION(debug_debug);
+ DBG_EXCEPTION_PROLOG(0xd00, PROLOG_ADDITION_2REGS)
+
+ /*
+ * If there is a single step or branch-taken exception in an
+ * exception entry sequence, it was probably meant to apply to
+ * the code where the exception occurred (since exception entry
+ * doesn't turn off DE automatically). We simulate the effect
+ * of turning off DE on entry to an exception handler by turning
+ * off DE in the DSRR1 value and clearing the debug status.
+ */
+
+ mfspr r14,SPRN_DBSR /* check single-step/branch taken */
+ andis. r15,r14,DBSR_IC@h
+ beq+ 1f
+
+ LOAD_REG_IMMEDIATE(r14,interrupt_base_book3e)
+ LOAD_REG_IMMEDIATE(r15,interrupt_end_book3e)
+ cmpld cr0,r10,r14
+ cmpld cr1,r10,r15
+ blt+ cr0,1f
+ bge+ cr1,1f
+
+ /* here it looks like we got an inappropriate debug exception. */
+ lis r14,DBSR_IC@h /* clear the IC event */
+ rlwinm r11,r11,0,~MSR_DE /* clear DE in the DSRR1 value */
+ mtspr SPRN_DBSR,r14
+ mtspr SPRN_DSRR1,r11
+ lwz r10,PACA_EXDBG+EX_CR(r13) /* restore registers */
+ ld r1,PACA_EXDBG+EX_R1(r13)
+ ld r14,PACA_EXDBG+EX_R14(r13)
+ ld r15,PACA_EXDBG+EX_R15(r13)
+ mtcr r10
+ ld r10,PACA_EXDBG+EX_R10(r13) /* restore registers */
+ ld r11,PACA_EXDBG+EX_R11(r13)
+ mfspr r13,SPRN_SPRG_DBG_SCRATCH
+ rfdi
+
+ /* Normal debug exception */
+ /* XXX We only handle coming from userspace for now since we can't
+ * quite save properly an interrupted kernel state yet
+ */
+1: andi. r14,r11,MSR_PR; /* check for userspace again */
+ beq kernel_dbg_exc; /* if from kernel mode */
+
+ /* Now we mash up things to make it look like we are coming on a
+ * normal exception
+ */
+ mfspr r15,SPRN_SPRG_DBG_SCRATCH
+ mtspr SPRN_SPRG_GEN_SCRATCH,r15
+ mfspr r14,SPRN_DBSR
+ EXCEPTION_COMMON(0xd00, PACA_EXDBG, INTS_DISABLE_ALL)
+ std r14,_DSISR(r1)
+ addi r3,r1,STACK_FRAME_OVERHEAD
+ mr r4,r14
+ ld r14,PACA_EXDBG+EX_R14(r13)
+ ld r15,PACA_EXDBG+EX_R15(r13)
+ bl .save_nvgprs
+ bl .DebugException
+ b .ret_from_except
+
/* Doorbell interrupt */
MASKABLE_EXCEPTION(0x2070, doorbell, .doorbell_exception, ACK_NONE)
diff --git a/arch/powerpc/kernel/setup_64.c b/arch/powerpc/kernel/setup_64.c
index 5a0401f..2ff0032 100644
--- a/arch/powerpc/kernel/setup_64.c
+++ b/arch/powerpc/kernel/setup_64.c
@@ -62,6 +62,7 @@
#include <asm/udbg.h>
#include <asm/kexec.h>
#include <asm/mmu_context.h>
+#include <asm/code-patching.h>
#include "setup.h"
@@ -453,6 +454,9 @@ static void __init irqstack_early_init(void)
#ifdef CONFIG_PPC_BOOK3E
static void __init exc_lvl_early_init(void)
{
+ extern unsigned int interrupt_base_book3e;
+ extern unsigned int exc_debug_debug_book3e;
+
unsigned int i;
for_each_possible_cpu(i) {
@@ -463,6 +467,10 @@ static void __init exc_lvl_early_init(void)
mcheckirq_ctx[i] = (struct thread_info *)
__va(memblock_alloc(THREAD_SIZE, THREAD_SIZE));
}
+
+ if (cpu_has_feature(CPU_FTR_DEBUG_LVL_EXC))
+ patch_branch(&interrupt_base_book3e + (0x040 / 4) + 1,
+ (unsigned long)&exc_debug_debug_book3e, 0);
}
#else
#define exc_lvl_early_init()
--
1.7.3.4
^ permalink raw reply related
* [PATCH] powerpc/book3e: Fix CPU feature handling on 64-bit e5500
From: Kumar Gala @ 2011-04-06 12:29 UTC (permalink / raw)
To: linuxppc-dev
The CPU_FTRS_POSSIBLE and CPU_FTRS_ALWAYS defines did not encompass
e5500 CPU features when built for 64-bit. This causes issues with
cpu_has_feature() as it utilizes the POSSIBLE & ALWAYS defines as part
of its check.
Create a unique CPU_FTRS_E5500 (as its different from CPU_FTRS_E500MC),
created a new group for 64-bit Book3e based CPUs and add CPU_FTRS_E5500
to that group.
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
---
* This patch is intened to fix some issues and I'd like to see it in v2.6.39
- k
arch/powerpc/include/asm/cputable.h | 14 ++++++++++++++
arch/powerpc/kernel/cputable.c | 2 +-
2 files changed, 15 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/include/asm/cputable.h b/arch/powerpc/include/asm/cputable.h
index be3cdf9..9028a9e 100644
--- a/arch/powerpc/include/asm/cputable.h
+++ b/arch/powerpc/include/asm/cputable.h
@@ -386,6 +386,10 @@ extern const char *powerpc_base_platform;
CPU_FTR_MAYBE_CAN_NAP | CPU_FTR_NODSISRALIGN | \
CPU_FTR_L2CSR | CPU_FTR_LWSYNC | CPU_FTR_NOEXECUTE | \
CPU_FTR_DBELL)
+#define CPU_FTRS_E5500 (CPU_FTR_MAYBE_CAN_DOZE | CPU_FTR_USE_TB | \
+ CPU_FTR_MAYBE_CAN_NAP | CPU_FTR_NODSISRALIGN | \
+ CPU_FTR_L2CSR | CPU_FTR_LWSYNC | CPU_FTR_NOEXECUTE | \
+ CPU_FTR_DBELL | CPU_FTR_POPCNTB | CPU_FTR_POPCNTD)
#define CPU_FTRS_GENERIC_32 (CPU_FTR_COMMON | CPU_FTR_NODSISRALIGN)
/* 64-bit CPUs */
@@ -435,11 +439,15 @@ extern const char *powerpc_base_platform;
#define CPU_FTRS_COMPATIBLE (CPU_FTR_USE_TB | CPU_FTR_PPCAS_ARCH_V2)
#ifdef __powerpc64__
+#ifdef CONFIG_PPC_BOOK3E
+#define CPU_FTRS_POSSIBLE (CPU_FTRS_E5500)
+#else
#define CPU_FTRS_POSSIBLE \
(CPU_FTRS_POWER3 | CPU_FTRS_RS64 | CPU_FTRS_POWER4 | \
CPU_FTRS_PPC970 | CPU_FTRS_POWER5 | CPU_FTRS_POWER6 | \
CPU_FTRS_POWER7 | CPU_FTRS_CELL | CPU_FTRS_PA6T | \
CPU_FTR_1T_SEGMENT | CPU_FTR_VSX)
+#endif
#else
enum {
CPU_FTRS_POSSIBLE =
@@ -473,16 +481,21 @@ enum {
#endif
#ifdef CONFIG_E500
CPU_FTRS_E500 | CPU_FTRS_E500_2 | CPU_FTRS_E500MC |
+ CPU_FTRS_E5500 |
#endif
0,
};
#endif /* __powerpc64__ */
#ifdef __powerpc64__
+#ifdef CONFIG_PPC_BOOK3E
+#define CPU_FTRS_ALWAYS (CPU_FTRS_E5500)
+#else
#define CPU_FTRS_ALWAYS \
(CPU_FTRS_POWER3 & CPU_FTRS_RS64 & CPU_FTRS_POWER4 & \
CPU_FTRS_PPC970 & CPU_FTRS_POWER5 & CPU_FTRS_POWER6 & \
CPU_FTRS_POWER7 & CPU_FTRS_CELL & CPU_FTRS_PA6T & CPU_FTRS_POSSIBLE)
+#endif
#else
enum {
CPU_FTRS_ALWAYS =
@@ -513,6 +526,7 @@ enum {
#endif
#ifdef CONFIG_E500
CPU_FTRS_E500 & CPU_FTRS_E500_2 & CPU_FTRS_E500MC &
+ CPU_FTRS_E5500 &
#endif
CPU_FTRS_POSSIBLE,
};
diff --git a/arch/powerpc/kernel/cputable.c b/arch/powerpc/kernel/cputable.c
index c9b68d0..b9602ee 100644
--- a/arch/powerpc/kernel/cputable.c
+++ b/arch/powerpc/kernel/cputable.c
@@ -1973,7 +1973,7 @@ static struct cpu_spec __initdata cpu_specs[] = {
.pvr_mask = 0xffff0000,
.pvr_value = 0x80240000,
.cpu_name = "e5500",
- .cpu_features = CPU_FTRS_E500MC,
+ .cpu_features = CPU_FTRS_E5500,
.cpu_user_features = COMMON_USER_BOOKE,
.mmu_features = MMU_FTR_TYPE_FSL_E | MMU_FTR_BIG_PHYS |
MMU_FTR_USE_TLBILX,
--
1.7.3.4
^ permalink raw reply related
* Re: [RFC][PATCH] powerpc/book3e: Fix CPU feature handling on e5500
From: Kumar Gala @ 2011-04-06 12:26 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: linuxppc-dev
In-Reply-To: <20110406154147.f736d92e.sfr@canb.auug.org.au>
On Apr 6, 2011, at 12:41 AM, Stephen Rothwell wrote:
> Hi Kumar,
>=20
> On Wed, 6 Apr 2011 00:29:32 -0500 Kumar Gala =
<galak@kernel.crashing.org> wrote:
>>=20
>> * I'm concerned if its ok to assume 'enum' can handle a 64-bit mask =
or not.
>> I'm assuming this is the reason that we use a #define on =
__powerpc64__
>=20
> enums are *ints* and therefore 32 bit. gcc can cope, but warns about =
it
> (I think). So we must use the #define if any of the included bits are
> above 2^32.
Thanks, I'll rework the patch to use #define.
- k=
^ permalink raw reply
* Re: [PATCH 00/34] Make kernel build deterministic
From: Artem Bityutskiy @ 2011-04-06 9:25 UTC (permalink / raw)
To: Michal Marek
Cc: anil_ravindranath, mchehab, mac, aacraid, linux-mtd,
allan.stephens, hpa, t.sailer, gwingerde, x86, elf, cluster-devel,
ccaulfie, mingo, dougthompson, tipc-discussion, dwmw2,
linux-media, arnaud.giersch, linux-kbuild, IvDoorn, teigland,
tony.olech, apw, linux-hams, tglx, swhiteho, linux-arm-kernel,
linux-edac, jon.maloy, linux-scsi, netdev, Greg KH,
linux-wireless, linux-kernel, davem, linux-usb, James.Bottomley,
chuanxiao.dong, paulus, linuxppc-dev, bluesmoke-devel
In-Reply-To: <4D9C2D56.70700@suse.cz>
On Wed, 2011-04-06 at 11:07 +0200, Michal Marek wrote:
> > So additionally, I'd suggest:
> > 1. Instrument checkpatch.pl and make it err or warn on timestamps.
>
> This is patch 34/34 in this series: https://lkml.org/lkml/2011/4/5/198
Yeah, great, did not notice, thanks!
> > 2. Probably instrument linux-next to rise a warning when people break
> > this.
>
> I'm not sure if Stephen has that much spare time, and I don't think it
> is necessary. I think the checkpatch check is sufficient and I'll check
> myself occasionally.
Yes, that's fine, I just wanted to speak this out - there is a
probability that someone gets excited and creates some instrumentation
to kbuild to automatically detect bad things and then Stephen could
easily use that.
WRT "not necessary" - well, I think it is always better to cut bad
things before they are merged, rather than afterwards.
But anyway, let's forget about this.
--
Best Regards,
Artem Bityutskiy (Артём Битюцкий)
^ permalink raw reply
* Re: [PATCH 00/34] Make kernel build deterministic
From: Michal Marek @ 2011-04-06 9:23 UTC (permalink / raw)
To: Greg KH
Cc: anil_ravindranath, mchehab, x86, mac, aacraid, linux-mtd,
allan.stephens, hpa, netdev, t.sailer, gwingerde, IvDoorn, elf,
cluster-devel, ccaulfie, mingo, dougthompson, linux-media,
arnaud.giersch, linux-kbuild, teigland, tony.olech, apw,
linux-hams, tglx, swhiteho, linux-arm-kernel, linux-edac,
jon.maloy, linux-scsi, linuxppc-dev, linux-usb, linux-wireless,
linux-kernel, bluesmoke-devel, James.Bottomley, tipc-discussion,
chuanxiao.dong, paulus, dwmw2, davem
In-Reply-To: <20110405154918.GA31337@suse.de>
On 5.4.2011 17:49, Greg KH wrote:
> Very nice stuff. Do you want to take the individual patches through one
> of your trees, or do you mind if the subsystem maintainers take them
> through theirs?
I'd leave it up to the subsystem maintainers. I'll check once the merge
window opens and send the remaining patches to Linus directly.
Michal
^ permalink raw reply
* Re: [PATCH 00/34] Make kernel build deterministic
From: Michal Marek @ 2011-04-06 9:07 UTC (permalink / raw)
To: dedekind1
Cc: anil_ravindranath, mchehab, mac, aacraid, linux-mtd,
allan.stephens, hpa, t.sailer, gwingerde, x86, elf, cluster-devel,
ccaulfie, mingo, dougthompson, tipc-discussion, dwmw2,
linux-media, arnaud.giersch, linux-kbuild, IvDoorn, teigland,
tony.olech, apw, linux-hams, tglx, swhiteho, linux-arm-kernel,
linux-edac, jon.maloy, linux-scsi, netdev, Greg KH,
linux-wireless, linux-kernel, davem, linux-usb, James.Bottomley,
chuanxiao.dong, paulus, linuxppc-dev, bluesmoke-devel
In-Reply-To: <1302031447.2608.41.camel@koala>
On 5.4.2011 21:24, Artem Bityutskiy wrote:
> On Tue, 2011-04-05 at 08:49 -0700, Greg KH wrote:
>> On Tue, Apr 05, 2011 at 04:58:47PM +0200, Michal Marek wrote:
>>>
>>> Hi,
>>>
>>> this series makes it possible to build bit-identical kernel image and
>>> modules from identical sources. Of course the build is already
>>> deterministic in terms of behavior of the code, but the various
>>> timestamps embedded in the object files make it hard to compare two
>>> builds, for instance to verify that a makefile cleanup didn't
>>> accidentally change something. A prime example is /proc/config.gz, which
>>> has both a timestamp in the gzip header and a timestamp in the payload
>>> data. With this series applied, a script like this will produce
>>> identical kernels each time:
>>
>> Very nice stuff. Do you want to take the individual patches through one
>> of your trees, or do you mind if the subsystem maintainers take them
>> through theirs?
>
> But unfortunately, it is very easy to break this and for sure it'll be
> broken very soon.
I'm not so pessimistic. 34 patches and 57 files might sound like a lot,
but given that this has been accumulating since day one, the cleanup
should last for some time.
> So additionally, I'd suggest:
> 1. Instrument checkpatch.pl and make it err or warn on timestamps.
This is patch 34/34 in this series: https://lkml.org/lkml/2011/4/5/198
> 2. Probably instrument linux-next to rise a warning when people break
> this.
I'm not sure if Stephen has that much spare time, and I don't think it
is necessary. I think the checkpatch check is sufficient and I'll check
myself occasionally.
Michal
^ permalink raw reply
* Re: [PATCH 00/34] Make kernel build deterministic
From: Ingo Molnar @ 2011-04-06 9:01 UTC (permalink / raw)
To: Michal Marek
Cc: anil_ravindranath, mchehab, x86, mac, aacraid, linux-mtd,
allan.stephens, hpa, netdev, t.sailer, gwingerde, IvDoorn, elf,
cluster-devel, ccaulfie, mingo, dougthompson, linux-usb,
linux-media, arnaud.giersch, linux-kbuild, teigland, tony.olech,
apw, linux-hams, tglx, swhiteho, linux-arm-kernel, linux-edac,
jon.maloy, linux-scsi, linuxppc-dev, gregkh, linux-wireless,
linux-kernel, bluesmoke-devel, James.Bottomley, tipc-discussion,
chuanxiao.dong, paulus, dwmw2, davem
In-Reply-To: <1302015561-21047-1-git-send-email-mmarek@suse.cz>
* Michal Marek <mmarek@suse.cz> wrote:
>
> Hi,
>
> this series makes it possible to build bit-identical kernel image and
> modules from identical sources. Of course the build is already
> deterministic in terms of behavior of the code, but the various
> timestamps embedded in the object files make it hard to compare two
> builds, for instance to verify that a makefile cleanup didn't
> accidentally change something. A prime example is /proc/config.gz, which
> has both a timestamp in the gzip header and a timestamp in the payload
> data. With this series applied, a script like this will produce
> identical kernels each time:
>
> #!/bin/bash
> rm -rf /dev/shm/{source,build}{,1,2}
> export KCONFIG_NOTIMESTAMP=1
> export KBUILD_BUILD_TIMESTAMP='Sun May 1 12:00:00 CEST 2011'
> export KBUILD_BUILD_USER=user
> export KBUILD_BUILD_HOST=host
> export ROOT_DEV=FLOPPY
> for i in 1 2; do
> mkdir /dev/shm/source
> # randomize the inode order just for fun
> git ls-tree -r -z --name-only HEAD | sort -R -z | xargs -0 \
> cp --parents --target=/dev/shm/source
> pushd /dev/shm/source
> mkdir /dev/shm/build
> >/dev/shm/build/all.config
> for opt in GCOV_KERNEL UBIFS_FS_DEBUG; do
> echo "# CONFIG_$opt is not set" >>"/dev/shm/build"/all.config
> done
> make O="/dev/shm/build" KCONFIG_ALLCONFIG=1 allmodconfig
> make O="/dev/shm/build" -j64
> popd
> mv /dev/shm/source /dev/shm/source$i
> mv /dev/shm/build /dev/shm/build$i
> done
> diff -rq /dev/shm/build{1,2}
Nice!
Acked-by: Ingo Molnar <mingo@elte.hu>
> Unfortunatelly, this cannot be used to validate indentation-only
> patches, even if CONFIG_DEBUG_INFO is turned off. This is because of the
> __FILE__ and __LINE__ macros used in many places. For the same reason,
> the source and build directory needs to be the same, otherwise the
> results will differ.
Nor can it be used to validate untrusted patches in general: a subtle change
might be introduced in a piece of code that is dependent on a .config detail
that is off for that particular build.
But in the common case it's nice to be able to have deterministic/reproducable
builds.
Thanks,
Ingo
^ permalink raw reply
* Re: [PATCH 00/34] Make kernel build deterministic
From: Ingo Molnar @ 2011-04-06 8:57 UTC (permalink / raw)
To: Artem Bityutskiy
Cc: anil_ravindranath, mchehab, mac, aacraid, linux-mtd,
allan.stephens, hpa, t.sailer, gwingerde, x86, elf, cluster-devel,
ccaulfie, mingo, dougthompson, tipc-discussion, dwmw2,
linux-media, jon.maloy, arnaud.giersch, linux-kbuild, IvDoorn,
teigland, tony.olech, apw, linux-hams, tglx, swhiteho,
linux-arm-kernel, linux-edac, Michal Marek, linux-scsi, netdev,
Greg KH, linux-wireless, linux-kernel, davem, linux-usb,
James.Bottomley, chuanxiao.dong, paulus, linuxppc-dev,
bluesmoke-devel
In-Reply-To: <1302031447.2608.41.camel@koala>
* Artem Bityutskiy <dedekind1@gmail.com> wrote:
> On Tue, 2011-04-05 at 08:49 -0700, Greg KH wrote:
> > On Tue, Apr 05, 2011 at 04:58:47PM +0200, Michal Marek wrote:
> > >
> > > Hi,
> > >
> > > this series makes it possible to build bit-identical kernel image and
> > > modules from identical sources. Of course the build is already
> > > deterministic in terms of behavior of the code, but the various
> > > timestamps embedded in the object files make it hard to compare two
> > > builds, for instance to verify that a makefile cleanup didn't
> > > accidentally change something. A prime example is /proc/config.gz, which
> > > has both a timestamp in the gzip header and a timestamp in the payload
> > > data. With this series applied, a script like this will produce
> > > identical kernels each time:
> >
> > Very nice stuff. Do you want to take the individual patches through one
> > of your trees, or do you mind if the subsystem maintainers take them
> > through theirs?
>
> But unfortunately, it is very easy to break this and for sure it'll be
> broken very soon.
>
> So additionally, I'd suggest:
> 1. Instrument checkpatch.pl and make it err or warn on timestamps.
See the grandparent mail:
checkpatch: Warn about usage of __DATE__, __TIME__ and __TIMESTAMP__
Thanks,
Ingo
^ permalink raw reply
* Re: Revert 737a3bb9416ce2a7c7a4170852473a4fcc9c67e8 ?
From: Dave Airlie @ 2011-04-06 8:46 UTC (permalink / raw)
To: Uwe Kleine-König; +Cc: Greg KH, linuxppc-dev, LKML
In-Reply-To: <20110406084101.GB13963@pengutronix.de>
2011/4/6 Uwe Kleine-K=F6nig <u.kleine-koenig@pengutronix.de>:
> Hi Gabriel,
>
> On Tue, Apr 05, 2011 at 01:52:59AM +0200, Gabriel Paubert wrote:
>> I've had the following funny crashes on PPC machines, with
>> cataleptic X server as a consequence:
>>
>> kernel: [drm] Setting GART location based on new memory map
>> kernel: Oops: Exception in kernel mode, sig: 4 [#1]
>> kernel: CHRP
>> kernel: last sysfs file: /sys/devices/pci0001:01/0001:01:08.0/resource
>> kernel: NIP: c05648fc LR: c0226f58 CTR: 00000008
>> kernel: REGS: ddb53d20 TRAP: 0700 =A0 Not tainted =A0(2.6.38)
>> kernel: MSR: 00089032 <EE,ME,IR,DR> =A0CR: 48044482 =A0XER: 00000000
>> kernel: TASK =3D ddab12b0[3040] 'Xorg' THREAD: ddb52000
>> kernel: GPR00: c0226f34 ddb53dd0 ddab12b0 00000000 c0509e6c 00000000 000=
00000 00000000
>> kernel: GPR08: 00000000 00000000 00000000 00000000 28044488 101f3d8c bf8=
166b4 00002c00
>> kernel: GPR16: 101b9458 1006f1a0 101ebe0c 00000001 101ebe08 00000000 df9=
efc20 df9efc00
>> kernel: GPR24: c0591e54 80546440 ddacf660 df9efc00 c0506048 c0480210 00a=
00000 df9ef800
>> kernel: NIP [c05648fc] platform_device_register_resndata+0x4/0xa4
>> kernel: LR [c0226f58] radeon_cp_init+0xd08/0x10c4
>> kernel: Call Trace:
>> kernel: [ddb53dd0] [c0226f34] radeon_cp_init+0xce4/0x10c4 (unreliable)
>> kernel: [ddb53df0] [c020801c] drm_ioctl+0x2c0/0x3e4
>> kernel: [ddb53eb0] [c0091264] do_vfs_ioctl+0x674/0x710
>> kernel: [ddb53f10] [c0091340] sys_ioctl+0x40/0x70
>> kernel: [ddb53f40] [c00111a8] ret_from_syscall+0x0/0x38
>> kernel: --- Exception: c01 at 0xfc54a78
>> kernel: =A0 =A0 LR =3D 0xfc549dc
>> kernel: Instruction dump:
>> kernel: 736f2e31 32002f75 73722f6c 69622f6c 6962786b 6c617669 65722e73 6=
f2e3132
>> kernel: 006c6962 786b6266 696c652e 736f2e31 <002f7573> 722f6c69 622f6c69=
62786b62
>> kernel: ---[ end trace ed79daba161e31d9 ]---
>>
>> As you can see, the processor is trying to execute ASCII strings like
>> "/usr/lib/libxkb" and has trouble digesting them :-)
>>
>> The backtrace is actually missing radeon_cp_init_microcode and radeon_do=
_init_cp
>> which are inlined inside radeon_cp_init.
>>
>> The trouble is that radeon_cp_init_microcode calls platform_device_regis=
ter_simple
>> which is a simple inline wrapper around platform_device_register_resndat=
a, which
>> happens to be already freed and overwritten with something looking like =
a list
>> of filenames, since I have a non modular kernel.
>>
>> For now I have locally reverted 737a3bb9416ce2a7c7a4170852473a4fcc9c67e8
>> which simply added an _init_or_module section attribute to
>> platform_device_register_resndata, and X is up again...
>>
>> Now it may be that it is the ioctl that does not have the right to do
>> this. Actually I thought that the name radeon_cp that is registered ther=
e
>> would appear somwhere under /sys (or /proc) but failed to find it...
> I don't know for sure, but it looks strange to me that an ioctl can
> register a device. But the fear for such code in the kernel made me
> choose not to squash 737a3bb941 into 44f28bdea094. So my POV is that if
> the maintainer of the radeon driver thinks registering the device is OK,
> reverting 737a3bb9416 is fine for me.
This is the old DRM driver for radeon, which relies on userspace to
start X then calls the kernel
to initialise the hardware. Due to this model, there is no device we
can hang off (the PCI device
might already be bound to fbdev), so we are forced to create a
platform device to load the firmware.
So its ugly, unless someone can suggest a better device to hang things
off I don't know of another way.
Dave.
^ permalink raw reply
* Re: Revert 737a3bb9416ce2a7c7a4170852473a4fcc9c67e8 ?
From: Uwe Kleine-König @ 2011-04-06 8:41 UTC (permalink / raw)
To: Gabriel Paubert; +Cc: Greg KH, linuxppc-dev, LKML
In-Reply-To: <20110404235259.GA30132@iram.es>
Hi Gabriel,
On Tue, Apr 05, 2011 at 01:52:59AM +0200, Gabriel Paubert wrote:
> I've had the following funny crashes on PPC machines, with
> cataleptic X server as a consequence:
>
> kernel: [drm] Setting GART location based on new memory map
> kernel: Oops: Exception in kernel mode, sig: 4 [#1]
> kernel: CHRP
> kernel: last sysfs file: /sys/devices/pci0001:01/0001:01:08.0/resource
> kernel: NIP: c05648fc LR: c0226f58 CTR: 00000008
> kernel: REGS: ddb53d20 TRAP: 0700 Not tainted (2.6.38)
> kernel: MSR: 00089032 <EE,ME,IR,DR> CR: 48044482 XER: 00000000
> kernel: TASK = ddab12b0[3040] 'Xorg' THREAD: ddb52000
> kernel: GPR00: c0226f34 ddb53dd0 ddab12b0 00000000 c0509e6c 00000000 00000000 00000000
> kernel: GPR08: 00000000 00000000 00000000 00000000 28044488 101f3d8c bf8166b4 00002c00
> kernel: GPR16: 101b9458 1006f1a0 101ebe0c 00000001 101ebe08 00000000 df9efc20 df9efc00
> kernel: GPR24: c0591e54 80546440 ddacf660 df9efc00 c0506048 c0480210 00a00000 df9ef800
> kernel: NIP [c05648fc] platform_device_register_resndata+0x4/0xa4
> kernel: LR [c0226f58] radeon_cp_init+0xd08/0x10c4
> kernel: Call Trace:
> kernel: [ddb53dd0] [c0226f34] radeon_cp_init+0xce4/0x10c4 (unreliable)
> kernel: [ddb53df0] [c020801c] drm_ioctl+0x2c0/0x3e4
> kernel: [ddb53eb0] [c0091264] do_vfs_ioctl+0x674/0x710
> kernel: [ddb53f10] [c0091340] sys_ioctl+0x40/0x70
> kernel: [ddb53f40] [c00111a8] ret_from_syscall+0x0/0x38
> kernel: --- Exception: c01 at 0xfc54a78
> kernel: LR = 0xfc549dc
> kernel: Instruction dump:
> kernel: 736f2e31 32002f75 73722f6c 69622f6c 6962786b 6c617669 65722e73 6f2e3132
> kernel: 006c6962 786b6266 696c652e 736f2e31 <002f7573> 722f6c69 622f6c69 62786b62
> kernel: ---[ end trace ed79daba161e31d9 ]---
>
> As you can see, the processor is trying to execute ASCII strings like
> "/usr/lib/libxkb" and has trouble digesting them :-)
>
> The backtrace is actually missing radeon_cp_init_microcode and radeon_do_init_cp
> which are inlined inside radeon_cp_init.
>
> The trouble is that radeon_cp_init_microcode calls platform_device_register_simple
> which is a simple inline wrapper around platform_device_register_resndata, which
> happens to be already freed and overwritten with something looking like a list
> of filenames, since I have a non modular kernel.
>
> For now I have locally reverted 737a3bb9416ce2a7c7a4170852473a4fcc9c67e8
> which simply added an _init_or_module section attribute to
> platform_device_register_resndata, and X is up again...
>
> Now it may be that it is the ioctl that does not have the right to do
> this. Actually I thought that the name radeon_cp that is registered there
> would appear somwhere under /sys (or /proc) but failed to find it...
I don't know for sure, but it looks strange to me that an ioctl can
register a device. But the fear for such code in the kernel made me
choose not to squash 737a3bb941 into 44f28bdea094. So my POV is that if
the maintainer of the radeon driver thinks registering the device is OK,
reverting 737a3bb9416 is fine for me.
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | http://www.pengutronix.de/ |
^ permalink raw reply
* [PATCH] powerpc/kernel: Don't add disabled serial device
From: Prabhakar Kushwaha @ 2011-04-06 7:26 UTC (permalink / raw)
To: linuxppc-dev; +Cc: meet2prabhu, Prabhakar Kushwaha
serial port nodes with the property status="disabled" are not usable and so
avoid adding "disabled" port with the system.
Signed-off-by: Prabhakar Kushwaha <prabhakar@freescale.com>
---
Based upon git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git(branch master)
This patch is made to support "Re-organizing P1020RDB P2020RDB dts". Creation
of Serial port node doesn't follow of_platform_device_create() way which takes
care case status = "disabled".
arch/powerpc/kernel/legacy_serial.c | 8 +++++---
1 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/kernel/legacy_serial.c b/arch/powerpc/kernel/legacy_serial.c
index c834757..26566ca 100644
--- a/arch/powerpc/kernel/legacy_serial.c
+++ b/arch/powerpc/kernel/legacy_serial.c
@@ -330,9 +330,11 @@ void __init find_legacy_serial_ports(void)
if (!parent)
continue;
if (of_match_node(legacy_serial_parents, parent) != NULL) {
- index = add_legacy_soc_port(np, np);
- if (index >= 0 && np == stdout)
- legacy_serial_console = index;
+ if (of_device_is_available(np)) {
+ index = add_legacy_soc_port(np, np);
+ if (index >= 0 && np == stdout)
+ legacy_serial_console = index;
+ }
}
of_node_put(parent);
}
--
1.7.3
^ permalink raw reply related
* Re: [RFC][PATCH] powerpc/book3e: Fix CPU feature handling on e5500
From: Stephen Rothwell @ 2011-04-06 5:41 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <1302067772-32104-1-git-send-email-galak@kernel.crashing.org>
[-- Attachment #1: Type: text/plain, Size: 522 bytes --]
Hi Kumar,
On Wed, 6 Apr 2011 00:29:32 -0500 Kumar Gala <galak@kernel.crashing.org> wrote:
>
> * I'm concerned if its ok to assume 'enum' can handle a 64-bit mask or not.
> I'm assuming this is the reason that we use a #define on __powerpc64__
enums are *ints* and therefore 32 bit. gcc can cope, but warns about it
(I think). So we must use the #define if any of the included bits are
above 2^32.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* [RFC][PATCH] powerpc/book3e: Fix CPU feature handling on e5500
From: Kumar Gala @ 2011-04-06 5:29 UTC (permalink / raw)
To: linuxppc-dev
The CPU_FTRS_POSSIBLE and CPU_FTRS_ALWAYS defines did not encompass
e5500 CPU features when built for 64-bit. This causes issues with
cpu_has_feature() as it utilizes the POSSIBLE & ALWAYS defines as part
of its check.
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
---
* I'm concerned if its ok to assume 'enum' can handle a 64-bit mask or not.
I'm assuming this is the reason that we use a #define on __powerpc64__
arch/powerpc/include/asm/cputable.h | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/include/asm/cputable.h b/arch/powerpc/include/asm/cputable.h
index be3cdf9..8200e9d 100644
--- a/arch/powerpc/include/asm/cputable.h
+++ b/arch/powerpc/include/asm/cputable.h
@@ -434,7 +434,7 @@ extern const char *powerpc_base_platform;
CPU_FTR_PURR | CPU_FTR_REAL_LE | CPU_FTR_NO_SLBIE_B)
#define CPU_FTRS_COMPATIBLE (CPU_FTR_USE_TB | CPU_FTR_PPCAS_ARCH_V2)
-#ifdef __powerpc64__
+#if defined(__powerpc64__) && !defined(CONFIG_PPC_BOOK3E)
#define CPU_FTRS_POSSIBLE \
(CPU_FTRS_POWER3 | CPU_FTRS_RS64 | CPU_FTRS_POWER4 | \
CPU_FTRS_PPC970 | CPU_FTRS_POWER5 | CPU_FTRS_POWER6 | \
@@ -478,7 +478,7 @@ enum {
};
#endif /* __powerpc64__ */
-#ifdef __powerpc64__
+#if defined(__powerpc64__) && !defined(CONFIG_PPC_BOOK3E)
#define CPU_FTRS_ALWAYS \
(CPU_FTRS_POWER3 & CPU_FTRS_RS64 & CPU_FTRS_POWER4 & \
CPU_FTRS_PPC970 & CPU_FTRS_POWER5 & CPU_FTRS_POWER6 & \
--
1.7.3.4
^ permalink raw reply related
* Re: [PATCH] powerpc/book3e: Fix extlb size
From: Kumar Gala @ 2011-04-06 1:45 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
In-Reply-To: <1302046749.2549.186.camel@pasglop>
On Apr 5, 2011, at 6:39 PM, Benjamin Herrenschmidt wrote:
> On Tue, 2011-04-05 at 07:41 -0500, Kumar Gala wrote:
>>> Rework it to make it a bit clearer, and also correct. We want 3 save
>>> areas, each EX_TLB_SIZE _bytes_.
>>
>> Where does the 3 come from? I have a guess, and think its possible we
>> (FSL) want 4?
>
> Wrong guess :-) It's not about exception levels. It's about how much
> the handler can re-enter (2 with E.PT, 3 with virtual linear)
>
> For MC's, CRITs etc... which we don't support on Book3E 64-bit at this
> stage, you'll have to probably backup the whole area... that or move
> the TLB frame pointer SPR to a separate set of 3 levels, but then you'd
> have to fix the code that makes assumption about level 0 being at a
> fixed offset in the PACA and instead use alignment tricks. We need that
> because that's how we "reset" the TLB frame when a second level finds
> a fault.
>
> Cheers,
> Ben.
Gotcha, can we add a comment here about what the '3' is about.
- k
^ permalink raw reply
* Re: sdhc/mpc8536 - SDCard always detected like read-only
From: Wolfram Sang @ 2011-04-05 23:48 UTC (permalink / raw)
To: Carlos Roberto Moratelli; +Cc: linuxppc-dev
In-Reply-To: <1302031171.10112.66.camel@moratelli-host.digitel.com.br>
[-- Attachment #1: Type: text/plain, Size: 561 bytes --]
> sdhci@2e000 {
> compatible = "fsl,mpc8536-esdhc", "fsl,esdhc";
> reg = <0x2e000 0x1000>;
> interrupts = <72 0x2>;
> interrupt-parent = <&mpic>;
> /* Filled in by U-Boot */
> clock-frequency = <0>;
> };
Hmm, I am not too familiar with those SoCs, yet some 83xx needed
sdhci,wp-inverted;
here. Maybe yours, too? Would fit the symptoms.
Regards,
Wolfram
--
Pengutronix e.K. | Wolfram Sang |
Industrial Linux Solutions | http://www.pengutronix.de/ |
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCH] powerpc/book3e: Fix extlb size
From: Benjamin Herrenschmidt @ 2011-04-05 23:39 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <F4D669C2-BAD4-4B79-BE24-FB5AD2961160@kernel.crashing.org>
On Tue, 2011-04-05 at 07:41 -0500, Kumar Gala wrote:
> > Rework it to make it a bit clearer, and also correct. We want 3 save
> > areas, each EX_TLB_SIZE _bytes_.
>
> Where does the 3 come from? I have a guess, and think its possible we
> (FSL) want 4?
Wrong guess :-) It's not about exception levels. It's about how much
the handler can re-enter (2 with E.PT, 3 with virtual linear)
For MC's, CRITs etc... which we don't support on Book3E 64-bit at this
stage, you'll have to probably backup the whole area... that or move
the TLB frame pointer SPR to a separate set of 3 levels, but then you'd
have to fix the code that makes assumption about level 0 being at a
fixed offset in the PACA and instead use alignment tricks. We need that
because that's how we "reset" the TLB frame when a second level finds
a fault.
Cheers,
Ben.
^ permalink raw reply
* Combining multiple NAND MTDs
From: Barry G @ 2011-04-05 23:35 UTC (permalink / raw)
To: linuxppc-dev
Hello,
I have an 8308 using the fsl_elbc_nand NAND controller. I have
chip selects 2 & 3 hooked up to a single die multiple chip select NAND
chip. I have programmed u-boot and the kernel correctly and the
NAND "chips" are found:
NAND device: Manufacturer ID: 0xec, Chip ID: 0xd3 (Samsung NAND 1GiB
3,3V 8-bit)
eLBC NAND device at 0xe0600000, bank 1
NAND device: Manufacturer ID: 0xec, Chip ID: 0xd3 (Samsung NAND 1GiB
3,3V 8-bit)
eLBC NAND device at 0xe0608000, bank 2
The nand chips are correctly show up:
# cat /proc/mtd
dev: size erasesize name
mtd0: 02000000 00020000 "fe000000.flash"
mtd1: 40000000 00020000 "e0600000.flash"
mtd2: 40000000 00020000 "e0608000.flash"
(mtd0 is unrelated NOR part).
I want to run UBIFS on the combined 2 gigs of flash. Whats the best
way to do this?
I tried using the mtdconcat stuff and wrote a small driver
but I am not sure how to populate the mtd_info structure since do_probe_map
doesn't work with NAND AFAIK.
I see that fsl_elbc_select_chip says "hardware does not seem to support this".
Not sure if this is related.
I see some comments in mtd-physmap.txt about using multiple reg ranges?
Does this work with NAND?
Thanks for any pointers,
Barry
^ permalink raw reply
* Re: [PATCH 00/34] Make kernel build deterministic
From: Artem Bityutskiy @ 2011-04-05 19:24 UTC (permalink / raw)
To: Greg KH
Cc: anil_ravindranath, mchehab, mac, aacraid, linux-mtd,
allan.stephens, hpa, t.sailer, gwingerde, x86, elf, cluster-devel,
ccaulfie, mingo, dougthompson, dwmw2, linux-media, jon.maloy,
arnaud.giersch, linux-kbuild, IvDoorn, teigland, tony.olech, apw,
linux-hams, tglx, swhiteho, linux-arm-kernel, linux-edac,
Michal Marek, linux-scsi, netdev, linux-usb, linux-wireless,
linux-kernel, davem, James.Bottomley, tipc-discussion,
chuanxiao.dong, paulus, linuxppc-dev, bluesmoke-devel
In-Reply-To: <20110405154918.GA31337@suse.de>
On Tue, 2011-04-05 at 08:49 -0700, Greg KH wrote:
> On Tue, Apr 05, 2011 at 04:58:47PM +0200, Michal Marek wrote:
> >
> > Hi,
> >
> > this series makes it possible to build bit-identical kernel image and
> > modules from identical sources. Of course the build is already
> > deterministic in terms of behavior of the code, but the various
> > timestamps embedded in the object files make it hard to compare two
> > builds, for instance to verify that a makefile cleanup didn't
> > accidentally change something. A prime example is /proc/config.gz, which
> > has both a timestamp in the gzip header and a timestamp in the payload
> > data. With this series applied, a script like this will produce
> > identical kernels each time:
>
> Very nice stuff. Do you want to take the individual patches through one
> of your trees, or do you mind if the subsystem maintainers take them
> through theirs?
But unfortunately, it is very easy to break this and for sure it'll be
broken very soon.
So additionally, I'd suggest:
1. Instrument checkpatch.pl and make it err or warn on timestamps.
2. Probably instrument linux-next to rise a warning when people break
this.
--
Best Regards,
Artem Bityutskiy (Битюцкий Артём)
^ permalink raw reply
* Re: sdhc/mpc8536 - SDCard always detected like read-only
From: Carlos Roberto Moratelli @ 2011-04-05 19:19 UTC (permalink / raw)
To: Wolfram Sang; +Cc: linuxppc-dev
In-Reply-To: <20110405190204.GB12723@pengutronix.de>
Em Ter, 2011-04-05 às 21:02 +0200, Wolfram Sang escreveu:
> > Every idea or tip is apreciated.
>
> Please post your dts.
>
/*
* MPC8536 DS Device Tree Source
*
* Copyright 2008-2009 Freescale Semiconductor, Inc.
*
* This program is free software; you can redistribute it and/or modify
it
* under the terms of the GNU General Public License as published by
the
* Free Software Foundation; either version 2 of the License, or (at
your
* option) any later version.
*/
/dts-v1/;
/ {
model = "fsl,mpc8536ds";
compatible = "fsl,mpc8536ds";
#address-cells = <2>;
#size-cells = <2>;
aliases {
ethernet0 = &enet0;
serial0 = &serial0;
serial1 = &serial1;
pci1 = &pci1;
};
cpus {
#cpus = <1>;
#address-cells = <1>;
#size-cells = <0>;
PowerPC,8536@0 {
device_type = "cpu";
reg = <0>;
next-level-cache = <&L2>;
};
};
memory {
device_type = "memory";
reg = <0 0 0 0>; // Filled by U-Boot
};
soc@fffe00000 {
#address-cells = <1>;
#size-cells = <1>;
device_type = "soc";
compatible = "simple-bus";
ranges = <0x0 0xf 0xffe00000 0x100000>;
bus-frequency = <0>; // Filled out by uboot.
ecm-law@0 {
compatible = "fsl,ecm-law";
reg = <0x0 0x1000>;
fsl,num-laws = <12>;
};
ecm@1000 {
compatible = "fsl,mpc8536-ecm", "fsl,ecm";
reg = <0x1000 0x1000>;
interrupts = <17 2>;
interrupt-parent = <&mpic>;
};
memory-controller@2000 {
compatible = "fsl,mpc8536-memory-controller";
reg = <0x2000 0x1000>;
interrupt-parent = <&mpic>;
interrupts = <18 0x2>;
};
L2: l2-cache-controller@20000 {
compatible = "fsl,mpc8536-l2-cache-controller";
reg = <0x20000 0x1000>;
interrupt-parent = <&mpic>;
interrupts = <16 0x2>;
};
i2c@3000 {
#address-cells = <1>;
#size-cells = <0>;
cell-index = <0>;
compatible = "fsl-i2c";
reg = <0x3000 0x100>;
interrupts = <43 0x2>;
interrupt-parent = <&mpic>;
dfsrr;
hwmon@48 {
compatible = "national,lm73";
reg = <0x49>;
};
rtc@68 {
compatible = "rtc-m41t80,m41t82";
reg = <0x68>;
};
lm90@4C {
compatible = "lm90,adt7461";
reg = <0x4C>;
};
};
i2c@3100 {
#address-cells = <1>;
#size-cells = <0>;
cell-index = <1>;
compatible = "fsl-i2c";
reg = <0x3100 0x100>;
interrupts = <43 0x2>;
interrupt-parent = <&mpic>;
dfsrr;
sfp@50 {
compatible = "sfp_teste,sfp_teste";
reg = <0x50>;
};
bcm56334@44{
compatible = "bcm56334,bcm56334";
reg = <0x44>;
};
};
spi@7000 {
cell-index = <0>;
#address-cells = <1>;
#size-cells = <0>;
compatible = "fsl,mpc8536-espi";
reg = <0x7000 0x1000>;
interrupts = <59 0x2>;
interrupt-parent = <&mpic>;
fsl,espi-num-chipselects = <4>;
mode = "cpu";
};
dma@21300 {
#address-cells = <1>;
#size-cells = <1>;
compatible = "fsl,mpc8536-dma", "fsl,eloplus-dma";
reg = <0x21300 4>;
ranges = <0 0x21100 0x200>;
cell-index = <0>;
dma-channel@0 {
compatible = "fsl,mpc8536-dma-channel",
"fsl,eloplus-dma-channel";
reg = <0x0 0x80>;
cell-index = <0>;
interrupt-parent = <&mpic>;
interrupts = <20 2>;
};
dma-channel@80 {
compatible = "fsl,mpc8536-dma-channel",
"fsl,eloplus-dma-channel";
reg = <0x80 0x80>;
cell-index = <1>;
interrupt-parent = <&mpic>;
interrupts = <21 2>;
};
dma-channel@100 {
compatible = "fsl,mpc8536-dma-channel",
"fsl,eloplus-dma-channel";
reg = <0x100 0x80>;
cell-index = <2>;
interrupt-parent = <&mpic>;
interrupts = <22 2>;
};
dma-channel@180 {
compatible = "fsl,mpc8536-dma-channel",
"fsl,eloplus-dma-channel";
reg = <0x180 0x80>;
cell-index = <3>;
interrupt-parent = <&mpic>;
interrupts = <23 2>;
};
};
usb@22000 {
compatible = "fsl,mpc8536-usb2-mph", "fsl-usb2-mph";
reg = <0x22000 0x1000>;
#address-cells = <1>;
#size-cells = <0>;
interrupt-parent = <&mpic>;
interrupts = <28 0x2>;
phy_type = "ulpi";
};
usb@23000 {
compatible = "fsl,mpc8536-usb2-mph", "fsl-usb2-mph";
reg = <0x23000 0x1000>;
#address-cells = <1>;
#size-cells = <0>;
interrupt-parent = <&mpic>;
interrupts = <46 0x2>;
phy_type = "ulpi";
};
enet0: ethernet@24000 {
#address-cells = <1>;
#size-cells = <1>;
cell-index = <0>;
device_type = "network";
model = "eTSEC";
compatible = "gianfar";
reg = <0x24000 0x1000>;
ranges = <0x0 0x24000 0x1000>;
local-mac-address = [ 00 00 00 00 00 00 ];
interrupts = <29 2 30 2 34 2>;
interrupt-parent = <&mpic>;
tbi-handle = <&tbi0>;
phy-handle = <&phy1>;
phy-connection-type = "rgmii-id";
mdio@520 {
#address-cells = <1>;
#size-cells = <0>;
compatible = "fsl,gianfar-mdio";
reg = <0x520 0x20>;
phy0: ethernet-phy@0 {
interrupt-parent = <&mpic>;
interrupts = <10 0x1>;
reg = <0>;
device_type = "ethernet-phy";
};
phy1: ethernet-phy@1 {
interrupt-parent = <&mpic>;
interrupts = <10 0x1>;
reg = <1>;
device_type = "ethernet-phy";
};
tbi0: tbi-phy@11 {
reg = <0x11>;
device_type = "tbi-phy";
};
};
};
usb@2b000 {
compatible = "fsl,mpc8536-usb2-dr", "fsl-usb2-dr";
reg = <0x2b000 0x1000>;
#address-cells = <1>;
#size-cells = <0>;
interrupt-parent = <&mpic>;
interrupts = <60 0x2>;
dr_mode = "peripheral";
phy_type = "ulpi";
};
sdhci@2e000 {
compatible = "fsl,mpc8536-esdhc", "fsl,esdhc";
reg = <0x2e000 0x1000>;
interrupts = <72 0x2>;
interrupt-parent = <&mpic>;
/* Filled in by U-Boot */
clock-frequency = <0>;
};
serial0: serial@4500 {
cell-index = <0>;
device_type = "serial";
compatible = "ns16550";
reg = <0x4500 0x100>;
clock-frequency = <0>;
interrupts = <42 0x2>;
interrupt-parent = <&mpic>;
};
serial1: serial@4600 {
cell-index = <1>;
device_type = "serial";
compatible = "ns16550";
reg = <0x4600 0x100>;
clock-frequency = <0>;
interrupts = <42 0x2>;
interrupt-parent = <&mpic>;
};
crypto@30000 {
compatible = "fsl,sec3.0", "fsl,sec2.4", "fsl,sec2.2",
"fsl,sec2.1", "fsl,sec2.0";
reg = <0x30000 0x10000>;
interrupts = <45 2 58 2>;
interrupt-parent = <&mpic>;
fsl,num-channels = <4>;
fsl,channel-fifo-len = <24>;
fsl,exec-units-mask = <0x9fe>;
fsl,descriptor-types-mask = <0x3ab0ebf>;
};
sata@18000 {
compatible = "fsl,mpc8536-sata", "fsl,pq-sata";
reg = <0x18000 0x1000>;
cell-index = <1>;
interrupts = <74 0x2>;
interrupt-parent = <&mpic>;
};
sata@19000 {
compatible = "fsl,mpc8536-sata", "fsl,pq-sata";
reg = <0x19000 0x1000>;
cell-index = <2>;
interrupts = <41 0x2>;
interrupt-parent = <&mpic>;
};
global-utilities@e0000 { //global utilities block
compatible = "fsl,mpc8548-guts";
reg = <0xe0000 0x1000>;
fsl,has-rstcr;
};
mpic: pic@40000 {
clock-frequency = <0>;
interrupt-controller;
#address-cells = <0>;
#interrupt-cells = <2>;
reg = <0x40000 0x40000>;
compatible = "chrp,open-pic";
device_type = "open-pic";
big-endian;
};
msi@41600 {
compatible = "fsl,mpc8536-msi", "fsl,mpic-msi";
reg = <0x41600 0x80>;
msi-available-ranges = <0 0x100>;
interrupts = <
0xe0 0
0xe1 0
0xe2 0
0xe3 0
0xe4 0
0xe5 0
0xe6 0
0xe7 0>;
interrupt-parent = <&mpic>;
};
};
pci1: pcie@fffe0a000 {
compatible = "fsl,mpc8548-pcie";
device_type = "pci";
#interrupt-cells = <1>;
#size-cells = <2>;
#address-cells = <3>;
reg = <0xf 0xffe0a000 0 0x1000>;
bus-range = <0 0xff>;
ranges = <0x02000000 0 0xf8000000 0xc 0x10000000 0 0x08000000
0x01000000 0 0x00000000 0xf 0xffc10000 0 0x0010000>;
clock-frequency = <66666666>;
interrupt-parent = <&mpic>;
interrupts = <26 0x2>;
interrupt-map-mask = <0xf800 0 0 7>;
interrupt-map = <
/* IDSEL 0x0 */
0000 0 0 1 &mpic 0 1
0000 0 0 2 &mpic 1 1
0000 0 0 3 &mpic 2 1
0000 0 0 4 &mpic 3 1
>;
pcie@0 {
reg = <0 0 0 0 0>;
#size-cells = <2>;
#address-cells = <3>;
device_type = "pci";
ranges = <0x02000000 0 0xf8000000
0x02000000 0 0xf8000000
0 0x08000000
0x01000000 0 0x00000000
0x01000000 0 0x00000000
0 0x00010000>;
};
};
};
^ permalink raw reply
* Re: sdhc/mpc8536 - SDCard always detected like read-only
From: Wolfram Sang @ 2011-04-05 19:02 UTC (permalink / raw)
To: Carlos Roberto Moratelli; +Cc: linuxppc-dev
In-Reply-To: <1302028796.10112.59.camel@moratelli-host.digitel.com.br>
[-- Attachment #1: Type: text/plain, Size: 220 bytes --]
> Every idea or tip is apreciated.
Please post your dts.
--
Pengutronix e.K. | Wolfram Sang |
Industrial Linux Solutions | http://www.pengutronix.de/ |
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ 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