[PATCH] ppc32: add 405EP cpu_spec entry

Andrew,

the following patch adds definition for PPC 405EP which was lost 
somehow during 2.4 -> 2.6 transition.

Recent change to arch/ppc/kernel/misc.S ("Fix incorrect CPU_FTR fixup 
usage for unified caches") triggered this bug and 405EP boards don't 
boot anymore.

Please, consider applying this patch before 2.6.12 release.

Signed-off-by: Eugene Surovegin <redacted>

diff --git a/arch/ppc/kernel/cputable.c b/arch/ppc/kernel/cputable.c
--- a/arch/ppc/kernel/cputable.c
+++ b/arch/ppc/kernel/cputable.c

@@ -838,6 +838,17 @@ struct cpu_spec	cpu_specs[] = {
 		.icache_bsize		= 32,
 		.dcache_bsize		= 32,
 	},
+	{	/* 405EP */
+		.pvr_mask		= 0xffff0000,
+		.pvr_value		= 0x51210000,
+		.cpu_name		= "405EP",
+		.cpu_features		= CPU_FTR_SPLIT_ID_CACHE |
+			CPU_FTR_USE_TB,
+		.cpu_user_features	= PPC_FEATURE_32 |
+			PPC_FEATURE_HAS_MMU | PPC_FEATURE_HAS_4xxMAC,
+		.icache_bsize		= 32,
+		.dcache_bsize		= 32,
+	},
 
 #endif /* CONFIG_40x */
 #ifdef CONFIG_44x

Linus,

You have applied this patch twice now.

- kumar

On Jun 6, 2005, at 8:20 PM, Eugene Surovegin wrote:

On Fri, 10 Jun 2005, Kumar Gala wrote:

You have applied this patch twice now.

Actually, looks like three times ;)

I think Andrew continually thinks it is dropped, because the patch ends up 
applying again, even though it got applied. So he keeps on re-sending it 
over and over again ;)

Andrew, I'll remove two extra copies. You please remove that patch from 
your queue..

		Linus

Linus Torvalds [off-list ref] wrote:

On Fri, 10 Jun 2005, Kumar Gala wrote:
 > 
 > You have applied this patch twice now.

 Actually, looks like three times ;)

Crap, sorry, that's happened three times now...  hmm..

 I think Andrew continually thinks it is dropped, because the patch ends up 
 applying again, even though it got applied. So he keeps on re-sending it 
 over and over again ;)

Fault-tolerance!

On Fri, 10 Jun 2005, Andrew Morton wrote:

quoted

 I think Andrew continually thinks it is dropped, because the patch ends up 
 applying again, even though it got applied. So he keeps on re-sending it 
 over and over again ;)

Fault-tolerance!

Indeed.

However, I'm sure there's a better way. For example, something like "try
if the patch applied reversed" might be a good idea to at least mark it
for questioning.

Something like

	patch -spfR  --dry-run --fuzz=0 < patch
	if [ $? -eq 0 ]; then
		echo Hmm.. patch might be applied already
		exit 1
	fi

might be a starting point...

		Linus