diff mbox

Can PYSMAP_COMPAT go?

Message ID 20100420090408.GM19957@pengutronix.de
State New, archived
Headers show

Commit Message

Wolfram Sang April 20, 2010, 9:04 a.m. UTC 
> And this was i386, which unfortunately doesn't use the device-tree yet,
> although on these embedded SoC devices it really _should_ be doing so.
> And it doesn't have 'platform code' either.

Okay, so unless i386 gets device-tree support ;), how about at least this?

From: Wolfram Sang <w.sang@pengutronix.de>
Subject: [PATCH] mtd/physmap: Use sensible default value for MTD_PHYSMAP_LEN

Commit 73566edf9b91dd085ddb12033d0ea7288979dd10 made it necessary to be
0, but commit dcb3e137ce9be1dfc86e306182b23e3ae5e239c4 obsoleted that
requirement. Restore the old value to get a meaningful default.

Signed-off-by: Wolfram Sang <w.sang@pengutronix.de>
---
 drivers/mtd/maps/Kconfig |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

Comments

David Woodhouse April 20, 2010, 9:20 a.m. UTC | #1 
On Tue, 2010-04-20 at 11:04 +0200, Wolfram Sang wrote:
> Okay, so unless i386 gets device-tree support ;), how about at least
> this?

I'd love to see i386 get device-tree support. OLPC could benefit from it
immediately, and we could start using it on the embedded toys which are
coming out now.

I really don't think 0x4000000 is a 'sensible' default. Zero was better
-- at least the user has to set it to something else. With Hartley's
patch applied, the kernel will no longer crash if it tries to register a
device with zero length (and perhaps it could bail out even sooner if
the length is zero, rather than waiting and noticing the error?).
Wolfram Sang April 20, 2010, 9:48 a.m. UTC | #2 
On Tue, Apr 20, 2010 at 10:20:56AM +0100, David Woodhouse wrote:
> On Tue, 2010-04-20 at 11:04 +0200, Wolfram Sang wrote:
> > Okay, so unless i386 gets device-tree support ;), how about at least
> > this?
> 
> I'd love to see i386 get device-tree support. OLPC could benefit from it
> immediately, and we could start using it on the embedded toys which are
> coming out now.

True. It was the "unless" I was pointing for. I'd think it will take a long
while...

> I really don't think 0x4000000 is a 'sensible' default. Zero was better

Okay. I just wanted to remove the inconsistency (all these options could be 0
then). But it's probably now worth the fuss.
Wolfram Sang April 21, 2010, 9:19 a.m. UTC | #3 
> -- at least the user has to set it to something else. With Hartley's
> patch applied, the kernel will no longer crash if it tries to register a

BTW will you pick it up or who should do?
David Woodhouse April 21, 2010, 9:25 a.m. UTC | #4 
On Wed, 2010-04-21 at 11:19 +0200, Wolfram Sang wrote:
> > -- at least the user has to set it to something else. With Hartley's
> > patch applied, the kernel will no longer crash if it tries to register a
> 
> BTW will you pick it up or who should do?

I already did. Although it looks like I forgot to push.... fixed.
diff mbox

Patch

diff --git a/drivers/mtd/maps/Kconfig b/drivers/mtd/maps/Kconfig
index aa2807d..213c615 100644
--- a/drivers/mtd/maps/Kconfig
+++ b/drivers/mtd/maps/Kconfig
@@ -47,7 +47,7 @@  config MTD_PHYSMAP_START
 config MTD_PHYSMAP_LEN
 	hex "Physical length of flash mapping"
 	depends on MTD_PHYSMAP_COMPAT
-	default "0"
+	default "0x4000000"
 	help
 	  This is the total length of the mapping of the flash chips on
 	  your particular board. If there is space, or aliases, in the