{pound} {pound} {pound}

Og woke up to the loud noise of the villagers pounding on his cave door.
He stumbled toward it, grabbing the four numbered bags that he knew were
needed at this time.

Opening the door, Og looked at the villagers, all expectant, wondering
where this week's kernels were, what was delaying them, as they needed
their weekly fix.

Reaching into the first bag, quite worn out with a faded "27" on the
outside of it, he grabbed one of the remaining kernels in there and
tossed it into the group.  A few small people at the back of the crowd
caught the kernel, and slowly walked off toward the village.  Og
wondered about these people, constantly relying on the old kernels to
save them for another day, while resisting the change to move on,
harboring some kind of strange reverence for this specific brand that Og
just could not understand.

Og then reached into a newer bag, with a big "32" on it, grabbed one
kernel from the many remaining in there, and threw it at the group.
Some people dressed in odd clothes, red swirls, green lizards on their
heads, red hats on others, and one remaining group who, despite it being
very unflattering, always wore dull brown clothing, picked up the kernel
and ran away with it back to the village.  They were going to use it to
send out to all of their sub-tribe members as they were the ones
responsible for handling this task.

The crowd was smaller now, and Og reached into a bag with a big "34" on
it.  It only had one kernel left in it and he threw it at the people,
saying, "this is the last one."  This seemed to stun the villagers who
grabbed it, as they had not been paying attention to what happened every
week.  The look in their eye ment that they were realizing they had a
long few days ahead of them as they prepared contingency plans due to
the lack of future kernels.

Og looked proudly at the remaining villagers in front of him.  These
were the strongest women, the most beautiful men, and the smartest
children around.  They ...
[ message continues ]

diff --git a/Makefile b/Makefile
index 554683d..73ab033 100644
--- a/Makefile
+++ b/Makefile
@@ -1,7 +1,7 @@
 VERSION = 2
 PATCHLEVEL = 6
 SUBLEVEL = 35
-EXTRAVERSION = .3
+EXTRAVERSION = .4
 NAME = Sheep on Meth
 
 # *DOCUMENTATION*
diff --git a/arch/arm/include/asm/ptrace.h b/arch/arm/include/asm/ptrace.h
index 9dcb11e..bf62c44 100644
--- a/arch/arm/include/asm/ptrace.h
+++ b/arch/arm/include/asm/ptrace.h
@@ -158,15 +158,24 @@ struct pt_regs {
  */
 static inline int valid_user_regs(struct pt_regs *regs)
 {
-	if (user_mode(regs) && (regs->ARM_cpsr & PSR_I_BIT) == 0) {
-		regs->ARM_cpsr &= ~(PSR_F_BIT | PSR_A_BIT);
-		return 1;
+	unsigned long mode = regs->ARM_cpsr & MODE_MASK;
+
+	/*
+	 * Always clear the F (FIQ) and A (delayed abort) bits
+	 */
+	regs->ARM_cpsr &= ~(PSR_F_BIT | PSR_A_BIT);
+
+	if ((regs->ARM_cpsr & PSR_I_BIT) == 0) {
+		if (mode == USR_MODE)
+			return 1;
+		if (elf_hwcap & HWCAP_26BIT && mode == USR26_MODE)
+			return 1;
 	}
 
 	/*
 	 * Force CPSR to something logical...
 	 */
-	regs->ARM_cpsr &= PSR_f | PSR_s | (PSR_x & ~PSR_A_BIT) | PSR_T_BIT | MODE32_BIT;
+	regs->ARM_cpsr &= PSR_f | PSR_s | PSR_x | PSR_T_BIT | MODE32_BIT;
 	if (!(elf_hwcap & HWCAP_26BIT))
 		regs->ARM_cpsr |= USR_MODE;
 
diff --git a/arch/arm/mach-ixp4xx/ixdp425-setup.c b/arch/arm/mach-ixp4xx/ixdp425-setup.c
index 827cbc4..ea9ee4e 100644
--- a/arch/arm/mach-ixp4xx/ixdp425-setup.c
+++ b/arch/arm/mach-ixp4xx/ixdp425-setup.c
@@ -100,6 +100,7 @@ ixdp425_flash_nand_cmd_ctrl(struct mtd_info *mtd, int cmd, unsigned int ctrl)
 
 static struct platform_nand_data ixdp425_flash_nand_data = {
 	.chip = {
+		.nr_chips		= 1,
 		.chip_delay		= 30,
 		.options		= NAND_NO_AUTOINCR,
 #ifdef CONFIG_MTD_PARTITIONS
diff --git a/arch/arm/mach-mx3/mach-qong.c b/arch/arm/mach-mx3/mach-qong.c
index e5b5b83..1f9363f 100644
--- a/arch/arm/mach-mx3/mach-qong.c
+++ b/arch/arm/mach-mx3/mach-qong.c
@@ -169,6 +169,7 @@ static void qong_nand_select_chip(struct mtd_info *mtd, int chip)
 
 ...
[ message continues ]

diff --git a/Makefile b/Makefile
index 948de60..9447d9d 100644
--- a/Makefile
+++ b/Makefile
@@ -1,7 +1,7 @@
 VERSION = 2
 PATCHLEVEL = 6
 SUBLEVEL = 27
-EXTRAVERSION = .52
+EXTRAVERSION = .53
 NAME = Trembling Tortoise
 
 # *DOCUMENTATION*
@@ -440,7 +440,11 @@ ifeq ($(config-targets),1)
 include $(srctree)/arch/$(SRCARCH)/Makefile
 export KBUILD_DEFCONFIG
 
-config %config: scripts_basic outputmakefile FORCE
+config: scripts_basic outputmakefile FORCE
+	$(Q)mkdir -p include/linux include/config
+	$(Q)$(MAKE) $(build)=scripts/kconfig $@
+
+%config: scripts_basic outputmakefile FORCE
 	$(Q)mkdir -p include/linux include/config
 	$(Q)$(MAKE) $(build)=scripts/kconfig $@
 
@@ -1602,7 +1606,11 @@ endif
 	$(Q)$(MAKE) $(build)=$(build-dir) $(target-dir)$(notdir $@)
 
 # Modules
-/ %/: prepare scripts FORCE
+/: prepare scripts FORCE
+	$(cmd_crmodverdir)
+	$(Q)$(MAKE) KBUILD_MODULES=$(if $(CONFIG_MODULES),1) \
+	$(build)=$(build-dir)
+%/: prepare scripts FORCE
 	$(cmd_crmodverdir)
 	$(Q)$(MAKE) KBUILD_MODULES=$(if $(CONFIG_MODULES),1) \
 	$(build)=$(build-dir)
diff --git a/arch/arm/include/asm/ptrace.h b/arch/arm/include/asm/ptrace.h
index b415c0e..1c0447e 100644
--- a/arch/arm/include/asm/ptrace.h
+++ b/arch/arm/include/asm/ptrace.h
@@ -124,15 +124,24 @@ struct pt_regs {
  */
 static inline int valid_user_regs(struct pt_regs *regs)
 {
-	if (user_mode(regs) && (regs->ARM_cpsr & PSR_I_BIT) == 0) {
-		regs->ARM_cpsr &= ~(PSR_F_BIT | PSR_A_BIT);
-		return 1;
+	unsigned long mode = regs->ARM_cpsr & MODE_MASK;
+
+	/*
+	 * Always clear the F (FIQ) and A (delayed abort) bits
+	 */
+	regs->ARM_cpsr &= ~(PSR_F_BIT | PSR_A_BIT);
+
+	if ((regs->ARM_cpsr & PSR_I_BIT) == 0) {
+		if (mode == USR_MODE)
+			return 1;
+		if (elf_hwcap & HWCAP_26BIT && mode == USR26_MODE)
+			return 1;
 	}
 
 	/*
 	 * Force CPSR to something logical...
 	 */
-	regs->ARM_cpsr &= PSR_f | PSR_s | (PSR_x & ~PSR_A_BIT) | PSR_T_BIT | MODE32_BIT;
+	regs->ARM_cpsr &= PSR_f | PSR_s | PSR_x | ...
[ message continues ]

[ removing Linus and Andrew not to pollute their mailboxes ]

Hi Og,


My villagers are nicer, only two have kindly asked if they would get their
bi-yearly lunch this week. I'll have to recall the recipe and prepare the

I certainly understand as I am one of them. The reason is precisely the one
that made you start this silly project : everyone has different expectations
on reliability. You don't put the same kernel on your desktop, on a SOHO
server, on an enterprise server, on an appliance or on a device you probably
won't be able to upgrade. And that's not only the kernel, it's true for all
software. The fact is that many issues fixed in recent kernels are specific
to those recent kernels. And we clearly observe that with the 2.6-stable
branches where the number of patches diminishes with time (I'm not comparing
branches between each other). I observe that even more with 2.4. Almost all
of the sensible fixes of the last 6 months did not apply to it (I just have
a few improbable ones in queue, though they're not easy to backport nor to
test).

Some of these many fixes in latest kernels may concern unreliable features
that were not present in earlier versions, some may simply be regressions.
When one kernel fits 100% of your needs, you don't want to take risks by
upgrading it if you know it is still supported, so you just apply fixes
from time to time. "If it ain't broke, don't fix it" !

And that works very well. I'm running 2.6.27.x on my desktop (2 months of
uptime, it's not up to date, but OK for what I do with it). Running 2.6.32.x
on my netbook because it needed updated drivers. I'm not tempted to update
it further simply because I use it to visit customers and I would not like
to waste time discovering that feature X or Y does not work anymore when I
need it (eventhough the risks are very low). I'm just applying the principle
above. So 2.6.32.x is perfect for it.

On an ARM-based development board, I have 2.6.35-rc2 which showed a nice
speed up and which was enough ...
[ message continues ]

Count me in with Willy as one of these small people, and for similar
reasons.  In an ideal world things might be different, but we do what we
can.

Thanks for keeping 2.6.27 going a while longer.

Chris

-- 
Chris Friesen
Software Developer
GENBAND
chris.friesen@genband.com
www.genband.com
--

[ message continues ]