From nils.faerber at kernelconcepts.de  Fri Sep  1 07:41:12 2006
From: nils.faerber at kernelconcepts.de (Nils Faerber)
Date: Fri, 01 Sep 2006 13:41:12 +0200
Subject: Problem with strata flash in 2 x 16bit config
Message-ID: <44F81C58.1030203@kernelconcepts.de>

Hi!
I have a little bit of an issue here and am already quite despereate...

We have a PXA270 based board here running a Linux kernel 2.6.10 which is
to almost 100% based on the Mainstone kernel. Also the board is mostly
based on Mainstone.

The board contains, besides other less important stuff, two Intel Strata
 flash chips (64MByte each) in 32-bit (2 x 16) data bus configuration
connected to CS0 and the appropriate address bus lines. The address bus
and CS0 are both equally connected to both flash chips. The data bus is
connected D0-D15 to chip one and D16-D31 to chip two.

In general the flash chips are detected properly and can be read
properly (programmed via BLOB). But as soon as I write to a flash
partition from a booted Linux system I get chip timeouts and other MTD
errors. (see buttom of email for some log output...)

According to other mailinglists and patches this configuration should be
supported by MTD if 32-bit banksize (CONFIG_MTD_MAP_BANK_WIDTH_4) and
CONFIG_MTD_CFI_I2 is enabled, correct?
This is enabled in our kernel config.

Is there anything else that needs to be taken care of to properly enable
32-bit data bus width with two chips? The bankwidth is detected
properly, but just to make sure I already hard-coded this in the
map_info struct. But still no proper write.

This is the first time we use a 32-bit configuration so I am not very
experienced with this - the 16-bit config worked quite well ;)


If anyone has a hint for me I would be very happy ;)
And if desired I would gladly post my experience and potential solution
here too.

Many thanks in advance!

Cheers
  nils faerber


Some logged messages...
Kernel startup:
(yes, I know, we did not make that kernel, the author used the PXA270
on-chip map-driver as template...)
---
Probing Intel PXA27x On-Chip ROM at physical address 0x00000000 (32-bit
bankwidth)
Intel PXA27x On-Chip ROM: Found 2 x16 devices at 0x0 in 32-bit bank
 Intel/Sharp Extended Query Table at 0x010A
 Intel/Sharp Extended Query Table at 0x010A
 Intel/Sharp Extended Query Table at 0x010A
Using buffer write method
cfi_cmdset_0001: Erase suspend on write enabled
No RedBoot partition table detected in Intel PXA27x On-Chip ROM
cmdlinepart partition parsing not available
Using static partitions on Intel PXA27x On-Chip ROM
Creating 4 MTD partitions on "Intel PXA27x On-Chip ROM":
0x00000000-0x00040000 : "Bootloader"
0x00040000-0x00240000 : "Kernel"
0x00240000-0x01240000 : "Filesystem"
0x01240000-0x01740000 : "User"
---


Writing to root-fs:
---
[root at Linux /root]#dd if=/dev/zero of=./blub2 bs=1k count=1k
Waiting for chip to be ready timed out. Status afd908
Write of 68 bytes at 0x00dd2f0c failed. returned -5, retlen 0
Not marking the space at 0x00dd2f0c as dirty because the flash driver
returned retlen zero
Waiting for chip to be ready timed out. Status afd908
Write of 68 bytes at 0x00dd2f0c failed. returned -5, retlen 0
Not marking the space at 0x00dd2f0c as dirty because the flash driver
returned retlen zero
dd: ./blub2: Input/output error
---
and from here on the root-fs is damaged.


Writing to the fourth yet unused "User" partition:
---
[root at Linux /root]#dd if=/dev/zero of=/dev/mtdblock3 bs=1k count=1
1+0 records in
1+0 records out
[root at Linux /root]#dmesg
Node CRC 00800080 != calculated CRC 4bf2ff8d for node at 000d4704
-sh: dmesg: Input/output error
---
and after that the root-fs is effectively broken. Sometimes it works
again after reboot.




From justin at redfish-group.com  Fri Sep  1 11:48:51 2006
From: justin at redfish-group.com (Justin Clacherty)
Date: Sat, 02 Sep 2006 01:48:51 +1000
Subject: Problem with strata flash in 2 x 16bit config
In-Reply-To: <44F81C58.1030203@kernelconcepts.de>
References: <44F81C58.1030203@kernelconcepts.de>
Message-ID: <44F85663.7090401@redfish-group.com>

Nils Faerber wrote:
> Node CRC 00800080 != calculated CRC 4bf2ff8d for node at 000d4704
> -sh: dmesg: Input/output error
Is it P30 flash?  I've seen something similar if you don't unlock the flash.

Justin.




From davidsk13 at o2.pl  Sat Sep  2 20:51:13 2006
From: davidsk13 at o2.pl (davidsk13 at o2.pl)
Date: Sun, 03 Sep 2006 02:51:13 +0200
Subject: =?iso-8859-2?Q?Good_day!Can_we_meet=3F?=
Message-ID: <20060903005113.D3262214010@rekin14.go2.pl>

GOOD DAY Sir/madam, 

I got your contact during my search on the Internet. My name is Mr.Kelvin Davids. I am a manager ofan Internationally reputable bank here in Uk . I am a Jamaican by birth married with two kids. I am writing to solicit your assistance in the transfer of USD 10,550.000.00 equivalent. 

This fund is the excess of what my branch in which I am the manger made as profit during the last year. I have already submitted an approved End of the Year report for the year 2005 to my Head Office and they will never know of this Excess. I have since then, placed this amount of USD 10,550.000.00 on a SUSPENCE ACCOUNT without a beneficiary. 

As an officer of the bank, I cannot be directly connected to this money thus I am impelled to request for your assistance to receive this money into your bank account. I intend to part 30% of this fund to you while 70% shall be for me. I do need to stress that there are practically no risk involved in this. The transaction is going to be d! one within the law of the land. All I need from you is to stand as the original depositor of this fund. If you accept this offer, I will appreciate your timely response to this private email address including your telephone number/s. With regards, 

Mr Kelvin Davids.






From davidsk32 at o2.pl  Sat Sep  2 22:59:38 2006
From: davidsk32 at o2.pl (davidsk32 at o2.pl)
Date: Sun, 03 Sep 2006 04:59:38 +0200
Subject: =?iso-8859-2?Q?Good_day!Can_we_meet=3F?=
Message-ID: <20060903025938.D042E45C06D@rekin22.go2.pl>

GOOD DAY Sir/madam, 

I got your contact during my search on the Internet. My name is Mr.Kelvin Davids. I am a manager ofan Internationally reputable bank here in Uk . 

I am a Jamaican by birth married with two kids. I am writing to solicit your assistance in the transfer of USD 10,550.000.00 equivalent. This fund is the excess of what my branch in which I am the manger made as profit during the last year. I have already submitted an approved End of the Year report for the year 2005 to my Head Office and they will never know of this Excess. I have since then, placed this amount of USD 10,550.000.00 on a SUSPENCE ACCOUNT without a beneficiary. 

As an officer of the bank, I cannot be directly connected to this money thus I am impelled to request for your assistance to receive this money into your bank account. I intend to part 30% of this fund to you while 70% shall be for me. I do need to stress that there are practically no risk involved in this. The transaction is going to be d! one within the law of the land. All I need from you is to stand as the original depositor of this fund. If you accept this offer, I will appreciate your timely response to this private email address including your telephone number/s. 

With regards, 
Mr Kelvin Davids.






From justin at redfish-group.com  Sun Sep  3 00:20:13 2006
From: justin at redfish-group.com (Justin Clacherty)
Date: Sun, 03 Sep 2006 14:20:13 +1000
Subject: Static partitions
Message-ID: <44FA57FD.8070003@redfish-group.com>

Hi,

I've managed to get mtd working on my PXA270 board.  I've used the 
mainstone port as a template for my board port and was wondering why the 
static partitions need to be defined twice.  Mainstone has it defined in 
arch/arm/mach-pxa/mainstone.c and in drivers/mt d/maps/mainstone-flash.c.

Regards,
Justin.



From nils.faerber at kernelconcepts.de  Sun Sep  3 16:21:05 2006
From: nils.faerber at kernelconcepts.de (Nils Faerber)
Date: Sun, 03 Sep 2006 22:21:05 +0200
Subject: Problem with strata flash in 2 x 16bit config
In-Reply-To: <44F85663.7090401@redfish-group.com>
References: <44F81C58.1030203@kernelconcepts.de>
	<44F85663.7090401@redfish-group.com>
Message-ID: <44FB3931.6040605@kernelconcepts.de>

Justin Clacherty schrieb:
> Nils Faerber wrote:
>> Node CRC 00800080 != calculated CRC 4bf2ff8d for node at 000d4704
>> -sh: dmesg: Input/output error
> Is it P30 flash?  I've seen something similar if you don't unlock the flash.

Yes, that's correct!
The board has two P30 flashes.

The BLOB bootloader flashes the complete 16MB root partition first.
After that, if I try to write to root using Linux-MTD, I get those errors.
But I would expect that BLOB has already unlocked the complete 16MB for
writing the image.

And even if some are still locked, how do I unlock them?

> Justin.
Cheers
  nils faerber

-- 
kernel concepts GbR      Tel: +49-271-771091-12
Dreisbachstr. 24         Fax: +49-271-771091-19
D-57250 Netphen          Mob: +49-176-21024535
--



From justin at redfish-group.com  Sun Sep  3 17:33:19 2006
From: justin at redfish-group.com (Justin Clacherty)
Date: Mon, 04 Sep 2006 07:33:19 +1000
Subject: Problem with strata flash in 2 x 16bit config
In-Reply-To: <44FB3931.6040605@kernelconcepts.de>
References: <44F81C58.1030203@kernelconcepts.de>
	<44F85663.7090401@redfish-group.com>
	<44FB3931.6040605@kernelconcepts.de>
Message-ID: <44FB4A1F.4040806@redfish-group.com>

Nils Faerber wrote:
> But I would expect that BLOB has already unlocked the complete 16MB for
> writing the image.
>   
Not sure how blob works with this, I'm using u-boot.
> And even if some are still locked, how do I unlock them?
>   
This would need to be done in blob so that it's available to the kernel 
for mounting.

When I get in to work this morning I'll try mounting flash with it 
locked to see if that is the error I was receiving.

Justin.




From aubreylee at gmail.com  Mon Sep  4 04:46:44 2006
From: aubreylee at gmail.com (Aubrey)
Date: Mon, 4 Sep 2006 16:46:44 +0800
Subject: [PATCH] Fill more device IDS in the structure of m25p80 driver
Message-ID: <6d6a94c50609040146k3538ef21x2a6d426f344f1e2e@mail.gmail.com>

Hi all,

the structure:
struct flash_info __devinitdata m25p_data [] = {
/* REVISIT: fill in JEDEC ids, for parts that have them */
...
};

has a bunch of missing fields (like the JEDEC ids indicated) ... this
causes problems when actually trying to use some ST parts as it gets
detected incorrectly

The following is the patch.
----------------------------------------------------------------------
Signed-off-by: Aubrey L1 <aubreylee at gmail.com>
---

 * Fill more device IDS in the structure of m25p80 driver.
diff --git a/drivers/mtd/devices/m25p80.c b/drivers/mtd/devices/m25p80.c
index a846614..ef4a731 100644
--- a/drivers/mtd/devices/m25p80.c
+++ b/drivers/mtd/devices/m25p80.c
@@ -406,13 +406,13 @@ struct flash_info {

 static struct flash_info __devinitdata m25p_data [] = {
        /* REVISIT: fill in JEDEC ids, for parts that have them */
-       { "m25p05", 0x05, 0x0000, 32 * 1024, 2 },
-       { "m25p10", 0x10, 0x0000, 32 * 1024, 4 },
-       { "m25p20", 0x11, 0x0000, 64 * 1024, 4 },
-       { "m25p40", 0x12, 0x0000, 64 * 1024, 8 },
+       { "m25p05", 0x05, 0x2010, 32 * 1024, 2 },
+       { "m25p10", 0x10, 0x2011, 32 * 1024, 4 },
+       { "m25p20", 0x11, 0x2012, 64 * 1024, 4 },
+       { "m25p40", 0x12, 0x2013, 64 * 1024, 8 },
        { "m25p80", 0x13, 0x0000, 64 * 1024, 16 },
-       { "m25p16", 0x14, 0x0000, 64 * 1024, 32 },
-       { "m25p32", 0x15, 0x0000, 64 * 1024, 64 },
+       { "m25p16", 0x14, 0x2015, 64 * 1024, 32 },
+       { "m25p32", 0x15, 0x2016, 64 * 1024, 64 },
        { "m25p64", 0x16, 0x2017, 64 * 1024, 128 },
 };

Regards,
-Aubrey



From jwboyer at gmail.com  Mon Sep  4 09:05:59 2006
From: jwboyer at gmail.com (Josh Boyer)
Date: Mon, 4 Sep 2006 08:05:59 -0500
Subject: [PATCH] Fill more device IDS in the structure of m25p80 driver
In-Reply-To: <6d6a94c50609040146k3538ef21x2a6d426f344f1e2e@mail.gmail.com>
References: <6d6a94c50609040146k3538ef21x2a6d426f344f1e2e@mail.gmail.com>
Message-ID: <625fc13d0609040605o313f3910yca80cb29b76ebc60@mail.gmail.com>

On 9/4/06, Aubrey <aubreylee at gmail.com> wrote:
> Hi all,
>
> the structure:
> struct flash_info __devinitdata m25p_data [] = {
> /* REVISIT: fill in JEDEC ids, for parts that have them */
> ...
> };
>
> has a bunch of missing fields (like the JEDEC ids indicated) ... this
> causes problems when actually trying to use some ST parts as it gets
> detected incorrectly
>
> The following is the patch.

The patch appears to have corrupted whitespace.  Your mailer probably
mangled it.  Care to try and fix it and resend?

thx,
josh



From andre at bluewatersys.com  Mon Sep  4 17:49:10 2006
From: andre at bluewatersys.com (Andre Renaud)
Date: Tue, 05 Sep 2006 09:49:10 +1200
Subject: MLC Nand Flash
Message-ID: <44FC9F56.3080702@bluewatersys.com>

Does anyone know if there is support for MLC (Multi Level Cell) NAND
flash chips in MTD?

Thanks,
Andre

-- 
Bluewater Systems Ltd - ARM Technology Solutions Centre

       Andre Renaud                             Bluewater Systems Ltd
Phone: +64 3 3779127 (Aus 1 800 148 751)        Level 17, 119 Armagh St
Fax:   +64 3 3779135                            PO Box 13889
Email: arenaud at bluewatersys.com                 Christchurch
Web:   http://www.bluewatersys.com              New Zealand



From davide.cascone at st.com  Tue Sep  5 08:37:41 2006
From: davide.cascone at st.com (Davide CASCONE)
Date: Tue, 5 Sep 2006 14:37:41 +0200
Subject: JFFS2 ECC options
Message-ID: <000f01c6d0e8$145e1ce0$d204960a@nap.st.com>


I'm working with JFFS2 on a NAND device. In order to disable the software ECC is it enough to set the mtd field "nand.eccmode" to "NAND_ECC_NONE"? 
If I do this, I have some CRC errors if JFFS2 file system includes a bad block. Is it right? Does the CRC check depend on the ECC options?

In order to use the summary support, is it enough to set the macro "CONFIG_JFFS2_SUMMARY" in the file ".config"? Do I have to re-make the file system image (that I create using the mkfs.jffs2 utility) in order to use it with the summary support?

Thanks in advance,
Davide





From havasi at inf.u-szeged.hu  Tue Sep  5 10:19:09 2006
From: havasi at inf.u-szeged.hu (Ferenc Havasi)
Date: Tue, 05 Sep 2006 16:19:09 +0200
Subject: [PATCH] Summary fix
Message-ID: <44FD875D.6080808@inf.u-szeged.hu>

Dear All!

We've fixed a bug in summary collecting (JFFS2). I've commited into my
git tree:

http://git.infradead.org/?p=users/havasi/summary-collecting-fix-2.6.git

Ferenc




From dhowells at redhat.com  Tue Sep  5 15:18:06 2006
From: dhowells at redhat.com (David Howells)
Date: Tue, 05 Sep 2006 20:18:06 +0100
Subject: [PATCH] Make MTD chardev mmap available under some circumstances
Message-ID: <24712.1157483886@warthog.cambridge.redhat.com>


Make it possible to mmap MTD chardevs directly or by copy on a NOMMU system.
This is done by:

 (1) Presenting backing device capabilities for MTD character device files to
     allow NOMMU mmap to do direct mapping where possible.

     Three BDIs are made available:

     (a) One to indicate that a device supports direct mapping with both read
     	 and write capability (eg: a RAM device).

     (b) One to indicate that a device supports direct mapping, but only with
     	 read capability (eg: a ROM device).

     (c) One to indicate that a device does not support direct mapping (eg: a
     	 NAND flash device).

     In all three cases, private mmap by copying *is* supported, which means
     that such as NAND flashes *can* be mapped privately.  The NOMMU mmap
     routine allocates some memory to hold the private mapping and then reads
     the data from the device into it.  This memory is then presented as the
     mapping.  This is *not* currently possible under MMU conditions; to
     support that will require changes to mm/mmap.c.

 (2) Providing a get_unmapped_area() op to permit the device driver to specify
     the whereabouts of the mappable data.

     If the get_unmapped_area() op is not present in mtd_info, -ENOSYS is
     returned to the caller to indicate that mapping isn't actually supported.
     The device driver may also return -ENOSYS if it doesn't want to handle the
     mapping.

 (3) Have the MTD partitioning code adjust and transfer the get_unmapped_area()
     op to the master device.

The MTDRAM driver has been modified to support this new op, and thus is able to
support full readable, writable and executable shared and private mappings.


This can be seen in the following strace excerpt:

	open("/dev/mtd0", O_RDWR)               = 4
	mmap2(NULL, 16384, PROT_READ|PROT_WRITE, MAP_SHARED, 4, 0) = 0xc0c00000
	mmap2(NULL, 16384, PROT_READ|PROT_WRITE, MAP_SHARED, 4, 0) = 0xc0c00000

which results in the following appearing in the /proc/pid/maps file:

	c0c00000-c0c04000 rw-S 00000000 00:0b 8561016    /dev/mtd0
	c0c00000-c0c04000 rw-S 00000000 00:0b 8561016    /dev/mtd0

Signed-Off-By: David Howells <dhowells at redhat.com>
---

 drivers/mtd/devices/mtdram.c |   14 ++++++
 drivers/mtd/mtdchar.c        |   99 ++++++++++++++++++++++++++++++++++++++++++
 drivers/mtd/mtdpart.c        |   13 ++++++
 include/linux/mtd/mtd.h      |    9 ++++
 4 files changed, 134 insertions(+), 1 deletions(-)

diff --git a/drivers/mtd/devices/mtdram.c b/drivers/mtd/devices/mtdram.c
index e427c82..438cdb9 100644
--- a/drivers/mtd/devices/mtdram.c
+++ b/drivers/mtd/devices/mtdram.c
@@ -62,6 +62,19 @@ static void ram_unpoint(struct mtd_info 
 {
 }
 
+/*
+ * Allow NOMMU mmap() to directly map the device (if not NULL)
+ * - return the address to which the offset maps
+ * - return -ENOSYS to indicate refusal to do the mapping
+ */
+static unsigned long ram_get_unmapped_area(struct mtd_info *mtd,
+					   unsigned long len,
+					   unsigned long offset,
+					   unsigned long flags)
+{
+	return (unsigned long) mtd->priv + offset;
+}
+
 static int ram_read(struct mtd_info *mtd, loff_t from, size_t len,
 		size_t *retlen, u_char *buf)
 {
@@ -113,6 +126,7 @@ int mtdram_init_device(struct mtd_info *
 	mtd->erase = ram_erase;
 	mtd->point = ram_point;
 	mtd->unpoint = ram_unpoint;
+	mtd->get_unmapped_area = ram_get_unmapped_area;
 	mtd->read = ram_read;
 	mtd->write = ram_write;
 
diff --git a/drivers/mtd/mtdchar.c b/drivers/mtd/mtdchar.c
index fb8b4f7..9742570 100644
--- a/drivers/mtd/mtdchar.c
+++ b/drivers/mtd/mtdchar.c
@@ -12,6 +12,7 @@ #include <linux/kernel.h>
 #include <linux/module.h>
 #include <linux/slab.h>
 #include <linux/sched.h>
+#include <linux/backing-dev.h>
 
 #include <linux/mtd/mtd.h>
 #include <linux/mtd/compatmac.h>
@@ -20,6 +21,35 @@ #include <asm/uaccess.h>
 
 static struct class *mtd_class;
 
+/*
+ * backing device capabilities for non-mappable devices (such as NAND flash)
+ * - permits private mappings, copies are taken of the data
+ */
+static struct backing_dev_info mtd_bdi_unmappable = {
+	.capabilities	= BDI_CAP_MAP_COPY,
+};
+
+/*
+ * backing device capabilities for R/O mappable devices (such as ROM)
+ * - permits private mappings, copies are taken of the data
+ * - permits non-writable shared mappings
+ */
+static struct backing_dev_info mtd_bdi_ro_mappable = {
+	.capabilities	= (BDI_CAP_MAP_COPY | BDI_CAP_MAP_DIRECT |
+			   BDI_CAP_EXEC_MAP | BDI_CAP_READ_MAP),
+};
+
+/*
+ * backing device capabilities for writable mappable devices (such as RAM)
+ * - permits private mappings, copies are taken of the data
+ * - permits non-writable shared mappings
+ */
+static struct backing_dev_info mtd_bdi_rw_mappable = {
+	.capabilities	= (BDI_CAP_MAP_COPY | BDI_CAP_MAP_DIRECT |
+			   BDI_CAP_EXEC_MAP | BDI_CAP_READ_MAP |
+			   BDI_CAP_WRITE_MAP),
+};
+
 static void mtd_notify_add(struct mtd_info* mtd)
 {
 	if (!mtd)
@@ -106,9 +136,19 @@ static int mtd_open(struct inode *inode,
 	if (!mtd)
 		return -ENODEV;
 
-	if (MTD_ABSENT == mtd->type) {
+	switch (mtd->type) {
+	case MTD_ABSENT:
 		put_mtd_device(mtd);
 		return -ENODEV;
+	case MTD_RAM:
+		file->f_mapping->backing_dev_info = &mtd_bdi_rw_mappable;
+		break;
+	case MTD_ROM:
+		file->f_mapping->backing_dev_info = &mtd_bdi_ro_mappable;
+		break;
+	default:
+		file->f_mapping->backing_dev_info = &mtd_bdi_unmappable;
+		break;
 	}
 
 	/* You can't open it RW if it's not a writeable device */
@@ -763,6 +803,59 @@ #endif
 	return ret;
 } /* memory_ioctl */
 
+/*
+ * try to determine where a shared mapping can be made
+ * - only supported for NOMMU at the moment (MMU can't doesn't copy private
+ *   mappings)
+ */
+#ifndef CONFIG_MMU
+static unsigned long mtd_get_unmapped_area(struct file *file,
+					   unsigned long addr,
+					   unsigned long len,
+					   unsigned long pgoff,
+					   unsigned long flags)
+{
+	struct mtd_file_info *mfi = file->private_data;
+	struct mtd_info *mtd = mfi->mtd;
+
+	if (mtd->get_unmapped_area) {
+		unsigned long offset;
+
+		if (addr != 0)
+			return (unsigned long) -EINVAL;
+
+		if (len > mtd->size || pgoff >= (mtd->size >> PAGE_SHIFT))
+			return (unsigned long) -EINVAL;
+
+		offset = pgoff << PAGE_SHIFT;
+		if (offset > mtd->size - len)
+			return (unsigned long) -EINVAL;
+
+		return mtd->get_unmapped_area(mtd, len, offset, flags);
+	}
+
+	/* can't map directly */
+	return (unsigned long) -ENOSYS;
+}
+#endif
+
+/*
+ * set up a mapping for shared memory segments
+ */
+static int mtd_mmap(struct file *file, struct vm_area_struct *vma)
+{
+#ifdef CONFIG_MMU
+	struct mtd_file_info *mfi = file->private_data;
+	struct mtd_info *mtd = mfi->mtd;
+
+	if (mtd->type == MTD_RAM || mtd->type == MTD_ROM)
+		return 0;
+	return -ENOSYS;
+#else
+	return vma->vm_flags & VM_SHARED ? 0 : -ENOSYS;
+#endif
+}
+
 static struct file_operations mtd_fops = {
 	.owner		= THIS_MODULE,
 	.llseek		= mtd_lseek,
@@ -771,6 +864,10 @@ static struct file_operations mtd_fops =
 	.ioctl		= mtd_ioctl,
 	.open		= mtd_open,
 	.release	= mtd_close,
+	.mmap		= mtd_mmap,
+#ifndef CONFIG_MMU
+	.get_unmapped_area = mtd_get_unmapped_area,
+#endif
 };
 
 static int __init init_mtdchar(void)
diff --git a/drivers/mtd/mtdpart.c b/drivers/mtd/mtdpart.c
index 06a9303..48bbc77 100644
--- a/drivers/mtd/mtdpart.c
+++ b/drivers/mtd/mtdpart.c
@@ -86,6 +86,17 @@ static void part_unpoint (struct mtd_inf
 	part->master->unpoint (part->master, addr, from + part->offset, len);
 }
 
+static unsigned long part_get_unmapped_area(struct mtd_info *mtd,
+					    unsigned long len,
+					    unsigned long offset,
+					    unsigned long flags)
+{
+	struct mtd_part *part = PART(mtd);
+
+	offset += part->offset;
+	return part->master->get_unmapped_area(mtd, len, offset, flags);
+}
+
 static int part_read_oob(struct mtd_info *mtd, loff_t from,
 			 struct mtd_oob_ops *ops)
 {
@@ -354,6 +365,8 @@ int add_mtd_partitions(struct mtd_info *
 			slave->mtd.unpoint = part_unpoint;
 		}
 
+		if (master->get_unmapped_area)
+			slave->mtd.get_unmapped_area = part_get_unmapped_area;
 		if (master->read_oob)
 			slave->mtd.read_oob = part_read_oob;
 		if (master->write_oob)
diff --git a/include/linux/mtd/mtd.h b/include/linux/mtd/mtd.h
index 94a443d..ab0f21f 100644
--- a/include/linux/mtd/mtd.h
+++ b/include/linux/mtd/mtd.h
@@ -156,6 +156,15 @@ #define MTD_PROGREGION_CTRLMODE_INVALID(
 	/* We probably shouldn't allow XIP if the unpoint isn't a NULL */
 	void (*unpoint) (struct mtd_info *mtd, u_char * addr, loff_t from, size_t len);
 
+	/* Allow NOMMU mmap() to directly map the device (if not NULL)
+	 * - return the address to which the offset maps
+	 * - return -ENOSYS to indicate refusal to do the mapping
+	 */
+	unsigned long (*get_unmapped_area) (struct mtd_info *mtd,
+					    unsigned long len,
+					    unsigned long offset,
+					    unsigned long flags);
+
 
 	int (*read) (struct mtd_info *mtd, loff_t from, size_t len, size_t *retlen, u_char *buf);
 	int (*write) (struct mtd_info *mtd, loff_t to, size_t len, size_t *retlen, const u_char *buf);



From choudhri at cs.tamu.edu  Tue Sep  5 20:37:56 2006
From: choudhri at cs.tamu.edu (Siddharth Choudhuri)
Date: Tue, 5 Sep 2006 19:37:56 -0500 (CDT)
Subject: Running nandsim 
Message-ID: <Pine.GSO.4.58.0609051935330.19487@sun>

Hi,

I am trying to run nandsim on linux kernel 2.6.16. However, during
configuration (make menuconfig), there is no option to install nandsim as
a module. The only options are to include it in the kernel or not. Is
there a way to run nandsim if its included as part of the kernel (and not
as a module) ?

thanks,
-siddharth

_____________________________________________________________________
     Unix is user friendly - its just picky about its friends.
_____________________________________________________________________



From jwboyer at gmail.com  Tue Sep  5 21:00:06 2006
From: jwboyer at gmail.com (Josh Boyer)
Date: Tue, 5 Sep 2006 20:00:06 -0500
Subject: [PATCH] Make MTD chardev mmap available under some circumstances
In-Reply-To: <24712.1157483886@warthog.cambridge.redhat.com>
References: <24712.1157483886@warthog.cambridge.redhat.com>
Message-ID: <625fc13d0609051800w5d4b114cp5e2517ca683708ee@mail.gmail.com>

On 9/5/06, David Howells <dhowells at redhat.com> wrote:
>
> Make it possible to mmap MTD chardevs directly or by copy on a NOMMU system.

Why would you want to do this?  I'm just curious.


> +/*
> + * Allow NOMMU mmap() to directly map the device (if not NULL)
> + * - return the address to which the offset maps
> + * - return -ENOSYS to indicate refusal to do the mapping

Where do you actually do the -ENOSYS part?  I think that comment
belongs to the actual mtd_get_unmapped_area call in mtdchar.c, no?

> +/*
> + * try to determine where a shared mapping can be made
> + * - only supported for NOMMU at the moment (MMU can't doesn't copy private
> + *   mappings)
> + */
> +#ifndef CONFIG_MMU
> +static unsigned long mtd_get_unmapped_area(struct file *file,
> +                                          unsigned long addr,
> +                                          unsigned long len,
> +                                          unsigned long pgoff,
> +                                          unsigned long flags)
> +{
> +       struct mtd_file_info *mfi = file->private_data;
> +       struct mtd_info *mtd = mfi->mtd;
> +
> +       if (mtd->get_unmapped_area) {
> +               unsigned long offset;
> +
> +               if (addr != 0)
> +                       return (unsigned long) -EINVAL;
> +
> +               if (len > mtd->size || pgoff >= (mtd->size >> PAGE_SHIFT))
> +                       return (unsigned long) -EINVAL;
> +
> +               offset = pgoff << PAGE_SHIFT;
> +               if (offset > mtd->size - len)
> +                       return (unsigned long) -EINVAL;
> +
> +               return mtd->get_unmapped_area(mtd, len, offset, flags);
> +       }
> +
> +       /* can't map directly */
> +       return (unsigned long) -ENOSYS;
> +}
> +#endif

Could we do something like:

#else
#define mtd_get_unmapped_area (NULL);

which would prevent the ugly ifdef in the mtd_fops structure?

>  static struct file_operations mtd_fops = {
>         .owner          = THIS_MODULE,
>         .llseek         = mtd_lseek,
> @@ -771,6 +864,10 @@ static struct file_operations mtd_fops =
>         .ioctl          = mtd_ioctl,
>         .open           = mtd_open,
>         .release        = mtd_close,
> +       .mmap           = mtd_mmap,
> +#ifndef CONFIG_MMU
> +       .get_unmapped_area = mtd_get_unmapped_area,
> +#endif

See above.


josh



From rln-mtd at arbetsmyra.dyndns.org  Wed Sep  6 04:37:58 2006
From: rln-mtd at arbetsmyra.dyndns.org (Ronny L Nilsson)
Date: Wed, 6 Sep 2006 10:37:58 +0200
Subject: Is NAND MTD preemption safe?
Message-ID: <20060906083858.B4DE55E7@arbetsmyra.dyndns.org>


Hi
I have a question about MTD, NAND and race conditions. Basically I'm 
wondering if the NAND support in MTD is preemption safe?

Scenario:
1) A NAND chip is splited in multiple partitions.

2) On each partition (/dev/mtdblockX) is a filesystem.

3) If one filesystem performs a write in the NAND chip, will the other 
filesystems temporarily be lock out? If preemption is enabled in the 
kernel I suspect races might otherwise occur (since addressing and 
command cycles of NANDS are quite lengthy).


Regards
/Ronny Nilsson






From nils.faerber at kernelconcepts.de  Wed Sep  6 09:50:12 2006
From: nils.faerber at kernelconcepts.de (Nils Faerber)
Date: Wed, 06 Sep 2006 15:50:12 +0200
Subject: Intel P30, locked sectors?
Message-ID: <44FED214.7090309@kernelconcepts.de>

Hi!
I now did a kernel update (in fact, I started over with a new kernel)
and am now using 2.6.18-RC6 from kernel.org.

I have read access to the flash, rootfs is mounted correctly but at
first write attempt I get:

[42949375.150000] Freeing init memory: 96K
[42949376.480000] Erase at 0x00cc0000 failed immediately: -EROFS. Is the
sector locked?
[42949377.520000] Erase at 0x00c80000 failed immediately: -EROFS. Is the
sector locked?
[42949378.560000] Erase at 0x00c40000 failed immediately: -EROFS. Is the
sector locked?
[42949379.600000] Erase at 0x00c00000 failed immediately: -EROFS. Is the
sector locked?


I had hoped that the P30 chips would be supported now, but it seems they
are not fully. How can I unlock the sectors, if that is really the issue
here.

This is really starting to scare me a little ;)

Thanks in advance!

Cheers
  nils faerber

-- 
kernel concepts GbR      Tel: +49-271-771091-12
Dreisbachstr. 24         Fax: +49-271-771091-19
D-57250 Netphen          Mob: +49-176-21024535
--



From justin at redfish-group.com  Wed Sep  6 10:16:17 2006
From: justin at redfish-group.com (Justin Clacherty)
Date: Thu, 07 Sep 2006 00:16:17 +1000
Subject: Intel P30, locked sectors?
In-Reply-To: <44FED214.7090309@kernelconcepts.de>
References: <44FED214.7090309@kernelconcepts.de>
Message-ID: <44FED831.60704@redfish-group.com>

Nils Faerber wrote:
> I had hoped that the P30 chips would be supported now, but it seems they
> are not fully. How can I unlock the sectors, if that is really the issue
> here.
>   
P30 flash is supported in that it supports CFI.  You can read and write 
to it as long as it's unlocked.  CFI does not support automatic 
unlocking, it assumes if it's locked, it's locked for a reason.  The 
bootloader has to ensure that the sectors occupied by the rootfs are 
unlocked before mounting the filesystem.  We're using P30 here without 
problems.

Justin.



From nils.faerber at kernelconcepts.de  Wed Sep  6 10:19:00 2006
From: nils.faerber at kernelconcepts.de (Nils Faerber)
Date: Wed, 06 Sep 2006 16:19:00 +0200
Subject: Intel P30, locked sectors?
In-Reply-To: <44FED831.60704@redfish-group.com>
References: <44FED214.7090309@kernelconcepts.de>
	<44FED831.60704@redfish-group.com>
Message-ID: <44FED8D4.6080505@kernelconcepts.de>

Justin Clacherty schrieb:
> Nils Faerber wrote:
>> I had hoped that the P30 chips would be supported now, but it seems they
>> are not fully. How can I unlock the sectors, if that is really the issue
>> here.
> P30 flash is supported in that it supports CFI.  You can read and write
> to it as long as it's unlocked.  CFI does not support automatic
> unlocking, it assumes if it's locked, it's locked for a reason.  The
> bootloader has to ensure that the sectors occupied by the rootfs are
> unlocked before mounting the filesystem.  We're using P30 here without
> problems.

Hmm... OK.
Just in theory, can one write to a locked sector?

I ask because I flashed the very same rootfs to the chip using the
bootloader. The bootloader, which is BLOB BTW, seems to be able to write
to the chips and the contents written also seems to be OK (since I can
boot and mount the rootfs).

> Justin.
Cheers
  nils faerber

-- 
kernel concepts GbR      Tel: +49-271-771091-12
Dreisbachstr. 24         Fax: +49-271-771091-19
D-57250 Netphen          Mob: +49-176-21024535
--



From nico at cam.org  Wed Sep  6 10:25:52 2006
From: nico at cam.org (Nicolas Pitre)
Date: Wed, 06 Sep 2006 10:25:52 -0400 (EDT)
Subject: Intel P30, locked sectors?
In-Reply-To: <44FED214.7090309@kernelconcepts.de>
References: <44FED214.7090309@kernelconcepts.de>
Message-ID: <Pine.LNX.4.64.0609061024300.18635@xanadu.home>

On Wed, 6 Sep 2006, Nils Faerber wrote:

> Hi!
> I now did a kernel update (in fact, I started over with a new kernel)
> and am now using 2.6.18-RC6 from kernel.org.
> 
> I have read access to the flash, rootfs is mounted correctly but at
> first write attempt I get:
> 
> [42949375.150000] Freeing init memory: 96K
> [42949376.480000] Erase at 0x00cc0000 failed immediately: -EROFS. Is the
> sector locked?

Before the first write attempt you need to run flash-unlock on the 
corresponding flash partition.


Nicolas



From nils.faerber at kernelconcepts.de  Wed Sep  6 10:30:19 2006
From: nils.faerber at kernelconcepts.de (Nils Faerber)
Date: Wed, 06 Sep 2006 16:30:19 +0200
Subject: Intel P30, locked sectors?
In-Reply-To: <Pine.LNX.4.64.0609061024300.18635@xanadu.home>
References: <44FED214.7090309@kernelconcepts.de>
	<Pine.LNX.4.64.0609061024300.18635@xanadu.home>
Message-ID: <44FEDB7B.8090809@kernelconcepts.de>

Nicolas Pitre schrieb:
> On Wed, 6 Sep 2006, Nils Faerber wrote:
>> I now did a kernel update (in fact, I started over with a new kernel)
>> and am now using 2.6.18-RC6 from kernel.org.
>> I have read access to the flash, rootfs is mounted correctly but at
>> first write attempt I get:
>> [42949375.150000] Freeing init memory: 96K
>> [42949376.480000] Erase at 0x00cc0000 failed immediately: -EROFS. Is the
>> sector locked?
> Before the first write attempt you need to run flash-unlock on the 
> corresponding flash partition.

Ah, cool, thanks!
I guess that this tool is part of mtd-utils, right?

Will be tested ASAP! But I fear that will have to wait until tomorrow,
gotta go soon.

Thanks again!

> Nicolas
Cheers
  nils faerber

-- 
kernel concepts GbR      Tel: +49-271-771091-12
Dreisbachstr. 24         Fax: +49-271-771091-19
D-57250 Netphen          Mob: +49-176-21024535
--



From justin at redfish-group.com  Wed Sep  6 11:12:51 2006
From: justin at redfish-group.com (Justin Clacherty)
Date: Thu, 07 Sep 2006 01:12:51 +1000
Subject: Intel P30, locked sectors?
In-Reply-To: <44FED8D4.6080505@kernelconcepts.de>
References: <44FED214.7090309@kernelconcepts.de>	<44FED831.60704@redfish-group.com>
	<44FED8D4.6080505@kernelconcepts.de>
Message-ID: <44FEE573.5060707@redfish-group.com>

Nils Faerber wrote:
> Just in theory, can one write to a locked sector?
>   
No.
> I ask because I flashed the very same rootfs to the chip using the
> bootloader. The bootloader, which is BLOB BTW, seems to be able to write
> to the chips and the contents written also seems to be OK (since I can
> boot and mount the rootfs).
>   
Not sure how blob works, maybe it unlocks, writes, then relocks...



From justin at redfish-group.com  Wed Sep  6 11:17:38 2006
From: justin at redfish-group.com (Justin Clacherty)
Date: Thu, 07 Sep 2006 01:17:38 +1000
Subject: Intel P30, locked sectors?
In-Reply-To: <Pine.LNX.4.64.0609061024300.18635@xanadu.home>
References: <44FED214.7090309@kernelconcepts.de>
	<Pine.LNX.4.64.0609061024300.18635@xanadu.home>
Message-ID: <44FEE692.9020900@redfish-group.com>

Nicolas Pitre wrote:
> Before the first write attempt you need to run flash-unlock on the
> corresponding flash partition.
>   
Will this work if it's your rootfs?  ie. it will need to be mounted and 
possibly written to before you get to the point where you can run 
flash-unlock.  I guess if you mount ro then there won't be any writes.

Justin.



From justin at redfish-group.com  Wed Sep  6 11:20:43 2006
From: justin at redfish-group.com (Justin Clacherty)
Date: Thu, 07 Sep 2006 01:20:43 +1000
Subject: Static partitions
In-Reply-To: <44FA57FD.8070003@redfish-group.com>
References: <44FA57FD.8070003@redfish-group.com>
Message-ID: <44FEE74B.3040907@redfish-group.com>

Justin Clacherty wrote:
> Hi,
>
> I've managed to get mtd working on my PXA270 board.  I've used the 
> mainstone port as a template for my board port and was wondering why the 
> static partitions need to be defined twice.  Mainstone has it defined in 
> arch/arm/mach-pxa/mainstone.c and in drivers/mt d/maps/mainstone-flash.c.
>
> Regards,
> Justin.
>   

Asking again due to lack of interest :)

Nicolas, you wouldn't happen to know the answer to this would you?



From nico at cam.org  Wed Sep  6 11:24:18 2006
From: nico at cam.org (Nicolas Pitre)
Date: Wed, 06 Sep 2006 11:24:18 -0400 (EDT)
Subject: Intel P30, locked sectors?
In-Reply-To: <44FEE692.9020900@redfish-group.com>
References: <44FED214.7090309@kernelconcepts.de>
	<Pine.LNX.4.64.0609061024300.18635@xanadu.home>
	<44FEE692.9020900@redfish-group.com>
Message-ID: <Pine.LNX.4.64.0609061122510.18635@xanadu.home>

On Thu, 7 Sep 2006, Justin Clacherty wrote:

> Nicolas Pitre wrote:
> > Before the first write attempt you need to run flash-unlock on the
> > corresponding flash partition.
> >   
> Will this work if it's your rootfs?  ie. it will need to be mounted and 
> possibly written to before you get to the point where you can run 
> flash-unlock. 

Up to you to manage for flash-unlock to be executed before writes.

> I guess if you mount ro then there won't be any writes.

Yes, And then you can remount rw.


Nicolas



From nico at cam.org  Wed Sep  6 12:45:13 2006
From: nico at cam.org (Nicolas Pitre)
Date: Wed, 06 Sep 2006 12:45:13 -0400 (EDT)
Subject: Static partitions
In-Reply-To: <44FEE74B.3040907@redfish-group.com>
References: <44FA57FD.8070003@redfish-group.com>
	<44FEE74B.3040907@redfish-group.com>
Message-ID: <Pine.LNX.4.64.0609061238340.18635@xanadu.home>

On Thu, 7 Sep 2006, Justin Clacherty wrote:

> Justin Clacherty wrote:
> > Hi,
> >
> > I've managed to get mtd working on my PXA270 board.  I've used the 
> > mainstone port as a template for my board port and was wondering why the 
> > static partitions need to be defined twice.  Mainstone has it defined in 
> > arch/arm/mach-pxa/mainstone.c and in drivers/mt d/maps/mainstone-flash.c.
> >
> > Regards,
> > Justin.
> >   
> 
> Asking again due to lack of interest :)
> 
> Nicolas, you wouldn't happen to know the answer to this would you?

There was a patch in the CVS to remove any partition definitions from 
mainstone-flash.c and lubbock-flash.c, merge those two into a generic 
pxa-flash.c and have it get the partition information in a generic way 
from each board specific file.

The board specific file part is in mainline now.  Somehow the other part 
hasn't been carried over to the MTD GIT tree yet.


Nicolas



From wgshizz at yahoo.com  Wed Sep  6 16:56:35 2006
From: wgshizz at yahoo.com (Weiguang Shi)
Date: Wed, 6 Sep 2006 13:56:35 -0700 (PDT)
Subject: flash_to_file() and file_to_flash() in mtd_debug.c
Message-ID: <20060906205635.66530.qmail@web30415.mail.mud.yahoo.com>

Hi,

I couldn't connect to the mail archive. So please forgive me if this
has been asked before. 

Why the two functions flash_to_file() and file_to_flash() in
mtd_debug.c?
I mean is it possible to do the flash device read/write using dd?

Thank you.
Wei

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 



From catboat at texas.net  Thu Sep  7 17:05:28 2006
From: catboat at texas.net (catboat at texas.net)
Date: Thu,  7 Sep 2006 16:05:28 -0500
Subject: testcase for JFFS2
Message-ID: <1157663128.45008998bded1@webmail.texas.net>



Hi, 

I'm doing white-box testing on jffs2.  It's not the very latest code, but
anyway ...

This tests the disk-full condition.  On my system, this test causes bad
values in c->free_size and c->dirty_size.  c->free_size gets decremented
too far, so I get values such as 0xfff838a8.  c->dirty_size gets
incremented too far, and I've seen it bigger than c->flash_size.  It also
causes problem for the GC thread.  I have seen the GC thread trap, BUG, or
go into an infinite loop.

Steps in this testcase.

[] Mount a clean jffs2 at /mnt.  Mine is 16MB.  I write all 0xFF there
before mounting.

[] Create a file of random data that is 75% the size of the device.  I use
random data because it is harder to compress, making the partition fill up
faster.  Maybe you can use a file that is compressed already, as long as
the file is about 3/4 the size of the partition.  Call it file75 for naming
sake.

[] Start filling it up by copying first file.

                        cp file75 /mnt/file1

This results in no error.

[] The next copy should exceed the partition size and cause a "no space"
error.  Resulting file is foreshortened.

                        cp file75 /mnt/file2

[] Next, remove the first file copied, which makes free space.

                        rm /mnt/file1

[] Copy over existing file2.  There should be room for it.

                        cp file75 /mnt/file2

At this point I have seen unusual values in c->free_size and c->dirty_size.

[] The next copy should again fill up the partition.

                        cp file75 /mnt/file1

At this point, I have seen the GC thread print "Argh.  No free space left
for GC." and "Aborting GC thread." I have also seen the GC thread quietly
go into an infinite loop.

Can anyone reproduce this bug? Thanks. 

Monte Copeland




From pschulz01 at gmail.com  Thu Sep  7 18:33:47 2006
From: pschulz01 at gmail.com (Paul Schulz)
Date: Fri, 8 Sep 2006 08:03:47 +0930
Subject: [Sfd] FOSS, Science, and Public activism
In-Reply-To: <20060701220824.1EC396B0FDD@gnu-darwin.org>
References: <20060701220824.1EC396B0FDD@gnu-darwin.org>
Message-ID: <cc9bf44d0609071533r10bc5c5cl940088ead9669c4f@mail.gmail.com>

Greetings,

On 7/2/06, proclus at gnu-darwin.org <proclus at gnu-darwin.org> wrote:
> It is important to alert the whole FOSS community that Darwin
> cannot be classified as a free or open source operation system
> as of the Darwin-8 revision, because AppleACPIplatform-39 which
> is required to boot the system is proprietary.  It is notable that
> only the current version of Darwin from Apple is a non-free OS.
> GNU-Darwin has a free version, an earlier revision that includes
> the source code.  It is FOSS, and we call upon Apple to maintain
> Darwin as such, as it has been in the past.  We hope that the
> current situation with the kernel and ACPI driver will soon be
> remedied so that Darwin will continue as a FOSS OS.

On a 'smaller' related note.. the ArmCore modules that are made by
Compulab (compulab.co.il) use a proprietory bootloader (ARMMon) for
their Intel Xscale,
system on a chip.

Rather than make use of the mtd drivers for Linux (for whatever reason), they
ship their own binary flash modules for Linux. This is used by both
the bootloader
and the modified linux kernel. This makes is (nearly) impossible to look into
various hardware  related issues on this platform eg.
  - reducing boot time of the Linux kernel
  - evaluating other flash drivers
  - using alternative OS's (L4/pistachio) and
  - running safety critical code directly 'on the metal'.

A nice clean FOSS based counter-example are the GunStix Waysmall systems
(same architecture) built by http://www.gumstix.com.

Regards,
Paul Schulz



From posaune at hotmail.com  Thu Sep  7 18:40:21 2006
From: posaune at hotmail.com (Han Chang)
Date: Thu, 07 Sep 2006 15:40:21 -0700
Subject: nand_bbt.c
In-Reply-To: <1156976978.29250.233.camel@localhost.localdomain>
Message-ID: <BAY110-F14E8B880BD6E4506273ABABC360@phx.gbl>


Hi Thomas,

I'm looking the nand bbt and noticed the file is written by you. I'm just 
curious in order to enable flash based bbt, what needs to be done at driver 
level. I enabled flag "NAND_USE_FLASH_BBT". Things are not quite working. 
Anything I'm missing here? Is there any doc other than the comments in the 
code that I can looked at?

Many thanks!

Han





From nils.faerber at kernelconcepts.de  Fri Sep  8 11:27:34 2006
From: nils.faerber at kernelconcepts.de (Nils Faerber)
Date: Fri, 08 Sep 2006 17:27:34 +0200
Subject: Again 2.6.18-RC6 XScale P30 issues
Message-ID: <45018BE6.5040102@kernelconcepts.de>

Hi, me again ...
I am sorry to bother you again, but I still have issues withe the P30
flashes.
Now that I can write to the chips I tested it a little more. After a
fresh write of a clean rootfs I can create and delete files almost fine
(I just get very few CRC errors but everything else works OK, also the
files are intact).

But after creating and deleting files and a reboot I get:

----------
[42949375.760000] Write of 68 bytes at 0x00cf91d0 failed. returned -30,
retlen 0
[42949375.770000] Not marking the space at 0x00cf91d0 as dirty because
the flash driver returned retlen zero
[42949375.780000] Write of 68 bytes at 0x00cf91d0 failed. returned -30,
retlen 0
[42949375.780000] Not marking the space at 0x00cf91d0 as dirty because
the flash driver returned retlen zero
ifup: /var/run/ifstate: Read-only file system

............

Starting telnetd...
Starting slideshow with images from the internal flash...
Starting pid 695, console /dev/ttyS0: '/bin/sh'

Processing /etc/profile... Done
[@colineator /]#cd
[@colineator /root]#ls -l
-rw-r--r--    1 0        0         5242880 Jan  1 00:14 blub
[@colineator /root]#rm blub
[42949387.590000] Write of 44 bytes at 0x00cf91d0 failed. returned -30,
retlen 0
[42949387.600000] Not marking the space at 0x00cf91d0 as dirty because
the flash driver returned retlen zero
[42949387.610000] Write of 44 bytes at 0x00cf91d0 failed. returned -30,
retlen 0
[42949387.620000] Not marking the space at 0x00cf91d0 as dirty because
the flash driver returned retlen zero
rm: unable to remove `blub': Read-only file system
----------------

So something is still wrong. At runtime the filesystem seems to be OK
but after a reboot it seems to be defect. Only way to recover is to
reflash the rootfs.

I am quite desperate right now.
For the new approach I took the Mainstone MTD mapping driver and
modified it for the single two-chip configuration. But I did not change
anything beyond that.

Cheers
  nils faerber

-- 
kernel concepts GbR      Tel: +49-271-771091-12
Dreisbachstr. 24         Fax: +49-271-771091-19
D-57250 Netphen          Mob: +49-176-21024535
--



From dwmw2 at infradead.org  Sat Sep  9 09:05:52 2006
From: dwmw2 at infradead.org (David Woodhouse)
Date: Sat, 09 Sep 2006 14:05:52 +0100
Subject: [Sfd] FOSS, Science, and Public activism
In-Reply-To: <cc9bf44d0609071533r10bc5c5cl940088ead9669c4f@mail.gmail.com>
References: <20060701220824.1EC396B0FDD@gnu-darwin.org>
	<cc9bf44d0609071533r10bc5c5cl940088ead9669c4f@mail.gmail.com>
Message-ID: <1157807152.2977.87.camel@pmac.infradead.org>

On Fri, 2006-09-08 at 08:03 +0930, Paul Schulz wrote:
> Greetings,
> 
> On 7/2/06, proclus at gnu-darwin.org <proclus at gnu-darwin.org> wrote:
> > It is important to alert the whole FOSS community that Darwin
> > cannot be classified as a free or open source operation system
> > as of the Darwin-8 revision, because AppleACPIplatform-39 which
> > is required to boot the system is proprietary.  It is notable that
> > only the current version of Darwin from Apple is a non-free OS.
> > GNU-Darwin has a free version, an earlier revision that includes
> > the source code.  It is FOSS, and we call upon Apple to maintain
> > Darwin as such, as it has been in the past.  We hope that the
> > current situation with the kernel and ACPI driver will soon be
> > remedied so that Darwin will continue as a FOSS OS.

If it's only ACPI, does it really matter? ACPI exists mostly for the
same reason as proprietary kernel modules -- to allow manufacturers to
obscure the details of the hardware.

Instead of having a free interpreter which runs their proprietary
bytecode in kernel mode, you have a closed interpreter which runs their
proprietary bytecode in kernel mode.

I would argue that even if your interpreter was open source, once you
submitted to using ACPI you'd already lost the Free Software game.

-- 
dwmw2




From nils.faerber at kernelconcepts.de  Sat Sep  9 08:16:02 2006
From: nils.faerber at kernelconcepts.de (Nils Faerber)
Date: Sat, 09 Sep 2006 14:16:02 +0200
Subject: Again 2.6.18-RC6 XScale P30 issues
In-Reply-To: <4502A2AA.30701@redfish-group.com>
References: <45018BE6.5040102@kernelconcepts.de>
	<4502A2AA.30701@redfish-group.com>
Message-ID: <4502B082.1090401@kernelconcepts.de>

Justin Clacherty schrieb:
> Nils Faerber wrote:
>> So something is still wrong. At runtime the filesystem seems to be OK
>> but after a reboot it seems to be defect. Only way to recover is to
>> reflash the rootfs.
> Is the bootup process writing to flash before you unlock it?  syslogd
> might be a culprit...

Well, yes, there are some scripts that touch the fs, but that is IMHO
not the issue here. If it would be I would get the other "unable to
write to locked sector" error.
Instead the fs gets permanently corrupted, i.e. data is written and the
written data is wrong.

Last night I found that the JFFS2 write cache is configured. I will
disable that now and see if that helps - I have the impression that the
fs may contain half-baked stuff after a write. On the other hand, the
JFFS2 write cache is not marked as an experimental feature so I thought
I should be safe...

Well, that like poking with a long pole in the mist, I have to admit.
Very nasty to debug...
If I find something new I'll let you know ;)

But many thanks for your (all of you) help so far!

Cheers
  nils faerber

-- 
kernel concepts GbR      Tel: +49-271-771091-12
Dreisbachstr. 24         Fax: +49-271-771091-19
D-57250 Netphen          Mob: +49-176-21024535
--



From justin at redfish-group.com  Sat Sep  9 07:16:58 2006
From: justin at redfish-group.com (Justin Clacherty)
Date: Sat, 09 Sep 2006 21:16:58 +1000
Subject: Again 2.6.18-RC6 XScale P30 issues
In-Reply-To: <45018BE6.5040102@kernelconcepts.de>
References: <45018BE6.5040102@kernelconcepts.de>
Message-ID: <4502A2AA.30701@redfish-group.com>

Nils Faerber wrote:
> So something is still wrong. At runtime the filesystem seems to be OK
> but after a reboot it seems to be defect. Only way to recover is to
> reflash the rootfs.
>   
Is the bootup process writing to flash before you unlock it?  syslogd 
might be a culprit...



From jwboyer at gmail.com  Sat Sep  9 10:10:58 2006
From: jwboyer at gmail.com (Josh Boyer)
Date: Sat, 9 Sep 2006 09:10:58 -0500
Subject: Again 2.6.18-RC6 XScale P30 issues
In-Reply-To: <4502B082.1090401@kernelconcepts.de>
References: <45018BE6.5040102@kernelconcepts.de>
	<4502A2AA.30701@redfish-group.com>
	<4502B082.1090401@kernelconcepts.de>
Message-ID: <625fc13d0609090710w1cf57ccaxc10e5b123e745119@mail.gmail.com>

On 9/9/06, Nils Faerber <nils.faerber at kernelconcepts.de> wrote:
> Justin Clacherty schrieb:
> > Nils Faerber wrote:
> >> So something is still wrong. At runtime the filesystem seems to be OK
> >> but after a reboot it seems to be defect. Only way to recover is to
> >> reflash the rootfs.
> > Is the bootup process writing to flash before you unlock it?  syslogd
> > might be a culprit...
>
> Well, yes, there are some scripts that touch the fs, but that is IMHO
> not the issue here. If it would be I would get the other "unable to
> write to locked sector" error.
> Instead the fs gets permanently corrupted, i.e. data is written and the
> written data is wrong.

How are you resetting the board?

> Last night I found that the JFFS2 write cache is configured. I will
> disable that now and see if that helps - I have the impression that the
> fs may contain half-baked stuff after a write. On the other hand, the
> JFFS2 write cache is not marked as an experimental feature so I thought
> I should be safe...

It typically is if you do things correctly.  You should remount the
filesystem as read-only or at the very least sync it before resetting.
 The writecache gets flushed every 5 seconds or so.  Depending on the
amount of data in there, if you reset without it being flushed you'll
loose data or even whole files.

josh



From justin at redfish-group.com  Sat Sep  9 18:00:49 2006
From: justin at redfish-group.com (Justin Clacherty)
Date: Sun, 10 Sep 2006 08:00:49 +1000
Subject: Again 2.6.18-RC6 XScale P30 issues
In-Reply-To: <4502B082.1090401@kernelconcepts.de>
References: <45018BE6.5040102@kernelconcepts.de>
	<4502A2AA.30701@redfish-group.com>
	<4502B082.1090401@kernelconcepts.de>
Message-ID: <45033991.20900@redfish-group.com>

Nils Faerber wrote:
> not the issue here. If it would be I would get the other "unable to
> write to locked sector" error.
>   
Yes, you're probably right about that.
> Instead the fs gets permanently corrupted, i.e. data is written and the
> written data is wrong.
>   
hmmm,,,didn't realise it was getting permanently corrupted.
> Last night I found that the JFFS2 write cache is configured. I will
> disable that now and see if that helps - I have the impression that the
> fs may contain half-baked stuff after a write. On the other hand, the
> JFFS2 write cache is not marked as an experimental feature so I thought
> I should be safe...
>   
Can't speak from experience here as I don't have write cache enabled, 
but I don't imagine you'd lose the whole fs if you were using write 
cache and lost power.  I suspect you'd just lose your changes or maybe 
the file that was being updated.

Justin.



From justin at redfish-group.com  Sat Sep  9 18:26:27 2006
From: justin at redfish-group.com (Justin Clacherty)
Date: Sun, 10 Sep 2006 08:26:27 +1000
Subject: [Sfd] FOSS, Science, and Public activism
In-Reply-To: <cc9bf44d0609071533r10bc5c5cl940088ead9669c4f@mail.gmail.com>
References: <20060701220824.1EC396B0FDD@gnu-darwin.org>
	<cc9bf44d0609071533r10bc5c5cl940088ead9669c4f@mail.gmail.com>
Message-ID: <45033F93.2040204@redfish-group.com>

Paul Schulz wrote:
> Rather than make use of the mtd drivers for Linux (for whatever reason), they
> ship their own binary flash modules for Linux. This is used by both
> the bootloader
> and the modified linux kernel. This makes is (nearly) impossible to look into
> various hardware  related issues on this platform eg.
>   
Had some problems with this myself.  The proprietary boot loader is 
annoying...

I believe they've open sourced the mtd driver now in this "[PATCH 04/06] 
CM-x2xx: MTD" patch to the arm-linux list.

Justin.



From jwboyer at gmail.com  Sat Sep  9 22:22:13 2006
From: jwboyer at gmail.com (Josh Boyer)
Date: Sat, 9 Sep 2006 21:22:13 -0500
Subject: State of UBI
Message-ID: <625fc13d0609091922m42a1caeagfa4e87bc18f2a8d6@mail.gmail.com>

Hi all,

Where are we with UBI?  It seems Artem has been steadily committing
fixes to the ubi git tree.  There's supposedly still interest from
other projects.  Yet it hasn't been reviewed very much, for which I'm
partly to blame.  So where should we go from here?

I think a good start would be to list what's missing.  I know that it
needs a patch to allow double page writes on NAND.  There's also the
missing JFFS2 integration, or rather two competing versions of it.  Is
there anything else?  Something documented in a TODO list would be
good.

Then there's a matter of when should it be merged.  As it stands right
now, UBI is in limbo and I'd hate to see something with good potential
just sit around rotting.  Having a merge goal would perhaps provide
some motivation.  It could be a date or a kernel version, but it
should be realistic.

So lets come up with some kind of plan to get it reviewed, tested, and
merged.  My hope would be that all involved so far, or even those that
want to help out, could reply with their thoughts.  I'm afraid some
won't for various reasons.  Perhaps if some of us are going to LCA we
could get together and hash some things out more in detail, but I'd
rather not wait until then to get things moving.

josh



From dedekind at yandex.ru  Sun Sep 10 04:47:10 2006
From: dedekind at yandex.ru (dedekind)
Date: Sun, 10 Sep 2006 12:47:10 +0400 (MSD)
Subject: State of UBI
In-Reply-To: <625fc13d0609091922m42a1caeagfa4e87bc18f2a8d6@mail.gmail.com>
References: <625fc13d0609091922m42a1caeagfa4e87bc18f2a8d6@mail.gmail.com>
Message-ID: <4503D10E.000001.07116@webmail12.yandex.ru>

Hello Josh,

>Where are we with UBI?  It seems Artem has been steadily committing
>fixes to the ubi git tree. 
Yes, I'm using it in another project so I stedily add more tiny
features, changes and fixes. Also, one may notice that I maintain
UBI FAQ which has considerably grown.

>I think a good start would be to list what's missing.  I know that it
>needs a patch to allow double page writes on NAND.  There's also the
>missing JFFS2 integration, or rather two competing versions of it.  Is
>there anything else?  Something documented in a TODO list would be
>good.

Well, what you've listed is not what UBI itself needs:
1. "double page writes on NAND" - it needs MTD changes and zero UBI changes.
2. JFFS2 integration also requires zero changes in UBI (as long as it is
sane).

But, well, this is not to start a new contest :-) Let's list want to
have in UBI and around UBI.

I'd add here then:

1. True and extensive unclean reboot testing.
2. Better UBI utilities as I find the current ones not ideal.

>Then there's a matter of when should it be merged.  As it stands right
>now, UBI is in limbo and I'd hate to see something with good potential
>just sit around rotting.  Having a merge goal would perhaps provide
>some motivation.  It could be a date or a kernel version, but it
>should be realistic.

Would be nice to just add it to mtd-2.6.git, IMO. This would be a good
and simple step further.

>So lets come up with some kind of plan to get it reviewed, tested, and
>merged.  My hope would be that all involved so far, or even those that
>want to help out, could reply with their thoughts.  I'm afraid some
>won't for various reasons.  Perhaps if some of us are going to LCA we
>could get together and hash some things out more in detail, but I'd
>rather not wait until then to get things moving.

I think that we should just to merge it with mtd-2.6.git. And all the
promotion stuff may go in parallel. I'm not sure about the plan... LCA
sounds great.

I can only say that I'm going to use it extensively. And I'm already
thinking about a new - scalable UBI implementation.

Artem.



From dwmw2 at infradead.org  Sun Sep 10 06:52:39 2006
From: dwmw2 at infradead.org (David Woodhouse)
Date: Sun, 10 Sep 2006 11:52:39 +0100
Subject: State of UBI
In-Reply-To: <4503D10E.000001.07116@webmail12.yandex.ru>
References: <625fc13d0609091922m42a1caeagfa4e87bc18f2a8d6@mail.gmail.com>
	<4503D10E.000001.07116@webmail12.yandex.ru>
Message-ID: <1157885559.2977.136.camel@pmac.infradead.org>

On Sun, 2006-09-10 at 12:47 +0400, dedekind wrote:
> Well, what you've listed is not what UBI itself needs:
> 1. "double page writes on NAND" - it needs MTD changes and zero UBI changes.
> 2. JFFS2 integration also requires zero changes in UBI (as long as it is
> sane).

I need to properly review UBI but I've been fairly busy on OLPC hardware
bringup so I haven't found the time yet.

Preliminary impressions are that I'm concerned by the amount of code --
it's _huge_. And I'm concerned by the fact that it doesn't just provide
MTD devices. I had envisaged that it would be fairly much akin to
another partitioning layer, perhaps requiring a few extra methods to be
added to the mtd_info. But it's a new type of device all of its own, and
requires far more to be changed in MTD users (like JFFS2, FTL, etc.)
than I had imagined.

And should the 'static partition' stuff be a layer on _top_ of UBI
rather than an inseparable part of it?

-- 
dwmw2




From jwboyer at gmail.com  Sun Sep 10 08:32:57 2006
From: jwboyer at gmail.com (Josh Boyer)
Date: Sun, 10 Sep 2006 07:32:57 -0500
Subject: State of UBI
In-Reply-To: <4503D10E.000001.07116@webmail12.yandex.ru>
References: <625fc13d0609091922m42a1caeagfa4e87bc18f2a8d6@mail.gmail.com>
	<4503D10E.000001.07116@webmail12.yandex.ru>
Message-ID: <625fc13d0609100532n58933486l3f66715c38172cd5@mail.gmail.com>

On 9/10/06, dedekind <dedekind at yandex.ru> wrote:
> Hello Josh,
>
> >Where are we with UBI?  It seems Artem has been steadily committing
> >fixes to the ubi git tree.
> Yes, I'm using it in another project so I stedily add more tiny
> features, changes and fixes. Also, one may notice that I maintain
> UBI FAQ which has considerably grown.

I've noticed that as well.  I think it's great and I appreciate the
effort you've put in so far.

>
> >I think a good start would be to list what's missing.  I know that it
> >needs a patch to allow double page writes on NAND.  There's also the
> >missing JFFS2 integration, or rather two competing versions of it.  Is
> >there anything else?  Something documented in a TODO list would be
> >good.
>
> Well, what you've listed is not what UBI itself needs:
> 1. "double page writes on NAND" - it needs MTD changes and zero UBI changes.

I'll politely disagree here.  UBI _does_ need this on NAND to be
really usable.  Otherwise you eat 2 pages per block for UBI metadata,
and that is quite a bit of overhead for a handful of bytes in the
structures.

> 2. Better UBI utilities as I find the current ones not ideal.

What do you find lacking or not ideal?  I'm just curious.

>
> >Then there's a matter of when should it be merged.  As it stands right
> >now, UBI is in limbo and I'd hate to see something with good potential
> >just sit around rotting.  Having a merge goal would perhaps provide
> >some motivation.  It could be a date or a kernel version, but it
> >should be realistic.
>
> Would be nice to just add it to mtd-2.6.git, IMO. This would be a good
> and simple step further.

Yes, maybe.  But I don't want to put the mtd-2.6.git tree in a state
where one has to cherry pick non-UBI fixes from it to send upstream.

josh



From jwboyer at gmail.com  Sun Sep 10 08:35:34 2006
From: jwboyer at gmail.com (Josh Boyer)
Date: Sun, 10 Sep 2006 07:35:34 -0500
Subject: State of UBI
In-Reply-To: <1157885559.2977.136.camel@pmac.infradead.org>
References: <625fc13d0609091922m42a1caeagfa4e87bc18f2a8d6@mail.gmail.com>
	<4503D10E.000001.07116@webmail12.yandex.ru>
	<1157885559.2977.136.camel@pmac.infradead.org>
Message-ID: <625fc13d0609100535v13e88e15k5886b43fda286f6a@mail.gmail.com>

On 9/10/06, David Woodhouse <dwmw2 at infradead.org> wrote:
> On Sun, 2006-09-10 at 12:47 +0400, dedekind wrote:
> > Well, what you've listed is not what UBI itself needs:
> > 1. "double page writes on NAND" - it needs MTD changes and zero UBI changes.
> > 2. JFFS2 integration also requires zero changes in UBI (as long as it is
> > sane).
>
> I need to properly review UBI but I've been fairly busy on OLPC hardware
> bringup so I haven't found the time yet.
>
> Preliminary impressions are that I'm concerned by the amount of code --
> it's _huge_. And I'm concerned by the fact that it doesn't just provide
> MTD devices. I had envisaged that it would be fairly much akin to
> another partitioning layer, perhaps requiring a few extra methods to be
> added to the mtd_info. But it's a new type of device all of its own, and
> requires far more to be changed in MTD users (like JFFS2, FTL, etc.)
> than I had imagined.

Gluebi was intended to provide this translation from UBI device to MTD
device.  I don't think that is a bad approach myself.  Either way
though, JFFS2 needs to be taught not to do wear-leveling or erasing on
a UBI device.

I'll see if I can scrounge up the latest gluebi patches on Monday.  I
doubt they'll appear on this list otherwise.

josh



From dedekind at yandex.ru  Sun Sep 10 09:19:15 2006
From: dedekind at yandex.ru (dedekind)
Date: Sun, 10 Sep 2006 17:19:15 +0400 (MSD)
Subject: State of UBI
In-Reply-To: <1157885559.2977.136.camel@pmac.infradead.org>
References: <625fc13d0609091922m42a1caeagfa4e87bc18f2a8d6@mail.gmail.com>
	<1157885559.2977.136.camel@pmac.infradead.org>
Message-ID: <450410D3.000007.27650@webmail9.yandex.ru>

Hello David,

>Preliminary impressions are that I'm concerned by the amount of code --
>it's _huge_.

It's subjective. I don't know what does huge mean here. But UBI is
not larger then JFFS2 if you use the slocount program
(http://www.dwheeler.com/sloc/) you'll see it is not larger then JFFS2.

>And I'm concerned by the fact that it doesn't just provide
>MTD devices.

Just because MTD device and UBI volume are two different things. There
are similarities, but they are still different and have different
semantics.

1. UBI works on top of MTD. It's a layer above an (one) MTD device.
   MTD over MTD does not make sense.
2. Most of stuff in MTD inteface is just not needed for UBI.
3. MTD interface does not have many thins UBI needs.

>I had envisaged that it would be fairly much akin to
>another partitioning layer, perhaps requiring a few extra methods to be
>added to the mtd_info.

It'd make MTD totally confusing. Having a separate layer is less error
prone and provides better modularization.

Let me provide an example to show how clear and flexible it is.

Consider a situation when one has a NAND chip. He may want to store
kernel image at a fixed place at the beginning of the flash. And the rest
of the chip he wants to use for data storage.

So, he creates 2 MTD partitions - mtd0 and mtd1. He uses mtd0 for the
kernel image and he feeds mtd1 to UBI. So he ends up with

* mtd0 containing the kernel. He can access it via /dev/mtd0 and change it.
* mtd1 owed by UBI. But he still can access it via /dev/mtd1. E.g., this
  may be needed for debugging purposes.
* ubi0 - a UBI device which manages UBI volumes and uses mtd0 as the storage.
* ubi0_0, ubi0_1, etc - ubi volumes which may be used for JFFS2 file system.

And if the user had 2 NAND chips, he could have mtd3 which is the whole
second chip. Then he could contcatenate mtd2 and mtd3 and create one ubi0
on top of the concatenation. Or he first could apply a striping layer
(BTW, what's going on with it?) on them, and create ubi0 on top of the
striped MTD device. Or, if the chips are very different, he could create
ubi0 on top of mtd2 and ubi1 on top of mtd3 - just 2 separate and independent
UBI devices.

>But it's a new type of device all of its own, and
>requires far more to be changed in MTD users (like JFFS2, FTL, etc.)
>than I had imagined.

VS "it's a new type of device" - yes, it is new type of device by design.
And it is not an MTD device because we already have MTD devices. And it
has its own interface which is small and nice.

VS "requires far more to be changed in MTD users (like JFFS2, FTL, etc.)" -
not really. Yo may emulate an MTD device on top of an UBI device. This is
why we have (?) gluebi.

>And should the 'static partition' stuff be a layer on _top_ of UBI
>rather than an inseparable part of it?

Sorry David, I don't understand this. Refine please. What is "static
partition"? The same as "an MTD partition" - just a piece of physical
flash?

Artem.



From dedekind at yandex.ru  Sun Sep 10 09:34:37 2006
From: dedekind at yandex.ru (dedekind)
Date: Sun, 10 Sep 2006 17:34:37 +0400 (MSD)
Subject: State of UBI
In-Reply-To: <625fc13d0609100532n58933486l3f66715c38172cd5@mail.gmail.com>
References: <625fc13d0609091922m42a1caeagfa4e87bc18f2a8d6@mail.gmail.com>
	<625fc13d0609100532n58933486l3f66715c38172cd5@mail.gmail.com>
Message-ID: <4504146D.000002.20805@webmail12.yandex.ru>

>> 1. "double page writes on NAND" - it needs MTD changes and zero UBI changes.
>
>I'll politely disagree here.  UBI _does_ need this on NAND to be
>really usable.  Otherwise you eat 2 pages per block for UBI metadata,
>and that is quite a bit of overhead for a handful of bytes in the
>structures.
Josh, I politely ask you to read what I said once more, sorry :-).

I didn't say the "double page" stuff is not needed. I agree that it *is*
needed, and is very important!

What I said is that this feature requires *zero changes in UBI code*. 
It requires changes in *MTD* code. So this is why I said it
does not really relate to UBI itself, it relates to what I called
"about UBI" in the previous mail. :-) See what I mean?

>> 2. Better UBI utilities as I find the current ones not ideal.
>What do you find lacking or not ideal?  I'm just curious.

I dislike that the utilities accept UBI device number instead of UBI
character device name. And they internally form the UBI device name
using hardcoded "/dev/ubi%d" pattern. It it insane. I may want to name
my UBI devices differently.

I'm partially guilty in this because I started the libubi library with
this insane feature. But I wrote it for my tests and didn't mean to
use it as a generic library. Then I created a new sane version of ubilib
but people had written most of the UBI utilities using the old insane one
by that time...

Also, the ubimkvol utility works only for ubi0 device and does not
work for ubi1 device. I did not dig why.

Artem.



From jwboyer at gmail.com  Sun Sep 10 10:11:04 2006
From: jwboyer at gmail.com (Josh Boyer)
Date: Sun, 10 Sep 2006 09:11:04 -0500
Subject: State of UBI
In-Reply-To: <4504146D.000002.20805@webmail12.yandex.ru>
References: <625fc13d0609091922m42a1caeagfa4e87bc18f2a8d6@mail.gmail.com>
	<625fc13d0609100532n58933486l3f66715c38172cd5@mail.gmail.com>
	<4504146D.000002.20805@webmail12.yandex.ru>
Message-ID: <625fc13d0609100711k1555d439ve7f3e15c63378e87@mail.gmail.com>

On 9/10/06, dedekind <dedekind at yandex.ru> wrote:
> >> 1. "double page writes on NAND" - it needs MTD changes and zero UBI changes.
> >
> >I'll politely disagree here.  UBI _does_ need this on NAND to be
> >really usable.  Otherwise you eat 2 pages per block for UBI metadata,
> >and that is quite a bit of overhead for a handful of bytes in the
> >structures.
> Josh, I politely ask you to read what I said once more, sorry :-).
>
> I didn't say the "double page" stuff is not needed. I agree that it *is*
> needed, and is very important!
>
> What I said is that this feature requires *zero changes in UBI code*.
> It requires changes in *MTD* code. So this is why I said it
> does not really relate to UBI itself, it relates to what I called
> "about UBI" in the previous mail. :-) See what I mean?

Sure, I know the changes need to be made in MTD and not UBI.  But I
think it's important enough to wait for MTD to get that fix before
merging UBI.  I didn't mean to imply that this was somehow a UBI
problem, but rather something that was hindering UBI in general.

Look at it from a user's perspective.  Someone tells you that UBI is
really cool and you should use it, but then you find out you have to
spend 4KiB per eraseblock in overhead on large page NAND devices.
It's just not that appealing.


> >> 2. Better UBI utilities as I find the current ones not ideal.
> >What do you find lacking or not ideal?  I'm just curious.
>
> I dislike that the utilities accept UBI device number instead of UBI
> character device name. And they internally form the UBI device name
> using hardcoded "/dev/ubi%d" pattern. It it insane. I may want to name
> my UBI devices differently.

Hm, ok.  I haven't looked, but that doesn't sound too hard to fix.
Perhaps the current behavior could be left as default.

> I'm partially guilty in this because I started the libubi library with
> this insane feature. But I wrote it for my tests and didn't mean to
> use it as a generic library. Then I created a new sane version of ubilib
> but people had written most of the UBI utilities using the old insane one
> by that time...

Well, nothing has been merged yet so it's easy to fix

> Also, the ubimkvol utility works only for ubi0 device and does not
> work for ubi1 device. I did not dig why.

Sounds like a bug to me.

josh



From dedekind at yandex.ru  Sun Sep 10 10:23:45 2006
From: dedekind at yandex.ru (dedekind)
Date: Sun, 10 Sep 2006 18:23:45 +0400 (MSD)
Subject: State of UBI
In-Reply-To: <625fc13d0609100711k1555d439ve7f3e15c63378e87@mail.gmail.com>
References: <625fc13d0609091922m42a1caeagfa4e87bc18f2a8d6@mail.gmail.com>
	<625fc13d0609100711k1555d439ve7f3e15c63378e87@mail.gmail.com>
Message-ID: <45041FF1.000003.28872@webmail11.yandex.ru>

>But I think it's important enough to wait for MTD to get that fix before merging UBI.

Probably you're right, granted the waiting time is reasonable :)

Artem.



From dedekind at yandex.ru  Sun Sep 10 13:00:04 2006
From: dedekind at yandex.ru (dedekind)
Date: Sun, 10 Sep 2006 21:00:04 +0400 (MSD)
Subject: State of UBI
In-Reply-To: <1157885559.2977.136.camel@pmac.infradead.org>
References: <625fc13d0609091922m42a1caeagfa4e87bc18f2a8d6@mail.gmail.com>
	<1157885559.2977.136.camel@pmac.infradead.org>
Message-ID: <45044494.000002.04222@tide.yandex.ru>

>I had envisaged that it would be fairly much akin to
>another partitioning layer, perhaps requiring a few extra methods to be
>added to the mtd_info.

To be more persuadive - I'll add to my previous mail.

It is similar to disc partitions and LVM volumes.
One can create can create several partitions. Then feed some of them to
LVM and create one or more volume groups (which is similar to UBI device(s)).
Then create logical volumes in each volume group (similar to create UBI volumes
within each UBI device).

E.g., the simplest configuration:
1. hda1 for /boot (otherwise the bootloader has to be smart and understand
   LVM tables)
2. hda2 for LVM
3. and then create as many logical volumes as you want.

And in my previous example it is similar.

1. mtd0 for the kernel (otherwise the bootloader has to be smart enough
   to understand UBI format)
2. mtd1 for UBI
3. then create as many UBI volumes as you want.

Full analogy with LVM. It'd be strange not to follow this model.

Artem.



From dwmw2 at infradead.org  Sun Sep 10 13:44:33 2006
From: dwmw2 at infradead.org (David Woodhouse)
Date: Sun, 10 Sep 2006 18:44:33 +0100
Subject: State of UBI
In-Reply-To: <45044494.000002.04222@tide.yandex.ru>
References: <625fc13d0609091922m42a1caeagfa4e87bc18f2a8d6@mail.gmail.com>
	<1157885559.2977.136.camel@pmac.infradead.org>
	<45044494.000002.04222@tide.yandex.ru>
Message-ID: <1157910273.2977.175.camel@pmac.infradead.org>

On Sun, 2006-09-10 at 21:00 +0400, dedekind wrote:
> Full analogy with LVM. It'd be strange not to follow this model.

Show me the changes that were made to ext3 to make it capable of
mounting these new "LVM devices" where previously it could only do block
devices.

-- 
dwmw2




From joern at wohnheim.fh-wedel.de  Sun Sep 10 18:04:42 2006
From: joern at wohnheim.fh-wedel.de (=?iso-8859-1?Q?J=F6rn?= Engel)
Date: Mon, 11 Sep 2006 00:04:42 +0200
Subject: Overrun end of disk in cache redahead
In-Reply-To: <45012439.5090001@joussein.com>
References: <45012439.5090001@joussein.com>
Message-ID: <20060910220442.GA10482@wohnheim.fh-wedel.de>

On Fri, 8 September 2006 10:05:13 +0200, Felix Joussein wrote:
>
> [...]
> Then I get 3 times "Overrun end of disk in cache redahead"
> [...]
> What am I doing wrong?

Nothing, in principle.  Looks like the readahead code is causing only
trouble for questionable gains.  Can you try the patch below?

J?rn

-- 
If you're willing to restrict the flexibility of your approach,
you can almost always do something better.
-- John Carmack

Remove readahead from block2mtd.

Signed-off-by: J?rn Engel <joern at wohnheim.fh-wedel.de>
---

 drivers/mtd/devices/block2mtd.c |   55 ++--------------------------------------
 1 file changed, 4 insertions(+), 51 deletions(-)

--- slab/drivers/mtd/devices/block2mtd.c~block2mtd	2006-08-11 13:03:22.000000000 +0200
+++ slab/drivers/mtd/devices/block2mtd.c	2006-09-11 00:00:26.000000000 +0200
@@ -39,56 +39,9 @@ struct block2mtd_dev {
 static LIST_HEAD(blkmtd_device_list);
 
 
-#define PAGE_READAHEAD 64
-static void cache_readahead(struct address_space *mapping, int index)
-{
-	filler_t *filler = (filler_t*)mapping->a_ops->readpage;
-	int i, pagei;
-	unsigned ret = 0;
-	unsigned long end_index;
-	struct page *page;
-	LIST_HEAD(page_pool);
-	struct inode *inode = mapping->host;
-	loff_t isize = i_size_read(inode);
-
-	if (!isize) {
-		INFO("iSize=0 in cache_readahead\n");
-		return;
-	}
-
-	end_index = ((isize - 1) >> PAGE_CACHE_SHIFT);
-
-	read_lock_irq(&mapping->tree_lock);
-	for (i = 0; i < PAGE_READAHEAD; i++) {
-		pagei = index + i;
-		if (pagei > end_index) {
-			INFO("Overrun end of disk in cache readahead\n");
-			break;
-		}
-		page = radix_tree_lookup(&mapping->page_tree, pagei);
-		if (page && (!i))
-			break;
-		if (page)
-			continue;
-		read_unlock_irq(&mapping->tree_lock);
-		page = page_cache_alloc_cold(mapping);
-		read_lock_irq(&mapping->tree_lock);
-		if (!page)
-			break;
-		page->index = pagei;
-		list_add(&page->lru, &page_pool);
-		ret++;
-	}
-	read_unlock_irq(&mapping->tree_lock);
-	if (ret)
-		read_cache_pages(mapping, &page_pool, filler, NULL);
-}
-
-
-static struct page* page_readahead(struct address_space *mapping, int index)
+static struct page *readpage(struct address_space *mapping, int index)
 {
 	filler_t *filler = (filler_t*)mapping->a_ops->readpage;
-	cache_readahead(mapping, index);
 	return read_cache_page(mapping, index, filler, NULL);
 }
 
@@ -104,7 +57,7 @@ static int _block2mtd_erase(struct block
 	u_long *max;
 
 	while (pages) {
-		page = page_readahead(mapping, index);
+		page = readpage(mapping, index);
 		if (!page)
 			return -ENOMEM;
 		if (IS_ERR(page))
@@ -174,7 +127,7 @@ static int block2mtd_read(struct mtd_inf
 		len = len - cpylen;
 
 		//      Get page
-		page = page_readahead(dev->blkdev->bd_inode->i_mapping, index);
+		page = readpage(dev->blkdev->bd_inode->i_mapping, index);
 		if (!page)
 			return -ENOMEM;
 		if (IS_ERR(page))
@@ -213,7 +166,7 @@ static int _block2mtd_write(struct block
 		len = len - cpylen;
 
 		//	Get page
-		page = page_readahead(mapping, index);
+		page = readpage(mapping, index);
 		if (!page)
 			return -ENOMEM;
 		if (IS_ERR(page))



From dedekind at yandex.ru  Mon Sep 11 02:11:18 2006
From: dedekind at yandex.ru (dedekind)
Date: Mon, 11 Sep 2006 10:11:18 +0400 (MSD)
Subject: State of UBI
In-Reply-To: <1157910273.2977.175.camel@pmac.infradead.org>
References: <625fc13d0609091922m42a1caeagfa4e87bc18f2a8d6@mail.gmail.com>
	<1157910273.2977.175.camel@pmac.infradead.org>
Message-ID: <4504FE06.000003.08700@webmail12.yandex.ru>

>On Sun, 2006-09-10 at 21:00 +0400, dedekind wrote:
>> Full analogy with LVM. It'd be strange not to follow this model.
>
>Show me the changes that were made to ext3 to make it capable of
>mounting these new "LVM devices" where previously it could only do block
>devices.

I love your tricky questions :-)

Ok, the analogy is indeed not full and stops here. LVM does not change
semantics - you still have block devices with 2 operation - read and write.
I noted this already.

In case of UBI we do have meny semantical changes.

* UBI volumes are bad block free even if the underlying flash may have them
  (like NAND). UBI hides this completely.
* UBI volumes wear are free, i.e., you may use the same eraseblock as much as
  you want and the wear will anyway be distributed over whole flash.
* erase is always asynchronous, i.e., you call erase and it is scheduled for
  erasure in context of the UBI background task.
* we have eraseblock type hints which are useful to let UBI know which
  eraseblock it should pick (with low erase couter, or high, or medium).
  This is not present in MTD.
* UBI maintains volume update operation. This is absent in MTD.
* UBI maintains GC hints. They are useful for a file system to to avoid
  moving eraseblock which are going to be GCed anyway. This is not present
  in MTD. And this is not implemented yet. But is planned.
* UBI maintains atomic eraseblock change operation. This means you may
  change the contents of a LEB atomically. MTD is devoid of this nice
  property which is extremely useful for FSes (e.g., you may garbage
  collect without having a spare logical eraseblock). This is not yet
  implemented but it is easy to implement and it is panned.
* UBI volumes may be dynamically created, deleted and resized. MTD
  assumes only static stuff.

I believe the list is not full. New UBI-oriented software will certainly
make use of these properties and won't work on top of MTD.

For example, JFFS3 assumes that it does not have to think about
wear-levelling. And it makes no sense to use it on top of MTD. It is
UBI-oriented. And it needs only native UBI interface.

Nevertheless, having MTD interface is not a big geal. We may make gluebi
a part of UBI. Then you'll have native interface and MTD-like interfave for
legacy software.


VS. my changes in JFFS2 which make it usable on top of UBI. As soon as we
have gluebi we can forget about it.

Artem.



From dwmw2 at infradead.org  Mon Sep 11 04:11:38 2006
From: dwmw2 at infradead.org (David Woodhouse)
Date: Mon, 11 Sep 2006 09:11:38 +0100
Subject: State of UBI
In-Reply-To: <625fc13d0609100532n58933486l3f66715c38172cd5@mail.gmail.com>
References: <625fc13d0609091922m42a1caeagfa4e87bc18f2a8d6@mail.gmail.com>
	<4503D10E.000001.07116@webmail12.yandex.ru>
	<625fc13d0609100532n58933486l3f66715c38172cd5@mail.gmail.com>
Message-ID: <1157962298.2977.193.camel@pmac.infradead.org>

On Sun, 2006-09-10 at 07:32 -0500, Josh Boyer wrote:
> I'll politely disagree here.  UBI _does_ need this on NAND to be
> really usable.  Otherwise you eat 2 pages per block for UBI metadata,
> and that is quite a bit of overhead for a handful of bytes in the
> structures.

"A handful of bytes" ought to fit into the spare area, and not take real
data pages at all.

-- 
dwmw2




From dedekind at yandex.ru  Mon Sep 11 05:19:42 2006
From: dedekind at yandex.ru (dedekind)
Date: Mon, 11 Sep 2006 13:19:42 +0400 (MSD)
Subject: State of UBI
In-Reply-To: <1157962298.2977.193.camel@pmac.infradead.org>
References: <625fc13d0609091922m42a1caeagfa4e87bc18f2a8d6@mail.gmail.com>
	<1157962298.2977.193.camel@pmac.infradead.org>
Message-ID: <45052A2E.000002.26611@webmail9.yandex.ru>

>"A handful of bytes" ought to fit into the spare area, and not take real
>data pages at all.

It was actually a design decision not to use OOB area and make UBI
flash-independent. OBB area size varies, tends to be ECC-only in
new NANDs, not large enough for UBI VID header.

Artem.



From felix at joussein.com  Mon Sep 11 06:05:20 2006
From: felix at joussein.com (Felix Joussein)
Date: Mon, 11 Sep 2006 12:05:20 +0200
Subject: howto jffs2 + mtd
Message-ID: <450534E0.2000405@joussein.com>

Hello list,

I would like to create a jffs2 filesystem on to an ordinary fresh- out 
of the box 512 Kingston Datatraveller USB Stick.
As I later want to boot from it, I performed the following steps:

fdisk /dev/sda
create 2 partitions
sda1, sda2

syslinux /dev/sda1
mount /dev/sda1 /mnt
cp $allYouNeedToBoot /dev/sda1
umount /mnt

Here now the mtd part:
modprobe block2mtd
echo "/dev/sda2" > /sys/module/block2mtd/parameters/block2mtd
cat /proc/mtd
mtd0: 0f480000 00001000 "block2mtd: /dev/sda2"

now I read in the internet 2 different commands:
either flash_eraseall -j /dev/mtd0
or flash_erase /dev/mtd0 0 00001000

Regardless of what I do, I am not able to mount -t jffs2 /dev/mtdblock0 /mnt
Either I get dmesg "mount jffs2_scan_eraseblock(): magic bitmask 0x1985 
not found" on all consoles, the only way to stop this is to reboot,
or I wait approx. 10 Mins, then I get
CPU:    0
EIP:    0060:[<d09bd77f>]    Not tainted VLI
EFLAGS: 00010206   (2.6.17.13-fwgw #1)
EIP is at block2mtd_erase+0x9b/0x148 [block2mtd]
eax: d0000000   ebx: d0003000   ecx: c11fffe0   edx: c11fffe0
esi: c11fffe0   edi: c11fffe0   ebp: 00000001   esp: c1325eb8
ds: 007b   es: 007b   ss: 0068
Process pdflush (pid: 216, threadinfo=c1324000 task=cfffa540)
Stack: cecc278c 0000dee8 cfe8c368 cf42a340 c1325efc cf42a370 d129db80 
c020209a
       cecc260c cf42a340 ced258d0 ced258d8 ced2592c ced258f8 00002000 
00000000
       0dee9000 20031985 0000000c e41eb0b1 c1325efc 0000000c 00001000 
0000000c
Call Trace:
 <c020209a> jffs2_erase_pending_blocks+0x21a/0x736  <c0202a02> 
jffs2_write_super+0x26/0x34
 <c015eb42> sync_supers+0x96/0xd4  <c0141ee0> pdflush+0x0/0x1a0
 <c0141686> wb_kupdate+0x26/0xd8  <c0141fc6> pdflush+0xe6/0x1a0
 <c0141660> wb_kupdate+0x0/0xd8  <c0130d97> kthread+0xbf/0xd8
 <c0130cd8> kthread+0x0/0xd8  <c0100cd5> kernel_thread_helper+0x5/0xc
Code: ff ff 0f 87 c0 00 00 00 50 e8 72 83 78 ef 8d 98 00 40 00 00 56 e8 
66 83 78 ef 5a 59 39 c3 77 0b eb 3c 89 f6 83 c0 04 39 c3 76 33 <83> 38 
ff 74 f4 90 0f ba 2e 00 19 c0 85 c0 75 36 56 e8 3f 83 78
EIP: [<d09bd77f>] block2mtd_erase+0x9b/0x148 [block2mtd] SS:ESP 
0068:c1325eb8
 BUG: warning at kernel/exit.c:855/do_exit()
 <c012296c> do_exit+0x83c/0x850  <c01147ff> bust_spinlocks+0x3f/0x48
 <c0104580> do_trap+0x0/0xd4  <c0114c6f> do_page_fault+0x353/0x5f4
 <c011491c> do_page_fault+0x0/0x5f4  <c0103c43> error_code+0x4f/0x54
 <d09bd77f> block2mtd_erase+0x9b/0x148 [block2mtd]  <c020209a> 
jffs2_erase_pending_blocks+0x21a/0x736
 <c0202a02> jffs2_write_super+0x26/0x34  <c015eb42> sync_supers+0x96/0xd4
 <c0141ee0> pdflush+0x0/0x1a0  <c0141686> wb_kupdate+0x26/0xd8
 <c0141fc6> pdflush+0xe6/0x1a0  <c0141660> wb_kupdate+0x0/0xd8
 <c0130d97> kthread+0xbf/0xd8  <c0130cd8> kthread+0x0/0xd8
 <c0100cd5> kernel_thread_helper+0x5/0xc


But: the filesystem is mounted.
How ever, accessing /mnt is not possible then... again: reboot is the 
only way out...

I would be very thankfull, if anybody could help me with this.

Thanks,

Felix Joussein



-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.




From nils.faerber at kernelconcepts.de  Mon Sep 11 06:12:16 2006
From: nils.faerber at kernelconcepts.de (Nils Faerber)
Date: Mon, 11 Sep 2006 12:12:16 +0200
Subject: howto jffs2 + mtd
In-Reply-To: <450534E0.2000405@joussein.com>
References: <450534E0.2000405@joussein.com>
Message-ID: <45053680.1060206@kernelconcepts.de>

Felix Joussein schrieb:
> Hello list,
> 
> I would like to create a jffs2 filesystem on to an ordinary fresh- out 
> of the box 512 Kingston Datatraveller USB Stick.
> As I later want to boot from it, I performed the following steps:
> 
> fdisk /dev/sda
> create 2 partitions
> sda1, sda2
> 
> syslinux /dev/sda1
> mount /dev/sda1 /mnt
> cp $allYouNeedToBoot /dev/sda1
> umount /mnt
> 
> Here now the mtd part:
> modprobe block2mtd
> echo "/dev/sda2" > /sys/module/block2mtd/parameters/block2mtd
> cat /proc/mtd
> mtd0: 0f480000 00001000 "block2mtd: /dev/sda2"
> 
> now I read in the internet 2 different commands:
> either flash_eraseall -j /dev/mtd0
> or flash_erase /dev/mtd0 0 00001000

You do not need that on the mtdblock device. This is only useful on real
flash devices, i.e. physicall mapped flash devices, not USB sticks or CF
cards.

[...]
> I would be very thankfull, if anybody could help me with this.

> Thanks,
> Felix Joussein
Cheers
  nils

-- 
kernel concepts GbR      Tel: +49-271-771091-12
Dreisbachstr. 24         Fax: +49-271-771091-19
D-57250 Netphen          Mob: +49-176-21024535
--



From nils.faerber at kernelconcepts.de  Mon Sep 11 06:41:32 2006
From: nils.faerber at kernelconcepts.de (Nils Faerber)
Date: Mon, 11 Sep 2006 12:41:32 +0200
Subject: howto jffs2 + mtd
In-Reply-To: <45053A19.5050801@joussein.com>
References: <450534E0.2000405@joussein.com>
	<45053680.1060206@kernelconcepts.de>
	<45053A19.5050801@joussein.com>
Message-ID: <45053D5C.5020005@kernelconcepts.de>

Felix Joussein schrieb:
>> You do not need that on the mtdblock device. This is only useful on real
>> flash devices, i.e. physicall mapped flash devices, not USB sticks or CF
>> cards.
> So, how else do I get a jffs2 filesystem on my usb or cf?

Oh, sorry, I should have been more precise.
You do not need the flash_erase or flash_erase_all. The rest of the
process is the same.

> As I understand any other filesystem would shredder my usb-stick after a
> approx. 1 mio writes?

But anyway, JFFS2 is not a very good idea on a USB stick. The problem is
that the stick's flash controller already does wear levelling and error
correction for you, transparantly.
With JFFS2 you might end up with doing the process twice which might
result in even worse performance than with a "normal" filesystem, like EXT2.
You should be pretty safe with an ext2 if you mount it with "noatime"
option and if possible, read-only.

> Thanks again,
> Felix
Cheers
  nils

-- 
kernel concepts GbR      Tel: +49-271-771091-12
Dreisbachstr. 24         Fax: +49-271-771091-19
D-57250 Netphen          Mob: +49-176-21024535
--



From jwboyer at gmail.com  Mon Sep 11 09:21:35 2006
From: jwboyer at gmail.com (Josh Boyer)
Date: Mon, 11 Sep 2006 08:21:35 -0500
Subject: State of UBI
In-Reply-To: <45052A2E.000002.26611@webmail9.yandex.ru>
References: <625fc13d0609091922m42a1caeagfa4e87bc18f2a8d6@mail.gmail.com>
	<1157962298.2977.193.camel@pmac.infradead.org>
	<45052A2E.000002.26611@webmail9.yandex.ru>
Message-ID: <625fc13d0609110621p7df16005ua223628f961ad9ab@mail.gmail.com>

On 9/11/06, dedekind <dedekind at yandex.ru> wrote:
> >"A handful of bytes" ought to fit into the spare area, and not take real
> >data pages at all.
>
> It was actually a design decision not to use OOB area and make UBI
> flash-independent. OBB area size varies, tends to be ECC-only in
> new NANDs, not large enough for UBI VID header.

Yes, what Artem said.  It's more than a handful of bytes.  The EC
header and VID headers are both 64 bytes.

josh



From vwool at ru.mvista.com  Wed Sep 13 11:01:41 2006
From: vwool at ru.mvista.com (Vitaly Wool)
Date: Wed, 13 Sep 2006 19:01:41 +0400
Subject: [PATCH] fix small nand_base errors
In-Reply-To: <20060710145637.03433875.vwool@ru.mvista.com>
References: <20060710145637.03433875.vwool@ru.mvista.com>
Message-ID: <45081D55.9090508@ru.mvista.com>

Thomas,

Vitaly Wool wrote:
> Hi Thomas,
>
> please find the patch that fixes small nand_base errors inlined.
> Brief explanation: for nand_write_oob_syndrome, you should first set the position to eccsize, as OOB starts past the eccsize, not eccsize + chunk.
> For nand_fill_oob I guess that's just a typo, otherwise it just doesn't make sense (and OTOH makes this routine write to 0-th OOB byte thus actually marking it as bad).
>   
Can't see this patch applied, which makes NAND base fail for me.

Vitaly



From tglx at linutronix.de  Thu Sep 14 05:07:08 2006
From: tglx at linutronix.de (tglx at linutronix.de)
Date: Thu, 14 Sep 2006 11:07:08 +0200 (CEST)
Subject: [PATCH] fix small nand_base errors
In-Reply-To: <45081D55.9090508@ru.mvista.com>
References: <20060710145637.03433875.vwool@ru.mvista.com>
	<45081D55.9090508@ru.mvista.com>
Message-ID: <10185.194.138.39.55.1158224828.squirrel@www.tglx.de>

> Thomas,
>
> Vitaly Wool wrote:
>> Hi Thomas,
>>
>> please find the patch that fixes small nand_base errors inlined.
>> Brief explanation: for nand_write_oob_syndrome, you should first set the
>> position to eccsize, as OOB starts past the eccsize, not eccsize +
>> chunk.
>> For nand_fill_oob I guess that's just a typo, otherwise it just doesn't
>> make sense (and OTOH makes this routine write to 0-th OOB byte thus
>> actually marking it as bad).
>>
> Can't see this patch applied, which makes NAND base fail for me.

Blame dwmw2. It's in my git tree since 2 month

http://git.infradead.org/?p=users/gleixner/mtd-nand-2.6.git;a=commit;h=8b0036eefd7a96f23244b969417684c8627f5ad6

  tglx





From hskinnemoen at atmel.com  Thu Sep 14 10:29:26 2006
From: hskinnemoen at atmel.com (Haavard Skinnemoen)
Date: Thu, 14 Sep 2006 16:29:26 +0200
Subject: [-mm patch 0/4] AVR32 MTD: Introduction
Message-ID: <20060914162926.6c117b36@cad-250-152.norway.atmel.com>

Hi Andrew and MTD people,

This patchset adds the necessary drivers and infrastructure to access
the external flash on the ATSTK1000 board through the MTD subsystem.

With this stuff in place, it will be possible to use a jffs2
filesystem stored in the external flash as a root filesystem. It might
also be possible to update the boot loader if you drop the write
protection of partition 0.

Andrew, can you apply this to -mm? They probably don't make sense for
the MTD tree until the rest of the AVR32 patches are merged into
mainline, but I'd really appreciate if someone could have a quick look
to see if I did something stupid.

This also needs two patches I've submitted earlier (included in
git-mtd.patch) in order to work, but it should still apply without
them. For the record, these are:
  MTD: Add lock/unlock operations for Atmel AT49BV6416
  MTD: Convert Atmel PRI information to AMD format

This patchset includes the following patches:

  AVR32 MTD: Static Memory Controller driver
  AVR32 MTD: Define struct flash_platform_data
  AVR32 MTD: Mapping driver for the ATSTK1000 board
  AVR32 MTD: AT49BV6416 platform device for atstk1000

And the combined diffstat looks like this:

 arch/avr32/boards/atstk1000/atstk1002.c |   46 ++++++++
 arch/avr32/mach-at32ap/Makefile         |    2 
 arch/avr32/mach-at32ap/at32ap7000.c     |   10 +
 arch/avr32/mach-at32ap/hsmc.c           |  164 +++++++++++++++++++++++++++++
 arch/avr32/mach-at32ap/hsmc.h           |  169 ++++++++++++++++++++++++++++++
 drivers/mtd/maps/Kconfig                |   10 +
 drivers/mtd/maps/Makefile               |    1 
 drivers/mtd/maps/atstk1000.c            |  179 ++++++++++++++++++++++++++++++++
 include/asm-avr32/arch-at32ap/board.h   |    7 +
 include/asm-avr32/arch-at32ap/smc.h     |   60 ++++++++++
 10 files changed, 647 insertions(+), 1 deletion(-)

Best regards,
Haavard



From justin_treon at yahoo.com  Thu Sep 14 12:32:19 2006
From: justin_treon at yahoo.com (Justin Treon)
Date: Thu, 14 Sep 2006 09:32:19 -0700 (PDT)
Subject: JFFS2 ECC options
In-Reply-To: <000f01c6d0e8$145e1ce0$d204960a@nap.st.com>
Message-ID: <20060914163219.74505.qmail@web30505.mail.mud.yahoo.com>


> I'm working with JFFS2 on a NAND device. In order to
> disable the software ECC is it enough to set the mtd
> field "nand.eccmode" to "NAND_ECC_NONE"? 
> If I do this, I have some CRC errors if JFFS2 file
> system includes a bad block. Is it right? Does the
> CRC check depend on the ECC options?
> 
> In order to use the summary support, is it enough to
> set the macro "CONFIG_JFFS2_SUMMARY" in the file
> ".config"? Do I have to re-make the file system
> image (that I create using the mkfs.jffs2 utility)
> in order to use it with the summary support?
> 

I have no idea about your first question.  You may
want to ask it again.  

Regarding summary support I have never been able to
make a jffs2 filing system that used summary support
with the mkfs.jffs2 tool that worked.  I create the
filing system with summary support on an empty chip
and then transfer the files. Please let me knhwo if
you get it to work with the mkfs.jffs2 tool.

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 



From dedekind at yandex.ru  Thu Sep 14 13:04:59 2006
From: dedekind at yandex.ru (dedekind)
Date: Thu, 14 Sep 2006 21:04:59 +0400 (MSD)
Subject: JFFS2 ECC options
In-Reply-To: <20060914163219.74505.qmail@web30505.mail.mud.yahoo.com>
References: <20060914163219.74505.qmail@web30505.mail.mud.yahoo.com>
Message-ID: <45098BBB.000009.05972@webmail11.yandex.ru>

>I have no idea about your first question.  You may
>want to ask it again.  
>
>Regarding summary support I have never been able to
>make a jffs2 filing system that used summary support
>with the mkfs.jffs2 tool that worked.  I create the
>filing system with summary support on an empty chip
>and then transfer the files. Please let me knhwo if
>you get it to work with the mkfs.jffs2 tool.

Yeah, it makes a lot of sense not integrate the "sumtool" stuff
and mkfs.jffs2.

Nevertheless, it would prabably be nice if you sent a bugreport if
it doesn't work.

Artem.



From hskinnemoen at atmel.com  Thu Sep 14 10:31:21 2006
From: hskinnemoen at atmel.com (Haavard Skinnemoen)
Date: Thu, 14 Sep 2006 16:31:21 +0200
Subject: [-mm patch 2/4] AVR32 MTD: Define struct flash_platform_data
In-Reply-To: <20060914163026.49766346@cad-250-152.norway.atmel.com>
References: <20060914162926.6c117b36@cad-250-152.norway.atmel.com>
	<20060914163026.49766346@cad-250-152.norway.atmel.com>
Message-ID: <20060914163121.241dec3e@cad-250-152.norway.atmel.com>

Define a data structure for passing board-specific information to an
MTD mapping driver. For now it specifies a default partition layout.

Signed-off-by: Haavard Skinnemoen <hskinnemoen at atmel.com>
---
 include/asm-avr32/arch-at32ap/board.h |    7 +++++++
 1 file changed, 7 insertions(+)

Index: linux-2.6.18-rc5-mm1/include/asm-avr32/arch-at32ap/board.h
===================================================================
--- linux-2.6.18-rc5-mm1.orig/include/asm-avr32/arch-at32ap/board.h	2006-09-07 15:14:20.000000000 +0200
+++ linux-2.6.18-rc5-mm1/include/asm-avr32/arch-at32ap/board.h	2006-09-07 15:19:08.000000000 +0200
@@ -6,6 +6,13 @@
 
 #include <linux/types.h>
 
+struct mtd_partition;
+
+struct flash_platform_data {
+	unsigned int nr_parts;
+	struct mtd_partition *parts;
+};
+
 /* Add basic devices: system manager, interrupt controller, portmuxes, etc. */
 void at32_add_system_devices(void);
 



From hskinnemoen at atmel.com  Thu Sep 14 10:34:21 2006
From: hskinnemoen at atmel.com (Haavard Skinnemoen)
Date: Thu, 14 Sep 2006 16:34:21 +0200
Subject: [-mm patch 4/4] AVR32 MTD: AT49BV6416 platform device for atstk1000
In-Reply-To: <20060914163259.068abe6d@cad-250-152.norway.atmel.com>
References: <20060914162926.6c117b36@cad-250-152.norway.atmel.com>
	<20060914163026.49766346@cad-250-152.norway.atmel.com>
	<20060914163121.241dec3e@cad-250-152.norway.atmel.com>
	<20060914163259.068abe6d@cad-250-152.norway.atmel.com>
Message-ID: <20060914163421.53ac453e@cad-250-152.norway.atmel.com>

Register a platform device for the AT49BV6416 NOR flash chip on the
ATSTK1000 development board for use by the ATSTK1000 MTD map driver.

Signed-off-by: Haavard Skinnemoen <hskinnemoen at atmel.com>
---
 arch/avr32/boards/atstk1000/atstk1002.c |   46 ++++++++++++++++++++++++++++
 1 file changed, 46 insertions(+)

Index: linux-2.6.18-rc5-mm1/arch/avr32/boards/atstk1000/atstk1002.c
===================================================================
--- linux-2.6.18-rc5-mm1.orig/arch/avr32/boards/atstk1000/atstk1002.c	2006-09-07 15:18:55.000000000 +0200
+++ linux-2.6.18-rc5-mm1/arch/avr32/boards/atstk1000/atstk1002.c	2006-09-07 15:21:18.000000000 +0200
@@ -8,6 +8,9 @@
  * published by the Free Software Foundation.
  */
 #include <linux/init.h>
+#include <linux/platform_device.h>
+#include <linux/mtd/mtd.h>
+#include <linux/mtd/partitions.h>
 
 #include <asm/arch/board.h>
 
@@ -20,6 +23,47 @@ struct eth_platform_data __initdata eth0
 
 extern struct lcdc_platform_data atstk1000_fb0_data;
 
+static struct mtd_partition flash_parts[] = {
+	{
+		.name           = "u-boot",
+		.offset         = 0x00000000,
+		.size           = 0x00020000,           /* 128 KiB */
+		.mask_flags     = MTD_WRITEABLE,
+	},
+	{
+		.name           = "root",
+		.offset         = 0x00020000,
+		.size           = 0x007d0000,
+	},
+	{
+		.name           = "env",
+		.offset         = 0x007f0000,
+		.size           = 0x00010000,
+		.mask_flags     = MTD_WRITEABLE,
+	},
+};
+
+static struct flash_platform_data flash_data = {
+	.nr_parts	= ARRAY_SIZE(flash_parts),
+	.parts		= flash_parts,
+};
+
+struct resource flash_resource = {
+	.start		= 0x00000000,
+	.end		= 0x007fffff,
+	.flags		= IORESOURCE_MEM,
+};
+
+struct platform_device flash_device = {
+	.name		= "atstk1000-flash",
+	.id		= 0,
+	.resource	= &flash_resource,
+	.num_resources	= 1,
+	.dev		= {
+		.platform_data = &flash_data,
+	},
+};
+
 static int __init atstk1002_init(void)
 {
 	at32_add_system_devices();
@@ -32,6 +76,8 @@ static int __init atstk1002_init(void)
 	at32_add_device_spi(0);
 	at32_add_device_lcdc(0, &atstk1000_fb0_data);
 
+	platform_device_register(&flash_device);
+
 	return 0;
 }
 postcore_initcall(atstk1002_init);



From hskinnemoen at atmel.com  Thu Sep 14 10:32:59 2006
From: hskinnemoen at atmel.com (Haavard Skinnemoen)
Date: Thu, 14 Sep 2006 16:32:59 +0200
Subject: [-mm patch 3/4] AVR32 MTD: Mapping driver for the ATSTK1000 board
In-Reply-To: <20060914163121.241dec3e@cad-250-152.norway.atmel.com>
References: <20060914162926.6c117b36@cad-250-152.norway.atmel.com>
	<20060914163026.49766346@cad-250-152.norway.atmel.com>
	<20060914163121.241dec3e@cad-250-152.norway.atmel.com>
Message-ID: <20060914163259.068abe6d@cad-250-152.norway.atmel.com>

Add mapping driver for the AT49BV6416 NOR flash chip on the ATSTK1000
development board.

Signed-off-by: Haavard Skinnemoen <hskinnemoen at atmel.com>
---
 drivers/mtd/maps/Kconfig     |   10 ++
 drivers/mtd/maps/Makefile    |    1 
 drivers/mtd/maps/atstk1000.c |  179 +++++++++++++++++++++++++++++++++++++++++++
 3 files changed, 190 insertions(+)

Index: linux-2.6.18-rc5-mm1/drivers/mtd/maps/Kconfig
===================================================================
--- linux-2.6.18-rc5-mm1.orig/drivers/mtd/maps/Kconfig	2006-09-07 15:56:47.000000000 +0200
+++ linux-2.6.18-rc5-mm1/drivers/mtd/maps/Kconfig	2006-09-07 16:18:47.000000000 +0200
@@ -630,5 +630,15 @@ config MTD_PLATRAM
 
 	  This selection automatically selects the map_ram driver.
 
+config MTD_ATSTK1000
+	tristate "Map driver for NOR flash on Atmel ATSTK1000"
+	depends on MTD && AVR32 && BOARD_ATSTK1000
+	select MTD_CFI
+	select MTD_CFI_AMDSTD
+	select MTD_PARTITIONS
+	help
+	  Map driver for NOR flash on the Atmel ATSTK1000 development
+	  board.
+
 endmenu
 
Index: linux-2.6.18-rc5-mm1/drivers/mtd/maps/Makefile
===================================================================
--- linux-2.6.18-rc5-mm1.orig/drivers/mtd/maps/Makefile	2006-09-07 15:56:47.000000000 +0200
+++ linux-2.6.18-rc5-mm1/drivers/mtd/maps/Makefile	2006-09-07 16:16:03.000000000 +0200
@@ -71,3 +71,4 @@ obj-$(CONFIG_MTD_PLATRAM)	+= plat-ram.o
 obj-$(CONFIG_MTD_OMAP_NOR)	+= omap_nor.o
 obj-$(CONFIG_MTD_MTX1)		+= mtx-1_flash.o
 obj-$(CONFIG_MTD_TQM834x)	+= tqm834x.o
+obj-$(CONFIG_MTD_ATSTK1000)	+= atstk1000.o
Index: linux-2.6.18-rc5-mm1/drivers/mtd/maps/atstk1000.c
===================================================================
--- /dev/null	1970-01-01 00:00:00.000000000 +0000
+++ linux-2.6.18-rc5-mm1/drivers/mtd/maps/atstk1000.c	2006-09-07 16:16:03.000000000 +0200
@@ -0,0 +1,179 @@
+/*
+ * Flash memory support for the ATSTK1000 development board
+ *
+ * Copyright (C) 2006 Atmel Corporation
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include <linux/init.h>
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/platform_device.h>
+
+#include <linux/mtd/mtd.h>
+#include <linux/mtd/map.h>
+#include <linux/mtd/partitions.h>
+
+#include <asm/io.h>
+#include <asm/arch/board.h>
+#include <asm/arch/smc.h>
+
+static struct smc_config flash_config = {
+	.ncs_read_setup		= 0,
+	.nrd_setup		= 40,
+	.ncs_write_setup	= 0,
+	.nwe_setup		= 10,
+
+	.ncs_read_pulse		= 80,
+	.nrd_pulse		= 40,
+	.ncs_write_pulse	= 65,
+	.nwe_pulse		= 55,
+
+	.read_cycle		= 120,
+	.write_cycle		= 120,
+
+	.bus_width		= 2,
+	.nrd_controlled		= 1,
+	.nwe_controlled		= 1,
+	.byte_write		= 1,
+};
+
+struct atstk1000_flash {
+	struct mtd_info		*mtd;
+	struct map_info		map;
+	unsigned int		nr_parts;
+	struct mtd_partition	*parts;
+};
+
+static const char *part_probes[] = { "cmdlinepart", NULL };
+
+static int __devinit atstk1000_flash_probe(struct platform_device *pdev)
+{
+	struct flash_platform_data *plat = pdev->dev.platform_data;
+	struct atstk1000_flash *flash;
+	struct resource *mem;
+	struct mtd_partition *parts;
+	unsigned long size;
+	int nr_parts;
+	int ret;
+
+	mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+	if (!mem)
+		return -ENXIO;
+
+	flash = kzalloc(sizeof(struct atstk1000_flash), GFP_KERNEL);
+	if (!flash)
+		return -ENOMEM;
+
+	size = mem->end - mem->start + 1;
+
+	ret = smc_set_configuration(0, &flash_config);
+	if (ret < 0)
+		goto out_free_flash;
+
+	ret = -ENOMEM;
+	flash->map.virt = ioremap(mem->start, size);
+	if (!flash->map.virt)
+		goto out_free_flash;
+	flash->map.name = pdev->dev.bus_id;
+	flash->map.phys = mem->start;
+	flash->map.size = size;
+	flash->map.bankwidth = 2;
+
+	simple_map_init(&flash->map);
+
+	ret = -ENXIO;
+	flash->mtd = do_map_probe("cfi_probe", &flash->map);
+	if (!flash->mtd)
+		goto out_unmap_mem;
+	flash->mtd->owner = THIS_MODULE;
+
+	if (flash->mtd->unlock) {
+		printk("ATSTK1000 flash: unlocking area 0x%08lx-0x%08lx\n",
+		       (unsigned long)mem->start, (unsigned long)mem->end);
+		ret = flash->mtd->unlock(flash->mtd, mem->start, size);
+		if (ret < 0)
+			goto out_destroy_map;
+	}
+
+	nr_parts = parse_mtd_partitions(flash->mtd, part_probes, &parts, 0);
+	if (nr_parts > 0) {
+		flash->parts = parts;
+	} else if (plat) {
+		parts = plat->parts;
+		nr_parts = plat->nr_parts;
+	}
+	if (nr_parts <= 0) {
+		printk(KERN_NOTICE "ATSTK1000 flash: no partition info "
+		       "available, registering whole flash\n");
+		add_mtd_device(flash->mtd);
+	} else {
+		ret = add_mtd_partitions(flash->mtd, parts, nr_parts);
+		if (ret < 0)
+			goto out_free_parts;
+	}
+
+	flash->nr_parts = nr_parts;
+
+	platform_set_drvdata(pdev, flash);
+	return 0;
+
+out_free_parts:
+	kfree(flash->parts);
+out_destroy_map:
+	map_destroy(flash->mtd);
+out_unmap_mem:
+	iounmap(flash->map.virt);
+out_free_flash:
+	kfree(flash);
+	return ret;
+}
+
+static int __devexit atstk1000_flash_remove(struct platform_device *pdev)
+{
+	struct atstk1000_flash *flash = platform_get_drvdata(pdev);
+
+	if (flash->mtd) {
+		if (flash->nr_parts > 0)
+			del_mtd_partitions(flash->mtd);
+		else
+			del_mtd_device(flash->mtd);
+
+		kfree(flash->parts);
+
+		map_destroy(flash->mtd);
+		iounmap(flash->map.virt);
+		kfree(flash);
+	}
+
+	platform_set_drvdata(pdev, NULL);
+	return 0;
+}
+
+static struct platform_driver atstk1000_flash_driver = {
+	.probe	= atstk1000_flash_probe,
+	.remove	= __devexit_p(atstk1000_flash_remove),
+	.driver	= {
+		.name	= "atstk1000-flash",
+	},
+};
+
+static int __init atstk1000_flash_init(void)
+{
+	return platform_driver_register(&atstk1000_flash_driver);
+}
+
+static void __exit atstk1000_flash_exit(void)
+{
+	platform_driver_unregister(&atstk1000_flash_driver);
+}
+
+module_init(atstk1000_flash_init);
+module_exit(atstk1000_flash_exit);
+
+MODULE_LICENSE("GPL");
+MODULE_DESCRIPTION("MTD NOR map driver for the ATSTK1000 board");
+MODULE_AUTHOR("Haavard Skinnemoen <hskinnemoen at atmel.com>");



From hskinnemoen at atmel.com  Thu Sep 14 10:30:26 2006
From: hskinnemoen at atmel.com (Haavard Skinnemoen)
Date: Thu, 14 Sep 2006 16:30:26 +0200
Subject: [-mm patch 1/4] AVR32 MTD: Static Memory Controller driver
In-Reply-To: <20060914162926.6c117b36@cad-250-152.norway.atmel.com>
References: <20060914162926.6c117b36@cad-250-152.norway.atmel.com>
Message-ID: <20060914163026.49766346@cad-250-152.norway.atmel.com>

This adds a simple API for configuring the static memory controller
along with an implementation for the Atmel HSMC.

Signed-off-by: Haavard Skinnemoen <hskinnemoen at atmel.com>
---
 arch/avr32/mach-at32ap/Makefile     |    2 
 arch/avr32/mach-at32ap/at32ap7000.c |   10 ++
 arch/avr32/mach-at32ap/hsmc.c       |  164 ++++++++++++++++++++++++++++++++++
 arch/avr32/mach-at32ap/hsmc.h       |  169 ++++++++++++++++++++++++++++++++++++
 include/asm-avr32/arch-at32ap/smc.h |   60 ++++++++++++
 5 files changed, 404 insertions(+), 1 deletion(-)

Index: linux-2.6.18-rc2-mm1/arch/avr32/mach-at32ap/Makefile
===================================================================
--- linux-2.6.18-rc2-mm1.orig/arch/avr32/mach-at32ap/Makefile	2006-08-01 16:16:07.000000000 +0200
+++ linux-2.6.18-rc2-mm1/arch/avr32/mach-at32ap/Makefile	2006-08-01 16:49:52.000000000 +0200
@@ -1,2 +1,2 @@
-obj-y				+= at32ap.o clock.o pio.o intc.o extint.o
+obj-y				+= at32ap.o clock.o pio.o intc.o extint.o hsmc.o
 obj-$(CONFIG_CPU_AT32AP7000)	+= at32ap7000.o
Index: linux-2.6.18-rc2-mm1/arch/avr32/mach-at32ap/at32ap7000.c
===================================================================
--- linux-2.6.18-rc2-mm1.orig/arch/avr32/mach-at32ap/at32ap7000.c	2006-08-01 16:16:07.000000000 +0200
+++ linux-2.6.18-rc2-mm1/arch/avr32/mach-at32ap/at32ap7000.c	2006-08-01 16:49:52.000000000 +0200
@@ -450,6 +450,13 @@ static struct clk hramc_clk = {
 	.users		= 1,
 };
 
+static struct resource smc0_resource[] = {
+	PBMEM(0xfff03400),
+};
+DEFINE_DEV(smc, 0);
+DEV_CLK(pclk, smc0, pbb, 13);
+DEV_CLK(mck, smc0, hsb, 0);
+
 static struct platform_device pdc_device = {
 	.name		= "pdc",
 	.id		= 0,
@@ -503,6 +510,7 @@ void __init at32_add_system_devices(void
 
 	platform_device_register(&at32_sm_device);
 	platform_device_register(&at32_intc0_device);
+	platform_device_register(&smc0_device);
 	platform_device_register(&pdc_device);
 
 	platform_device_register(&pio0_device);
@@ -796,6 +804,8 @@ struct clk *at32_clock_list[] = {
 	&at32_intc0_pclk,
 	&ebi_clk,
 	&hramc_clk,
+	&smc0_pclk,
+	&smc0_mck,
 	&pdc_hclk,
 	&pdc_pclk,
 	&pico_clk,
Index: linux-2.6.18-rc2-mm1/arch/avr32/mach-at32ap/hsmc.c
===================================================================
--- /dev/null	1970-01-01 00:00:00.000000000 +0000
+++ linux-2.6.18-rc2-mm1/arch/avr32/mach-at32ap/hsmc.c	2006-08-01 16:49:52.000000000 +0200
@@ -0,0 +1,164 @@
+/*
+ * Static Memory Controller for AT32 chips
+ *
+ * Copyright (C) 2006 Atmel Corporation
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+#define DEBUG
+#include <linux/clk.h>
+#include <linux/err.h>
+#include <linux/init.h>
+#include <linux/module.h>
+#include <linux/platform_device.h>
+
+#include <asm/io.h>
+#include <asm/arch/smc.h>
+
+#include "hsmc.h"
+
+#define NR_CHIP_SELECTS 6
+
+struct hsmc {
+	void __iomem *regs;
+	struct clk *pclk;
+	struct clk *mck;
+};
+
+static struct hsmc *hsmc;
+
+int smc_set_configuration(int cs, const struct smc_config *config)
+{
+	unsigned long mul;
+	unsigned long offset;
+	u32 setup, pulse, cycle, mode;
+
+	if (!hsmc)
+		return -ENODEV;
+	if (cs >= NR_CHIP_SELECTS)
+		return -EINVAL;
+
+	/*
+	 * cycles = x / T = x * f
+	 *   = ((x * 1000000000) * ((f * 65536) / 1000000000)) / 65536
+	 *   = ((x * 1000000000) * (((f / 10000) * 65536) / 100000)) / 65536
+	 */
+	mul = (clk_get_rate(hsmc->mck) / 10000) << 16;
+	mul /= 100000;
+
+#define ns2cyc(x) ((((x) * mul) + 65535) >> 16)
+
+	setup = (HSMC_BF(NWE_SETUP, ns2cyc(config->nwe_setup))
+		 | HSMC_BF(NCS_WR_SETUP, ns2cyc(config->ncs_write_setup))
+		 | HSMC_BF(NRD_SETUP, ns2cyc(config->nrd_setup))
+		 | HSMC_BF(NCS_RD_SETUP, ns2cyc(config->ncs_read_setup)));
+	pulse = (HSMC_BF(NWE_PULSE, ns2cyc(config->nwe_pulse))
+		 | HSMC_BF(NCS_WR_PULSE, ns2cyc(config->ncs_write_pulse))
+		 | HSMC_BF(NRD_PULSE, ns2cyc(config->nrd_pulse))
+		 | HSMC_BF(NCS_RD_PULSE, ns2cyc(config->ncs_read_pulse)));
+	cycle = (HSMC_BF(NWE_CYCLE, ns2cyc(config->write_cycle))
+		 | HSMC_BF(NRD_CYCLE, ns2cyc(config->read_cycle)));
+
+	switch (config->bus_width) {
+	case 1:
+		mode = HSMC_BF(DBW, HSMC_DBW_8_BITS);
+		break;
+	case 2:
+		mode = HSMC_BF(DBW, HSMC_DBW_16_BITS);
+		break;
+	case 4:
+		mode = HSMC_BF(DBW, HSMC_DBW_32_BITS);
+		break;
+	default:
+		return -EINVAL;
+	}
+
+	if (config->nrd_controlled)
+		mode |= HSMC_BIT(READ_MODE);
+	if (config->nwe_controlled)
+		mode |= HSMC_BIT(WRITE_MODE);
+	if (config->byte_write)
+		mode |= HSMC_BIT(BAT);
+
+	pr_debug("smc cs%d: setup/%08x pulse/%08x cycle/%08x mode/%08x\n",
+		 cs, setup, pulse, cycle, mode);
+
+	offset = cs * 0x10;
+	hsmc_writel(hsmc, SETUP0 + offset, setup);
+	hsmc_writel(hsmc, PULSE0 + offset, pulse);
+	hsmc_writel(hsmc, CYCLE0 + offset, cycle);
+	hsmc_writel(hsmc, MODE0 + offset, mode);
+	hsmc_readl(hsmc, MODE0); /* I/O barrier */
+
+	return 0;
+}
+EXPORT_SYMBOL(smc_set_configuration);
+
+static int hsmc_probe(struct platform_device *pdev)
+{
+	struct resource *regs;
+	struct clk *pclk, *mck;
+	int ret;
+
+	if (hsmc)
+		return -EBUSY;
+
+	regs = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+	if (!regs)
+		return -ENXIO;
+	pclk = clk_get(&pdev->dev, "pclk");
+	if (IS_ERR(pclk))
+		return PTR_ERR(pclk);
+	mck = clk_get(&pdev->dev, "mck");
+	if (IS_ERR(mck)) {
+		ret = PTR_ERR(mck);
+		goto out_put_pclk;
+	}
+
+	ret = -ENOMEM;
+	hsmc = kzalloc(sizeof(struct hsmc), GFP_KERNEL);
+	if (!hsmc)
+		goto out_put_clocks;
+
+	clk_enable(pclk);
+	clk_enable(mck);
+
+	hsmc->pclk = pclk;
+	hsmc->mck = mck;
+	hsmc->regs = ioremap(regs->start, regs->end - regs->start + 1);
+	if (!hsmc->regs)
+		goto out_disable_clocks;
+
+	dev_info(&pdev->dev, "Atmel Static Memory Controller at 0x%08lx\n",
+		 (unsigned long)regs->start);
+
+	platform_set_drvdata(pdev, hsmc);
+
+	return 0;
+
+out_disable_clocks:
+	clk_disable(mck);
+	clk_disable(pclk);
+	kfree(hsmc);
+out_put_clocks:
+	clk_put(mck);
+out_put_pclk:
+	clk_put(pclk);
+	hsmc = NULL;
+	return ret;
+}
+
+static struct platform_driver hsmc_driver = {
+	.probe		= hsmc_probe,
+	.driver		= {
+		.name	= "smc",
+	},
+};
+
+static int __init hsmc_init(void)
+{
+	return platform_driver_register(&hsmc_driver);
+}
+arch_initcall(hsmc_init);
Index: linux-2.6.18-rc2-mm1/arch/avr32/mach-at32ap/hsmc.h
===================================================================
--- /dev/null	1970-01-01 00:00:00.000000000 +0000
+++ linux-2.6.18-rc2-mm1/arch/avr32/mach-at32ap/hsmc.h	2006-08-01 16:49:52.000000000 +0200
@@ -0,0 +1,169 @@
+/*
+ * Register definitions for Atmel Static Memory Controller (SMC)
+ *
+ * Copyright (C) 2006 Atmel Corporation
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+#ifndef __ASM_AVR32_HSMC_H__
+#define __ASM_AVR32_HSMC_H__
+
+/* HSMC register offsets */
+#define HSMC_SETUP0                            0x0000
+#define HSMC_PULSE0                            0x0004
+#define HSMC_CYCLE0                            0x0008
+#define HSMC_MODE0                             0x000c
+#define HSMC_SETUP1                            0x0010
+#define HSMC_PULSE1                            0x0014
+#define HSMC_CYCLE1                            0x0018
+#define HSMC_MODE1                             0x001c
+#define HSMC_SETUP2                            0x0020
+#define HSMC_PULSE2                            0x0024
+#define HSMC_CYCLE2                            0x0028
+#define HSMC_MODE2                             0x002c
+#define HSMC_SETUP3                            0x0030
+#define HSMC_PULSE3                            0x0034
+#define HSMC_CYCLE3                            0x0038
+#define HSMC_MODE3                             0x003c
+#define HSMC_SETUP4                            0x0040
+#define HSMC_PULSE4                            0x0044
+#define HSMC_CYCLE4                            0x0048
+#define HSMC_MODE4                             0x004c
+#define HSMC_SETUP5                            0x0050
+#define HSMC_PULSE5                            0x0054
+#define HSMC_CYCLE5                            0x0058
+#define HSMC_MODE5                             0x005c
+
+/* Bitfields in SETUP0 */
+#define HSMC_NWE_SETUP_OFFSET                  0
+#define HSMC_NWE_SETUP_SIZE                    6
+#define HSMC_NCS_WR_SETUP_OFFSET               8
+#define HSMC_NCS_WR_SETUP_SIZE                 6
+#define HSMC_NRD_SETUP_OFFSET                  16
+#define HSMC_NRD_SETUP_SIZE                    6
+#define HSMC_NCS_RD_SETUP_OFFSET               24
+#define HSMC_NCS_RD_SETUP_SIZE                 6
+
+/* Bitfields in PULSE0 */
+#define HSMC_NWE_PULSE_OFFSET                  0
+#define HSMC_NWE_PULSE_SIZE                    7
+#define HSMC_NCS_WR_PULSE_OFFSET               8
+#define HSMC_NCS_WR_PULSE_SIZE                 7
+#define HSMC_NRD_PULSE_OFFSET                  16
+#define HSMC_NRD_PULSE_SIZE                    7
+#define HSMC_NCS_RD_PULSE_OFFSET               24
+#define HSMC_NCS_RD_PULSE_SIZE                 7
+
+/* Bitfields in CYCLE0 */
+#define HSMC_NWE_CYCLE_OFFSET                  0
+#define HSMC_NWE_CYCLE_SIZE                    9
+#define HSMC_NRD_CYCLE_OFFSET                  16
+#define HSMC_NRD_CYCLE_SIZE                    9
+
+/* Bitfields in MODE0 */
+#define HSMC_READ_MODE_OFFSET                  0
+#define HSMC_READ_MODE_SIZE                    1
+#define HSMC_WRITE_MODE_OFFSET                 1
+#define HSMC_WRITE_MODE_SIZE                   1
+#define HSMC_EXNW_MODE_OFFSET                  4
+#define HSMC_EXNW_MODE_SIZE                    2
+#define HSMC_BAT_OFFSET                        8
+#define HSMC_BAT_SIZE                          1
+#define HSMC_DBW_OFFSET                        12
+#define HSMC_DBW_SIZE                          2
+#define HSMC_TDF_CYCLES_OFFSET                 16
+#define HSMC_TDF_CYCLES_SIZE                   4
+#define HSMC_TDF_MODE_OFFSET                   20
+#define HSMC_TDF_MODE_SIZE                     1
+#define HSMC_PMEN_OFFSET                       24
+#define HSMC_PMEN_SIZE                         1
+#define HSMC_PS_OFFSET                         28
+#define HSMC_PS_SIZE                           2
+
+/* Bitfields in SETUP1 */
+
+/* Bitfields in PULSE1 */
+
+/* Bitfields in CYCLE1 */
+
+/* Bitfields in MODE1 */
+#define HSMC_PD_OFFSET                         28
+#define HSMC_PD_SIZE                           2
+
+/* Bitfields in SETUP2 */
+
+/* Bitfields in PULSE2 */
+
+/* Bitfields in CYCLE2 */
+
+/* Bitfields in MODE2 */
+
+/* Bitfields in SETUP3 */
+
+/* Bitfields in PULSE3 */
+
+/* Bitfields in CYCLE3 */
+
+/* Bitfields in MODE3 */
+
+/* Bitfields in SETUP4 */
+
+/* Bitfields in PULSE4 */
+
+/* Bitfields in CYCLE4 */
+
+/* Bitfields in MODE4 */
+
+/* Bitfields in SETUP5 */
+
+/* Bitfields in PULSE5 */
+
+/* Bitfields in CYCLE5 */
+
+/* Bitfields in MODE5 */
+
+/* Constants for READ_MODE */
+#define HSMC_READ_MODE_NCS_CONTROLLED          0
+#define HSMC_READ_MODE_NRD_CONTROLLED          1
+
+/* Constants for WRITE_MODE */
+#define HSMC_WRITE_MODE_NCS_CONTROLLED         0
+#define HSMC_WRITE_MODE_NWE_CONTROLLED         1
+
+/* Constants for EXNW_MODE */
+#define HSMC_EXNW_MODE_DISABLED                0
+#define HSMC_EXNW_MODE_RESERVED                1
+#define HSMC_EXNW_MODE_FROZEN                  2
+#define HSMC_EXNW_MODE_READY                   3
+
+/* Constants for BAT */
+#define HSMC_BAT_BYTE_SELECT                   0
+#define HSMC_BAT_BYTE_WRITE                    1
+
+/* Constants for DBW */
+#define HSMC_DBW_8_BITS                        0
+#define HSMC_DBW_16_BITS                       1
+#define HSMC_DBW_32_BITS                       2
+
+/* Bit manipulation macros */
+#define HSMC_BIT(name)							\
+	(1 << HSMC_##name##_OFFSET)
+#define HSMC_BF(name,value)						\
+	(((value) & ((1 << HSMC_##name##_SIZE) - 1))			\
+	 << HSMC_##name##_OFFSET)
+#define HSMC_BFEXT(name,value)						\
+	(((value) >> HSMC_##name##_OFFSET)				\
+	 & ((1 << HSMC_##name##_SIZE) - 1))
+#define HSMC_BFINS(name,value,old)					\
+	(((old) & ~(((1 << HSMC_##name##_SIZE) - 1)			\
+		    << HSMC_##name##_OFFSET)) | HSMC_BF(name,value))
+
+/* Register access macros */
+#define hsmc_readl(port,reg)						\
+	readl((port)->regs + HSMC_##reg)
+#define hsmc_writel(port,reg,value)					\
+	writel((value), (port)->regs + HSMC_##reg)
+
+#endif /* __ASM_AVR32_HSMC_H__ */
Index: linux-2.6.18-rc2-mm1/include/asm-avr32/arch-at32ap/smc.h
===================================================================
--- /dev/null	1970-01-01 00:00:00.000000000 +0000
+++ linux-2.6.18-rc2-mm1/include/asm-avr32/arch-at32ap/smc.h	2006-08-01 16:49:52.000000000 +0200
@@ -0,0 +1,60 @@
+/*
+ * Static Memory Controller for AT32 chips
+ *
+ * Copyright (C) 2006 Atmel Corporation
+ *
+ * Inspired by the OMAP2 General-Purpose Memory Controller interface
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+#ifndef __ARCH_AT32AP_SMC_H
+#define __ARCH_AT32AP_SMC_H
+
+/*
+ * All timing parameters are in nanoseconds.
+ */
+struct smc_config {
+	/* Delay from address valid to assertion of given strobe */
+	u16		ncs_read_setup;
+	u16		nrd_setup;
+	u16		ncs_write_setup;
+	u16		nwe_setup;
+
+	/* Pulse length of given strobe */
+	u16		ncs_read_pulse;
+	u16		nrd_pulse;
+	u16		ncs_write_pulse;
+	u16		nwe_pulse;
+
+	/* Total cycle length of given operation */
+	u16		read_cycle;
+	u16		write_cycle;
+
+	/* Bus width in bytes */
+	u8		bus_width;
+
+	/*
+	 * 0: Data is sampled on rising edge of NCS
+	 * 1: Data is sampled on rising edge of NRD
+	 */
+	unsigned int	nrd_controlled:1;
+
+	/*
+	 * 0: Data is driven on falling edge of NCS
+	 * 1: Data is driven on falling edge of NWR
+	 */
+	unsigned int	nwe_controlled:1;
+
+	/*
+	 * 0: Byte select access type
+	 * 1: Byte write access type
+	 */
+	unsigned int	byte_write:1;
+};
+
+extern int smc_set_configuration(int cs, const struct smc_config *config);
+extern struct smc_config *smc_get_configuration(int cs);
+
+#endif /* __ARCH_AT32AP_SMC_H */



From dwmw2 at infradead.org  Thu Sep 14 16:11:28 2006
From: dwmw2 at infradead.org (David Woodhouse)
Date: Thu, 14 Sep 2006 21:11:28 +0100
Subject: [-mm patch 3/4] AVR32 MTD: Mapping driver for the ATSTK1000 board
In-Reply-To: <20060914163259.068abe6d@cad-250-152.norway.atmel.com>
References: <20060914162926.6c117b36@cad-250-152.norway.atmel.com>
	<20060914163026.49766346@cad-250-152.norway.atmel.com>
	<20060914163121.241dec3e@cad-250-152.norway.atmel.com>
	<20060914163259.068abe6d@cad-250-152.norway.atmel.com>
Message-ID: <1158264688.4312.82.camel@pmac.infradead.org>

On Thu, 2006-09-14 at 16:32 +0200, Haavard Skinnemoen wrote:
> Add mapping driver for the AT49BV6416 NOR flash chip on the ATSTK1000
> development board. 

Hm, can't you set it up in advance and just register a platform_device
for physmap to drive?

-- 
dwmw2




From wangbj at lzu.edu.cn  Fri Sep  8 08:54:26 2006
From: wangbj at lzu.edu.cn (Wang, Baojun)
Date: Fri, 08 Sep 2006 20:54:26 +0800
Subject: mtd failed on ppc 440GR(yosemite) while CONFIG_YOSEMITE=y
Message-ID: <357780444.20354@eyou.net>

hi, 

I'm trying to enable mtd on the amcc 440GR yosemite evaluation board,
but failed. here is a section from the .config of linux-2.6.16 from eldk
provided kernel:

#
# Memory Technology Devices (MTD)
#
CONFIG_MTD=y
# CONFIG_MTD_DEBUG is not set
# CONFIG_MTD_CONCAT is not set
CONFIG_MTD_PARTITIONS=y
# CONFIG_MTD_REDBOOT_PARTS is not set
CONFIG_MTD_CMDLINE_PARTS=y

#
# User Modules And Translation Layers
#
CONFIG_MTD_CHAR=y
CONFIG_MTD_BLOCK=y
# CONFIG_FTL is not set
# CONFIG_NFTL is not set
# CONFIG_INFTL is not set
# CONFIG_RFD_FTL is not set

#
# RAM/ROM/Flash chip drivers
#
CONFIG_MTD_CFI=y
# CONFIG_MTD_JEDECPROBE is not set
CONFIG_MTD_GEN_PROBE=y
# CONFIG_MTD_CFI_ADV_OPTIONS is not set
CONFIG_MTD_MAP_BANK_WIDTH_1=y
CONFIG_MTD_MAP_BANK_WIDTH_2=y
CONFIG_MTD_MAP_BANK_WIDTH_4=y
# CONFIG_MTD_MAP_BANK_WIDTH_8 is not set
# CONFIG_MTD_MAP_BANK_WIDTH_16 is not set
# CONFIG_MTD_MAP_BANK_WIDTH_32 is not set
CONFIG_MTD_CFI_I1=y
CONFIG_MTD_CFI_I2=y
# CONFIG_MTD_CFI_I4 is not set
# CONFIG_MTD_CFI_I8 is not set
# CONFIG_MTD_CFI_INTELEXT is not set
CONFIG_MTD_CFI_AMDSTD=y
CONFIG_MTD_CFI_AMDSTD_RETRY=0
# CONFIG_MTD_CFI_STAA is not set
CONFIG_MTD_CFI_UTIL=y
# CONFIG_MTD_RAM is not set
# CONFIG_MTD_ROM is not set
# CONFIG_MTD_ABSENT is not set
# CONFIG_MTD_OBSOLETE_CHIPS is not set

#
# Mapping drivers for chip access
#
# CONFIG_MTD_COMPLEX_MAPPINGS is not set
# CONFIG_MTD_PHYSMAP is not set
CONFIG_MTD_YOSEMITE=y
# CONFIG_MTD_PLATRAM is not set

#
# Self-contained MTD device drivers
#
# CONFIG_MTD_PMC551 is not set
# CONFIG_MTD_DATAFLASH is not set
# CONFIG_MTD_M25P80 is not set
# CONFIG_MTD_SLRAM is not set
# CONFIG_MTD_PHRAM is not set
# CONFIG_MTD_MTDRAM is not set
# CONFIG_MTD_BLKMTD is not set
# CONFIG_MTD_BLOCK2MTD is not set

#
# Disk-On-Chip Device Drivers
#
# CONFIG_MTD_DOC2000 is not set
# CONFIG_MTD_DOC2001 is not set
# CONFIG_MTD_DOC2001PLUS is not set

#
# NAND Flash Device Drivers
#
# CONFIG_MTD_NAND is not set

#
# OneNAND Flash Device Drivers
#
# CONFIG_MTD_ONENAND is not set

it caused Data Machine Check, attachment mtd_error.txt is the log file.

config-2.6.16-5-eldk-ppc_440-yosemite is the related .config file for
linux-2.6.16 which cause data machine check(can't boot while detecting
flash)

config-2.6.16-4-eldk-ppc_440-yosemite is the .config file without
CONFIG_YOSEMITE, but with mtd physical map:

-# CONFIG_MTD_PHYSMAP is not set
-CONFIG_MTD_YOSEMITE=y
+CONFIG_MTD_PHYSMAP=y
+CONFIG_MTD_PHYSMAP_START=0xFE200000  /* reserved 2M for kernel */
+CONFIG_MTD_PHYSMAP_LEN=0x1D1FFFF

boot success, but it cause the system only have 1 partition of mtd, and
when doing a: 
# fdisk /dev/mtd0
would cause the shell block for ever(don't return to the shell prompt).

how could I enable mtd in (amcc) 440GR yosemite evaluation board? thanks
in advance!

I've tried this for days, and really get tired of that.

BTW: the kernel source is different from vanilla kernel, and it can be
found at: ftp://ftp.denx.de/pub/linux/linux-2.6.16.tar.bz2
and ELDK I use is 4.0(ppc_2006_01_11.iso, for target ppc_4xx)

regards!

-- 
Wang, Baojun                                     University of Lanzhou
Distributed & Embedded System Lab              http://dslab.lzu.edu.cn
School of Information Science and Engeneering        wangbj at lzu.edu.cn
Tianshui South Road 222. Lanzhou 730000                     .P.R.China
Tel:+86-931-8912025                                Fax:+86-931-8912022
-------------- next part --------------
configure linux-2.6.16 provided by eldk with MTD devices while MTD_YOSEMITE=y:

TFTP from server 192.168.1.179; our IP address is 192.168.1.24
Filename 'uImage-2.6.16-ppc_440-20060908-4'.
Load address: 0x400000
Loading: #################################################################
         #################################################################
         #################################################################
	 #################################################################
         #############################################################
done
Bytes transferred = 1631028 (18e334 hex)
=> bootm 0x400000
## Booting image at 00400000 ...
   Image Name:   Linux-2.6.16-eldk-ppc_440-yosemi
   Created:      2006-09-08   7:42:25 UTC
   Image Type:   PowerPC Linux Kernel Image (gzip compressed)
   Data Size:    1630964 Bytes =  1.6 MB
   Load Address: 00000000
   Entry Point:  00000000
   Verifying Checksum ... OK
   Uncompressing Kernel Image ... OK
Linux version 2.6.16-eldk-ppc_440-yosemite (distcc at ubuntu01) (gcc version 4.0.0 (DENX ELDK 4.0 4.0.0)) #14 PREEMPT Fri Sep 8 15:41:20 CST 2006
AMCC PowerPC 440EP Yosemite Platform
Built 1 zonelists
Kernel command line: root=/dev/nfs rw nfsroot=192.168.1.179:/opt/eldk/ppc_4xx ip=dhcp console=ttyS0,115200
PID hash table entries: 2048 (order: 11, 32768 bytes)
Console: colour dummy device 80x25
Dentry cache hash table entries: 65536 (order: 6, 262144 bytes)
Inode-cache hash table entries: 32768 (order: 5, 131072 bytes)
Memory: 255744k available (2596k kernel code, 1112k data, 144k init, 0k highmem)
Mount-cache hash table entries: 512
NET: Registered protocol family 16
PCI: Probing PCI hardware
TC classifier action (bugs to netdev at vger.kernel.org cc hadi at cyberus.ca)
Registering GDB sysrq handler
audit: initializing netlink socket (disabled)
audit(0.208:1): initialized
JFFS2 version 2.2. (NAND) (C) 2001-2003 Red Hat, Inc.
Initializing Cryptographic API
io scheduler noop registered (default)
Generic RTC Driver v1.07
Macintosh non-volatile memory driver v1.1
PowerPC Book-E Watchdog Timer Loaded
Serial: 8250/16550 driver $Revision: 1.2 $ 4 ports, IRQ sharing enabled
serial8250: ttyS0 at MMIO 0x0 (irq = 0) is a 16550A
serial8250: ttyS1 at MMIO 0x0 (irq = 1) is a 16550A
RAMDISK driver initialized: 16 RAM disks of 16384K size 1024 blocksize
loop: loaded (max 8 devices)
nbd: registered device at major 43
Intel(R) PRO/1000 Network Driver - version 6.3.9-k4
Copyright (c) 1999-2005 Intel Corporation.
PPC 4xx OCP EMAC driver, version 3.54
mal0: initialized, 4 TX channels, 2 RX channels
zmii0: bridge in RMII mode
eth0: emac0, MAC 00:10:ec:00:89:69
eth0: found Generic MII PHY (0x01)
eth1: emac1, MAC 00:10:ec:80:89:69
eth1: found Generic MII PHY (0x03)
Data machine check in kernel mode.
PLB0: BEAR=0x0000000000000000 ACR=  0x00000000 BESR= 0xfffffffe
POB0: BEAR=0xc27e3194ffbffffd BESR0=0x00000000 BESR1=0x00000000
OPB0: BEAR=0x0000000000000151 BSTAT=0x00000000

-------------- next part --------------
#
# Automatically generated make config: don't edit
# Linux kernel version: 2.6.16-eldk-ppc_440-yosemite
# Fri Sep  8 10:52:40 2006
#
CONFIG_MMU=y
CONFIG_GENERIC_HARDIRQS=y
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_PPC=y
CONFIG_PPC32=y
CONFIG_GENERIC_NVRAM=y
CONFIG_SCHED_NO_NO_OMIT_FRAME_POINTER=y
CONFIG_ARCH_MAY_HAVE_PC_FDC=y

#
# Code maturity level options
#
CONFIG_EXPERIMENTAL=y
CONFIG_BROKEN_ON_SMP=y
CONFIG_LOCK_KERNEL=y
CONFIG_INIT_ENV_ARG_LIMIT=32

#
# General setup
#
CONFIG_LOCALVERSION=""
# CONFIG_LOCALVERSION_AUTO is not set
CONFIG_SWAP=y
CONFIG_SYSVIPC=y
CONFIG_POSIX_MQUEUE=y
CONFIG_BSD_PROCESS_ACCT=y
CONFIG_BSD_PROCESS_ACCT_V3=y
CONFIG_SYSCTL=y
CONFIG_AUDIT=y
# CONFIG_AUDITSYSCALL is not set
# CONFIG_IKCONFIG is not set
CONFIG_INITRAMFS_SOURCE=""
CONFIG_CC_OPTIMIZE_FOR_SIZE=y
CONFIG_EMBEDDED=y
CONFIG_KALLSYMS=y
CONFIG_KALLSYMS_ALL=y
# CONFIG_KALLSYMS_EXTRA_PASS is not set
CONFIG_HOTPLUG=y
CONFIG_PRINTK=y
CONFIG_BUG=y
CONFIG_ELF_CORE=y
CONFIG_BASE_FULL=y
CONFIG_FUTEX=y
CONFIG_EPOLL=y
CONFIG_SHMEM=y
CONFIG_CC_ALIGN_FUNCTIONS=0
CONFIG_CC_ALIGN_LABELS=0
CONFIG_CC_ALIGN_LOOPS=0
CONFIG_CC_ALIGN_JUMPS=0
CONFIG_SLAB=y
# CONFIG_TINY_SHMEM is not set
CONFIG_BASE_SMALL=0
# CONFIG_SLOB is not set
CONFIG_OBSOLETE_INTERMODULE=y

#
# Loadable module support
#
CONFIG_MODULES=y
CONFIG_MODULE_UNLOAD=y
# CONFIG_MODULE_FORCE_UNLOAD is not set
CONFIG_OBSOLETE_MODPARM=y
CONFIG_MODVERSIONS=y
CONFIG_MODULE_SRCVERSION_ALL=y
CONFIG_KMOD=y

#
# Block layer
#
# CONFIG_LBD is not set

#
# IO Schedulers
#
CONFIG_IOSCHED_NOOP=y
# CONFIG_IOSCHED_AS is not set
# CONFIG_IOSCHED_DEADLINE is not set
# CONFIG_IOSCHED_CFQ is not set
# CONFIG_DEFAULT_AS is not set
# CONFIG_DEFAULT_DEADLINE is not set
# CONFIG_DEFAULT_CFQ is not set
CONFIG_DEFAULT_NOOP=y
CONFIG_DEFAULT_IOSCHED="noop"

#
# Processor
#
# CONFIG_6xx is not set
# CONFIG_40x is not set
CONFIG_44x=y
# CONFIG_POWER3 is not set
# CONFIG_8xx is not set
# CONFIG_E200 is not set
# CONFIG_E500 is not set
CONFIG_PPC_FPU=y
CONFIG_BOOKE=y
CONFIG_PTE_64BIT=y
CONFIG_PHYS_64BIT=y
CONFIG_MATH_EMULATION=y
# CONFIG_KEXEC is not set
# CONFIG_CPU_FREQ is not set
CONFIG_4xx=y
CONFIG_WANT_EARLY_SERIAL=y

#
# IBM 4xx options
#
# CONFIG_BAMBOO is not set
# CONFIG_EBONY is not set
# CONFIG_LUAN is not set
# CONFIG_YUCCA is not set
# CONFIG_OCOTEA is not set
# CONFIG_P3P440 is not set
# CONFIG_YELLOWSTONE is not set
CONFIG_YOSEMITE=y
CONFIG_440EP=y
CONFIG_440=y
CONFIG_IBM440EP_ERR42=y
CONFIG_IBM_OCP=y
CONFIG_PPC4xx_DMA=y
CONFIG_PPC4xx_EDMA=y
CONFIG_PPC_GEN550=y
CONFIG_NOT_COHERENT_CACHE=y

#
# Platform options
#
# CONFIG_PC_KEYBOARD is not set
# CONFIG_HIGHMEM is not set
# CONFIG_HZ_100 is not set
CONFIG_HZ_250=y
# CONFIG_HZ_1000 is not set
CONFIG_HZ=250
# CONFIG_PREEMPT_NONE is not set
# CONFIG_PREEMPT_VOLUNTARY is not set
CONFIG_PREEMPT=y
CONFIG_PREEMPT_BKL=y
CONFIG_SELECT_MEMORY_MODEL=y
CONFIG_FLATMEM_MANUAL=y
# CONFIG_DISCONTIGMEM_MANUAL is not set
# CONFIG_SPARSEMEM_MANUAL is not set
CONFIG_FLATMEM=y
CONFIG_FLAT_NODE_MEM_MAP=y
# CONFIG_SPARSEMEM_STATIC is not set
CONFIG_SPLIT_PTLOCK_CPUS=4
CONFIG_BINFMT_ELF=y
# CONFIG_BINFMT_MISC is not set
# CONFIG_CMDLINE_BOOL is not set
# CONFIG_SECCOMP is not set
CONFIG_ISA_DMA_API=y

#
# Bus options
#
# CONFIG_PPC_I8259 is not set
CONFIG_PPC_INDIRECT_PCI=y
CONFIG_PCI=y
CONFIG_PCI_DOMAINS=y
CONFIG_PCI_LEGACY_PROC=y
# CONFIG_PCI_DEBUG is not set

#
# PCCARD (PCMCIA/CardBus) support
#
# CONFIG_PCCARD is not set

#
# Advanced setup
#
# CONFIG_ADVANCED_OPTIONS is not set

#
# Default settings for advanced configuration options are used
#
CONFIG_HIGHMEM_START=0xfe000000
CONFIG_LOWMEM_SIZE=0x30000000
CONFIG_KERNEL_START=0xc0000000
CONFIG_TASK_SIZE=0x80000000
CONFIG_CONSISTENT_START=0xff100000
CONFIG_CONSISTENT_SIZE=0x00200000
CONFIG_BOOT_LOAD=0x01000000

#
# Networking
#
CONFIG_NET=y

#
# Networking options
#
# CONFIG_NETDEBUG is not set
CONFIG_PACKET=y
CONFIG_PACKET_MMAP=y
CONFIG_UNIX=y
CONFIG_XFRM=y
CONFIG_XFRM_USER=y
CONFIG_NET_KEY=y
CONFIG_INET=y
CONFIG_IP_MULTICAST=y
CONFIG_IP_ADVANCED_ROUTER=y
CONFIG_ASK_IP_FIB_HASH=y
# CONFIG_IP_FIB_TRIE is not set
CONFIG_IP_FIB_HASH=y
CONFIG_IP_MULTIPLE_TABLES=y
CONFIG_IP_ROUTE_FWMARK=y
CONFIG_IP_ROUTE_MULTIPATH=y
# CONFIG_IP_ROUTE_MULTIPATH_CACHED is not set
CONFIG_IP_ROUTE_VERBOSE=y
CONFIG_IP_PNP=y
CONFIG_IP_PNP_DHCP=y
CONFIG_IP_PNP_BOOTP=y
CONFIG_IP_PNP_RARP=y
CONFIG_NET_IPIP=y
CONFIG_NET_IPGRE=y
CONFIG_NET_IPGRE_BROADCAST=y
CONFIG_IP_MROUTE=y
CONFIG_IP_PIMSM_V1=y
CONFIG_IP_PIMSM_V2=y
# CONFIG_ARPD is not set
CONFIG_SYN_COOKIES=y
CONFIG_INET_AH=y
CONFIG_INET_ESP=y
CONFIG_INET_IPCOMP=y
CONFIG_INET_TUNNEL=y
# CONFIG_INET_DIAG is not set
# CONFIG_TCP_CONG_ADVANCED is not set
CONFIG_TCP_CONG_BIC=y

#
# IP: Virtual Server Configuration
#
# CONFIG_IP_VS is not set
CONFIG_IPV6=y
CONFIG_IPV6_PRIVACY=y
CONFIG_INET6_AH=y
CONFIG_INET6_ESP=y
CONFIG_INET6_IPCOMP=y
CONFIG_INET6_TUNNEL=y
# CONFIG_IPV6_TUNNEL is not set
CONFIG_NETFILTER=y
# CONFIG_NETFILTER_DEBUG is not set

#
# Core Netfilter Configuration
#
CONFIG_NETFILTER_NETLINK=y
CONFIG_NETFILTER_NETLINK_QUEUE=y
CONFIG_NETFILTER_NETLINK_LOG=y
CONFIG_NETFILTER_XTABLES=y
CONFIG_NETFILTER_XT_TARGET_CLASSIFY=y
CONFIG_NETFILTER_XT_TARGET_CONNMARK=y
CONFIG_NETFILTER_XT_TARGET_MARK=y
CONFIG_NETFILTER_XT_TARGET_NFQUEUE=y
CONFIG_NETFILTER_XT_TARGET_NOTRACK=y
CONFIG_NETFILTER_XT_MATCH_COMMENT=y
CONFIG_NETFILTER_XT_MATCH_CONNBYTES=y
CONFIG_NETFILTER_XT_MATCH_CONNMARK=y
CONFIG_NETFILTER_XT_MATCH_CONNTRACK=y
# CONFIG_NETFILTER_XT_MATCH_DCCP is not set
CONFIG_NETFILTER_XT_MATCH_HELPER=y
CONFIG_NETFILTER_XT_MATCH_LENGTH=y
CONFIG_NETFILTER_XT_MATCH_LIMIT=y
CONFIG_NETFILTER_XT_MATCH_MAC=y
CONFIG_NETFILTER_XT_MATCH_MARK=y
CONFIG_NETFILTER_XT_MATCH_PKTTYPE=y
CONFIG_NETFILTER_XT_MATCH_REALM=y
# CONFIG_NETFILTER_XT_MATCH_SCTP is not set
CONFIG_NETFILTER_XT_MATCH_STATE=y
CONFIG_NETFILTER_XT_MATCH_STRING=y
CONFIG_NETFILTER_XT_MATCH_TCPMSS=y

#
# IP: Netfilter Configuration
#
CONFIG_IP_NF_CONNTRACK=y
CONFIG_IP_NF_CT_ACCT=y
CONFIG_IP_NF_CONNTRACK_MARK=y
# CONFIG_IP_NF_CONNTRACK_EVENTS is not set
# CONFIG_IP_NF_CONNTRACK_NETLINK is not set
# CONFIG_IP_NF_CT_PROTO_SCTP is not set
CONFIG_IP_NF_FTP=y
CONFIG_IP_NF_IRC=y
# CONFIG_IP_NF_NETBIOS_NS is not set
CONFIG_IP_NF_TFTP=y
CONFIG_IP_NF_AMANDA=y
CONFIG_IP_NF_PPTP=y
# CONFIG_IP_NF_QUEUE is not set
CONFIG_IP_NF_IPTABLES=y
CONFIG_IP_NF_MATCH_IPRANGE=y
CONFIG_IP_NF_MATCH_MULTIPORT=y
CONFIG_IP_NF_MATCH_TOS=y
CONFIG_IP_NF_MATCH_RECENT=y
CONFIG_IP_NF_MATCH_ECN=y
# CONFIG_IP_NF_MATCH_DSCP is not set
CONFIG_IP_NF_MATCH_AH_ESP=y
CONFIG_IP_NF_MATCH_TTL=y
CONFIG_IP_NF_MATCH_OWNER=y
CONFIG_IP_NF_MATCH_ADDRTYPE=y
CONFIG_IP_NF_MATCH_HASHLIMIT=y
CONFIG_IP_NF_MATCH_POLICY=y
CONFIG_IP_NF_FILTER=y
CONFIG_IP_NF_TARGET_REJECT=y
CONFIG_IP_NF_TARGET_LOG=y
# CONFIG_IP_NF_TARGET_ULOG is not set
CONFIG_IP_NF_TARGET_TCPMSS=y
CONFIG_IP_NF_NAT=y
CONFIG_IP_NF_NAT_NEEDED=y
CONFIG_IP_NF_TARGET_MASQUERADE=y
CONFIG_IP_NF_TARGET_REDIRECT=y
CONFIG_IP_NF_TARGET_NETMAP=y
CONFIG_IP_NF_TARGET_SAME=y
CONFIG_IP_NF_NAT_SNMP_BASIC=y
CONFIG_IP_NF_NAT_IRC=y
CONFIG_IP_NF_NAT_FTP=y
CONFIG_IP_NF_NAT_TFTP=y
CONFIG_IP_NF_NAT_AMANDA=y
CONFIG_IP_NF_NAT_PPTP=y
CONFIG_IP_NF_MANGLE=y
CONFIG_IP_NF_TARGET_TOS=y
CONFIG_IP_NF_TARGET_ECN=y
# CONFIG_IP_NF_TARGET_DSCP is not set
CONFIG_IP_NF_TARGET_TTL=y
# CONFIG_IP_NF_TARGET_CLUSTERIP is not set
CONFIG_IP_NF_RAW=y
CONFIG_IP_NF_ARPTABLES=y
CONFIG_IP_NF_ARPFILTER=y
CONFIG_IP_NF_ARP_MANGLE=y

#
# IPv6: Netfilter Configuration (EXPERIMENTAL)
#
# CONFIG_IP6_NF_QUEUE is not set
CONFIG_IP6_NF_IPTABLES=y
CONFIG_IP6_NF_MATCH_RT=y
CONFIG_IP6_NF_MATCH_OPTS=y
CONFIG_IP6_NF_MATCH_FRAG=y
CONFIG_IP6_NF_MATCH_HL=y
CONFIG_IP6_NF_MATCH_MULTIPORT=y
CONFIG_IP6_NF_MATCH_OWNER=y
CONFIG_IP6_NF_MATCH_IPV6HEADER=y
CONFIG_IP6_NF_MATCH_AHESP=y
CONFIG_IP6_NF_MATCH_EUI64=y
CONFIG_IP6_NF_MATCH_POLICY=y
CONFIG_IP6_NF_FILTER=y
CONFIG_IP6_NF_TARGET_LOG=y
CONFIG_IP6_NF_TARGET_REJECT=y
CONFIG_IP6_NF_MANGLE=y
CONFIG_IP6_NF_TARGET_HL=y
CONFIG_IP6_NF_RAW=y

#
# DCCP Configuration (EXPERIMENTAL)
#
# CONFIG_IP_DCCP is not set

#
# SCTP Configuration (EXPERIMENTAL)
#
# CONFIG_IP_SCTP is not set

#
# TIPC Configuration (EXPERIMENTAL)
#
# CONFIG_TIPC is not set
# CONFIG_ATM is not set
# CONFIG_BRIDGE is not set
# CONFIG_VLAN_8021Q is not set
# CONFIG_DECNET is not set
# CONFIG_LLC2 is not set
# CONFIG_IPX is not set
# CONFIG_ATALK is not set
# CONFIG_X25 is not set
# CONFIG_LAPB is not set
# CONFIG_NET_DIVERT is not set
# CONFIG_ECONET is not set
# CONFIG_WAN_ROUTER is not set

#
# QoS and/or fair queueing
#
CONFIG_NET_SCHED=y
# CONFIG_NET_SCH_CLK_JIFFIES is not set
CONFIG_NET_SCH_CLK_GETTIMEOFDAY=y
# CONFIG_NET_SCH_CLK_CPU is not set

#
# Queueing/Scheduling
#
CONFIG_NET_SCH_CBQ=y
CONFIG_NET_SCH_HTB=y
CONFIG_NET_SCH_HFSC=y
CONFIG_NET_SCH_PRIO=y
CONFIG_NET_SCH_RED=y
CONFIG_NET_SCH_SFQ=y
CONFIG_NET_SCH_TEQL=y
CONFIG_NET_SCH_TBF=y
CONFIG_NET_SCH_GRED=y
CONFIG_NET_SCH_DSMARK=y
CONFIG_NET_SCH_NETEM=y
CONFIG_NET_SCH_INGRESS=y

#
# Classification
#
CONFIG_NET_CLS=y
CONFIG_NET_CLS_BASIC=y
CONFIG_NET_CLS_TCINDEX=y
CONFIG_NET_CLS_ROUTE4=y
CONFIG_NET_CLS_ROUTE=y
CONFIG_NET_CLS_FW=y
CONFIG_NET_CLS_U32=y
CONFIG_CLS_U32_PERF=y
CONFIG_CLS_U32_MARK=y
CONFIG_NET_CLS_RSVP=y
CONFIG_NET_CLS_RSVP6=y
CONFIG_NET_EMATCH=y
CONFIG_NET_EMATCH_STACK=32
CONFIG_NET_EMATCH_CMP=y
CONFIG_NET_EMATCH_NBYTE=y
CONFIG_NET_EMATCH_U32=y
CONFIG_NET_EMATCH_META=y
CONFIG_NET_EMATCH_TEXT=y
CONFIG_NET_CLS_ACT=y
CONFIG_NET_ACT_POLICE=y
CONFIG_NET_ACT_GACT=y
CONFIG_GACT_PROB=y
CONFIG_NET_ACT_MIRRED=y
CONFIG_NET_ACT_IPT=y
CONFIG_NET_ACT_PEDIT=y
# CONFIG_NET_ACT_SIMP is not set
CONFIG_NET_CLS_IND=y
CONFIG_NET_ESTIMATOR=y

#
# Network testing
#
CONFIG_NET_PKTGEN=y
# CONFIG_HAMRADIO is not set
# CONFIG_IRDA is not set
# CONFIG_BT is not set
# CONFIG_IEEE80211 is not set

#
# Device Drivers
#

#
# Generic Driver Options
#
CONFIG_STANDALONE=y
CONFIG_PREVENT_FIRMWARE_BUILD=y
# CONFIG_FW_LOADER is not set
# CONFIG_DEBUG_DRIVER is not set

#
# Connector - unified userspace <-> kernelspace linker
#
CONFIG_CONNECTOR=y
CONFIG_PROC_EVENTS=y

#
# Memory Technology Devices (MTD)
#
CONFIG_MTD=y
CONFIG_MTD_DEBUG=y
CONFIG_MTD_DEBUG_VERBOSE=3
# CONFIG_MTD_CONCAT is not set
CONFIG_MTD_PARTITIONS=y
# CONFIG_MTD_REDBOOT_PARTS is not set
# CONFIG_MTD_CMDLINE_PARTS is not set

#
# User Modules And Translation Layers
#
CONFIG_MTD_CHAR=y
CONFIG_MTD_BLOCK=y
# CONFIG_FTL is not set
# CONFIG_NFTL is not set
# CONFIG_INFTL is not set
# CONFIG_RFD_FTL is not set

#
# RAM/ROM/Flash chip drivers
#
CONFIG_MTD_CFI=y
CONFIG_MTD_JEDECPROBE=y
CONFIG_MTD_GEN_PROBE=y
# CONFIG_MTD_CFI_ADV_OPTIONS is not set
CONFIG_MTD_MAP_BANK_WIDTH_1=y
CONFIG_MTD_MAP_BANK_WIDTH_2=y
CONFIG_MTD_MAP_BANK_WIDTH_4=y
# CONFIG_MTD_MAP_BANK_WIDTH_8 is not set
# CONFIG_MTD_MAP_BANK_WIDTH_16 is not set
# CONFIG_MTD_MAP_BANK_WIDTH_32 is not set
CONFIG_MTD_CFI_I1=y
CONFIG_MTD_CFI_I2=y
# CONFIG_MTD_CFI_I4 is not set
# CONFIG_MTD_CFI_I8 is not set
# CONFIG_MTD_CFI_INTELEXT is not set
CONFIG_MTD_CFI_AMDSTD=y
CONFIG_MTD_CFI_AMDSTD_RETRY=0
# CONFIG_MTD_CFI_STAA is not set
CONFIG_MTD_CFI_UTIL=y
# CONFIG_MTD_RAM is not set
# CONFIG_MTD_ROM is not set
# CONFIG_MTD_ABSENT is not set
# CONFIG_MTD_OBSOLETE_CHIPS is not set

#
# Mapping drivers for chip access
#
# CONFIG_MTD_COMPLEX_MAPPINGS is not set
CONFIG_MTD_PHYSMAP=y
CONFIG_MTD_PHYSMAP_START=0xFE200000
CONFIG_MTD_PHYSMAP_LEN=0x1D1FFFF
CONFIG_MTD_PHYSMAP_BANKWIDTH=2
# CONFIG_MTD_YOSEMITE is not set
# CONFIG_MTD_PLATRAM is not set

#
# Self-contained MTD device drivers
#
# CONFIG_MTD_PMC551 is not set
# CONFIG_MTD_DATAFLASH is not set
# CONFIG_MTD_M25P80 is not set
# CONFIG_MTD_SLRAM is not set
# CONFIG_MTD_PHRAM is not set
# CONFIG_MTD_MTDRAM is not set
# CONFIG_MTD_BLKMTD is not set
# CONFIG_MTD_BLOCK2MTD is not set

#
# Disk-On-Chip Device Drivers
#
# CONFIG_MTD_DOC2000 is not set
# CONFIG_MTD_DOC2001 is not set
# CONFIG_MTD_DOC2001PLUS is not set

#
# NAND Flash Device Drivers
#
# CONFIG_MTD_NAND is not set

#
# OneNAND Flash Device Drivers
#
# CONFIG_MTD_ONENAND is not set

#
# Parallel port support
#
CONFIG_PARPORT=y
# CONFIG_PARPORT_PC is not set
# CONFIG_PARPORT_GSC is not set
# CONFIG_PARPORT_1284 is not set

#
# Plug and Play support
#

#
# Block devices
#
# CONFIG_BLK_DEV_FD is not set
# CONFIG_BLK_CPQ_DA is not set
# CONFIG_BLK_CPQ_CISS_DA is not set
# CONFIG_BLK_DEV_DAC960 is not set
# CONFIG_BLK_DEV_UMEM is not set
# CONFIG_BLK_DEV_COW_COMMON is not set
CONFIG_BLK_DEV_LOOP=y
CONFIG_BLK_DEV_CRYPTOLOOP=y
CONFIG_BLK_DEV_NBD=y
# CONFIG_BLK_DEV_SX8 is not set
CONFIG_BLK_DEV_RAM=y
CONFIG_BLK_DEV_RAM_COUNT=16
CONFIG_BLK_DEV_RAM_SIZE=16384
CONFIG_BLK_DEV_INITRD=y
# CONFIG_CDROM_PKTCDVD is not set
# CONFIG_ATA_OVER_ETH is not set

#
# ATA/ATAPI/MFM/RLL support
#
# CONFIG_IDE is not set

#
# SCSI device support
#
# CONFIG_RAID_ATTRS is not set
# CONFIG_SCSI is not set

#
# Multi-device support (RAID and LVM)
#
# CONFIG_MD is not set

#
# Fusion MPT device support
#
# CONFIG_FUSION is not set

#
# IEEE 1394 (FireWire) support
#
# CONFIG_IEEE1394 is not set

#
# I2O device support
#
# CONFIG_I2O is not set

#
# Macintosh device drivers
#
# CONFIG_WINDFARM is not set

#
# Network device support
#
CONFIG_NETDEVICES=y
# CONFIG_IFB is not set
CONFIG_DUMMY=y
# CONFIG_BONDING is not set
# CONFIG_EQUALIZER is not set
# CONFIG_TUN is not set

#
# ARCnet devices
#
# CONFIG_ARCNET is not set

#
# PHY device support
#
# CONFIG_PHYLIB is not set

#
# Ethernet (10 or 100Mbit)
#
CONFIG_NET_ETHERNET=y
CONFIG_MII=y
# CONFIG_HAPPYMEAL is not set
# CONFIG_SUNGEM is not set
# CONFIG_CASSINI is not set
# CONFIG_NET_VENDOR_3COM is not set

#
# Tulip family network device support
#
# CONFIG_NET_TULIP is not set
# CONFIG_HP100 is not set
CONFIG_IBM_EMAC=y
CONFIG_IBM_EMAC_RXB=128
CONFIG_IBM_EMAC_TXB=64
CONFIG_IBM_EMAC_POLL_WEIGHT=32
CONFIG_IBM_EMAC_RX_COPY_THRESHOLD=256
CONFIG_IBM_EMAC_RX_SKB_HEADROOM=0
# CONFIG_IBM_EMAC_PHY_RX_CLK_FIX is not set
# CONFIG_IBM_EMAC_DEBUG is not set
CONFIG_IBM_EMAC_ZMII=y
CONFIG_NET_PCI=y
# CONFIG_PCNET32 is not set
# CONFIG_AMD8111_ETH is not set
# CONFIG_ADAPTEC_STARFIRE is not set
# CONFIG_B44 is not set
# CONFIG_FORCEDETH is not set
# CONFIG_DGRS is not set
# CONFIG_EEPRO100 is not set
# CONFIG_E100 is not set
# CONFIG_FEALNX is not set
# CONFIG_NATSEMI is not set
# CONFIG_NE2K_PCI is not set
# CONFIG_8139CP is not set
# CONFIG_8139TOO is not set
# CONFIG_SIS900 is not set
# CONFIG_EPIC100 is not set
# CONFIG_SUNDANCE is not set
# CONFIG_TLAN is not set
# CONFIG_VIA_RHINE is not set
# CONFIG_NET_POCKET is not set

#
# Ethernet (1000 Mbit)
#
# CONFIG_ACENIC is not set
# CONFIG_DL2K is not set
CONFIG_E1000=y
# CONFIG_E1000_NAPI is not set
# CONFIG_E1000_DISABLE_PACKET_SPLIT is not set
# CONFIG_NS83820 is not set
# CONFIG_HAMACHI is not set
# CONFIG_YELLOWFIN is not set
# CONFIG_R8169 is not set
# CONFIG_SIS190 is not set
# CONFIG_SKGE is not set
# CONFIG_SKY2 is not set
# CONFIG_SK98LIN is not set
# CONFIG_VIA_VELOCITY is not set
# CONFIG_TIGON3 is not set
# CONFIG_BNX2 is not set

#
# Ethernet (10000 Mbit)
#
# CONFIG_CHELSIO_T1 is not set
# CONFIG_IXGB is not set
# CONFIG_S2IO is not set

#
# Token Ring devices
#
# CONFIG_TR is not set

#
# Wireless LAN (non-hamradio)
#
# CONFIG_NET_RADIO is not set

#
# Wan interfaces
#
# CONFIG_WAN is not set
# CONFIG_FDDI is not set
# CONFIG_HIPPI is not set
# CONFIG_PLIP is not set
# CONFIG_PPP is not set
# CONFIG_SLIP is not set
# CONFIG_SHAPER is not set
# CONFIG_NETCONSOLE is not set
# CONFIG_NETPOLL is not set
# CONFIG_NET_POLL_CONTROLLER is not set

#
# ISDN subsystem
#
# CONFIG_ISDN is not set

#
# Telephony Support
#
# CONFIG_PHONE is not set

#
# Input device support
#
CONFIG_INPUT=y

#
# Userland interfaces
#
# CONFIG_INPUT_MOUSEDEV is not set
# CONFIG_INPUT_JOYDEV is not set
# CONFIG_INPUT_TSDEV is not set
# CONFIG_INPUT_EVDEV is not set
# CONFIG_INPUT_EVBUG is not set

#
# Input Device Drivers
#
# CONFIG_INPUT_KEYBOARD is not set
# CONFIG_INPUT_MOUSE is not set
# CONFIG_INPUT_JOYSTICK is not set
# CONFIG_INPUT_TOUCHSCREEN is not set
# CONFIG_INPUT_MISC is not set

#
# Hardware I/O ports
#
# CONFIG_SERIO is not set
# CONFIG_GAMEPORT is not set

#
# Character devices
#
CONFIG_VT=y
CONFIG_VT_CONSOLE=y
CONFIG_HW_CONSOLE=y
# CONFIG_SERIAL_NONSTANDARD is not set

#
# Serial drivers
#
CONFIG_SERIAL_8250=y
CONFIG_SERIAL_8250_CONSOLE=y
CONFIG_SERIAL_8250_NR_UARTS=48
CONFIG_SERIAL_8250_RUNTIME_UARTS=4
CONFIG_SERIAL_8250_EXTENDED=y
CONFIG_SERIAL_8250_MANY_PORTS=y
CONFIG_SERIAL_8250_SHARE_IRQ=y
# CONFIG_SERIAL_8250_DETECT_IRQ is not set
CONFIG_SERIAL_8250_RSA=y

#
# Non-8250 serial port support
#
CONFIG_SERIAL_CORE=y
CONFIG_SERIAL_CORE_CONSOLE=y
# CONFIG_SERIAL_JSM is not set
CONFIG_UNIX98_PTYS=y
CONFIG_LEGACY_PTYS=y
CONFIG_LEGACY_PTY_COUNT=256
# CONFIG_PRINTER is not set
# CONFIG_PPDEV is not set
# CONFIG_TIPAR is not set

#
# IPMI
#
# CONFIG_IPMI_HANDLER is not set

#
# Watchdog Cards
#
CONFIG_WATCHDOG=y
# CONFIG_WATCHDOG_NOWAYOUT is not set

#
# Watchdog Device Drivers
#
# CONFIG_SOFT_WATCHDOG is not set
CONFIG_BOOKE_WDT=y

#
# PCI-based Watchdog Cards
#
# CONFIG_PCIPCWATCHDOG is not set
# CONFIG_WDTPCI is not set
CONFIG_NVRAM=y
CONFIG_GEN_RTC=y
CONFIG_GEN_RTC_X=y
# CONFIG_DTLK is not set
# CONFIG_R3964 is not set
# CONFIG_APPLICOM is not set

#
# Ftape, the floppy tape device driver
#
# CONFIG_AGP is not set
# CONFIG_DRM is not set
# CONFIG_RAW_DRIVER is not set

#
# TPM devices
#
# CONFIG_TCG_TPM is not set
# CONFIG_TELCLOCK is not set

#
# I2C support
#
CONFIG_I2C=y
CONFIG_I2C_CHARDEV=y

#
# I2C Algorithms
#
CONFIG_I2C_ALGOBIT=y
CONFIG_I2C_ALGOPCF=y
CONFIG_I2C_ALGOPCA=y

#
# I2C Hardware Bus support
#
# CONFIG_I2C_ALI1535 is not set
# CONFIG_I2C_ALI1563 is not set
# CONFIG_I2C_ALI15X3 is not set
# CONFIG_I2C_AMD756 is not set
# CONFIG_I2C_AMD8111 is not set
# CONFIG_I2C_I801 is not set
# CONFIG_I2C_I810 is not set
# CONFIG_I2C_PIIX4 is not set
CONFIG_I2C_IBM_IIC=y
# CONFIG_I2C_MPC is not set
# CONFIG_I2C_MPC8260 is not set
# CONFIG_I2C_NFORCE2 is not set
# CONFIG_I2C_PARPORT is not set
# CONFIG_I2C_PARPORT_LIGHT is not set
# CONFIG_I2C_PROSAVAGE is not set
# CONFIG_I2C_SAVAGE4 is not set
# CONFIG_SCx200_ACB is not set
# CONFIG_I2C_SIS5595 is not set
# CONFIG_I2C_SIS630 is not set
# CONFIG_I2C_SIS96X is not set
# CONFIG_I2C_STUB is not set
# CONFIG_I2C_VIA is not set
# CONFIG_I2C_VIAPRO is not set
# CONFIG_I2C_VOODOO3 is not set
# CONFIG_I2C_PCA_ISA is not set

#
# Miscellaneous I2C Chip support
#
# CONFIG_SENSORS_DS1337 is not set
# CONFIG_SENSORS_DS1374 is not set
# CONFIG_SENSORS_EEPROM is not set
# CONFIG_SENSORS_MAX6900 is not set
# CONFIG_SENSORS_PCF8574 is not set
# CONFIG_SENSORS_PCF8563 is not set
# CONFIG_SENSORS_PCA9539 is not set
# CONFIG_SENSORS_PCF8591 is not set
# CONFIG_SENSORS_RTC8564 is not set
# CONFIG_SENSORS_M41T00 is not set
# CONFIG_SENSORS_MAX6875 is not set
# CONFIG_RTC_X1205_I2C is not set
# CONFIG_I2C_DEBUG_CORE is not set
# CONFIG_I2C_DEBUG_ALGO is not set
# CONFIG_I2C_DEBUG_BUS is not set
# CONFIG_I2C_DEBUG_CHIP is not set

#
# SPI support
#
CONFIG_SPI=y
# CONFIG_SPI_DEBUG is not set
CONFIG_SPI_MASTER=y

#
# SPI Master Controller Drivers
#
# CONFIG_SPI_BITBANG is not set
# CONFIG_SPI_BUTTERFLY is not set

#
# SPI Protocol Masters
#

#
# Dallas's 1-wire bus
#
# CONFIG_W1 is not set

#
# Hardware Monitoring support
#
# CONFIG_HWMON is not set
# CONFIG_HWMON_VID is not set

#
# Misc devices
#

#
# Multimedia Capabilities Port drivers
#

#
# Multimedia devices
#
# CONFIG_VIDEO_DEV is not set

#
# Digital Video Broadcasting Devices
#
# CONFIG_DVB is not set

#
# Graphics support
#
# CONFIG_FB is not set

#
# Console display driver support
#
CONFIG_DUMMY_CONSOLE=y

#
# Sound
#
# CONFIG_SOUND is not set

#
# USB support
#
CONFIG_USB_ARCH_HAS_HCD=y
CONFIG_USB_ARCH_HAS_OHCI=y
# CONFIG_USB is not set

#
# NOTE: USB_STORAGE enables SCSI, and 'SCSI disk support'
#

#
# USB Gadget Support
#
# CONFIG_USB_GADGET is not set

#
# MMC/SD Card support
#
# CONFIG_MMC is not set

#
# InfiniBand support
#
# CONFIG_INFINIBAND is not set

#
# EDAC - error detection and reporting (RAS) (EXPERIMENTAL)
#

#
# File systems
#
CONFIG_EXT2_FS=y
CONFIG_EXT2_FS_XATTR=y
CONFIG_EXT2_FS_POSIX_ACL=y
CONFIG_EXT2_FS_SECURITY=y
# CONFIG_EXT2_FS_XIP is not set
# CONFIG_EXT3_FS is not set
CONFIG_FS_MBCACHE=y
# CONFIG_REISERFS_FS is not set
# CONFIG_JFS_FS is not set
CONFIG_FS_POSIX_ACL=y
# CONFIG_XFS_FS is not set
# CONFIG_OCFS2_FS is not set
# CONFIG_MINIX_FS is not set
# CONFIG_ROMFS_FS is not set
CONFIG_INOTIFY=y
# CONFIG_QUOTA is not set
CONFIG_DNOTIFY=y
CONFIG_AUTOFS_FS=y
CONFIG_AUTOFS4_FS=y
# CONFIG_FUSE_FS is not set

#
# CD-ROM/DVD Filesystems
#
# CONFIG_ISO9660_FS is not set
# CONFIG_UDF_FS is not set

#
# DOS/FAT/NT Filesystems
#
# CONFIG_MSDOS_FS is not set
# CONFIG_VFAT_FS is not set
# CONFIG_NTFS_FS is not set

#
# Pseudo filesystems
#
CONFIG_PROC_FS=y
CONFIG_PROC_KCORE=y
CONFIG_SYSFS=y
CONFIG_TMPFS=y
# CONFIG_HUGETLB_PAGE is not set
CONFIG_RAMFS=y
CONFIG_RELAYFS_FS=y
# CONFIG_CONFIGFS_FS is not set

#
# Miscellaneous filesystems
#
# CONFIG_ADFS_FS is not set
# CONFIG_AFFS_FS is not set
# CONFIG_HFS_FS is not set
# CONFIG_HFSPLUS_FS is not set
# CONFIG_BEFS_FS is not set
# CONFIG_BFS_FS is not set
# CONFIG_EFS_FS is not set
# CONFIG_JFFS_FS is not set
CONFIG_JFFS2_FS=y
CONFIG_JFFS2_FS_DEBUG=0
CONFIG_JFFS2_FS_WRITEBUFFER=y
# CONFIG_JFFS2_SUMMARY is not set
# CONFIG_JFFS2_COMPRESSION_OPTIONS is not set
CONFIG_JFFS2_ZLIB=y
CONFIG_JFFS2_RTIME=y
# CONFIG_JFFS2_RUBIN is not set
CONFIG_CRAMFS=y
# CONFIG_VXFS_FS is not set
# CONFIG_HPFS_FS is not set
# CONFIG_QNX4FS_FS is not set
# CONFIG_SYSV_FS is not set
# CONFIG_UFS_FS is not set

#
# Network File Systems
#
CONFIG_NFS_FS=y
CONFIG_NFS_V3=y
CONFIG_NFS_V3_ACL=y
CONFIG_NFS_V4=y
CONFIG_NFS_DIRECTIO=y
# CONFIG_NFSD is not set
CONFIG_ROOT_NFS=y
CONFIG_LOCKD=y
CONFIG_LOCKD_V4=y
CONFIG_NFS_ACL_SUPPORT=y
CONFIG_NFS_COMMON=y
CONFIG_SUNRPC=y
CONFIG_SUNRPC_GSS=y
CONFIG_RPCSEC_GSS_KRB5=y
# CONFIG_RPCSEC_GSS_SPKM3 is not set
# CONFIG_SMB_FS is not set
# CONFIG_CIFS is not set
# CONFIG_NCP_FS is not set
# CONFIG_CODA_FS is not set
# CONFIG_AFS_FS is not set
# CONFIG_9P_FS is not set

#
# Partition Types
#
# CONFIG_PARTITION_ADVANCED is not set
CONFIG_MSDOS_PARTITION=y

#
# Native Language Support
#
CONFIG_NLS=y
CONFIG_NLS_DEFAULT="cp437"
# CONFIG_NLS_CODEPAGE_437 is not set
# CONFIG_NLS_CODEPAGE_737 is not set
# CONFIG_NLS_CODEPAGE_775 is not set
# CONFIG_NLS_CODEPAGE_850 is not set
# CONFIG_NLS_CODEPAGE_852 is not set
# CONFIG_NLS_CODEPAGE_855 is not set
# CONFIG_NLS_CODEPAGE_857 is not set
# CONFIG_NLS_CODEPAGE_860 is not set
# CONFIG_NLS_CODEPAGE_861 is not set
# CONFIG_NLS_CODEPAGE_862 is not set
# CONFIG_NLS_CODEPAGE_863 is not set
# CONFIG_NLS_CODEPAGE_864 is not set
# CONFIG_NLS_CODEPAGE_865 is not set
# CONFIG_NLS_CODEPAGE_866 is not set
# CONFIG_NLS_CODEPAGE_869 is not set
# CONFIG_NLS_CODEPAGE_936 is not set
# CONFIG_NLS_CODEPAGE_950 is not set
# CONFIG_NLS_CODEPAGE_932 is not set
# CONFIG_NLS_CODEPAGE_949 is not set
# CONFIG_NLS_CODEPAGE_874 is not set
# CONFIG_NLS_ISO8859_8 is not set
# CONFIG_NLS_CODEPAGE_1250 is not set
# CONFIG_NLS_CODEPAGE_1251 is not set
# CONFIG_NLS_ASCII is not set
# CONFIG_NLS_ISO8859_1 is not set
# CONFIG_NLS_ISO8859_2 is not set
# CONFIG_NLS_ISO8859_3 is not set
# CONFIG_NLS_ISO8859_4 is not set
# CONFIG_NLS_ISO8859_5 is not set
# CONFIG_NLS_ISO8859_6 is not set
# CONFIG_NLS_ISO8859_7 is not set
# CONFIG_NLS_ISO8859_9 is not set
# CONFIG_NLS_ISO8859_13 is not set
# CONFIG_NLS_ISO8859_14 is not set
# CONFIG_NLS_ISO8859_15 is not set
# CONFIG_NLS_KOI8_R is not set
# CONFIG_NLS_KOI8_U is not set
CONFIG_NLS_UTF8=y

#
# Library routines
#
# CONFIG_CRC_CCITT is not set
# CONFIG_CRC16 is not set
CONFIG_CRC32=y
# CONFIG_LIBCRC32C is not set
CONFIG_ZLIB_INFLATE=y
CONFIG_ZLIB_DEFLATE=y
CONFIG_TEXTSEARCH=y
CONFIG_TEXTSEARCH_KMP=y
CONFIG_TEXTSEARCH_BM=y
CONFIG_TEXTSEARCH_FSM=y
# CONFIG_PROFILING is not set

#
# Kernel hacking
#
# CONFIG_PRINTK_TIME is not set
CONFIG_MAGIC_SYSRQ=y
CONFIG_DEBUG_KERNEL=y
CONFIG_LOG_BUF_SHIFT=17
CONFIG_DETECT_SOFTLOCKUP=y
# CONFIG_SCHEDSTATS is not set
# CONFIG_DEBUG_SLAB is not set
# CONFIG_DEBUG_PREEMPT is not set
# CONFIG_DEBUG_MUTEXES is not set
# CONFIG_DEBUG_SPINLOCK is not set
# CONFIG_DEBUG_SPINLOCK_SLEEP is not set
# CONFIG_DEBUG_KOBJECT is not set
CONFIG_DEBUG_INFO=y
# CONFIG_DEBUG_FS is not set
# CONFIG_DEBUG_VM is not set
# CONFIG_FORCED_INLINING is not set
# CONFIG_RCU_TORTURE_TEST is not set
CONFIG_KGDB=y
# CONFIG_KGDB_TTYS0 is not set
CONFIG_KGDB_TTYS1=y
# CONFIG_KGDB_TTYS2 is not set
# CONFIG_KGDB_TTYS3 is not set
# CONFIG_XMON is not set
# CONFIG_BDI_SWITCH is not set
# CONFIG_SERIAL_TEXT_DEBUG is not set
CONFIG_PPC_OCP=y

#
# Security options
#
# CONFIG_KEYS is not set
# CONFIG_SECURITY is not set

#
# Cryptographic options
#
CONFIG_CRYPTO=y
CONFIG_CRYPTO_HMAC=y
# CONFIG_CRYPTO_NULL is not set
# CONFIG_CRYPTO_MD4 is not set
CONFIG_CRYPTO_MD5=y
CONFIG_CRYPTO_SHA1=y
# CONFIG_CRYPTO_SHA256 is not set
# CONFIG_CRYPTO_SHA512 is not set
# CONFIG_CRYPTO_WP512 is not set
# CONFIG_CRYPTO_TGR192 is not set
CONFIG_CRYPTO_DES=y
# CONFIG_CRYPTO_BLOWFISH is not set
# CONFIG_CRYPTO_TWOFISH is not set
# CONFIG_CRYPTO_SERPENT is not set
# CONFIG_CRYPTO_AES is not set
# CONFIG_CRYPTO_CAST5 is not set
# CONFIG_CRYPTO_CAST6 is not set
# CONFIG_CRYPTO_TEA is not set
# CONFIG_CRYPTO_ARC4 is not set
# CONFIG_CRYPTO_KHAZAD is not set
# CONFIG_CRYPTO_ANUBIS is not set
CONFIG_CRYPTO_DEFLATE=y
# CONFIG_CRYPTO_MICHAEL_MIC is not set
# CONFIG_CRYPTO_CRC32C is not set
# CONFIG_CRYPTO_TEST is not set

#
# Hardware crypto devices
#
-------------- next part --------------
#
# Automatically generated make config: don't edit
# Linux kernel version: 2.6.16-eldk-ppc_440-yosemite
# Fri Sep  8 15:24:39 2006
#
CONFIG_MMU=y
CONFIG_GENERIC_HARDIRQS=y
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_PPC=y
CONFIG_PPC32=y
CONFIG_GENERIC_NVRAM=y
CONFIG_SCHED_NO_NO_OMIT_FRAME_POINTER=y
CONFIG_ARCH_MAY_HAVE_PC_FDC=y

#
# Code maturity level options
#
CONFIG_EXPERIMENTAL=y
CONFIG_BROKEN_ON_SMP=y
CONFIG_LOCK_KERNEL=y
CONFIG_INIT_ENV_ARG_LIMIT=32

#
# General setup
#
CONFIG_LOCALVERSION=""
# CONFIG_LOCALVERSION_AUTO is not set
CONFIG_SWAP=y
CONFIG_SYSVIPC=y
CONFIG_POSIX_MQUEUE=y
CONFIG_BSD_PROCESS_ACCT=y
CONFIG_BSD_PROCESS_ACCT_V3=y
CONFIG_SYSCTL=y
CONFIG_AUDIT=y
# CONFIG_AUDITSYSCALL is not set
# CONFIG_IKCONFIG is not set
CONFIG_INITRAMFS_SOURCE=""
CONFIG_CC_OPTIMIZE_FOR_SIZE=y
CONFIG_EMBEDDED=y
CONFIG_KALLSYMS=y
CONFIG_KALLSYMS_ALL=y
# CONFIG_KALLSYMS_EXTRA_PASS is not set
CONFIG_HOTPLUG=y
CONFIG_PRINTK=y
CONFIG_BUG=y
CONFIG_ELF_CORE=y
CONFIG_BASE_FULL=y
CONFIG_FUTEX=y
CONFIG_EPOLL=y
CONFIG_SHMEM=y
CONFIG_CC_ALIGN_FUNCTIONS=0
CONFIG_CC_ALIGN_LABELS=0
CONFIG_CC_ALIGN_LOOPS=0
CONFIG_CC_ALIGN_JUMPS=0
CONFIG_SLAB=y
# CONFIG_TINY_SHMEM is not set
CONFIG_BASE_SMALL=0
# CONFIG_SLOB is not set
CONFIG_OBSOLETE_INTERMODULE=y

#
# Loadable module support
#
CONFIG_MODULES=y
CONFIG_MODULE_UNLOAD=y
# CONFIG_MODULE_FORCE_UNLOAD is not set
CONFIG_OBSOLETE_MODPARM=y
CONFIG_MODVERSIONS=y
CONFIG_MODULE_SRCVERSION_ALL=y
CONFIG_KMOD=y

#
# Block layer
#
# CONFIG_LBD is not set

#
# IO Schedulers
#
CONFIG_IOSCHED_NOOP=y
# CONFIG_IOSCHED_AS is not set
# CONFIG_IOSCHED_DEADLINE is not set
# CONFIG_IOSCHED_CFQ is not set
# CONFIG_DEFAULT_AS is not set
# CONFIG_DEFAULT_DEADLINE is not set
# CONFIG_DEFAULT_CFQ is not set
CONFIG_DEFAULT_NOOP=y
CONFIG_DEFAULT_IOSCHED="noop"

#
# Processor
#
# CONFIG_6xx is not set
# CONFIG_40x is not set
CONFIG_44x=y
# CONFIG_POWER3 is not set
# CONFIG_8xx is not set
# CONFIG_E200 is not set
# CONFIG_E500 is not set
CONFIG_PPC_FPU=y
CONFIG_BOOKE=y
CONFIG_PTE_64BIT=y
CONFIG_PHYS_64BIT=y
CONFIG_MATH_EMULATION=y
# CONFIG_KEXEC is not set
# CONFIG_CPU_FREQ is not set
CONFIG_4xx=y
CONFIG_WANT_EARLY_SERIAL=y

#
# IBM 4xx options
#
# CONFIG_BAMBOO is not set
# CONFIG_EBONY is not set
# CONFIG_LUAN is not set
# CONFIG_YUCCA is not set
# CONFIG_OCOTEA is not set
# CONFIG_P3P440 is not set
# CONFIG_YELLOWSTONE is not set
CONFIG_YOSEMITE=y
CONFIG_440EP=y
CONFIG_440=y
CONFIG_IBM440EP_ERR42=y
CONFIG_IBM_OCP=y
CONFIG_PPC4xx_DMA=y
CONFIG_PPC4xx_EDMA=y
CONFIG_PPC_GEN550=y
CONFIG_NOT_COHERENT_CACHE=y

#
# Platform options
#
# CONFIG_PC_KEYBOARD is not set
# CONFIG_HIGHMEM is not set
# CONFIG_HZ_100 is not set
CONFIG_HZ_250=y
# CONFIG_HZ_1000 is not set
CONFIG_HZ=250
# CONFIG_PREEMPT_NONE is not set
# CONFIG_PREEMPT_VOLUNTARY is not set
CONFIG_PREEMPT=y
CONFIG_PREEMPT_BKL=y
CONFIG_SELECT_MEMORY_MODEL=y
CONFIG_FLATMEM_MANUAL=y
# CONFIG_DISCONTIGMEM_MANUAL is not set
# CONFIG_SPARSEMEM_MANUAL is not set
CONFIG_FLATMEM=y
CONFIG_FLAT_NODE_MEM_MAP=y
# CONFIG_SPARSEMEM_STATIC is not set
CONFIG_SPLIT_PTLOCK_CPUS=4
CONFIG_BINFMT_ELF=y
# CONFIG_BINFMT_MISC is not set
# CONFIG_CMDLINE_BOOL is not set
# CONFIG_SECCOMP is not set
CONFIG_ISA_DMA_API=y

#
# Bus options
#
# CONFIG_PPC_I8259 is not set
CONFIG_PPC_INDIRECT_PCI=y
CONFIG_PCI=y
CONFIG_PCI_DOMAINS=y
CONFIG_PCI_LEGACY_PROC=y
# CONFIG_PCI_DEBUG is not set

#
# PCCARD (PCMCIA/CardBus) support
#
# CONFIG_PCCARD is not set

#
# Advanced setup
#
# CONFIG_ADVANCED_OPTIONS is not set

#
# Default settings for advanced configuration options are used
#
CONFIG_HIGHMEM_START=0xfe000000
CONFIG_LOWMEM_SIZE=0x30000000
CONFIG_KERNEL_START=0xc0000000
CONFIG_TASK_SIZE=0x80000000
CONFIG_CONSISTENT_START=0xff100000
CONFIG_CONSISTENT_SIZE=0x00200000
CONFIG_BOOT_LOAD=0x01000000

#
# Networking
#
CONFIG_NET=y

#
# Networking options
#
# CONFIG_NETDEBUG is not set
CONFIG_PACKET=y
CONFIG_PACKET_MMAP=y
CONFIG_UNIX=y
CONFIG_XFRM=y
CONFIG_XFRM_USER=y
CONFIG_NET_KEY=y
CONFIG_INET=y
CONFIG_IP_MULTICAST=y
CONFIG_IP_ADVANCED_ROUTER=y
CONFIG_ASK_IP_FIB_HASH=y
# CONFIG_IP_FIB_TRIE is not set
CONFIG_IP_FIB_HASH=y
CONFIG_IP_MULTIPLE_TABLES=y
CONFIG_IP_ROUTE_FWMARK=y
CONFIG_IP_ROUTE_MULTIPATH=y
# CONFIG_IP_ROUTE_MULTIPATH_CACHED is not set
CONFIG_IP_ROUTE_VERBOSE=y
CONFIG_IP_PNP=y
CONFIG_IP_PNP_DHCP=y
CONFIG_IP_PNP_BOOTP=y
CONFIG_IP_PNP_RARP=y
CONFIG_NET_IPIP=y
CONFIG_NET_IPGRE=y
CONFIG_NET_IPGRE_BROADCAST=y
CONFIG_IP_MROUTE=y
CONFIG_IP_PIMSM_V1=y
CONFIG_IP_PIMSM_V2=y
# CONFIG_ARPD is not set
CONFIG_SYN_COOKIES=y
CONFIG_INET_AH=y
CONFIG_INET_ESP=y
CONFIG_INET_IPCOMP=y
CONFIG_INET_TUNNEL=y
# CONFIG_INET_DIAG is not set
# CONFIG_TCP_CONG_ADVANCED is not set
CONFIG_TCP_CONG_BIC=y

#
# IP: Virtual Server Configuration
#
# CONFIG_IP_VS is not set
CONFIG_IPV6=y
CONFIG_IPV6_PRIVACY=y
CONFIG_INET6_AH=y
CONFIG_INET6_ESP=y
CONFIG_INET6_IPCOMP=y
CONFIG_INET6_TUNNEL=y
# CONFIG_IPV6_TUNNEL is not set
CONFIG_NETFILTER=y
# CONFIG_NETFILTER_DEBUG is not set

#
# Core Netfilter Configuration
#
CONFIG_NETFILTER_NETLINK=y
CONFIG_NETFILTER_NETLINK_QUEUE=y
CONFIG_NETFILTER_NETLINK_LOG=y
CONFIG_NETFILTER_XTABLES=y
CONFIG_NETFILTER_XT_TARGET_CLASSIFY=y
CONFIG_NETFILTER_XT_TARGET_CONNMARK=y
CONFIG_NETFILTER_XT_TARGET_MARK=y
CONFIG_NETFILTER_XT_TARGET_NFQUEUE=y
CONFIG_NETFILTER_XT_TARGET_NOTRACK=y
CONFIG_NETFILTER_XT_MATCH_COMMENT=y
CONFIG_NETFILTER_XT_MATCH_CONNBYTES=y
CONFIG_NETFILTER_XT_MATCH_CONNMARK=y
CONFIG_NETFILTER_XT_MATCH_CONNTRACK=y
# CONFIG_NETFILTER_XT_MATCH_DCCP is not set
CONFIG_NETFILTER_XT_MATCH_HELPER=y
CONFIG_NETFILTER_XT_MATCH_LENGTH=y
CONFIG_NETFILTER_XT_MATCH_LIMIT=y
CONFIG_NETFILTER_XT_MATCH_MAC=y
CONFIG_NETFILTER_XT_MATCH_MARK=y
CONFIG_NETFILTER_XT_MATCH_PKTTYPE=y
CONFIG_NETFILTER_XT_MATCH_REALM=y
# CONFIG_NETFILTER_XT_MATCH_SCTP is not set
CONFIG_NETFILTER_XT_MATCH_STATE=y
CONFIG_NETFILTER_XT_MATCH_STRING=y
CONFIG_NETFILTER_XT_MATCH_TCPMSS=y

#
# IP: Netfilter Configuration
#
CONFIG_IP_NF_CONNTRACK=y
CONFIG_IP_NF_CT_ACCT=y
CONFIG_IP_NF_CONNTRACK_MARK=y
# CONFIG_IP_NF_CONNTRACK_EVENTS is not set
# CONFIG_IP_NF_CONNTRACK_NETLINK is not set
# CONFIG_IP_NF_CT_PROTO_SCTP is not set
CONFIG_IP_NF_FTP=y
CONFIG_IP_NF_IRC=y
# CONFIG_IP_NF_NETBIOS_NS is not set
CONFIG_IP_NF_TFTP=y
CONFIG_IP_NF_AMANDA=y
CONFIG_IP_NF_PPTP=y
# CONFIG_IP_NF_QUEUE is not set
CONFIG_IP_NF_IPTABLES=y
CONFIG_IP_NF_MATCH_IPRANGE=y
CONFIG_IP_NF_MATCH_MULTIPORT=y
CONFIG_IP_NF_MATCH_TOS=y
CONFIG_IP_NF_MATCH_RECENT=y
CONFIG_IP_NF_MATCH_ECN=y
# CONFIG_IP_NF_MATCH_DSCP is not set
CONFIG_IP_NF_MATCH_AH_ESP=y
CONFIG_IP_NF_MATCH_TTL=y
CONFIG_IP_NF_MATCH_OWNER=y
CONFIG_IP_NF_MATCH_ADDRTYPE=y
CONFIG_IP_NF_MATCH_HASHLIMIT=y
CONFIG_IP_NF_MATCH_POLICY=y
CONFIG_IP_NF_FILTER=y
CONFIG_IP_NF_TARGET_REJECT=y
CONFIG_IP_NF_TARGET_LOG=y
# CONFIG_IP_NF_TARGET_ULOG is not set
CONFIG_IP_NF_TARGET_TCPMSS=y
CONFIG_IP_NF_NAT=y
CONFIG_IP_NF_NAT_NEEDED=y
CONFIG_IP_NF_TARGET_MASQUERADE=y
CONFIG_IP_NF_TARGET_REDIRECT=y
CONFIG_IP_NF_TARGET_NETMAP=y
CONFIG_IP_NF_TARGET_SAME=y
CONFIG_IP_NF_NAT_SNMP_BASIC=y
CONFIG_IP_NF_NAT_IRC=y
CONFIG_IP_NF_NAT_FTP=y
CONFIG_IP_NF_NAT_TFTP=y
CONFIG_IP_NF_NAT_AMANDA=y
CONFIG_IP_NF_NAT_PPTP=y
CONFIG_IP_NF_MANGLE=y
CONFIG_IP_NF_TARGET_TOS=y
CONFIG_IP_NF_TARGET_ECN=y
# CONFIG_IP_NF_TARGET_DSCP is not set
CONFIG_IP_NF_TARGET_TTL=y
# CONFIG_IP_NF_TARGET_CLUSTERIP is not set
CONFIG_IP_NF_RAW=y
CONFIG_IP_NF_ARPTABLES=y
CONFIG_IP_NF_ARPFILTER=y
CONFIG_IP_NF_ARP_MANGLE=y

#
# IPv6: Netfilter Configuration (EXPERIMENTAL)
#
# CONFIG_IP6_NF_QUEUE is not set
CONFIG_IP6_NF_IPTABLES=y
CONFIG_IP6_NF_MATCH_RT=y
CONFIG_IP6_NF_MATCH_OPTS=y
CONFIG_IP6_NF_MATCH_FRAG=y
CONFIG_IP6_NF_MATCH_HL=y
CONFIG_IP6_NF_MATCH_MULTIPORT=y
CONFIG_IP6_NF_MATCH_OWNER=y
CONFIG_IP6_NF_MATCH_IPV6HEADER=y
CONFIG_IP6_NF_MATCH_AHESP=y
CONFIG_IP6_NF_MATCH_EUI64=y
CONFIG_IP6_NF_MATCH_POLICY=y
CONFIG_IP6_NF_FILTER=y
CONFIG_IP6_NF_TARGET_LOG=y
CONFIG_IP6_NF_TARGET_REJECT=y
CONFIG_IP6_NF_MANGLE=y
CONFIG_IP6_NF_TARGET_HL=y
CONFIG_IP6_NF_RAW=y

#
# DCCP Configuration (EXPERIMENTAL)
#
# CONFIG_IP_DCCP is not set

#
# SCTP Configuration (EXPERIMENTAL)
#
# CONFIG_IP_SCTP is not set

#
# TIPC Configuration (EXPERIMENTAL)
#
# CONFIG_TIPC is not set
# CONFIG_ATM is not set
# CONFIG_BRIDGE is not set
# CONFIG_VLAN_8021Q is not set
# CONFIG_DECNET is not set
# CONFIG_LLC2 is not set
# CONFIG_IPX is not set
# CONFIG_ATALK is not set
# CONFIG_X25 is not set
# CONFIG_LAPB is not set
# CONFIG_NET_DIVERT is not set
# CONFIG_ECONET is not set
# CONFIG_WAN_ROUTER is not set

#
# QoS and/or fair queueing
#
CONFIG_NET_SCHED=y
# CONFIG_NET_SCH_CLK_JIFFIES is not set
CONFIG_NET_SCH_CLK_GETTIMEOFDAY=y
# CONFIG_NET_SCH_CLK_CPU is not set

#
# Queueing/Scheduling
#
CONFIG_NET_SCH_CBQ=y
CONFIG_NET_SCH_HTB=y
CONFIG_NET_SCH_HFSC=y
CONFIG_NET_SCH_PRIO=y
CONFIG_NET_SCH_RED=y
CONFIG_NET_SCH_SFQ=y
CONFIG_NET_SCH_TEQL=y
CONFIG_NET_SCH_TBF=y
CONFIG_NET_SCH_GRED=y
CONFIG_NET_SCH_DSMARK=y
CONFIG_NET_SCH_NETEM=y
CONFIG_NET_SCH_INGRESS=y

#
# Classification
#
CONFIG_NET_CLS=y
CONFIG_NET_CLS_BASIC=y
CONFIG_NET_CLS_TCINDEX=y
CONFIG_NET_CLS_ROUTE4=y
CONFIG_NET_CLS_ROUTE=y
CONFIG_NET_CLS_FW=y
CONFIG_NET_CLS_U32=y
CONFIG_CLS_U32_PERF=y
CONFIG_CLS_U32_MARK=y
CONFIG_NET_CLS_RSVP=y
CONFIG_NET_CLS_RSVP6=y
CONFIG_NET_EMATCH=y
CONFIG_NET_EMATCH_STACK=32
CONFIG_NET_EMATCH_CMP=y
CONFIG_NET_EMATCH_NBYTE=y
CONFIG_NET_EMATCH_U32=y
CONFIG_NET_EMATCH_META=y
CONFIG_NET_EMATCH_TEXT=y
CONFIG_NET_CLS_ACT=y
CONFIG_NET_ACT_POLICE=y
CONFIG_NET_ACT_GACT=y
CONFIG_GACT_PROB=y
CONFIG_NET_ACT_MIRRED=y
CONFIG_NET_ACT_IPT=y
CONFIG_NET_ACT_PEDIT=y
# CONFIG_NET_ACT_SIMP is not set
CONFIG_NET_CLS_IND=y
CONFIG_NET_ESTIMATOR=y

#
# Network testing
#
CONFIG_NET_PKTGEN=y
# CONFIG_HAMRADIO is not set
# CONFIG_IRDA is not set
# CONFIG_BT is not set
# CONFIG_IEEE80211 is not set

#
# Device Drivers
#

#
# Generic Driver Options
#
CONFIG_STANDALONE=y
CONFIG_PREVENT_FIRMWARE_BUILD=y
# CONFIG_FW_LOADER is not set
# CONFIG_DEBUG_DRIVER is not set

#
# Connector - unified userspace <-> kernelspace linker
#
CONFIG_CONNECTOR=y
CONFIG_PROC_EVENTS=y

#
# Memory Technology Devices (MTD)
#
CONFIG_MTD=y
# CONFIG_MTD_DEBUG is not set
# CONFIG_MTD_CONCAT is not set
CONFIG_MTD_PARTITIONS=y
# CONFIG_MTD_REDBOOT_PARTS is not set
CONFIG_MTD_CMDLINE_PARTS=y

#
# User Modules And Translation Layers
#
CONFIG_MTD_CHAR=y
CONFIG_MTD_BLOCK=y
# CONFIG_FTL is not set
# CONFIG_NFTL is not set
# CONFIG_INFTL is not set
# CONFIG_RFD_FTL is not set

#
# RAM/ROM/Flash chip drivers
#
CONFIG_MTD_CFI=y
# CONFIG_MTD_JEDECPROBE is not set
CONFIG_MTD_GEN_PROBE=y
# CONFIG_MTD_CFI_ADV_OPTIONS is not set
CONFIG_MTD_MAP_BANK_WIDTH_1=y
CONFIG_MTD_MAP_BANK_WIDTH_2=y
CONFIG_MTD_MAP_BANK_WIDTH_4=y
# CONFIG_MTD_MAP_BANK_WIDTH_8 is not set
# CONFIG_MTD_MAP_BANK_WIDTH_16 is not set
# CONFIG_MTD_MAP_BANK_WIDTH_32 is not set
CONFIG_MTD_CFI_I1=y
CONFIG_MTD_CFI_I2=y
# CONFIG_MTD_CFI_I4 is not set
# CONFIG_MTD_CFI_I8 is not set
# CONFIG_MTD_CFI_INTELEXT is not set
CONFIG_MTD_CFI_AMDSTD=y
CONFIG_MTD_CFI_AMDSTD_RETRY=0
# CONFIG_MTD_CFI_STAA is not set
CONFIG_MTD_CFI_UTIL=y
# CONFIG_MTD_RAM is not set
# CONFIG_MTD_ROM is not set
# CONFIG_MTD_ABSENT is not set
# CONFIG_MTD_OBSOLETE_CHIPS is not set

#
# Mapping drivers for chip access
#
# CONFIG_MTD_COMPLEX_MAPPINGS is not set
# CONFIG_MTD_PHYSMAP is not set
CONFIG_MTD_YOSEMITE=y
# CONFIG_MTD_PLATRAM is not set

#
# Self-contained MTD device drivers
#
# CONFIG_MTD_PMC551 is not set
# CONFIG_MTD_DATAFLASH is not set
# CONFIG_MTD_M25P80 is not set
# CONFIG_MTD_SLRAM is not set
# CONFIG_MTD_PHRAM is not set
# CONFIG_MTD_MTDRAM is not set
# CONFIG_MTD_BLKMTD is not set
# CONFIG_MTD_BLOCK2MTD is not set

#
# Disk-On-Chip Device Drivers
#
# CONFIG_MTD_DOC2000 is not set
# CONFIG_MTD_DOC2001 is not set
# CONFIG_MTD_DOC2001PLUS is not set

#
# NAND Flash Device Drivers
#
# CONFIG_MTD_NAND is not set

#
# OneNAND Flash Device Drivers
#
# CONFIG_MTD_ONENAND is not set

#
# Parallel port support
#
CONFIG_PARPORT=y
# CONFIG_PARPORT_PC is not set
# CONFIG_PARPORT_GSC is not set
# CONFIG_PARPORT_1284 is not set

#
# Plug and Play support
#

#
# Block devices
#
# CONFIG_BLK_DEV_FD is not set
# CONFIG_BLK_CPQ_DA is not set
# CONFIG_BLK_CPQ_CISS_DA is not set
# CONFIG_BLK_DEV_DAC960 is not set
# CONFIG_BLK_DEV_UMEM is not set
# CONFIG_BLK_DEV_COW_COMMON is not set
CONFIG_BLK_DEV_LOOP=y
CONFIG_BLK_DEV_CRYPTOLOOP=y
CONFIG_BLK_DEV_NBD=y
# CONFIG_BLK_DEV_SX8 is not set
CONFIG_BLK_DEV_RAM=y
CONFIG_BLK_DEV_RAM_COUNT=16
CONFIG_BLK_DEV_RAM_SIZE=16384
CONFIG_BLK_DEV_INITRD=y
# CONFIG_CDROM_PKTCDVD is not set
# CONFIG_ATA_OVER_ETH is not set

#
# ATA/ATAPI/MFM/RLL support
#
# CONFIG_IDE is not set

#
# SCSI device support
#
# CONFIG_RAID_ATTRS is not set
# CONFIG_SCSI is not set

#
# Multi-device support (RAID and LVM)
#
# CONFIG_MD is not set

#
# Fusion MPT device support
#
# CONFIG_FUSION is not set

#
# IEEE 1394 (FireWire) support
#
# CONFIG_IEEE1394 is not set

#
# I2O device support
#
# CONFIG_I2O is not set

#
# Macintosh device drivers
#
# CONFIG_WINDFARM is not set

#
# Network device support
#
CONFIG_NETDEVICES=y
# CONFIG_IFB is not set
CONFIG_DUMMY=y
# CONFIG_BONDING is not set
# CONFIG_EQUALIZER is not set
# CONFIG_TUN is not set

#
# ARCnet devices
#
# CONFIG_ARCNET is not set

#
# PHY device support
#
# CONFIG_PHYLIB is not set

#
# Ethernet (10 or 100Mbit)
#
CONFIG_NET_ETHERNET=y
CONFIG_MII=y
# CONFIG_HAPPYMEAL is not set
# CONFIG_SUNGEM is not set
# CONFIG_CASSINI is not set
# CONFIG_NET_VENDOR_3COM is not set

#
# Tulip family network device support
#
# CONFIG_NET_TULIP is not set
# CONFIG_HP100 is not set
CONFIG_IBM_EMAC=y
CONFIG_IBM_EMAC_RXB=128
CONFIG_IBM_EMAC_TXB=64
CONFIG_IBM_EMAC_POLL_WEIGHT=32
CONFIG_IBM_EMAC_RX_COPY_THRESHOLD=256
CONFIG_IBM_EMAC_RX_SKB_HEADROOM=0
# CONFIG_IBM_EMAC_PHY_RX_CLK_FIX is not set
# CONFIG_IBM_EMAC_DEBUG is not set
CONFIG_IBM_EMAC_ZMII=y
CONFIG_NET_PCI=y
# CONFIG_PCNET32 is not set
# CONFIG_AMD8111_ETH is not set
# CONFIG_ADAPTEC_STARFIRE is not set
# CONFIG_B44 is not set
# CONFIG_FORCEDETH is not set
# CONFIG_DGRS is not set
# CONFIG_EEPRO100 is not set
# CONFIG_E100 is not set
# CONFIG_FEALNX is not set
# CONFIG_NATSEMI is not set
# CONFIG_NE2K_PCI is not set
# CONFIG_8139CP is not set
# CONFIG_8139TOO is not set
# CONFIG_SIS900 is not set
# CONFIG_EPIC100 is not set
# CONFIG_SUNDANCE is not set
# CONFIG_TLAN is not set
# CONFIG_VIA_RHINE is not set
# CONFIG_NET_POCKET is not set

#
# Ethernet (1000 Mbit)
#
# CONFIG_ACENIC is not set
# CONFIG_DL2K is not set
CONFIG_E1000=y
# CONFIG_E1000_NAPI is not set
# CONFIG_E1000_DISABLE_PACKET_SPLIT is not set
# CONFIG_NS83820 is not set
# CONFIG_HAMACHI is not set
# CONFIG_YELLOWFIN is not set
# CONFIG_R8169 is not set
# CONFIG_SIS190 is not set
# CONFIG_SKGE is not set
# CONFIG_SKY2 is not set
# CONFIG_SK98LIN is not set
# CONFIG_VIA_VELOCITY is not set
# CONFIG_TIGON3 is not set
# CONFIG_BNX2 is not set

#
# Ethernet (10000 Mbit)
#
# CONFIG_CHELSIO_T1 is not set
# CONFIG_IXGB is not set
# CONFIG_S2IO is not set

#
# Token Ring devices
#
# CONFIG_TR is not set

#
# Wireless LAN (non-hamradio)
#
# CONFIG_NET_RADIO is not set

#
# Wan interfaces
#
# CONFIG_WAN is not set
# CONFIG_FDDI is not set
# CONFIG_HIPPI is not set
# CONFIG_PLIP is not set
# CONFIG_PPP is not set
# CONFIG_SLIP is not set
# CONFIG_SHAPER is not set
# CONFIG_NETCONSOLE is not set
# CONFIG_NETPOLL is not set
# CONFIG_NET_POLL_CONTROLLER is not set

#
# ISDN subsystem
#
# CONFIG_ISDN is not set

#
# Telephony Support
#
# CONFIG_PHONE is not set

#
# Input device support
#
CONFIG_INPUT=y

#
# Userland interfaces
#
# CONFIG_INPUT_MOUSEDEV is not set
# CONFIG_INPUT_JOYDEV is not set
# CONFIG_INPUT_TSDEV is not set
# CONFIG_INPUT_EVDEV is not set
# CONFIG_INPUT_EVBUG is not set

#
# Input Device Drivers
#
# CONFIG_INPUT_KEYBOARD is not set
# CONFIG_INPUT_MOUSE is not set
# CONFIG_INPUT_JOYSTICK is not set
# CONFIG_INPUT_TOUCHSCREEN is not set
# CONFIG_INPUT_MISC is not set

#
# Hardware I/O ports
#
# CONFIG_SERIO is not set
# CONFIG_GAMEPORT is not set

#
# Character devices
#
CONFIG_VT=y
CONFIG_VT_CONSOLE=y
CONFIG_HW_CONSOLE=y
# CONFIG_SERIAL_NONSTANDARD is not set

#
# Serial drivers
#
CONFIG_SERIAL_8250=y
CONFIG_SERIAL_8250_CONSOLE=y
CONFIG_SERIAL_8250_NR_UARTS=48
CONFIG_SERIAL_8250_RUNTIME_UARTS=4
CONFIG_SERIAL_8250_EXTENDED=y
CONFIG_SERIAL_8250_MANY_PORTS=y
CONFIG_SERIAL_8250_SHARE_IRQ=y
# CONFIG_SERIAL_8250_DETECT_IRQ is not set
CONFIG_SERIAL_8250_RSA=y

#
# Non-8250 serial port support
#
CONFIG_SERIAL_CORE=y
CONFIG_SERIAL_CORE_CONSOLE=y
# CONFIG_SERIAL_JSM is not set
CONFIG_UNIX98_PTYS=y
CONFIG_LEGACY_PTYS=y
CONFIG_LEGACY_PTY_COUNT=256
# CONFIG_PRINTER is not set
# CONFIG_PPDEV is not set
# CONFIG_TIPAR is not set

#
# IPMI
#
# CONFIG_IPMI_HANDLER is not set

#
# Watchdog Cards
#
CONFIG_WATCHDOG=y
# CONFIG_WATCHDOG_NOWAYOUT is not set

#
# Watchdog Device Drivers
#
# CONFIG_SOFT_WATCHDOG is not set
CONFIG_BOOKE_WDT=y

#
# PCI-based Watchdog Cards
#
# CONFIG_PCIPCWATCHDOG is not set
# CONFIG_WDTPCI is not set
CONFIG_NVRAM=y
CONFIG_GEN_RTC=y
CONFIG_GEN_RTC_X=y
# CONFIG_DTLK is not set
# CONFIG_R3964 is not set
# CONFIG_APPLICOM is not set

#
# Ftape, the floppy tape device driver
#
# CONFIG_AGP is not set
# CONFIG_DRM is not set
# CONFIG_RAW_DRIVER is not set

#
# TPM devices
#
# CONFIG_TCG_TPM is not set
# CONFIG_TELCLOCK is not set

#
# I2C support
#
CONFIG_I2C=y
CONFIG_I2C_CHARDEV=y

#
# I2C Algorithms
#
CONFIG_I2C_ALGOBIT=y
CONFIG_I2C_ALGOPCF=y
CONFIG_I2C_ALGOPCA=y

#
# I2C Hardware Bus support
#
# CONFIG_I2C_ALI1535 is not set
# CONFIG_I2C_ALI1563 is not set
# CONFIG_I2C_ALI15X3 is not set
# CONFIG_I2C_AMD756 is not set
# CONFIG_I2C_AMD8111 is not set
# CONFIG_I2C_I801 is not set
# CONFIG_I2C_I810 is not set
# CONFIG_I2C_PIIX4 is not set
CONFIG_I2C_IBM_IIC=y
# CONFIG_I2C_MPC is not set
# CONFIG_I2C_MPC8260 is not set
# CONFIG_I2C_NFORCE2 is not set
# CONFIG_I2C_PARPORT is not set
# CONFIG_I2C_PARPORT_LIGHT is not set
# CONFIG_I2C_PROSAVAGE is not set
# CONFIG_I2C_SAVAGE4 is not set
# CONFIG_SCx200_ACB is not set
# CONFIG_I2C_SIS5595 is not set
# CONFIG_I2C_SIS630 is not set
# CONFIG_I2C_SIS96X is not set
# CONFIG_I2C_STUB is not set
# CONFIG_I2C_VIA is not set
# CONFIG_I2C_VIAPRO is not set
# CONFIG_I2C_VOODOO3 is not set
# CONFIG_I2C_PCA_ISA is not set

#
# Miscellaneous I2C Chip support
#
# CONFIG_SENSORS_DS1337 is not set
# CONFIG_SENSORS_DS1374 is not set
# CONFIG_SENSORS_EEPROM is not set
# CONFIG_SENSORS_MAX6900 is not set
# CONFIG_SENSORS_PCF8574 is not set
# CONFIG_SENSORS_PCF8563 is not set
# CONFIG_SENSORS_PCA9539 is not set
# CONFIG_SENSORS_PCF8591 is not set
# CONFIG_SENSORS_RTC8564 is not set
# CONFIG_SENSORS_M41T00 is not set
# CONFIG_SENSORS_MAX6875 is not set
# CONFIG_RTC_X1205_I2C is not set
# CONFIG_I2C_DEBUG_CORE is not set
# CONFIG_I2C_DEBUG_ALGO is not set
# CONFIG_I2C_DEBUG_BUS is not set
# CONFIG_I2C_DEBUG_CHIP is not set

#
# SPI support
#
CONFIG_SPI=y
# CONFIG_SPI_DEBUG is not set
CONFIG_SPI_MASTER=y

#
# SPI Master Controller Drivers
#
# CONFIG_SPI_BITBANG is not set
# CONFIG_SPI_BUTTERFLY is not set

#
# SPI Protocol Masters
#

#
# Dallas's 1-wire bus
#
# CONFIG_W1 is not set

#
# Hardware Monitoring support
#
# CONFIG_HWMON is not set
# CONFIG_HWMON_VID is not set

#
# Misc devices
#

#
# Multimedia Capabilities Port drivers
#

#
# Multimedia devices
#
# CONFIG_VIDEO_DEV is not set

#
# Digital Video Broadcasting Devices
#
# CONFIG_DVB is not set

#
# Graphics support
#
# CONFIG_FB is not set

#
# Console display driver support
#
CONFIG_DUMMY_CONSOLE=y

#
# Sound
#
# CONFIG_SOUND is not set

#
# USB support
#
CONFIG_USB_ARCH_HAS_HCD=y
CONFIG_USB_ARCH_HAS_OHCI=y
# CONFIG_USB is not set

#
# NOTE: USB_STORAGE enables SCSI, and 'SCSI disk support'
#

#
# USB Gadget Support
#
# CONFIG_USB_GADGET is not set

#
# MMC/SD Card support
#
# CONFIG_MMC is not set

#
# InfiniBand support
#
# CONFIG_INFINIBAND is not set

#
# EDAC - error detection and reporting (RAS) (EXPERIMENTAL)
#

#
# File systems
#
CONFIG_EXT2_FS=y
CONFIG_EXT2_FS_XATTR=y
CONFIG_EXT2_FS_POSIX_ACL=y
CONFIG_EXT2_FS_SECURITY=y
# CONFIG_EXT2_FS_XIP is not set
# CONFIG_EXT3_FS is not set
CONFIG_FS_MBCACHE=y
# CONFIG_REISERFS_FS is not set
# CONFIG_JFS_FS is not set
CONFIG_FS_POSIX_ACL=y
# CONFIG_XFS_FS is not set
# CONFIG_OCFS2_FS is not set
# CONFIG_MINIX_FS is not set
# CONFIG_ROMFS_FS is not set
CONFIG_INOTIFY=y
# CONFIG_QUOTA is not set
CONFIG_DNOTIFY=y
CONFIG_AUTOFS_FS=y
CONFIG_AUTOFS4_FS=y
# CONFIG_FUSE_FS is not set

#
# CD-ROM/DVD Filesystems
#
# CONFIG_ISO9660_FS is not set
# CONFIG_UDF_FS is not set

#
# DOS/FAT/NT Filesystems
#
# CONFIG_MSDOS_FS is not set
# CONFIG_VFAT_FS is not set
# CONFIG_NTFS_FS is not set

#
# Pseudo filesystems
#
CONFIG_PROC_FS=y
CONFIG_PROC_KCORE=y
CONFIG_SYSFS=y
CONFIG_TMPFS=y
# CONFIG_HUGETLB_PAGE is not set
CONFIG_RAMFS=y
CONFIG_RELAYFS_FS=y
# CONFIG_CONFIGFS_FS is not set

#
# Miscellaneous filesystems
#
# CONFIG_ADFS_FS is not set
# CONFIG_AFFS_FS is not set
# CONFIG_HFS_FS is not set
# CONFIG_HFSPLUS_FS is not set
# CONFIG_BEFS_FS is not set
# CONFIG_BFS_FS is not set
# CONFIG_EFS_FS is not set
# CONFIG_JFFS_FS is not set
CONFIG_JFFS2_FS=y
CONFIG_JFFS2_FS_DEBUG=0
CONFIG_JFFS2_FS_WRITEBUFFER=y
# CONFIG_JFFS2_SUMMARY is not set
# CONFIG_JFFS2_COMPRESSION_OPTIONS is not set
CONFIG_JFFS2_ZLIB=y
CONFIG_JFFS2_RTIME=y
# CONFIG_JFFS2_RUBIN is not set
CONFIG_CRAMFS=y
# CONFIG_VXFS_FS is not set
# CONFIG_HPFS_FS is not set
# CONFIG_QNX4FS_FS is not set
# CONFIG_SYSV_FS is not set
# CONFIG_UFS_FS is not set

#
# Network File Systems
#
CONFIG_NFS_FS=y
CONFIG_NFS_V3=y
CONFIG_NFS_V3_ACL=y
CONFIG_NFS_V4=y
CONFIG_NFS_DIRECTIO=y
# CONFIG_NFSD is not set
CONFIG_ROOT_NFS=y
CONFIG_LOCKD=y
CONFIG_LOCKD_V4=y
CONFIG_NFS_ACL_SUPPORT=y
CONFIG_NFS_COMMON=y
CONFIG_SUNRPC=y
CONFIG_SUNRPC_GSS=y
CONFIG_RPCSEC_GSS_KRB5=y
# CONFIG_RPCSEC_GSS_SPKM3 is not set
# CONFIG_SMB_FS is not set
# CONFIG_CIFS is not set
# CONFIG_NCP_FS is not set
# CONFIG_CODA_FS is not set
# CONFIG_AFS_FS is not set
# CONFIG_9P_FS is not set

#
# Partition Types
#
# CONFIG_PARTITION_ADVANCED is not set
CONFIG_MSDOS_PARTITION=y

#
# Native Language Support
#
CONFIG_NLS=y
CONFIG_NLS_DEFAULT="cp437"
# CONFIG_NLS_CODEPAGE_437 is not set
# CONFIG_NLS_CODEPAGE_737 is not set
# CONFIG_NLS_CODEPAGE_775 is not set
# CONFIG_NLS_CODEPAGE_850 is not set
# CONFIG_NLS_CODEPAGE_852 is not set
# CONFIG_NLS_CODEPAGE_855 is not set
# CONFIG_NLS_CODEPAGE_857 is not set
# CONFIG_NLS_CODEPAGE_860 is not set
# CONFIG_NLS_CODEPAGE_861 is not set
# CONFIG_NLS_CODEPAGE_862 is not set
# CONFIG_NLS_CODEPAGE_863 is not set
# CONFIG_NLS_CODEPAGE_864 is not set
# CONFIG_NLS_CODEPAGE_865 is not set
# CONFIG_NLS_CODEPAGE_866 is not set
# CONFIG_NLS_CODEPAGE_869 is not set
# CONFIG_NLS_CODEPAGE_936 is not set
# CONFIG_NLS_CODEPAGE_950 is not set
# CONFIG_NLS_CODEPAGE_932 is not set
# CONFIG_NLS_CODEPAGE_949 is not set
# CONFIG_NLS_CODEPAGE_874 is not set
# CONFIG_NLS_ISO8859_8 is not set
# CONFIG_NLS_CODEPAGE_1250 is not set
# CONFIG_NLS_CODEPAGE_1251 is not set
# CONFIG_NLS_ASCII is not set
# CONFIG_NLS_ISO8859_1 is not set
# CONFIG_NLS_ISO8859_2 is not set
# CONFIG_NLS_ISO8859_3 is not set
# CONFIG_NLS_ISO8859_4 is not set
# CONFIG_NLS_ISO8859_5 is not set
# CONFIG_NLS_ISO8859_6 is not set
# CONFIG_NLS_ISO8859_7 is not set
# CONFIG_NLS_ISO8859_9 is not set
# CONFIG_NLS_ISO8859_13 is not set
# CONFIG_NLS_ISO8859_14 is not set
# CONFIG_NLS_ISO8859_15 is not set
# CONFIG_NLS_KOI8_R is not set
# CONFIG_NLS_KOI8_U is not set
CONFIG_NLS_UTF8=y

#
# Library routines
#
# CONFIG_CRC_CCITT is not set
# CONFIG_CRC16 is not set
CONFIG_CRC32=y
# CONFIG_LIBCRC32C is not set
CONFIG_ZLIB_INFLATE=y
CONFIG_ZLIB_DEFLATE=y
CONFIG_TEXTSEARCH=y
CONFIG_TEXTSEARCH_KMP=y
CONFIG_TEXTSEARCH_BM=y
CONFIG_TEXTSEARCH_FSM=y
# CONFIG_PROFILING is not set

#
# Kernel hacking
#
# CONFIG_PRINTK_TIME is not set
CONFIG_MAGIC_SYSRQ=y
CONFIG_DEBUG_KERNEL=y
CONFIG_LOG_BUF_SHIFT=17
CONFIG_DETECT_SOFTLOCKUP=y
# CONFIG_SCHEDSTATS is not set
# CONFIG_DEBUG_SLAB is not set
# CONFIG_DEBUG_PREEMPT is not set
# CONFIG_DEBUG_MUTEXES is not set
# CONFIG_DEBUG_SPINLOCK is not set
# CONFIG_DEBUG_SPINLOCK_SLEEP is not set
# CONFIG_DEBUG_KOBJECT is not set
CONFIG_DEBUG_INFO=y
# CONFIG_DEBUG_FS is not set
# CONFIG_DEBUG_VM is not set
# CONFIG_FORCED_INLINING is not set
# CONFIG_RCU_TORTURE_TEST is not set
CONFIG_KGDB=y
# CONFIG_KGDB_TTYS0 is not set
CONFIG_KGDB_TTYS1=y
# CONFIG_KGDB_TTYS2 is not set
# CONFIG_KGDB_TTYS3 is not set
# CONFIG_XMON is not set
# CONFIG_BDI_SWITCH is not set
# CONFIG_SERIAL_TEXT_DEBUG is not set
CONFIG_PPC_OCP=y

#
# Security options
#
# CONFIG_KEYS is not set
# CONFIG_SECURITY is not set

#
# Cryptographic options
#
CONFIG_CRYPTO=y
CONFIG_CRYPTO_HMAC=y
# CONFIG_CRYPTO_NULL is not set
# CONFIG_CRYPTO_MD4 is not set
CONFIG_CRYPTO_MD5=y
CONFIG_CRYPTO_SHA1=y
# CONFIG_CRYPTO_SHA256 is not set
# CONFIG_CRYPTO_SHA512 is not set
# CONFIG_CRYPTO_WP512 is not set
# CONFIG_CRYPTO_TGR192 is not set
CONFIG_CRYPTO_DES=y
# CONFIG_CRYPTO_BLOWFISH is not set
# CONFIG_CRYPTO_TWOFISH is not set
# CONFIG_CRYPTO_SERPENT is not set
# CONFIG_CRYPTO_AES is not set
# CONFIG_CRYPTO_CAST5 is not set
# CONFIG_CRYPTO_CAST6 is not set
# CONFIG_CRYPTO_TEA is not set
# CONFIG_CRYPTO_ARC4 is not set
# CONFIG_CRYPTO_KHAZAD is not set
# CONFIG_CRYPTO_ANUBIS is not set
CONFIG_CRYPTO_DEFLATE=y
# CONFIG_CRYPTO_MICHAEL_MIC is not set
# CONFIG_CRYPTO_CRC32C is not set
# CONFIG_CRYPTO_TEST is not set

#
# Hardware crypto devices
#
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 191 bytes
Desc: =?UTF-8?Q?=E8=BF=99=E6=98=AF=E4=BF=A1=E4=BB=B6=E7=9A=84=E6=95=B0?=
	=?UTF-8?Q?=E5=AD=97=E7=AD=BE=E5=90=8D=E9=83=A8=E5=88=86?=
Url : http://lists.infradead.org/pipermail/linux-mtd/attachments/20060908/2ca83e61/attachment.bin 

From raph at 8d.com  Wed Sep 13 08:50:33 2006
From: raph at 8d.com (Raphael Assenat)
Date: Wed, 13 Sep 2006 08:50:33 -0400
Subject: [PATCH] cmx270-nand: Make CMDLINE_PARTS usable
Message-ID: <4507FE99.3030106@8d.com>

This patch gives a name to the cmx270 nand mtd, making it possible to use command line
partitioning.

eg:
mtdparts=cmx270-nand:32m(root),8m(data),-(spare)"

does not work without this patch. The default (one full device partition)
hardcoded in the driver is used.


Signed-off-by: Raphael Assenat <raph at 8d.com>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: cmx270-nand-cmdlinepart.diff
Url: http://lists.infradead.org/pipermail/linux-mtd/attachments/20060913/da46eba9/attachment.pl 

From wd at denx.de  Thu Sep 14 18:18:30 2006
From: wd at denx.de (Wolfgang Denk)
Date: Fri, 15 Sep 2006 00:18:30 +0200
Subject: mtd failed on ppc 440GR(yosemite) while CONFIG_YOSEMITE=y 
In-Reply-To: Your message of "Fri, 08 Sep 2006 20:54:26 +0800."
	<357780444.20354@eyou.net> <1157720067.10958.25.camel@ubuntu01> 
Message-ID: <20060914221830.4F953353A15@atlas.denx.de>

Hello,

in message <357780444.20354 at eyou.net> <1157720067.10958.25.camel at ubuntu01> you wrote:
> 
> I'm trying to enable mtd on the amcc 440GR yosemite evaluation board,
> but failed. here is a section from the .config of linux-2.6.16 from eldk

Please get your information right. ELDK does *not* inlcude a 2.6.16
kernel. ELDK-4.0 (the latest official release) comes with 2.6.15
instead.

> it caused Data Machine Check, attachment mtd_error.txt is the log file.

The ELDK version (2.6.15) works fine here:

	...
	AMCC440-flash: Found 1 x16 devices at 0x0 in 16-bit bank
	 Amd/Fujitsu Extended Query Table at 0x0040
	AMCC440-flash: CFI does not contain boot bank location.  Assuming top.
	number of CFI chips: 1
	cfi_cmdset_0002: Disabling erase-suspend-program due to code brokenness.
	Creating 5 MTD partitions on "AMCC440-flash":
	0x00000000-0x00180000 : "kernel"
	0x00180000-0x00400000 : "root"
	0x00400000-0x03f40000 : "user"
	0x03f40000-0x03f80000 : "env"
	0x03f80000-0x04000000 : "u-boot"
	...

Also, running cuurent source (which is strongly recommended) wortks
fine for me:

a) using the latest image from the FTP server (2.6.17-rc3):
   ftp://ftp.denx.de/pub/linux/images/amcc/yosemite/uImage

	...
	AMCC440-flash: Found 1 x16 devices at 0x0 in 16-bit bank
	 Amd/Fujitsu Extended Query Table at 0x0040
	AMCC440-flash: CFI does not contain boot bank location. Assuming top.
	number of CFI chips: 1
	cfi_cmdset_0002: Disabling erase-suspend-program due to code
	brokenness.
	Creating 5 MTD partitions on "AMCC440-flash":
	0x00000000-0x00180000 : "kernel"
	0x00180000-0x00400000 : "root"
	0x00400000-0x03f40000 : "user"
	0x03f40000-0x03f80000 : "env"
	0x03f80000-0x04000000 : "u-boot"
	...

b) Using top of tree from git repo (2.6.18-rc7):

	...
	AMCC440-flash: Found 1 x16 devices at 0x0 in 16-bit bank
	 Amd/Fujitsu Extended Query Table at 0x0040
	AMCC440-flash: CFI does not contain boot bank location. Assuming
	top.
	number of CFI chips: 1
	cfi_cmdset_0002: Disabling erase-suspend-program due to code
	brokenness.
	Creating 5 MTD partitions on "AMCC440-flash":
	0x00000000-0x00180000 : "kernel"
	0x00180000-0x00400000 : "root"
	0x00400000-0x03f40000 : "user"
	0x03f40000-0x03f80000 : "env"
	0x03f80000-0x04000000 : "u-boot"
	...


In all 3 cases the yosemite default configuration (i. e. what you get
when running "make yosemite_defconfig") was used. No problems
observed.

You must be doing something wrong. Please RTFM. The  yosemite  manual
can be found at
http://www.denx.de/wiki/view/DULG/Manual?stickboard=yosemite


> config-2.6.16-5-eldk-ppc_440-yosemite is the related .config file for
> config-2.6.16-4-eldk-ppc_440-yosemite is the .config file without

2.6.16-5 does not look like a kernel from our repo, and neither does
2.6.16-4

> boot success, but it cause the system only have 1 partition of mtd, and
> when doing a: 
> # fdisk /dev/mtd0
> would cause the shell block for ever(don't return to the shell prompt).

This command is bogus anyway.  "fdisk"  cannot  be  used  with  flash
devices like this.

> how could I enable mtd in (amcc) 440GR yosemite evaluation board? thanks
> in advance!

Ummm... what are you talking about? The 'yosemite' board is  a  440EP
system; the 440GR eval board is called 'yellowstone'.

> I've tried this for days, and really get tired of that.

Maybe you just mix up configurations.

> BTW: the kernel source is different from vanilla kernel, and it can be
> found at: ftp://ftp.denx.de/pub/linux/linux-2.6.16.tar.bz2

The kernel on our FTP server / in our repo is NOT a  vanilla  kernel.
It contains patches that did not make it upstream (yet).

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
"Here's a fish hangs in the net like a poor man's right in  the  law.
'Twill hardly come out."     - Shakespeare, Pericles, Act II, Scene 1



From confirm.croquet at rossipaul.com  Thu Sep 14 21:21:28 2006
From: confirm.croquet at rossipaul.com (confirm)
Date: Fri, 15 Sep 2006 03:21:28 +0200
Subject: You can get ca sh now
Message-ID: <04665158231172.EC767DEFFA@U124NKX>


Highly Respected,


You have been chosen to join in an invitation only limited time event!

If you own real estate this offer can make you pro fit.

Simple, if You need some extra cas h to spend any way you like - just deal with us.

Are you currently p aying too much on your monthly paymen ts?

Your current cr edit is not the issue for us, and will not disqualify you!

If you're interested, please go here > http://WXGZ.liseranvo.com/?ncache=1030239

If not, please send blank email to: nomore at ascoltob.com  with the subject "NoMore",

Your email address will be removed within 48 hour from our advertising partner's lists.



Cre dit Math Specialists,
Donald Gee,
Advertising & Approval dept.,
10505 Highland Lane
Takoma Park, MD, 20912






From arvind at 4access-comm.com  Thu Sep 14 21:28:58 2006
From: arvind at 4access-comm.com (Arvind Agrawal)
Date: Thu, 14 Sep 2006 18:28:58 -0700
Subject: Nand Read Errors using Jffs2
Message-ID: <00fa01c6d866$51306df0$6501a8c0@arvindwin2000>

Hi,

We are using Micro Nand Flash 256MiB with Arm Linux 2.6.11.7 (which is more
than a year old) .
Time to time , I get mtd->read errors but most of the time data seems to be
O.K. and then will start getting inode errors.
Also the flash started it with just 3 bad blocks and now I have around 12
bad blocks, which means that either they have gone genuinely bad or because
of excessive read errors jffs2 marked them bad ;

# # time cp stage.jffs2 nand4/s14%

mtd->read(0x1044 bytes from 0x2f1c888) returned ECC error
Header CRC failed on REF_PRISTINE node at 0x02f1c888: Read 0x30303030,
calculated 0xa52a526a

# # time cp stage.jffs2 nand4/s10_1

mtd->read(0x1044 bytes from 0x2f0e558) returned ECC error
Unknown node type for REF_PRISTINE node at 0x02f0e558: 0x0000

# time cp stage.jffs2 nand4/s41_7
mtd->read(0x1000 bytes from 0x2f20000) returned ECC error
Newly-erased block contained word 0x30 at offset 0x02f20000
mtd->read(0x1000 bytes from 0x2f20000) returned ECC error
Newly-erased block contained word 0x0 at offset 0x02f20000


I need help to figure out that what may be causing this problem?
Could it be hardware timing related?
Or could point software, either old versions of mtd, jffs2 or the small
driver , we did for Micron NAND?

Any pointers are greatly appreciated.

thanks,
Arvind




From dedekind at yandex.ru  Fri Sep 15 03:16:49 2006
From: dedekind at yandex.ru (dedekind)
Date: Fri, 15 Sep 2006 11:16:49 +0400 (MSD)
Subject: Running nandsim...
Message-ID: <450A5361.000001.25703@mfront8.yandex.ru>

[Please, let's keep MTD ML in CC]

>> It is just a bug. I was fixed in newer kernels. Just change "bool" to
>> "tristate" for nandsim in Kconfig.
> Thanks for your quick reply. I got nandsim running as a module. I was 
> trying to search for some documentation on how to use it (Say to 
> simulate a NAND chip with FTL/NFTL running VFAT or directly using
> JFFS2).
No, no FTL/NFTL.

> Is there some documentation ?
I don't think so.

> I searched on linux-mtd and google'd for some information.
Glance at the UBI HOWTO page - there is some information:
http://www.linux-mtd.infradead.org/faq/ubi.html#L_how_debug

BR, Artem.



From hskinnemoen at atmel.com  Fri Sep 15 03:56:29 2006
From: hskinnemoen at atmel.com (Haavard Skinnemoen)
Date: Fri, 15 Sep 2006 09:56:29 +0200
Subject: [-mm patch 3/4] AVR32 MTD: Mapping driver for the ATSTK1000board
In-Reply-To: <1158264688.4312.82.camel@pmac.infradead.org>
References: <20060914162926.6c117b36@cad-250-152.norway.atmel.com>
	<20060914163026.49766346@cad-250-152.norway.atmel.com>
	<20060914163121.241dec3e@cad-250-152.norway.atmel.com>
	<20060914163259.068abe6d@cad-250-152.norway.atmel.com>
	<1158264688.4312.82.camel@pmac.infradead.org>
Message-ID: <20060915095629.22cf01f4@cad-250-152.norway.atmel.com>

On Thu, 14 Sep 2006 21:11:28 +0100
David Woodhouse <dwmw2 at infradead.org> wrote:

> On Thu, 2006-09-14 at 16:32 +0200, Haavard Skinnemoen wrote:
> > Add mapping driver for the AT49BV6416 NOR flash chip on the
> > ATSTK1000 development board. 
> 
> Hm, can't you set it up in advance and just register a platform_device
> for physmap to drive?

Probably. I'll give it a try.

I have to find a way to unlock the flash at some point, though. Is it
okay if I add code to physmap to iterate over the partitions and unlock
the writable ones if info->mtd->unlock is non-null? Or is there a
better way to do it?

Andrew, please don't merge any of the patches in this series. I just
noticed that the SMC patch should be cleaned up a bit, so I'm
probably going to rework all the patches.

(btw, I got an "awaiting moderator approval" message from the linux-mtd
mailer because "Message has a suspicious header". Can someone tell me
more about this so I can fix my mailer?)

Thanks,

Haavard



From dwmw2 at infradead.org  Fri Sep 15 04:00:30 2006
From: dwmw2 at infradead.org (David Woodhouse)
Date: Fri, 15 Sep 2006 09:00:30 +0100
Subject: [-mm patch 3/4] AVR32 MTD: Mapping driver for the ATSTK1000board
In-Reply-To: <20060915095629.22cf01f4@cad-250-152.norway.atmel.com>
References: <20060914162926.6c117b36@cad-250-152.norway.atmel.com>
	<20060914163026.49766346@cad-250-152.norway.atmel.com>
	<20060914163121.241dec3e@cad-250-152.norway.atmel.com>
	<20060914163259.068abe6d@cad-250-152.norway.atmel.com>
	<1158264688.4312.82.camel@pmac.infradead.org>
	<20060915095629.22cf01f4@cad-250-152.norway.atmel.com>
Message-ID: <1158307230.24527.36.camel@pmac.infradead.org>

On Fri, 2006-09-15 at 09:56 +0200, Haavard Skinnemoen wrote:
> Probably. I'll give it a try.
> 
> I have to find a way to unlock the flash at some point, though. Is it
> okay if I add code to physmap to iterate over the partitions and unlock
> the writable ones if info->mtd->unlock is non-null? Or is there a
> better way to do it?

I'm coming to the conclusion that if there are flash chips which inherit
the Intel insanity of automatically locking themselves on every power
cycle, thus rendering the 'locked' status meaningless, we should just
automatically unlock the whole chip at boot time, from the _chip_
driver.

That way, we can remove that hack from the board drivers which are
currently doing it.

> (btw, I got an "awaiting moderator approval" message from the linux-mtd
> mailer because "Message has a suspicious header". Can someone tell me
> more about this so I can fix my mailer?) 

Attachments would do that, but your patches were sensibly inlined.

In fact, your mail got trapped for moderation because you did the
_right_ thing -- you sent them in a thread, with References: headers to
keep them together. But because that means you have References: and no
'Re:' in the Subject: header, that's indistinguishable from the muppets
who try to start a new thread by replying to an existing mail and
changing the subject. So it's trapped for moderation and I get to look
at it and manually approve it.

-- 
dwmw2




From hskinnemoen at atmel.com  Fri Sep 15 04:22:32 2006
From: hskinnemoen at atmel.com (Haavard Skinnemoen)
Date: Fri, 15 Sep 2006 10:22:32 +0200
Subject: [-mm patch 3/4] AVR32 MTD: Mapping driver for theATSTK1000board
In-Reply-To: <1158307230.24527.36.camel@pmac.infradead.org>
References: <20060914162926.6c117b36@cad-250-152.norway.atmel.com>
	<20060914163026.49766346@cad-250-152.norway.atmel.com>
	<20060914163121.241dec3e@cad-250-152.norway.atmel.com>
	<20060914163259.068abe6d@cad-250-152.norway.atmel.com>
	<1158264688.4312.82.camel@pmac.infradead.org>
	<20060915095629.22cf01f4@cad-250-152.norway.atmel.com>
	<1158307230.24527.36.camel@pmac.infradead.org>
Message-ID: <20060915102232.29909340@cad-250-152.norway.atmel.com>

On Fri, 15 Sep 2006 09:00:30 +0100
David Woodhouse <dwmw2 at infradead.org> wrote:

> I'm coming to the conclusion that if there are flash chips which
> inherit the Intel insanity of automatically locking themselves on
> every power cycle, thus rendering the 'locked' status meaningless, we
> should just automatically unlock the whole chip at boot time, from
> the _chip_ driver.

Yeah, there really is no reason to keep anything "soft locked". I'll
unlock the chip from the fixup I submitted earlier so that it comes up
unlocked by default.

> So it's trapped for moderation and I
> get to look at it and manually approve it.

I'll keep doing it, then. That way, I can be sure that you'll notice my
patches, too ;)

Thanks,

Haavard



From alan at lxorguk.ukuu.org.uk  Fri Sep 15 10:20:32 2006
From: alan at lxorguk.ukuu.org.uk (Alan Cox)
Date: Fri, 15 Sep 2006 15:20:32 +0100
Subject: [PATCH] mtd: switch to pci_get_device and do ref counting
Message-ID: <1158330032.29932.48.camel@localhost.localdomain>

Signed-off-by: Alan Cox <alan at redhat.com>

diff -u --new-file --recursive --exclude-from /usr/src/exclude linux.vanilla-2.6.18-rc6-mm1/drivers/mtd/devices/pmc551.c linux-2.6.18-rc6-mm1/drivers/mtd/devices/pmc551.c
--- linux.vanilla-2.6.18-rc6-mm1/drivers/mtd/devices/pmc551.c	2006-09-11 17:00:13.000000000 +0100
+++ linux-2.6.18-rc6-mm1/drivers/mtd/devices/pmc551.c	2006-09-14 17:13:56.000000000 +0100
@@ -674,7 +674,7 @@
          */
         for( count = 0; count < MAX_MTD_DEVICES; count++ ) {
 
-                if ((PCI_Device = pci_find_device(PCI_VENDOR_ID_V3_SEMI,
+                if ((PCI_Device = pci_get_device(PCI_VENDOR_ID_V3_SEMI,
                                                   PCI_DEVICE_ID_V3_SEMI_V370PDC,
 						  PCI_Device ) ) == NULL) {
                         break;
@@ -783,6 +783,10 @@
                         kfree(mtd);
                         break;
                 }
+                
+                /* Keep a reference as the add_mtd_device worked */
+                pci_dev_get(PCI_Device);
+
                 printk(KERN_NOTICE "Registered pmc551 memory device.\n");
                 printk(KERN_NOTICE "Mapped %dM of memory from 0x%p to 0x%p\n",
                        priv->asize>>20,
@@ -797,6 +801,10 @@
 		found++;
         }
 
+        /* Exited early, reference left over */
+        if (PCI_Device)
+        	pci_dev_put(PCI_Device);
+
         if( !pmc551list ) {
                 printk(KERN_NOTICE "pmc551: not detected\n");
                 return -ENODEV;
@@ -824,6 +832,7 @@
 				priv->asize>>20, priv->start);
 			iounmap (priv->start);
 		}
+		pci_dev_put(priv->dev);
 
 		kfree (mtd->priv);
 		del_mtd_device (mtd);
diff -u --new-file --recursive --exclude-from /usr/src/exclude linux.vanilla-2.6.18-rc6-mm1/drivers/mtd/maps/amd76xrom.c linux-2.6.18-rc6-mm1/drivers/mtd/maps/amd76xrom.c
--- linux.vanilla-2.6.18-rc6-mm1/drivers/mtd/maps/amd76xrom.c	2006-09-11 11:02:17.000000000 +0100
+++ linux-2.6.18-rc6-mm1/drivers/mtd/maps/amd76xrom.c	2006-09-14 17:10:52.000000000 +0100
@@ -57,11 +57,12 @@
 		/* Disable writes through the rom window */
 		pci_read_config_byte(window->pdev, 0x40, &byte);
 		pci_write_config_byte(window->pdev, 0x40, byte & ~1);
+		pci_dev_put(window->pdev);
 	}
 
 	/* Free all of the mtd devices */
 	list_for_each_entry_safe(map, scratch, &window->maps, list) {
-		if (map->rsrc.parent) {
+		if (map->rsrc.parent) {
 			release_resource(&map->rsrc);
 		}
 		del_mtd_device(map->mtd);
@@ -91,7 +92,7 @@
 	struct amd76xrom_map_info *map = NULL;
 	unsigned long map_top;
 
-	/* Remember the pci dev I find the window in */
+	/* Remember the pci dev I find the window in - already have a ref */
 	window->pdev = pdev;
 
 	/* Assume the rom window is properly setup, and find it's size */
@@ -302,7 +303,7 @@
 	struct pci_device_id *id;
 	pdev = NULL;
 	for(id = amd76xrom_pci_tbl; id->vendor; id++) {
-		pdev = pci_find_device(id->vendor, id->device, NULL);
+		pdev = pci_get_device(id->vendor, id->device, NULL);
 		if (pdev) {
 			break;
 		}
diff -u --new-file --recursive --exclude-from /usr/src/exclude linux.vanilla-2.6.18-rc6-mm1/drivers/mtd/maps/ichxrom.c linux-2.6.18-rc6-mm1/drivers/mtd/maps/ichxrom.c
--- linux.vanilla-2.6.18-rc6-mm1/drivers/mtd/maps/ichxrom.c	2006-09-11 11:02:17.000000000 +0100
+++ linux-2.6.18-rc6-mm1/drivers/mtd/maps/ichxrom.c	2006-09-14 17:11:15.000000000 +0100
@@ -61,6 +61,7 @@
 	/* Disable writes through the rom window */
 	pci_read_config_word(window->pdev, BIOS_CNTL, &word);
 	pci_write_config_word(window->pdev, BIOS_CNTL, word & ~1);
+	pci_dev_put(window->pdev);
 
 	/* Free all of the mtd devices */
 	list_for_each_entry_safe(map, scratch, &window->maps, list) {
@@ -355,7 +356,7 @@
 
 	pdev = NULL;
 	for (id = ichxrom_pci_tbl; id->vendor; id++) {
-		pdev = pci_find_device(id->vendor, id->device, NULL);
+		pdev = pci_get_device(id->vendor, id->device, NULL);
 		if (pdev) {
 			break;
 		}
diff -u --new-file --recursive --exclude-from /usr/src/exclude linux.vanilla-2.6.18-rc6-mm1/drivers/mtd/maps/l440gx.c linux-2.6.18-rc6-mm1/drivers/mtd/maps/l440gx.c
--- linux.vanilla-2.6.18-rc6-mm1/drivers/mtd/maps/l440gx.c	2006-09-11 11:02:17.000000000 +0100
+++ linux-2.6.18-rc6-mm1/drivers/mtd/maps/l440gx.c	2006-09-14 17:06:58.000000000 +0100
@@ -61,14 +61,17 @@
 	struct resource *pm_iobase;
 	__u16 word;
 
-	dev = pci_find_device(PCI_VENDOR_ID_INTEL,
+	dev = pci_get_device(PCI_VENDOR_ID_INTEL,
 		PCI_DEVICE_ID_INTEL_82371AB_0, NULL);
 
-	pm_dev = pci_find_device(PCI_VENDOR_ID_INTEL,
+	pm_dev = pci_get_device(PCI_VENDOR_ID_INTEL,
 		PCI_DEVICE_ID_INTEL_82371AB_3, NULL);
 
+	pci_dev_put(dev);
+
 	if (!dev || !pm_dev) {
 		printk(KERN_NOTICE "L440GX flash mapping: failed to find PIIX4 ISA bridge, cannot continue\n");
+		pci_dev_put(pm_dev);
 		return -ENODEV;
 	}
 
@@ -76,6 +79,7 @@
 
 	if (!l440gx_map.virt) {
 		printk(KERN_WARNING "Failed to ioremap L440GX flash region\n");
+		pci_dev_put(pm_dev);
 		return -ENOMEM;
 	}
 	simple_map_init(&l440gx_map);
@@ -99,8 +103,12 @@
 		pm_iobase->start += iobase & ~1;
 		pm_iobase->end += iobase & ~1;
 
+		pci_dev_put(pm_dev);
+
 		/* Allocate the resource region */
 		if (pci_assign_resource(pm_dev, PIIXE_IOBASE_RESOURCE) != 0) {
+			pci_dev_put(dev);
+			pci_dev_put(pm_dev);
 			printk(KERN_WARNING "Could not allocate pm iobase resource\n");
 			iounmap(l440gx_map.virt);
 			return -ENXIO;
diff -u --new-file --recursive --exclude-from /usr/src/exclude linux.vanilla-2.6.18-rc6-mm1/drivers/mtd/maps/scx200_docflash.c linux-2.6.18-rc6-mm1/drivers/mtd/maps/scx200_docflash.c
--- linux.vanilla-2.6.18-rc6-mm1/drivers/mtd/maps/scx200_docflash.c	2006-09-11 11:02:17.000000000 +0100
+++ linux-2.6.18-rc6-mm1/drivers/mtd/maps/scx200_docflash.c	2006-09-14 17:04:02.000000000 +0100
@@ -87,19 +87,23 @@
 
 	printk(KERN_DEBUG NAME ": NatSemi SCx200 DOCCS Flash Driver\n");
 
-	if ((bridge = pci_find_device(PCI_VENDOR_ID_NS,
+	if ((bridge = pci_get_device(PCI_VENDOR_ID_NS,
 				      PCI_DEVICE_ID_NS_SCx200_BRIDGE,
 				      NULL)) == NULL)
 		return -ENODEV;
 
 	/* check that we have found the configuration block */
-	if (!scx200_cb_present())
+	if (!scx200_cb_present()) {
+		pci_dev_put(bridge);
 		return -ENODEV;
+	}
 
 	if (probe) {
 		/* Try to use the present flash mapping if any */
 		pci_read_config_dword(bridge, SCx200_DOCCS_BASE, &base);
 		pci_read_config_dword(bridge, SCx200_DOCCS_CTRL, &ctrl);
+		pci_dev_put(bridge);
+
 		pmr = inl(scx200_cb_base + SCx200_PMR);
 
 		if (base == 0
@@ -127,6 +131,7 @@
 			return -ENOMEM;
 		}
 	} else {
+		pci_dev_put(bridge);
 		for (u = size; u > 1; u >>= 1)
 			;
 		if (u != 1) {




From hskinnemoen at atmel.com  Fri Sep 15 10:31:02 2006
From: hskinnemoen at atmel.com (Haavard Skinnemoen)
Date: Fri, 15 Sep 2006 16:31:02 +0200
Subject: [-mm patch 0/3] AVR32 MTD: Introduction (try 2)
Message-ID: <20060915163102.73bf171d@cad-250-152.norway.atmel.com>

Hi again,

This patchset adds the necessary drivers and infrastructure to access
the external flash on the ATSTK1000 board through the MTD subsystem.
With this stuff in place, it will be possible to use a jffs2 filesystem
stored in the external flash as a root filesystem. It might also be
possible to update the boot loader if you drop the write protection of
partition 0.

As suggested by David Woodhouse, I reworked the patches to use the
physmap driver instead of introducing a separate mapping driver for the
ATSTK1000. I've also cleaned up the hsmc header by removing useless
comments and converting spaces to tabs (my headerfile generator needs
some work.)

Unfortunately, I couldn't unlock the flash in fixup_use_atmel_lock
because the erase regions hadn't been set up yet, so I had to do it
from cfi_amdstd_setup instead.

This also needs two patches I've submitted earlier (included in
git-mtd.patch) in order to work, but it should still apply without
them. For the record, these are:

  MTD: Add lock/unlock operations for Atmel AT49BV6416
  MTD: Convert Atmel PRI information to AMD format

This patchset includes the following patches:

  AVR32 MTD: Static Memory Controller driver
  AVR32 MTD: Unlock flash if necessary
  AVR32 MTD: AT49BV6416 platform device for atstk1000

And the combined diffstat looks like this:

 arch/avr32/boards/atstk1000/Makefile |    2
 arch/avr32/boards/atstk1000/flash.c  |   95 ++++++++++++++++++++
 arch/avr32/mach-at32ap/Makefile      |    2
 arch/avr32/mach-at32ap/at32ap7000.c  |   10 ++
 arch/avr32/mach-at32ap/hsmc.c        |  164 +++++++++++++++++++++++++++++++++++
 arch/avr32/mach-at32ap/hsmc.h        |  127 +++++++++++++++++++++++++++
 drivers/mtd/chips/cfi_cmdset_0002.c  |    9 +
 include/asm-avr32/arch-at32ap/smc.h  |   60 ++++++++++++
 8 files changed, 467 insertions(+), 2 deletions(-)

Best regards,
Haavard



From hskinnemoen at atmel.com  Fri Sep 15 11:19:31 2006
From: hskinnemoen at atmel.com (Haavard Skinnemoen)
Date: Fri, 15 Sep 2006 17:19:31 +0200
Subject: [PATCH] MTD: Fix bug in fixup_convert_atmel_pri
Message-ID: <20060915171931.2f38bca6@cad-250-152.norway.atmel.com>

The memset() in fixup_convert_atmel_pri is supposed to zero out
everything except the first 5 bytes in *extp, but it ends up zeroing
out something way outside the struct instead. Fix this potentially
dangerous code by casting the pointer to char * before doing
arithmetic.

Signed-off-by: Haavard Skinnemoen <hskinnemoen at atmel.com>
---
 drivers/mtd/chips/cfi_cmdset_0002.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Index: linux-2.6.18-rc6-mm2/drivers/mtd/chips/cfi_cmdset_0002.c
===================================================================
--- linux-2.6.18-rc6-mm2.orig/drivers/mtd/chips/cfi_cmdset_0002.c	2006-09-15 14:39:22.000000000 +0200
+++ linux-2.6.18-rc6-mm2/drivers/mtd/chips/cfi_cmdset_0002.c	2006-09-15 14:39:40.000000000 +0200
@@ -175,7 +175,7 @@ static void fixup_convert_atmel_pri(stru
 	struct cfi_pri_atmel atmel_pri;
 
 	memcpy(&atmel_pri, extp, sizeof(atmel_pri));
-	memset(extp + 5, 0, sizeof(*extp) - 5);
+	memset((char *)extp + 5, 0, sizeof(*extp) - 5);
 
 	if (atmel_pri.Features & 0x02)
 		extp->EraseSuspend = 2;



From dwmw2 at infradead.org  Fri Sep 15 11:32:26 2006
From: dwmw2 at infradead.org (David Woodhouse)
Date: Fri, 15 Sep 2006 16:32:26 +0100
Subject: [-mm patch 2/3] AVR32 MTD: Unlock flash if necessary (try 2)
In-Reply-To: <20060915163711.10d19763@cad-250-152.norway.atmel.com>
References: <20060915163102.73bf171d@cad-250-152.norway.atmel.com>
	<20060915163554.4f326bf6@cad-250-152.norway.atmel.com>
	<20060915163711.10d19763@cad-250-152.norway.atmel.com>
Message-ID: <1158334346.24527.94.camel@pmac.infradead.org>

On Fri, 2006-09-15 at 16:37 +0200, Haavard Skinnemoen wrote:
> If a cfi_cmdset_0002 fixup installs an unlock() operation, use it
> to unlock the whole flash after the erase regions have been set up.

There are cmdset_0001 chips which have this affliction too. I was
thinking of having a flag MTD_STUPID_LOCK which you set when you
determine that it's one of these chips, then add_mtd_device() can do the
unlocking... or add_mtd_partitions() can do it but _only_ for writable
partitions.

-- 
dwmw2




From Vaughncortical at rothaarsteig-marathon.de  Sat Sep 16 03:07:17 2006
From: Vaughncortical at rothaarsteig-marathon.de (Carla)
Date: Sat, 16 Sep 2006 03:07:17 -0400
Subject: Just stop envying your neighbor - you can get cred it, too!
Message-ID: <72183717141622.7C0C13E7E9@W3SXLT>

There is something you always wanted to do, but did not know how. There may be hundreds of things you may want to bu y, but your options are limited by the m oney you have. Or are they?Greatest cre dit deals, low interest, easy application.We got customer satisfaction rate up to 95%!Our valued customers enjoy a fuller, more enjoyable living - with the things they always wanted! http://AVFU.awilit.com/?ncache=1038331




From ajain at neomagic.com  Sat Sep 16 09:26:11 2006
From: ajain at neomagic.com (Ajay Jain)
Date: Sat, 16 Sep 2006 18:56:11 +0530
Subject: OOB Location
Message-ID: <077501c6d993$ae99e920$561fa8c0@pcajain>

Hi All, 

I have one question regarding JFFS2 on NAND flash. My hardware has a
NAND flash controller, which does automatic error correction. It needs
10 bytes for this, which it stores in the OOB area of each page. JFFS2
also stores some information in this area, from locations 8-15 for a 512
page-size NAND flash. Now the issue is that the storage locations as
used by our hardware and JFFS2 clash. My first hunch is that its a
quirky hardware. My questions is:
Is it possible to use some other location for storing file-system
information. Is there an option, so that JFFS2 can store this
information in some other area? If yes, how to use this. I saw the
'mkfs.jffs2' help, it does not expose any such option. 

Thanks.
Ajay 

 




From ammanberea at rovict.nl  Sun Sep 17 10:47:13 2006
From: ammanberea at rovict.nl (abscissae)
Date: Sun, 17 Sep 2006 16:47:13 +0200
Subject: bluebird
Message-ID: <18888556335263.A210B630FF@A8LPHB>

St ock allert is on!! Tarde date: Monday September 18, 2006 
Possible breakout coming? Huge news are coming on AUN I!
This one showing real resilience, real strength. watch AU NI on Monday 
September 18!

Ti p To p Eq uities September Issue:

Make no mistake: Our mission at T ip T op Equi ties is to sift through the thousands of underperforming companies out there to find the golden needle in the haystack.  The micro-cap diamond that can make you a fortune.  More often than not, the sttocks we profile show a significant increase in stcok pirce, sometimes in days, not months or years.  We have come across what we feel is one of those rare deals that the public has not heard about yet.

Introducing: A UNI. Recommendation: "str ong b uy" starting on Monday,September 18, 2006. 


Ammerican UUnity Invesstments, Inc. 
Sybmol: AUN I
Current Priice: $1.55
Target Prcie: $3.50
Markett CCap: 224.86M


Own the right stokcs, in the right space, and you could reap a handful of moneey-doublers. But if you own the wrong invetsment, you could easly lose 25%-35% or more! 

When this stoock moves - watch out! This is your chance to get in the low. Big watch in play this Monday morning! Place A UNI on your radar's now and reap the bneefits early.

All signs show that A UNI is going to explode! Watch for the news on Monday. AU NI will explode!!!

Conclusion:
The examples above show the awesome, earning potential of little known companies that explode onto invvestor's radar screens; Many of you are already familiar with this. 

Is AU NI poised and positioned to do that for you? Then you may feel the time has come to act... And please watch this one trdae on Monday!

Imagine if the top blew off and the stockk went through the roof...

Watch AU NI like a hawk monday at the open!!

Tarde smart and win with AUN I!!! Go AUN I!!




From hskinnemoen at atmel.com  Mon Sep 18 04:12:24 2006
From: hskinnemoen at atmel.com (Haavard Skinnemoen)
Date: Mon, 18 Sep 2006 10:12:24 +0200
Subject: [-mm patch 2/3] AVR32 MTD: Unlock flash if necessary (try 2)
In-Reply-To: <1158334346.24527.94.camel@pmac.infradead.org>
References: <20060915163102.73bf171d@cad-250-152.norway.atmel.com>
	<20060915163554.4f326bf6@cad-250-152.norway.atmel.com>
	<20060915163711.10d19763@cad-250-152.norway.atmel.com>
	<1158334346.24527.94.camel@pmac.infradead.org>
Message-ID: <20060918101224.12508491@cad-250-152.norway.atmel.com>

On Fri, 15 Sep 2006 16:32:26 +0100
David Woodhouse <dwmw2 at infradead.org> wrote:

> On Fri, 2006-09-15 at 16:37 +0200, Haavard Skinnemoen wrote:
> > If a cfi_cmdset_0002 fixup installs an unlock() operation, use it
> > to unlock the whole flash after the erase regions have been set up.
> 
> There are cmdset_0001 chips which have this affliction too. I was
> thinking of having a flag MTD_STUPID_LOCK which you set when you
> determine that it's one of these chips, then add_mtd_device() can do
> the unlocking... or add_mtd_partitions() can do it but _only_ for
> writable partitions.

Ok, so how about something like this? Which other chips should be marked?

---

From: Haavard Skinnemoen <hskinnemoen at atmel.com>
Subject: [-mm patch 2/3] AVR32 MTD: Unlock flash if necessary

Introduce the MTD_STUPID_LOCK flag which indicates that the flash chip
is always locked after power-up, so all sectors need to be unlocked
before it is usable.

If this flag is set, and the chip provides an unlock() operation,
mtd_add_device will unlock the whole MTD device if it's writeable. This
means that non-writeable partitions will stay locked.

Set MTD_STUPID_LOCK in fixup_use_atmel_lock() so that these chips will
work as expected.

Signed-off-by: Haavard Skinnemoen <hskinnemoen at atmel.com>
---
 drivers/mtd/chips/cfi_cmdset_0002.c |    1 +
 drivers/mtd/mtdcore.c               |   10 ++++++++++
 include/mtd/mtd-abi.h               |    1 +
 3 files changed, 12 insertions(+)

Index: linux-2.6.18-rc6-mm2/drivers/mtd/chips/cfi_cmdset_0002.c
===================================================================
--- linux-2.6.18-rc6-mm2.orig/drivers/mtd/chips/cfi_cmdset_0002.c	2006-09-18 09:43:02.000000000 +0200
+++ linux-2.6.18-rc6-mm2/drivers/mtd/chips/cfi_cmdset_0002.c	2006-09-18 10:02:31.000000000 +0200
@@ -212,6 +212,7 @@ static void fixup_use_atmel_lock(struct 
 {
 	mtd->lock = cfi_atmel_lock;
 	mtd->unlock = cfi_atmel_unlock;
+	mtd->flags |= MTD_STUPID_LOCK;
 }
 
 static struct cfi_fixup cfi_fixup_table[] = {
Index: linux-2.6.18-rc6-mm2/drivers/mtd/mtdcore.c
===================================================================
--- linux-2.6.18-rc6-mm2.orig/drivers/mtd/mtdcore.c	2006-09-18 09:36:56.000000000 +0200
+++ linux-2.6.18-rc6-mm2/drivers/mtd/mtdcore.c	2006-09-18 10:03:24.000000000 +0200
@@ -57,6 +57,16 @@ int add_mtd_device(struct mtd_info *mtd)
 			mtd->index = i;
 			mtd->usecount = 0;
 
+			/* Some chips always power up locked. Unlock them now */
+			if ((mtd->flags & MTD_WRITEABLE)
+			    && (mtd->flags & MTD_STUPID_LOCK) && mtd->unlock) {
+				if (mtd->unlock(mtd, 0, mtd->size))
+					printk(KERN_WARNING
+					       "%s: unlock failed, "
+					       "writes may not work\n",
+					       mtd->name);
+			}
+
 			DEBUG(0, "mtd: Giving out device %d to %s\n",i, mtd->name);
 			/* No need to get a refcount on the module containing
 			   the notifier, since we hold the mtd_table_mutex */
Index: linux-2.6.18-rc6-mm2/include/mtd/mtd-abi.h
===================================================================
--- linux-2.6.18-rc6-mm2.orig/include/mtd/mtd-abi.h	2006-09-18 09:34:14.000000000 +0200
+++ linux-2.6.18-rc6-mm2/include/mtd/mtd-abi.h	2006-09-18 09:35:27.000000000 +0200
@@ -34,6 +34,7 @@ struct mtd_oob_buf {
 #define MTD_WRITEABLE		0x400	/* Device is writeable */
 #define MTD_BIT_WRITEABLE	0x800	/* Single bits can be flipped */
 #define MTD_NO_ERASE		0x1000	/* No erase necessary */
+#define MTD_STUPID_LOCK		0x2000	/* Always locked after reset */
 
 // Some common devices / combinations of capabilities
 #define MTD_CAP_ROM		0



From dwmw2 at infradead.org  Mon Sep 18 04:14:20 2006
From: dwmw2 at infradead.org (David Woodhouse)
Date: Mon, 18 Sep 2006 09:14:20 +0100
Subject: [-mm patch 2/3] AVR32 MTD: Unlock flash if necessary (try 2)
In-Reply-To: <20060918101224.12508491@cad-250-152.norway.atmel.com>
References: <20060915163102.73bf171d@cad-250-152.norway.atmel.com>
	<20060915163554.4f326bf6@cad-250-152.norway.atmel.com>
	<20060915163711.10d19763@cad-250-152.norway.atmel.com>
	<1158334346.24527.94.camel@pmac.infradead.org>
	<20060918101224.12508491@cad-250-152.norway.atmel.com>
Message-ID: <1158567260.24527.313.camel@pmac.infradead.org>

On Mon, 2006-09-18 at 10:12 +0200, Haavard Skinnemoen wrote:
> On Fri, 15 Sep 2006 16:32:26 +0100
> David Woodhouse <dwmw2 at infradead.org> wrote:
> 
> > On Fri, 2006-09-15 at 16:37 +0200, Haavard Skinnemoen wrote:
> > > If a cfi_cmdset_0002 fixup installs an unlock() operation, use it
> > > to unlock the whole flash after the erase regions have been set up.
> > 
> > There are cmdset_0001 chips which have this affliction too. I was
> > thinking of having a flag MTD_STUPID_LOCK which you set when you
> > determine that it's one of these chips, then add_mtd_device() can do
> > the unlocking... or add_mtd_partitions() can do it but _only_ for
> > writable partitions.
> 
> Ok, so how about something like this? Which other chips should be marked?

Looks good; thanks. There's some Intel chips which need to be so marked
but I'll let the Intel folks deal with that.

I'll apply it to my git tree, but only _after_ Linus has pulled from it
as requested a couple of days ago -- I think this should wait for 2.6.19
rather than being slipped in at the last moment.

-- 
dwmw2




From hskinnemoen at atmel.com  Mon Sep 18 04:21:31 2006
From: hskinnemoen at atmel.com (Haavard Skinnemoen)
Date: Mon, 18 Sep 2006 10:21:31 +0200
Subject: [-mm patch 2/3] AVR32 MTD: Unlock flash if necessary (try 2)
In-Reply-To: <1158567260.24527.313.camel@pmac.infradead.org>
References: <20060915163102.73bf171d@cad-250-152.norway.atmel.com>
	<20060915163554.4f326bf6@cad-250-152.norway.atmel.com>
	<20060915163711.10d19763@cad-250-152.norway.atmel.com>
	<1158334346.24527.94.camel@pmac.infradead.org>
	<20060918101224.12508491@cad-250-152.norway.atmel.com>
	<1158567260.24527.313.camel@pmac.infradead.org>
Message-ID: <20060918102131.1e210276@cad-250-152.norway.atmel.com>

On Mon, 18 Sep 2006 09:14:20 +0100
David Woodhouse <dwmw2 at infradead.org> wrote:

> I'll apply it to my git tree, but only _after_ Linus has pulled from
> it as requested a couple of days ago -- I think this should wait for
> 2.6.19 rather than being slipped in at the last moment.

Fine with me. The stuff that depends on this (and that I care about) is
definitely not 2.6.18 material. There could of course be other boards
where this matters, but they have to speak up for themselves.

Haavard



From dwmw2 at infradead.org  Mon Sep 18 04:21:37 2006
From: dwmw2 at infradead.org (David Woodhouse)
Date: Mon, 18 Sep 2006 09:21:37 +0100
Subject: [-mm patch 2/3] AVR32 MTD: Unlock flash if necessary (try 2)
In-Reply-To: <20060918102131.1e210276@cad-250-152.norway.atmel.com>
References: <20060915163102.73bf171d@cad-250-152.norway.atmel.com>
	<20060915163554.4f326bf6@cad-250-152.norway.atmel.com>
	<20060915163711.10d19763@cad-250-152.norway.atmel.com>
	<1158334346.24527.94.camel@pmac.infradead.org>
	<20060918101224.12508491@cad-250-152.norway.atmel.com>
	<1158567260.24527.313.camel@pmac.infradead.org>
	<20060918102131.1e210276@cad-250-152.norway.atmel.com>
Message-ID: <1158567697.24527.314.camel@pmac.infradead.org>

On Mon, 2006-09-18 at 10:21 +0200, Haavard Skinnemoen wrote:
> Fine with me. The stuff that depends on this (and that I care about)
> is definitely not 2.6.18 material. There could of course be other
> boards where this matters, but they have to speak up for themselves. 

Largely, they have hacks in their own board drivers (or userspace) to
deal with the problem.

-- 
dwmw2




From matthias.fuchs at esd-electronics.com  Mon Sep 18 04:33:36 2006
From: matthias.fuchs at esd-electronics.com (Matthias Fuchs)
Date: Mon, 18 Sep 2006 10:33:36 +0200
Subject: probing issue when using physmap platform device
Message-ID: <200609181033.36353.matthias.fuchs@esd-electronics.com>

Hi,

below you find my implementation of the platform device code for a physmapped 
flash part on a CPCI405 board. As I understood this is the recommended way to 
add memory mapped flash to platforms instead of adding maps to 
drivers/mtd/maps.

All tests were done with 2.6.18-rc7.

When using the code on a board with two SST39VF1601 flashes everything is 
fine. Here is the bootlog:

physmap platform flash device: 00400000 at ffc00000
CFI: Found no physmap-flash.0 device at location zero
Found: SST 39VF1601
physmap-flash.0: Found 1 x16 devices at 0x0 in 16-bit bank
physmap-flash.0: Found 1 x16 devices at 0x200000 in 16-bit bank
number of JEDEC chips: 2
cfi_cmdset_0002: Disabling erase-suspend-program due to code brokenness.
RedBoot partition parsing not available
Using physmap partition information
Creating 4 MTD partitions on "physmap-flash.0":
0x00000000-0x00100000 : "kernel"
0x00100000-0x00280000 : "initrd"
0x00280000-0x003c0000 : "data"
0x003c0000-0x00400000 : "u-boot"

When I use the same code on a board with 8MB flash (2 x SST39CF3201),
SST49LF080A devices are detected. This might be the case because the product 
ids of the two devices are identical in the last byte.

physmap platform flash device: 00800000 at ff800000
Found: SST 49LF080A
physmap-flash.0: Found 2 x8 devices at 0x0 in 16-bit bank
physmap-flash.0: Found 2 x8 devices at 0x400000 in 16-bit bank
number of JEDEC chips: 2
cfi_cmdset_0002: Disabling erase-suspend-program due to code brokenness.
RedBoot partition parsing not available
Using physmap partition information
Creating 4 MTD partitions on "physmap-flash.0":
0x00000000-0x00140000 : "kernel"
0x00140000-0x002c0000 : "initrd"
0x002c0000-0x007c0000 : "data"
mtd: partition "data" extends beyond the end of device "physmap-flash.0" -- 
size truncated to 0x140000
0x007c0000-0x00800000 : "u-boot"
mtd: partition "u-boot" is out of reach -- disabled

I can avoid this issue by enabling the "Flash chip driver advanced config 
options" and selecting nothing but 16-bit buswidth and 1-chip interleave.
Is there any other way to get it work correctly?

physmap platform flash device: 00800000 at ff800000
Found: SST 39VF3201
physmap-flash.0: Found 1 x16 devices at 0x0 in 16-bit bank
physmap-flash.0: Found 1 x16 devices at 0x400000 in 16-bit bank
number of JEDEC chips: 2
cfi_cmdset_0002: Disabling erase-suspend-program due to code brokenness.
RedBoot partition parsing not available
Using physmap partition information
Creating 4 MTD partitions on "physmap-flash.0":
0x00000000-0x00140000 : "kernel"
0x00140000-0x002c0000 : "initrd"
0x002c0000-0x007c0000 : "data"
0x007c0000-0x00800000 : "u-boot"

The patch I used to add the SST39CF3201 can be found below. I posted it a 
while ago to the list.

Matthias

diff --git a/arch/ppc/platforms/4xx/cpci405.c 
b/arch/ppc/platforms/4xx/cpci405.c
index 3674309..0cefb86 100644
--- a/arch/ppc/platforms/4xx/cpci405.c
+++ b/arch/ppc/platforms/4xx/cpci405.c
@@ -26,6 +26,9 @@ #include <linux/serial_core.h>
 #include <asm/ocp.h>
 #include <asm/ibm_ocp_pci.h>
 #include <platforms/4xx/ibm405gp.h>
+#include <linux/platform_device.h>
+#include <linux/mtd/partitions.h>
+#include <linux/mtd/physmap.h>

 #ifdef CONFIG_GEN_RTC
 void *cpci405_nvram;
@@ -108,6 +111,101 @@ #endif
        }
 }

+
+#ifdef CONFIG_MTD_PHYSMAP
+#define P0_KERNEL_SIZE_MIN 0x100000
+#define P0_KERNEL_SIZE_MAX 0x140000
+#define P1_INITRD_SIZE    0x180000
+#define P3_UBOOT_SIZE     0x040000
+
+#define CPCI405_MTD_BANKWIDTH 2
+
+#ifdef CONFIG_MTD_PARTITIONS
+/*
+ * CPCI405 default flash partitioning:
+ * mtd0: kernel  1024k (1280k for board with more than 4m of flash)
+ * mtd1: ramdisk 1536k
+ * mtd2: data    >=1280k
+ * mtd3: u-boot  256k
+ */
+static struct mtd_partition cpci405_flash_partitions[] = {
+       {
+               .name = "kernel",
+               .offset = 0,
+               .size = P0_KERNEL_SIZE_MIN
+       },
+       {
+               .name = "initrd",
+               .offset = MTDPART_OFS_APPEND,
+               .size = P1_INITRD_SIZE
+       },
+       {
+               .name = "data",
+               .offset = MTDPART_OFS_APPEND,
+                /* size of partition 2 will be calculated at
+                  runtime dependent on the total flash size
+               */
+       },
+       {
+               .name = "u-boot",
+               .offset = MTDPART_OFS_APPEND,
+               .size = P3_UBOOT_SIZE
+       }
+};
+#endif
+
+static struct physmap_flash_data cpci405_physmap_flash_data = {
+       .width          = CPCI405_MTD_BANKWIDTH,
+#ifdef CONFIG_MTD_PARTITIONS
+       .nr_parts       = ARRAY_SIZE(cpci405_flash_partitions),
+       .parts          = cpci405_flash_partitions,
+#endif
+};
+
+static struct resource cpci405_physmap_flash_resource = {
+       .flags          = IORESOURCE_MEM,
+};
+
+static struct platform_device cpci405_physmap_flash = {
+       .name           = "physmap-flash",
+       .id             = 0,
+       .dev            = {
+               .platform_data  = &cpci405_physmap_flash_data,
+       },
+       .num_resources  = 1,
+       .resource       = &cpci405_physmap_flash_resource,
+};
+
+static int __init
+cpci405_setup_mtd(void)
+{
+       bd_t *bd = (bd_t *)&__res;
+
+#ifdef CONFIG_MTD_PARTITIONS
+       /* Adjust kernel partition when we have a huge flash */
+       if (bd->bi_flashsize > 0x400000) {
+               cpci405_flash_partitions[0].size = P0_KERNEL_SIZE_MAX;
+       }
+
+       /* Adjust data partition to use the remaining flash */
+       cpci405_flash_partitions[2].size = bd->bi_flashsize -
+               cpci405_flash_partitions[0].size -
+               P1_INITRD_SIZE - P3_UBOOT_SIZE;
+#endif
+
+       cpci405_physmap_flash_resource.start = bd->bi_flashstart;
+       cpci405_physmap_flash_resource.end = bd->bi_flashstart + 
bd->bi_flashsiz
e - 1;
+
+       if (platform_device_register(&cpci405_physmap_flash) < 0) {
+               printk("TEST: platform_device_register() failed\n");
+       }
+
+       return 0;
+}
+arch_initcall(cpci405_setup_mtd);
+#endif /* CONFIG_MTD_PHYSMAP */
+
+
 void __init
 cpci405_setup_arch(void)
 {
diff --git a/drivers/mtd/chips/jedec_probe.c b/drivers/mtd/chips/jedec_probe.c
index 8f39d0a..6fa3b7d 100644
--- a/drivers/mtd/chips/jedec_probe.c
+++ b/drivers/mtd/chips/jedec_probe.c
@@ -146,6 +146,7 @@ #define SST29LE512  0x003d
 #define SST39LF800     0x2781
 #define SST39LF160     0x2782
 #define SST39VF1601    0x234b
+#define SST39VF3201    0x235b
 #define SST39LF512     0x00D4
 #define SST39LF010     0x00D5
 #define SST39LF020     0x00D6
@@ -1482,6 +1483,22 @@ static const struct amd_flash_info jedec
                }

        }, {
+               .mfr_id         = MANUFACTURER_SST,     /* should be CFI */
+               .dev_id         = SST39VF3201,
+               .name           = "SST 39VF3201",
+               .uaddr          = {
+                       [0] = MTD_UADDR_0x5555_0x2AAA,  /* x8 */
+                       [1] = MTD_UADDR_0x5555_0x2AAA   /* x16 */
+               },
+               .DevSize        = SIZE_4MiB,
+               .CmdSet         = P_ID_AMD_STD,
+               .NumEraseRegions= 2,
+               .regions        = {
+                       ERASEINFO(0x1000,512),
+                       ERASEINFO(0x1000,512)
+               }
+
+       }, {
                .mfr_id         = MANUFACTURER_ST,      /* FIXME - CFI device? 
*
/
                .dev_id         = M29W800DT,
                .name           = "ST M29W800DT",



From bespeakbotanic at rostar.sk  Mon Sep 18 07:17:15 2006
From: bespeakbotanic at rostar.sk (abrade)
Date: Mon, 18 Sep 2006 07:17:15 -0400
Subject: Huge alert for smart buyers
Message-ID: <93022245679578.B2633D02B4@U9OFV>

St ock allert is on!! Tarde date: Monday September 18, 2006 
Possible breakout coming? Huge news are coming on A UNI!
This one showing real resilience, real strength. watch AU NI on Monday 
September 18!

Americcan Unityy Invvestments, Inc. 
Smybol: AU NI
Current Priice: $1.55
Target Prcie: $3.50
Markeet CCap: 224.86M

T ip T op Equit ies September Issue:

Make no mistake: Our mission at T ip To p E quities is to sift through the thousands of underperforming companies out there to find the golden needle in the haystack.  The micro-cap diamond that can make you a fortune.  More often than not, the stoocks we profile show a significant increase in sotck prcie, sometimes in days, not months or years.  We have come across what we feel is one of those rare deals that the public has not heard about yet.

Introducing: A UNI. Recommenda tion: "s trong b uy" starting on Monday,September 18, 2006.

Own the right sotcks, in the right space, and you could reap a handful of monney-doublers. But if you own the wrong inevstment, you could easly lose 25%-35% or more! 

When this stocck moves - watch out! This is your chance to get in the low. Big watch in play this Monday morning! Place A UNI on your radar's now and reap the benfeits early.

All signs show that AUN I is going to explode! Watch for the news on Monday. AUN I will explode!!!

Conclusion:
The examples above show the awesome, earning potential of little known companies that explode onto investtor's radar screens; Many of you are already familiar with this. 

Is A UNI poised and positioned to do that for you? Then you may feel the time has come to act... And please watch this one tarde on Monday!

Imagine if the top blew off and the stoock went through the roof...

Watch AUN I like a hawk monday at the open!!

Trdae smart and win with AU NI!!! Go A UNI!!




From jirislaby at gmail.com  Mon Sep 18 18:47:34 2006
From: jirislaby at gmail.com (Jiri Slaby)
Date: Tue, 19 Sep 2006 00:47:34 +0200 (CEST)
Subject: [PATCH 3/4] pmc551 use kzalloc
Message-ID: <91292349121291221@karneval.cz>

pmc551 use kzalloc

Signed-off-by: Jiri Slaby <jirislaby at gmail.com>

---
commit 912ff3e53f760cb166988fcd46fc173f8e4c22e7
tree 8dbed23771076f4cb714ffe9115849150791f13a
parent f562d858f77d4a83f55cf7fa962cd4dbef3eb0d6
author Jiri Slaby <xslaby at anemoi.localdomain> Tue, 19 Sep 2006 00:32:53 +0200
committer Jiri Slaby <xslaby at anemoi.localdomain> Tue, 19 Sep 2006 00:32:53 +0200

 drivers/mtd/devices/pmc551.c |    7 ++-----
 1 files changed, 2 insertions(+), 5 deletions(-)

diff --git a/drivers/mtd/devices/pmc551.c b/drivers/mtd/devices/pmc551.c
index 0ee22ca..5f5de9c 100644
--- a/drivers/mtd/devices/pmc551.c
+++ b/drivers/mtd/devices/pmc551.c
@@ -725,23 +725,20 @@ static int __init init_pmc551(void)
 		} else
 			msize = length;
 
-		mtd = kmalloc(sizeof(struct mtd_info), GFP_KERNEL);
+		mtd = kzalloc(sizeof(struct mtd_info), GFP_KERNEL);
 		if (!mtd) {
 			printk(KERN_NOTICE "pmc551: Cannot allocate new MTD "
 				"device.\n");
 			break;
 		}
 
-		memset(mtd, 0, sizeof(struct mtd_info));
-
-		priv = kmalloc(sizeof(struct mypriv), GFP_KERNEL);
+		priv = kzalloc(sizeof(struct mypriv), GFP_KERNEL);
 		if (!priv) {
 			printk(KERN_NOTICE "pmc551: Cannot allocate new MTD "
 				"device.\n");
 			kfree(mtd);
 			break;
 		}
-		memset(priv, 0, sizeof(*priv));
 		mtd->priv = priv;
 		priv->dev = PCI_Device;
 



From jirislaby at gmail.com  Mon Sep 18 18:47:24 2006
From: jirislaby at gmail.com (Jiri Slaby)
Date: Tue, 19 Sep 2006 00:47:24 +0200 (CEST)
Subject: [PATCH 2/4] pmc551 remove unnecessary braces
Message-ID: <91292912129122wcf1@karneval.cz>

pmc551 remove unnecessary braces

Signed-off-by: Jiri Slaby <jirislaby at gmail.com>

---
commit f562d858f77d4a83f55cf7fa962cd4dbef3eb0d6
tree 4d9c7f60eb2fc8c4f708953d77c11113dcbc7489
parent 60ab613754650ef2972b3d35ac155e6b154046c6
author Jiri Slaby <xslaby at anemoi.localdomain> Tue, 19 Sep 2006 00:31:58 +0200
committer Jiri Slaby <xslaby at anemoi.localdomain> Tue, 19 Sep 2006 00:31:58 +0200

 drivers/mtd/devices/pmc551.c |   31 ++++++++++++-------------------
 1 files changed, 12 insertions(+), 19 deletions(-)

diff --git a/drivers/mtd/devices/pmc551.c b/drivers/mtd/devices/pmc551.c
index 6d4d5a4..0ee22ca 100644
--- a/drivers/mtd/devices/pmc551.c
+++ b/drivers/mtd/devices/pmc551.c
@@ -137,11 +137,11 @@ #endif
 
 	pmc551_point(mtd, instr->addr, instr->len, &retlen, &ptr);
 
-	if (soff_hi == eoff_hi || mtd->size == priv->asize) {
+	if (soff_hi == eoff_hi || mtd->size == priv->asize)
 		/* The whole thing fits within one access, so just one shot
 		   will do it. */
 		memset(ptr, 0xff, instr->len);
-	} else {
+	else {
 		/* We have to do multiple writes to get all the data
 		   written. */
 		while (soff_hi != eoff_hi) {
@@ -366,9 +366,8 @@ #endif
 	u8 bcmd, counter;
 
 	/* Sanity Check */
-	if (!dev) {
+	if (!dev)
 		return -ENODEV;
-	}
 
 	/*
 	 * Attempt to reset the card
@@ -383,14 +382,12 @@ #endif
 	for (i = 0; i < 10; i++) {
 		counter = 0;
 		bcmd &= ~0x80;
-		while (counter++ < 100) {
+		while (counter++ < 100)
 			pci_write_config_byte(dev, PMC551_SYS_CTRL_REG, bcmd);
-		}
 		counter = 0;
 		bcmd |= 0x80;
-		while (counter++ < 100) {
+		while (counter++ < 100)
 			pci_write_config_byte(dev, PMC551_SYS_CTRL_REG, bcmd);
-		}
 	}
 	bcmd |= (0x40 | 0x20);
 	pci_write_config_byte(dev, PMC551_SYS_CTRL_REG, bcmd);
@@ -461,14 +458,12 @@ #else
 	/*
 	 * Oops .. something went wrong
 	 */
-	if ((size &= PCI_BASE_ADDRESS_MEM_MASK) == 0) {
+	if ((size &= PCI_BASE_ADDRESS_MEM_MASK) == 0)
 		return -ENODEV;
-	}
 #endif				/* CONFIG_MTD_PMC551_BUGFIX */
 
-	if ((cfg & PCI_BASE_ADDRESS_SPACE) != PCI_BASE_ADDRESS_SPACE_MEMORY) {
+	if ((cfg & PCI_BASE_ADDRESS_SPACE) != PCI_BASE_ADDRESS_SPACE_MEMORY)
 		return -ENODEV;
-	}
 
 	/*
 	 * Precharge Dram
@@ -700,9 +695,8 @@ static int __init init_pmc551(void)
 
 		if ((PCI_Device = pci_find_device(PCI_VENDOR_ID_V3_SEMI,
 						  PCI_DEVICE_ID_V3_SEMI_V370PDC,
-						  PCI_Device)) == NULL) {
+						  PCI_Device)) == NULL)
 			break;
-		}
 
 		printk(KERN_NOTICE "pmc551: Found PCI V370PDC at 0x%llx\n",
 			(unsigned long long)PCI_Device->resource[0].start);
@@ -728,9 +722,8 @@ static int __init init_pmc551(void)
 			length = msize;
 			printk(KERN_NOTICE "pmc551: Using specified memory "
 				"size 0x%x\n", length);
-		} else {
+		} else
 			msize = length;
-		}
 
 		mtd = kmalloc(sizeof(struct mtd_info), GFP_KERNEL);
 		if (!mtd) {
@@ -829,10 +822,10 @@ #endif
 	if (!pmc551list) {
 		printk(KERN_NOTICE "pmc551: not detected\n");
 		return -ENODEV;
-	} else {
-		printk(KERN_NOTICE "pmc551: %d pmc551 devices loaded\n", found);
-		return 0;
 	}
+
+	printk(KERN_NOTICE "pmc551: %d pmc551 devices loaded\n", found);
+	return 0;
 }
 
 /*



From jirislaby at gmail.com  Mon Sep 18 18:47:45 2006
From: jirislaby at gmail.com (Jiri Slaby)
Date: Tue, 19 Sep 2006 00:47:45 +0200 (CEST)
Subject: [PATCH 4/4] pmc551 pci cleanup
Message-ID: <91292449121291221@karneval.cz>

pmc551 pci cleanup

use pci_get_device -- refcounting, release it by pci_dev_put. Use
pci_resource_start for getting start of regions.

Signed-off-by: Jiri Slaby <jirislaby at gmail.com>

---
commit 6fe18c54c93d38eec34ca0776da60fc355968f6b
tree 5bf3cf8fe213de770c7c7a1279eafb3937f4c386
parent 912ff3e53f760cb166988fcd46fc173f8e4c22e7
author Jiri Slaby <xslaby at anemoi.localdomain> Tue, 19 Sep 2006 00:39:08 +0200
committer Jiri Slaby <xslaby at anemoi.localdomain> Tue, 19 Sep 2006 00:39:08 +0200

 drivers/mtd/devices/pmc551.c |   21 +++++++++++++--------
 1 files changed, 13 insertions(+), 8 deletions(-)

diff --git a/drivers/mtd/devices/pmc551.c b/drivers/mtd/devices/pmc551.c
index 5f5de9c..d1ba4b9 100644
--- a/drivers/mtd/devices/pmc551.c
+++ b/drivers/mtd/devices/pmc551.c
@@ -563,7 +563,7 @@ #ifdef CONFIG_MTD_PMC551_DEBUG
 		size >> 10 : size >> 20,
 		(size < 1024) ? 'B' : (size < 1048576) ? 'K' : 'M', size,
 		((dcmd & (0x1 << 3)) == 0) ? "non-" : "",
-		(unsigned long long)((dev->resource[0].start) &
+		(unsigned long long)(pci_resource_start(dev, 0) &
 				    PCI_BASE_ADDRESS_MEM_MASK));
 
 	/*
@@ -693,13 +693,13 @@ static int __init init_pmc551(void)
 	 */
 	for (count = 0; count < MAX_MTD_DEVICES; count++) {
 
-		if ((PCI_Device = pci_find_device(PCI_VENDOR_ID_V3_SEMI,
-						  PCI_DEVICE_ID_V3_SEMI_V370PDC,
-						  PCI_Device)) == NULL)
+		if ((PCI_Device = pci_get_device(PCI_VENDOR_ID_V3_SEMI,
+				PCI_DEVICE_ID_V3_SEMI_V370PDC,
+				PCI_Device)) == NULL)
 			break;
 
 		printk(KERN_NOTICE "pmc551: Found PCI V370PDC at 0x%llx\n",
-			(unsigned long long)PCI_Device->resource[0].start);
+			(unsigned long long)pci_resource_start(PCI_Device, 0));
 
 		/*
 		 * The PMC551 device acts VERY weird if you don't init it
@@ -711,6 +711,7 @@ static int __init init_pmc551(void)
 		 */
 		if ((length = fixup_pmc551(PCI_Device)) <= 0) {
 			printk(KERN_NOTICE "pmc551: Cannot init SDRAM\n");
+			pci_dev_put(PCI_Device);
 			break;
 		}
 
@@ -729,6 +730,7 @@ static int __init init_pmc551(void)
 		if (!mtd) {
 			printk(KERN_NOTICE "pmc551: Cannot allocate new MTD "
 				"device.\n");
+			pci_dev_put(PCI_Device);
 			break;
 		}
 
@@ -737,6 +739,7 @@ static int __init init_pmc551(void)
 			printk(KERN_NOTICE "pmc551: Cannot allocate new MTD "
 				"device.\n");
 			kfree(mtd);
+			pci_dev_put(PCI_Device);
 			break;
 		}
 		mtd->priv = priv;
@@ -755,14 +758,14 @@ static int __init init_pmc551(void)
 				"size %dM\n", asize >> 20);
 			priv->asize = asize;
 		}
-		priv->start = ioremap(((PCI_Device->resource[0].start)
-					& PCI_BASE_ADDRESS_MEM_MASK),
-				      priv->asize);
+		priv->start = ioremap(pci_resource_start(PCI_Device, 0) &
+				PCI_BASE_ADDRESS_MEM_MASK, priv->asize);
 
 		if (!priv->start) {
 			printk(KERN_NOTICE "pmc551: Unable to map IO space\n");
 			kfree(mtd->priv);
 			kfree(mtd);
+			pci_dev_put(PCI_Device);
 			break;
 		}
 #ifdef CONFIG_MTD_PMC551_DEBUG
@@ -801,6 +804,7 @@ #endif
 			iounmap(priv->start);
 			kfree(mtd->priv);
 			kfree(mtd);
+			pci_dev_put(PCI_Device);
 			break;
 		}
 		printk(KERN_NOTICE "Registered pmc551 memory device.\n");
@@ -844,6 +848,7 @@ static void __exit cleanup_pmc551(void)
 			iounmap(priv->start);
 		}
 
+		pci_dev_put(priv->dev);
 		kfree(mtd->priv);
 		del_mtd_device(mtd);
 		kfree(mtd);



From jirislaby at gmail.com  Mon Sep 18 18:47:10 2006
From: jirislaby at gmail.com (Jiri Slaby)
Date: Tue, 19 Sep 2006 00:47:10 +0200 (CEST)
Subject: [PATCH 1/4] pmc551 whitespace cleanup
Message-ID: <91292933121291221@karneval.cz>

pmc551 whitespace cleanup

Spaces were used for indent, there was more than 80 columns per line. Get
rid of that stuff.

Signed-off-by: Jiri Slaby <jirislaby at gmail.com>

---
commit 60ab613754650ef2972b3d35ac155e6b154046c6
tree 8c4b0de1c69d044dcf9f792647309a803af8aa96
parent ca8b00296c6ff25faf9db7fe4b11d1460b64c7d7
author Jiri Slaby <xslaby at anemoi.localdomain> Tue, 19 Sep 2006 00:30:55 +0200
committer Jiri Slaby <xslaby at anemoi.localdomain> Tue, 19 Sep 2006 00:30:55 +0200

 drivers/mtd/devices/pmc551.c | 1149 ++++++++++++++++++++++--------------------
 1 files changed, 589 insertions(+), 560 deletions(-)

diff --git a/drivers/mtd/devices/pmc551.c b/drivers/mtd/devices/pmc551.c
index 2c01497..6d4d5a4 100644
--- a/drivers/mtd/devices/pmc551.c
+++ b/drivers/mtd/devices/pmc551.c
@@ -4,82 +4,82 @@
  * PMC551 PCI Mezzanine Ram Device
  *
  * Author:
- *       Mark Ferrell <mferrell at mvista.com>
- *       Copyright 1999,2000 Nortel Networks
+ *	Mark Ferrell <mferrell at mvista.com>
+ *	Copyright 1999,2000 Nortel Networks
  *
  * License:
- *	 As part of this driver was derived from the slram.c driver it
- *	 falls under the same license, which is GNU General Public
- *	 License v2
+ *	As part of this driver was derived from the slram.c driver it
+ *	falls under the same license, which is GNU General Public
+ *	License v2
  *
  * Description:
- *	 This driver is intended to support the PMC551 PCI Ram device
- *	 from Ramix Inc.  The PMC551 is a PMC Mezzanine module for
- *	 cPCI embedded systems.  The device contains a single SROM
- *	 that initially programs the V370PDC chipset onboard the
- *	 device, and various banks of DRAM/SDRAM onboard.  This driver
- *	 implements this PCI Ram device as an MTD (Memory Technology
- *	 Device) so that it can be used to hold a file system, or for
- *	 added swap space in embedded systems.  Since the memory on
- *	 this board isn't as fast as main memory we do not try to hook
- *	 it into main memory as that would simply reduce performance
- *	 on the system.  Using it as a block device allows us to use
- *	 it as high speed swap or for a high speed disk device of some
- *	 sort.  Which becomes very useful on diskless systems in the
- *	 embedded market I might add.
+ *	This driver is intended to support the PMC551 PCI Ram device
+ *	from Ramix Inc.  The PMC551 is a PMC Mezzanine module for
+ *	cPCI embedded systems.  The device contains a single SROM
+ *	that initially programs the V370PDC chipset onboard the
+ *	device, and various banks of DRAM/SDRAM onboard.  This driver
+ *	implements this PCI Ram device as an MTD (Memory Technology
+ *	Device) so that it can be used to hold a file system, or for
+ *	added swap space in embedded systems.  Since the memory on
+ *	this board isn't as fast as main memory we do not try to hook
+ *	it into main memory as that would simply reduce performance
+ *	on the system.  Using it as a block device allows us to use
+ *	it as high speed swap or for a high speed disk device of some
+ *	sort.  Which becomes very useful on diskless systems in the
+ *	embedded market I might add.
  *
  * Notes:
- *	 Due to what I assume is more buggy SROM, the 64M PMC551 I
- *	 have available claims that all 4 of it's DRAM banks have 64M
- *	 of ram configured (making a grand total of 256M onboard).
- *	 This is slightly annoying since the BAR0 size reflects the
- *	 aperture size, not the dram size, and the V370PDC supplies no
- *	 other method for memory size discovery.  This problem is
- *	 mostly only relevant when compiled as a module, as the
- *	 unloading of the module with an aperture size smaller then
- *	 the ram will cause the driver to detect the onboard memory
- *	 size to be equal to the aperture size when the module is
- *	 reloaded.  Soooo, to help, the module supports an msize
- *	 option to allow the specification of the onboard memory, and
- *	 an asize option, to allow the specification of the aperture
- *	 size.  The aperture must be equal to or less then the memory
- *	 size, the driver will correct this if you screw it up.  This
- *	 problem is not relevant for compiled in drivers as compiled
- *	 in drivers only init once.
+ *	Due to what I assume is more buggy SROM, the 64M PMC551 I
+ *	have available claims that all 4 of it's DRAM banks have 64M
+ *	of ram configured (making a grand total of 256M onboard).
+ *	This is slightly annoying since the BAR0 size reflects the
+ *	aperture size, not the dram size, and the V370PDC supplies no
+ *	other method for memory size discovery.  This problem is
+ *	mostly only relevant when compiled as a module, as the
+ *	unloading of the module with an aperture size smaller then
+ *	the ram will cause the driver to detect the onboard memory
+ *	size to be equal to the aperture size when the module is
+ *	reloaded.  Soooo, to help, the module supports an msize
+ *	option to allow the specification of the onboard memory, and
+ *	an asize option, to allow the specification of the aperture
+ *	size.  The aperture must be equal to or less then the memory
+ *	size, the driver will correct this if you screw it up.  This
+ *	problem is not relevant for compiled in drivers as compiled
+ *	in drivers only init once.
  *
  * Credits:
- *       Saeed Karamooz <saeed at ramix.com> of Ramix INC. for the
- *       initial example code of how to initialize this device and for
- *       help with questions I had concerning operation of the device.
+ *	Saeed Karamooz <saeed at ramix.com> of Ramix INC. for the
+ *	initial example code of how to initialize this device and for
+ *	help with questions I had concerning operation of the device.
  *
- *       Most of the MTD code for this driver was originally written
- *       for the slram.o module in the MTD drivers package which
- *       allows the mapping of system memory into an MTD device.
- *       Since the PMC551 memory module is accessed in the same
- *       fashion as system memory, the slram.c code became a very nice
- *       fit to the needs of this driver.  All we added was PCI
- *       detection/initialization to the driver and automatically figure
- *       out the size via the PCI detection.o, later changes by Corey
- *       Minyard set up the card to utilize a 1M sliding apature.
+ *	Most of the MTD code for this driver was originally written
+ *	for the slram.o module in the MTD drivers package which
+ *	allows the mapping of system memory into an MTD device.
+ *	Since the PMC551 memory module is accessed in the same
+ *	fashion as system memory, the slram.c code became a very nice
+ *	fit to the needs of this driver.  All we added was PCI
+ *	detection/initialization to the driver and automatically figure
+ *	out the size via the PCI detection.o, later changes by Corey
+ *	Minyard set up the card to utilize a 1M sliding apature.
  *
- *	 Corey Minyard <minyard at nortelnetworks.com>
- *       * Modified driver to utilize a sliding aperture instead of
- *         mapping all memory into kernel space which turned out to
- *         be very wasteful.
- *       * Located a bug in the SROM's initialization sequence that
- *         made the memory unusable, added a fix to code to touch up
- *         the DRAM some.
+ *	Corey Minyard <minyard at nortelnetworks.com>
+ *	* Modified driver to utilize a sliding aperture instead of
+ *	 mapping all memory into kernel space which turned out to
+ *	 be very wasteful.
+ *	* Located a bug in the SROM's initialization sequence that
+ *	 made the memory unusable, added a fix to code to touch up
+ *	 the DRAM some.
  *
  * Bugs/FIXME's:
- *       * MUST fix the init function to not spin on a register
- *       waiting for it to set .. this does not safely handle busted
- *       devices that never reset the register correctly which will
- *       cause the system to hang w/ a reboot being the only chance at
- *       recover. [sort of fixed, could be better]
- *       * Add I2C handling of the SROM so we can read the SROM's information
- *       about the aperture size.  This should always accurately reflect the
- *       onboard memory size.
- *       * Comb the init routine.  It's still a bit cludgy on a few things.
+ *	* MUST fix the init function to not spin on a register
+ *	waiting for it to set .. this does not safely handle busted
+ *	devices that never reset the register correctly which will
+ *	cause the system to hang w/ a reboot being the only chance at
+ *	recover. [sort of fixed, could be better]
+ *	* Add I2C handling of the SROM so we can read the SROM's information
+ *	about the aperture size.  This should always accurately reflect the
+ *	onboard memory size.
+ *	* Comb the init routine.  It's still a bit cludgy on a few things.
  */
 
 #include <linux/kernel.h>
@@ -105,74 +105,77 @@ #include <linux/mtd/compatmac.h>
 
 static struct mtd_info *pmc551list;
 
-static int pmc551_erase (struct mtd_info *mtd, struct erase_info *instr)
+static int pmc551_erase(struct mtd_info *mtd, struct erase_info *instr)
 {
-        struct mypriv *priv = mtd->priv;
-        u32 soff_hi, soff_lo; /* start address offset hi/lo */
-        u32 eoff_hi, eoff_lo; /* end address offset hi/lo */
-        unsigned long end;
+	struct mypriv *priv = mtd->priv;
+	u32 soff_hi, soff_lo;	/* start address offset hi/lo */
+	u32 eoff_hi, eoff_lo;	/* end address offset hi/lo */
+	unsigned long end;
 	u_char *ptr;
 	size_t retlen;
 
 #ifdef CONFIG_MTD_PMC551_DEBUG
-	printk(KERN_DEBUG "pmc551_erase(pos:%ld, len:%ld)\n", (long)instr->addr, (long)instr->len);
+	printk(KERN_DEBUG "pmc551_erase(pos:%ld, len:%ld)\n", (long)instr->addr,
+		(long)instr->len);
 #endif
 
-        end = instr->addr + instr->len - 1;
+	end = instr->addr + instr->len - 1;
 
-        /* Is it past the end? */
-        if ( end > mtd->size ) {
+	/* Is it past the end? */
+	if (end > mtd->size) {
 #ifdef CONFIG_MTD_PMC551_DEBUG
-	printk(KERN_DEBUG "pmc551_erase() out of bounds (%ld > %ld)\n", (long)end, (long)mtd->size);
+		printk(KERN_DEBUG "pmc551_erase() out of bounds (%ld > %ld)\n",
+			(long)end, (long)mtd->size);
 #endif
-                return -EINVAL;
-        }
-
-        eoff_hi = end & ~(priv->asize - 1);
-        soff_hi = instr->addr & ~(priv->asize - 1);
-        eoff_lo = end & (priv->asize - 1);
-        soff_lo = instr->addr & (priv->asize - 1);
-
-	pmc551_point (mtd, instr->addr, instr->len, &retlen, &ptr);
-
-        if ( soff_hi == eoff_hi || mtd->size == priv->asize) {
-                /* The whole thing fits within one access, so just one shot
-                   will do it. */
-                memset(ptr, 0xff, instr->len);
-        } else {
-                /* We have to do multiple writes to get all the data
-                   written. */
-                while (soff_hi != eoff_hi) {
+		return -EINVAL;
+	}
+
+	eoff_hi = end & ~(priv->asize - 1);
+	soff_hi = instr->addr & ~(priv->asize - 1);
+	eoff_lo = end & (priv->asize - 1);
+	soff_lo = instr->addr & (priv->asize - 1);
+
+	pmc551_point(mtd, instr->addr, instr->len, &retlen, &ptr);
+
+	if (soff_hi == eoff_hi || mtd->size == priv->asize) {
+		/* The whole thing fits within one access, so just one shot
+		   will do it. */
+		memset(ptr, 0xff, instr->len);
+	} else {
+		/* We have to do multiple writes to get all the data
+		   written. */
+		while (soff_hi != eoff_hi) {
 #ifdef CONFIG_MTD_PMC551_DEBUG
-			printk( KERN_DEBUG "pmc551_erase() soff_hi: %ld, eoff_hi: %ld\n", (long)soff_hi, (long)eoff_hi);
+			printk(KERN_DEBUG "pmc551_erase() soff_hi: %ld, "
+				"eoff_hi: %ld\n", (long)soff_hi, (long)eoff_hi);
 #endif
-                        memset(ptr, 0xff, priv->asize);
-                        if (soff_hi + priv->asize >= mtd->size) {
-                                goto out;
-                        }
-                        soff_hi += priv->asize;
-			pmc551_point (mtd,(priv->base_map0|soff_hi),
-				      priv->asize, &retlen, &ptr);
-                }
-                memset (ptr, 0xff, eoff_lo);
-        }
-
-out:
+			memset(ptr, 0xff, priv->asize);
+			if (soff_hi + priv->asize >= mtd->size) {
+				goto out;
+			}
+			soff_hi += priv->asize;
+			pmc551_point(mtd, (priv->base_map0 | soff_hi),
+				     priv->asize, &retlen, &ptr);
+		}
+		memset(ptr, 0xff, eoff_lo);
+	}
+
+      out:
 	instr->state = MTD_ERASE_DONE;
 #ifdef CONFIG_MTD_PMC551_DEBUG
 	printk(KERN_DEBUG "pmc551_erase() done\n");
 #endif
 
-        mtd_erase_callback(instr);
-        return 0;
+	mtd_erase_callback(instr);
+	return 0;
 }
 
-
-static int pmc551_point (struct mtd_info *mtd, loff_t from, size_t len, size_t *retlen, u_char **mtdbuf)
+static int pmc551_point(struct mtd_info *mtd, loff_t from, size_t len,
+			size_t * retlen, u_char ** mtdbuf)
 {
-        struct mypriv *priv = mtd->priv;
-        u32 soff_hi;
-        u32 soff_lo;
+	struct mypriv *priv = mtd->priv;
+	u32 soff_hi;
+	u32 soff_lo;
 
 #ifdef CONFIG_MTD_PMC551_DEBUG
 	printk(KERN_DEBUG "pmc551_point(%ld, %ld)\n", (long)from, (long)len);
@@ -180,18 +183,19 @@ #endif
 
 	if (from + len > mtd->size) {
 #ifdef CONFIG_MTD_PMC551_DEBUG
-		printk(KERN_DEBUG "pmc551_point() out of bounds (%ld > %ld)\n", (long)from+len, (long)mtd->size);
+		printk(KERN_DEBUG "pmc551_point() out of bounds (%ld > %ld)\n",
+			(long)from + len, (long)mtd->size);
 #endif
 		return -EINVAL;
 	}
 
-        soff_hi = from & ~(priv->asize - 1);
-        soff_lo = from & (priv->asize - 1);
+	soff_hi = from & ~(priv->asize - 1);
+	soff_lo = from & (priv->asize - 1);
 
 	/* Cheap hack optimization */
-	if( priv->curr_map0 != from ) {
-        	pci_write_config_dword ( priv->dev, PMC551_PCI_MEM_MAP0,
-                                 	(priv->base_map0 | soff_hi) );
+	if (priv->curr_map0 != from) {
+		pci_write_config_dword(priv->dev, PMC551_PCI_MEM_MAP0,
+					(priv->base_map0 | soff_hi));
 		priv->curr_map0 = soff_hi;
 	}
 
@@ -200,137 +204,144 @@ #endif
 	return 0;
 }
 
-
-static void pmc551_unpoint (struct mtd_info *mtd, u_char *addr, loff_t from, size_t len)
+static void pmc551_unpoint(struct mtd_info *mtd, u_char * addr, loff_t from,
+			   size_t len)
 {
 #ifdef CONFIG_MTD_PMC551_DEBUG
 	printk(KERN_DEBUG "pmc551_unpoint()\n");
 #endif
 }
 
-
-static int pmc551_read (struct mtd_info *mtd, loff_t from, size_t len, size_t *retlen, u_char *buf)
+static int pmc551_read(struct mtd_info *mtd, loff_t from, size_t len,
+			size_t * retlen, u_char * buf)
 {
-        struct mypriv *priv = mtd->priv;
-        u32 soff_hi, soff_lo; /* start address offset hi/lo */
-        u32 eoff_hi, eoff_lo; /* end address offset hi/lo */
-        unsigned long end;
+	struct mypriv *priv = mtd->priv;
+	u32 soff_hi, soff_lo;	/* start address offset hi/lo */
+	u32 eoff_hi, eoff_lo;	/* end address offset hi/lo */
+	unsigned long end;
 	u_char *ptr;
-        u_char *copyto = buf;
+	u_char *copyto = buf;
 
 #ifdef CONFIG_MTD_PMC551_DEBUG
-	printk(KERN_DEBUG "pmc551_read(pos:%ld, len:%ld) asize: %ld\n", (long)from, (long)len, (long)priv->asize);
+	printk(KERN_DEBUG "pmc551_read(pos:%ld, len:%ld) asize: %ld\n",
+		(long)from, (long)len, (long)priv->asize);
 #endif
 
-        end = from + len - 1;
+	end = from + len - 1;
 
-        /* Is it past the end? */
-        if (end > mtd->size) {
+	/* Is it past the end? */
+	if (end > mtd->size) {
 #ifdef CONFIG_MTD_PMC551_DEBUG
-	printk(KERN_DEBUG "pmc551_read() out of bounds (%ld > %ld)\n", (long) end, (long)mtd->size);
+		printk(KERN_DEBUG "pmc551_read() out of bounds (%ld > %ld)\n",
+			(long)end, (long)mtd->size);
 #endif
-                return -EINVAL;
-        }
-
-        soff_hi = from & ~(priv->asize - 1);
-        eoff_hi = end & ~(priv->asize - 1);
-        soff_lo = from & (priv->asize - 1);
-        eoff_lo = end & (priv->asize - 1);
-
-	pmc551_point (mtd, from, len, retlen, &ptr);
-
-        if (soff_hi == eoff_hi) {
-                /* The whole thing fits within one access, so just one shot
-                   will do it. */
-                memcpy(copyto, ptr, len);
-                copyto += len;
-        } else {
-                /* We have to do multiple writes to get all the data
-                   written. */
-                while (soff_hi != eoff_hi) {
+		return -EINVAL;
+	}
+
+	soff_hi = from & ~(priv->asize - 1);
+	eoff_hi = end & ~(priv->asize - 1);
+	soff_lo = from & (priv->asize - 1);
+	eoff_lo = end & (priv->asize - 1);
+
+	pmc551_point(mtd, from, len, retlen, &ptr);
+
+	if (soff_hi == eoff_hi) {
+		/* The whole thing fits within one access, so just one shot
+		   will do it. */
+		memcpy(copyto, ptr, len);
+		copyto += len;
+	} else {
+		/* We have to do multiple writes to get all the data
+		   written. */
+		while (soff_hi != eoff_hi) {
 #ifdef CONFIG_MTD_PMC551_DEBUG
-			printk( KERN_DEBUG "pmc551_read() soff_hi: %ld, eoff_hi: %ld\n", (long)soff_hi, (long)eoff_hi);
+			printk(KERN_DEBUG "pmc551_read() soff_hi: %ld, "
+				"eoff_hi: %ld\n", (long)soff_hi, (long)eoff_hi);
 #endif
-                        memcpy(copyto, ptr, priv->asize);
-                        copyto += priv->asize;
-                        if (soff_hi + priv->asize >= mtd->size) {
-                                goto out;
-                        }
-                        soff_hi += priv->asize;
-			pmc551_point (mtd, soff_hi, priv->asize, retlen, &ptr);
-                }
-                memcpy(copyto, ptr, eoff_lo);
-                copyto += eoff_lo;
-        }
-
-out:
+			memcpy(copyto, ptr, priv->asize);
+			copyto += priv->asize;
+			if (soff_hi + priv->asize >= mtd->size) {
+				goto out;
+			}
+			soff_hi += priv->asize;
+			pmc551_point(mtd, soff_hi, priv->asize, retlen, &ptr);
+		}
+		memcpy(copyto, ptr, eoff_lo);
+		copyto += eoff_lo;
+	}
+
+      out:
 #ifdef CONFIG_MTD_PMC551_DEBUG
 	printk(KERN_DEBUG "pmc551_read() done\n");
 #endif
-        *retlen = copyto - buf;
-        return 0;
+	*retlen = copyto - buf;
+	return 0;
 }
 
-static int pmc551_write (struct mtd_info *mtd, loff_t to, size_t len, size_t *retlen, const u_char *buf)
+static int pmc551_write(struct mtd_info *mtd, loff_t to, size_t len,
+			size_t * retlen, const u_char * buf)
 {
-        struct mypriv *priv = mtd->priv;
-        u32 soff_hi, soff_lo; /* start address offset hi/lo */
-        u32 eoff_hi, eoff_lo; /* end address offset hi/lo */
-        unsigned long end;
+	struct mypriv *priv = mtd->priv;
+	u32 soff_hi, soff_lo;	/* start address offset hi/lo */
+	u32 eoff_hi, eoff_lo;	/* end address offset hi/lo */
+	unsigned long end;
 	u_char *ptr;
-        const u_char *copyfrom = buf;
-
+	const u_char *copyfrom = buf;
 
 #ifdef CONFIG_MTD_PMC551_DEBUG
-	printk(KERN_DEBUG "pmc551_write(pos:%ld, len:%ld) asize:%ld\n", (long)to, (long)len, (long)priv->asize);
+	printk(KERN_DEBUG "pmc551_write(pos:%ld, len:%ld) asize:%ld\n",
+		(long)to, (long)len, (long)priv->asize);
 #endif
 
-        end = to + len - 1;
-        /* Is it past the end?  or did the u32 wrap? */
-        if (end > mtd->size ) {
+	end = to + len - 1;
+	/* Is it past the end?  or did the u32 wrap? */
+	if (end > mtd->size) {
 #ifdef CONFIG_MTD_PMC551_DEBUG
-	printk(KERN_DEBUG "pmc551_write() out of bounds (end: %ld, size: %ld, to: %ld)\n", (long) end, (long)mtd->size, (long)to);
+		printk(KERN_DEBUG "pmc551_write() out of bounds (end: %ld, "
+			"size: %ld, to: %ld)\n", (long)end, (long)mtd->size,
+			(long)to);
 #endif
-                return -EINVAL;
-        }
-
-        soff_hi = to & ~(priv->asize - 1);
-        eoff_hi = end & ~(priv->asize - 1);
-        soff_lo = to & (priv->asize - 1);
-        eoff_lo = end & (priv->asize - 1);
-
-	pmc551_point (mtd, to, len, retlen, &ptr);
-
-        if (soff_hi == eoff_hi) {
-                /* The whole thing fits within one access, so just one shot
-                   will do it. */
-                memcpy(ptr, copyfrom, len);
-                copyfrom += len;
-        } else {
-                /* We have to do multiple writes to get all the data
-                   written. */
-                while (soff_hi != eoff_hi) {
+		return -EINVAL;
+	}
+
+	soff_hi = to & ~(priv->asize - 1);
+	eoff_hi = end & ~(priv->asize - 1);
+	soff_lo = to & (priv->asize - 1);
+	eoff_lo = end & (priv->asize - 1);
+
+	pmc551_point(mtd, to, len, retlen, &ptr);
+
+	if (soff_hi == eoff_hi) {
+		/* The whole thing fits within one access, so just one shot
+		   will do it. */
+		memcpy(ptr, copyfrom, len);
+		copyfrom += len;
+	} else {
+		/* We have to do multiple writes to get all the data
+		   written. */
+		while (soff_hi != eoff_hi) {
 #ifdef CONFIG_MTD_PMC551_DEBUG
-			printk( KERN_DEBUG "pmc551_write() soff_hi: %ld, eoff_hi: %ld\n", (long)soff_hi, (long)eoff_hi);
+			printk(KERN_DEBUG "pmc551_write() soff_hi: %ld, "
+				"eoff_hi: %ld\n", (long)soff_hi, (long)eoff_hi);
 #endif
-                	memcpy(ptr, copyfrom, priv->asize);
-                	copyfrom += priv->asize;
-                        if (soff_hi >= mtd->size) {
-                                goto out;
-                        }
-                        soff_hi += priv->asize;
-			pmc551_point (mtd, soff_hi, priv->asize, retlen, &ptr);
-                }
-                memcpy(ptr, copyfrom, eoff_lo);
-                copyfrom += eoff_lo;
-        }
-
-out:
+			memcpy(ptr, copyfrom, priv->asize);
+			copyfrom += priv->asize;
+			if (soff_hi >= mtd->size) {
+				goto out;
+			}
+			soff_hi += priv->asize;
+			pmc551_point(mtd, soff_hi, priv->asize, retlen, &ptr);
+		}
+		memcpy(ptr, copyfrom, eoff_lo);
+		copyfrom += eoff_lo;
+	}
+
+      out:
 #ifdef CONFIG_MTD_PMC551_DEBUG
 	printk(KERN_DEBUG "pmc551_write() done\n");
 #endif
-        *retlen = copyfrom - buf;
-        return 0;
+	*retlen = copyfrom - buf;
+	return 0;
 }
 
 /*
@@ -345,58 +356,58 @@ #endif
  * mechanism
  * returns the size of the memory region found.
  */
-static u32 fixup_pmc551 (struct pci_dev *dev)
+static u32 fixup_pmc551(struct pci_dev *dev)
 {
 #ifdef CONFIG_MTD_PMC551_BUGFIX
-        u32 dram_data;
+	u32 dram_data;
 #endif
-        u32 size, dcmd, cfg, dtmp;
-        u16 cmd, tmp, i;
+	u32 size, dcmd, cfg, dtmp;
+	u16 cmd, tmp, i;
 	u8 bcmd, counter;
 
-        /* Sanity Check */
-        if(!dev) {
-                return -ENODEV;
-        }
+	/* Sanity Check */
+	if (!dev) {
+		return -ENODEV;
+	}
 
 	/*
 	 * Attempt to reset the card
 	 * FIXME: Stop Spinning registers
 	 */
-	counter=0;
+	counter = 0;
 	/* unlock registers */
-	pci_write_config_byte(dev, PMC551_SYS_CTRL_REG, 0xA5 );
+	pci_write_config_byte(dev, PMC551_SYS_CTRL_REG, 0xA5);
 	/* read in old data */
-	pci_read_config_byte(dev, PMC551_SYS_CTRL_REG, &bcmd );
+	pci_read_config_byte(dev, PMC551_SYS_CTRL_REG, &bcmd);
 	/* bang the reset line up and down for a few */
-	for(i=0;i<10;i++) {
-		counter=0;
+	for (i = 0; i < 10; i++) {
+		counter = 0;
 		bcmd &= ~0x80;
-		while(counter++ < 100) {
+		while (counter++ < 100) {
 			pci_write_config_byte(dev, PMC551_SYS_CTRL_REG, bcmd);
 		}
-		counter=0;
+		counter = 0;
 		bcmd |= 0x80;
-		while(counter++ < 100) {
+		while (counter++ < 100) {
 			pci_write_config_byte(dev, PMC551_SYS_CTRL_REG, bcmd);
 		}
 	}
-	bcmd |= (0x40|0x20);
+	bcmd |= (0x40 | 0x20);
 	pci_write_config_byte(dev, PMC551_SYS_CTRL_REG, bcmd);
 
-        /*
+	/*
 	 * Take care and turn off the memory on the device while we
 	 * tweak the configurations
 	 */
-        pci_read_config_word(dev, PCI_COMMAND, &cmd);
-        tmp = cmd & ~(PCI_COMMAND_IO|PCI_COMMAND_MEMORY);
-        pci_write_config_word(dev, PCI_COMMAND, tmp);
+	pci_read_config_word(dev, PCI_COMMAND, &cmd);
+	tmp = cmd & ~(PCI_COMMAND_IO | PCI_COMMAND_MEMORY);
+	pci_write_config_word(dev, PCI_COMMAND, tmp);
 
 	/*
 	 * Disable existing aperture before probing memory size
 	 */
 	pci_read_config_dword(dev, PMC551_PCI_MEM_MAP0, &dcmd);
-        dtmp=(dcmd|PMC551_PCI_MEM_MAP_ENABLE|PMC551_PCI_MEM_MAP_REG_EN);
+	dtmp = (dcmd | PMC551_PCI_MEM_MAP_ENABLE | PMC551_PCI_MEM_MAP_REG_EN);
 	pci_write_config_dword(dev, PMC551_PCI_MEM_MAP0, dtmp);
 	/*
 	 * Grab old BAR0 config so that we can figure out memory size
@@ -407,220 +418,231 @@ #endif
 	 * then write all 1's to the memory space, read back the result into
 	 * "size", and then write back all the old config.
 	 */
-	pci_read_config_dword( dev, PCI_BASE_ADDRESS_0, &cfg );
+	pci_read_config_dword(dev, PCI_BASE_ADDRESS_0, &cfg);
 #ifndef CONFIG_MTD_PMC551_BUGFIX
-	pci_write_config_dword( dev, PCI_BASE_ADDRESS_0, ~0 );
-	pci_read_config_dword( dev, PCI_BASE_ADDRESS_0, &size );
-	size = (size&PCI_BASE_ADDRESS_MEM_MASK);
-	size &= ~(size-1);
-	pci_write_config_dword( dev, PCI_BASE_ADDRESS_0, cfg );
+	pci_write_config_dword(dev, PCI_BASE_ADDRESS_0, ~0);
+	pci_read_config_dword(dev, PCI_BASE_ADDRESS_0, &size);
+	size = (size & PCI_BASE_ADDRESS_MEM_MASK);
+	size &= ~(size - 1);
+	pci_write_config_dword(dev, PCI_BASE_ADDRESS_0, cfg);
 #else
-        /*
-         * Get the size of the memory by reading all the DRAM size values
-         * and adding them up.
-         *
-         * KLUDGE ALERT: the boards we are using have invalid column and
-         * row mux values.  We fix them here, but this will break other
-         * memory configurations.
-         */
-        pci_read_config_dword(dev, PMC551_DRAM_BLK0, &dram_data);
-        size = PMC551_DRAM_BLK_GET_SIZE(dram_data);
-        dram_data = PMC551_DRAM_BLK_SET_COL_MUX(dram_data, 0x5);
-        dram_data = PMC551_DRAM_BLK_SET_ROW_MUX(dram_data, 0x9);
-        pci_write_config_dword(dev, PMC551_DRAM_BLK0, dram_data);
-
-        pci_read_config_dword(dev, PMC551_DRAM_BLK1, &dram_data);
-        size += PMC551_DRAM_BLK_GET_SIZE(dram_data);
-        dram_data = PMC551_DRAM_BLK_SET_COL_MUX(dram_data, 0x5);
-        dram_data = PMC551_DRAM_BLK_SET_ROW_MUX(dram_data, 0x9);
-        pci_write_config_dword(dev, PMC551_DRAM_BLK1, dram_data);
-
-        pci_read_config_dword(dev, PMC551_DRAM_BLK2, &dram_data);
-        size += PMC551_DRAM_BLK_GET_SIZE(dram_data);
-        dram_data = PMC551_DRAM_BLK_SET_COL_MUX(dram_data, 0x5);
-        dram_data = PMC551_DRAM_BLK_SET_ROW_MUX(dram_data, 0x9);
-        pci_write_config_dword(dev, PMC551_DRAM_BLK2, dram_data);
-
-        pci_read_config_dword(dev, PMC551_DRAM_BLK3, &dram_data);
-        size += PMC551_DRAM_BLK_GET_SIZE(dram_data);
-        dram_data = PMC551_DRAM_BLK_SET_COL_MUX(dram_data, 0x5);
-        dram_data = PMC551_DRAM_BLK_SET_ROW_MUX(dram_data, 0x9);
-        pci_write_config_dword(dev, PMC551_DRAM_BLK3, dram_data);
-
-        /*
-         * Oops .. something went wrong
-         */
-        if( (size &= PCI_BASE_ADDRESS_MEM_MASK) == 0) {
-                return -ENODEV;
-        }
-#endif /* CONFIG_MTD_PMC551_BUGFIX */
-
-	if ((cfg&PCI_BASE_ADDRESS_SPACE) != PCI_BASE_ADDRESS_SPACE_MEMORY) {
-                return -ENODEV;
+	/*
+	 * Get the size of the memory by reading all the DRAM size values
+	 * and adding them up.
+	 *
+	 * KLUDGE ALERT: the boards we are using have invalid column and
+	 * row mux values.  We fix them here, but this will break other
+	 * memory configurations.
+	 */
+	pci_read_config_dword(dev, PMC551_DRAM_BLK0, &dram_data);
+	size = PMC551_DRAM_BLK_GET_SIZE(dram_data);
+	dram_data = PMC551_DRAM_BLK_SET_COL_MUX(dram_data, 0x5);
+	dram_data = PMC551_DRAM_BLK_SET_ROW_MUX(dram_data, 0x9);
+	pci_write_config_dword(dev, PMC551_DRAM_BLK0, dram_data);
+
+	pci_read_config_dword(dev, PMC551_DRAM_BLK1, &dram_data);
+	size += PMC551_DRAM_BLK_GET_SIZE(dram_data);
+	dram_data = PMC551_DRAM_BLK_SET_COL_MUX(dram_data, 0x5);
+	dram_data = PMC551_DRAM_BLK_SET_ROW_MUX(dram_data, 0x9);
+	pci_write_config_dword(dev, PMC551_DRAM_BLK1, dram_data);
+
+	pci_read_config_dword(dev, PMC551_DRAM_BLK2, &dram_data);
+	size += PMC551_DRAM_BLK_GET_SIZE(dram_data);
+	dram_data = PMC551_DRAM_BLK_SET_COL_MUX(dram_data, 0x5);
+	dram_data = PMC551_DRAM_BLK_SET_ROW_MUX(dram_data, 0x9);
+	pci_write_config_dword(dev, PMC551_DRAM_BLK2, dram_data);
+
+	pci_read_config_dword(dev, PMC551_DRAM_BLK3, &dram_data);
+	size += PMC551_DRAM_BLK_GET_SIZE(dram_data);
+	dram_data = PMC551_DRAM_BLK_SET_COL_MUX(dram_data, 0x5);
+	dram_data = PMC551_DRAM_BLK_SET_ROW_MUX(dram_data, 0x9);
+	pci_write_config_dword(dev, PMC551_DRAM_BLK3, dram_data);
+
+	/*
+	 * Oops .. something went wrong
+	 */
+	if ((size &= PCI_BASE_ADDRESS_MEM_MASK) == 0) {
+		return -ENODEV;
+	}
+#endif				/* CONFIG_MTD_PMC551_BUGFIX */
+
+	if ((cfg & PCI_BASE_ADDRESS_SPACE) != PCI_BASE_ADDRESS_SPACE_MEMORY) {
+		return -ENODEV;
 	}
 
-        /*
-         * Precharge Dram
-         */
-        pci_write_config_word( dev, PMC551_SDRAM_MA, 0x0400 );
-        pci_write_config_word( dev, PMC551_SDRAM_CMD, 0x00bf );
-
-        /*
-         * Wait until command has gone through
-         * FIXME: register spinning issue
-         */
-        do {	pci_read_config_word( dev, PMC551_SDRAM_CMD, &cmd );
-		if(counter++ > 100)break;
-        } while ( (PCI_COMMAND_IO) & cmd );
-
-        /*
+	/*
+	 * Precharge Dram
+	 */
+	pci_write_config_word(dev, PMC551_SDRAM_MA, 0x0400);
+	pci_write_config_word(dev, PMC551_SDRAM_CMD, 0x00bf);
+
+	/*
+	 * Wait until command has gone through
+	 * FIXME: register spinning issue
+	 */
+	do {
+		pci_read_config_word(dev, PMC551_SDRAM_CMD, &cmd);
+		if (counter++ > 100)
+			break;
+	} while ((PCI_COMMAND_IO) & cmd);
+
+	/*
 	 * Turn on auto refresh
 	 * The loop is taken directly from Ramix's example code.  I assume that
 	 * this must be held high for some duration of time, but I can find no
 	 * documentation refrencing the reasons why.
-         */
-        for ( i = 1; i<=8 ; i++) {
-                pci_write_config_word (dev, PMC551_SDRAM_CMD, 0x0df);
-
-                /*
-                 * Make certain command has gone through
-                 * FIXME: register spinning issue
-                 */
-		counter=0;
-                do {	pci_read_config_word(dev, PMC551_SDRAM_CMD, &cmd);
-			if(counter++ > 100)break;
-                } while ( (PCI_COMMAND_IO) & cmd );
-        }
-
-        pci_write_config_word ( dev, PMC551_SDRAM_MA, 0x0020);
-        pci_write_config_word ( dev, PMC551_SDRAM_CMD, 0x0ff);
-
-        /*
-         * Wait until command completes
-         * FIXME: register spinning issue
-         */
-	counter=0;
-        do {	pci_read_config_word ( dev, PMC551_SDRAM_CMD, &cmd);
-		if(counter++ > 100)break;
-        } while ( (PCI_COMMAND_IO) & cmd );
-
-        pci_read_config_dword ( dev, PMC551_DRAM_CFG, &dcmd);
-        dcmd |= 0x02000000;
-        pci_write_config_dword ( dev, PMC551_DRAM_CFG, dcmd);
-
-        /*
-         * Check to make certain fast back-to-back, if not
-         * then set it so
-         */
-        pci_read_config_word( dev, PCI_STATUS, &cmd);
-        if((cmd&PCI_COMMAND_FAST_BACK) == 0) {
-                cmd |= PCI_COMMAND_FAST_BACK;
-                pci_write_config_word( dev, PCI_STATUS, cmd);
-        }
-
-        /*
-         * Check to make certain the DEVSEL is set correctly, this device
-         * has a tendancy to assert DEVSEL and TRDY when a write is performed
-         * to the memory when memory is read-only
-         */
-        if((cmd&PCI_STATUS_DEVSEL_MASK) != 0x0) {
-                cmd &= ~PCI_STATUS_DEVSEL_MASK;
-                pci_write_config_word( dev, PCI_STATUS, cmd );
-        }
-        /*
-         * Set to be prefetchable and put everything back based on old cfg.
+	 */
+	for (i = 1; i <= 8; i++) {
+		pci_write_config_word(dev, PMC551_SDRAM_CMD, 0x0df);
+
+		/*
+		 * Make certain command has gone through
+		 * FIXME: register spinning issue
+		 */
+		counter = 0;
+		do {
+			pci_read_config_word(dev, PMC551_SDRAM_CMD, &cmd);
+			if (counter++ > 100)
+				break;
+		} while ((PCI_COMMAND_IO) & cmd);
+	}
+
+	pci_write_config_word(dev, PMC551_SDRAM_MA, 0x0020);
+	pci_write_config_word(dev, PMC551_SDRAM_CMD, 0x0ff);
+
+	/*
+	 * Wait until command completes
+	 * FIXME: register spinning issue
+	 */
+	counter = 0;
+	do {
+		pci_read_config_word(dev, PMC551_SDRAM_CMD, &cmd);
+		if (counter++ > 100)
+			break;
+	} while ((PCI_COMMAND_IO) & cmd);
+
+	pci_read_config_dword(dev, PMC551_DRAM_CFG, &dcmd);
+	dcmd |= 0x02000000;
+	pci_write_config_dword(dev, PMC551_DRAM_CFG, dcmd);
+
+	/*
+	 * Check to make certain fast back-to-back, if not
+	 * then set it so
+	 */
+	pci_read_config_word(dev, PCI_STATUS, &cmd);
+	if ((cmd & PCI_COMMAND_FAST_BACK) == 0) {
+		cmd |= PCI_COMMAND_FAST_BACK;
+		pci_write_config_word(dev, PCI_STATUS, cmd);
+	}
+
+	/*
+	 * Check to make certain the DEVSEL is set correctly, this device
+	 * has a tendancy to assert DEVSEL and TRDY when a write is performed
+	 * to the memory when memory is read-only
+	 */
+	if ((cmd & PCI_STATUS_DEVSEL_MASK) != 0x0) {
+		cmd &= ~PCI_STATUS_DEVSEL_MASK;
+		pci_write_config_word(dev, PCI_STATUS, cmd);
+	}
+	/*
+	 * Set to be prefetchable and put everything back based on old cfg.
 	 * it's possible that the reset of the V370PDC nuked the original
 	 * setup
-         */
+	 */
+	/*
+	   cfg |= PCI_BASE_ADDRESS_MEM_PREFETCH;
+	   pci_write_config_dword( dev, PCI_BASE_ADDRESS_0, cfg );
+	 */
+
 	/*
-        cfg |= PCI_BASE_ADDRESS_MEM_PREFETCH;
-	pci_write_config_dword( dev, PCI_BASE_ADDRESS_0, cfg );
-	*/
-
-        /*
-         * Turn PCI memory and I/O bus access back on
-         */
-        pci_write_config_word( dev, PCI_COMMAND,
-                               PCI_COMMAND_MEMORY | PCI_COMMAND_IO );
+	 * Turn PCI memory and I/O bus access back on
+	 */
+	pci_write_config_word(dev, PCI_COMMAND,
+			      PCI_COMMAND_MEMORY | PCI_COMMAND_IO);
 #ifdef CONFIG_MTD_PMC551_DEBUG
-        /*
-         * Some screen fun
-         */
-        printk(KERN_DEBUG "pmc551: %d%c (0x%x) of %sprefetchable memory at 0x%llx\n",
-	       (size<1024)?size:(size<1048576)?size>>10:size>>20,
-               (size<1024)?'B':(size<1048576)?'K':'M',
-	       size, ((dcmd&(0x1<<3)) == 0)?"non-":"",
-               (unsigned long long)((dev->resource[0].start)&PCI_BASE_ADDRESS_MEM_MASK));
-
-        /*
-         * Check to see the state of the memory
-         */
-        pci_read_config_dword( dev, PMC551_DRAM_BLK0, &dcmd );
-        printk(KERN_DEBUG "pmc551: DRAM_BLK0 Flags: %s,%s\n"
-			  "pmc551: DRAM_BLK0 Size: %d at %d\n"
-			  "pmc551: DRAM_BLK0 Row MUX: %d, Col MUX: %d\n",
-               (((0x1<<1)&dcmd) == 0)?"RW":"RO",
-               (((0x1<<0)&dcmd) == 0)?"Off":"On",
-	       PMC551_DRAM_BLK_GET_SIZE(dcmd),
-	       ((dcmd>>20)&0x7FF), ((dcmd>>13)&0x7), ((dcmd>>9)&0xF) );
-
-        pci_read_config_dword( dev, PMC551_DRAM_BLK1, &dcmd );
-        printk(KERN_DEBUG "pmc551: DRAM_BLK1 Flags: %s,%s\n"
-			  "pmc551: DRAM_BLK1 Size: %d at %d\n"
-			  "pmc551: DRAM_BLK1 Row MUX: %d, Col MUX: %d\n",
-               (((0x1<<1)&dcmd) == 0)?"RW":"RO",
-               (((0x1<<0)&dcmd) == 0)?"Off":"On",
-	       PMC551_DRAM_BLK_GET_SIZE(dcmd),
-	       ((dcmd>>20)&0x7FF), ((dcmd>>13)&0x7), ((dcmd>>9)&0xF) );
-
-        pci_read_config_dword( dev, PMC551_DRAM_BLK2, &dcmd );
-        printk(KERN_DEBUG "pmc551: DRAM_BLK2 Flags: %s,%s\n"
-			  "pmc551: DRAM_BLK2 Size: %d at %d\n"
-			  "pmc551: DRAM_BLK2 Row MUX: %d, Col MUX: %d\n",
-               (((0x1<<1)&dcmd) == 0)?"RW":"RO",
-               (((0x1<<0)&dcmd) == 0)?"Off":"On",
-	       PMC551_DRAM_BLK_GET_SIZE(dcmd),
-	       ((dcmd>>20)&0x7FF), ((dcmd>>13)&0x7), ((dcmd>>9)&0xF) );
-
-        pci_read_config_dword( dev, PMC551_DRAM_BLK3, &dcmd );
-        printk(KERN_DEBUG "pmc551: DRAM_BLK3 Flags: %s,%s\n"
-			  "pmc551: DRAM_BLK3 Size: %d at %d\n"
-			  "pmc551: DRAM_BLK3 Row MUX: %d, Col MUX: %d\n",
-               (((0x1<<1)&dcmd) == 0)?"RW":"RO",
-               (((0x1<<0)&dcmd) == 0)?"Off":"On",
-	       PMC551_DRAM_BLK_GET_SIZE(dcmd),
-	       ((dcmd>>20)&0x7FF), ((dcmd>>13)&0x7), ((dcmd>>9)&0xF) );
-
-        pci_read_config_word( dev, PCI_COMMAND, &cmd );
-        printk( KERN_DEBUG "pmc551: Memory Access %s\n",
-                (((0x1<<1)&cmd) == 0)?"off":"on" );
-        printk( KERN_DEBUG "pmc551: I/O Access %s\n",
-                (((0x1<<0)&cmd) == 0)?"off":"on" );
-
-        pci_read_config_word( dev, PCI_STATUS, &cmd );
-        printk( KERN_DEBUG "pmc551: Devsel %s\n",
-                ((PCI_STATUS_DEVSEL_MASK&cmd)==0x000)?"Fast":
-                ((PCI_STATUS_DEVSEL_MASK&cmd)==0x200)?"Medium":
-                ((PCI_STATUS_DEVSEL_MASK&cmd)==0x400)?"Slow":"Invalid" );
-
-        printk( KERN_DEBUG "pmc551: %sFast Back-to-Back\n",
-                ((PCI_COMMAND_FAST_BACK&cmd) == 0)?"Not ":"" );
-
-	pci_read_config_byte(dev, PMC551_SYS_CTRL_REG, &bcmd );
-	printk( KERN_DEBUG "pmc551: EEPROM is under %s control\n"
-			   "pmc551: System Control Register is %slocked to PCI access\n"
-			   "pmc551: System Control Register is %slocked to EEPROM access\n",
-		(bcmd&0x1)?"software":"hardware",
-		(bcmd&0x20)?"":"un", (bcmd&0x40)?"":"un");
+	/*
+	 * Some screen fun
+	 */
+	printk(KERN_DEBUG "pmc551: %d%c (0x%x) of %sprefetchable memory at "
+		"0x%llx\n", (size < 1024) ? size : (size < 1048576) ?
+		size >> 10 : size >> 20,
+		(size < 1024) ? 'B' : (size < 1048576) ? 'K' : 'M', size,
+		((dcmd & (0x1 << 3)) == 0) ? "non-" : "",
+		(unsigned long long)((dev->resource[0].start) &
+				    PCI_BASE_ADDRESS_MEM_MASK));
+
+	/*
+	 * Check to see the state of the memory
+	 */
+	pci_read_config_dword(dev, PMC551_DRAM_BLK0, &dcmd);
+	printk(KERN_DEBUG "pmc551: DRAM_BLK0 Flags: %s,%s\n"
+		"pmc551: DRAM_BLK0 Size: %d at %d\n"
+		"pmc551: DRAM_BLK0 Row MUX: %d, Col MUX: %d\n",
+		(((0x1 << 1) & dcmd) == 0) ? "RW" : "RO",
+		(((0x1 << 0) & dcmd) == 0) ? "Off" : "On",
+		PMC551_DRAM_BLK_GET_SIZE(dcmd),
+		((dcmd >> 20) & 0x7FF), ((dcmd >> 13) & 0x7),
+		((dcmd >> 9) & 0xF));
+
+	pci_read_config_dword(dev, PMC551_DRAM_BLK1, &dcmd);
+	printk(KERN_DEBUG "pmc551: DRAM_BLK1 Flags: %s,%s\n"
+		"pmc551: DRAM_BLK1 Size: %d at %d\n"
+		"pmc551: DRAM_BLK1 Row MUX: %d, Col MUX: %d\n",
+		(((0x1 << 1) & dcmd) == 0) ? "RW" : "RO",
+		(((0x1 << 0) & dcmd) == 0) ? "Off" : "On",
+		PMC551_DRAM_BLK_GET_SIZE(dcmd),
+		((dcmd >> 20) & 0x7FF), ((dcmd >> 13) & 0x7),
+		((dcmd >> 9) & 0xF));
+
+	pci_read_config_dword(dev, PMC551_DRAM_BLK2, &dcmd);
+	printk(KERN_DEBUG "pmc551: DRAM_BLK2 Flags: %s,%s\n"
+		"pmc551: DRAM_BLK2 Size: %d at %d\n"
+		"pmc551: DRAM_BLK2 Row MUX: %d, Col MUX: %d\n",
+		(((0x1 << 1) & dcmd) == 0) ? "RW" : "RO",
+		(((0x1 << 0) & dcmd) == 0) ? "Off" : "On",
+		PMC551_DRAM_BLK_GET_SIZE(dcmd),
+		((dcmd >> 20) & 0x7FF), ((dcmd >> 13) & 0x7),
+		((dcmd >> 9) & 0xF));
+
+	pci_read_config_dword(dev, PMC551_DRAM_BLK3, &dcmd);
+	printk(KERN_DEBUG "pmc551: DRAM_BLK3 Flags: %s,%s\n"
+		"pmc551: DRAM_BLK3 Size: %d at %d\n"
+		"pmc551: DRAM_BLK3 Row MUX: %d, Col MUX: %d\n",
+		(((0x1 << 1) & dcmd) == 0) ? "RW" : "RO",
+		(((0x1 << 0) & dcmd) == 0) ? "Off" : "On",
+		PMC551_DRAM_BLK_GET_SIZE(dcmd),
+		((dcmd >> 20) & 0x7FF), ((dcmd >> 13) & 0x7),
+		((dcmd >> 9) & 0xF));
+
+	pci_read_config_word(dev, PCI_COMMAND, &cmd);
+	printk(KERN_DEBUG "pmc551: Memory Access %s\n",
+		(((0x1 << 1) & cmd) == 0) ? "off" : "on");
+	printk(KERN_DEBUG "pmc551: I/O Access %s\n",
+		(((0x1 << 0) & cmd) == 0) ? "off" : "on");
+
+	pci_read_config_word(dev, PCI_STATUS, &cmd);
+	printk(KERN_DEBUG "pmc551: Devsel %s\n",
+		((PCI_STATUS_DEVSEL_MASK & cmd) == 0x000) ? "Fast" :
+		((PCI_STATUS_DEVSEL_MASK & cmd) == 0x200) ? "Medium" :
+		((PCI_STATUS_DEVSEL_MASK & cmd) == 0x400) ? "Slow" : "Invalid");
+
+	printk(KERN_DEBUG "pmc551: %sFast Back-to-Back\n",
+		((PCI_COMMAND_FAST_BACK & cmd) == 0) ? "Not " : "");
+
+	pci_read_config_byte(dev, PMC551_SYS_CTRL_REG, &bcmd);
+	printk(KERN_DEBUG "pmc551: EEPROM is under %s control\n"
+		"pmc551: System Control Register is %slocked to PCI access\n"
+		"pmc551: System Control Register is %slocked to EEPROM access\n",
+		(bcmd & 0x1) ? "software" : "hardware",
+		(bcmd & 0x20) ? "" : "un", (bcmd & 0x40) ? "" : "un");
 #endif
-        return size;
+	return size;
 }
 
 /*
  * Kernel version specific module stuffages
  */
 
-
 MODULE_LICENSE("GPL");
 MODULE_AUTHOR("Mark Ferrell <mferrell at mvista.com>");
 MODULE_DESCRIPTION(PMC551_VERSION);
@@ -628,11 +650,11 @@ MODULE_DESCRIPTION(PMC551_VERSION);
 /*
  * Stuff these outside the ifdef so as to not bust compiled in driver support
  */
-static int msize=0;
+static int msize = 0;
 #if defined(CONFIG_MTD_PMC551_APERTURE_SIZE)
-static int asize=CONFIG_MTD_PMC551_APERTURE_SIZE
+static int asize = CONFIG_MTD_PMC551_APERTURE_SIZE
 #else
-static int asize=0;
+static int asize = 0;
 #endif
 
 module_param(msize, int, 0);
@@ -645,164 +667,171 @@ MODULE_PARM_DESC(asize, "aperture size, 
  */
 static int __init init_pmc551(void)
 {
-        struct pci_dev *PCI_Device = NULL;
-        struct mypriv *priv;
-        int count, found=0;
-        struct mtd_info *mtd;
-        u32 length = 0;
-
-	if(msize) {
-		msize = (1 << (ffs(msize) - 1))<<20;
-		if (msize > (1<<30)) {
-			printk(KERN_NOTICE "pmc551: Invalid memory size [%d]\n", msize);
+	struct pci_dev *PCI_Device = NULL;
+	struct mypriv *priv;
+	int count, found = 0;
+	struct mtd_info *mtd;
+	u32 length = 0;
+
+	if (msize) {
+		msize = (1 << (ffs(msize) - 1)) << 20;
+		if (msize > (1 << 30)) {
+			printk(KERN_NOTICE "pmc551: Invalid memory size [%d]\n",
+				msize);
 			return -EINVAL;
 		}
 	}
 
-	if(asize) {
-		asize = (1 << (ffs(asize) - 1))<<20;
-		if (asize > (1<<30) ) {
-			printk(KERN_NOTICE "pmc551: Invalid aperture size [%d]\n", asize);
+	if (asize) {
+		asize = (1 << (ffs(asize) - 1)) << 20;
+		if (asize > (1 << 30)) {
+			printk(KERN_NOTICE "pmc551: Invalid aperture size "
+				"[%d]\n", asize);
 			return -EINVAL;
 		}
 	}
 
-        printk(KERN_INFO PMC551_VERSION);
-
-        /*
-         * PCU-bus chipset probe.
-         */
-        for( count = 0; count < MAX_MTD_DEVICES; count++ ) {
-
-                if ((PCI_Device = pci_find_device(PCI_VENDOR_ID_V3_SEMI,
-                                                  PCI_DEVICE_ID_V3_SEMI_V370PDC,
-						  PCI_Device ) ) == NULL) {
-                        break;
-                }
-
-                printk(KERN_NOTICE "pmc551: Found PCI V370PDC at 0x%llx\n",
-				    (unsigned long long)PCI_Device->resource[0].start);
-
-                /*
-                 * The PMC551 device acts VERY weird if you don't init it
-                 * first.  i.e. it will not correctly report devsel.  If for
-                 * some reason the sdram is in a wrote-protected state the
-                 * device will DEVSEL when it is written to causing problems
-                 * with the oldproc.c driver in
-                 * some kernels (2.2.*)
-                 */
-                if((length = fixup_pmc551(PCI_Device)) <= 0) {
-                        printk(KERN_NOTICE "pmc551: Cannot init SDRAM\n");
-                        break;
-                }
+	printk(KERN_INFO PMC551_VERSION);
+
+	/*
+	 * PCU-bus chipset probe.
+	 */
+	for (count = 0; count < MAX_MTD_DEVICES; count++) {
+
+		if ((PCI_Device = pci_find_device(PCI_VENDOR_ID_V3_SEMI,
+						  PCI_DEVICE_ID_V3_SEMI_V370PDC,
+						  PCI_Device)) == NULL) {
+			break;
+		}
+
+		printk(KERN_NOTICE "pmc551: Found PCI V370PDC at 0x%llx\n",
+			(unsigned long long)PCI_Device->resource[0].start);
+
+		/*
+		 * The PMC551 device acts VERY weird if you don't init it
+		 * first.  i.e. it will not correctly report devsel.  If for
+		 * some reason the sdram is in a wrote-protected state the
+		 * device will DEVSEL when it is written to causing problems
+		 * with the oldproc.c driver in
+		 * some kernels (2.2.*)
+		 */
+		if ((length = fixup_pmc551(PCI_Device)) <= 0) {
+			printk(KERN_NOTICE "pmc551: Cannot init SDRAM\n");
+			break;
+		}
 
 		/*
 		 * This is needed until the driver is capable of reading the
 		 * onboard I2C SROM to discover the "real" memory size.
 		 */
-		if(msize) {
+		if (msize) {
 			length = msize;
-			printk(KERN_NOTICE "pmc551: Using specified memory size 0x%x\n", length);
+			printk(KERN_NOTICE "pmc551: Using specified memory "
+				"size 0x%x\n", length);
 		} else {
 			msize = length;
 		}
 
-                mtd = kmalloc(sizeof(struct mtd_info), GFP_KERNEL);
-                if (!mtd) {
-                        printk(KERN_NOTICE "pmc551: Cannot allocate new MTD device.\n");
-                        break;
-                }
-
-                memset(mtd, 0, sizeof(struct mtd_info));
-
-                priv = kmalloc (sizeof(struct mypriv), GFP_KERNEL);
-                if (!priv) {
-                        printk(KERN_NOTICE "pmc551: Cannot allocate new MTD device.\n");
-                        kfree(mtd);
-                        break;
-                }
-                memset(priv, 0, sizeof(*priv));
-                mtd->priv = priv;
-                priv->dev = PCI_Device;
-
-		if(asize > length) {
-			printk(KERN_NOTICE "pmc551: reducing aperture size to fit %dM\n",length>>20);
+		mtd = kmalloc(sizeof(struct mtd_info), GFP_KERNEL);
+		if (!mtd) {
+			printk(KERN_NOTICE "pmc551: Cannot allocate new MTD "
+				"device.\n");
+			break;
+		}
+
+		memset(mtd, 0, sizeof(struct mtd_info));
+
+		priv = kmalloc(sizeof(struct mypriv), GFP_KERNEL);
+		if (!priv) {
+			printk(KERN_NOTICE "pmc551: Cannot allocate new MTD "
+				"device.\n");
+			kfree(mtd);
+			break;
+		}
+		memset(priv, 0, sizeof(*priv));
+		mtd->priv = priv;
+		priv->dev = PCI_Device;
+
+		if (asize > length) {
+			printk(KERN_NOTICE "pmc551: reducing aperture size to
+				fit %dM\n", length >> 20);
 			priv->asize = asize = length;
 		} else if (asize == 0 || asize == length) {
-			printk(KERN_NOTICE "pmc551: Using existing aperture size %dM\n", length>>20);
+			printk(KERN_NOTICE "pmc551: Using existing aperture "
+				"size %dM\n", length >> 20);
 			priv->asize = asize = length;
 		} else {
-			printk(KERN_NOTICE "pmc551: Using specified aperture size %dM\n", asize>>20);
+			printk(KERN_NOTICE "pmc551: Using specified aperture "
+				"size %dM\n", asize >> 20);
 			priv->asize = asize;
 		}
-                priv->start = ioremap(((PCI_Device->resource[0].start)
-                                       & PCI_BASE_ADDRESS_MEM_MASK),
-                                      priv->asize);
+		priv->start = ioremap(((PCI_Device->resource[0].start)
+					& PCI_BASE_ADDRESS_MEM_MASK),
+				      priv->asize);
 
 		if (!priv->start) {
 			printk(KERN_NOTICE "pmc551: Unable to map IO space\n");
-                        kfree(mtd->priv);
-                        kfree(mtd);
+			kfree(mtd->priv);
+			kfree(mtd);
 			break;
 		}
-
 #ifdef CONFIG_MTD_PMC551_DEBUG
-		printk( KERN_DEBUG "pmc551: setting aperture to %d\n",
-			ffs(priv->asize>>20)-1);
+		printk(KERN_DEBUG "pmc551: setting aperture to %d\n",
+			ffs(priv->asize >> 20) - 1);
 #endif
 
-                priv->base_map0 = ( PMC551_PCI_MEM_MAP_REG_EN
-				  | PMC551_PCI_MEM_MAP_ENABLE
-				  | (ffs(priv->asize>>20)-1)<<4 );
-                priv->curr_map0 = priv->base_map0;
-                pci_write_config_dword ( priv->dev, PMC551_PCI_MEM_MAP0,
-                                         priv->curr_map0 );
+		priv->base_map0 = (PMC551_PCI_MEM_MAP_REG_EN
+				   | PMC551_PCI_MEM_MAP_ENABLE
+				   | (ffs(priv->asize >> 20) - 1) << 4);
+		priv->curr_map0 = priv->base_map0;
+		pci_write_config_dword(priv->dev, PMC551_PCI_MEM_MAP0,
+					priv->curr_map0);
 
 #ifdef CONFIG_MTD_PMC551_DEBUG
-		printk( KERN_DEBUG "pmc551: aperture set to %d\n",
-			(priv->base_map0 & 0xF0)>>4 );
+		printk(KERN_DEBUG "pmc551: aperture set to %d\n",
+			(priv->base_map0 & 0xF0) >> 4);
 #endif
 
-                mtd->size 	= msize;
-                mtd->flags 	= MTD_CAP_RAM;
-                mtd->erase 	= pmc551_erase;
-                mtd->read 	= pmc551_read;
-                mtd->write 	= pmc551_write;
-                mtd->point 	= pmc551_point;
-                mtd->unpoint 	= pmc551_unpoint;
-                mtd->type 	= MTD_RAM;
-                mtd->name 	= "PMC551 RAM board";
-                mtd->erasesize 	= 0x10000;
-                mtd->writesize  = 1;
-                mtd->owner = THIS_MODULE;
-
-                if (add_mtd_device(mtd)) {
-                        printk(KERN_NOTICE "pmc551: Failed to register new device\n");
+		mtd->size = msize;
+		mtd->flags = MTD_CAP_RAM;
+		mtd->erase = pmc551_erase;
+		mtd->read = pmc551_read;
+		mtd->write = pmc551_write;
+		mtd->point = pmc551_point;
+		mtd->unpoint = pmc551_unpoint;
+		mtd->type = MTD_RAM;
+		mtd->name = "PMC551 RAM board";
+		mtd->erasesize = 0x10000;
+		mtd->writesize = 1;
+		mtd->owner = THIS_MODULE;
+
+		if (add_mtd_device(mtd)) {
+			printk(KERN_NOTICE "pmc551: Failed to register new "
+				"device\n");
 			iounmap(priv->start);
-                        kfree(mtd->priv);
-                        kfree(mtd);
-                        break;
-                }
-                printk(KERN_NOTICE "Registered pmc551 memory device.\n");
-                printk(KERN_NOTICE "Mapped %dM of memory from 0x%p to 0x%p\n",
-                       priv->asize>>20,
-                       priv->start,
-                       priv->start + priv->asize);
-                printk(KERN_NOTICE "Total memory is %d%c\n",
-	       		(length<1024)?length:
-				(length<1048576)?length>>10:length>>20,
-               		(length<1024)?'B':(length<1048576)?'K':'M');
+			kfree(mtd->priv);
+			kfree(mtd);
+			break;
+		}
+		printk(KERN_NOTICE "Registered pmc551 memory device.\n");
+		printk(KERN_NOTICE "Mapped %dM of memory from 0x%p to 0x%p\n",
+			priv->asize >> 20,
+			priv->start, priv->start + priv->asize);
+		printk(KERN_NOTICE "Total memory is %d%c\n",
+			(length < 1024) ? length :
+			(length < 1048576) ? length >> 10 : length >> 20,
+			(length < 1024) ? 'B' : (length < 1048576) ? 'K' : 'M');
 		priv->nextpmc551 = pmc551list;
 		pmc551list = mtd;
 		found++;
-        }
+	}
 
-        if( !pmc551list ) {
-                printk(KERN_NOTICE "pmc551: not detected\n");
-                return -ENODEV;
-        } else {
+	if (!pmc551list) {
+		printk(KERN_NOTICE "pmc551: not detected\n");
+		return -ENODEV;
+	} else {
 		printk(KERN_NOTICE "pmc551: %d pmc551 devices loaded\n", found);
-                return 0;
+		return 0;
 	}
 }
 
@@ -811,23 +840,23 @@ #endif
  */
 static void __exit cleanup_pmc551(void)
 {
-        int found=0;
-        struct mtd_info *mtd;
+	int found = 0;
+	struct mtd_info *mtd;
 	struct mypriv *priv;
 
-	while((mtd=pmc551list)) {
+	while ((mtd = pmc551list)) {
 		priv = mtd->priv;
 		pmc551list = priv->nextpmc551;
 
-		if(priv->start) {
-			printk (KERN_DEBUG "pmc551: unmapping %dM starting at 0x%p\n",
-				priv->asize>>20, priv->start);
-			iounmap (priv->start);
+		if (priv->start) {
+			printk(KERN_DEBUG "pmc551: unmapping %dM starting at "
+				"0x%p\n", priv->asize >> 20, priv->start);
+			iounmap(priv->start);
 		}
 
-		kfree (mtd->priv);
-		del_mtd_device (mtd);
-		kfree (mtd);
+		kfree(mtd->priv);
+		del_mtd_device(mtd);
+		kfree(mtd);
 		found++;
 	}
 



From jirislaby at gmail.com  Mon Sep 18 18:55:08 2006
From: jirislaby at gmail.com (Jiri Slaby)
Date: Tue, 19 Sep 2006 00:55:08 +0200 (CEST)
Subject: [PATCH 1/4 corrected] pmc551 whitespace cleanup
Message-ID: <91aaa292933121291221@karneval.cz>

Please apply this one, instead of previous 1/4 patch:

pmc551 whitespace cleanup

Spaces were used for indent, there was more than 80 columns per line. Get
rid of that stuff.

Signed-off-by: Jiri Slaby <jirislaby at gmail.com>

---
commit 60ab613754650ef2972b3d35ac155e6b154046c6
tree 8c4b0de1c69d044dcf9f792647309a803af8aa96
parent ca8b00296c6ff25faf9db7fe4b11d1460b64c7d7
author Jiri Slaby <xslaby at anemoi.localdomain> Tue, 19 Sep 2006 00:30:55 +0200
committer Jiri Slaby <xslaby at anemoi.localdomain> Tue, 19 Sep 2006 00:30:55 +0200

 drivers/mtd/devices/pmc551.c | 1149 ++++++++++++++++++++++--------------------
 1 files changed, 589 insertions(+), 560 deletions(-)

diff --git a/drivers/mtd/devices/pmc551.c b/drivers/mtd/devices/pmc551.c
index 2c01497..12c833e 100644
--- a/drivers/mtd/devices/pmc551.c
+++ b/drivers/mtd/devices/pmc551.c
@@ -4,82 +4,82 @@
  * PMC551 PCI Mezzanine Ram Device
  *
  * Author:
- *       Mark Ferrell <mferrell at mvista.com>
- *       Copyright 1999,2000 Nortel Networks
+ *	Mark Ferrell <mferrell at mvista.com>
+ *	Copyright 1999,2000 Nortel Networks
  *
  * License:
- *	 As part of this driver was derived from the slram.c driver it
- *	 falls under the same license, which is GNU General Public
- *	 License v2
+ *	As part of this driver was derived from the slram.c driver it
+ *	falls under the same license, which is GNU General Public
+ *	License v2
  *
  * Description:
- *	 This driver is intended to support the PMC551 PCI Ram device
- *	 from Ramix Inc.  The PMC551 is a PMC Mezzanine module for
- *	 cPCI embedded systems.  The device contains a single SROM
- *	 that initially programs the V370PDC chipset onboard the
- *	 device, and various banks of DRAM/SDRAM onboard.  This driver
- *	 implements this PCI Ram device as an MTD (Memory Technology
- *	 Device) so that it can be used to hold a file system, or for
- *	 added swap space in embedded systems.  Since the memory on
- *	 this board isn't as fast as main memory we do not try to hook
- *	 it into main memory as that would simply reduce performance
- *	 on the system.  Using it as a block device allows us to use
- *	 it as high speed swap or for a high speed disk device of some
- *	 sort.  Which becomes very useful on diskless systems in the
- *	 embedded market I might add.
+ *	This driver is intended to support the PMC551 PCI Ram device
+ *	from Ramix Inc.  The PMC551 is a PMC Mezzanine module for
+ *	cPCI embedded systems.  The device contains a single SROM
+ *	that initially programs the V370PDC chipset onboard the
+ *	device, and various banks of DRAM/SDRAM onboard.  This driver
+ *	implements this PCI Ram device as an MTD (Memory Technology
+ *	Device) so that it can be used to hold a file system, or for
+ *	added swap space in embedded systems.  Since the memory on
+ *	this board isn't as fast as main memory we do not try to hook
+ *	it into main memory as that would simply reduce performance
+ *	on the system.  Using it as a block device allows us to use
+ *	it as high speed swap or for a high speed disk device of some
+ *	sort.  Which becomes very useful on diskless systems in the
+ *	embedded market I might add.
  *
  * Notes:
- *	 Due to what I assume is more buggy SROM, the 64M PMC551 I
- *	 have available claims that all 4 of it's DRAM banks have 64M
- *	 of ram configured (making a grand total of 256M onboard).
- *	 This is slightly annoying since the BAR0 size reflects the
- *	 aperture size, not the dram size, and the V370PDC supplies no
- *	 other method for memory size discovery.  This problem is
- *	 mostly only relevant when compiled as a module, as the
- *	 unloading of the module with an aperture size smaller then
- *	 the ram will cause the driver to detect the onboard memory
- *	 size to be equal to the aperture size when the module is
- *	 reloaded.  Soooo, to help, the module supports an msize
- *	 option to allow the specification of the onboard memory, and
- *	 an asize option, to allow the specification of the aperture
- *	 size.  The aperture must be equal to or less then the memory
- *	 size, the driver will correct this if you screw it up.  This
- *	 problem is not relevant for compiled in drivers as compiled
- *	 in drivers only init once.
+ *	Due to what I assume is more buggy SROM, the 64M PMC551 I
+ *	have available claims that all 4 of it's DRAM banks have 64M
+ *	of ram configured (making a grand total of 256M onboard).
+ *	This is slightly annoying since the BAR0 size reflects the
+ *	aperture size, not the dram size, and the V370PDC supplies no
+ *	other method for memory size discovery.  This problem is
+ *	mostly only relevant when compiled as a module, as the
+ *	unloading of the module with an aperture size smaller then
+ *	the ram will cause the driver to detect the onboard memory
+ *	size to be equal to the aperture size when the module is
+ *	reloaded.  Soooo, to help, the module supports an msize
+ *	option to allow the specification of the onboard memory, and
+ *	an asize option, to allow the specification of the aperture
+ *	size.  The aperture must be equal to or less then the memory
+ *	size, the driver will correct this if you screw it up.  This
+ *	problem is not relevant for compiled in drivers as compiled
+ *	in drivers only init once.
  *
  * Credits:
- *       Saeed Karamooz <saeed at ramix.com> of Ramix INC. for the
- *       initial example code of how to initialize this device and for
- *       help with questions I had concerning operation of the device.
+ *	Saeed Karamooz <saeed at ramix.com> of Ramix INC. for the
+ *	initial example code of how to initialize this device and for
+ *	help with questions I had concerning operation of the device.
  *
- *       Most of the MTD code for this driver was originally written
- *       for the slram.o module in the MTD drivers package which
- *       allows the mapping of system memory into an MTD device.
- *       Since the PMC551 memory module is accessed in the same
- *       fashion as system memory, the slram.c code became a very nice
- *       fit to the needs of this driver.  All we added was PCI
- *       detection/initialization to the driver and automatically figure
- *       out the size via the PCI detection.o, later changes by Corey
- *       Minyard set up the card to utilize a 1M sliding apature.
+ *	Most of the MTD code for this driver was originally written
+ *	for the slram.o module in the MTD drivers package which
+ *	allows the mapping of system memory into an MTD device.
+ *	Since the PMC551 memory module is accessed in the same
+ *	fashion as system memory, the slram.c code became a very nice
+ *	fit to the needs of this driver.  All we added was PCI
+ *	detection/initialization to the driver and automatically figure
+ *	out the size via the PCI detection.o, later changes by Corey
+ *	Minyard set up the card to utilize a 1M sliding apature.
  *
- *	 Corey Minyard <minyard at nortelnetworks.com>
- *       * Modified driver to utilize a sliding aperture instead of
- *         mapping all memory into kernel space which turned out to
- *         be very wasteful.
- *       * Located a bug in the SROM's initialization sequence that
- *         made the memory unusable, added a fix to code to touch up
- *         the DRAM some.
+ *	Corey Minyard <minyard at nortelnetworks.com>
+ *	* Modified driver to utilize a sliding aperture instead of
+ *	 mapping all memory into kernel space which turned out to
+ *	 be very wasteful.
+ *	* Located a bug in the SROM's initialization sequence that
+ *	 made the memory unusable, added a fix to code to touch up
+ *	 the DRAM some.
  *
  * Bugs/FIXME's:
- *       * MUST fix the init function to not spin on a register
- *       waiting for it to set .. this does not safely handle busted
- *       devices that never reset the register correctly which will
- *       cause the system to hang w/ a reboot being the only chance at
- *       recover. [sort of fixed, could be better]
- *       * Add I2C handling of the SROM so we can read the SROM's information
- *       about the aperture size.  This should always accurately reflect the
- *       onboard memory size.
- *       * Comb the init routine.  It's still a bit cludgy on a few things.
+ *	* MUST fix the init function to not spin on a register
+ *	waiting for it to set .. this does not safely handle busted
+ *	devices that never reset the register correctly which will
+ *	cause the system to hang w/ a reboot being the only chance at
+ *	recover. [sort of fixed, could be better]
+ *	* Add I2C handling of the SROM so we can read the SROM's information
+ *	about the aperture size.  This should always accurately reflect the
+ *	onboard memory size.
+ *	* Comb the init routine.  It's still a bit cludgy on a few things.
  */
 
 #include <linux/kernel.h>
@@ -105,74 +105,77 @@ #include <linux/mtd/compatmac.h>
 
 static struct mtd_info *pmc551list;
 
-static int pmc551_erase (struct mtd_info *mtd, struct erase_info *instr)
+static int pmc551_erase(struct mtd_info *mtd, struct erase_info *instr)
 {
-        struct mypriv *priv = mtd->priv;
-        u32 soff_hi, soff_lo; /* start address offset hi/lo */
-        u32 eoff_hi, eoff_lo; /* end address offset hi/lo */
-        unsigned long end;
+	struct mypriv *priv = mtd->priv;
+	u32 soff_hi, soff_lo;	/* start address offset hi/lo */
+	u32 eoff_hi, eoff_lo;	/* end address offset hi/lo */
+	unsigned long end;
 	u_char *ptr;
 	size_t retlen;
 
 #ifdef CONFIG_MTD_PMC551_DEBUG
-	printk(KERN_DEBUG "pmc551_erase(pos:%ld, len:%ld)\n", (long)instr->addr, (long)instr->len);
+	printk(KERN_DEBUG "pmc551_erase(pos:%ld, len:%ld)\n", (long)instr->addr,
+		(long)instr->len);
 #endif
 
-        end = instr->addr + instr->len - 1;
+	end = instr->addr + instr->len - 1;
 
-        /* Is it past the end? */
-        if ( end > mtd->size ) {
+	/* Is it past the end? */
+	if (end > mtd->size) {
 #ifdef CONFIG_MTD_PMC551_DEBUG
-	printk(KERN_DEBUG "pmc551_erase() out of bounds (%ld > %ld)\n", (long)end, (long)mtd->size);
+		printk(KERN_DEBUG "pmc551_erase() out of bounds (%ld > %ld)\n",
+			(long)end, (long)mtd->size);
 #endif
-                return -EINVAL;
-        }
-
-        eoff_hi = end & ~(priv->asize - 1);
-        soff_hi = instr->addr & ~(priv->asize - 1);
-        eoff_lo = end & (priv->asize - 1);
-        soff_lo = instr->addr & (priv->asize - 1);
-
-	pmc551_point (mtd, instr->addr, instr->len, &retlen, &ptr);
-
-        if ( soff_hi == eoff_hi || mtd->size == priv->asize) {
-                /* The whole thing fits within one access, so just one shot
-                   will do it. */
-                memset(ptr, 0xff, instr->len);
-        } else {
-                /* We have to do multiple writes to get all the data
-                   written. */
-                while (soff_hi != eoff_hi) {
+		return -EINVAL;
+	}
+
+	eoff_hi = end & ~(priv->asize - 1);
+	soff_hi = instr->addr & ~(priv->asize - 1);
+	eoff_lo = end & (priv->asize - 1);
+	soff_lo = instr->addr & (priv->asize - 1);
+
+	pmc551_point(mtd, instr->addr, instr->len, &retlen, &ptr);
+
+	if (soff_hi == eoff_hi || mtd->size == priv->asize) {
+		/* The whole thing fits within one access, so just one shot
+		   will do it. */
+		memset(ptr, 0xff, instr->len);
+	} else {
+		/* We have to do multiple writes to get all the data
+		   written. */
+		while (soff_hi != eoff_hi) {
 #ifdef CONFIG_MTD_PMC551_DEBUG
-			printk( KERN_DEBUG "pmc551_erase() soff_hi: %ld, eoff_hi: %ld\n", (long)soff_hi, (long)eoff_hi);
+			printk(KERN_DEBUG "pmc551_erase() soff_hi: %ld, "
+				"eoff_hi: %ld\n", (long)soff_hi, (long)eoff_hi);
 #endif
-                        memset(ptr, 0xff, priv->asize);
-                        if (soff_hi + priv->asize >= mtd->size) {
-                                goto out;
-                        }
-                        soff_hi += priv->asize;
-			pmc551_point (mtd,(priv->base_map0|soff_hi),
-				      priv->asize, &retlen, &ptr);
-                }
-                memset (ptr, 0xff, eoff_lo);
-        }
-
-out:
+			memset(ptr, 0xff, priv->asize);
+			if (soff_hi + priv->asize >= mtd->size) {
+				goto out;
+			}
+			soff_hi += priv->asize;
+			pmc551_point(mtd, (priv->base_map0 | soff_hi),
+				     priv->asize, &retlen, &ptr);
+		}
+		memset(ptr, 0xff, eoff_lo);
+	}
+
+      out:
 	instr->state = MTD_ERASE_DONE;
 #ifdef CONFIG_MTD_PMC551_DEBUG
 	printk(KERN_DEBUG "pmc551_erase() done\n");
 #endif
 
-        mtd_erase_callback(instr);
-        return 0;
+	mtd_erase_callback(instr);
+	return 0;
 }
 
-
-static int pmc551_point (struct mtd_info *mtd, loff_t from, size_t len, size_t *retlen, u_char **mtdbuf)
+static int pmc551_point(struct mtd_info *mtd, loff_t from, size_t len,
+			size_t * retlen, u_char ** mtdbuf)
 {
-        struct mypriv *priv = mtd->priv;
-        u32 soff_hi;
-        u32 soff_lo;
+	struct mypriv *priv = mtd->priv;
+	u32 soff_hi;
+	u32 soff_lo;
 
 #ifdef CONFIG_MTD_PMC551_DEBUG
 	printk(KERN_DEBUG "pmc551_point(%ld, %ld)\n", (long)from, (long)len);
@@ -180,18 +183,19 @@ #endif
 
 	if (from + len > mtd->size) {
 #ifdef CONFIG_MTD_PMC551_DEBUG
-		printk(KERN_DEBUG "pmc551_point() out of bounds (%ld > %ld)\n", (long)from+len, (long)mtd->size);
+		printk(KERN_DEBUG "pmc551_point() out of bounds (%ld > %ld)\n",
+			(long)from + len, (long)mtd->size);
 #endif
 		return -EINVAL;
 	}
 
-        soff_hi = from & ~(priv->asize - 1);
-        soff_lo = from & (priv->asize - 1);
+	soff_hi = from & ~(priv->asize - 1);
+	soff_lo = from & (priv->asize - 1);
 
 	/* Cheap hack optimization */
-	if( priv->curr_map0 != from ) {
-        	pci_write_config_dword ( priv->dev, PMC551_PCI_MEM_MAP0,
-                                 	(priv->base_map0 | soff_hi) );
+	if (priv->curr_map0 != from) {
+		pci_write_config_dword(priv->dev, PMC551_PCI_MEM_MAP0,
+					(priv->base_map0 | soff_hi));
 		priv->curr_map0 = soff_hi;
 	}
 
@@ -200,137 +204,144 @@ #endif
 	return 0;
 }
 
-
-static void pmc551_unpoint (struct mtd_info *mtd, u_char *addr, loff_t from, size_t len)
+static void pmc551_unpoint(struct mtd_info *mtd, u_char * addr, loff_t from,
+			   size_t len)
 {
 #ifdef CONFIG_MTD_PMC551_DEBUG
 	printk(KERN_DEBUG "pmc551_unpoint()\n");
 #endif
 }
 
-
-static int pmc551_read (struct mtd_info *mtd, loff_t from, size_t len, size_t *retlen, u_char *buf)
+static int pmc551_read(struct mtd_info *mtd, loff_t from, size_t len,
+			size_t * retlen, u_char * buf)
 {
-        struct mypriv *priv = mtd->priv;
-        u32 soff_hi, soff_lo; /* start address offset hi/lo */
-        u32 eoff_hi, eoff_lo; /* end address offset hi/lo */
-        unsigned long end;
+	struct mypriv *priv = mtd->priv;
+	u32 soff_hi, soff_lo;	/* start address offset hi/lo */
+	u32 eoff_hi, eoff_lo;	/* end address offset hi/lo */
+	unsigned long end;
 	u_char *ptr;
-        u_char *copyto = buf;
+	u_char *copyto = buf;
 
 #ifdef CONFIG_MTD_PMC551_DEBUG
-	printk(KERN_DEBUG "pmc551_read(pos:%ld, len:%ld) asize: %ld\n", (long)from, (long)len, (long)priv->asize);
+	printk(KERN_DEBUG "pmc551_read(pos:%ld, len:%ld) asize: %ld\n",
+		(long)from, (long)len, (long)priv->asize);
 #endif
 
-        end = from + len - 1;
+	end = from + len - 1;
 
-        /* Is it past the end? */
-        if (end > mtd->size) {
+	/* Is it past the end? */
+	if (end > mtd->size) {
 #ifdef CONFIG_MTD_PMC551_DEBUG
-	printk(KERN_DEBUG "pmc551_read() out of bounds (%ld > %ld)\n", (long) end, (long)mtd->size);
+		printk(KERN_DEBUG "pmc551_read() out of bounds (%ld > %ld)\n",
+			(long)end, (long)mtd->size);
 #endif
-                return -EINVAL;
-        }
-
-        soff_hi = from & ~(priv->asize - 1);
-        eoff_hi = end & ~(priv->asize - 1);
-        soff_lo = from & (priv->asize - 1);
-        eoff_lo = end & (priv->asize - 1);
-
-	pmc551_point (mtd, from, len, retlen, &ptr);
-
-        if (soff_hi == eoff_hi) {
-                /* The whole thing fits within one access, so just one shot
-                   will do it. */
-                memcpy(copyto, ptr, len);
-                copyto += len;
-        } else {
-                /* We have to do multiple writes to get all the data
-                   written. */
-                while (soff_hi != eoff_hi) {
+		return -EINVAL;
+	}
+
+	soff_hi = from & ~(priv->asize - 1);
+	eoff_hi = end & ~(priv->asize - 1);
+	soff_lo = from & (priv->asize - 1);
+	eoff_lo = end & (priv->asize - 1);
+
+	pmc551_point(mtd, from, len, retlen, &ptr);
+
+	if (soff_hi == eoff_hi) {
+		/* The whole thing fits within one access, so just one shot
+		   will do it. */
+		memcpy(copyto, ptr, len);
+		copyto += len;
+	} else {
+		/* We have to do multiple writes to get all the data
+		   written. */
+		while (soff_hi != eoff_hi) {
 #ifdef CONFIG_MTD_PMC551_DEBUG
-			printk( KERN_DEBUG "pmc551_read() soff_hi: %ld, eoff_hi: %ld\n", (long)soff_hi, (long)eoff_hi);
+			printk(KERN_DEBUG "pmc551_read() soff_hi: %ld, "
+				"eoff_hi: %ld\n", (long)soff_hi, (long)eoff_hi);
 #endif
-                        memcpy(copyto, ptr, priv->asize);
-                        copyto += priv->asize;
-                        if (soff_hi + priv->asize >= mtd->size) {
-                                goto out;
-                        }
-                        soff_hi += priv->asize;
-			pmc551_point (mtd, soff_hi, priv->asize, retlen, &ptr);
-                }
-                memcpy(copyto, ptr, eoff_lo);
-                copyto += eoff_lo;
-        }
-
-out:
+			memcpy(copyto, ptr, priv->asize);
+			copyto += priv->asize;
+			if (soff_hi + priv->asize >= mtd->size) {
+				goto out;
+			}
+			soff_hi += priv->asize;
+			pmc551_point(mtd, soff_hi, priv->asize, retlen, &ptr);
+		}
+		memcpy(copyto, ptr, eoff_lo);
+		copyto += eoff_lo;
+	}
+
+      out:
 #ifdef CONFIG_MTD_PMC551_DEBUG
 	printk(KERN_DEBUG "pmc551_read() done\n");
 #endif
-        *retlen = copyto - buf;
-        return 0;
+	*retlen = copyto - buf;
+	return 0;
 }
 
-static int pmc551_write (struct mtd_info *mtd, loff_t to, size_t len, size_t *retlen, const u_char *buf)
+static int pmc551_write(struct mtd_info *mtd, loff_t to, size_t len,
+			size_t * retlen, const u_char * buf)
 {
-        struct mypriv *priv = mtd->priv;
-        u32 soff_hi, soff_lo; /* start address offset hi/lo */
-        u32 eoff_hi, eoff_lo; /* end address offset hi/lo */
-        unsigned long end;
+	struct mypriv *priv = mtd->priv;
+	u32 soff_hi, soff_lo;	/* start address offset hi/lo */
+	u32 eoff_hi, eoff_lo;	/* end address offset hi/lo */
+	unsigned long end;
 	u_char *ptr;
-        const u_char *copyfrom = buf;
-
+	const u_char *copyfrom = buf;
 
 #ifdef CONFIG_MTD_PMC551_DEBUG
-	printk(KERN_DEBUG "pmc551_write(pos:%ld, len:%ld) asize:%ld\n", (long)to, (long)len, (long)priv->asize);
+	printk(KERN_DEBUG "pmc551_write(pos:%ld, len:%ld) asize:%ld\n",
+		(long)to, (long)len, (long)priv->asize);
 #endif
 
-        end = to + len - 1;
-        /* Is it past the end?  or did the u32 wrap? */
-        if (end > mtd->size ) {
+	end = to + len - 1;
+	/* Is it past the end?  or did the u32 wrap? */
+	if (end > mtd->size) {
 #ifdef CONFIG_MTD_PMC551_DEBUG
-	printk(KERN_DEBUG "pmc551_write() out of bounds (end: %ld, size: %ld, to: %ld)\n", (long) end, (long)mtd->size, (long)to);
+		printk(KERN_DEBUG "pmc551_write() out of bounds (end: %ld, "
+			"size: %ld, to: %ld)\n", (long)end, (long)mtd->size,
+			(long)to);
 #endif
-                return -EINVAL;
-        }
-
-        soff_hi = to & ~(priv->asize - 1);
-        eoff_hi = end & ~(priv->asize - 1);
-        soff_lo = to & (priv->asize - 1);
-        eoff_lo = end & (priv->asize - 1);
-
-	pmc551_point (mtd, to, len, retlen, &ptr);
-
-        if (soff_hi == eoff_hi) {
-                /* The whole thing fits within one access, so just one shot
-                   will do it. */
-                memcpy(ptr, copyfrom, len);
-                copyfrom += len;
-        } else {
-                /* We have to do multiple writes to get all the data
-                   written. */
-                while (soff_hi != eoff_hi) {
+		return -EINVAL;
+	}
+
+	soff_hi = to & ~(priv->asize - 1);
+	eoff_hi = end & ~(priv->asize - 1);
+	soff_lo = to & (priv->asize - 1);
+	eoff_lo = end & (priv->asize - 1);
+
+	pmc551_point(mtd, to, len, retlen, &ptr);
+
+	if (soff_hi == eoff_hi) {
+		/* The whole thing fits within one access, so just one shot
+		   will do it. */
+		memcpy(ptr, copyfrom, len);
+		copyfrom += len;
+	} else {
+		/* We have to do multiple writes to get all the data
+		   written. */
+		while (soff_hi != eoff_hi) {
 #ifdef CONFIG_MTD_PMC551_DEBUG
-			printk( KERN_DEBUG "pmc551_write() soff_hi: %ld, eoff_hi: %ld\n", (long)soff_hi, (long)eoff_hi);
+			printk(KERN_DEBUG "pmc551_write() soff_hi: %ld, "
+				"eoff_hi: %ld\n", (long)soff_hi, (long)eoff_hi);
 #endif
-                	memcpy(ptr, copyfrom, priv->asize);
-                	copyfrom += priv->asize;
-                        if (soff_hi >= mtd->size) {
-                                goto out;
-                        }
-                        soff_hi += priv->asize;
-			pmc551_point (mtd, soff_hi, priv->asize, retlen, &ptr);
-                }
-                memcpy(ptr, copyfrom, eoff_lo);
-                copyfrom += eoff_lo;
-        }
-
-out:
+			memcpy(ptr, copyfrom, priv->asize);
+			copyfrom += priv->asize;
+			if (soff_hi >= mtd->size) {
+				goto out;
+			}
+			soff_hi += priv->asize;
+			pmc551_point(mtd, soff_hi, priv->asize, retlen, &ptr);
+		}
+		memcpy(ptr, copyfrom, eoff_lo);
+		copyfrom += eoff_lo;
+	}
+
+      out:
 #ifdef CONFIG_MTD_PMC551_DEBUG
 	printk(KERN_DEBUG "pmc551_write() done\n");
 #endif
-        *retlen = copyfrom - buf;
-        return 0;
+	*retlen = copyfrom - buf;
+	return 0;
 }
 
 /*
@@ -345,58 +356,58 @@ #endif
  * mechanism
  * returns the size of the memory region found.
  */
-static u32 fixup_pmc551 (struct pci_dev *dev)
+static u32 fixup_pmc551(struct pci_dev *dev)
 {
 #ifdef CONFIG_MTD_PMC551_BUGFIX
-        u32 dram_data;
+	u32 dram_data;
 #endif
-        u32 size, dcmd, cfg, dtmp;
-        u16 cmd, tmp, i;
+	u32 size, dcmd, cfg, dtmp;
+	u16 cmd, tmp, i;
 	u8 bcmd, counter;
 
-        /* Sanity Check */
-        if(!dev) {
-                return -ENODEV;
-        }
+	/* Sanity Check */
+	if (!dev) {
+		return -ENODEV;
+	}
 
 	/*
 	 * Attempt to reset the card
 	 * FIXME: Stop Spinning registers
 	 */
-	counter=0;
+	counter = 0;
 	/* unlock registers */
-	pci_write_config_byte(dev, PMC551_SYS_CTRL_REG, 0xA5 );
+	pci_write_config_byte(dev, PMC551_SYS_CTRL_REG, 0xA5);
 	/* read in old data */
-	pci_read_config_byte(dev, PMC551_SYS_CTRL_REG, &bcmd );
+	pci_read_config_byte(dev, PMC551_SYS_CTRL_REG, &bcmd);
 	/* bang the reset line up and down for a few */
-	for(i=0;i<10;i++) {
-		counter=0;
+	for (i = 0; i < 10; i++) {
+		counter = 0;
 		bcmd &= ~0x80;
-		while(counter++ < 100) {
+		while (counter++ < 100) {
 			pci_write_config_byte(dev, PMC551_SYS_CTRL_REG, bcmd);
 		}
-		counter=0;
+		counter = 0;
 		bcmd |= 0x80;
-		while(counter++ < 100) {
+		while (counter++ < 100) {
 			pci_write_config_byte(dev, PMC551_SYS_CTRL_REG, bcmd);
 		}
 	}
-	bcmd |= (0x40|0x20);
+	bcmd |= (0x40 | 0x20);
 	pci_write_config_byte(dev, PMC551_SYS_CTRL_REG, bcmd);
 
-        /*
+	/*
 	 * Take care and turn off the memory on the device while we
 	 * tweak the configurations
 	 */
-        pci_read_config_word(dev, PCI_COMMAND, &cmd);
-        tmp = cmd & ~(PCI_COMMAND_IO|PCI_COMMAND_MEMORY);
-        pci_write_config_word(dev, PCI_COMMAND, tmp);
+	pci_read_config_word(dev, PCI_COMMAND, &cmd);
+	tmp = cmd & ~(PCI_COMMAND_IO | PCI_COMMAND_MEMORY);
+	pci_write_config_word(dev, PCI_COMMAND, tmp);
 
 	/*
 	 * Disable existing aperture before probing memory size
 	 */
 	pci_read_config_dword(dev, PMC551_PCI_MEM_MAP0, &dcmd);
-        dtmp=(dcmd|PMC551_PCI_MEM_MAP_ENABLE|PMC551_PCI_MEM_MAP_REG_EN);
+	dtmp = (dcmd | PMC551_PCI_MEM_MAP_ENABLE | PMC551_PCI_MEM_MAP_REG_EN);
 	pci_write_config_dword(dev, PMC551_PCI_MEM_MAP0, dtmp);
 	/*
 	 * Grab old BAR0 config so that we can figure out memory size
@@ -407,220 +418,231 @@ #endif
 	 * then write all 1's to the memory space, read back the result into
 	 * "size", and then write back all the old config.
 	 */
-	pci_read_config_dword( dev, PCI_BASE_ADDRESS_0, &cfg );
+	pci_read_config_dword(dev, PCI_BASE_ADDRESS_0, &cfg);
 #ifndef CONFIG_MTD_PMC551_BUGFIX
-	pci_write_config_dword( dev, PCI_BASE_ADDRESS_0, ~0 );
-	pci_read_config_dword( dev, PCI_BASE_ADDRESS_0, &size );
-	size = (size&PCI_BASE_ADDRESS_MEM_MASK);
-	size &= ~(size-1);
-	pci_write_config_dword( dev, PCI_BASE_ADDRESS_0, cfg );
+	pci_write_config_dword(dev, PCI_BASE_ADDRESS_0, ~0);
+	pci_read_config_dword(dev, PCI_BASE_ADDRESS_0, &size);
+	size = (size & PCI_BASE_ADDRESS_MEM_MASK);
+	size &= ~(size - 1);
+	pci_write_config_dword(dev, PCI_BASE_ADDRESS_0, cfg);
 #else
-        /*
-         * Get the size of the memory by reading all the DRAM size values
-         * and adding them up.
-         *
-         * KLUDGE ALERT: the boards we are using have invalid column and
-         * row mux values.  We fix them here, but this will break other
-         * memory configurations.
-         */
-        pci_read_config_dword(dev, PMC551_DRAM_BLK0, &dram_data);
-        size = PMC551_DRAM_BLK_GET_SIZE(dram_data);
-        dram_data = PMC551_DRAM_BLK_SET_COL_MUX(dram_data, 0x5);
-        dram_data = PMC551_DRAM_BLK_SET_ROW_MUX(dram_data, 0x9);
-        pci_write_config_dword(dev, PMC551_DRAM_BLK0, dram_data);
-
-        pci_read_config_dword(dev, PMC551_DRAM_BLK1, &dram_data);
-        size += PMC551_DRAM_BLK_GET_SIZE(dram_data);
-        dram_data = PMC551_DRAM_BLK_SET_COL_MUX(dram_data, 0x5);
-        dram_data = PMC551_DRAM_BLK_SET_ROW_MUX(dram_data, 0x9);
-        pci_write_config_dword(dev, PMC551_DRAM_BLK1, dram_data);
-
-        pci_read_config_dword(dev, PMC551_DRAM_BLK2, &dram_data);
-        size += PMC551_DRAM_BLK_GET_SIZE(dram_data);
-        dram_data = PMC551_DRAM_BLK_SET_COL_MUX(dram_data, 0x5);
-        dram_data = PMC551_DRAM_BLK_SET_ROW_MUX(dram_data, 0x9);
-        pci_write_config_dword(dev, PMC551_DRAM_BLK2, dram_data);
-
-        pci_read_config_dword(dev, PMC551_DRAM_BLK3, &dram_data);
-        size += PMC551_DRAM_BLK_GET_SIZE(dram_data);
-        dram_data = PMC551_DRAM_BLK_SET_COL_MUX(dram_data, 0x5);
-        dram_data = PMC551_DRAM_BLK_SET_ROW_MUX(dram_data, 0x9);
-        pci_write_config_dword(dev, PMC551_DRAM_BLK3, dram_data);
-
-        /*
-         * Oops .. something went wrong
-         */
-        if( (size &= PCI_BASE_ADDRESS_MEM_MASK) == 0) {
-                return -ENODEV;
-        }
-#endif /* CONFIG_MTD_PMC551_BUGFIX */
-
-	if ((cfg&PCI_BASE_ADDRESS_SPACE) != PCI_BASE_ADDRESS_SPACE_MEMORY) {
-                return -ENODEV;
+	/*
+	 * Get the size of the memory by reading all the DRAM size values
+	 * and adding them up.
+	 *
+	 * KLUDGE ALERT: the boards we are using have invalid column and
+	 * row mux values.  We fix them here, but this will break other
+	 * memory configurations.
+	 */
+	pci_read_config_dword(dev, PMC551_DRAM_BLK0, &dram_data);
+	size = PMC551_DRAM_BLK_GET_SIZE(dram_data);
+	dram_data = PMC551_DRAM_BLK_SET_COL_MUX(dram_data, 0x5);
+	dram_data = PMC551_DRAM_BLK_SET_ROW_MUX(dram_data, 0x9);
+	pci_write_config_dword(dev, PMC551_DRAM_BLK0, dram_data);
+
+	pci_read_config_dword(dev, PMC551_DRAM_BLK1, &dram_data);
+	size += PMC551_DRAM_BLK_GET_SIZE(dram_data);
+	dram_data = PMC551_DRAM_BLK_SET_COL_MUX(dram_data, 0x5);
+	dram_data = PMC551_DRAM_BLK_SET_ROW_MUX(dram_data, 0x9);
+	pci_write_config_dword(dev, PMC551_DRAM_BLK1, dram_data);
+
+	pci_read_config_dword(dev, PMC551_DRAM_BLK2, &dram_data);
+	size += PMC551_DRAM_BLK_GET_SIZE(dram_data);
+	dram_data = PMC551_DRAM_BLK_SET_COL_MUX(dram_data, 0x5);
+	dram_data = PMC551_DRAM_BLK_SET_ROW_MUX(dram_data, 0x9);
+	pci_write_config_dword(dev, PMC551_DRAM_BLK2, dram_data);
+
+	pci_read_config_dword(dev, PMC551_DRAM_BLK3, &dram_data);
+	size += PMC551_DRAM_BLK_GET_SIZE(dram_data);
+	dram_data = PMC551_DRAM_BLK_SET_COL_MUX(dram_data, 0x5);
+	dram_data = PMC551_DRAM_BLK_SET_ROW_MUX(dram_data, 0x9);
+	pci_write_config_dword(dev, PMC551_DRAM_BLK3, dram_data);
+
+	/*
+	 * Oops .. something went wrong
+	 */
+	if ((size &= PCI_BASE_ADDRESS_MEM_MASK) == 0) {
+		return -ENODEV;
+	}
+#endif				/* CONFIG_MTD_PMC551_BUGFIX */
+
+	if ((cfg & PCI_BASE_ADDRESS_SPACE) != PCI_BASE_ADDRESS_SPACE_MEMORY) {
+		return -ENODEV;
 	}
 
-        /*
-         * Precharge Dram
-         */
-        pci_write_config_word( dev, PMC551_SDRAM_MA, 0x0400 );
-        pci_write_config_word( dev, PMC551_SDRAM_CMD, 0x00bf );
-
-        /*
-         * Wait until command has gone through
-         * FIXME: register spinning issue
-         */
-        do {	pci_read_config_word( dev, PMC551_SDRAM_CMD, &cmd );
-		if(counter++ > 100)break;
-        } while ( (PCI_COMMAND_IO) & cmd );
-
-        /*
+	/*
+	 * Precharge Dram
+	 */
+	pci_write_config_word(dev, PMC551_SDRAM_MA, 0x0400);
+	pci_write_config_word(dev, PMC551_SDRAM_CMD, 0x00bf);
+
+	/*
+	 * Wait until command has gone through
+	 * FIXME: register spinning issue
+	 */
+	do {
+		pci_read_config_word(dev, PMC551_SDRAM_CMD, &cmd);
+		if (counter++ > 100)
+			break;
+	} while ((PCI_COMMAND_IO) & cmd);
+
+	/*
 	 * Turn on auto refresh
 	 * The loop is taken directly from Ramix's example code.  I assume that
 	 * this must be held high for some duration of time, but I can find no
 	 * documentation refrencing the reasons why.
-         */
-        for ( i = 1; i<=8 ; i++) {
-                pci_write_config_word (dev, PMC551_SDRAM_CMD, 0x0df);
-
-                /*
-                 * Make certain command has gone through
-                 * FIXME: register spinning issue
-                 */
-		counter=0;
-                do {	pci_read_config_word(dev, PMC551_SDRAM_CMD, &cmd);
-			if(counter++ > 100)break;
-                } while ( (PCI_COMMAND_IO) & cmd );
-        }
-
-        pci_write_config_word ( dev, PMC551_SDRAM_MA, 0x0020);
-        pci_write_config_word ( dev, PMC551_SDRAM_CMD, 0x0ff);
-
-        /*
-         * Wait until command completes
-         * FIXME: register spinning issue
-         */
-	counter=0;
-        do {	pci_read_config_word ( dev, PMC551_SDRAM_CMD, &cmd);
-		if(counter++ > 100)break;
-        } while ( (PCI_COMMAND_IO) & cmd );
-
-        pci_read_config_dword ( dev, PMC551_DRAM_CFG, &dcmd);
-        dcmd |= 0x02000000;
-        pci_write_config_dword ( dev, PMC551_DRAM_CFG, dcmd);
-
-        /*
-         * Check to make certain fast back-to-back, if not
-         * then set it so
-         */
-        pci_read_config_word( dev, PCI_STATUS, &cmd);
-        if((cmd&PCI_COMMAND_FAST_BACK) == 0) {
-                cmd |= PCI_COMMAND_FAST_BACK;
-                pci_write_config_word( dev, PCI_STATUS, cmd);
-        }
-
-        /*
-         * Check to make certain the DEVSEL is set correctly, this device
-         * has a tendancy to assert DEVSEL and TRDY when a write is performed
-         * to the memory when memory is read-only
-         */
-        if((cmd&PCI_STATUS_DEVSEL_MASK) != 0x0) {
-                cmd &= ~PCI_STATUS_DEVSEL_MASK;
-                pci_write_config_word( dev, PCI_STATUS, cmd );
-        }
-        /*
-         * Set to be prefetchable and put everything back based on old cfg.
+	 */
+	for (i = 1; i <= 8; i++) {
+		pci_write_config_word(dev, PMC551_SDRAM_CMD, 0x0df);
+
+		/*
+		 * Make certain command has gone through
+		 * FIXME: register spinning issue
+		 */
+		counter = 0;
+		do {
+			pci_read_config_word(dev, PMC551_SDRAM_CMD, &cmd);
+			if (counter++ > 100)
+				break;
+		} while ((PCI_COMMAND_IO) & cmd);
+	}
+
+	pci_write_config_word(dev, PMC551_SDRAM_MA, 0x0020);
+	pci_write_config_word(dev, PMC551_SDRAM_CMD, 0x0ff);
+
+	/*
+	 * Wait until command completes
+	 * FIXME: register spinning issue
+	 */
+	counter = 0;
+	do {
+		pci_read_config_word(dev, PMC551_SDRAM_CMD, &cmd);
+		if (counter++ > 100)
+			break;
+	} while ((PCI_COMMAND_IO) & cmd);
+
+	pci_read_config_dword(dev, PMC551_DRAM_CFG, &dcmd);
+	dcmd |= 0x02000000;
+	pci_write_config_dword(dev, PMC551_DRAM_CFG, dcmd);
+
+	/*
+	 * Check to make certain fast back-to-back, if not
+	 * then set it so
+	 */
+	pci_read_config_word(dev, PCI_STATUS, &cmd);
+	if ((cmd & PCI_COMMAND_FAST_BACK) == 0) {
+		cmd |= PCI_COMMAND_FAST_BACK;
+		pci_write_config_word(dev, PCI_STATUS, cmd);
+	}
+
+	/*
+	 * Check to make certain the DEVSEL is set correctly, this device
+	 * has a tendancy to assert DEVSEL and TRDY when a write is performed
+	 * to the memory when memory is read-only
+	 */
+	if ((cmd & PCI_STATUS_DEVSEL_MASK) != 0x0) {
+		cmd &= ~PCI_STATUS_DEVSEL_MASK;
+		pci_write_config_word(dev, PCI_STATUS, cmd);
+	}
+	/*
+	 * Set to be prefetchable and put everything back based on old cfg.
 	 * it's possible that the reset of the V370PDC nuked the original
 	 * setup
-         */
+	 */
+	/*
+	   cfg |= PCI_BASE_ADDRESS_MEM_PREFETCH;
+	   pci_write_config_dword( dev, PCI_BASE_ADDRESS_0, cfg );
+	 */
+
 	/*
-        cfg |= PCI_BASE_ADDRESS_MEM_PREFETCH;
-	pci_write_config_dword( dev, PCI_BASE_ADDRESS_0, cfg );
-	*/
-
-        /*
-         * Turn PCI memory and I/O bus access back on
-         */
-        pci_write_config_word( dev, PCI_COMMAND,
-                               PCI_COMMAND_MEMORY | PCI_COMMAND_IO );
+	 * Turn PCI memory and I/O bus access back on
+	 */
+	pci_write_config_word(dev, PCI_COMMAND,
+			      PCI_COMMAND_MEMORY | PCI_COMMAND_IO);
 #ifdef CONFIG_MTD_PMC551_DEBUG
-        /*
-         * Some screen fun
-         */
-        printk(KERN_DEBUG "pmc551: %d%c (0x%x) of %sprefetchable memory at 0x%llx\n",
-	       (size<1024)?size:(size<1048576)?size>>10:size>>20,
-               (size<1024)?'B':(size<1048576)?'K':'M',
-	       size, ((dcmd&(0x1<<3)) == 0)?"non-":"",
-               (unsigned long long)((dev->resource[0].start)&PCI_BASE_ADDRESS_MEM_MASK));
-
-        /*
-         * Check to see the state of the memory
-         */
-        pci_read_config_dword( dev, PMC551_DRAM_BLK0, &dcmd );
-        printk(KERN_DEBUG "pmc551: DRAM_BLK0 Flags: %s,%s\n"
-			  "pmc551: DRAM_BLK0 Size: %d at %d\n"
-			  "pmc551: DRAM_BLK0 Row MUX: %d, Col MUX: %d\n",
-               (((0x1<<1)&dcmd) == 0)?"RW":"RO",
-               (((0x1<<0)&dcmd) == 0)?"Off":"On",
-	       PMC551_DRAM_BLK_GET_SIZE(dcmd),
-	       ((dcmd>>20)&0x7FF), ((dcmd>>13)&0x7), ((dcmd>>9)&0xF) );
-
-        pci_read_config_dword( dev, PMC551_DRAM_BLK1, &dcmd );
-        printk(KERN_DEBUG "pmc551: DRAM_BLK1 Flags: %s,%s\n"
-			  "pmc551: DRAM_BLK1 Size: %d at %d\n"
-			  "pmc551: DRAM_BLK1 Row MUX: %d, Col MUX: %d\n",
-               (((0x1<<1)&dcmd) == 0)?"RW":"RO",
-               (((0x1<<0)&dcmd) == 0)?"Off":"On",
-	       PMC551_DRAM_BLK_GET_SIZE(dcmd),
-	       ((dcmd>>20)&0x7FF), ((dcmd>>13)&0x7), ((dcmd>>9)&0xF) );
-
-        pci_read_config_dword( dev, PMC551_DRAM_BLK2, &dcmd );
-        printk(KERN_DEBUG "pmc551: DRAM_BLK2 Flags: %s,%s\n"
-			  "pmc551: DRAM_BLK2 Size: %d at %d\n"
-			  "pmc551: DRAM_BLK2 Row MUX: %d, Col MUX: %d\n",
-               (((0x1<<1)&dcmd) == 0)?"RW":"RO",
-               (((0x1<<0)&dcmd) == 0)?"Off":"On",
-	       PMC551_DRAM_BLK_GET_SIZE(dcmd),
-	       ((dcmd>>20)&0x7FF), ((dcmd>>13)&0x7), ((dcmd>>9)&0xF) );
-
-        pci_read_config_dword( dev, PMC551_DRAM_BLK3, &dcmd );
-        printk(KERN_DEBUG "pmc551: DRAM_BLK3 Flags: %s,%s\n"
-			  "pmc551: DRAM_BLK3 Size: %d at %d\n"
-			  "pmc551: DRAM_BLK3 Row MUX: %d, Col MUX: %d\n",
-               (((0x1<<1)&dcmd) == 0)?"RW":"RO",
-               (((0x1<<0)&dcmd) == 0)?"Off":"On",
-	       PMC551_DRAM_BLK_GET_SIZE(dcmd),
-	       ((dcmd>>20)&0x7FF), ((dcmd>>13)&0x7), ((dcmd>>9)&0xF) );
-
-        pci_read_config_word( dev, PCI_COMMAND, &cmd );
-        printk( KERN_DEBUG "pmc551: Memory Access %s\n",
-                (((0x1<<1)&cmd) == 0)?"off":"on" );
-        printk( KERN_DEBUG "pmc551: I/O Access %s\n",
-                (((0x1<<0)&cmd) == 0)?"off":"on" );
-
-        pci_read_config_word( dev, PCI_STATUS, &cmd );
-        printk( KERN_DEBUG "pmc551: Devsel %s\n",
-                ((PCI_STATUS_DEVSEL_MASK&cmd)==0x000)?"Fast":
-                ((PCI_STATUS_DEVSEL_MASK&cmd)==0x200)?"Medium":
-                ((PCI_STATUS_DEVSEL_MASK&cmd)==0x400)?"Slow":"Invalid" );
-
-        printk( KERN_DEBUG "pmc551: %sFast Back-to-Back\n",
-                ((PCI_COMMAND_FAST_BACK&cmd) == 0)?"Not ":"" );
-
-	pci_read_config_byte(dev, PMC551_SYS_CTRL_REG, &bcmd );
-	printk( KERN_DEBUG "pmc551: EEPROM is under %s control\n"
-			   "pmc551: System Control Register is %slocked to PCI access\n"
-			   "pmc551: System Control Register is %slocked to EEPROM access\n",
-		(bcmd&0x1)?"software":"hardware",
-		(bcmd&0x20)?"":"un", (bcmd&0x40)?"":"un");
+	/*
+	 * Some screen fun
+	 */
+	printk(KERN_DEBUG "pmc551: %d%c (0x%x) of %sprefetchable memory at "
+		"0x%llx\n", (size < 1024) ? size : (size < 1048576) ?
+		size >> 10 : size >> 20,
+		(size < 1024) ? 'B' : (size < 1048576) ? 'K' : 'M', size,
+		((dcmd & (0x1 << 3)) == 0) ? "non-" : "",
+		(unsigned long long)((dev->resource[0].start) &
+				    PCI_BASE_ADDRESS_MEM_MASK));
+
+	/*
+	 * Check to see the state of the memory
+	 */
+	pci_read_config_dword(dev, PMC551_DRAM_BLK0, &dcmd);
+	printk(KERN_DEBUG "pmc551: DRAM_BLK0 Flags: %s,%s\n"
+		"pmc551: DRAM_BLK0 Size: %d at %d\n"
+		"pmc551: DRAM_BLK0 Row MUX: %d, Col MUX: %d\n",
+		(((0x1 << 1) & dcmd) == 0) ? "RW" : "RO",
+		(((0x1 << 0) & dcmd) == 0) ? "Off" : "On",
+		PMC551_DRAM_BLK_GET_SIZE(dcmd),
+		((dcmd >> 20) & 0x7FF), ((dcmd >> 13) & 0x7),
+		((dcmd >> 9) & 0xF));
+
+	pci_read_config_dword(dev, PMC551_DRAM_BLK1, &dcmd);
+	printk(KERN_DEBUG "pmc551: DRAM_BLK1 Flags: %s,%s\n"
+		"pmc551: DRAM_BLK1 Size: %d at %d\n"
+		"pmc551: DRAM_BLK1 Row MUX: %d, Col MUX: %d\n",
+		(((0x1 << 1) & dcmd) == 0) ? "RW" : "RO",
+		(((0x1 << 0) & dcmd) == 0) ? "Off" : "On",
+		PMC551_DRAM_BLK_GET_SIZE(dcmd),
+		((dcmd >> 20) & 0x7FF), ((dcmd >> 13) & 0x7),
+		((dcmd >> 9) & 0xF));
+
+	pci_read_config_dword(dev, PMC551_DRAM_BLK2, &dcmd);
+	printk(KERN_DEBUG "pmc551: DRAM_BLK2 Flags: %s,%s\n"
+		"pmc551: DRAM_BLK2 Size: %d at %d\n"
+		"pmc551: DRAM_BLK2 Row MUX: %d, Col MUX: %d\n",
+		(((0x1 << 1) & dcmd) == 0) ? "RW" : "RO",
+		(((0x1 << 0) & dcmd) == 0) ? "Off" : "On",
+		PMC551_DRAM_BLK_GET_SIZE(dcmd),
+		((dcmd >> 20) & 0x7FF), ((dcmd >> 13) & 0x7),
+		((dcmd >> 9) & 0xF));
+
+	pci_read_config_dword(dev, PMC551_DRAM_BLK3, &dcmd);
+	printk(KERN_DEBUG "pmc551: DRAM_BLK3 Flags: %s,%s\n"
+		"pmc551: DRAM_BLK3 Size: %d at %d\n"
+		"pmc551: DRAM_BLK3 Row MUX: %d, Col MUX: %d\n",
+		(((0x1 << 1) & dcmd) == 0) ? "RW" : "RO",
+		(((0x1 << 0) & dcmd) == 0) ? "Off" : "On",
+		PMC551_DRAM_BLK_GET_SIZE(dcmd),
+		((dcmd >> 20) & 0x7FF), ((dcmd >> 13) & 0x7),
+		((dcmd >> 9) & 0xF));
+
+	pci_read_config_word(dev, PCI_COMMAND, &cmd);
+	printk(KERN_DEBUG "pmc551: Memory Access %s\n",
+		(((0x1 << 1) & cmd) == 0) ? "off" : "on");
+	printk(KERN_DEBUG "pmc551: I/O Access %s\n",
+		(((0x1 << 0) & cmd) == 0) ? "off" : "on");
+
+	pci_read_config_word(dev, PCI_STATUS, &cmd);
+	printk(KERN_DEBUG "pmc551: Devsel %s\n",
+		((PCI_STATUS_DEVSEL_MASK & cmd) == 0x000) ? "Fast" :
+		((PCI_STATUS_DEVSEL_MASK & cmd) == 0x200) ? "Medium" :
+		((PCI_STATUS_DEVSEL_MASK & cmd) == 0x400) ? "Slow" : "Invalid");
+
+	printk(KERN_DEBUG "pmc551: %sFast Back-to-Back\n",
+		((PCI_COMMAND_FAST_BACK & cmd) == 0) ? "Not " : "");
+
+	pci_read_config_byte(dev, PMC551_SYS_CTRL_REG, &bcmd);
+	printk(KERN_DEBUG "pmc551: EEPROM is under %s control\n"
+		"pmc551: System Control Register is %slocked to PCI access\n"
+		"pmc551: System Control Register is %slocked to EEPROM access\n",
+		(bcmd & 0x1) ? "software" : "hardware",
+		(bcmd & 0x20) ? "" : "un", (bcmd & 0x40) ? "" : "un");
 #endif
-        return size;
+	return size;
 }
 
 /*
  * Kernel version specific module stuffages
  */
 
-
 MODULE_LICENSE("GPL");
 MODULE_AUTHOR("Mark Ferrell <mferrell at mvista.com>");
 MODULE_DESCRIPTION(PMC551_VERSION);
@@ -628,11 +650,11 @@ MODULE_DESCRIPTION(PMC551_VERSION);
 /*
  * Stuff these outside the ifdef so as to not bust compiled in driver support
  */
-static int msize=0;
+static int msize = 0;
 #if defined(CONFIG_MTD_PMC551_APERTURE_SIZE)
-static int asize=CONFIG_MTD_PMC551_APERTURE_SIZE
+static int asize = CONFIG_MTD_PMC551_APERTURE_SIZE
 #else
-static int asize=0;
+static int asize = 0;
 #endif
 
 module_param(msize, int, 0);
@@ -645,164 +667,171 @@ MODULE_PARM_DESC(asize, "aperture size, 
  */
 static int __init init_pmc551(void)
 {
-        struct pci_dev *PCI_Device = NULL;
-        struct mypriv *priv;
-        int count, found=0;
-        struct mtd_info *mtd;
-        u32 length = 0;
-
-	if(msize) {
-		msize = (1 << (ffs(msize) - 1))<<20;
-		if (msize > (1<<30)) {
-			printk(KERN_NOTICE "pmc551: Invalid memory size [%d]\n", msize);
+	struct pci_dev *PCI_Device = NULL;
+	struct mypriv *priv;
+	int count, found = 0;
+	struct mtd_info *mtd;
+	u32 length = 0;
+
+	if (msize) {
+		msize = (1 << (ffs(msize) - 1)) << 20;
+		if (msize > (1 << 30)) {
+			printk(KERN_NOTICE "pmc551: Invalid memory size [%d]\n",
+				msize);
 			return -EINVAL;
 		}
 	}
 
-	if(asize) {
-		asize = (1 << (ffs(asize) - 1))<<20;
-		if (asize > (1<<30) ) {
-			printk(KERN_NOTICE "pmc551: Invalid aperture size [%d]\n", asize);
+	if (asize) {
+		asize = (1 << (ffs(asize) - 1)) << 20;
+		if (asize > (1 << 30)) {
+			printk(KERN_NOTICE "pmc551: Invalid aperture size "
+				"[%d]\n", asize);
 			return -EINVAL;
 		}
 	}
 
-        printk(KERN_INFO PMC551_VERSION);
-
-        /*
-         * PCU-bus chipset probe.
-         */
-        for( count = 0; count < MAX_MTD_DEVICES; count++ ) {
-
-                if ((PCI_Device = pci_find_device(PCI_VENDOR_ID_V3_SEMI,
-                                                  PCI_DEVICE_ID_V3_SEMI_V370PDC,
-						  PCI_Device ) ) == NULL) {
-                        break;
-                }
-
-                printk(KERN_NOTICE "pmc551: Found PCI V370PDC at 0x%llx\n",
-				    (unsigned long long)PCI_Device->resource[0].start);
-
-                /*
-                 * The PMC551 device acts VERY weird if you don't init it
-                 * first.  i.e. it will not correctly report devsel.  If for
-                 * some reason the sdram is in a wrote-protected state the
-                 * device will DEVSEL when it is written to causing problems
-                 * with the oldproc.c driver in
-                 * some kernels (2.2.*)
-                 */
-                if((length = fixup_pmc551(PCI_Device)) <= 0) {
-                        printk(KERN_NOTICE "pmc551: Cannot init SDRAM\n");
-                        break;
-                }
+	printk(KERN_INFO PMC551_VERSION);
+
+	/*
+	 * PCU-bus chipset probe.
+	 */
+	for (count = 0; count < MAX_MTD_DEVICES; count++) {
+
+		if ((PCI_Device = pci_find_device(PCI_VENDOR_ID_V3_SEMI,
+						  PCI_DEVICE_ID_V3_SEMI_V370PDC,
+						  PCI_Device)) == NULL) {
+			break;
+		}
+
+		printk(KERN_NOTICE "pmc551: Found PCI V370PDC at 0x%llx\n",
+			(unsigned long long)PCI_Device->resource[0].start);
+
+		/*
+		 * The PMC551 device acts VERY weird if you don't init it
+		 * first.  i.e. it will not correctly report devsel.  If for
+		 * some reason the sdram is in a wrote-protected state the
+		 * device will DEVSEL when it is written to causing problems
+		 * with the oldproc.c driver in
+		 * some kernels (2.2.*)
+		 */
+		if ((length = fixup_pmc551(PCI_Device)) <= 0) {
+			printk(KERN_NOTICE "pmc551: Cannot init SDRAM\n");
+			break;
+		}
 
 		/*
 		 * This is needed until the driver is capable of reading the
 		 * onboard I2C SROM to discover the "real" memory size.
 		 */
-		if(msize) {
+		if (msize) {
 			length = msize;
-			printk(KERN_NOTICE "pmc551: Using specified memory size 0x%x\n", length);
+			printk(KERN_NOTICE "pmc551: Using specified memory "
+				"size 0x%x\n", length);
 		} else {
 			msize = length;
 		}
 
-                mtd = kmalloc(sizeof(struct mtd_info), GFP_KERNEL);
-                if (!mtd) {
-                        printk(KERN_NOTICE "pmc551: Cannot allocate new MTD device.\n");
-                        break;
-                }
-
-                memset(mtd, 0, sizeof(struct mtd_info));
-
-                priv = kmalloc (sizeof(struct mypriv), GFP_KERNEL);
-                if (!priv) {
-                        printk(KERN_NOTICE "pmc551: Cannot allocate new MTD device.\n");
-                        kfree(mtd);
-                        break;
-                }
-                memset(priv, 0, sizeof(*priv));
-                mtd->priv = priv;
-                priv->dev = PCI_Device;
-
-		if(asize > length) {
-			printk(KERN_NOTICE "pmc551: reducing aperture size to fit %dM\n",length>>20);
+		mtd = kmalloc(sizeof(struct mtd_info), GFP_KERNEL);
+		if (!mtd) {
+			printk(KERN_NOTICE "pmc551: Cannot allocate new MTD "
+				"device.\n");
+			break;
+		}
+
+		memset(mtd, 0, sizeof(struct mtd_info));
+
+		priv = kmalloc(sizeof(struct mypriv), GFP_KERNEL);
+		if (!priv) {
+			printk(KERN_NOTICE "pmc551: Cannot allocate new MTD "
+				"device.\n");
+			kfree(mtd);
+			break;
+		}
+		memset(priv, 0, sizeof(*priv));
+		mtd->priv = priv;
+		priv->dev = PCI_Device;
+
+		if (asize > length) {
+			printk(KERN_NOTICE "pmc551: reducing aperture size to "
+				"fit %dM\n", length >> 20);
 			priv->asize = asize = length;
 		} else if (asize == 0 || asize == length) {
-			printk(KERN_NOTICE "pmc551: Using existing aperture size %dM\n", length>>20);
+			printk(KERN_NOTICE "pmc551: Using existing aperture "
+				"size %dM\n", length >> 20);
 			priv->asize = asize = length;
 		} else {
-			printk(KERN_NOTICE "pmc551: Using specified aperture size %dM\n", asize>>20);
+			printk(KERN_NOTICE "pmc551: Using specified aperture "
+				"size %dM\n", asize >> 20);
 			priv->asize = asize;
 		}
-                priv->start = ioremap(((PCI_Device->resource[0].start)
-                                       & PCI_BASE_ADDRESS_MEM_MASK),
-                                      priv->asize);
+		priv->start = ioremap(((PCI_Device->resource[0].start)
+					& PCI_BASE_ADDRESS_MEM_MASK),
+				      priv->asize);
 
 		if (!priv->start) {
 			printk(KERN_NOTICE "pmc551: Unable to map IO space\n");
-                        kfree(mtd->priv);
-                        kfree(mtd);
+			kfree(mtd->priv);
+			kfree(mtd);
 			break;
 		}
-
 #ifdef CONFIG_MTD_PMC551_DEBUG
-		printk( KERN_DEBUG "pmc551: setting aperture to %d\n",
-			ffs(priv->asize>>20)-1);
+		printk(KERN_DEBUG "pmc551: setting aperture to %d\n",
+			ffs(priv->asize >> 20) - 1);
 #endif
 
-                priv->base_map0 = ( PMC551_PCI_MEM_MAP_REG_EN
-				  | PMC551_PCI_MEM_MAP_ENABLE
-				  | (ffs(priv->asize>>20)-1)<<4 );
-                priv->curr_map0 = priv->base_map0;
-                pci_write_config_dword ( priv->dev, PMC551_PCI_MEM_MAP0,
-                                         priv->curr_map0 );
+		priv->base_map0 = (PMC551_PCI_MEM_MAP_REG_EN
+				   | PMC551_PCI_MEM_MAP_ENABLE
+				   | (ffs(priv->asize >> 20) - 1) << 4);
+		priv->curr_map0 = priv->base_map0;
+		pci_write_config_dword(priv->dev, PMC551_PCI_MEM_MAP0,
+					priv->curr_map0);
 
 #ifdef CONFIG_MTD_PMC551_DEBUG
-		printk( KERN_DEBUG "pmc551: aperture set to %d\n",
-			(priv->base_map0 & 0xF0)>>4 );
+		printk(KERN_DEBUG "pmc551: aperture set to %d\n",
+			(priv->base_map0 & 0xF0) >> 4);
 #endif
 
-                mtd->size 	= msize;
-                mtd->flags 	= MTD_CAP_RAM;
-                mtd->erase 	= pmc551_erase;
-                mtd->read 	= pmc551_read;
-                mtd->write 	= pmc551_write;
-                mtd->point 	= pmc551_point;
-                mtd->unpoint 	= pmc551_unpoint;
-                mtd->type 	= MTD_RAM;
-                mtd->name 	= "PMC551 RAM board";
-                mtd->erasesize 	= 0x10000;
-                mtd->writesize  = 1;
-                mtd->owner = THIS_MODULE;
-
-                if (add_mtd_device(mtd)) {
-                        printk(KERN_NOTICE "pmc551: Failed to register new device\n");
+		mtd->size = msize;
+		mtd->flags = MTD_CAP_RAM;
+		mtd->erase = pmc551_erase;
+		mtd->read = pmc551_read;
+		mtd->write = pmc551_write;
+		mtd->point = pmc551_point;
+		mtd->unpoint = pmc551_unpoint;
+		mtd->type = MTD_RAM;
+		mtd->name = "PMC551 RAM board";
+		mtd->erasesize = 0x10000;
+		mtd->writesize = 1;
+		mtd->owner = THIS_MODULE;
+
+		if (add_mtd_device(mtd)) {
+			printk(KERN_NOTICE "pmc551: Failed to register new "
+				"device\n");
 			iounmap(priv->start);
-                        kfree(mtd->priv);
-                        kfree(mtd);
-                        break;
-                }
-                printk(KERN_NOTICE "Registered pmc551 memory device.\n");
-                printk(KERN_NOTICE "Mapped %dM of memory from 0x%p to 0x%p\n",
-                       priv->asize>>20,
-                       priv->start,
-                       priv->start + priv->asize);
-                printk(KERN_NOTICE "Total memory is %d%c\n",
-	       		(length<1024)?length:
-				(length<1048576)?length>>10:length>>20,
-               		(length<1024)?'B':(length<1048576)?'K':'M');
+			kfree(mtd->priv);
+			kfree(mtd);
+			break;
+		}
+		printk(KERN_NOTICE "Registered pmc551 memory device.\n");
+		printk(KERN_NOTICE "Mapped %dM of memory from 0x%p to 0x%p\n",
+			priv->asize >> 20,
+			priv->start, priv->start + priv->asize);
+		printk(KERN_NOTICE "Total memory is %d%c\n",
+			(length < 1024) ? length :
+			(length < 1048576) ? length >> 10 : length >> 20,
+			(length < 1024) ? 'B' : (length < 1048576) ? 'K' : 'M');
 		priv->nextpmc551 = pmc551list;
 		pmc551list = mtd;
 		found++;
-        }
+	}
 
-        if( !pmc551list ) {
-                printk(KERN_NOTICE "pmc551: not detected\n");
-                return -ENODEV;
-        } else {
+	if (!pmc551list) {
+		printk(KERN_NOTICE "pmc551: not detected\n");
+		return -ENODEV;
+	} else {
 		printk(KERN_NOTICE "pmc551: %d pmc551 devices loaded\n", found);
-                return 0;
+		return 0;
 	}
 }
 
@@ -811,23 +840,23 @@ #endif
  */
 static void __exit cleanup_pmc551(void)
 {
-        int found=0;
-        struct mtd_info *mtd;
+	int found = 0;
+	struct mtd_info *mtd;
 	struct mypriv *priv;
 
-	while((mtd=pmc551list)) {
+	while ((mtd = pmc551list)) {
 		priv = mtd->priv;
 		pmc551list = priv->nextpmc551;
 
-		if(priv->start) {
-			printk (KERN_DEBUG "pmc551: unmapping %dM starting at 0x%p\n",
-				priv->asize>>20, priv->start);
-			iounmap (priv->start);
+		if (priv->start) {
+			printk(KERN_DEBUG "pmc551: unmapping %dM starting at "
+				"0x%p\n", priv->asize >> 20, priv->start);
+			iounmap(priv->start);
 		}
 
-		kfree (mtd->priv);
-		del_mtd_device (mtd);
-		kfree (mtd);
+		kfree(mtd->priv);
+		del_mtd_device(mtd);
+		kfree(mtd);
 		found++;
 	}
 



From jdub at us.ibm.com  Mon Sep 18 20:16:19 2006
From: jdub at us.ibm.com (Josh Boyer)
Date: Mon, 18 Sep 2006 19:16:19 -0500
Subject: [PATCH 2/4] pmc551 remove unnecessary braces
In-Reply-To: <91292912129122wcf1@karneval.cz>
References: <91292912129122wcf1@karneval.cz>
Message-ID: <1158624979.3600.31.camel@zod.rchland.ibm.com>

On Tue, 2006-09-19 at 00:47 +0200, Jiri Slaby wrote:
> 
> diff --git a/drivers/mtd/devices/pmc551.c b/drivers/mtd/devices/pmc551.c
> index 6d4d5a4..0ee22ca 100644
> --- a/drivers/mtd/devices/pmc551.c
> +++ b/drivers/mtd/devices/pmc551.c
> @@ -137,11 +137,11 @@ #endif
>  
>  	pmc551_point(mtd, instr->addr, instr->len, &retlen, &ptr);
>  
> -	if (soff_hi == eoff_hi || mtd->size == priv->asize) {
> +	if (soff_hi == eoff_hi || mtd->size == priv->asize)
>  		/* The whole thing fits within one access, so just one shot
>  		   will do it. */
>  		memset(ptr, 0xff, instr->len);
> -	} else {
> +	else {
>  		/* We have to do multiple writes to get all the data
>  		   written. */
>  		while (soff_hi != eoff_hi) {

I actually find this change to make the code less readable.  Yes, the
braces aren't technically necessary, but the else requires them, and the
comment block before the memset makes this multi-line.

This whole patch is highly user preference, but I'd rather these braces
stay.


> @@ -700,9 +695,8 @@ static int __init init_pmc551(void)
>  
>  		if ((PCI_Device = pci_find_device(PCI_VENDOR_ID_V3_SEMI,
>  						  PCI_DEVICE_ID_V3_SEMI_V370PDC,
> -						  PCI_Device)) == NULL) {
> +						  PCI_Device)) == NULL)
>  			break;
> -		}

1) If you're going for coding style, the assignment within the if
condition needs to be moved outside of it.

2) If you're not going to fix 1, then leave the braces.

josh




From jirislaby at gmail.com  Tue Sep 19 06:17:08 2006
From: jirislaby at gmail.com (Jiri Slaby)
Date: Tue, 19 Sep 2006 12:17:08 +0200
Subject: [PATCH 2/4] pmc551 remove unnecessary braces
In-Reply-To: <1158624979.3600.31.camel@zod.rchland.ibm.com>
References: <91292912129122wcf1@karneval.cz>
	<1158624979.3600.31.camel@zod.rchland.ibm.com>
Message-ID: <450FC3A4.9020402@gmail.com>

Josh Boyer wrote:
> On Tue, 2006-09-19 at 00:47 +0200, Jiri Slaby wrote:
>> diff --git a/drivers/mtd/devices/pmc551.c b/drivers/mtd/devices/pmc551.c
>> index 6d4d5a4..0ee22ca 100644
>> --- a/drivers/mtd/devices/pmc551.c
>> +++ b/drivers/mtd/devices/pmc551.c
>> @@ -137,11 +137,11 @@ #endif
>>  
>>  	pmc551_point(mtd, instr->addr, instr->len, &retlen, &ptr);
>>  
>> -	if (soff_hi == eoff_hi || mtd->size == priv->asize) {
>> +	if (soff_hi == eoff_hi || mtd->size == priv->asize)
>>  		/* The whole thing fits within one access, so just one shot
>>  		   will do it. */
>>  		memset(ptr, 0xff, instr->len);
>> -	} else {
>> +	else {
>>  		/* We have to do multiple writes to get all the data
>>  		   written. */
>>  		while (soff_hi != eoff_hi) {
> 
> I actually find this change to make the code less readable.  Yes, the
> braces aren't technically necessary, but the else requires them, and the
> comment block before the memset makes this multi-line.
> 
> This whole patch is highly user preference, but I'd rather these braces
> stay.

Yes, I agree. This was one of my old patches stored on other PC, that I find 
now. The patch definitely makes it ugly.

>> @@ -700,9 +695,8 @@ static int __init init_pmc551(void)
>>  
>>  		if ((PCI_Device = pci_find_device(PCI_VENDOR_ID_V3_SEMI,
>>  						  PCI_DEVICE_ID_V3_SEMI_V370PDC,
>> -						  PCI_Device)) == NULL) {
>> +						  PCI_Device)) == NULL)
>>  			break;
>> -		}
> 
> 1) If you're going for coding style, the assignment within the if
> condition needs to be moved outside of it.
> 
> 2) If you're not going to fix 1, then leave the braces.

1) is fine, I will do it, thanks for comments.

-- 
http://www.fi.muni.cz/~xslaby/            Jiri Slaby
faculty of informatics, masaryk university, brno, cz
e-mail: jirislaby gmail com, gpg pubkey fingerprint:
B674 9967 0407 CE62 ACC8  22A0 32CC 55C3 39D4 7A7E



From jirislaby at gmail.com  Tue Sep 19 15:55:18 2006
From: jirislaby at gmail.com (Jiri Slaby)
Date: Tue, 19 Sep 2006 21:55:18 +0200 (CEST)
Subject: [PATCH 2/3] pmc551 use kzalloc
Message-ID: <91new349121291221@karneval.cz>

pmc551 use kzalloc

Use kzalloc instad of kmalloc+memset(0).

Signed-off-by: Jiri Slaby <jirislaby at gmail.com>

---
commit eb0edd8068cde9b5e6afaf09065a94cb83c10efd
tree a2f56ac7c0f5cb8e0e3dba707faa68cc8d5c9952
parent 22f07f42debab2cc3b6ab895d2fa2c34d192c25c
author Jiri Slaby <jirislaby at gmail.com> Tue, 19 Sep 2006 21:33:07 +0200
committer Jiri Slaby <xslaby at anemoi.localdomain> Tue, 19 Sep 2006 21:33:07 +0200

 drivers/mtd/devices/pmc551.c |    7 ++-----
 1 files changed, 2 insertions(+), 5 deletions(-)

diff --git a/drivers/mtd/devices/pmc551.c b/drivers/mtd/devices/pmc551.c
index 4d40236..62a9188 100644
--- a/drivers/mtd/devices/pmc551.c
+++ b/drivers/mtd/devices/pmc551.c
@@ -732,23 +732,20 @@ static int __init init_pmc551(void)
 			msize = length;
 		}
 
-		mtd = kmalloc(sizeof(struct mtd_info), GFP_KERNEL);
+		mtd = kzalloc(sizeof(struct mtd_info), GFP_KERNEL);
 		if (!mtd) {
 			printk(KERN_NOTICE "pmc551: Cannot allocate new MTD "
 				"device.\n");
 			break;
 		}
 
-		memset(mtd, 0, sizeof(struct mtd_info));
-
-		priv = kmalloc(sizeof(struct mypriv), GFP_KERNEL);
+		priv = kzalloc(sizeof(struct mypriv), GFP_KERNEL);
 		if (!priv) {
 			printk(KERN_NOTICE "pmc551: Cannot allocate new MTD "
 				"device.\n");
 			kfree(mtd);
 			break;
 		}
-		memset(priv, 0, sizeof(*priv));
 		mtd->priv = priv;
 		priv->dev = PCI_Device;
 



From jirislaby at gmail.com  Tue Sep 19 15:55:06 2006
From: jirislaby at gmail.com (Jiri Slaby)
Date: Tue, 19 Sep 2006 21:55:06 +0200 (CEST)
Subject: [PATCH 1/3] pmc551 whitespace cleanup
Message-ID: <91anewaa292933121291221@karneval.cz>

pmc551 whitespace cleanup

Spaces were used for indent, there was more than 80 columns per line. Get
rid of that stuff.

Signed-off-by: Jiri Slaby <jirislaby at gmail.com>

---
commit 22f07f42debab2cc3b6ab895d2fa2c34d192c25c
tree 11ae1ed1123a77a12c1f7238d3cb14213dab3431
parent b1022ccd9ec9cb8d9503e649f62c0cd4784c4598
author Jiri Slaby <jirislaby at gmail.com> Tue, 19 Sep 2006 21:30:05 +0200
committer Jiri Slaby <xslaby at anemoi.localdomain> Tue, 19 Sep 2006 21:30:05 +0200

 drivers/mtd/devices/pmc551.c | 1163 ++++++++++++++++++++++--------------------
 1 files changed, 596 insertions(+), 567 deletions(-)

diff --git a/drivers/mtd/devices/pmc551.c b/drivers/mtd/devices/pmc551.c
index a03a8a7..4d40236 100644
--- a/drivers/mtd/devices/pmc551.c
+++ b/drivers/mtd/devices/pmc551.c
@@ -4,82 +4,82 @@
  * PMC551 PCI Mezzanine Ram Device
  *
  * Author:
- *       Mark Ferrell <mferrell at mvista.com>
- *       Copyright 1999,2000 Nortel Networks
+ *	Mark Ferrell <mferrell at mvista.com>
+ *	Copyright 1999,2000 Nortel Networks
  *
  * License:
- *	 As part of this driver was derived from the slram.c driver it
- *	 falls under the same license, which is GNU General Public
- *	 License v2
+ *	As part of this driver was derived from the slram.c driver it
+ *	falls under the same license, which is GNU General Public
+ *	License v2
  *
  * Description:
- *	 This driver is intended to support the PMC551 PCI Ram device
- *	 from Ramix Inc.  The PMC551 is a PMC Mezzanine module for
- *	 cPCI embedded systems.  The device contains a single SROM
- *	 that initially programs the V370PDC chipset onboard the
- *	 device, and various banks of DRAM/SDRAM onboard.  This driver
- *	 implements this PCI Ram device as an MTD (Memory Technology
- *	 Device) so that it can be used to hold a file system, or for
- *	 added swap space in embedded systems.  Since the memory on
- *	 this board isn't as fast as main memory we do not try to hook
- *	 it into main memory as that would simply reduce performance
- *	 on the system.  Using it as a block device allows us to use
- *	 it as high speed swap or for a high speed disk device of some
- *	 sort.  Which becomes very useful on diskless systems in the
- *	 embedded market I might add.
+ *	This driver is intended to support the PMC551 PCI Ram device
+ *	from Ramix Inc.  The PMC551 is a PMC Mezzanine module for
+ *	cPCI embedded systems.  The device contains a single SROM
+ *	that initially programs the V370PDC chipset onboard the
+ *	device, and various banks of DRAM/SDRAM onboard.  This driver
+ *	implements this PCI Ram device as an MTD (Memory Technology
+ *	Device) so that it can be used to hold a file system, or for
+ *	added swap space in embedded systems.  Since the memory on
+ *	this board isn't as fast as main memory we do not try to hook
+ *	it into main memory as that would simply reduce performance
+ *	on the system.  Using it as a block device allows us to use
+ *	it as high speed swap or for a high speed disk device of some
+ *	sort.  Which becomes very useful on diskless systems in the
+ *	embedded market I might add.
  *
  * Notes:
- *	 Due to what I assume is more buggy SROM, the 64M PMC551 I
- *	 have available claims that all 4 of it's DRAM banks have 64M
- *	 of ram configured (making a grand total of 256M onboard).
- *	 This is slightly annoying since the BAR0 size reflects the
- *	 aperture size, not the dram size, and the V370PDC supplies no
- *	 other method for memory size discovery.  This problem is
- *	 mostly only relevant when compiled as a module, as the
- *	 unloading of the module with an aperture size smaller then
- *	 the ram will cause the driver to detect the onboard memory
- *	 size to be equal to the aperture size when the module is
- *	 reloaded.  Soooo, to help, the module supports an msize
- *	 option to allow the specification of the onboard memory, and
- *	 an asize option, to allow the specification of the aperture
- *	 size.  The aperture must be equal to or less then the memory
- *	 size, the driver will correct this if you screw it up.  This
- *	 problem is not relevant for compiled in drivers as compiled
- *	 in drivers only init once.
+ *	Due to what I assume is more buggy SROM, the 64M PMC551 I
+ *	have available claims that all 4 of it's DRAM banks have 64M
+ *	of ram configured (making a grand total of 256M onboard).
+ *	This is slightly annoying since the BAR0 size reflects the
+ *	aperture size, not the dram size, and the V370PDC supplies no
+ *	other method for memory size discovery.  This problem is
+ *	mostly only relevant when compiled as a module, as the
+ *	unloading of the module with an aperture size smaller then
+ *	the ram will cause the driver to detect the onboard memory
+ *	size to be equal to the aperture size when the module is
+ *	reloaded.  Soooo, to help, the module supports an msize
+ *	option to allow the specification of the onboard memory, and
+ *	an asize option, to allow the specification of the aperture
+ *	size.  The aperture must be equal to or less then the memory
+ *	size, the driver will correct this if you screw it up.  This
+ *	problem is not relevant for compiled in drivers as compiled
+ *	in drivers only init once.
  *
  * Credits:
- *       Saeed Karamooz <saeed at ramix.com> of Ramix INC. for the
- *       initial example code of how to initialize this device and for
- *       help with questions I had concerning operation of the device.
+ *	Saeed Karamooz <saeed at ramix.com> of Ramix INC. for the
+ *	initial example code of how to initialize this device and for
+ *	help with questions I had concerning operation of the device.
  *
- *       Most of the MTD code for this driver was originally written
- *       for the slram.o module in the MTD drivers package which
- *       allows the mapping of system memory into an MTD device.
- *       Since the PMC551 memory module is accessed in the same
- *       fashion as system memory, the slram.c code became a very nice
- *       fit to the needs of this driver.  All we added was PCI
- *       detection/initialization to the driver and automatically figure
- *       out the size via the PCI detection.o, later changes by Corey
- *       Minyard set up the card to utilize a 1M sliding apature.
+ *	Most of the MTD code for this driver was originally written
+ *	for the slram.o module in the MTD drivers package which
+ *	allows the mapping of system memory into an MTD device.
+ *	Since the PMC551 memory module is accessed in the same
+ *	fashion as system memory, the slram.c code became a very nice
+ *	fit to the needs of this driver.  All we added was PCI
+ *	detection/initialization to the driver and automatically figure
+ *	out the size via the PCI detection.o, later changes by Corey
+ *	Minyard set up the card to utilize a 1M sliding apature.
  *
- *	 Corey Minyard <minyard at nortelnetworks.com>
- *       * Modified driver to utilize a sliding aperture instead of
- *         mapping all memory into kernel space which turned out to
- *         be very wasteful.
- *       * Located a bug in the SROM's initialization sequence that
- *         made the memory unusable, added a fix to code to touch up
- *         the DRAM some.
+ *	Corey Minyard <minyard at nortelnetworks.com>
+ *	* Modified driver to utilize a sliding aperture instead of
+ *	 mapping all memory into kernel space which turned out to
+ *	 be very wasteful.
+ *	* Located a bug in the SROM's initialization sequence that
+ *	 made the memory unusable, added a fix to code to touch up
+ *	 the DRAM some.
  *
  * Bugs/FIXME's:
- *       * MUST fix the init function to not spin on a register
- *       waiting for it to set .. this does not safely handle busted
- *       devices that never reset the register correctly which will
- *       cause the system to hang w/ a reboot being the only chance at
- *       recover. [sort of fixed, could be better]
- *       * Add I2C handling of the SROM so we can read the SROM's information
- *       about the aperture size.  This should always accurately reflect the
- *       onboard memory size.
- *       * Comb the init routine.  It's still a bit cludgy on a few things.
+ *	* MUST fix the init function to not spin on a register
+ *	waiting for it to set .. this does not safely handle busted
+ *	devices that never reset the register correctly which will
+ *	cause the system to hang w/ a reboot being the only chance at
+ *	recover. [sort of fixed, could be better]
+ *	* Add I2C handling of the SROM so we can read the SROM's information
+ *	about the aperture size.  This should always accurately reflect the
+ *	onboard memory size.
+ *	* Comb the init routine.  It's still a bit cludgy on a few things.
  */
 
 #include <linux/kernel.h>
@@ -105,74 +105,77 @@ #include <linux/mtd/compatmac.h>
 
 static struct mtd_info *pmc551list;
 
-static int pmc551_erase (struct mtd_info *mtd, struct erase_info *instr)
+static int pmc551_erase(struct mtd_info *mtd, struct erase_info *instr)
 {
-        struct mypriv *priv = mtd->priv;
-        u32 soff_hi, soff_lo; /* start address offset hi/lo */
-        u32 eoff_hi, eoff_lo; /* end address offset hi/lo */
-        unsigned long end;
+	struct mypriv *priv = mtd->priv;
+	u32 soff_hi, soff_lo;	/* start address offset hi/lo */
+	u32 eoff_hi, eoff_lo;	/* end address offset hi/lo */
+	unsigned long end;
 	u_char *ptr;
 	size_t retlen;
 
 #ifdef CONFIG_MTD_PMC551_DEBUG
-	printk(KERN_DEBUG "pmc551_erase(pos:%ld, len:%ld)\n", (long)instr->addr, (long)instr->len);
+	printk(KERN_DEBUG "pmc551_erase(pos:%ld, len:%ld)\n", (long)instr->addr,
+		(long)instr->len);
 #endif
 
-        end = instr->addr + instr->len - 1;
+	end = instr->addr + instr->len - 1;
 
-        /* Is it past the end? */
-        if ( end > mtd->size ) {
+	/* Is it past the end? */
+	if (end > mtd->size) {
 #ifdef CONFIG_MTD_PMC551_DEBUG
-	printk(KERN_DEBUG "pmc551_erase() out of bounds (%ld > %ld)\n", (long)end, (long)mtd->size);
+		printk(KERN_DEBUG "pmc551_erase() out of bounds (%ld > %ld)\n",
+			(long)end, (long)mtd->size);
 #endif
-                return -EINVAL;
-        }
-
-        eoff_hi = end & ~(priv->asize - 1);
-        soff_hi = instr->addr & ~(priv->asize - 1);
-        eoff_lo = end & (priv->asize - 1);
-        soff_lo = instr->addr & (priv->asize - 1);
-
-	pmc551_point (mtd, instr->addr, instr->len, &retlen, &ptr);
-
-        if ( soff_hi == eoff_hi || mtd->size == priv->asize) {
-                /* The whole thing fits within one access, so just one shot
-                   will do it. */
-                memset(ptr, 0xff, instr->len);
-        } else {
-                /* We have to do multiple writes to get all the data
-                   written. */
-                while (soff_hi != eoff_hi) {
+		return -EINVAL;
+	}
+
+	eoff_hi = end & ~(priv->asize - 1);
+	soff_hi = instr->addr & ~(priv->asize - 1);
+	eoff_lo = end & (priv->asize - 1);
+	soff_lo = instr->addr & (priv->asize - 1);
+
+	pmc551_point(mtd, instr->addr, instr->len, &retlen, &ptr);
+
+	if (soff_hi == eoff_hi || mtd->size == priv->asize) {
+		/* The whole thing fits within one access, so just one shot
+		   will do it. */
+		memset(ptr, 0xff, instr->len);
+	} else {
+		/* We have to do multiple writes to get all the data
+		   written. */
+		while (soff_hi != eoff_hi) {
 #ifdef CONFIG_MTD_PMC551_DEBUG
-			printk( KERN_DEBUG "pmc551_erase() soff_hi: %ld, eoff_hi: %ld\n", (long)soff_hi, (long)eoff_hi);
+			printk(KERN_DEBUG "pmc551_erase() soff_hi: %ld, "
+				"eoff_hi: %ld\n", (long)soff_hi, (long)eoff_hi);
 #endif
-                        memset(ptr, 0xff, priv->asize);
-                        if (soff_hi + priv->asize >= mtd->size) {
-                                goto out;
-                        }
-                        soff_hi += priv->asize;
-			pmc551_point (mtd,(priv->base_map0|soff_hi),
-				      priv->asize, &retlen, &ptr);
-                }
-                memset (ptr, 0xff, eoff_lo);
-        }
-
-out:
+			memset(ptr, 0xff, priv->asize);
+			if (soff_hi + priv->asize >= mtd->size) {
+				goto out;
+			}
+			soff_hi += priv->asize;
+			pmc551_point(mtd, (priv->base_map0 | soff_hi),
+				     priv->asize, &retlen, &ptr);
+		}
+		memset(ptr, 0xff, eoff_lo);
+	}
+
+      out:
 	instr->state = MTD_ERASE_DONE;
 #ifdef CONFIG_MTD_PMC551_DEBUG
 	printk(KERN_DEBUG "pmc551_erase() done\n");
 #endif
 
-        mtd_erase_callback(instr);
-        return 0;
+	mtd_erase_callback(instr);
+	return 0;
 }
 
-
-static int pmc551_point (struct mtd_info *mtd, loff_t from, size_t len, size_t *retlen, u_char **mtdbuf)
+static int pmc551_point(struct mtd_info *mtd, loff_t from, size_t len,
+			size_t * retlen, u_char ** mtdbuf)
 {
-        struct mypriv *priv = mtd->priv;
-        u32 soff_hi;
-        u32 soff_lo;
+	struct mypriv *priv = mtd->priv;
+	u32 soff_hi;
+	u32 soff_lo;
 
 #ifdef CONFIG_MTD_PMC551_DEBUG
 	printk(KERN_DEBUG "pmc551_point(%ld, %ld)\n", (long)from, (long)len);
@@ -180,18 +183,19 @@ #endif
 
 	if (from + len > mtd->size) {
 #ifdef CONFIG_MTD_PMC551_DEBUG
-		printk(KERN_DEBUG "pmc551_point() out of bounds (%ld > %ld)\n", (long)from+len, (long)mtd->size);
+		printk(KERN_DEBUG "pmc551_point() out of bounds (%ld > %ld)\n",
+			(long)from + len, (long)mtd->size);
 #endif
 		return -EINVAL;
 	}
 
-        soff_hi = from & ~(priv->asize - 1);
-        soff_lo = from & (priv->asize - 1);
+	soff_hi = from & ~(priv->asize - 1);
+	soff_lo = from & (priv->asize - 1);
 
 	/* Cheap hack optimization */
-	if( priv->curr_map0 != from ) {
-        	pci_write_config_dword ( priv->dev, PMC551_PCI_MEM_MAP0,
-                                 	(priv->base_map0 | soff_hi) );
+	if (priv->curr_map0 != from) {
+		pci_write_config_dword(priv->dev, PMC551_PCI_MEM_MAP0,
+					(priv->base_map0 | soff_hi));
 		priv->curr_map0 = soff_hi;
 	}
 
@@ -200,137 +204,144 @@ #endif
 	return 0;
 }
 
-
-static void pmc551_unpoint (struct mtd_info *mtd, u_char *addr, loff_t from, size_t len)
+static void pmc551_unpoint(struct mtd_info *mtd, u_char * addr, loff_t from,
+			   size_t len)
 {
 #ifdef CONFIG_MTD_PMC551_DEBUG
 	printk(KERN_DEBUG "pmc551_unpoint()\n");
 #endif
 }
 
-
-static int pmc551_read (struct mtd_info *mtd, loff_t from, size_t len, size_t *retlen, u_char *buf)
+static int pmc551_read(struct mtd_info *mtd, loff_t from, size_t len,
+			size_t * retlen, u_char * buf)
 {
-        struct mypriv *priv = mtd->priv;
-        u32 soff_hi, soff_lo; /* start address offset hi/lo */
-        u32 eoff_hi, eoff_lo; /* end address offset hi/lo */
-        unsigned long end;
+	struct mypriv *priv = mtd->priv;
+	u32 soff_hi, soff_lo;	/* start address offset hi/lo */
+	u32 eoff_hi, eoff_lo;	/* end address offset hi/lo */
+	unsigned long end;
 	u_char *ptr;
-        u_char *copyto = buf;
+	u_char *copyto = buf;
 
 #ifdef CONFIG_MTD_PMC551_DEBUG
-	printk(KERN_DEBUG "pmc551_read(pos:%ld, len:%ld) asize: %ld\n", (long)from, (long)len, (long)priv->asize);
+	printk(KERN_DEBUG "pmc551_read(pos:%ld, len:%ld) asize: %ld\n",
+		(long)from, (long)len, (long)priv->asize);
 #endif
 
-        end = from + len - 1;
+	end = from + len - 1;
 
-        /* Is it past the end? */
-        if (end > mtd->size) {
+	/* Is it past the end? */
+	if (end > mtd->size) {
 #ifdef CONFIG_MTD_PMC551_DEBUG
-	printk(KERN_DEBUG "pmc551_read() out of bounds (%ld > %ld)\n", (long) end, (long)mtd->size);
+		printk(KERN_DEBUG "pmc551_read() out of bounds (%ld > %ld)\n",
+			(long)end, (long)mtd->size);
 #endif
-                return -EINVAL;
-        }
-
-        soff_hi = from & ~(priv->asize - 1);
-        eoff_hi = end & ~(priv->asize - 1);
-        soff_lo = from & (priv->asize - 1);
-        eoff_lo = end & (priv->asize - 1);
-
-	pmc551_point (mtd, from, len, retlen, &ptr);
-
-        if (soff_hi == eoff_hi) {
-                /* The whole thing fits within one access, so just one shot
-                   will do it. */
-                memcpy(copyto, ptr, len);
-                copyto += len;
-        } else {
-                /* We have to do multiple writes to get all the data
-                   written. */
-                while (soff_hi != eoff_hi) {
+		return -EINVAL;
+	}
+
+	soff_hi = from & ~(priv->asize - 1);
+	eoff_hi = end & ~(priv->asize - 1);
+	soff_lo = from & (priv->asize - 1);
+	eoff_lo = end & (priv->asize - 1);
+
+	pmc551_point(mtd, from, len, retlen, &ptr);
+
+	if (soff_hi == eoff_hi) {
+		/* The whole thing fits within one access, so just one shot
+		   will do it. */
+		memcpy(copyto, ptr, len);
+		copyto += len;
+	} else {
+		/* We have to do multiple writes to get all the data
+		   written. */
+		while (soff_hi != eoff_hi) {
 #ifdef CONFIG_MTD_PMC551_DEBUG
-			printk( KERN_DEBUG "pmc551_read() soff_hi: %ld, eoff_hi: %ld\n", (long)soff_hi, (long)eoff_hi);
+			printk(KERN_DEBUG "pmc551_read() soff_hi: %ld, "
+				"eoff_hi: %ld\n", (long)soff_hi, (long)eoff_hi);
 #endif
-                        memcpy(copyto, ptr, priv->asize);
-                        copyto += priv->asize;
-                        if (soff_hi + priv->asize >= mtd->size) {
-                                goto out;
-                        }
-                        soff_hi += priv->asize;
-			pmc551_point (mtd, soff_hi, priv->asize, retlen, &ptr);
-                }
-                memcpy(copyto, ptr, eoff_lo);
-                copyto += eoff_lo;
-        }
-
-out:
+			memcpy(copyto, ptr, priv->asize);
+			copyto += priv->asize;
+			if (soff_hi + priv->asize >= mtd->size) {
+				goto out;
+			}
+			soff_hi += priv->asize;
+			pmc551_point(mtd, soff_hi, priv->asize, retlen, &ptr);
+		}
+		memcpy(copyto, ptr, eoff_lo);
+		copyto += eoff_lo;
+	}
+
+      out:
 #ifdef CONFIG_MTD_PMC551_DEBUG
 	printk(KERN_DEBUG "pmc551_read() done\n");
 #endif
-        *retlen = copyto - buf;
-        return 0;
+	*retlen = copyto - buf;
+	return 0;
 }
 
-static int pmc551_write (struct mtd_info *mtd, loff_t to, size_t len, size_t *retlen, const u_char *buf)
+static int pmc551_write(struct mtd_info *mtd, loff_t to, size_t len,
+			size_t * retlen, const u_char * buf)
 {
-        struct mypriv *priv = mtd->priv;
-        u32 soff_hi, soff_lo; /* start address offset hi/lo */
-        u32 eoff_hi, eoff_lo; /* end address offset hi/lo */
-        unsigned long end;
+	struct mypriv *priv = mtd->priv;
+	u32 soff_hi, soff_lo;	/* start address offset hi/lo */
+	u32 eoff_hi, eoff_lo;	/* end address offset hi/lo */
+	unsigned long end;
 	u_char *ptr;
-        const u_char *copyfrom = buf;
-
+	const u_char *copyfrom = buf;
 
 #ifdef CONFIG_MTD_PMC551_DEBUG
-	printk(KERN_DEBUG "pmc551_write(pos:%ld, len:%ld) asize:%ld\n", (long)to, (long)len, (long)priv->asize);
+	printk(KERN_DEBUG "pmc551_write(pos:%ld, len:%ld) asize:%ld\n",
+		(long)to, (long)len, (long)priv->asize);
 #endif
 
-        end = to + len - 1;
-        /* Is it past the end?  or did the u32 wrap? */
-        if (end > mtd->size ) {
+	end = to + len - 1;
+	/* Is it past the end?  or did the u32 wrap? */
+	if (end > mtd->size) {
 #ifdef CONFIG_MTD_PMC551_DEBUG
-	printk(KERN_DEBUG "pmc551_write() out of bounds (end: %ld, size: %ld, to: %ld)\n", (long) end, (long)mtd->size, (long)to);
+		printk(KERN_DEBUG "pmc551_write() out of bounds (end: %ld, "
+			"size: %ld, to: %ld)\n", (long)end, (long)mtd->size,
+			(long)to);
 #endif
-                return -EINVAL;
-        }
-
-        soff_hi = to & ~(priv->asize - 1);
-        eoff_hi = end & ~(priv->asize - 1);
-        soff_lo = to & (priv->asize - 1);
-        eoff_lo = end & (priv->asize - 1);
-
-	pmc551_point (mtd, to, len, retlen, &ptr);
-
-        if (soff_hi == eoff_hi) {
-                /* The whole thing fits within one access, so just one shot
-                   will do it. */
-                memcpy(ptr, copyfrom, len);
-                copyfrom += len;
-        } else {
-                /* We have to do multiple writes to get all the data
-                   written. */
-                while (soff_hi != eoff_hi) {
+		return -EINVAL;
+	}
+
+	soff_hi = to & ~(priv->asize - 1);
+	eoff_hi = end & ~(priv->asize - 1);
+	soff_lo = to & (priv->asize - 1);
+	eoff_lo = end & (priv->asize - 1);
+
+	pmc551_point(mtd, to, len, retlen, &ptr);
+
+	if (soff_hi == eoff_hi) {
+		/* The whole thing fits within one access, so just one shot
+		   will do it. */
+		memcpy(ptr, copyfrom, len);
+		copyfrom += len;
+	} else {
+		/* We have to do multiple writes to get all the data
+		   written. */
+		while (soff_hi != eoff_hi) {
 #ifdef CONFIG_MTD_PMC551_DEBUG
-			printk( KERN_DEBUG "pmc551_write() soff_hi: %ld, eoff_hi: %ld\n", (long)soff_hi, (long)eoff_hi);
+			printk(KERN_DEBUG "pmc551_write() soff_hi: %ld, "
+				"eoff_hi: %ld\n", (long)soff_hi, (long)eoff_hi);
 #endif
-                	memcpy(ptr, copyfrom, priv->asize);
-                	copyfrom += priv->asize;
-                        if (soff_hi >= mtd->size) {
-                                goto out;
-                        }
-                        soff_hi += priv->asize;
-			pmc551_point (mtd, soff_hi, priv->asize, retlen, &ptr);
-                }
-                memcpy(ptr, copyfrom, eoff_lo);
-                copyfrom += eoff_lo;
-        }
-
-out:
+			memcpy(ptr, copyfrom, priv->asize);
+			copyfrom += priv->asize;
+			if (soff_hi >= mtd->size) {
+				goto out;
+			}
+			soff_hi += priv->asize;
+			pmc551_point(mtd, soff_hi, priv->asize, retlen, &ptr);
+		}
+		memcpy(ptr, copyfrom, eoff_lo);
+		copyfrom += eoff_lo;
+	}
+
+      out:
 #ifdef CONFIG_MTD_PMC551_DEBUG
 	printk(KERN_DEBUG "pmc551_write() done\n");
 #endif
-        *retlen = copyfrom - buf;
-        return 0;
+	*retlen = copyfrom - buf;
+	return 0;
 }
 
 /*
@@ -345,58 +356,58 @@ #endif
  * mechanism
  * returns the size of the memory region found.
  */
-static u32 fixup_pmc551 (struct pci_dev *dev)
+static u32 fixup_pmc551(struct pci_dev *dev)
 {
 #ifdef CONFIG_MTD_PMC551_BUGFIX
-        u32 dram_data;
+	u32 dram_data;
 #endif
-        u32 size, dcmd, cfg, dtmp;
-        u16 cmd, tmp, i;
+	u32 size, dcmd, cfg, dtmp;
+	u16 cmd, tmp, i;
 	u8 bcmd, counter;
 
-        /* Sanity Check */
-        if(!dev) {
-                return -ENODEV;
-        }
+	/* Sanity Check */
+	if (!dev) {
+		return -ENODEV;
+	}
 
 	/*
 	 * Attempt to reset the card
 	 * FIXME: Stop Spinning registers
 	 */
-	counter=0;
+	counter = 0;
 	/* unlock registers */
-	pci_write_config_byte(dev, PMC551_SYS_CTRL_REG, 0xA5 );
+	pci_write_config_byte(dev, PMC551_SYS_CTRL_REG, 0xA5);
 	/* read in old data */
-	pci_read_config_byte(dev, PMC551_SYS_CTRL_REG, &bcmd );
+	pci_read_config_byte(dev, PMC551_SYS_CTRL_REG, &bcmd);
 	/* bang the reset line up and down for a few */
-	for(i=0;i<10;i++) {
-		counter=0;
+	for (i = 0; i < 10; i++) {
+		counter = 0;
 		bcmd &= ~0x80;
-		while(counter++ < 100) {
+		while (counter++ < 100) {
 			pci_write_config_byte(dev, PMC551_SYS_CTRL_REG, bcmd);
 		}
-		counter=0;
+		counter = 0;
 		bcmd |= 0x80;
-		while(counter++ < 100) {
+		while (counter++ < 100) {
 			pci_write_config_byte(dev, PMC551_SYS_CTRL_REG, bcmd);
 		}
 	}
-	bcmd |= (0x40|0x20);
+	bcmd |= (0x40 | 0x20);
 	pci_write_config_byte(dev, PMC551_SYS_CTRL_REG, bcmd);
 
-        /*
+	/*
 	 * Take care and turn off the memory on the device while we
 	 * tweak the configurations
 	 */
-        pci_read_config_word(dev, PCI_COMMAND, &cmd);
-        tmp = cmd & ~(PCI_COMMAND_IO|PCI_COMMAND_MEMORY);
-        pci_write_config_word(dev, PCI_COMMAND, tmp);
+	pci_read_config_word(dev, PCI_COMMAND, &cmd);
+	tmp = cmd & ~(PCI_COMMAND_IO | PCI_COMMAND_MEMORY);
+	pci_write_config_word(dev, PCI_COMMAND, tmp);
 
 	/*
 	 * Disable existing aperture before probing memory size
 	 */
 	pci_read_config_dword(dev, PMC551_PCI_MEM_MAP0, &dcmd);
-        dtmp=(dcmd|PMC551_PCI_MEM_MAP_ENABLE|PMC551_PCI_MEM_MAP_REG_EN);
+	dtmp = (dcmd | PMC551_PCI_MEM_MAP_ENABLE | PMC551_PCI_MEM_MAP_REG_EN);
 	pci_write_config_dword(dev, PMC551_PCI_MEM_MAP0, dtmp);
 	/*
 	 * Grab old BAR0 config so that we can figure out memory size
@@ -407,220 +418,231 @@ #endif
 	 * then write all 1's to the memory space, read back the result into
 	 * "size", and then write back all the old config.
 	 */
-	pci_read_config_dword( dev, PCI_BASE_ADDRESS_0, &cfg );
+	pci_read_config_dword(dev, PCI_BASE_ADDRESS_0, &cfg);
 #ifndef CONFIG_MTD_PMC551_BUGFIX
-	pci_write_config_dword( dev, PCI_BASE_ADDRESS_0, ~0 );
-	pci_read_config_dword( dev, PCI_BASE_ADDRESS_0, &size );
-	size = (size&PCI_BASE_ADDRESS_MEM_MASK);
-	size &= ~(size-1);
-	pci_write_config_dword( dev, PCI_BASE_ADDRESS_0, cfg );
+	pci_write_config_dword(dev, PCI_BASE_ADDRESS_0, ~0);
+	pci_read_config_dword(dev, PCI_BASE_ADDRESS_0, &size);
+	size = (size & PCI_BASE_ADDRESS_MEM_MASK);
+	size &= ~(size - 1);
+	pci_write_config_dword(dev, PCI_BASE_ADDRESS_0, cfg);
 #else
-        /*
-         * Get the size of the memory by reading all the DRAM size values
-         * and adding them up.
-         *
-         * KLUDGE ALERT: the boards we are using have invalid column and
-         * row mux values.  We fix them here, but this will break other
-         * memory configurations.
-         */
-        pci_read_config_dword(dev, PMC551_DRAM_BLK0, &dram_data);
-        size = PMC551_DRAM_BLK_GET_SIZE(dram_data);
-        dram_data = PMC551_DRAM_BLK_SET_COL_MUX(dram_data, 0x5);
-        dram_data = PMC551_DRAM_BLK_SET_ROW_MUX(dram_data, 0x9);
-        pci_write_config_dword(dev, PMC551_DRAM_BLK0, dram_data);
-
-        pci_read_config_dword(dev, PMC551_DRAM_BLK1, &dram_data);
-        size += PMC551_DRAM_BLK_GET_SIZE(dram_data);
-        dram_data = PMC551_DRAM_BLK_SET_COL_MUX(dram_data, 0x5);
-        dram_data = PMC551_DRAM_BLK_SET_ROW_MUX(dram_data, 0x9);
-        pci_write_config_dword(dev, PMC551_DRAM_BLK1, dram_data);
-
-        pci_read_config_dword(dev, PMC551_DRAM_BLK2, &dram_data);
-        size += PMC551_DRAM_BLK_GET_SIZE(dram_data);
-        dram_data = PMC551_DRAM_BLK_SET_COL_MUX(dram_data, 0x5);
-        dram_data = PMC551_DRAM_BLK_SET_ROW_MUX(dram_data, 0x9);
-        pci_write_config_dword(dev, PMC551_DRAM_BLK2, dram_data);
-
-        pci_read_config_dword(dev, PMC551_DRAM_BLK3, &dram_data);
-        size += PMC551_DRAM_BLK_GET_SIZE(dram_data);
-        dram_data = PMC551_DRAM_BLK_SET_COL_MUX(dram_data, 0x5);
-        dram_data = PMC551_DRAM_BLK_SET_ROW_MUX(dram_data, 0x9);
-        pci_write_config_dword(dev, PMC551_DRAM_BLK3, dram_data);
-
-        /*
-         * Oops .. something went wrong
-         */
-        if( (size &= PCI_BASE_ADDRESS_MEM_MASK) == 0) {
-                return -ENODEV;
-        }
-#endif /* CONFIG_MTD_PMC551_BUGFIX */
-
-	if ((cfg&PCI_BASE_ADDRESS_SPACE) != PCI_BASE_ADDRESS_SPACE_MEMORY) {
-                return -ENODEV;
+	/*
+	 * Get the size of the memory by reading all the DRAM size values
+	 * and adding them up.
+	 *
+	 * KLUDGE ALERT: the boards we are using have invalid column and
+	 * row mux values.  We fix them here, but this will break other
+	 * memory configurations.
+	 */
+	pci_read_config_dword(dev, PMC551_DRAM_BLK0, &dram_data);
+	size = PMC551_DRAM_BLK_GET_SIZE(dram_data);
+	dram_data = PMC551_DRAM_BLK_SET_COL_MUX(dram_data, 0x5);
+	dram_data = PMC551_DRAM_BLK_SET_ROW_MUX(dram_data, 0x9);
+	pci_write_config_dword(dev, PMC551_DRAM_BLK0, dram_data);
+
+	pci_read_config_dword(dev, PMC551_DRAM_BLK1, &dram_data);
+	size += PMC551_DRAM_BLK_GET_SIZE(dram_data);
+	dram_data = PMC551_DRAM_BLK_SET_COL_MUX(dram_data, 0x5);
+	dram_data = PMC551_DRAM_BLK_SET_ROW_MUX(dram_data, 0x9);
+	pci_write_config_dword(dev, PMC551_DRAM_BLK1, dram_data);
+
+	pci_read_config_dword(dev, PMC551_DRAM_BLK2, &dram_data);
+	size += PMC551_DRAM_BLK_GET_SIZE(dram_data);
+	dram_data = PMC551_DRAM_BLK_SET_COL_MUX(dram_data, 0x5);
+	dram_data = PMC551_DRAM_BLK_SET_ROW_MUX(dram_data, 0x9);
+	pci_write_config_dword(dev, PMC551_DRAM_BLK2, dram_data);
+
+	pci_read_config_dword(dev, PMC551_DRAM_BLK3, &dram_data);
+	size += PMC551_DRAM_BLK_GET_SIZE(dram_data);
+	dram_data = PMC551_DRAM_BLK_SET_COL_MUX(dram_data, 0x5);
+	dram_data = PMC551_DRAM_BLK_SET_ROW_MUX(dram_data, 0x9);
+	pci_write_config_dword(dev, PMC551_DRAM_BLK3, dram_data);
+
+	/*
+	 * Oops .. something went wrong
+	 */
+	if ((size &= PCI_BASE_ADDRESS_MEM_MASK) == 0) {
+		return -ENODEV;
 	}
+#endif				/* CONFIG_MTD_PMC551_BUGFIX */
 
-        /*
-         * Precharge Dram
-         */
-        pci_write_config_word( dev, PMC551_SDRAM_MA, 0x0400 );
-        pci_write_config_word( dev, PMC551_SDRAM_CMD, 0x00bf );
-
-        /*
-         * Wait until command has gone through
-         * FIXME: register spinning issue
-         */
-        do {	pci_read_config_word( dev, PMC551_SDRAM_CMD, &cmd );
-		if(counter++ > 100)break;
-        } while ( (PCI_COMMAND_IO) & cmd );
-
-        /*
+	if ((cfg & PCI_BASE_ADDRESS_SPACE) != PCI_BASE_ADDRESS_SPACE_MEMORY) {
+		return -ENODEV;
+	}
+
+	/*
+	 * Precharge Dram
+	 */
+	pci_write_config_word(dev, PMC551_SDRAM_MA, 0x0400);
+	pci_write_config_word(dev, PMC551_SDRAM_CMD, 0x00bf);
+
+	/*
+	 * Wait until command has gone through
+	 * FIXME: register spinning issue
+	 */
+	do {
+		pci_read_config_word(dev, PMC551_SDRAM_CMD, &cmd);
+		if (counter++ > 100)
+			break;
+	} while ((PCI_COMMAND_IO) & cmd);
+
+	/*
 	 * Turn on auto refresh
 	 * The loop is taken directly from Ramix's example code.  I assume that
 	 * this must be held high for some duration of time, but I can find no
 	 * documentation refrencing the reasons why.
-         */
-        for ( i = 1; i<=8 ; i++) {
-                pci_write_config_word (dev, PMC551_SDRAM_CMD, 0x0df);
-
-                /*
-                 * Make certain command has gone through
-                 * FIXME: register spinning issue
-                 */
-		counter=0;
-                do {	pci_read_config_word(dev, PMC551_SDRAM_CMD, &cmd);
-			if(counter++ > 100)break;
-                } while ( (PCI_COMMAND_IO) & cmd );
-        }
-
-        pci_write_config_word ( dev, PMC551_SDRAM_MA, 0x0020);
-        pci_write_config_word ( dev, PMC551_SDRAM_CMD, 0x0ff);
-
-        /*
-         * Wait until command completes
-         * FIXME: register spinning issue
-         */
-	counter=0;
-        do {	pci_read_config_word ( dev, PMC551_SDRAM_CMD, &cmd);
-		if(counter++ > 100)break;
-        } while ( (PCI_COMMAND_IO) & cmd );
-
-        pci_read_config_dword ( dev, PMC551_DRAM_CFG, &dcmd);
-        dcmd |= 0x02000000;
-        pci_write_config_dword ( dev, PMC551_DRAM_CFG, dcmd);
-
-        /*
-         * Check to make certain fast back-to-back, if not
-         * then set it so
-         */
-        pci_read_config_word( dev, PCI_STATUS, &cmd);
-        if((cmd&PCI_COMMAND_FAST_BACK) == 0) {
-                cmd |= PCI_COMMAND_FAST_BACK;
-                pci_write_config_word( dev, PCI_STATUS, cmd);
-        }
-
-        /*
-         * Check to make certain the DEVSEL is set correctly, this device
-         * has a tendancy to assert DEVSEL and TRDY when a write is performed
-         * to the memory when memory is read-only
-         */
-        if((cmd&PCI_STATUS_DEVSEL_MASK) != 0x0) {
-                cmd &= ~PCI_STATUS_DEVSEL_MASK;
-                pci_write_config_word( dev, PCI_STATUS, cmd );
-        }
-        /*
-         * Set to be prefetchable and put everything back based on old cfg.
+	 */
+	for (i = 1; i <= 8; i++) {
+		pci_write_config_word(dev, PMC551_SDRAM_CMD, 0x0df);
+
+		/*
+		 * Make certain command has gone through
+		 * FIXME: register spinning issue
+		 */
+		counter = 0;
+		do {
+			pci_read_config_word(dev, PMC551_SDRAM_CMD, &cmd);
+			if (counter++ > 100)
+				break;
+		} while ((PCI_COMMAND_IO) & cmd);
+	}
+
+	pci_write_config_word(dev, PMC551_SDRAM_MA, 0x0020);
+	pci_write_config_word(dev, PMC551_SDRAM_CMD, 0x0ff);
+
+	/*
+	 * Wait until command completes
+	 * FIXME: register spinning issue
+	 */
+	counter = 0;
+	do {
+		pci_read_config_word(dev, PMC551_SDRAM_CMD, &cmd);
+		if (counter++ > 100)
+			break;
+	} while ((PCI_COMMAND_IO) & cmd);
+
+	pci_read_config_dword(dev, PMC551_DRAM_CFG, &dcmd);
+	dcmd |= 0x02000000;
+	pci_write_config_dword(dev, PMC551_DRAM_CFG, dcmd);
+
+	/*
+	 * Check to make certain fast back-to-back, if not
+	 * then set it so
+	 */
+	pci_read_config_word(dev, PCI_STATUS, &cmd);
+	if ((cmd & PCI_COMMAND_FAST_BACK) == 0) {
+		cmd |= PCI_COMMAND_FAST_BACK;
+		pci_write_config_word(dev, PCI_STATUS, cmd);
+	}
+
+	/*
+	 * Check to make certain the DEVSEL is set correctly, this device
+	 * has a tendancy to assert DEVSEL and TRDY when a write is performed
+	 * to the memory when memory is read-only
+	 */
+	if ((cmd & PCI_STATUS_DEVSEL_MASK) != 0x0) {
+		cmd &= ~PCI_STATUS_DEVSEL_MASK;
+		pci_write_config_word(dev, PCI_STATUS, cmd);
+	}
+	/*
+	 * Set to be prefetchable and put everything back based on old cfg.
 	 * it's possible that the reset of the V370PDC nuked the original
 	 * setup
-         */
+	 */
 	/*
-        cfg |= PCI_BASE_ADDRESS_MEM_PREFETCH;
-	pci_write_config_dword( dev, PCI_BASE_ADDRESS_0, cfg );
-	*/
-
-        /*
-         * Turn PCI memory and I/O bus access back on
-         */
-        pci_write_config_word( dev, PCI_COMMAND,
-                               PCI_COMMAND_MEMORY | PCI_COMMAND_IO );
+	   cfg |= PCI_BASE_ADDRESS_MEM_PREFETCH;
+	   pci_write_config_dword( dev, PCI_BASE_ADDRESS_0, cfg );
+	 */
+
+	/*
+	 * Turn PCI memory and I/O bus access back on
+	 */
+	pci_write_config_word(dev, PCI_COMMAND,
+			      PCI_COMMAND_MEMORY | PCI_COMMAND_IO);
 #ifdef CONFIG_MTD_PMC551_DEBUG
-        /*
-         * Some screen fun
-         */
-        printk(KERN_DEBUG "pmc551: %d%c (0x%x) of %sprefetchable memory at 0x%llx\n",
-	       (size<1024)?size:(size<1048576)?size>>10:size>>20,
-               (size<1024)?'B':(size<1048576)?'K':'M',
-	       size, ((dcmd&(0x1<<3)) == 0)?"non-":"",
-               (unsigned long long)((dev->resource[0].start)&PCI_BASE_ADDRESS_MEM_MASK));
-
-        /*
-         * Check to see the state of the memory
-         */
-        pci_read_config_dword( dev, PMC551_DRAM_BLK0, &dcmd );
-        printk(KERN_DEBUG "pmc551: DRAM_BLK0 Flags: %s,%s\n"
-			  "pmc551: DRAM_BLK0 Size: %d at %d\n"
-			  "pmc551: DRAM_BLK0 Row MUX: %d, Col MUX: %d\n",
-               (((0x1<<1)&dcmd) == 0)?"RW":"RO",
-               (((0x1<<0)&dcmd) == 0)?"Off":"On",
-	       PMC551_DRAM_BLK_GET_SIZE(dcmd),
-	       ((dcmd>>20)&0x7FF), ((dcmd>>13)&0x7), ((dcmd>>9)&0xF) );
-
-        pci_read_config_dword( dev, PMC551_DRAM_BLK1, &dcmd );
-        printk(KERN_DEBUG "pmc551: DRAM_BLK1 Flags: %s,%s\n"
-			  "pmc551: DRAM_BLK1 Size: %d at %d\n"
-			  "pmc551: DRAM_BLK1 Row MUX: %d, Col MUX: %d\n",
-               (((0x1<<1)&dcmd) == 0)?"RW":"RO",
-               (((0x1<<0)&dcmd) == 0)?"Off":"On",
-	       PMC551_DRAM_BLK_GET_SIZE(dcmd),
-	       ((dcmd>>20)&0x7FF), ((dcmd>>13)&0x7), ((dcmd>>9)&0xF) );
-
-        pci_read_config_dword( dev, PMC551_DRAM_BLK2, &dcmd );
-        printk(KERN_DEBUG "pmc551: DRAM_BLK2 Flags: %s,%s\n"
-			  "pmc551: DRAM_BLK2 Size: %d at %d\n"
-			  "pmc551: DRAM_BLK2 Row MUX: %d, Col MUX: %d\n",
-               (((0x1<<1)&dcmd) == 0)?"RW":"RO",
-               (((0x1<<0)&dcmd) == 0)?"Off":"On",
-	       PMC551_DRAM_BLK_GET_SIZE(dcmd),
-	       ((dcmd>>20)&0x7FF), ((dcmd>>13)&0x7), ((dcmd>>9)&0xF) );
-
-        pci_read_config_dword( dev, PMC551_DRAM_BLK3, &dcmd );
-        printk(KERN_DEBUG "pmc551: DRAM_BLK3 Flags: %s,%s\n"
-			  "pmc551: DRAM_BLK3 Size: %d at %d\n"
-			  "pmc551: DRAM_BLK3 Row MUX: %d, Col MUX: %d\n",
-               (((0x1<<1)&dcmd) == 0)?"RW":"RO",
-               (((0x1<<0)&dcmd) == 0)?"Off":"On",
-	       PMC551_DRAM_BLK_GET_SIZE(dcmd),
-	       ((dcmd>>20)&0x7FF), ((dcmd>>13)&0x7), ((dcmd>>9)&0xF) );
-
-        pci_read_config_word( dev, PCI_COMMAND, &cmd );
-        printk( KERN_DEBUG "pmc551: Memory Access %s\n",
-                (((0x1<<1)&cmd) == 0)?"off":"on" );
-        printk( KERN_DEBUG "pmc551: I/O Access %s\n",
-                (((0x1<<0)&cmd) == 0)?"off":"on" );
-
-        pci_read_config_word( dev, PCI_STATUS, &cmd );
-        printk( KERN_DEBUG "pmc551: Devsel %s\n",
-                ((PCI_STATUS_DEVSEL_MASK&cmd)==0x000)?"Fast":
-                ((PCI_STATUS_DEVSEL_MASK&cmd)==0x200)?"Medium":
-                ((PCI_STATUS_DEVSEL_MASK&cmd)==0x400)?"Slow":"Invalid" );
-
-        printk( KERN_DEBUG "pmc551: %sFast Back-to-Back\n",
-                ((PCI_COMMAND_FAST_BACK&cmd) == 0)?"Not ":"" );
-
-	pci_read_config_byte(dev, PMC551_SYS_CTRL_REG, &bcmd );
-	printk( KERN_DEBUG "pmc551: EEPROM is under %s control\n"
-			   "pmc551: System Control Register is %slocked to PCI access\n"
-			   "pmc551: System Control Register is %slocked to EEPROM access\n",
-		(bcmd&0x1)?"software":"hardware",
-		(bcmd&0x20)?"":"un", (bcmd&0x40)?"":"un");
+	/*
+	 * Some screen fun
+	 */
+	printk(KERN_DEBUG "pmc551: %d%c (0x%x) of %sprefetchable memory at "
+		"0x%llx\n", (size < 1024) ? size : (size < 1048576) ?
+		size >> 10 : size >> 20,
+		(size < 1024) ? 'B' : (size < 1048576) ? 'K' : 'M', size,
+		((dcmd & (0x1 << 3)) == 0) ? "non-" : "",
+		(unsigned long long)((dev->resource[0].start) &
+				    PCI_BASE_ADDRESS_MEM_MASK));
+
+	/*
+	 * Check to see the state of the memory
+	 */
+	pci_read_config_dword(dev, PMC551_DRAM_BLK0, &dcmd);
+	printk(KERN_DEBUG "pmc551: DRAM_BLK0 Flags: %s,%s\n"
+		"pmc551: DRAM_BLK0 Size: %d at %d\n"
+		"pmc551: DRAM_BLK0 Row MUX: %d, Col MUX: %d\n",
+		(((0x1 << 1) & dcmd) == 0) ? "RW" : "RO",
+		(((0x1 << 0) & dcmd) == 0) ? "Off" : "On",
+		PMC551_DRAM_BLK_GET_SIZE(dcmd),
+		((dcmd >> 20) & 0x7FF), ((dcmd >> 13) & 0x7),
+		((dcmd >> 9) & 0xF));
+
+	pci_read_config_dword(dev, PMC551_DRAM_BLK1, &dcmd);
+	printk(KERN_DEBUG "pmc551: DRAM_BLK1 Flags: %s,%s\n"
+		"pmc551: DRAM_BLK1 Size: %d at %d\n"
+		"pmc551: DRAM_BLK1 Row MUX: %d, Col MUX: %d\n",
+		(((0x1 << 1) & dcmd) == 0) ? "RW" : "RO",
+		(((0x1 << 0) & dcmd) == 0) ? "Off" : "On",
+		PMC551_DRAM_BLK_GET_SIZE(dcmd),
+		((dcmd >> 20) & 0x7FF), ((dcmd >> 13) & 0x7),
+		((dcmd >> 9) & 0xF));
+
+	pci_read_config_dword(dev, PMC551_DRAM_BLK2, &dcmd);
+	printk(KERN_DEBUG "pmc551: DRAM_BLK2 Flags: %s,%s\n"
+		"pmc551: DRAM_BLK2 Size: %d at %d\n"
+		"pmc551: DRAM_BLK2 Row MUX: %d, Col MUX: %d\n",
+		(((0x1 << 1) & dcmd) == 0) ? "RW" : "RO",
+		(((0x1 << 0) & dcmd) == 0) ? "Off" : "On",
+		PMC551_DRAM_BLK_GET_SIZE(dcmd),
+		((dcmd >> 20) & 0x7FF), ((dcmd >> 13) & 0x7),
+		((dcmd >> 9) & 0xF));
+
+	pci_read_config_dword(dev, PMC551_DRAM_BLK3, &dcmd);
+	printk(KERN_DEBUG "pmc551: DRAM_BLK3 Flags: %s,%s\n"
+		"pmc551: DRAM_BLK3 Size: %d at %d\n"
+		"pmc551: DRAM_BLK3 Row MUX: %d, Col MUX: %d\n",
+		(((0x1 << 1) & dcmd) == 0) ? "RW" : "RO",
+		(((0x1 << 0) & dcmd) == 0) ? "Off" : "On",
+		PMC551_DRAM_BLK_GET_SIZE(dcmd),
+		((dcmd >> 20) & 0x7FF), ((dcmd >> 13) & 0x7),
+		((dcmd >> 9) & 0xF));
+
+	pci_read_config_word(dev, PCI_COMMAND, &cmd);
+	printk(KERN_DEBUG "pmc551: Memory Access %s\n",
+		(((0x1 << 1) & cmd) == 0) ? "off" : "on");
+	printk(KERN_DEBUG "pmc551: I/O Access %s\n",
+		(((0x1 << 0) & cmd) == 0) ? "off" : "on");
+
+	pci_read_config_word(dev, PCI_STATUS, &cmd);
+	printk(KERN_DEBUG "pmc551: Devsel %s\n",
+		((PCI_STATUS_DEVSEL_MASK & cmd) == 0x000) ? "Fast" :
+		((PCI_STATUS_DEVSEL_MASK & cmd) == 0x200) ? "Medium" :
+		((PCI_STATUS_DEVSEL_MASK & cmd) == 0x400) ? "Slow" : "Invalid");
+
+	printk(KERN_DEBUG "pmc551: %sFast Back-to-Back\n",
+		((PCI_COMMAND_FAST_BACK & cmd) == 0) ? "Not " : "");
+
+	pci_read_config_byte(dev, PMC551_SYS_CTRL_REG, &bcmd);
+	printk(KERN_DEBUG "pmc551: EEPROM is under %s control\n"
+		"pmc551: System Control Register is %slocked to PCI access\n"
+		"pmc551: System Control Register is %slocked to EEPROM access\n",
+		(bcmd & 0x1) ? "software" : "hardware",
+		(bcmd & 0x20) ? "" : "un", (bcmd & 0x40) ? "" : "un");
 #endif
-        return size;
+	return size;
 }
 
 /*
  * Kernel version specific module stuffages
  */
 
-
 MODULE_LICENSE("GPL");
 MODULE_AUTHOR("Mark Ferrell <mferrell at mvista.com>");
 MODULE_DESCRIPTION(PMC551_VERSION);
@@ -628,11 +650,11 @@ MODULE_DESCRIPTION(PMC551_VERSION);
 /*
  * Stuff these outside the ifdef so as to not bust compiled in driver support
  */
-static int msize=0;
+static int msize = 0;
 #if defined(CONFIG_MTD_PMC551_APERTURE_SIZE)
-static int asize=CONFIG_MTD_PMC551_APERTURE_SIZE
+static int asize = CONFIG_MTD_PMC551_APERTURE_SIZE
 #else
-static int asize=0;
+static int asize = 0;
 #endif
 
 module_param(msize, int, 0);
@@ -645,172 +667,179 @@ MODULE_PARM_DESC(asize, "aperture size, 
  */
 static int __init init_pmc551(void)
 {
-        struct pci_dev *PCI_Device = NULL;
-        struct mypriv *priv;
-        int count, found=0;
-        struct mtd_info *mtd;
-        u32 length = 0;
-
-	if(msize) {
-		msize = (1 << (ffs(msize) - 1))<<20;
-		if (msize > (1<<30)) {
-			printk(KERN_NOTICE "pmc551: Invalid memory size [%d]\n", msize);
+	struct pci_dev *PCI_Device = NULL;
+	struct mypriv *priv;
+	int count, found = 0;
+	struct mtd_info *mtd;
+	u32 length = 0;
+
+	if (msize) {
+		msize = (1 << (ffs(msize) - 1)) << 20;
+		if (msize > (1 << 30)) {
+			printk(KERN_NOTICE "pmc551: Invalid memory size [%d]\n",
+				msize);
 			return -EINVAL;
 		}
 	}
 
-	if(asize) {
-		asize = (1 << (ffs(asize) - 1))<<20;
-		if (asize > (1<<30) ) {
-			printk(KERN_NOTICE "pmc551: Invalid aperture size [%d]\n", asize);
+	if (asize) {
+		asize = (1 << (ffs(asize) - 1)) << 20;
+		if (asize > (1 << 30)) {
+			printk(KERN_NOTICE "pmc551: Invalid aperture size "
+				"[%d]\n", asize);
 			return -EINVAL;
 		}
 	}
 
-        printk(KERN_INFO PMC551_VERSION);
-
-        /*
-         * PCU-bus chipset probe.
-         */
-        for( count = 0; count < MAX_MTD_DEVICES; count++ ) {
-
-                if ((PCI_Device = pci_get_device(PCI_VENDOR_ID_V3_SEMI,
-                                                  PCI_DEVICE_ID_V3_SEMI_V370PDC,
-						  PCI_Device ) ) == NULL) {
-                        break;
-                }
-
-                printk(KERN_NOTICE "pmc551: Found PCI V370PDC at 0x%llx\n",
-				    (unsigned long long)PCI_Device->resource[0].start);
-
-                /*
-                 * The PMC551 device acts VERY weird if you don't init it
-                 * first.  i.e. it will not correctly report devsel.  If for
-                 * some reason the sdram is in a wrote-protected state the
-                 * device will DEVSEL when it is written to causing problems
-                 * with the oldproc.c driver in
-                 * some kernels (2.2.*)
-                 */
-                if((length = fixup_pmc551(PCI_Device)) <= 0) {
-                        printk(KERN_NOTICE "pmc551: Cannot init SDRAM\n");
-                        break;
-                }
+	printk(KERN_INFO PMC551_VERSION);
+
+	/*
+	 * PCU-bus chipset probe.
+	 */
+	for (count = 0; count < MAX_MTD_DEVICES; count++) {
+
+		if ((PCI_Device = pci_get_device(PCI_VENDOR_ID_V3_SEMI,
+						  PCI_DEVICE_ID_V3_SEMI_V370PDC,
+						  PCI_Device)) == NULL) {
+			break;
+		}
+
+		printk(KERN_NOTICE "pmc551: Found PCI V370PDC at 0x%llx\n",
+			(unsigned long long)PCI_Device->resource[0].start);
+
+		/*
+		 * The PMC551 device acts VERY weird if you don't init it
+		 * first.  i.e. it will not correctly report devsel.  If for
+		 * some reason the sdram is in a wrote-protected state the
+		 * device will DEVSEL when it is written to causing problems
+		 * with the oldproc.c driver in
+		 * some kernels (2.2.*)
+		 */
+		if ((length = fixup_pmc551(PCI_Device)) <= 0) {
+			printk(KERN_NOTICE "pmc551: Cannot init SDRAM\n");
+			break;
+		}
 
 		/*
 		 * This is needed until the driver is capable of reading the
 		 * onboard I2C SROM to discover the "real" memory size.
 		 */
-		if(msize) {
+		if (msize) {
 			length = msize;
-			printk(KERN_NOTICE "pmc551: Using specified memory size 0x%x\n", length);
+			printk(KERN_NOTICE "pmc551: Using specified memory "
+				"size 0x%x\n", length);
 		} else {
 			msize = length;
 		}
 
-                mtd = kmalloc(sizeof(struct mtd_info), GFP_KERNEL);
-                if (!mtd) {
-                        printk(KERN_NOTICE "pmc551: Cannot allocate new MTD device.\n");
-                        break;
-                }
-
-                memset(mtd, 0, sizeof(struct mtd_info));
-
-                priv = kmalloc (sizeof(struct mypriv), GFP_KERNEL);
-                if (!priv) {
-                        printk(KERN_NOTICE "pmc551: Cannot allocate new MTD device.\n");
-                        kfree(mtd);
-                        break;
-                }
-                memset(priv, 0, sizeof(*priv));
-                mtd->priv = priv;
-                priv->dev = PCI_Device;
-
-		if(asize > length) {
-			printk(KERN_NOTICE "pmc551: reducing aperture size to fit %dM\n",length>>20);
+		mtd = kmalloc(sizeof(struct mtd_info), GFP_KERNEL);
+		if (!mtd) {
+			printk(KERN_NOTICE "pmc551: Cannot allocate new MTD "
+				"device.\n");
+			break;
+		}
+
+		memset(mtd, 0, sizeof(struct mtd_info));
+
+		priv = kmalloc(sizeof(struct mypriv), GFP_KERNEL);
+		if (!priv) {
+			printk(KERN_NOTICE "pmc551: Cannot allocate new MTD "
+				"device.\n");
+			kfree(mtd);
+			break;
+		}
+		memset(priv, 0, sizeof(*priv));
+		mtd->priv = priv;
+		priv->dev = PCI_Device;
+
+		if (asize > length) {
+			printk(KERN_NOTICE "pmc551: reducing aperture size to "
+				"fit %dM\n", length >> 20);
 			priv->asize = asize = length;
 		} else if (asize == 0 || asize == length) {
-			printk(KERN_NOTICE "pmc551: Using existing aperture size %dM\n", length>>20);
+			printk(KERN_NOTICE "pmc551: Using existing aperture "
+				"size %dM\n", length >> 20);
 			priv->asize = asize = length;
 		} else {
-			printk(KERN_NOTICE "pmc551: Using specified aperture size %dM\n", asize>>20);
+			printk(KERN_NOTICE "pmc551: Using specified aperture "
+				"size %dM\n", asize >> 20);
 			priv->asize = asize;
 		}
-                priv->start = ioremap(((PCI_Device->resource[0].start)
-                                       & PCI_BASE_ADDRESS_MEM_MASK),
-                                      priv->asize);
+		priv->start = ioremap(((PCI_Device->resource[0].start)
+					& PCI_BASE_ADDRESS_MEM_MASK),
+				      priv->asize);
 
 		if (!priv->start) {
 			printk(KERN_NOTICE "pmc551: Unable to map IO space\n");
-                        kfree(mtd->priv);
-                        kfree(mtd);
+			kfree(mtd->priv);
+			kfree(mtd);
 			break;
 		}
-
 #ifdef CONFIG_MTD_PMC551_DEBUG
-		printk( KERN_DEBUG "pmc551: setting aperture to %d\n",
-			ffs(priv->asize>>20)-1);
+		printk(KERN_DEBUG "pmc551: setting aperture to %d\n",
+			ffs(priv->asize >> 20) - 1);
 #endif
 
-                priv->base_map0 = ( PMC551_PCI_MEM_MAP_REG_EN
-				  | PMC551_PCI_MEM_MAP_ENABLE
-				  | (ffs(priv->asize>>20)-1)<<4 );
-                priv->curr_map0 = priv->base_map0;
-                pci_write_config_dword ( priv->dev, PMC551_PCI_MEM_MAP0,
-                                         priv->curr_map0 );
+		priv->base_map0 = (PMC551_PCI_MEM_MAP_REG_EN
+				   | PMC551_PCI_MEM_MAP_ENABLE
+				   | (ffs(priv->asize >> 20) - 1) << 4);
+		priv->curr_map0 = priv->base_map0;
+		pci_write_config_dword(priv->dev, PMC551_PCI_MEM_MAP0,
+					priv->curr_map0);
 
 #ifdef CONFIG_MTD_PMC551_DEBUG
-		printk( KERN_DEBUG "pmc551: aperture set to %d\n",
-			(priv->base_map0 & 0xF0)>>4 );
+		printk(KERN_DEBUG "pmc551: aperture set to %d\n",
+			(priv->base_map0 & 0xF0) >> 4);
 #endif
 
-                mtd->size 	= msize;
-                mtd->flags 	= MTD_CAP_RAM;
-                mtd->erase 	= pmc551_erase;
-                mtd->read 	= pmc551_read;
-                mtd->write 	= pmc551_write;
-                mtd->point 	= pmc551_point;
-                mtd->unpoint 	= pmc551_unpoint;
-                mtd->type 	= MTD_RAM;
-                mtd->name 	= "PMC551 RAM board";
-                mtd->erasesize 	= 0x10000;
-                mtd->writesize  = 1;
-                mtd->owner = THIS_MODULE;
-
-                if (add_mtd_device(mtd)) {
-                        printk(KERN_NOTICE "pmc551: Failed to register new device\n");
+		mtd->size = msize;
+		mtd->flags = MTD_CAP_RAM;
+		mtd->erase = pmc551_erase;
+		mtd->read = pmc551_read;
+		mtd->write = pmc551_write;
+		mtd->point = pmc551_point;
+		mtd->unpoint = pmc551_unpoint;
+		mtd->type = MTD_RAM;
+		mtd->name = "PMC551 RAM board";
+		mtd->erasesize = 0x10000;
+		mtd->writesize = 1;
+		mtd->owner = THIS_MODULE;
+
+		if (add_mtd_device(mtd)) {
+			printk(KERN_NOTICE "pmc551: Failed to register new "
+				"device\n");
 			iounmap(priv->start);
-                        kfree(mtd->priv);
-                        kfree(mtd);
-                        break;
-                }
-
-                /* Keep a reference as the add_mtd_device worked */
-                pci_dev_get(PCI_Device);
-
-                printk(KERN_NOTICE "Registered pmc551 memory device.\n");
-                printk(KERN_NOTICE "Mapped %dM of memory from 0x%p to 0x%p\n",
-                       priv->asize>>20,
-                       priv->start,
-                       priv->start + priv->asize);
-                printk(KERN_NOTICE "Total memory is %d%c\n",
-	       		(length<1024)?length:
-				(length<1048576)?length>>10:length>>20,
-               		(length<1024)?'B':(length<1048576)?'K':'M');
+			kfree(mtd->priv);
+			kfree(mtd);
+			break;
+		}
+
+		/* Keep a reference as the add_mtd_device worked */
+		pci_dev_get(PCI_Device);
+
+		printk(KERN_NOTICE "Registered pmc551 memory device.\n");
+		printk(KERN_NOTICE "Mapped %dM of memory from 0x%p to 0x%p\n",
+			priv->asize >> 20,
+			priv->start, priv->start + priv->asize);
+		printk(KERN_NOTICE "Total memory is %d%c\n",
+			(length < 1024) ? length :
+			(length < 1048576) ? length >> 10 : length >> 20,
+			(length < 1024) ? 'B' : (length < 1048576) ? 'K' : 'M');
 		priv->nextpmc551 = pmc551list;
 		pmc551list = mtd;
 		found++;
-        }
+	}
 
-        /* Exited early, reference left over */
-        if (PCI_Device)
-        	pci_dev_put(PCI_Device);
+	/* Exited early, reference left over */
+	if (PCI_Device)
+		pci_dev_put(PCI_Device);
 
-        if( !pmc551list ) {
-                printk(KERN_NOTICE "pmc551: not detected\n");
-                return -ENODEV;
-        } else {
+	if (!pmc551list) {
+		printk(KERN_NOTICE "pmc551: not detected\n");
+		return -ENODEV;
+	} else {
 		printk(KERN_NOTICE "pmc551: %d pmc551 devices loaded\n", found);
-                return 0;
+		return 0;
 	}
 }
 
@@ -819,24 +848,24 @@ #endif
  */
 static void __exit cleanup_pmc551(void)
 {
-        int found=0;
-        struct mtd_info *mtd;
+	int found = 0;
+	struct mtd_info *mtd;
 	struct mypriv *priv;
 
-	while((mtd=pmc551list)) {
+	while ((mtd = pmc551list)) {
 		priv = mtd->priv;
 		pmc551list = priv->nextpmc551;
 
-		if(priv->start) {
-			printk (KERN_DEBUG "pmc551: unmapping %dM starting at 0x%p\n",
-				priv->asize>>20, priv->start);
-			iounmap (priv->start);
+		if (priv->start) {
+			printk(KERN_DEBUG "pmc551: unmapping %dM starting at "
+				"0x%p\n", priv->asize >> 20, priv->start);
+			iounmap(priv->start);
 		}
 		pci_dev_put(priv->dev);
 
-		kfree (mtd->priv);
-		del_mtd_device (mtd);
-		kfree (mtd);
+		kfree(mtd->priv);
+		del_mtd_device(mtd);
+		kfree(mtd);
 		found++;
 	}
 



From jirislaby at gmail.com  Tue Sep 19 15:55:28 2006
From: jirislaby at gmail.com (Jiri Slaby)
Date: Tue, 19 Sep 2006 21:55:28 +0200 (CEST)
Subject: [PATCH 3/3] pmc551 pci cleanup
Message-ID: <91292new449121291221@karneval.cz>

pmc551 pci cleanup

Use pci_resource_start for getting start of regions and pci_iomap to not
doing this directly by using dev->resource... (Thanks to Rolf Eike Beer)

Signed-off-by: Jiri Slaby <jirislaby at gmail.com>

---
commit f168fc8e075580212def9c838b21824faf516cf4
tree 41bdcab4eb268c8022d6eb370aed06688a599d5e
parent eb0edd8068cde9b5e6afaf09065a94cb83c10efd
author Jiri Slaby <jirislaby at gmail.com> Tue, 19 Sep 2006 21:48:40 +0200
committer Jiri Slaby <xslaby at anemoi.localdomain> Tue, 19 Sep 2006 21:48:40 +0200

 drivers/mtd/devices/pmc551.c |   13 +++++--------
 1 files changed, 5 insertions(+), 8 deletions(-)

diff --git a/drivers/mtd/devices/pmc551.c b/drivers/mtd/devices/pmc551.c
index 62a9188..354e165 100644
--- a/drivers/mtd/devices/pmc551.c
+++ b/drivers/mtd/devices/pmc551.c
@@ -568,8 +568,7 @@ #ifdef CONFIG_MTD_PMC551_DEBUG
 		size >> 10 : size >> 20,
 		(size < 1024) ? 'B' : (size < 1048576) ? 'K' : 'M', size,
 		((dcmd & (0x1 << 3)) == 0) ? "non-" : "",
-		(unsigned long long)((dev->resource[0].start) &
-				    PCI_BASE_ADDRESS_MEM_MASK));
+		(unsigned long long)pci_resource_start(dev, 0));
 
 	/*
 	 * Check to see the state of the memory
@@ -705,7 +704,7 @@ static int __init init_pmc551(void)
 		}
 
 		printk(KERN_NOTICE "pmc551: Found PCI V370PDC at 0x%llx\n",
-			(unsigned long long)PCI_Device->resource[0].start);
+			(unsigned long long)pci_resource_start(PCI_Device, 0));
 
 		/*
 		 * The PMC551 device acts VERY weird if you don't init it
@@ -762,9 +761,7 @@ static int __init init_pmc551(void)
 				"size %dM\n", asize >> 20);
 			priv->asize = asize;
 		}
-		priv->start = ioremap(((PCI_Device->resource[0].start)
-					& PCI_BASE_ADDRESS_MEM_MASK),
-				      priv->asize);
+		priv->start = pci_iomap(PCI_Device, 0, priv->asize);
 
 		if (!priv->start) {
 			printk(KERN_NOTICE "pmc551: Unable to map IO space\n");
@@ -805,7 +802,7 @@ #endif
 		if (add_mtd_device(mtd)) {
 			printk(KERN_NOTICE "pmc551: Failed to register new "
 				"device\n");
-			iounmap(priv->start);
+			pci_iounmap(PCI_Device, priv->start);
 			kfree(mtd->priv);
 			kfree(mtd);
 			break;
@@ -856,7 +853,7 @@ static void __exit cleanup_pmc551(void)
 		if (priv->start) {
 			printk(KERN_DEBUG "pmc551: unmapping %dM starting at "
 				"0x%p\n", priv->asize >> 20, priv->start);
-			iounmap(priv->start);
+			pci_iounmap(priv->dev, priv->start);
 		}
 		pci_dev_put(priv->dev);
 



From joakim.tjernlund at transmode.se  Wed Sep 20 05:30:41 2006
From: joakim.tjernlund at transmode.se (Joakim Tjernlund)
Date: Wed, 20 Sep 2006 11:30:41 +0200
Subject: JFFS2 appears to "freeze" during erase
Message-ID: <F6AD7E21CDF4E145A44F61F43EE6D9399B42C8@tmnt04.transmode.se>

Hi list

We have been using JFFS2 since around 2001 on linux 2.4 and it has
worked well
for us. Now we are upgrading to 2.6 and and I see a problem that was
solved 
long time ago in our JFFS2 tree: 

When JFFS2 is starts on a fresh FS without clean markers or if I remove
a large file,
futher FS operations hangs as if all pending erase operations has to be
completed
before futher activity is allowed.

Is this the expected behaviour today or a bug? I see this
on linux 2.6.11 and 2.6.17 on powerpc.
Flash: Intel Strata P30 family.

 Jocke

PS.
    http://lists.infradead.org/ seems dead.




From buytenh at wantstofly.org  Wed Sep 20 21:47:48 2006
From: buytenh at wantstofly.org (Lennert Buytenhek)
Date: Thu, 21 Sep 2006 03:47:48 +0200
Subject: [PATCH,RESEND] remove iq80310 map driver
Message-ID: <20060921014748.GA23373@xi.wantstofly.org>

The iq80310 mtd map driver depends on ARCH_IQ80310, which isn't
defined anywhere in the tree (as we don't have 80310 support), and
furthermore, everything the driver does can be done with physmap
instead.

Signed-off-by: Lennert Buytenhek <buytenh at wantstofly.org>

Index: linux-2.6.18-rc7/drivers/mtd/maps/Kconfig
===================================================================
--- linux-2.6.18-rc7.orig/drivers/mtd/maps/Kconfig
+++ linux-2.6.18-rc7/drivers/mtd/maps/Kconfig
@@ -447,14 +447,6 @@ config MTD_DC21285
 	  21285 bridge used with Intel's StrongARM processors. More info at
 	  <http://www.intel.com/design/bridge/docs/21285_documentation.htm>.
 
-config MTD_IQ80310
-	tristate "CFI Flash device mapped on the XScale IQ80310 board"
-	depends on MTD_CFI && ARCH_IQ80310
-	help
-	  This enables access routines for the flash chips on the Intel XScale
-	  IQ80310 evaluation board. If you have one of these boards and would
-	  like to use the flash chips on it, say 'Y'.
-
 config MTD_IXP4XX
 	tristate "CFI Flash device mapped on Intel IXP4xx based systems"
 	depends on MTD_CFI && MTD_COMPLEX_MAPPINGS && ARCH_IXP4XX
Index: linux-2.6.18-rc7/drivers/mtd/maps/Makefile
===================================================================
--- linux-2.6.18-rc7.orig/drivers/mtd/maps/Makefile
+++ linux-2.6.18-rc7/drivers/mtd/maps/Makefile
@@ -15,7 +15,6 @@ obj-$(CONFIG_MTD_CFI_FLAGADM)	+= cfi_fla
 obj-$(CONFIG_MTD_CSTM_MIPS_IXX)	+= cstm_mips_ixx.o
 obj-$(CONFIG_MTD_DC21285)	+= dc21285.o
 obj-$(CONFIG_MTD_DILNETPC)	+= dilnetpc.o
-obj-$(CONFIG_MTD_IQ80310)	+= iq80310.o
 obj-$(CONFIG_MTD_L440GX)	+= l440gx.o
 obj-$(CONFIG_MTD_AMD76XROM)	+= amd76xrom.o
 obj-$(CONFIG_MTD_ICHXROM)	+= ichxrom.o
Index: linux-2.6.18-rc7/drivers/mtd/maps/iq80310.c
===================================================================
--- linux-2.6.18-rc7.orig/drivers/mtd/maps/iq80310.c
+++ /dev/null
@@ -1,118 +0,0 @@
-/*
- * $Id: iq80310.c,v 1.21 2005/11/07 11:14:27 gleixner Exp $
- *
- * Mapping for the Intel XScale IQ80310 evaluation board
- *
- * Author:	Nicolas Pitre
- * Copyright:	(C) 2001 MontaVista Software Inc.
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
- */
-
-#include <linux/module.h>
-#include <linux/types.h>
-#include <linux/kernel.h>
-#include <linux/init.h>
-#include <linux/slab.h>
-#include <asm/io.h>
-#include <linux/mtd/mtd.h>
-#include <linux/mtd/map.h>
-#include <linux/mtd/partitions.h>
-
-
-#define WINDOW_ADDR 	0
-#define WINDOW_SIZE 	8*1024*1024
-#define BUSWIDTH 	1
-
-static struct mtd_info *mymtd;
-
-static struct map_info iq80310_map = {
-	.name = "IQ80310 flash",
-	.size = WINDOW_SIZE,
-	.bankwidth = BUSWIDTH,
-	.phys = WINDOW_ADDR
-};
-
-static struct mtd_partition iq80310_partitions[4] = {
-	{
-		.name =		"Firmware",
-		.size =		0x00080000,
-		.offset =	0,
-		.mask_flags =	MTD_WRITEABLE  /* force read-only */
-	},{
-		.name =		"Kernel",
-		.size =		0x000a0000,
-		.offset =	0x00080000,
-	},{
-		.name =		"Filesystem",
-		.size =		0x00600000,
-		.offset =	0x00120000
-	},{
-		.name =		"RedBoot",
-		.size =		0x000e0000,
-		.offset =	0x00720000,
-		.mask_flags =	MTD_WRITEABLE
-	}
-};
-
-static struct mtd_info *mymtd;
-static struct mtd_partition *parsed_parts;
-static const char *probes[] = { "RedBoot", "cmdlinepart", NULL };
-
-static int __init init_iq80310(void)
-{
-	struct mtd_partition *parts;
-	int nb_parts = 0;
-	int parsed_nr_parts = 0;
-	int ret;
-
-	iq80310_map.virt = ioremap(WINDOW_ADDR, WINDOW_SIZE);
-	if (!iq80310_map.virt) {
-		printk("Failed to ioremap\n");
-		return -EIO;
-	}
-	simple_map_init(&iq80310_map);
-
-	mymtd = do_map_probe("cfi_probe", &iq80310_map);
-	if (!mymtd) {
-		iounmap((void *)iq80310_map.virt);
-		return -ENXIO;
-	}
-	mymtd->owner = THIS_MODULE;
-
-	ret = parse_mtd_partitions(mymtd, probes, &parsed_parts, 0);
-
-	if (ret > 0)
-		parsed_nr_parts = ret;
-
-	if (parsed_nr_parts > 0) {
-		parts = parsed_parts;
-		nb_parts = parsed_nr_parts;
-	} else {
-		parts = iq80310_partitions;
-		nb_parts = ARRAY_SIZE(iq80310_partitions);
-	}
-	add_mtd_partitions(mymtd, parts, nb_parts);
-	return 0;
-}
-
-static void __exit cleanup_iq80310(void)
-{
-	if (mymtd) {
-		del_mtd_partitions(mymtd);
-		map_destroy(mymtd);
-		kfree(parsed_parts);
-	}
-	if (iq80310_map.virt)
-		iounmap((void *)iq80310_map.virt);
-}
-
-module_init(init_iq80310);
-module_exit(cleanup_iq80310);
-
-
-MODULE_LICENSE("GPL");
-MODULE_AUTHOR("Nicolas Pitre <nico at cam.org>");
-MODULE_DESCRIPTION("MTD map driver for Intel XScale IQ80310 evaluation board");



From choudhri at cs.tamu.edu  Wed Sep 20 12:30:26 2006
From: choudhri at cs.tamu.edu (Siddharth Choudhuri)
Date: Wed, 20 Sep 2006 11:30:26 -0500 (CDT)
Subject: Multiple writes to NAND OOB...
Message-ID: <Pine.GSO.4.58.0609201121180.26525@sun>

Hi,

I have the following question regarding multiple writes to OOB data:

Is it possible to write to the OOB data of the same page multiple times ?
If so, does it mean that the bytes being written are to different
locations(offsets) of the OOB because a byte cannot be rewritten in NAND
unless its block is erased ?

thanks,
-siddharth

_____________________________________________________________________
     Unix is user friendly - its just picky about its friends.
_____________________________________________________________________



From haver at vnet.ibm.com  Wed Sep 20 11:24:52 2006
From: haver at vnet.ibm.com (Frank Haverkamp)
Date: Wed, 20 Sep 2006 17:24:52 +0200
Subject: [PATCH] [MTD] NAND: Fix typo ndfc.c
Message-ID: <1158765892.5120.11.camel@localhost.localdomain>

[PATCH] [MTD] NAND: Fix typo ndfc.c

Due to this typo, a wrong ECC layout table is choosen.

Signed-off-by: Frank Haverkamp <haver at vnet.ibm.com>
---
 drivers/mtd/nand/ndfc.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Index: mtd-2.6.git/drivers/mtd/nand/ndfc.c
===================================================================
--- mtd-2.6.git.orig/drivers/mtd/nand/ndfc.c	2006-09-14
16:30:18.000000000 +0200
+++ mtd-2.6.git/drivers/mtd/nand/ndfc.c	2006-09-20 17:11:54.000000000
+0200
@@ -168,7 +168,7 @@ static void ndfc_chip_init(struct ndfc_n
 	chip->ecc.mode = NAND_ECC_HW;
 	chip->ecc.size = 256;
 	chip->ecc.bytes = 3;
-	chip->ecclayout = mtd->pl_chip->ecclayout;
+	chip->ecclayout = chip->ecc.layout = mtd->pl_chip->ecclayout;
 	mtd->mtd.priv = chip;
 	mtd->mtd.owner = THIS_MODULE;
 }





From dhowells at redhat.com  Wed Sep 20 14:24:07 2006
From: dhowells at redhat.com (David Howells)
Date: Wed, 20 Sep 2006 19:24:07 +0100
Subject: [PATCH][RFC] Abstract MTD mounting from JFFS2 and add
	super_block::s_mtd
Message-ID: <4587.1158776647@warthog.cambridge.redhat.com>


Abstract MTD mounting from JFFS2 so that it can be used by other filesystems
(such as ROMFS for MTD which is being developed).

This patch:

 (1) Creates get_sb_mtd() and kill_mtd_super() functions as analogues of the
     blockdev ones.  These functions live in the MTD core module rather than in
     fs/super.c because they require access to MTD facilities, and in any case
     only MTD-dependent code may use them.

     A new header file <linux/mtd/super.h> is provided for access to them.

 (2) Adds s_mtd to struct super_block as an analogue of s_bdev.  This is used
     to hold a pointer to the MTD device structure used by a superblock instead
     of a blockdev pointer.  It is also used to compare superblocks during
     mounting, as for blockdevs.

     This change shouldn't add all that much overhead since it adds a single
     pointer to the super_block struct, and there shouldn't be all that many of
     those in a system.

 (3) Removes the corresponding code from JFFS2 and has JFFS2 use the new
     facility instead.

I've considered putting s_bdev and s_mtd in an anonymous union together.  For
the most part this wouldn't be a problem as no filesystems use both and most of
the generic code follows suit.  However, there are a couple of places where
s_bdev is used if non-NULL without checking that it's a blockdev, and I'm not
sure how I'd deal with those as I'm not sure how else to check that a
filesystem is blockdev based (FS_REQUIRES_DEV maybe?).

I've also considered adding an analogue to FS_REQUIRES_DEV, but I'm not sure of
what use it would be, since it seems the only place it is used it
get_filesystem_list().  I could mark filesystems such as JFFS2 as being "mtd"
in /proc/filesystems, I suppose.

Thoughts anyone?

David

---
 drivers/mtd/Makefile      |    2 
 drivers/mtd/mtdsuper.c    |  231 +++++++++++++++++++++++++++++++++++++++++
 fs/jffs2/super.c          |  197 ++++-------------------------------
 include/linux/fs.h        |    1 
 include/linux/mtd/super.h |   30 +++++

diff --git a/drivers/mtd/Makefile b/drivers/mtd/Makefile
index 9282d4a..aca6b10 100644
--- a/drivers/mtd/Makefile
+++ b/drivers/mtd/Makefile
@@ -4,7 +4,7 @@ #
 # $Id: Makefile.common,v 1.7 2005/07/11 10:39:27 gleixner Exp $
 
 # Core functionality.
-mtd-y				:= mtdcore.o
+mtd-y				:= mtdcore.o mtdsuper.o
 mtd-$(CONFIG_MTD_PARTITIONS)	+= mtdpart.o
 obj-$(CONFIG_MTD)		+= $(mtd-y)
 
diff --git a/drivers/mtd/mtdsuper.c b/drivers/mtd/mtdsuper.c
new file mode 100644
index 0000000..7ffab96
--- /dev/null
+++ b/drivers/mtd/mtdsuper.c
@@ -0,0 +1,231 @@
+/* MTD-based superblock management
+ *
+ * Copyright (C) 2006 Red Hat, Inc. All Rights Reserved.
+ * Written by David Howells (dhowells at redhat.com)
+ *
+ * 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.
+ */
+
+#include <linux/mtd/super.h>
+#include <linux/namei.h>
+#include <linux/ctype.h>
+
+/*
+ * compare superblocks to see if they're equivalent
+ * - they are if the underlying MTD device is the same
+ */
+static int get_sb_mtd_compare(struct super_block *sb, void *_mtd)
+{
+	struct mtd_info *mtd = _mtd;
+
+	if (sb->s_mtd == mtd) {
+		DEBUG(2, "MTDSB: Match on device %d (\"%s\")\n",
+		      mtd->index, mtd->name);
+		return 1;
+	}
+
+	DEBUG(2, "MTDSB: No match, device %d (\"%s\"), device %d (\"%s\")\n",
+	      sb->s_mtd->index, sb->s_mtd->name, mtd->index, mtd->name);
+	return 0;
+}
+
+/*
+ * mark the superblock by the MTD device it is using
+ * - set the device number to be the correct MTD block device for pesuperstence
+ *   of NFS exports
+ */
+static int get_sb_mtd_set(struct super_block *sb, void *_mtd)
+{
+	struct mtd_info *mtd = _mtd;
+
+	sb->s_mtd = mtd;
+	sb->s_dev = MKDEV(MTD_BLOCK_MAJOR, mtd->index);
+	return 0;
+}
+
+/*
+ * get a superblock on an MTD-backed filesystem
+ */
+static int get_sb_mtd_aux(struct file_system_type *fs_type, int flags,
+			  const char *dev_name, void *data,
+			  struct mtd_info *mtd,
+			  int (*fill_super)(struct super_block *, void *, int),
+			  struct vfsmount *mnt)
+{
+	struct super_block *sb;
+	int ret;
+
+	sb = sget(fs_type, get_sb_mtd_compare, get_sb_mtd_set, mtd);
+	if (IS_ERR(sb))
+		goto out_error;
+
+	if (sb->s_root)
+		goto already_mounted;
+
+	/* fresh new superblock */
+	DEBUG(1, "MTDSB: New superblock for device %d (\"%s\")\n",
+	      mtd->index, mtd->name);
+
+	ret = fill_super(sb, data, flags & MS_SILENT ? 1 : 0);
+	if (ret < 0) {
+		up_write(&sb->s_umount);
+		deactivate_super(sb);
+		return ret;
+	}
+
+	/* go */
+	sb->s_flags |= MS_ACTIVE;
+	return simple_set_mnt(mnt, sb);
+
+	/* new mountpoint for an already mounted superblock */
+already_mounted:
+	DEBUG(1, "MTDSB: Device %d (\"%s\") is already mounted\n",
+	      mtd->index, mtd->name);
+	ret = simple_set_mnt(mnt, sb);
+	goto out_put;
+
+out_error:
+	ret = PTR_ERR(sb);
+out_put:
+	put_mtd_device(mtd);
+	return ret;
+}
+
+/*
+ * get a superblock on an MTD-backed filesystem by MTD device number
+ */
+static int get_sb_mtd_nr(struct file_system_type *fs_type, int flags,
+			 const char *dev_name, void *data, int mtdnr,
+			 int (*fill_super)(struct super_block *, void *, int),
+			 struct vfsmount *mnt)
+{
+	struct mtd_info *mtd;
+
+	mtd = get_mtd_device(NULL, mtdnr);
+	if (!mtd) {
+		DEBUG(0, "MTDSB: Device #%u doesn't appear to exist\n", mtdnr);
+		return -EINVAL;
+	}
+
+	return get_sb_mtd_aux(fs_type, flags, dev_name, data, mtd, fill_super,
+			      mnt);
+}
+
+/*
+ * set up an MTD-based superblock
+ */
+int get_sb_mtd(struct file_system_type *fs_type, int flags,
+	       const char *dev_name, void *data,
+	       int (*fill_super)(struct super_block *, void *, int),
+	       struct vfsmount *mnt)
+{
+	struct nameidata nd;
+	int mtdnr, ret;
+
+	if (!dev_name)
+		return -EINVAL;
+
+	DEBUG(2, "MTDSB: dev_name \"%s\"\n", dev_name);
+
+	/* the preferred way of mounting in future; especially when
+	 * CONFIG_BLOCK=n - we specify the underlying MTD device by number or
+	 * by name, so that we don't require block device support to be present
+	 * in the kernel. */
+	if (dev_name[0] == 'm' && dev_name[1] == 't' && dev_name[2] == 'd') {
+		if (dev_name[3] == ':') {
+			struct mtd_info *mtd;
+
+			/* mount by MTD device name */
+			DEBUG(1, "MTDSB: mtd:%%s, name \"%s\"\n",
+			      dev_name + 4);
+
+			for (mtdnr = 0; mtdnr < MAX_MTD_DEVICES; mtdnr++) {
+				mtd = get_mtd_device(NULL, mtdnr);
+				if (mtd) {
+					if (!strcmp(mtd->name, dev_name + 4))
+						return get_sb_mtd_aux(
+							fs_type, flags,
+							dev_name, data, mtd,
+							fill_super, mnt);
+
+					put_mtd_device(mtd);
+				}
+			}
+
+			printk(KERN_NOTICE "MTD:"
+			       " MTD device with name \"%s\" not found.\n",
+			       dev_name + 4);
+
+		} else if (isdigit(dev_name[3])) {
+			/* mount by MTD device number name */
+			char *endptr;
+
+			mtdnr = simple_strtoul(dev_name + 3, &endptr, 0);
+			if (!*endptr) {
+				/* It was a valid number */
+				DEBUG(1, "MTDSB: mtd%%d, mtdnr %d\n",
+				      mtdnr);
+				return get_sb_mtd_nr(fs_type, flags,
+						     dev_name, data,
+						     mtdnr, fill_super, mnt);
+			}
+		}
+	}
+
+	/* try the old way - the hack where we allowed users to mount
+	 * /dev/mtdblock$(n) but didn't actually _use_ the blockdev
+	 */
+	ret = path_lookup(dev_name, LOOKUP_FOLLOW, &nd);
+
+	DEBUG(1, "MTDSB: path_lookup() returned %d, inode %p\n",
+	      ret, nd.dentry ? nd.dentry->d_inode : NULL);
+
+	if (ret)
+		return ret;
+
+	ret = -EINVAL;
+
+	if (!S_ISBLK(nd.dentry->d_inode->i_mode))
+		goto out;
+
+	if (nd.mnt->mnt_flags & MNT_NODEV) {
+		ret = -EACCES;
+		goto out;
+	}
+
+	if (imajor(nd.dentry->d_inode) != MTD_BLOCK_MAJOR)
+		goto not_an_MTD_device;
+
+	mtdnr = iminor(nd.dentry->d_inode);
+	path_release(&nd);
+
+	return get_sb_mtd_nr(fs_type, flags, dev_name, data, mtdnr, fill_super,
+			     mnt);
+
+not_an_MTD_device:
+	if (!(flags & MS_SILENT))
+		printk(KERN_NOTICE
+		       "MTD: Attempt to mount non-MTD device \"%s\"\n",
+		       dev_name);
+out:
+	path_release(&nd);
+	return ret;
+
+}
+
+EXPORT_SYMBOL_GPL(get_sb_mtd);
+
+/*
+ * destroy an MTD-based superblock
+ */
+void kill_mtd_super(struct super_block *sb)
+{
+	generic_shutdown_super(sb);
+	put_mtd_device(sb->s_mtd);
+	sb->s_mtd = NULL;
+}
+
+EXPORT_SYMBOL_GPL(kill_mtd_super);
diff --git a/fs/jffs2/super.c b/fs/jffs2/super.c
index 68e3953..394d5ee 100644
--- a/fs/jffs2/super.c
+++ b/fs/jffs2/super.c
@@ -20,7 +20,7 @@ #include <linux/fs.h>
 #include <linux/mount.h>
 #include <linux/jffs2.h>
 #include <linux/pagemap.h>
-#include <linux/mtd/mtd.h>
+#include <linux/mtd/super.h>
 #include <linux/ctype.h>
 #include <linux/namei.h>
 #include "compr.h"
@@ -79,70 +79,27 @@ static struct super_operations jffs2_sup
 	.sync_fs =	jffs2_sync_fs,
 };
 
-static int jffs2_sb_compare(struct super_block *sb, void *data)
-{
-	struct jffs2_sb_info *p = data;
-	struct jffs2_sb_info *c = JFFS2_SB_INFO(sb);
-
-	/* The superblocks are considered to be equivalent if the underlying MTD
-	   device is the same one */
-	if (c->mtd == p->mtd) {
-		D1(printk(KERN_DEBUG "jffs2_sb_compare: match on device %d (\"%s\")\n", p->mtd->index, p->mtd->name));
-		return 1;
-	} else {
-		D1(printk(KERN_DEBUG "jffs2_sb_compare: No match, device %d (\"%s\"), device %d (\"%s\")\n",
-			  c->mtd->index, c->mtd->name, p->mtd->index, p->mtd->name));
-		return 0;
-	}
-}
-
-static int jffs2_sb_set(struct super_block *sb, void *data)
-{
-	struct jffs2_sb_info *p = data;
-
-	/* For persistence of NFS exports etc. we use the same s_dev
-	   each time we mount the device, don't just use an anonymous
-	   device */
-	sb->s_fs_info = p;
-	p->os_priv = sb;
-	sb->s_dev = MKDEV(MTD_BLOCK_MAJOR, p->mtd->index);
-
-	return 0;
-}
-
-static int jffs2_get_sb_mtd(struct file_system_type *fs_type,
-			    int flags, const char *dev_name,
-			    void *data, struct mtd_info *mtd,
-			    struct vfsmount *mnt)
+/*
+ * fill in the superblock
+ */
+static int jffs2_fill_super(struct super_block *sb, void *data, int silent)
 {
-	struct super_block *sb;
 	struct jffs2_sb_info *c;
-	int ret;
 
-	c = kmalloc(sizeof(*c), GFP_KERNEL);
+	D1(printk(KERN_DEBUG "jffs2_get_sb_mtd():"
+		  " New superblock for device %d (\"%s\")\n",
+		  sb->s_mtd->index, sb->s_mtd->name));
+
+	c = kzalloc(sizeof(*c), GFP_KERNEL);
 	if (!c)
 		return -ENOMEM;
-	memset(c, 0, sizeof(*c));
-	c->mtd = mtd;
-
-	sb = sget(fs_type, jffs2_sb_compare, jffs2_sb_set, c);
-
-	if (IS_ERR(sb))
-		goto out_error;
-
-	if (sb->s_root) {
-		/* New mountpoint for JFFS2 which is already mounted */
-		D1(printk(KERN_DEBUG "jffs2_get_sb_mtd(): Device %d (\"%s\") is already mounted\n",
-			  mtd->index, mtd->name));
-		ret = simple_set_mnt(mnt, sb);
-		goto out_put;
-	}
 
-	D1(printk(KERN_DEBUG "jffs2_get_sb_mtd(): New superblock for device %d (\"%s\")\n",
-		  mtd->index, mtd->name));
+	c->mtd = sb->s_mtd;
+	c->os_priv = sb;
+	sb->s_fs_info = c;
 
-	/* Initialize JFFS2 superblock locks, the further initialization will be
-	 * done later */
+	/* Initialize JFFS2 superblock locks, the further initialization will
+	 * be done later */
 	init_MUTEX(&c->alloc_sem);
 	init_MUTEX(&c->erase_free_sem);
 	init_waitqueue_head(&c->erase_wait);
@@ -151,133 +108,20 @@ static int jffs2_get_sb_mtd(struct file_
 	spin_lock_init(&c->inocache_lock);
 
 	sb->s_op = &jffs2_super_operations;
-	sb->s_flags = flags | MS_NOATIME;
+	sb->s_flags = sb->s_flags | MS_NOATIME;
 	sb->s_xattr = jffs2_xattr_handlers;
 #ifdef CONFIG_JFFS2_FS_POSIX_ACL
 	sb->s_flags |= MS_POSIXACL;
 #endif
-	ret = jffs2_do_fill_super(sb, data, flags & MS_SILENT ? 1 : 0);
-
-	if (ret) {
-		/* Failure case... */
-		up_write(&sb->s_umount);
-		deactivate_super(sb);
-		return ret;
-	}
-
-	sb->s_flags |= MS_ACTIVE;
-	return simple_set_mnt(mnt, sb);
-
-out_error:
-	ret = PTR_ERR(sb);
- out_put:
-	kfree(c);
-	put_mtd_device(mtd);
-
-	return ret;
-}
-
-static int jffs2_get_sb_mtdnr(struct file_system_type *fs_type,
-			      int flags, const char *dev_name,
-			      void *data, int mtdnr,
-			      struct vfsmount *mnt)
-{
-	struct mtd_info *mtd;
-
-	mtd = get_mtd_device(NULL, mtdnr);
-	if (!mtd) {
-		D1(printk(KERN_DEBUG "jffs2: MTD device #%u doesn't appear to exist\n", mtdnr));
-		return -EINVAL;
-	}
-
-	return jffs2_get_sb_mtd(fs_type, flags, dev_name, data, mtd, mnt);
+	return jffs2_do_fill_super(sb, data, silent);
 }
 
 static int jffs2_get_sb(struct file_system_type *fs_type,
 			int flags, const char *dev_name,
 			void *data, struct vfsmount *mnt)
 {
-	int err;
-	struct nameidata nd;
-	int mtdnr;
-
-	if (!dev_name)
-		return -EINVAL;
-
-	D1(printk(KERN_DEBUG "jffs2_get_sb(): dev_name \"%s\"\n", dev_name));
-
-	/* The preferred way of mounting in future; especially when
-	   CONFIG_BLK_DEV is implemented - we specify the underlying
-	   MTD device by number or by name, so that we don't require
-	   block device support to be present in the kernel. */
-
-	/* FIXME: How to do the root fs this way? */
-
-	if (dev_name[0] == 'm' && dev_name[1] == 't' && dev_name[2] == 'd') {
-		/* Probably mounting without the blkdev crap */
-		if (dev_name[3] == ':') {
-			struct mtd_info *mtd;
-
-			/* Mount by MTD device name */
-			D1(printk(KERN_DEBUG "jffs2_get_sb(): mtd:%%s, name \"%s\"\n", dev_name+4));
-			for (mtdnr = 0; mtdnr < MAX_MTD_DEVICES; mtdnr++) {
-				mtd = get_mtd_device(NULL, mtdnr);
-				if (mtd) {
-					if (!strcmp(mtd->name, dev_name+4))
-						return jffs2_get_sb_mtd(fs_type, flags, dev_name, data, mtd, mnt);
-					put_mtd_device(mtd);
-				}
-			}
-			printk(KERN_NOTICE "jffs2_get_sb(): MTD device with name \"%s\" not found.\n", dev_name+4);
-		} else if (isdigit(dev_name[3])) {
-			/* Mount by MTD device number name */
-			char *endptr;
-
-			mtdnr = simple_strtoul(dev_name+3, &endptr, 0);
-			if (!*endptr) {
-				/* It was a valid number */
-				D1(printk(KERN_DEBUG "jffs2_get_sb(): mtd%%d, mtdnr %d\n", mtdnr));
-				return jffs2_get_sb_mtdnr(fs_type, flags, dev_name, data, mtdnr, mnt);
-			}
-		}
-	}
-
-	/* Try the old way - the hack where we allowed users to mount
-	   /dev/mtdblock$(n) but didn't actually _use_ the blkdev */
-
-	err = path_lookup(dev_name, LOOKUP_FOLLOW, &nd);
-
-	D1(printk(KERN_DEBUG "jffs2_get_sb(): path_lookup() returned %d, inode %p\n",
-		  err, nd.dentry->d_inode));
-
-	if (err)
-		return err;
-
-	err = -EINVAL;
-
-	if (!S_ISBLK(nd.dentry->d_inode->i_mode))
-		goto out;
-
-	if (nd.mnt->mnt_flags & MNT_NODEV) {
-		err = -EACCES;
-		goto out;
-	}
-
-	if (imajor(nd.dentry->d_inode) != MTD_BLOCK_MAJOR) {
-		if (!(flags & MS_SILENT))
-			printk(KERN_NOTICE "Attempt to mount non-MTD device \"%s\" as JFFS2\n",
-			       dev_name);
-		goto out;
-	}
-
-	mtdnr = iminor(nd.dentry->d_inode);
-	path_release(&nd);
-
-	return jffs2_get_sb_mtdnr(fs_type, flags, dev_name, data, mtdnr, mnt);
-
-out:
-	path_release(&nd);
-	return err;
+	return get_sb_mtd(fs_type, flags, dev_name, data, jffs2_fill_super,
+			  mnt);
 }
 
 static void jffs2_put_super (struct super_block *sb)
@@ -312,8 +156,7 @@ static void jffs2_kill_sb(struct super_b
 	struct jffs2_sb_info *c = JFFS2_SB_INFO(sb);
 	if (!(sb->s_flags & MS_RDONLY))
 		jffs2_stop_garbage_collect_thread(c);
-	generic_shutdown_super(sb);
-	put_mtd_device(c->mtd);
+	kill_mtd_super(sb);
 	kfree(c);
 }
 
diff --git a/include/linux/fs.h b/include/linux/fs.h
index 555bc19..a36dc28 100644
--- a/include/linux/fs.h
+++ b/include/linux/fs.h
@@ -888,6 +888,7 @@ struct super_block {
 	struct list_head	s_files;
 
 	struct block_device	*s_bdev;
+	struct mtd_info		*s_mtd;
 	struct list_head	s_instances;
 	struct quota_info	s_dquot;	/* Diskquota specific options */
 
diff --git a/include/linux/mtd/super.h b/include/linux/mtd/super.h
new file mode 100644
index 0000000..8fcdbdf
--- /dev/null
+++ b/include/linux/mtd/super.h
@@ -0,0 +1,30 @@
+/* MTD-based superblock handling
+ *
+ * Copyright (C) 2006 Red Hat, Inc. All Rights Reserved.
+ * Written by David Howells (dhowells at redhat.com)
+ *
+ * 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.
+ */
+
+#ifndef __MTD_SUPER_H__
+#define __MTD_SUPER_H__
+
+#ifdef __KERNEL__
+
+#include <linux/mtd/mtd.h>
+#include <linux/fs.h>
+#include <linux/mount.h>
+
+extern int get_sb_mtd(struct file_system_type *fs_type, int flags,
+		      const char *dev_name, void *data,
+		      int (*fill_super)(struct super_block *, void *, int),
+		      struct vfsmount *mnt);
+extern void kill_mtd_super(struct super_block *sb);
+
+
+#endif /* __KERNEL__ */
+
+#endif /* __MTD_SUPER_H__ */



From Joakim.Tjernlund at transmode.se  Thu Sep 21 07:17:52 2006
From: Joakim.Tjernlund at transmode.se (Joakim Tjernlund)
Date: Thu, 21 Sep 2006 13:17:52 +0200
Subject: JFFS2 appears to "freeze" during erase
In-Reply-To: <ee47688c0609210125vf796aa2qb2817c4e77c42417@mail.gmail.com>
References: <F6AD7E21CDF4E145A44F61F43EE6D9399B42C8@tmnt04.transmode.se>
	<ee47688c0609210125vf796aa2qb2817c4e77c42417@mail.gmail.com>
Message-ID: <451274E0.6090602@transmode.se>

Radoslaw Bisewski wrote:
> This bug is caused by the use of erase_free_sem semaphore. Block erasing
> function jffs2_erase_block is called with erase_free_sem locked, i.e.
> erase_free_sem will be locked for the time needed to erase flash block (
> ~1 s for typical NOR chip), in the worst scenario access to file system
> may be blocked for a numer of seconds when the number of blocks is being
> erased. Workaround for this bug is simple - erase_free_sem cannot be
> locked when jffs2_erase_block function is called. See attached patch.
>
Me again

I think there is a bug in jffs2_erase_pending_blocks() after applying your patch:
	spin_unlock(&c->erase_completion_lock);
 done:
	D1(printk(KERN_DEBUG "jffs2_erase_pending_blocks completed\n"));

	up(&c->erase_free_sem);

the up(&c->erase_free_sem); needs to move to before done:

 Jocke




From jdub at us.ibm.com  Thu Sep 21 08:05:16 2006
From: jdub at us.ibm.com (Josh Boyer)
Date: Thu, 21 Sep 2006 07:05:16 -0500
Subject: JFFS2 appears to "freeze" during erase
In-Reply-To: <F6AD7E21CDF4E145A44F61F43EE6D9399B42C8@tmnt04.transmode.se>
References: <F6AD7E21CDF4E145A44F61F43EE6D9399B42C8@tmnt04.transmode.se>
Message-ID: <1158840316.3121.76.camel@zod.rchland.ibm.com>

On Wed, 2006-09-20 at 11:30 +0200, Joakim Tjernlund wrote:
>     http://lists.infradead.org/ seems dead.

It's IPv6 only at the moment.

josh




From amol at verismonetworks.com  Thu Sep 21 08:42:43 2006
From: amol at verismonetworks.com (Amol Lad)
Date: Thu, 21 Sep 2006 18:12:43 +0530
Subject: [PATCH] ioremap balanced with iounmap for drivers/mtd subsystem
Message-ID: <1158842563.28299.145.camel@amol.verismonetworks.com>

ioremap must be balanced by an iounmap and failing to do so can result
in a memory leak.

Tested (compilation only) with:
- allmodconfig
- Modifying drivers/mtd/maps/Kconfig and drivers/mtd/nand/Kconfig to
make sure that the changed file is compiling without warning

Signed-off-by: Amol Lad <amol at verismonetworks.com>

---
I'm not subsribed to linux-mtd so please cc me.

---
 drivers/mtd/maps/arctic-mtd.c     |   14 ++++++++++++--
 drivers/mtd/maps/beech-mtd.c      |   14 ++++++++++++--
 drivers/mtd/maps/cstm_mips_ixx.c  |   18 ++++++++++++++++--
 drivers/mtd/maps/ebony.c          |    4 ++++
 drivers/mtd/maps/fortunet.c       |    3 +++
 drivers/mtd/maps/lasat.c          |    2 ++
 drivers/mtd/maps/nettel.c         |   34 +++++++++++++++++++++++++++-------
 drivers/mtd/maps/ocotea.c         |    4 ++++
 drivers/mtd/maps/pcmciamtd.c      |    4 ++++
 drivers/mtd/maps/redwood.c        |   11 ++++++++++-
 drivers/mtd/maps/sbc8240.c        |   11 ++++++++++-
 drivers/mtd/maps/walnut.c         |    4 ++++
 drivers/mtd/nand/edb7312.c        |    3 +++
 drivers/mtd/nand/ppchameleonevb.c |    7 +++++++
 include/linux/utsrelease.h        |    1 +
 15 files changed, 119 insertions(+), 15 deletions(-)
---
diff -uprN -X linux-2.6.18-orig/Documentation/dontdiff linux-2.6.18-orig/drivers/mtd/maps/arctic-mtd.c linux-2.6.18/drivers/mtd/maps/arctic-mtd.c
--- linux-2.6.18-orig/drivers/mtd/maps/arctic-mtd.c	2006-08-24 02:46:33.000000000 +0530
+++ linux-2.6.18/drivers/mtd/maps/arctic-mtd.c	2006-09-21 16:51:44.000000000 +0530
@@ -96,6 +96,8 @@ static struct mtd_partition arctic_parti
 static int __init
 init_arctic_mtd(void)
 {
+	int err = 0;
+
 	printk("%s: 0x%08x at 0x%08x\n", NAME, SIZE, PADDR);
 
 	arctic_mtd_map.virt = ioremap(PADDR, SIZE);
@@ -109,12 +111,20 @@ init_arctic_mtd(void)
 	printk("%s: probing %d-bit flash bus\n", NAME, BUSWIDTH * 8);
 	arctic_mtd = do_map_probe("cfi_probe", &arctic_mtd_map);
 
-	if (!arctic_mtd)
+	if (!arctic_mtd) {
+		iounmap((void *) arctic_mtd_map.virt);
 		return -ENXIO;
+	}
 
 	arctic_mtd->owner = THIS_MODULE;
 
-	return add_mtd_partitions(arctic_mtd, arctic_partitions, PARTITIONS);
+	err = add_mtd_partitions(arctic_mtd, arctic_partitions, PARTITIONS);
+	if (err) {
+		printk("%s: add_mtd_partitions failed\n", NAME);
+		iounmap((void *) arctic_mtd_map.virt);
+	}
+
+	return err;
 }
 
 static void __exit
diff -uprN -X linux-2.6.18-orig/Documentation/dontdiff linux-2.6.18-orig/drivers/mtd/maps/beech-mtd.c linux-2.6.18/drivers/mtd/maps/beech-mtd.c
--- linux-2.6.18-orig/drivers/mtd/maps/beech-mtd.c	2006-08-24 02:46:33.000000000 +0530
+++ linux-2.6.18/drivers/mtd/maps/beech-mtd.c	2006-09-21 16:52:39.000000000 +0530
@@ -72,6 +72,8 @@ static struct mtd_partition beech_partit
 static int __init
 init_beech_mtd(void)
 {
+	int err = 0;
+
 	printk("%s: 0x%08x at 0x%08x\n", NAME, SIZE, PADDR);
 
 	beech_mtd_map.virt = ioremap(PADDR, SIZE);
@@ -86,12 +88,20 @@ init_beech_mtd(void)
 	printk("%s: probing %d-bit flash bus\n", NAME, BUSWIDTH * 8);
 	beech_mtd = do_map_probe("cfi_probe", &beech_mtd_map);
 
-	if (!beech_mtd)
+	if (!beech_mtd) {
+		iounmap((void *) beech_mtd_map.virt);
 		return -ENXIO;
+	}
 
 	beech_mtd->owner = THIS_MODULE;
 
-	return add_mtd_partitions(beech_mtd, beech_partitions, 2);
+	err = add_mtd_partitions(beech_mtd, beech_partitions, 2);
+	if (err) {
+		printk("%s: add_mtd_partitions failed\n", NAME);
+		iounmap((void *) beech_mtd_map.virt);
+	}
+
+	return err;
 }
 
 static void __exit
diff -uprN -X linux-2.6.18-orig/Documentation/dontdiff linux-2.6.18-orig/drivers/mtd/maps/cstm_mips_ixx.c linux-2.6.18/drivers/mtd/maps/cstm_mips_ixx.c
--- linux-2.6.18-orig/drivers/mtd/maps/cstm_mips_ixx.c	2006-09-21 10:15:35.000000000 +0530
+++ linux-2.6.18/drivers/mtd/maps/cstm_mips_ixx.c	2006-09-21 16:52:39.000000000 +0530
@@ -171,7 +171,14 @@ int __init init_cstm_mips_ixx(void)
 		cstm_mips_ixx_map[i].phys = cstm_mips_ixx_board_desc[i].window_addr;
 		cstm_mips_ixx_map[i].virt = ioremap(cstm_mips_ixx_board_desc[i].window_addr, cstm_mips_ixx_board_desc[i].window_size);
 		if (!cstm_mips_ixx_map[i].virt) {
+			int j = 0;
 			printk(KERN_WARNING "Failed to ioremap\n");
+			for (j = 0; j < i; j++) {
+				if (cstm_mips_ixx_map[j].virt) {
+					iounmap((void *)cstm_mips_ixx_map[j].virt);
+					cstm_mips_ixx_map[j].virt = 0;
+				}
+			}
 			return -EIO;
 	        }
 		cstm_mips_ixx_map[i].name = cstm_mips_ixx_board_desc[i].name;
@@ -204,8 +211,15 @@ int __init init_cstm_mips_ixx(void)
 	                cstm_mips_ixx_map[i].map_priv_2 = (unsigned long)mymtd;
 		        add_mtd_partitions(mymtd, parts, cstm_mips_ixx_board_desc[i].num_partitions);
 		}
-		else
-	           return -ENXIO;
+		else {
+			for (i = 0; i < PHYSMAP_NUMBER; i++) {
+				if (cstm_mips_ixx_map[i].virt) {
+					iounmap((void *)cstm_mips_ixx_map[i].virt);
+					cstm_mips_ixx_map[i].virt = 0;
+				}
+			}
+			return -ENXIO;
+		}
 	}
 	return 0;
 }
diff -uprN -X linux-2.6.18-orig/Documentation/dontdiff linux-2.6.18-orig/drivers/mtd/maps/ebony.c linux-2.6.18/drivers/mtd/maps/ebony.c
--- linux-2.6.18-orig/drivers/mtd/maps/ebony.c	2006-09-21 10:15:35.000000000 +0530
+++ linux-2.6.18/drivers/mtd/maps/ebony.c	2006-09-21 16:52:39.000000000 +0530
@@ -108,6 +108,7 @@ int __init init_ebony(void)
 					ARRAY_SIZE(ebony_small_partitions));
 	} else {
 		printk("map probe failed for flash\n");
+		iounmap(ebony_small_map.virt);
 		return -ENXIO;
 	}
 
@@ -117,6 +118,7 @@ int __init init_ebony(void)
 
 	if (!ebony_large_map.virt) {
 		printk("Failed to ioremap flash\n");
+		iounmap(ebony_small_map.virt);
 		return -EIO;
 	}
 
@@ -129,6 +131,8 @@ int __init init_ebony(void)
 					ARRAY_SIZE(ebony_large_partitions));
 	} else {
 		printk("map probe failed for flash\n");
+		iounmap(ebony_small_map.virt);
+		iounmap(ebony_large_map.virt);
 		return -ENXIO;
 	}
 
diff -uprN -X linux-2.6.18-orig/Documentation/dontdiff linux-2.6.18-orig/drivers/mtd/maps/fortunet.c linux-2.6.18/drivers/mtd/maps/fortunet.c
--- linux-2.6.18-orig/drivers/mtd/maps/fortunet.c	2006-08-24 02:46:33.000000000 +0530
+++ linux-2.6.18/drivers/mtd/maps/fortunet.c	2006-09-21 16:52:39.000000000 +0530
@@ -218,8 +218,11 @@ int __init init_fortunet(void)
 				map_regions[ix].map_info.size);
 			if(!map_regions[ix].map_info.virt)
 			{
+				int j = 0;
 				printk(MTD_FORTUNET_PK "%s flash failed to ioremap!\n",
 					map_regions[ix].map_info.name);
+				for (j = 0 ; j < ix; j++)
+					iounmap(map_regions[j].map_info.virt);
 				return -ENXIO;
 			}
 			simple_map_init(&map_regions[ix].map_info);
diff -uprN -X linux-2.6.18-orig/Documentation/dontdiff linux-2.6.18-orig/drivers/mtd/maps/lasat.c linux-2.6.18/drivers/mtd/maps/lasat.c
--- linux-2.6.18-orig/drivers/mtd/maps/lasat.c	2006-09-21 10:15:35.000000000 +0530
+++ linux-2.6.18/drivers/mtd/maps/lasat.c	2006-09-21 16:52:39.000000000 +0530
@@ -79,6 +79,7 @@ static int __init init_lasat(void)
 		return 0;
 	}
 
+	iounmap(lasat_map.virt);
 	return -ENXIO;
 }
 
@@ -89,6 +90,7 @@ static void __exit cleanup_lasat(void)
 		map_destroy(lasat_mtd);
 	}
 	if (lasat_map.virt) {
+		iounmap(lasat_map.virt);
 		lasat_map.virt = 0;
 	}
 }
diff -uprN -X linux-2.6.18-orig/Documentation/dontdiff linux-2.6.18-orig/drivers/mtd/maps/nettel.c linux-2.6.18/drivers/mtd/maps/nettel.c
--- linux-2.6.18-orig/drivers/mtd/maps/nettel.c	2006-09-21 10:15:35.000000000 +0530
+++ linux-2.6.18/drivers/mtd/maps/nettel.c	2006-09-21 16:55:13.000000000 +0530
@@ -277,6 +277,7 @@ int __init nettel_init(void)
 	nettel_amd_map.virt = ioremap_nocache(amdaddr, maxsize);
 	if (!nettel_amd_map.virt) {
 		printk("SNAPGEAR: failed to ioremap() BOOTCS\n");
+		iounmap(nettel_mmcrp);
 		return(-EIO);
 	}
 	simple_map_init(&nettel_amd_map);
@@ -337,7 +338,8 @@ int __init nettel_init(void)
 		nettel_amd_map.virt = NULL;
 #else
 		/* Only AMD flash supported */
-		return(-ENXIO);
+		rc = -ENXIO;
+		goto out_unmap2;
 #endif
 	}
 
@@ -361,14 +363,15 @@ int __init nettel_init(void)
 	nettel_intel_map.virt = ioremap_nocache(intel0addr, maxsize);
 	if (!nettel_intel_map.virt) {
 		printk("SNAPGEAR: failed to ioremap() ROMCS1\n");
-		return(-EIO);
+		rc = -EIO;
+		goto out_unmap2;
 	}
 	simple_map_init(&nettel_intel_map);
 
 	intel_mtd = do_map_probe("cfi_probe", &nettel_intel_map);
 	if (!intel_mtd) {
-		iounmap(nettel_intel_map.virt);
-		return(-ENXIO);
+		rc = -ENXIO;
+		goto out_unmap1;
 	}
 
 	/* Set PAR to the detected size */
@@ -394,13 +397,14 @@ int __init nettel_init(void)
 	nettel_intel_map.virt = ioremap_nocache(intel0addr, maxsize);
 	if (!nettel_intel_map.virt) {
 		printk("SNAPGEAR: failed to ioremap() ROMCS1/2\n");
-		return(-EIO);
+		rc = -EIO;
+		goto out_unmap2;
 	}
 
 	intel_mtd = do_map_probe("cfi_probe", &nettel_intel_map);
 	if (! intel_mtd) {
-		iounmap((void *) nettel_intel_map.virt);
-		return(-ENXIO);
+		rc = -ENXIO;
+		goto out_unmap1;
 	}
 
 	intel1size = intel_mtd->size - intel0size;
@@ -456,6 +460,18 @@ int __init nettel_init(void)
 #endif
 
 	return(rc);
+
+#ifdef CONFIG_MTD_CFI_INTELEXT
+out_unmap1:
+	iounmap((void *) nettel_intel_map.virt);
+#endif
+
+out_unmap2:
+	iounmap(nettel_mmcrp);
+	iounmap(nettel_amd_map.virt);
+
+	return(rc);
+		
 }
 
 /****************************************************************************/
@@ -469,6 +485,10 @@ void __exit nettel_cleanup(void)
 		del_mtd_partitions(amd_mtd);
 		map_destroy(amd_mtd);
 	}
+	if (nettel_mmcrp) {
+		iounmap(nettel_mmcrp);
+		nettel_mmcrp = NULL;
+	}
 	if (nettel_amd_map.virt) {
 		iounmap(nettel_amd_map.virt);
 		nettel_amd_map.virt = NULL;
diff -uprN -X linux-2.6.18-orig/Documentation/dontdiff linux-2.6.18-orig/drivers/mtd/maps/ocotea.c linux-2.6.18/drivers/mtd/maps/ocotea.c
--- linux-2.6.18-orig/drivers/mtd/maps/ocotea.c	2006-09-21 10:15:35.000000000 +0530
+++ linux-2.6.18/drivers/mtd/maps/ocotea.c	2006-09-21 16:52:39.000000000 +0530
@@ -97,6 +97,7 @@ int __init init_ocotea(void)
 					ARRAY_SIZE(ocotea_small_partitions));
 	} else {
 		printk("map probe failed for flash\n");
+		iounmap(ocotea_small_map.virt);
 		return -ENXIO;
 	}
 
@@ -106,6 +107,7 @@ int __init init_ocotea(void)
 
 	if (!ocotea_large_map.virt) {
 		printk("Failed to ioremap flash\n");
+		iounmap(ocotea_small_map.virt);
 		return -EIO;
 	}
 
@@ -118,6 +120,8 @@ int __init init_ocotea(void)
 					ARRAY_SIZE(ocotea_large_partitions));
 	} else {
 		printk("map probe failed for flash\n");
+		iounmap(ocotea_small_map.virt);
+		iounmap(ocotea_large_map.virt);
 		return -ENXIO;
 	}
 
diff -uprN -X linux-2.6.18-orig/Documentation/dontdiff linux-2.6.18-orig/drivers/mtd/maps/pcmciamtd.c linux-2.6.18/drivers/mtd/maps/pcmciamtd.c
--- linux-2.6.18-orig/drivers/mtd/maps/pcmciamtd.c	2006-09-21 10:15:35.000000000 +0530
+++ linux-2.6.18/drivers/mtd/maps/pcmciamtd.c	2006-09-21 16:52:39.000000000 +0530
@@ -602,6 +602,10 @@ static int pcmciamtd_config(struct pcmci
 	ret = pcmcia_request_configuration(link, &link->conf);
 	if(ret != CS_SUCCESS) {
 		cs_error(link, RequestConfiguration, ret);
+		if (dev->win_base) {
+			iounmap(dev->win_base);
+			dev->win_base = NULL;
+		}
 		return -ENODEV;
 	}
 
diff -uprN -X linux-2.6.18-orig/Documentation/dontdiff linux-2.6.18-orig/drivers/mtd/maps/redwood.c linux-2.6.18/drivers/mtd/maps/redwood.c
--- linux-2.6.18-orig/drivers/mtd/maps/redwood.c	2006-09-21 10:15:35.000000000 +0530
+++ linux-2.6.18/drivers/mtd/maps/redwood.c	2006-09-21 16:52:39.000000000 +0530
@@ -126,6 +126,8 @@ static struct mtd_info *redwood_mtd;
 
 int __init init_redwood_flash(void)
 {
+	int err = 0;
+
 	printk(KERN_NOTICE "redwood: flash mapping: %x at %x\n",
 			WINDOW_SIZE, WINDOW_ADDR);
 
@@ -141,11 +143,18 @@ int __init init_redwood_flash(void)
 
 	if (redwood_mtd) {
 		redwood_mtd->owner = THIS_MODULE;
-		return add_mtd_partitions(redwood_mtd,
+		err = add_mtd_partitions(redwood_mtd,
 				redwood_flash_partitions,
 				NUM_REDWOOD_FLASH_PARTITIONS);
+		if (err) {
+			printk("init_redwood_flash: add_mtd_partitions failed\n");
+			iounmap(redwood_flash_map.virt);
+		}
+		return err;
+
 	}
 
+	iounmap(redwood_flash_map.virt);
 	return -ENXIO;
 }
 
diff -uprN -X linux-2.6.18-orig/Documentation/dontdiff linux-2.6.18-orig/drivers/mtd/maps/sbc8240.c linux-2.6.18/drivers/mtd/maps/sbc8240.c
--- linux-2.6.18-orig/drivers/mtd/maps/sbc8240.c	2006-09-21 10:15:35.000000000 +0530
+++ linux-2.6.18/drivers/mtd/maps/sbc8240.c	2006-09-21 17:17:27.000000000 +0530
@@ -156,7 +156,7 @@ int __init init_sbc8240_mtd (void)
 	};
 
 	int devicesfound = 0;
-	int i;
+	int i,j;
 
 	for (i = 0; i < NUM_FLASH_BANKS; i++) {
 		printk (KERN_NOTICE MSG_PREFIX
@@ -166,6 +166,10 @@ int __init init_sbc8240_mtd (void)
 			(unsigned long) ioremap (pt[i].addr, pt[i].size);
 		if (!sbc8240_map[i].map_priv_1) {
 			printk (MSG_PREFIX "failed to ioremap\n");
+			for (j = 0; j < i; j++) {
+				iounmap((void *) sbc8240_map[j].map_priv_1);
+				sbc8240_map[j].map_priv_1 = 0;
+			}
 			return -EIO;
 		}
 		simple_map_init(&sbc8240_mtd[i]);
@@ -175,6 +179,11 @@ int __init init_sbc8240_mtd (void)
 		if (sbc8240_mtd[i]) {
 			sbc8240_mtd[i]->module = THIS_MODULE;
 			devicesfound++;
+		} else {
+			if (sbc8240_map[i].map_priv_1) {
+				iounmap((void *) sbc8240_map[i].map_priv_1);
+				sbc8240_map[i].map_priv_1 = 0;
+			}
 		}
 	}
 
diff -uprN -X linux-2.6.18-orig/Documentation/dontdiff linux-2.6.18-orig/drivers/mtd/maps/walnut.c linux-2.6.18/drivers/mtd/maps/walnut.c
--- linux-2.6.18-orig/drivers/mtd/maps/walnut.c	2006-09-21 10:15:35.000000000 +0530
+++ linux-2.6.18/drivers/mtd/maps/walnut.c	2006-09-21 16:52:39.000000000 +0530
@@ -68,6 +68,7 @@ int __init init_walnut(void)
 
 	if (WALNUT_FLASH_ONBD_N(fpga_brds1)) {
 		printk("The on-board flash is disabled (U79 sw 5)!");
+		iounmap(fpga_status_adr);
 		return -EIO;
 	}
 	if (WALNUT_FLASH_SRAM_SEL(fpga_brds1))
@@ -81,6 +82,7 @@ int __init init_walnut(void)
 
 	if (!walnut_map.virt) {
 		printk("Failed to ioremap flash.\n");
+		iounmap(fpga_status_adr);
 		return -EIO;
 	}
 
@@ -93,9 +95,11 @@ int __init init_walnut(void)
 					ARRAY_SIZE(walnut_partitions));
 	} else {
 		printk("map probe failed for flash\n");
+		iounmap(fpga_status_adr);
 		return -ENXIO;
 	}
 
+	iounmap(fpga_status_adr);
 	return 0;
 }
 
diff -uprN -X linux-2.6.18-orig/Documentation/dontdiff linux-2.6.18-orig/drivers/mtd/nand/edb7312.c linux-2.6.18/drivers/mtd/nand/edb7312.c
--- linux-2.6.18-orig/drivers/mtd/nand/edb7312.c	2006-09-21 10:15:35.000000000 +0530
+++ linux-2.6.18/drivers/mtd/nand/edb7312.c	2006-09-21 17:35:56.000000000 +0530
@@ -198,6 +198,9 @@ static void __exit ep7312_cleanup(void)
 	/* Release resources, unregister device */
 	nand_release(ap7312_mtd);
 
+	/* Release io resource */
+	iounmap((void *)this->IO_ADDR_R);
+
 	/* Free the MTD device structure */
 	kfree(ep7312_mtd);
 }
diff -uprN -X linux-2.6.18-orig/Documentation/dontdiff linux-2.6.18-orig/drivers/mtd/nand/ppchameleonevb.c linux-2.6.18/drivers/mtd/nand/ppchameleonevb.c
--- linux-2.6.18-orig/drivers/mtd/nand/ppchameleonevb.c	2006-09-21 10:15:35.000000000 +0530
+++ linux-2.6.18/drivers/mtd/nand/ppchameleonevb.c	2006-09-21 16:52:39.000000000 +0530
@@ -276,6 +276,7 @@ static int __init ppchameleonevb_init(vo
 	/* Scan to find existence of the device (it could not be mounted) */
 	if (nand_scan(ppchameleon_mtd, 1)) {
 		iounmap((void *)ppchameleon_fio_base);
+		ppchameleon_fio_base = NULL;
 		kfree(ppchameleon_mtd);
 		goto nand_evb_init;
 	}
@@ -314,6 +315,8 @@ static int __init ppchameleonevb_init(vo
 	ppchameleonevb_mtd = kmalloc(sizeof(struct mtd_info) + sizeof(struct nand_chip), GFP_KERNEL);
 	if (!ppchameleonevb_mtd) {
 		printk("Unable to allocate PPChameleonEVB NAND MTD device structure.\n");
+		if (ppchameleon_fio_base)
+			iounmap(ppchameleon_fio_base);
 		return -ENOMEM;
 	}
 
@@ -322,6 +325,8 @@ static int __init ppchameleonevb_init(vo
 	if (!ppchameleonevb_fio_base) {
 		printk("ioremap PPChameleonEVB NAND flash failed\n");
 		kfree(ppchameleonevb_mtd);
+		if (ppchameleon_fio_base)
+			iounmap(ppchameleon_fio_base);
 		return -EIO;
 	}
 
@@ -378,6 +383,8 @@ static int __init ppchameleonevb_init(vo
 	if (nand_scan(ppchameleonevb_mtd, 1)) {
 		iounmap((void *)ppchameleonevb_fio_base);
 		kfree(ppchameleonevb_mtd);
+		if (ppchameleon_fio_base)
+			iounmap(ppchameleon_fio_base);
 		return -ENXIO;
 	}
 #ifdef CONFIG_MTD_PARTITIONS
diff -uprN -X linux-2.6.18-orig/Documentation/dontdiff linux-2.6.18-orig/include/linux/utsrelease.h linux-2.6.18/include/linux/utsrelease.h
--- linux-2.6.18-orig/include/linux/utsrelease.h	1970-01-01 05:30:00.000000000 +0530
+++ linux-2.6.18/include/linux/utsrelease.h	2006-09-21 16:02:59.000000000 +0530
@@ -0,0 +1 @@
+#define UTS_RELEASE "2.6.18"





From buytenh at wantstofly.org  Thu Sep 21 17:16:48 2006
From: buytenh at wantstofly.org (Lennert Buytenhek)
Date: Thu, 21 Sep 2006 23:16:48 +0200
Subject: [PATCH] physmap: add power management support
Message-ID: <20060921211648.GA30338@xi.wantstofly.org>

Implement PM handling for physmap.  Idea from Steven Scholz, patch
by David Anders.

Signed-off-by: Lennert Buytenhek <buytenh at wantstofly.org>

Index: linux-2.6.18/drivers/mtd/maps/physmap.c
===================================================================
--- linux-2.6.18.orig/drivers/mtd/maps/physmap.c
+++ linux-2.6.18/drivers/mtd/maps/physmap.c
@@ -158,9 +158,44 @@ err_out:
 	return err;
 }
 
+#ifdef CONFIG_PM
+static int physmap_flash_suspend(struct platform_device *dev, pm_message_t state)
+{
+	struct physmap_flash_info *info = platform_get_drvdata(dev);
+	int ret = 0;
+
+	if (info)
+		ret = info->mtd->suspend(info->mtd);
+
+	return ret;
+}
+
+static int physmap_flash_resume(struct platform_device *dev)
+{
+	struct physmap_flash_info *info = platform_get_drvdata(dev);
+	if (info)
+		info->mtd->resume(info->mtd);
+	return 0;
+}
+
+static void physmap_flash_shutdown(struct platform_device *dev)
+{
+	struct physmap_flash_info *info = platform_get_drvdata(dev);
+	if (info && info->mtd->suspend(info->mtd) == 0)
+		info->mtd->resume(info->mtd);
+}
+#else
+#define physmap_flash_suspend NULL
+#define physmap_flash_resume  NULL
+#define physmap_flash_shutdown NULL
+#endif
+
 static struct platform_driver physmap_flash_driver = {
 	.probe		= physmap_flash_probe,
 	.remove		= physmap_flash_remove,
+	.suspend	= physmap_flash_suspend,
+	.resume		= physmap_flash_resume,
+	.shutdown	= physmap_flash_shutdown,
 	.driver		= {
 		.name	= "physmap-flash",
 	},



From chainantioch at rrherning.dk  Thu Sep 21 20:20:59 2006
From: chainantioch at rrherning.dk (Parson)
Date: Thu, 21 Sep 2006 20:20:59 -0400
Subject: Latest stuff You gape for shooting like you had seen in those films…
Message-ID: <58286519475300.07DCD1F0B3@B5QE>

Now you have chance to do it Let?s make our ejaculation like steel Come in: http://frosder.com/gal/gsm/ Have you ever dreamt to have a very hard penis during all process? It?s absolutely true ? just take one before start Enjoy multi-orgasms using this powerful thing 
 If you want a place in the sun, you must leave the shade of the family tree




From manningc2 at actrix.gen.nz  Thu Sep 21 23:18:46 2006
From: manningc2 at actrix.gen.nz (Charles Manning)
Date: Fri, 22 Sep 2006 15:18:46 +1200
Subject: Multiple writes to NAND OOB...
In-Reply-To: <Pine.GSO.4.58.0609201121180.26525@sun>
References: <Pine.GSO.4.58.0609201121180.26525@sun>
Message-ID: <200609221518.46412.manningc2@actrix.gen.nz>

On Thursday 21 September 2006 04:30, Siddharth Choudhuri wrote:
> Hi,
>
> I have the following question regarding multiple writes to OOB data:
>
> Is it possible to write to the OOB data of the same page multiple times ?
Yes it is **possible**, but be be careful. If you do too many writes without 
an erase you can cause corruptions due to "write disturb".

> If so, does it mean that the bytes being written are to different
> locations(offsets) of the OOB because a byte cannot be rewritten in NAND
> unless its block is erased ?

If you write to NAND, then what you get is the ANDing of the pattern you write 
against what was already there.

If a byte had 0011-0101 and you program 1101-0011 nto it you'll end up with 
0001-0001.

Thus, if you want to program a new pattern into some bytes, you use 0xff for 
any bytes you don't want to change.

You need to do an erase to change bits back to 1.

Note a subtle difference. Most NOR writes will fail if you write a pattern 
that tries to set a bit from 0 to a 1.  On NAND, the bit will not change, but 
it is not an error to try to do this.

-- CHarles




From dwmw2 at infradead.org  Fri Sep 22 05:36:30 2006
From: dwmw2 at infradead.org (David Woodhouse)
Date: Fri, 22 Sep 2006 10:36:30 +0100
Subject: [PATCH] cmx270-nand: Make CMDLINE_PARTS usable
In-Reply-To: <4507FE99.3030106@8d.com>
References: <4507FE99.3030106@8d.com>
Message-ID: <1158917790.24527.664.camel@pmac.infradead.org>

On Wed, 2006-09-13 at 08:50 -0400, Raphael Assenat wrote:
> This patch gives a name to the cmx270 nand mtd, making it possible to
> use command line partitioning.

Er, there _is_ no cmx270 nand board driver in my tree.

-- 
dwmw2




From miho3211 at enet.com.cn  Thu Sep 21 22:50:53 2006
From: miho3211 at enet.com.cn (miho3211 at enet.com.cn)
Date: 22 Sep 2006 11:50:53 +0900
Subject: =?ISO-2022-JP?B?g4uDcIOTjk+QooLmgug==?=
Message-ID: <20060922115053.10144@enet.com.cn>


?p?X???[?h??????????!!??http://91993.com:112/blog-ot/

???p?X???[?h???K??5115???o?^???????S?????o?^???????????x???O?C????????

?g?????????o?^?????S?????????B???d?b?????????f?[?^?[???n???????\????????

???????????????????????d?b?????????B???????C?t???????O???d?b???????R?s?[??????!!

????????????

http://91993.com:112/blog-ot/



From raph at 8d.com  Fri Sep 22 10:15:57 2006
From: raph at 8d.com (Raphael Assenat)
Date: Fri, 22 Sep 2006 10:15:57 -0400
Subject: [PATCH] cmx270-nand: Make CMDLINE_PARTS usable
In-Reply-To: <1158917790.24527.664.camel@pmac.infradead.org>
References: <4507FE99.3030106@8d.com>
	<1158917790.24527.664.camel@pmac.infradead.org>
Message-ID: <4513F01D.80608@8d.com>

David Woodhouse wrote:
> On Wed, 2006-09-13 at 08:50 -0400, Raphael Assenat wrote:
> 
>>This patch gives a name to the cmx270 nand mtd, making it possible to
>>use command line partitioning.
> 
> 
> Er, there _is_ no cmx270 nand board driver in my tree.
> 
Oh, sorry. My patch applies over the patch Mike Rapoport sent to the list on July 18
([PATCH] [MTD] CM-x270 NAND flash support), which I thought was already accepted. Was 
there anything wrong with it? Maybe you just missed it...

I also sent a patch to the list on July 21 which added NAND flash support for the cm-x255 
boards ([PATCH] Add support for NAND flash on cm-x255) but received no feedback. I can 
resend it if you wish.

(BTW, every time I send to the linux-mtd list my message is held for moderator approval 
for reason 'Message has a suspicious header'. Who should I contact for more information? 
I'd like to know exactly what header(s) is/are 'suspicious' and fix them if possible).

Best regards,

-- 
Raphael Assenat
8D Technologies Inc.



From dwmw2 at infradead.org  Fri Sep 22 10:44:00 2006
From: dwmw2 at infradead.org (David Woodhouse)
Date: Fri, 22 Sep 2006 15:44:00 +0100
Subject: [PATCH] cmx270-nand: Make CMDLINE_PARTS usable
In-Reply-To: <4513F01D.80608@8d.com>
References: <4507FE99.3030106@8d.com>
	<1158917790.24527.664.camel@pmac.infradead.org> <4513F01D.80608@8d.com>
Message-ID: <1158936240.24527.733.camel@pmac.infradead.org>

On Fri, 2006-09-22 at 10:15 -0400, Raphael Assenat wrote:
> Oh, sorry. My patch applies over the patch Mike Rapoport sent to the list on July 18
> ([PATCH] [MTD] CM-x270 NAND flash support), which I thought was already accepted. Was 
> there anything wrong with it? Maybe you just missed it...
> 
> I also sent a patch to the list on July 21 which added NAND flash support for the cm-x255 
> boards ([PATCH] Add support for NAND flash on cm-x255) but received no feedback. I can 
> resend it if you wish.

July and August weren't really a good time for sending stuff that you
expect me to pay attention to; sorry. Yes -- please retest and resend.

Can you explain how these two boards differ, and why they need two
separate drivers?

> (BTW, every time I send to the linux-mtd list my message is held for moderator approval 
> for reason 'Message has a suspicious header'. Who should I contact for more information? 
> I'd like to know exactly what header(s) is/are 'suspicious' and fix them if possible).

It just doesn't like attachments. Send patches inline and they shouldn't
get trapped.

-- 
dwmw2




From dave123_aml at yahoo.com  Fri Sep 22 11:07:44 2006
From: dave123_aml at yahoo.com (David Anders)
Date: Fri, 22 Sep 2006 08:07:44 -0700 (PDT)
Subject: patch to leave cfi in read-array on suspend
Message-ID: <20060922150744.30960.qmail@web54407.mail.yahoo.com>

greetings,

during some testing with several samsung s3c24xx based
devices it was discovered that often the
cfi_cmdset_0001.c would not leave the chip in
read-array mode on suspend. this is an issue if the
same flash chip is used for the bootloader that needs
to read on resume. attached is a patch generated
against the 2.6.18 kernel and has been tested with
several s3c24xx based devices as well as several sharp
lh79520 devices. your feedback would be appreciated.

Signed-off-by: David Anders <danders at amltd.com>

--- linux-2.6.18/drivers/mtd/chips/cfi_cmdset_0001.c    2006-09-19 23:42:06.000000000 -0400
+++ linux-2.6.18-m5900/drivers/mtd/chips/cfi_cmdset_0001.c      2006-09-22 09:16:21.000000000
-0400
@@ -2224,6 +2224,8 @@
                case FL_CFI_QUERY:
                case FL_JEDEC_QUERY:
                        if (chip->oldstate == FL_READY) {
+                               /* place the chip in a known state before suspend */
+                               map_write(map, CMD(0xFF), cfi->chips[i].start);
                                chip->oldstate = chip->state;
                                chip->state = FL_PM_SUSPENDED;
                                /* No need to wake_up() on this state change -



__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 



From ajain at neomagic.com  Fri Sep 22 11:39:20 2006
From: ajain at neomagic.com (Ajay Jain)
Date: Fri, 22 Sep 2006 21:09:20 +0530
Subject: Nand Flash write fails
Message-ID: <04c001c6de5d$46f73a10$561fa8c0@pcajain>

Hi, 

I have set up a JFFS2 partition on my NAND flash. The board driver in
question is my own. I can successfully 'mkfs' & 'mount' that partition.
However when I start copying any file to it, it gives the following
error.

nand_write_ecc: vectored attempt to write not page aligned data: to =
20b9e4, total_len =       44
Write of 68 bytes at 0x0000b9e4 failed. returned -22, retlen 0
Not marking the space at 0x0000b9e4 as dirty because the flash driver
returned retlen zero

I was looking up the code of the mtd nand layer. I see that in case the
data is not alligned on the page boundary, it returns back giving this
error. Therefore my question is that is it the responsibility of the
"jffs2 layer" or "mtd" layer to issue writes that are aligned to page
boundary. 
ANY suggestions are welcome.

Thanks.




From cheesycuff at rpp.tie.cl  Fri Sep 22 13:50:57 2006
From: cheesycuff at rpp.tie.cl (Rose)
Date: Fri, 22 Sep 2006 12:50:57 -0500
Subject: Fresh stuff More earning power
Message-ID: <96602002377294.0E0A91AC3B@8AWQWJ>

Degre e - advancement

A Genui ne Un iversity Degre e in 4-6 weeks!

Have yo u ever thought that the only thing st opping you from a great jo b and bette r p ay was a few let  ters behind you name?
W ell now you can get them!

BA BSc MA MSc M BA Ph D

Within 4-6 weeks!
No Study Required!
100% Verifiable!

These  ar e rea l, genuine deg rees that include B achelors, Masters, M BA and Doct orate D egrees. They are fully verifiable and certif ied transcripts are also available.

Just call the num ber below.
You thank me later

Please call:
 1-206-984 -2185 
Calls returned promptly



It will all come out in the wash One man's meat is another man's poison.. The Best Wine Comes Out of an Old Vessel Poor men seek meat for their stomach; rich men stomach for their meat Turn the other cheek Laughter is the best medicine. Many hands make light work





From nikbansa at cisco.com  Fri Sep 22 18:26:15 2006
From: nikbansa at cisco.com (Nikhil Bansal (nikbansa))
Date: Fri, 22 Sep 2006 15:26:15 -0700
Subject: MTD Partitions
Message-ID: <ED07EE9DB42A8945877C9794BA15040805D582@xmb-sjc-229.amer.cisco.com>

Hi,

>From what I understand you need to provide the partitioning details of
MTD devices at the compile time. I was wondering if there is any way to
partition a flash device at runtime based on the sectors. For Example:
partition 1 from sector 1 to sector 10, partition 2 from sector 11 to
sector 20. 

The thing is that we have a board with a flash chip on it and
configuration of this chip may vary based on several factors. I don't
have the luxury of compiling the kernel for each such requirement :( I
think I read somewhere that at this point, partitioning can be done at
compile time only but just wanted to confirm.

By the way, we can keep the number of partitions fixed but size needs to
be varied. Please let me know if it can be done.

Thanks in advance,
Nikhil



From jwboyer at gmail.com  Fri Sep 22 20:08:59 2006
From: jwboyer at gmail.com (Josh Boyer)
Date: Fri, 22 Sep 2006 19:08:59 -0500
Subject: MTD Partitions
In-Reply-To: <ED07EE9DB42A8945877C9794BA15040805D582@xmb-sjc-229.amer.cisco.com>
References: <ED07EE9DB42A8945877C9794BA15040805D582@xmb-sjc-229.amer.cisco.com>
Message-ID: <625fc13d0609221708g43c56ad8mfce6bd1fbae1e482@mail.gmail.com>

On 9/22/06, Nikhil Bansal (nikbansa) <nikbansa at cisco.com> wrote:
> Hi,
>
> >From what I understand you need to provide the partitioning details of
> MTD devices at the compile time. I was wondering if there is any way to
> partition a flash device at runtime based on the sectors. For Example:
> partition 1 from sector 1 to sector 10, partition 2 from sector 11 to
> sector 20.
>
> The thing is that we have a board with a flash chip on it and
> configuration of this chip may vary based on several factors. I don't
> have the luxury of compiling the kernel for each such requirement :( I
> think I read somewhere that at this point, partitioning can be done at
> compile time only but just wanted to confirm.
>
> By the way, we can keep the number of partitions fixed but size needs to
> be varied. Please let me know if it can be done.

You might want to take a look at UBI.  It can do much of what you are
looking for, depending on how complex things are.  It's still a work
in progress, but it's usable.

http://linux-mtd.infradead.org/doc/ubi.html

josh



From dwmw2 at infradead.org  Sat Sep 23 06:44:27 2006
From: dwmw2 at infradead.org (David Woodhouse)
Date: Sat, 23 Sep 2006 11:44:27 +0100
Subject: 2.6.19 -mm merge plans
In-Reply-To: <1158917046.24527.662.camel@pmac.infradead.org>
References: <20060920135438.d7dd362b.akpm@osdl.org>
	<1158917046.24527.662.camel@pmac.infradead.org>
Message-ID: <1159008267.24527.908.camel@pmac.infradead.org>

On Fri, 2006-09-22 at 10:24 +0100, David Woodhouse wrote:
> Merged, with the exception of the unlock addr one which I'm still not
> sure about -- about to investigate harder. 

Please drop it (fix-the-unlock-addr-lookup-bug-in-mtd-jedec-probe.patch).

Returning the first value in the array is intentional -- it should be
automatically shifted to make it work if it's a x16 chip, and the right
thing should happen. If _that_ isn't working, give details and we'll
work out a proper fix.

-- 
dwmw2




From dwmw2 at infradead.org  Sat Sep 23 18:44:36 2006
From: dwmw2 at infradead.org (David Woodhouse)
Date: Sat, 23 Sep 2006 23:44:36 +0100
Subject: [PATCH 1/3 -repost] pmc551 whitespace cleanup
In-Reply-To: <91anewaa2929331212a91221@wsc.cz>
References: <91anewaa2929331212a91221@wsc.cz>
Message-ID: <1159051476.24527.939.camel@pmac.infradead.org>

On Sat, 2006-09-23 at 12:54 -0400, Jiri Slaby wrote:
> pmc551 whitespace cleanup
> 
> Spaces were used for indent, there was more than 80 columns per line.
> Get
> rid of that stuff.
> 
> Signed-off-by: Jiri Slaby <jirislaby at gmail.com>

These are already applied.

-- 
dwmw2




From jirislaby at gmail.com  Sat Sep 23 18:55:58 2006
From: jirislaby at gmail.com (Jiri Slaby)
Date: Sun, 24 Sep 2006 00:54:58 +0159
Subject: [PATCH 1/3 -repost] pmc551 whitespace cleanup
In-Reply-To: <1159051476.24527.939.camel@pmac.infradead.org>
References: <91anewaa2929331212a91221@wsc.cz>
	<1159051476.24527.939.camel@pmac.infradead.org>
Message-ID: <4515BB59.6060609@gmail.com>

David Woodhouse wrote:
> On Sat, 2006-09-23 at 12:54 -0400, Jiri Slaby wrote:
>> pmc551 whitespace cleanup
>>
>> Spaces were used for indent, there was more than 80 columns per line.
>> Get
>> rid of that stuff.
>>
>> Signed-off-by: Jiri Slaby <jirislaby at gmail.com>
> 
> These are already applied.

Aah, sorry for repost.

thanks,
-- 
http://www.fi.muni.cz/~xslaby/            Jiri Slaby
faculty of informatics, masaryk university, brno, cz
e-mail: jirislaby gmail com, gpg pubkey fingerprint:
B674 9967 0407 CE62 ACC8  22A0 32CC 55C3 39D4 7A7E



From jirislaby at gmail.com  Sat Sep 23 18:59:17 2006
From: jirislaby at gmail.com (Jiri Slaby)
Date: Sat, 23 Sep 2006 22:59:17 -0000
Subject: [PATCH 1/3 -repost] pmc551 whitespace cleanup
Message-ID: <91anewaa2929331212a91221@wsc.cz>

pmc551 whitespace cleanup

Spaces were used for indent, there was more than 80 columns per line. Get
rid of that stuff.

Signed-off-by: Jiri Slaby <jirislaby at gmail.com>

---
commit 22f07f42debab2cc3b6ab895d2fa2c34d192c25c
tree 11ae1ed1123a77a12c1f7238d3cb14213dab3431
parent b1022ccd9ec9cb8d9503e649f62c0cd4784c4598
author Jiri Slaby <jirislaby at gmail.com> Tue, 19 Sep 2006 21:30:05 +0200
committer Jiri Slaby <xslaby at anemoi.localdomain> Tue, 19 Sep 2006 21:30:05 +0200

 drivers/mtd/devices/pmc551.c | 1163 ++++++++++++++++++++++--------------------
 1 files changed, 596 insertions(+), 567 deletions(-)

diff --git a/drivers/mtd/devices/pmc551.c b/drivers/mtd/devices/pmc551.c
index a03a8a7..4d40236 100644
--- a/drivers/mtd/devices/pmc551.c
+++ b/drivers/mtd/devices/pmc551.c
@@ -4,82 +4,82 @@
  * PMC551 PCI Mezzanine Ram Device
  *
  * Author:
- *       Mark Ferrell <mferrell at mvista.com>
- *       Copyright 1999,2000 Nortel Networks
+ *	Mark Ferrell <mferrell at mvista.com>
+ *	Copyright 1999,2000 Nortel Networks
  *
  * License:
- *	 As part of this driver was derived from the slram.c driver it
- *	 falls under the same license, which is GNU General Public
- *	 License v2
+ *	As part of this driver was derived from the slram.c driver it
+ *	falls under the same license, which is GNU General Public
+ *	License v2
  *
  * Description:
- *	 This driver is intended to support the PMC551 PCI Ram device
- *	 from Ramix Inc.  The PMC551 is a PMC Mezzanine module for
- *	 cPCI embedded systems.  The device contains a single SROM
- *	 that initially programs the V370PDC chipset onboard the
- *	 device, and various banks of DRAM/SDRAM onboard.  This driver
- *	 implements this PCI Ram device as an MTD (Memory Technology
- *	 Device) so that it can be used to hold a file system, or for
- *	 added swap space in embedded systems.  Since the memory on
- *	 this board isn't as fast as main memory we do not try to hook
- *	 it into main memory as that would simply reduce performance
- *	 on the system.  Using it as a block device allows us to use
- *	 it as high speed swap or for a high speed disk device of some
- *	 sort.  Which becomes very useful on diskless systems in the
- *	 embedded market I might add.
+ *	This driver is intended to support the PMC551 PCI Ram device
+ *	from Ramix Inc.  The PMC551 is a PMC Mezzanine module for
+ *	cPCI embedded systems.  The device contains a single SROM
+ *	that initially programs the V370PDC chipset onboard the
+ *	device, and various banks of DRAM/SDRAM onboard.  This driver
+ *	implements this PCI Ram device as an MTD (Memory Technology
+ *	Device) so that it can be used to hold a file system, or for
+ *	added swap space in embedded systems.  Since the memory on
+ *	this board isn't as fast as main memory we do not try to hook
+ *	it into main memory as that would simply reduce performance
+ *	on the system.  Using it as a block device allows us to use
+ *	it as high speed swap or for a high speed disk device of some
+ *	sort.  Which becomes very useful on diskless systems in the
+ *	embedded market I might add.
  *
  * Notes:
- *	 Due to what I assume is more buggy SROM, the 64M PMC551 I
- *	 have available claims that all 4 of it's DRAM banks have 64M
- *	 of ram configured (making a grand total of 256M onboard).
- *	 This is slightly annoying since the BAR0 size reflects the
- *	 aperture size, not the dram size, and the V370PDC supplies no
- *	 other method for memory size discovery.  This problem is
- *	 mostly only relevant when compiled as a module, as the
- *	 unloading of the module with an aperture size smaller then
- *	 the ram will cause the driver to detect the onboard memory
- *	 size to be equal to the aperture size when the module is
- *	 reloaded.  Soooo, to help, the module supports an msize
- *	 option to allow the specification of the onboard memory, and
- *	 an asize option, to allow the specification of the aperture
- *	 size.  The aperture must be equal to or less then the memory
- *	 size, the driver will correct this if you screw it up.  This
- *	 problem is not relevant for compiled in drivers as compiled
- *	 in drivers only init once.
+ *	Due to what I assume is more buggy SROM, the 64M PMC551 I
+ *	have available claims that all 4 of it's DRAM banks have 64M
+ *	of ram configured (making a grand total of 256M onboard).
+ *	This is slightly annoying since the BAR0 size reflects the
+ *	aperture size, not the dram size, and the V370PDC supplies no
+ *	other method for memory size discovery.  This problem is
+ *	mostly only relevant when compiled as a module, as the
+ *	unloading of the module with an aperture size smaller then
+ *	the ram will cause the driver to detect the onboard memory
+ *	size to be equal to the aperture size when the module is
+ *	reloaded.  Soooo, to help, the module supports an msize
+ *	option to allow the specification of the onboard memory, and
+ *	an asize option, to allow the specification of the aperture
+ *	size.  The aperture must be equal to or less then the memory
+ *	size, the driver will correct this if you screw it up.  This
+ *	problem is not relevant for compiled in drivers as compiled
+ *	in drivers only init once.
  *
  * Credits:
- *       Saeed Karamooz <saeed at ramix.com> of Ramix INC. for the
- *       initial example code of how to initialize this device and for
- *       help with questions I had concerning operation of the device.
+ *	Saeed Karamooz <saeed at ramix.com> of Ramix INC. for the
+ *	initial example code of how to initialize this device and for
+ *	help with questions I had concerning operation of the device.
  *
- *       Most of the MTD code for this driver was originally written
- *       for the slram.o module in the MTD drivers package which
- *       allows the mapping of system memory into an MTD device.
- *       Since the PMC551 memory module is accessed in the same
- *       fashion as system memory, the slram.c code became a very nice
- *       fit to the needs of this driver.  All we added was PCI
- *       detection/initialization to the driver and automatically figure
- *       out the size via the PCI detection.o, later changes by Corey
- *       Minyard set up the card to utilize a 1M sliding apature.
+ *	Most of the MTD code for this driver was originally written
+ *	for the slram.o module in the MTD drivers package which
+ *	allows the mapping of system memory into an MTD device.
+ *	Since the PMC551 memory module is accessed in the same
+ *	fashion as system memory, the slram.c code became a very nice
+ *	fit to the needs of this driver.  All we added was PCI
+ *	detection/initialization to the driver and automatically figure
+ *	out the size via the PCI detection.o, later changes by Corey
+ *	Minyard set up the card to utilize a 1M sliding apature.
  *
- *	 Corey Minyard <minyard at nortelnetworks.com>
- *       * Modified driver to utilize a sliding aperture instead of
- *         mapping all memory into kernel space which turned out to
- *         be very wasteful.
- *       * Located a bug in the SROM's initialization sequence that
- *         made the memory unusable, added a fix to code to touch up
- *         the DRAM some.
+ *	Corey Minyard <minyard at nortelnetworks.com>
+ *	* Modified driver to utilize a sliding aperture instead of
+ *	 mapping all memory into kernel space which turned out to
+ *	 be very wasteful.
+ *	* Located a bug in the SROM's initialization sequence that
+ *	 made the memory unusable, added a fix to code to touch up
+ *	 the DRAM some.
  *
  * Bugs/FIXME's:
- *       * MUST fix the init function to not spin on a register
- *       waiting for it to set .. this does not safely handle busted
- *       devices that never reset the register correctly which will
- *       cause the system to hang w/ a reboot being the only chance at
- *       recover. [sort of fixed, could be better]
- *       * Add I2C handling of the SROM so we can read the SROM's information
- *       about the aperture size.  This should always accurately reflect the
- *       onboard memory size.
- *       * Comb the init routine.  It's still a bit cludgy on a few things.
+ *	* MUST fix the init function to not spin on a register
+ *	waiting for it to set .. this does not safely handle busted
+ *	devices that never reset the register correctly which will
+ *	cause the system to hang w/ a reboot being the only chance at
+ *	recover. [sort of fixed, could be better]
+ *	* Add I2C handling of the SROM so we can read the SROM's information
+ *	about the aperture size.  This should always accurately reflect the
+ *	onboard memory size.
+ *	* Comb the init routine.  It's still a bit cludgy on a few things.
  */
 
 #include <linux/kernel.h>
@@ -105,74 +105,77 @@ #include <linux/mtd/compatmac.h>
 
 static struct mtd_info *pmc551list;
 
-static int pmc551_erase (struct mtd_info *mtd, struct erase_info *instr)
+static int pmc551_erase(struct mtd_info *mtd, struct erase_info *instr)
 {
-        struct mypriv *priv = mtd->priv;
-        u32 soff_hi, soff_lo; /* start address offset hi/lo */
-        u32 eoff_hi, eoff_lo; /* end address offset hi/lo */
-        unsigned long end;
+	struct mypriv *priv = mtd->priv;
+	u32 soff_hi, soff_lo;	/* start address offset hi/lo */
+	u32 eoff_hi, eoff_lo;	/* end address offset hi/lo */
+	unsigned long end;
 	u_char *ptr;
 	size_t retlen;
 
 #ifdef CONFIG_MTD_PMC551_DEBUG
-	printk(KERN_DEBUG "pmc551_erase(pos:%ld, len:%ld)\n", (long)instr->addr, (long)instr->len);
+	printk(KERN_DEBUG "pmc551_erase(pos:%ld, len:%ld)\n", (long)instr->addr,
+		(long)instr->len);
 #endif
 
-        end = instr->addr + instr->len - 1;
+	end = instr->addr + instr->len - 1;
 
-        /* Is it past the end? */
-        if ( end > mtd->size ) {
+	/* Is it past the end? */
+	if (end > mtd->size) {
 #ifdef CONFIG_MTD_PMC551_DEBUG
-	printk(KERN_DEBUG "pmc551_erase() out of bounds (%ld > %ld)\n", (long)end, (long)mtd->size);
+		printk(KERN_DEBUG "pmc551_erase() out of bounds (%ld > %ld)\n",
+			(long)end, (long)mtd->size);
 #endif
-                return -EINVAL;
-        }
-
-        eoff_hi = end & ~(priv->asize - 1);
-        soff_hi = instr->addr & ~(priv->asize - 1);
-        eoff_lo = end & (priv->asize - 1);
-        soff_lo = instr->addr & (priv->asize - 1);
-
-	pmc551_point (mtd, instr->addr, instr->len, &retlen, &ptr);
-
-        if ( soff_hi == eoff_hi || mtd->size == priv->asize) {
-                /* The whole thing fits within one access, so just one shot
-                   will do it. */
-                memset(ptr, 0xff, instr->len);
-        } else {
-                /* We have to do multiple writes to get all the data
-                   written. */
-                while (soff_hi != eoff_hi) {
+		return -EINVAL;
+	}
+
+	eoff_hi = end & ~(priv->asize - 1);
+	soff_hi = instr->addr & ~(priv->asize - 1);
+	eoff_lo = end & (priv->asize - 1);
+	soff_lo = instr->addr & (priv->asize - 1);
+
+	pmc551_point(mtd, instr->addr, instr->len, &retlen, &ptr);
+
+	if (soff_hi == eoff_hi || mtd->size == priv->asize) {
+		/* The whole thing fits within one access, so just one shot
+		   will do it. */
+		memset(ptr, 0xff, instr->len);
+	} else {
+		/* We have to do multiple writes to get all the data
+		   written. */
+		while (soff_hi != eoff_hi) {
 #ifdef CONFIG_MTD_PMC551_DEBUG
-			printk( KERN_DEBUG "pmc551_erase() soff_hi: %ld, eoff_hi: %ld\n", (long)soff_hi, (long)eoff_hi);
+			printk(KERN_DEBUG "pmc551_erase() soff_hi: %ld, "
+				"eoff_hi: %ld\n", (long)soff_hi, (long)eoff_hi);
 #endif
-                        memset(ptr, 0xff, priv->asize);
-                        if (soff_hi + priv->asize >= mtd->size) {
-                                goto out;
-                        }
-                        soff_hi += priv->asize;
-			pmc551_point (mtd,(priv->base_map0|soff_hi),
-				      priv->asize, &retlen, &ptr);
-                }
-                memset (ptr, 0xff, eoff_lo);
-        }
-
-out:
+			memset(ptr, 0xff, priv->asize);
+			if (soff_hi + priv->asize >= mtd->size) {
+				goto out;
+			}
+			soff_hi += priv->asize;
+			pmc551_point(mtd, (priv->base_map0 | soff_hi),
+				     priv->asize, &retlen, &ptr);
+		}
+		memset(ptr, 0xff, eoff_lo);
+	}
+
+      out:
 	instr->state = MTD_ERASE_DONE;
 #ifdef CONFIG_MTD_PMC551_DEBUG
 	printk(KERN_DEBUG "pmc551_erase() done\n");
 #endif
 
-        mtd_erase_callback(instr);
-        return 0;
+	mtd_erase_callback(instr);
+	return 0;
 }
 
-
-static int pmc551_point (struct mtd_info *mtd, loff_t from, size_t len, size_t *retlen, u_char **mtdbuf)
+static int pmc551_point(struct mtd_info *mtd, loff_t from, size_t len,
+			size_t * retlen, u_char ** mtdbuf)
 {
-        struct mypriv *priv = mtd->priv;
-        u32 soff_hi;
-        u32 soff_lo;
+	struct mypriv *priv = mtd->priv;
+	u32 soff_hi;
+	u32 soff_lo;
 
 #ifdef CONFIG_MTD_PMC551_DEBUG
 	printk(KERN_DEBUG "pmc551_point(%ld, %ld)\n", (long)from, (long)len);
@@ -180,18 +183,19 @@ #endif
 
 	if (from + len > mtd->size) {
 #ifdef CONFIG_MTD_PMC551_DEBUG
-		printk(KERN_DEBUG "pmc551_point() out of bounds (%ld > %ld)\n", (long)from+len, (long)mtd->size);
+		printk(KERN_DEBUG "pmc551_point() out of bounds (%ld > %ld)\n",
+			(long)from + len, (long)mtd->size);
 #endif
 		return -EINVAL;
 	}
 
-        soff_hi = from & ~(priv->asize - 1);
-        soff_lo = from & (priv->asize - 1);
+	soff_hi = from & ~(priv->asize - 1);
+	soff_lo = from & (priv->asize - 1);
 
 	/* Cheap hack optimization */
-	if( priv->curr_map0 != from ) {
-        	pci_write_config_dword ( priv->dev, PMC551_PCI_MEM_MAP0,
-                                 	(priv->base_map0 | soff_hi) );
+	if (priv->curr_map0 != from) {
+		pci_write_config_dword(priv->dev, PMC551_PCI_MEM_MAP0,
+					(priv->base_map0 | soff_hi));
 		priv->curr_map0 = soff_hi;
 	}
 
@@ -200,137 +204,144 @@ #endif
 	return 0;
 }
 
-
-static void pmc551_unpoint (struct mtd_info *mtd, u_char *addr, loff_t from, size_t len)
+static void pmc551_unpoint(struct mtd_info *mtd, u_char * addr, loff_t from,
+			   size_t len)
 {
 #ifdef CONFIG_MTD_PMC551_DEBUG
 	printk(KERN_DEBUG "pmc551_unpoint()\n");
 #endif
 }
 
-
-static int pmc551_read (struct mtd_info *mtd, loff_t from, size_t len, size_t *retlen, u_char *buf)
+static int pmc551_read(struct mtd_info *mtd, loff_t from, size_t len,
+			size_t * retlen, u_char * buf)
 {
-        struct mypriv *priv = mtd->priv;
-        u32 soff_hi, soff_lo; /* start address offset hi/lo */
-        u32 eoff_hi, eoff_lo; /* end address offset hi/lo */
-        unsigned long end;
+	struct mypriv *priv = mtd->priv;
+	u32 soff_hi, soff_lo;	/* start address offset hi/lo */
+	u32 eoff_hi, eoff_lo;	/* end address offset hi/lo */
+	unsigned long end;
 	u_char *ptr;
-        u_char *copyto = buf;
+	u_char *copyto = buf;
 
 #ifdef CONFIG_MTD_PMC551_DEBUG
-	printk(KERN_DEBUG "pmc551_read(pos:%ld, len:%ld) asize: %ld\n", (long)from, (long)len, (long)priv->asize);
+	printk(KERN_DEBUG "pmc551_read(pos:%ld, len:%ld) asize: %ld\n",
+		(long)from, (long)len, (long)priv->asize);
 #endif
 
-        end = from + len - 1;
+	end = from + len - 1;
 
-        /* Is it past the end? */
-        if (end > mtd->size) {
+	/* Is it past the end? */
+	if (end > mtd->size) {
 #ifdef CONFIG_MTD_PMC551_DEBUG
-	printk(KERN_DEBUG "pmc551_read() out of bounds (%ld > %ld)\n", (long) end, (long)mtd->size);
+		printk(KERN_DEBUG "pmc551_read() out of bounds (%ld > %ld)\n",
+			(long)end, (long)mtd->size);
 #endif
-                return -EINVAL;
-        }
-
-        soff_hi = from & ~(priv->asize - 1);
-        eoff_hi = end & ~(priv->asize - 1);
-        soff_lo = from & (priv->asize - 1);
-        eoff_lo = end & (priv->asize - 1);
-
-	pmc551_point (mtd, from, len, retlen, &ptr);
-
-        if (soff_hi == eoff_hi) {
-                /* The whole thing fits within one access, so just one shot
-                   will do it. */
-                memcpy(copyto, ptr, len);
-                copyto += len;
-        } else {
-                /* We have to do multiple writes to get all the data
-                   written. */
-                while (soff_hi != eoff_hi) {
+		return -EINVAL;
+	}
+
+	soff_hi = from & ~(priv->asize - 1);
+	eoff_hi = end & ~(priv->asize - 1);
+	soff_lo = from & (priv->asize - 1);
+	eoff_lo = end & (priv->asize - 1);
+
+	pmc551_point(mtd, from, len, retlen, &ptr);
+
+	if (soff_hi == eoff_hi) {
+		/* The whole thing fits within one access, so just one shot
+		   will do it. */
+		memcpy(copyto, ptr, len);
+		copyto += len;
+	} else {
+		/* We have to do multiple writes to get all the data
+		   written. */
+		while (soff_hi != eoff_hi) {
 #ifdef CONFIG_MTD_PMC551_DEBUG
-			printk( KERN_DEBUG "pmc551_read() soff_hi: %ld, eoff_hi: %ld\n", (long)soff_hi, (long)eoff_hi);
+			printk(KERN_DEBUG "pmc551_read() soff_hi: %ld, "
+				"eoff_hi: %ld\n", (long)soff_hi, (long)eoff_hi);
 #endif
-                        memcpy(copyto, ptr, priv->asize);
-                        copyto += priv->asize;
-                        if (soff_hi + priv->asize >= mtd->size) {
-                                goto out;
-                        }
-                        soff_hi += priv->asize;
-			pmc551_point (mtd, soff_hi, priv->asize, retlen, &ptr);
-                }
-                memcpy(copyto, ptr, eoff_lo);
-                copyto += eoff_lo;
-        }
-
-out:
+			memcpy(copyto, ptr, priv->asize);
+			copyto += priv->asize;
+			if (soff_hi + priv->asize >= mtd->size) {
+				goto out;
+			}
+			soff_hi += priv->asize;
+			pmc551_point(mtd, soff_hi, priv->asize, retlen, &ptr);
+		}
+		memcpy(copyto, ptr, eoff_lo);
+		copyto += eoff_lo;
+	}
+
+      out:
 #ifdef CONFIG_MTD_PMC551_DEBUG
 	printk(KERN_DEBUG "pmc551_read() done\n");
 #endif
-        *retlen = copyto - buf;
-        return 0;
+	*retlen = copyto - buf;
+	return 0;
 }
 
-static int pmc551_write (struct mtd_info *mtd, loff_t to, size_t len, size_t *retlen, const u_char *buf)
+static int pmc551_write(struct mtd_info *mtd, loff_t to, size_t len,
+			size_t * retlen, const u_char * buf)
 {
-        struct mypriv *priv = mtd->priv;
-        u32 soff_hi, soff_lo; /* start address offset hi/lo */
-        u32 eoff_hi, eoff_lo; /* end address offset hi/lo */
-        unsigned long end;
+	struct mypriv *priv = mtd->priv;
+	u32 soff_hi, soff_lo;	/* start address offset hi/lo */
+	u32 eoff_hi, eoff_lo;	/* end address offset hi/lo */
+	unsigned long end;
 	u_char *ptr;
-        const u_char *copyfrom = buf;
-
+	const u_char *copyfrom = buf;
 
 #ifdef CONFIG_MTD_PMC551_DEBUG
-	printk(KERN_DEBUG "pmc551_write(pos:%ld, len:%ld) asize:%ld\n", (long)to, (long)len, (long)priv->asize);
+	printk(KERN_DEBUG "pmc551_write(pos:%ld, len:%ld) asize:%ld\n",
+		(long)to, (long)len, (long)priv->asize);
 #endif
 
-        end = to + len - 1;
-        /* Is it past the end?  or did the u32 wrap? */
-        if (end > mtd->size ) {
+	end = to + len - 1;
+	/* Is it past the end?  or did the u32 wrap? */
+	if (end > mtd->size) {
 #ifdef CONFIG_MTD_PMC551_DEBUG
-	printk(KERN_DEBUG "pmc551_write() out of bounds (end: %ld, size: %ld, to: %ld)\n", (long) end, (long)mtd->size, (long)to);
+		printk(KERN_DEBUG "pmc551_write() out of bounds (end: %ld, "
+			"size: %ld, to: %ld)\n", (long)end, (long)mtd->size,
+			(long)to);
 #endif
-                return -EINVAL;
-        }
-
-        soff_hi = to & ~(priv->asize - 1);
-        eoff_hi = end & ~(priv->asize - 1);
-        soff_lo = to & (priv->asize - 1);
-        eoff_lo = end & (priv->asize - 1);
-
-	pmc551_point (mtd, to, len, retlen, &ptr);
-
-        if (soff_hi == eoff_hi) {
-                /* The whole thing fits within one access, so just one shot
-                   will do it. */
-                memcpy(ptr, copyfrom, len);
-                copyfrom += len;
-        } else {
-                /* We have to do multiple writes to get all the data
-                   written. */
-                while (soff_hi != eoff_hi) {
+		return -EINVAL;
+	}
+
+	soff_hi = to & ~(priv->asize - 1);
+	eoff_hi = end & ~(priv->asize - 1);
+	soff_lo = to & (priv->asize - 1);
+	eoff_lo = end & (priv->asize - 1);
+
+	pmc551_point(mtd, to, len, retlen, &ptr);
+
+	if (soff_hi == eoff_hi) {
+		/* The whole thing fits within one access, so just one shot
+		   will do it. */
+		memcpy(ptr, copyfrom, len);
+		copyfrom += len;
+	} else {
+		/* We have to do multiple writes to get all the data
+		   written. */
+		while (soff_hi != eoff_hi) {
 #ifdef CONFIG_MTD_PMC551_DEBUG
-			printk( KERN_DEBUG "pmc551_write() soff_hi: %ld, eoff_hi: %ld\n", (long)soff_hi, (long)eoff_hi);
+			printk(KERN_DEBUG "pmc551_write() soff_hi: %ld, "
+				"eoff_hi: %ld\n", (long)soff_hi, (long)eoff_hi);
 #endif
-                	memcpy(ptr, copyfrom, priv->asize);
-                	copyfrom += priv->asize;
-                        if (soff_hi >= mtd->size) {
-                                goto out;
-                        }
-                        soff_hi += priv->asize;
-			pmc551_point (mtd, soff_hi, priv->asize, retlen, &ptr);
-                }
-                memcpy(ptr, copyfrom, eoff_lo);
-                copyfrom += eoff_lo;
-        }
-
-out:
+			memcpy(ptr, copyfrom, priv->asize);
+			copyfrom += priv->asize;
+			if (soff_hi >= mtd->size) {
+				goto out;
+			}
+			soff_hi += priv->asize;
+			pmc551_point(mtd, soff_hi, priv->asize, retlen, &ptr);
+		}
+		memcpy(ptr, copyfrom, eoff_lo);
+		copyfrom += eoff_lo;
+	}
+
+      out:
 #ifdef CONFIG_MTD_PMC551_DEBUG
 	printk(KERN_DEBUG "pmc551_write() done\n");
 #endif
-        *retlen = copyfrom - buf;
-        return 0;
+	*retlen = copyfrom - buf;
+	return 0;
 }
 
 /*
@@ -345,58 +356,58 @@ #endif
  * mechanism
  * returns the size of the memory region found.
  */
-static u32 fixup_pmc551 (struct pci_dev *dev)
+static u32 fixup_pmc551(struct pci_dev *dev)
 {
 #ifdef CONFIG_MTD_PMC551_BUGFIX
-        u32 dram_data;
+	u32 dram_data;
 #endif
-        u32 size, dcmd, cfg, dtmp;
-        u16 cmd, tmp, i;
+	u32 size, dcmd, cfg, dtmp;
+	u16 cmd, tmp, i;
 	u8 bcmd, counter;
 
-        /* Sanity Check */
-        if(!dev) {
-                return -ENODEV;
-        }
+	/* Sanity Check */
+	if (!dev) {
+		return -ENODEV;
+	}
 
 	/*
 	 * Attempt to reset the card
 	 * FIXME: Stop Spinning registers
 	 */
-	counter=0;
+	counter = 0;
 	/* unlock registers */
-	pci_write_config_byte(dev, PMC551_SYS_CTRL_REG, 0xA5 );
+	pci_write_config_byte(dev, PMC551_SYS_CTRL_REG, 0xA5);
 	/* read in old data */
-	pci_read_config_byte(dev, PMC551_SYS_CTRL_REG, &bcmd );
+	pci_read_config_byte(dev, PMC551_SYS_CTRL_REG, &bcmd);
 	/* bang the reset line up and down for a few */
-	for(i=0;i<10;i++) {
-		counter=0;
+	for (i = 0; i < 10; i++) {
+		counter = 0;
 		bcmd &= ~0x80;
-		while(counter++ < 100) {
+		while (counter++ < 100) {
 			pci_write_config_byte(dev, PMC551_SYS_CTRL_REG, bcmd);
 		}
-		counter=0;
+		counter = 0;
 		bcmd |= 0x80;
-		while(counter++ < 100) {
+		while (counter++ < 100) {
 			pci_write_config_byte(dev, PMC551_SYS_CTRL_REG, bcmd);
 		}
 	}
-	bcmd |= (0x40|0x20);
+	bcmd |= (0x40 | 0x20);
 	pci_write_config_byte(dev, PMC551_SYS_CTRL_REG, bcmd);
 
-        /*
+	/*
 	 * Take care and turn off the memory on the device while we
 	 * tweak the configurations
 	 */
-        pci_read_config_word(dev, PCI_COMMAND, &cmd);
-        tmp = cmd & ~(PCI_COMMAND_IO|PCI_COMMAND_MEMORY);
-        pci_write_config_word(dev, PCI_COMMAND, tmp);
+	pci_read_config_word(dev, PCI_COMMAND, &cmd);
+	tmp = cmd & ~(PCI_COMMAND_IO | PCI_COMMAND_MEMORY);
+	pci_write_config_word(dev, PCI_COMMAND, tmp);
 
 	/*
 	 * Disable existing aperture before probing memory size
 	 */
 	pci_read_config_dword(dev, PMC551_PCI_MEM_MAP0, &dcmd);
-        dtmp=(dcmd|PMC551_PCI_MEM_MAP_ENABLE|PMC551_PCI_MEM_MAP_REG_EN);
+	dtmp = (dcmd | PMC551_PCI_MEM_MAP_ENABLE | PMC551_PCI_MEM_MAP_REG_EN);
 	pci_write_config_dword(dev, PMC551_PCI_MEM_MAP0, dtmp);
 	/*
 	 * Grab old BAR0 config so that we can figure out memory size
@@ -407,220 +418,231 @@ #endif
 	 * then write all 1's to the memory space, read back the result into
 	 * "size", and then write back all the old config.
 	 */
-	pci_read_config_dword( dev, PCI_BASE_ADDRESS_0, &cfg );
+	pci_read_config_dword(dev, PCI_BASE_ADDRESS_0, &cfg);
 #ifndef CONFIG_MTD_PMC551_BUGFIX
-	pci_write_config_dword( dev, PCI_BASE_ADDRESS_0, ~0 );
-	pci_read_config_dword( dev, PCI_BASE_ADDRESS_0, &size );
-	size = (size&PCI_BASE_ADDRESS_MEM_MASK);
-	size &= ~(size-1);
-	pci_write_config_dword( dev, PCI_BASE_ADDRESS_0, cfg );
+	pci_write_config_dword(dev, PCI_BASE_ADDRESS_0, ~0);
+	pci_read_config_dword(dev, PCI_BASE_ADDRESS_0, &size);
+	size = (size & PCI_BASE_ADDRESS_MEM_MASK);
+	size &= ~(size - 1);
+	pci_write_config_dword(dev, PCI_BASE_ADDRESS_0, cfg);
 #else
-        /*
-         * Get the size of the memory by reading all the DRAM size values
-         * and adding them up.
-         *
-         * KLUDGE ALERT: the boards we are using have invalid column and
-         * row mux values.  We fix them here, but this will break other
-         * memory configurations.
-         */
-        pci_read_config_dword(dev, PMC551_DRAM_BLK0, &dram_data);
-        size = PMC551_DRAM_BLK_GET_SIZE(dram_data);
-        dram_data = PMC551_DRAM_BLK_SET_COL_MUX(dram_data, 0x5);
-        dram_data = PMC551_DRAM_BLK_SET_ROW_MUX(dram_data, 0x9);
-        pci_write_config_dword(dev, PMC551_DRAM_BLK0, dram_data);
-
-        pci_read_config_dword(dev, PMC551_DRAM_BLK1, &dram_data);
-        size += PMC551_DRAM_BLK_GET_SIZE(dram_data);
-        dram_data = PMC551_DRAM_BLK_SET_COL_MUX(dram_data, 0x5);
-        dram_data = PMC551_DRAM_BLK_SET_ROW_MUX(dram_data, 0x9);
-        pci_write_config_dword(dev, PMC551_DRAM_BLK1, dram_data);
-
-        pci_read_config_dword(dev, PMC551_DRAM_BLK2, &dram_data);
-        size += PMC551_DRAM_BLK_GET_SIZE(dram_data);
-        dram_data = PMC551_DRAM_BLK_SET_COL_MUX(dram_data, 0x5);
-        dram_data = PMC551_DRAM_BLK_SET_ROW_MUX(dram_data, 0x9);
-        pci_write_config_dword(dev, PMC551_DRAM_BLK2, dram_data);
-
-        pci_read_config_dword(dev, PMC551_DRAM_BLK3, &dram_data);
-        size += PMC551_DRAM_BLK_GET_SIZE(dram_data);
-        dram_data = PMC551_DRAM_BLK_SET_COL_MUX(dram_data, 0x5);
-        dram_data = PMC551_DRAM_BLK_SET_ROW_MUX(dram_data, 0x9);
-        pci_write_config_dword(dev, PMC551_DRAM_BLK3, dram_data);
-
-        /*
-         * Oops .. something went wrong
-         */
-        if( (size &= PCI_BASE_ADDRESS_MEM_MASK) == 0) {
-                return -ENODEV;
-        }
-#endif /* CONFIG_MTD_PMC551_BUGFIX */
-
-	if ((cfg&PCI_BASE_ADDRESS_SPACE) != PCI_BASE_ADDRESS_SPACE_MEMORY) {
-                return -ENODEV;
+	/*
+	 * Get the size of the memory by reading all the DRAM size values
+	 * and adding them up.
+	 *
+	 * KLUDGE ALERT: the boards we are using have invalid column and
+	 * row mux values.  We fix them here, but this will break other
+	 * memory configurations.
+	 */
+	pci_read_config_dword(dev, PMC551_DRAM_BLK0, &dram_data);
+	size = PMC551_DRAM_BLK_GET_SIZE(dram_data);
+	dram_data = PMC551_DRAM_BLK_SET_COL_MUX(dram_data, 0x5);
+	dram_data = PMC551_DRAM_BLK_SET_ROW_MUX(dram_data, 0x9);
+	pci_write_config_dword(dev, PMC551_DRAM_BLK0, dram_data);
+
+	pci_read_config_dword(dev, PMC551_DRAM_BLK1, &dram_data);
+	size += PMC551_DRAM_BLK_GET_SIZE(dram_data);
+	dram_data = PMC551_DRAM_BLK_SET_COL_MUX(dram_data, 0x5);
+	dram_data = PMC551_DRAM_BLK_SET_ROW_MUX(dram_data, 0x9);
+	pci_write_config_dword(dev, PMC551_DRAM_BLK1, dram_data);
+
+	pci_read_config_dword(dev, PMC551_DRAM_BLK2, &dram_data);
+	size += PMC551_DRAM_BLK_GET_SIZE(dram_data);
+	dram_data = PMC551_DRAM_BLK_SET_COL_MUX(dram_data, 0x5);
+	dram_data = PMC551_DRAM_BLK_SET_ROW_MUX(dram_data, 0x9);
+	pci_write_config_dword(dev, PMC551_DRAM_BLK2, dram_data);
+
+	pci_read_config_dword(dev, PMC551_DRAM_BLK3, &dram_data);
+	size += PMC551_DRAM_BLK_GET_SIZE(dram_data);
+	dram_data = PMC551_DRAM_BLK_SET_COL_MUX(dram_data, 0x5);
+	dram_data = PMC551_DRAM_BLK_SET_ROW_MUX(dram_data, 0x9);
+	pci_write_config_dword(dev, PMC551_DRAM_BLK3, dram_data);
+
+	/*
+	 * Oops .. something went wrong
+	 */
+	if ((size &= PCI_BASE_ADDRESS_MEM_MASK) == 0) {
+		return -ENODEV;
 	}
+#endif				/* CONFIG_MTD_PMC551_BUGFIX */
 
-        /*
-         * Precharge Dram
-         */
-        pci_write_config_word( dev, PMC551_SDRAM_MA, 0x0400 );
-        pci_write_config_word( dev, PMC551_SDRAM_CMD, 0x00bf );
-
-        /*
-         * Wait until command has gone through
-         * FIXME: register spinning issue
-         */
-        do {	pci_read_config_word( dev, PMC551_SDRAM_CMD, &cmd );
-		if(counter++ > 100)break;
-        } while ( (PCI_COMMAND_IO) & cmd );
-
-        /*
+	if ((cfg & PCI_BASE_ADDRESS_SPACE) != PCI_BASE_ADDRESS_SPACE_MEMORY) {
+		return -ENODEV;
+	}
+
+	/*
+	 * Precharge Dram
+	 */
+	pci_write_config_word(dev, PMC551_SDRAM_MA, 0x0400);
+	pci_write_config_word(dev, PMC551_SDRAM_CMD, 0x00bf);
+
+	/*
+	 * Wait until command has gone through
+	 * FIXME: register spinning issue
+	 */
+	do {
+		pci_read_config_word(dev, PMC551_SDRAM_CMD, &cmd);
+		if (counter++ > 100)
+			break;
+	} while ((PCI_COMMAND_IO) & cmd);
+
+	/*
 	 * Turn on auto refresh
 	 * The loop is taken directly from Ramix's example code.  I assume that
 	 * this must be held high for some duration of time, but I can find no
 	 * documentation refrencing the reasons why.
-         */
-        for ( i = 1; i<=8 ; i++) {
-                pci_write_config_word (dev, PMC551_SDRAM_CMD, 0x0df);
-
-                /*
-                 * Make certain command has gone through
-                 * FIXME: register spinning issue
-                 */
-		counter=0;
-                do {	pci_read_config_word(dev, PMC551_SDRAM_CMD, &cmd);
-			if(counter++ > 100)break;
-                } while ( (PCI_COMMAND_IO) & cmd );
-        }
-
-        pci_write_config_word ( dev, PMC551_SDRAM_MA, 0x0020);
-        pci_write_config_word ( dev, PMC551_SDRAM_CMD, 0x0ff);
-
-        /*
-         * Wait until command completes
-         * FIXME: register spinning issue
-         */
-	counter=0;
-        do {	pci_read_config_word ( dev, PMC551_SDRAM_CMD, &cmd);
-		if(counter++ > 100)break;
-        } while ( (PCI_COMMAND_IO) & cmd );
-
-        pci_read_config_dword ( dev, PMC551_DRAM_CFG, &dcmd);
-        dcmd |= 0x02000000;
-        pci_write_config_dword ( dev, PMC551_DRAM_CFG, dcmd);
-
-        /*
-         * Check to make certain fast back-to-back, if not
-         * then set it so
-         */
-        pci_read_config_word( dev, PCI_STATUS, &cmd);
-        if((cmd&PCI_COMMAND_FAST_BACK) == 0) {
-                cmd |= PCI_COMMAND_FAST_BACK;
-                pci_write_config_word( dev, PCI_STATUS, cmd);
-        }
-
-        /*
-         * Check to make certain the DEVSEL is set correctly, this device
-         * has a tendancy to assert DEVSEL and TRDY when a write is performed
-         * to the memory when memory is read-only
-         */
-        if((cmd&PCI_STATUS_DEVSEL_MASK) != 0x0) {
-                cmd &= ~PCI_STATUS_DEVSEL_MASK;
-                pci_write_config_word( dev, PCI_STATUS, cmd );
-        }
-        /*
-         * Set to be prefetchable and put everything back based on old cfg.
+	 */
+	for (i = 1; i <= 8; i++) {
+		pci_write_config_word(dev, PMC551_SDRAM_CMD, 0x0df);
+
+		/*
+		 * Make certain command has gone through
+		 * FIXME: register spinning issue
+		 */
+		counter = 0;
+		do {
+			pci_read_config_word(dev, PMC551_SDRAM_CMD, &cmd);
+			if (counter++ > 100)
+				break;
+		} while ((PCI_COMMAND_IO) & cmd);
+	}
+
+	pci_write_config_word(dev, PMC551_SDRAM_MA, 0x0020);
+	pci_write_config_word(dev, PMC551_SDRAM_CMD, 0x0ff);
+
+	/*
+	 * Wait until command completes
+	 * FIXME: register spinning issue
+	 */
+	counter = 0;
+	do {
+		pci_read_config_word(dev, PMC551_SDRAM_CMD, &cmd);
+		if (counter++ > 100)
+			break;
+	} while ((PCI_COMMAND_IO) & cmd);
+
+	pci_read_config_dword(dev, PMC551_DRAM_CFG, &dcmd);
+	dcmd |= 0x02000000;
+	pci_write_config_dword(dev, PMC551_DRAM_CFG, dcmd);
+
+	/*
+	 * Check to make certain fast back-to-back, if not
+	 * then set it so
+	 */
+	pci_read_config_word(dev, PCI_STATUS, &cmd);
+	if ((cmd & PCI_COMMAND_FAST_BACK) == 0) {
+		cmd |= PCI_COMMAND_FAST_BACK;
+		pci_write_config_word(dev, PCI_STATUS, cmd);
+	}
+
+	/*
+	 * Check to make certain the DEVSEL is set correctly, this device
+	 * has a tendancy to assert DEVSEL and TRDY when a write is performed
+	 * to the memory when memory is read-only
+	 */
+	if ((cmd & PCI_STATUS_DEVSEL_MASK) != 0x0) {
+		cmd &= ~PCI_STATUS_DEVSEL_MASK;
+		pci_write_config_word(dev, PCI_STATUS, cmd);
+	}
+	/*
+	 * Set to be prefetchable and put everything back based on old cfg.
 	 * it's possible that the reset of the V370PDC nuked the original
 	 * setup
-         */
+	 */
 	/*
-        cfg |= PCI_BASE_ADDRESS_MEM_PREFETCH;
-	pci_write_config_dword( dev, PCI_BASE_ADDRESS_0, cfg );
-	*/
-
-        /*
-         * Turn PCI memory and I/O bus access back on
-         */
-        pci_write_config_word( dev, PCI_COMMAND,
-                               PCI_COMMAND_MEMORY | PCI_COMMAND_IO );
+	   cfg |= PCI_BASE_ADDRESS_MEM_PREFETCH;
+	   pci_write_config_dword( dev, PCI_BASE_ADDRESS_0, cfg );
+	 */
+
+	/*
+	 * Turn PCI memory and I/O bus access back on
+	 */
+	pci_write_config_word(dev, PCI_COMMAND,
+			      PCI_COMMAND_MEMORY | PCI_COMMAND_IO);
 #ifdef CONFIG_MTD_PMC551_DEBUG
-        /*
-         * Some screen fun
-         */
-        printk(KERN_DEBUG "pmc551: %d%c (0x%x) of %sprefetchable memory at 0x%llx\n",
-	       (size<1024)?size:(size<1048576)?size>>10:size>>20,
-               (size<1024)?'B':(size<1048576)?'K':'M',
-	       size, ((dcmd&(0x1<<3)) == 0)?"non-":"",
-               (unsigned long long)((dev->resource[0].start)&PCI_BASE_ADDRESS_MEM_MASK));
-
-        /*
-         * Check to see the state of the memory
-         */
-        pci_read_config_dword( dev, PMC551_DRAM_BLK0, &dcmd );
-        printk(KERN_DEBUG "pmc551: DRAM_BLK0 Flags: %s,%s\n"
-			  "pmc551: DRAM_BLK0 Size: %d at %d\n"
-			  "pmc551: DRAM_BLK0 Row MUX: %d, Col MUX: %d\n",
-               (((0x1<<1)&dcmd) == 0)?"RW":"RO",
-               (((0x1<<0)&dcmd) == 0)?"Off":"On",
-	       PMC551_DRAM_BLK_GET_SIZE(dcmd),
-	       ((dcmd>>20)&0x7FF), ((dcmd>>13)&0x7), ((dcmd>>9)&0xF) );
-
-        pci_read_config_dword( dev, PMC551_DRAM_BLK1, &dcmd );
-        printk(KERN_DEBUG "pmc551: DRAM_BLK1 Flags: %s,%s\n"
-			  "pmc551: DRAM_BLK1 Size: %d at %d\n"
-			  "pmc551: DRAM_BLK1 Row MUX: %d, Col MUX: %d\n",
-               (((0x1<<1)&dcmd) == 0)?"RW":"RO",
-               (((0x1<<0)&dcmd) == 0)?"Off":"On",
-	       PMC551_DRAM_BLK_GET_SIZE(dcmd),
-	       ((dcmd>>20)&0x7FF), ((dcmd>>13)&0x7), ((dcmd>>9)&0xF) );
-
-        pci_read_config_dword( dev, PMC551_DRAM_BLK2, &dcmd );
-        printk(KERN_DEBUG "pmc551: DRAM_BLK2 Flags: %s,%s\n"
-			  "pmc551: DRAM_BLK2 Size: %d at %d\n"
-			  "pmc551: DRAM_BLK2 Row MUX: %d, Col MUX: %d\n",
-               (((0x1<<1)&dcmd) == 0)?"RW":"RO",
-               (((0x1<<0)&dcmd) == 0)?"Off":"On",
-	       PMC551_DRAM_BLK_GET_SIZE(dcmd),
-	       ((dcmd>>20)&0x7FF), ((dcmd>>13)&0x7), ((dcmd>>9)&0xF) );
-
-        pci_read_config_dword( dev, PMC551_DRAM_BLK3, &dcmd );
-        printk(KERN_DEBUG "pmc551: DRAM_BLK3 Flags: %s,%s\n"
-			  "pmc551: DRAM_BLK3 Size: %d at %d\n"
-			  "pmc551: DRAM_BLK3 Row MUX: %d, Col MUX: %d\n",
-               (((0x1<<1)&dcmd) == 0)?"RW":"RO",
-               (((0x1<<0)&dcmd) == 0)?"Off":"On",
-	       PMC551_DRAM_BLK_GET_SIZE(dcmd),
-	       ((dcmd>>20)&0x7FF), ((dcmd>>13)&0x7), ((dcmd>>9)&0xF) );
-
-        pci_read_config_word( dev, PCI_COMMAND, &cmd );
-        printk( KERN_DEBUG "pmc551: Memory Access %s\n",
-                (((0x1<<1)&cmd) == 0)?"off":"on" );
-        printk( KERN_DEBUG "pmc551: I/O Access %s\n",
-                (((0x1<<0)&cmd) == 0)?"off":"on" );
-
-        pci_read_config_word( dev, PCI_STATUS, &cmd );
-        printk( KERN_DEBUG "pmc551: Devsel %s\n",
-                ((PCI_STATUS_DEVSEL_MASK&cmd)==0x000)?"Fast":
-                ((PCI_STATUS_DEVSEL_MASK&cmd)==0x200)?"Medium":
-                ((PCI_STATUS_DEVSEL_MASK&cmd)==0x400)?"Slow":"Invalid" );
-
-        printk( KERN_DEBUG "pmc551: %sFast Back-to-Back\n",
-                ((PCI_COMMAND_FAST_BACK&cmd) == 0)?"Not ":"" );
-
-	pci_read_config_byte(dev, PMC551_SYS_CTRL_REG, &bcmd );
-	printk( KERN_DEBUG "pmc551: EEPROM is under %s control\n"
-			   "pmc551: System Control Register is %slocked to PCI access\n"
-			   "pmc551: System Control Register is %slocked to EEPROM access\n",
-		(bcmd&0x1)?"software":"hardware",
-		(bcmd&0x20)?"":"un", (bcmd&0x40)?"":"un");
+	/*
+	 * Some screen fun
+	 */
+	printk(KERN_DEBUG "pmc551: %d%c (0x%x) of %sprefetchable memory at "
+		"0x%llx\n", (size < 1024) ? size : (size < 1048576) ?
+		size >> 10 : size >> 20,
+		(size < 1024) ? 'B' : (size < 1048576) ? 'K' : 'M', size,
+		((dcmd & (0x1 << 3)) == 0) ? "non-" : "",
+		(unsigned long long)((dev->resource[0].start) &
+				    PCI_BASE_ADDRESS_MEM_MASK));
+
+	/*
+	 * Check to see the state of the memory
+	 */
+	pci_read_config_dword(dev, PMC551_DRAM_BLK0, &dcmd);
+	printk(KERN_DEBUG "pmc551: DRAM_BLK0 Flags: %s,%s\n"
+		"pmc551: DRAM_BLK0 Size: %d at %d\n"
+		"pmc551: DRAM_BLK0 Row MUX: %d, Col MUX: %d\n",
+		(((0x1 << 1) & dcmd) == 0) ? "RW" : "RO",
+		(((0x1 << 0) & dcmd) == 0) ? "Off" : "On",
+		PMC551_DRAM_BLK_GET_SIZE(dcmd),
+		((dcmd >> 20) & 0x7FF), ((dcmd >> 13) & 0x7),
+		((dcmd >> 9) & 0xF));
+
+	pci_read_config_dword(dev, PMC551_DRAM_BLK1, &dcmd);
+	printk(KERN_DEBUG "pmc551: DRAM_BLK1 Flags: %s,%s\n"
+		"pmc551: DRAM_BLK1 Size: %d at %d\n"
+		"pmc551: DRAM_BLK1 Row MUX: %d, Col MUX: %d\n",
+		(((0x1 << 1) & dcmd) == 0) ? "RW" : "RO",
+		(((0x1 << 0) & dcmd) == 0) ? "Off" : "On",
+		PMC551_DRAM_BLK_GET_SIZE(dcmd),
+		((dcmd >> 20) & 0x7FF), ((dcmd >> 13) & 0x7),
+		((dcmd >> 9) & 0xF));
+
+	pci_read_config_dword(dev, PMC551_DRAM_BLK2, &dcmd);
+	printk(KERN_DEBUG "pmc551: DRAM_BLK2 Flags: %s,%s\n"
+		"pmc551: DRAM_BLK2 Size: %d at %d\n"
+		"pmc551: DRAM_BLK2 Row MUX: %d, Col MUX: %d\n",
+		(((0x1 << 1) & dcmd) == 0) ? "RW" : "RO",
+		(((0x1 << 0) & dcmd) == 0) ? "Off" : "On",
+		PMC551_DRAM_BLK_GET_SIZE(dcmd),
+		((dcmd >> 20) & 0x7FF), ((dcmd >> 13) & 0x7),
+		((dcmd >> 9) & 0xF));
+
+	pci_read_config_dword(dev, PMC551_DRAM_BLK3, &dcmd);
+	printk(KERN_DEBUG "pmc551: DRAM_BLK3 Flags: %s,%s\n"
+		"pmc551: DRAM_BLK3 Size: %d at %d\n"
+		"pmc551: DRAM_BLK3 Row MUX: %d, Col MUX: %d\n",
+		(((0x1 << 1) & dcmd) == 0) ? "RW" : "RO",
+		(((0x1 << 0) & dcmd) == 0) ? "Off" : "On",
+		PMC551_DRAM_BLK_GET_SIZE(dcmd),
+		((dcmd >> 20) & 0x7FF), ((dcmd >> 13) & 0x7),
+		((dcmd >> 9) & 0xF));
+
+	pci_read_config_word(dev, PCI_COMMAND, &cmd);
+	printk(KERN_DEBUG "pmc551: Memory Access %s\n",
+		(((0x1 << 1) & cmd) == 0) ? "off" : "on");
+	printk(KERN_DEBUG "pmc551: I/O Access %s\n",
+		(((0x1 << 0) & cmd) == 0) ? "off" : "on");
+
+	pci_read_config_word(dev, PCI_STATUS, &cmd);
+	printk(KERN_DEBUG "pmc551: Devsel %s\n",
+		((PCI_STATUS_DEVSEL_MASK & cmd) == 0x000) ? "Fast" :
+		((PCI_STATUS_DEVSEL_MASK & cmd) == 0x200) ? "Medium" :
+		((PCI_STATUS_DEVSEL_MASK & cmd) == 0x400) ? "Slow" : "Invalid");
+
+	printk(KERN_DEBUG "pmc551: %sFast Back-to-Back\n",
+		((PCI_COMMAND_FAST_BACK & cmd) == 0) ? "Not " : "");
+
+	pci_read_config_byte(dev, PMC551_SYS_CTRL_REG, &bcmd);
+	printk(KERN_DEBUG "pmc551: EEPROM is under %s control\n"
+		"pmc551: System Control Register is %slocked to PCI access\n"
+		"pmc551: System Control Register is %slocked to EEPROM access\n",
+		(bcmd & 0x1) ? "software" : "hardware",
+		(bcmd & 0x20) ? "" : "un", (bcmd & 0x40) ? "" : "un");
 #endif
-        return size;
+	return size;
 }
 
 /*
  * Kernel version specific module stuffages
  */
 
-
 MODULE_LICENSE("GPL");
 MODULE_AUTHOR("Mark Ferrell <mferrell at mvista.com>");
 MODULE_DESCRIPTION(PMC551_VERSION);
@@ -628,11 +650,11 @@ MODULE_DESCRIPTION(PMC551_VERSION);
 /*
  * Stuff these outside the ifdef so as to not bust compiled in driver support
  */
-static int msize=0;
+static int msize = 0;
 #if defined(CONFIG_MTD_PMC551_APERTURE_SIZE)
-static int asize=CONFIG_MTD_PMC551_APERTURE_SIZE
+static int asize = CONFIG_MTD_PMC551_APERTURE_SIZE
 #else
-static int asize=0;
+static int asize = 0;
 #endif
 
 module_param(msize, int, 0);
@@ -645,172 +667,179 @@ MODULE_PARM_DESC(asize, "aperture size, 
  */
 static int __init init_pmc551(void)
 {
-        struct pci_dev *PCI_Device = NULL;
-        struct mypriv *priv;
-        int count, found=0;
-        struct mtd_info *mtd;
-        u32 length = 0;
-
-	if(msize) {
-		msize = (1 << (ffs(msize) - 1))<<20;
-		if (msize > (1<<30)) {
-			printk(KERN_NOTICE "pmc551: Invalid memory size [%d]\n", msize);
+	struct pci_dev *PCI_Device = NULL;
+	struct mypriv *priv;
+	int count, found = 0;
+	struct mtd_info *mtd;
+	u32 length = 0;
+
+	if (msize) {
+		msize = (1 << (ffs(msize) - 1)) << 20;
+		if (msize > (1 << 30)) {
+			printk(KERN_NOTICE "pmc551: Invalid memory size [%d]\n",
+				msize);
 			return -EINVAL;
 		}
 	}
 
-	if(asize) {
-		asize = (1 << (ffs(asize) - 1))<<20;
-		if (asize > (1<<30) ) {
-			printk(KERN_NOTICE "pmc551: Invalid aperture size [%d]\n", asize);
+	if (asize) {
+		asize = (1 << (ffs(asize) - 1)) << 20;
+		if (asize > (1 << 30)) {
+			printk(KERN_NOTICE "pmc551: Invalid aperture size "
+				"[%d]\n", asize);
 			return -EINVAL;
 		}
 	}
 
-        printk(KERN_INFO PMC551_VERSION);
-
-        /*
-         * PCU-bus chipset probe.
-         */
-        for( count = 0; count < MAX_MTD_DEVICES; count++ ) {
-
-                if ((PCI_Device = pci_get_device(PCI_VENDOR_ID_V3_SEMI,
-                                                  PCI_DEVICE_ID_V3_SEMI_V370PDC,
-						  PCI_Device ) ) == NULL) {
-                        break;
-                }
-
-                printk(KERN_NOTICE "pmc551: Found PCI V370PDC at 0x%llx\n",
-				    (unsigned long long)PCI_Device->resource[0].start);
-
-                /*
-                 * The PMC551 device acts VERY weird if you don't init it
-                 * first.  i.e. it will not correctly report devsel.  If for
-                 * some reason the sdram is in a wrote-protected state the
-                 * device will DEVSEL when it is written to causing problems
-                 * with the oldproc.c driver in
-                 * some kernels (2.2.*)
-                 */
-                if((length = fixup_pmc551(PCI_Device)) <= 0) {
-                        printk(KERN_NOTICE "pmc551: Cannot init SDRAM\n");
-                        break;
-                }
+	printk(KERN_INFO PMC551_VERSION);
+
+	/*
+	 * PCU-bus chipset probe.
+	 */
+	for (count = 0; count < MAX_MTD_DEVICES; count++) {
+
+		if ((PCI_Device = pci_get_device(PCI_VENDOR_ID_V3_SEMI,
+						  PCI_DEVICE_ID_V3_SEMI_V370PDC,
+						  PCI_Device)) == NULL) {
+			break;
+		}
+
+		printk(KERN_NOTICE "pmc551: Found PCI V370PDC at 0x%llx\n",
+			(unsigned long long)PCI_Device->resource[0].start);
+
+		/*
+		 * The PMC551 device acts VERY weird if you don't init it
+		 * first.  i.e. it will not correctly report devsel.  If for
+		 * some reason the sdram is in a wrote-protected state the
+		 * device will DEVSEL when it is written to causing problems
+		 * with the oldproc.c driver in
+		 * some kernels (2.2.*)
+		 */
+		if ((length = fixup_pmc551(PCI_Device)) <= 0) {
+			printk(KERN_NOTICE "pmc551: Cannot init SDRAM\n");
+			break;
+		}
 
 		/*
 		 * This is needed until the driver is capable of reading the
 		 * onboard I2C SROM to discover the "real" memory size.
 		 */
-		if(msize) {
+		if (msize) {
 			length = msize;
-			printk(KERN_NOTICE "pmc551: Using specified memory size 0x%x\n", length);
+			printk(KERN_NOTICE "pmc551: Using specified memory "
+				"size 0x%x\n", length);
 		} else {
 			msize = length;
 		}
 
-                mtd = kmalloc(sizeof(struct mtd_info), GFP_KERNEL);
-                if (!mtd) {
-                        printk(KERN_NOTICE "pmc551: Cannot allocate new MTD device.\n");
-                        break;
-                }
-
-                memset(mtd, 0, sizeof(struct mtd_info));
-
-                priv = kmalloc (sizeof(struct mypriv), GFP_KERNEL);
-                if (!priv) {
-                        printk(KERN_NOTICE "pmc551: Cannot allocate new MTD device.\n");
-                        kfree(mtd);
-                        break;
-                }
-                memset(priv, 0, sizeof(*priv));
-                mtd->priv = priv;
-                priv->dev = PCI_Device;
-
-		if(asize > length) {
-			printk(KERN_NOTICE "pmc551: reducing aperture size to fit %dM\n",length>>20);
+		mtd = kmalloc(sizeof(struct mtd_info), GFP_KERNEL);
+		if (!mtd) {
+			printk(KERN_NOTICE "pmc551: Cannot allocate new MTD "
+				"device.\n");
+			break;
+		}
+
+		memset(mtd, 0, sizeof(struct mtd_info));
+
+		priv = kmalloc(sizeof(struct mypriv), GFP_KERNEL);
+		if (!priv) {
+			printk(KERN_NOTICE "pmc551: Cannot allocate new MTD "
+				"device.\n");
+			kfree(mtd);
+			break;
+		}
+		memset(priv, 0, sizeof(*priv));
+		mtd->priv = priv;
+		priv->dev = PCI_Device;
+
+		if (asize > length) {
+			printk(KERN_NOTICE "pmc551: reducing aperture size to "
+				"fit %dM\n", length >> 20);
 			priv->asize = asize = length;
 		} else if (asize == 0 || asize == length) {
-			printk(KERN_NOTICE "pmc551: Using existing aperture size %dM\n", length>>20);
+			printk(KERN_NOTICE "pmc551: Using existing aperture "
+				"size %dM\n", length >> 20);
 			priv->asize = asize = length;
 		} else {
-			printk(KERN_NOTICE "pmc551: Using specified aperture size %dM\n", asize>>20);
+			printk(KERN_NOTICE "pmc551: Using specified aperture "
+				"size %dM\n", asize >> 20);
 			priv->asize = asize;
 		}
-                priv->start = ioremap(((PCI_Device->resource[0].start)
-                                       & PCI_BASE_ADDRESS_MEM_MASK),
-                                      priv->asize);
+		priv->start = ioremap(((PCI_Device->resource[0].start)
+					& PCI_BASE_ADDRESS_MEM_MASK),
+				      priv->asize);
 
 		if (!priv->start) {
 			printk(KERN_NOTICE "pmc551: Unable to map IO space\n");
-                        kfree(mtd->priv);
-                        kfree(mtd);
+			kfree(mtd->priv);
+			kfree(mtd);
 			break;
 		}
-
 #ifdef CONFIG_MTD_PMC551_DEBUG
-		printk( KERN_DEBUG "pmc551: setting aperture to %d\n",
-			ffs(priv->asize>>20)-1);
+		printk(KERN_DEBUG "pmc551: setting aperture to %d\n",
+			ffs(priv->asize >> 20) - 1);
 #endif
 
-                priv->base_map0 = ( PMC551_PCI_MEM_MAP_REG_EN
-				  | PMC551_PCI_MEM_MAP_ENABLE
-				  | (ffs(priv->asize>>20)-1)<<4 );
-                priv->curr_map0 = priv->base_map0;
-                pci_write_config_dword ( priv->dev, PMC551_PCI_MEM_MAP0,
-                                         priv->curr_map0 );
+		priv->base_map0 = (PMC551_PCI_MEM_MAP_REG_EN
+				   | PMC551_PCI_MEM_MAP_ENABLE
+				   | (ffs(priv->asize >> 20) - 1) << 4);
+		priv->curr_map0 = priv->base_map0;
+		pci_write_config_dword(priv->dev, PMC551_PCI_MEM_MAP0,
+					priv->curr_map0);
 
 #ifdef CONFIG_MTD_PMC551_DEBUG
-		printk( KERN_DEBUG "pmc551: aperture set to %d\n",
-			(priv->base_map0 & 0xF0)>>4 );
+		printk(KERN_DEBUG "pmc551: aperture set to %d\n",
+			(priv->base_map0 & 0xF0) >> 4);
 #endif
 
-                mtd->size 	= msize;
-                mtd->flags 	= MTD_CAP_RAM;
-                mtd->erase 	= pmc551_erase;
-                mtd->read 	= pmc551_read;
-                mtd->write 	= pmc551_write;
-                mtd->point 	= pmc551_point;
-                mtd->unpoint 	= pmc551_unpoint;
-                mtd->type 	= MTD_RAM;
-                mtd->name 	= "PMC551 RAM board";
-                mtd->erasesize 	= 0x10000;
-                mtd->writesize  = 1;
-                mtd->owner = THIS_MODULE;
-
-                if (add_mtd_device(mtd)) {
-                        printk(KERN_NOTICE "pmc551: Failed to register new device\n");
+		mtd->size = msize;
+		mtd->flags = MTD_CAP_RAM;
+		mtd->erase = pmc551_erase;
+		mtd->read = pmc551_read;
+		mtd->write = pmc551_write;
+		mtd->point = pmc551_point;
+		mtd->unpoint = pmc551_unpoint;
+		mtd->type = MTD_RAM;
+		mtd->name = "PMC551 RAM board";
+		mtd->erasesize = 0x10000;
+		mtd->writesize = 1;
+		mtd->owner = THIS_MODULE;
+
+		if (add_mtd_device(mtd)) {
+			printk(KERN_NOTICE "pmc551: Failed to register new "
+				"device\n");
 			iounmap(priv->start);
-                        kfree(mtd->priv);
-                        kfree(mtd);
-                        break;
-                }
-
-                /* Keep a reference as the add_mtd_device worked */
-                pci_dev_get(PCI_Device);
-
-                printk(KERN_NOTICE "Registered pmc551 memory device.\n");
-                printk(KERN_NOTICE "Mapped %dM of memory from 0x%p to 0x%p\n",
-                       priv->asize>>20,
-                       priv->start,
-                       priv->start + priv->asize);
-                printk(KERN_NOTICE "Total memory is %d%c\n",
-	       		(length<1024)?length:
-				(length<1048576)?length>>10:length>>20,
-               		(length<1024)?'B':(length<1048576)?'K':'M');
+			kfree(mtd->priv);
+			kfree(mtd);
+			break;
+		}
+
+		/* Keep a reference as the add_mtd_device worked */
+		pci_dev_get(PCI_Device);
+
+		printk(KERN_NOTICE "Registered pmc551 memory device.\n");
+		printk(KERN_NOTICE "Mapped %dM of memory from 0x%p to 0x%p\n",
+			priv->asize >> 20,
+			priv->start, priv->start + priv->asize);
+		printk(KERN_NOTICE "Total memory is %d%c\n",
+			(length < 1024) ? length :
+			(length < 1048576) ? length >> 10 : length >> 20,
+			(length < 1024) ? 'B' : (length < 1048576) ? 'K' : 'M');
 		priv->nextpmc551 = pmc551list;
 		pmc551list = mtd;
 		found++;
-        }
+	}
 
-        /* Exited early, reference left over */
-        if (PCI_Device)
-        	pci_dev_put(PCI_Device);
+	/* Exited early, reference left over */
+	if (PCI_Device)
+		pci_dev_put(PCI_Device);
 
-        if( !pmc551list ) {
-                printk(KERN_NOTICE "pmc551: not detected\n");
-                return -ENODEV;
-        } else {
+	if (!pmc551list) {
+		printk(KERN_NOTICE "pmc551: not detected\n");
+		return -ENODEV;
+	} else {
 		printk(KERN_NOTICE "pmc551: %d pmc551 devices loaded\n", found);
-                return 0;
+		return 0;
 	}
 }
 
@@ -819,24 +848,24 @@ #endif
  */
 static void __exit cleanup_pmc551(void)
 {
-        int found=0;
-        struct mtd_info *mtd;
+	int found = 0;
+	struct mtd_info *mtd;
 	struct mypriv *priv;
 
-	while((mtd=pmc551list)) {
+	while ((mtd = pmc551list)) {
 		priv = mtd->priv;
 		pmc551list = priv->nextpmc551;
 
-		if(priv->start) {
-			printk (KERN_DEBUG "pmc551: unmapping %dM starting at 0x%p\n",
-				priv->asize>>20, priv->start);
-			iounmap (priv->start);
+		if (priv->start) {
+			printk(KERN_DEBUG "pmc551: unmapping %dM starting at "
+				"0x%p\n", priv->asize >> 20, priv->start);
+			iounmap(priv->start);
 		}
 		pci_dev_put(priv->dev);
 
-		kfree (mtd->priv);
-		del_mtd_device (mtd);
-		kfree (mtd);
+		kfree(mtd->priv);
+		del_mtd_device(mtd);
+		kfree(mtd);
 		found++;
 	}
 



From jirislaby at gmail.com  Sat Sep 23 19:00:18 2006
From: jirislaby at gmail.com (Jiri Slaby)
Date: Sat, 23 Sep 2006 23:00:18 -0000
Subject: [PATCH 3/3 -repost] pmc551 pci cleanup
Message-ID: <91292new4a49121291221@wsc.cz>

pmc551 pci cleanup

Use pci_resource_start for getting start of regions and pci_iomap to not
doing this directly by using dev->resource... (Thanks to Rolf Eike Beer)

Signed-off-by: Jiri Slaby <jirislaby at gmail.com>

---
commit f168fc8e075580212def9c838b21824faf516cf4
tree 41bdcab4eb268c8022d6eb370aed06688a599d5e
parent eb0edd8068cde9b5e6afaf09065a94cb83c10efd
author Jiri Slaby <jirislaby at gmail.com> Tue, 19 Sep 2006 21:48:40 +0200
committer Jiri Slaby <xslaby at anemoi.localdomain> Tue, 19 Sep 2006 21:48:40 +0200

 drivers/mtd/devices/pmc551.c |   13 +++++--------
 1 files changed, 5 insertions(+), 8 deletions(-)

diff --git a/drivers/mtd/devices/pmc551.c b/drivers/mtd/devices/pmc551.c
index 62a9188..354e165 100644
--- a/drivers/mtd/devices/pmc551.c
+++ b/drivers/mtd/devices/pmc551.c
@@ -568,8 +568,7 @@ #ifdef CONFIG_MTD_PMC551_DEBUG
 		size >> 10 : size >> 20,
 		(size < 1024) ? 'B' : (size < 1048576) ? 'K' : 'M', size,
 		((dcmd & (0x1 << 3)) == 0) ? "non-" : "",
-		(unsigned long long)((dev->resource[0].start) &
-				    PCI_BASE_ADDRESS_MEM_MASK));
+		(unsigned long long)pci_resource_start(dev, 0));
 
 	/*
 	 * Check to see the state of the memory
@@ -705,7 +704,7 @@ static int __init init_pmc551(void)
 		}
 
 		printk(KERN_NOTICE "pmc551: Found PCI V370PDC at 0x%llx\n",
-			(unsigned long long)PCI_Device->resource[0].start);
+			(unsigned long long)pci_resource_start(PCI_Device, 0));
 
 		/*
 		 * The PMC551 device acts VERY weird if you don't init it
@@ -762,9 +761,7 @@ static int __init init_pmc551(void)
 				"size %dM\n", asize >> 20);
 			priv->asize = asize;
 		}
-		priv->start = ioremap(((PCI_Device->resource[0].start)
-					& PCI_BASE_ADDRESS_MEM_MASK),
-				      priv->asize);
+		priv->start = pci_iomap(PCI_Device, 0, priv->asize);
 
 		if (!priv->start) {
 			printk(KERN_NOTICE "pmc551: Unable to map IO space\n");
@@ -805,7 +802,7 @@ #endif
 		if (add_mtd_device(mtd)) {
 			printk(KERN_NOTICE "pmc551: Failed to register new "
 				"device\n");
-			iounmap(priv->start);
+			pci_iounmap(PCI_Device, priv->start);
 			kfree(mtd->priv);
 			kfree(mtd);
 			break;
@@ -856,7 +853,7 @@ static void __exit cleanup_pmc551(void)
 		if (priv->start) {
 			printk(KERN_DEBUG "pmc551: unmapping %dM starting at "
 				"0x%p\n", priv->asize >> 20, priv->start);
-			iounmap(priv->start);
+			pci_iounmap(priv->dev, priv->start);
 		}
 		pci_dev_put(priv->dev);
 



From jirislaby at gmail.com  Sat Sep 23 19:00:20 2006
From: jirislaby at gmail.com (Jiri Slaby)
Date: Sat, 23 Sep 2006 23:00:20 -0000
Subject: [PATCH 2/3 -repost] pmc551 use kzalloc
Message-ID: <91newa49121291221@wsc.cz>

pmc551 use kzalloc

Use kzalloc instad of kmalloc+memset(0).

Signed-off-by: Jiri Slaby <jirislaby at gmail.com>

---
commit eb0edd8068cde9b5e6afaf09065a94cb83c10efd
tree a2f56ac7c0f5cb8e0e3dba707faa68cc8d5c9952
parent 22f07f42debab2cc3b6ab895d2fa2c34d192c25c
author Jiri Slaby <jirislaby at gmail.com> Tue, 19 Sep 2006 21:33:07 +0200
committer Jiri Slaby <xslaby at anemoi.localdomain> Tue, 19 Sep 2006 21:33:07 +0200

 drivers/mtd/devices/pmc551.c |    7 ++-----
 1 files changed, 2 insertions(+), 5 deletions(-)

diff --git a/drivers/mtd/devices/pmc551.c b/drivers/mtd/devices/pmc551.c
index 4d40236..62a9188 100644
--- a/drivers/mtd/devices/pmc551.c
+++ b/drivers/mtd/devices/pmc551.c
@@ -732,23 +732,20 @@ static int __init init_pmc551(void)
 			msize = length;
 		}
 
-		mtd = kmalloc(sizeof(struct mtd_info), GFP_KERNEL);
+		mtd = kzalloc(sizeof(struct mtd_info), GFP_KERNEL);
 		if (!mtd) {
 			printk(KERN_NOTICE "pmc551: Cannot allocate new MTD "
 				"device.\n");
 			break;
 		}
 
-		memset(mtd, 0, sizeof(struct mtd_info));
-
-		priv = kmalloc(sizeof(struct mypriv), GFP_KERNEL);
+		priv = kzalloc(sizeof(struct mypriv), GFP_KERNEL);
 		if (!priv) {
 			printk(KERN_NOTICE "pmc551: Cannot allocate new MTD "
 				"device.\n");
 			kfree(mtd);
 			break;
 		}
-		memset(priv, 0, sizeof(*priv));
 		mtd->priv = priv;
 		priv->dev = PCI_Device;
 



From deependialysis at route66guitars.com  Sun Sep 24 09:12:45 2006
From: deependialysis at route66guitars.com (Grubbs)
Date: Sun, 24 Sep 2006 15:12:45 +0200
Subject: {PRE_SUBJ} New and hot Would you like to have stronger ejaculation? 
Message-ID: <47291887922797.7E08AA74C8@E0NM7E>

Hello It is possible today with excellent formula Have you some doubt? But without any results? Now it?s possible to do with magic tab Do you wish to increase your volume by up to 500%? Just take a look: http://galicoor.com/gal/gsm/




From decibelasparagus at rrmodelcraftsman.com  Sun Sep 24 09:23:50 2006
From: decibelasparagus at rrmodelcraftsman.com (Gamble)
Date: Sun, 24 Sep 2006 06:23:50 -0700
Subject: {PRE_SUBJ} Recently added  Do you wish to become multi-orgasmic?
Message-ID: <38307782159675.DF8477E872@PXWCA>

Greetings Show your girl a huge explosion as I used to do Increase your volume in just days I am sure it was Just take a look: http://frosder.com/gal/gsm/ Don?t trust me? Would you like to have stronger ejaculation? 




From approbationanomaly at roxannes-restaurant.com  Sun Sep 24 09:24:17 2006
From: approbationanomaly at roxannes-restaurant.com (Oliver)
Date: Sun, 24 Sep 2006 21:24:17 +0800
Subject: {PRE_SUBJ} Hot'n'new Would you like to please your lovely partner
	completely?
Message-ID: <04955978378726.319C09CB7B@P15I>

Greetings This successful product is created especially for you, guys Lots of pleasure waits for you right after you take this medicine I am sure it was Come in here: http://frosder.com/gal/gsm/ Use this tab regularly and you?ll have the best Would you like to have stronger ejaculation? 




From trimarchi at gandalf.sssup.it  Sun Sep 24 14:19:33 2006
From: trimarchi at gandalf.sssup.it (Michael Trimarchi)
Date: Sun, 24 Sep 2006 20:19:33 +0200
Subject: MTD Partitions
In-Reply-To: <ED07EE9DB42A8945877C9794BA15040805D582@xmb-sjc-229.amer.cisco.com>
References: <ED07EE9DB42A8945877C9794BA15040805D582@xmb-sjc-229.amer.cisco.com>
Message-ID: <4516CC35.5010507@gandalf.sssup.it>

Nikhil Bansal (nikbansa) wrote:

>Hi,
>
>>From what I understand you need to provide the partitioning details of
>MTD devices at the compile time. I was wondering if there is any way to
>partition a flash device at runtime based on the sectors. For Example:
>partition 1 from sector 1 to sector 10, partition 2 from sector 11 to
>sector 20. 
>
>The thing is that we have a board with a flash chip on it and
>configuration of this chip may vary based on several factors. I don't
>have the luxury of compiling the kernel for each such requirement :( I
>think I read somewhere that at this point, partitioning can be done at
>compile time only but just wanted to confirm.
>
>By the way, we can keep the number of partitions fixed but size needs to
>be varied. Please let me know if it can be done.
>
>Thanks in advance,
>Nikhil
>
>______________________________________________________
>Linux MTD discussion mailing list
>http://lists.infradead.org/mailman/listinfo/linux-mtd/
>
>  
>
Hi,
I think that you can use cmdline partition option in the kernel. I use 
it in the IXDP465
Regards Michael




From ajain at neomagic.com  Mon Sep 25 05:11:30 2006
From: ajain at neomagic.com (Ajay Jain)
Date: Mon, 25 Sep 2006 14:41:30 +0530
Subject: Questions regarding JFFS2/NAND
Message-ID: <071301c6e082$985f23a0$561fa8c0@pcajain>

Hi All, 

I have a few questions. Please help me to answer them, if you find
suitable.

1. Is it possible to run JFFS2 on NAND Flash on 2.4. I am seeing that
the mtd website mentions that it is not supported. I do not clearly
understand what it means. Does it mean that mtd guys do not support it,
or does it mean that you can't run JFFS2 on nand in 2.4 at all.

2. On version 2.4.21, we see that 'ecc' is always disabled. It does not
really matter, as what value we set. Is anybody you aware of this issue.


3. Because of this, we backported 'mtd' from 2.6 version. Now the mtd
appears to be reasonably stable. But we still have the old jffs2 in
place. The new mtd does not allow unaligned writes, but jffs2 (the old
one) keeps sending unaligned requests. We modified the mtd layer to
handle this, but then the issue is that we are writing to the same page
again and again, as the writes are unaligned. But the ecc value can only
be written once. So this solution will not work either. It does work if
we switch off the ecc. Are you aware of any of these issues, is my
observation correct.

4. Is it realistically possible to backport 2.6 JFFS2 to 2.4.

Please help me to solve these issues. We want to run JFFS2 on 2.4/NAND.

Thanks.





From jwboyer at gmail.com  Mon Sep 25 06:50:25 2006
From: jwboyer at gmail.com (Josh Boyer)
Date: Mon, 25 Sep 2006 05:50:25 -0500
Subject: Questions regarding JFFS2/NAND
In-Reply-To: <071301c6e082$985f23a0$561fa8c0@pcajain>
References: <071301c6e082$985f23a0$561fa8c0@pcajain>
Message-ID: <625fc13d0609250350t3434dd69r72c1fc92fcfbc622@mail.gmail.com>

On 9/25/06, Ajay Jain <ajain at neomagic.com> wrote:
>
> 1. Is it possible to run JFFS2 on NAND Flash on 2.4. I am seeing that
> the mtd website mentions that it is not supported. I do not clearly
> understand what it means. Does it mean that mtd guys do not support it,
> or does it mean that you can't run JFFS2 on nand in 2.4 at all.

The latter.  Unless you attempt to backport the code from 2.6.  And
that is definitely unsupported.

> 3. Because of this, we backported 'mtd' from 2.6 version. Now the mtd
> appears to be reasonably stable. But we still have the old jffs2 in
> place. The new mtd does not allow unaligned writes, but jffs2 (the old
> one) keeps sending unaligned requests. We modified the mtd layer to
> handle this, but then the issue is that we are writing to the same page
> again and again, as the writes are unaligned. But the ecc value can only
> be written once. So this solution will not work either. It does work if
> we switch off the ecc. Are you aware of any of these issues, is my
> observation correct.

You would need newer JFFS2.

> 4. Is it realistically possible to backport 2.6 JFFS2 to 2.4.

No, not really.

> Please help me to solve these issues. We want to run JFFS2 on 2.4/NAND.

http://linux-mtd.infradead.org/source.html#kernelversions

josh



From raph at 8d.com  Mon Sep 25 09:07:55 2006
From: raph at 8d.com (Raphael Assenat)
Date: Mon, 25 Sep 2006 09:07:55 -0400
Subject: [PATCH] cmx270-nand: Make CMDLINE_PARTS usable
In-Reply-To: <1158936240.24527.733.camel@pmac.infradead.org>
References: <4507FE99.3030106@8d.com>	
	<1158917790.24527.664.camel@pmac.infradead.org>
	<4513F01D.80608@8d.com>
	<1158936240.24527.733.camel@pmac.infradead.org>
Message-ID: <4517D4AB.2060706@8d.com>

David Woodhouse wrote:
> On Fri, 2006-09-22 at 10:15 -0400, Raphael Assenat wrote:
> 
>>Oh, sorry. My patch applies over the patch Mike Rapoport sent to the list on July 18
>>([PATCH] [MTD] CM-x270 NAND flash support), which I thought was already accepted. Was 
>>there anything wrong with it? Maybe you just missed it...
>>
>>I also sent a patch to the list on July 21 which added NAND flash support for the cm-x255 
>>boards ([PATCH] Add support for NAND flash on cm-x255) but received no feedback. I can 
>>resend it if you wish.
> 
> 
> July and August weren't really a good time for sending stuff that you
> expect me to pay attention to; sorry. Yes -- please retest and resend.
> 
> Can you explain how these two boards differ, and why they need two
> separate drivers?
Yes.

NAND on cm-x255:
- Uses physical address 0x04000000
- CS, ALE, CLE and RB mapped to pxa GPIOs 5,4,3,10 respectively.

NAND on cm-x270:
- CS and RB mapped to pxa GPIOs 11 and 89
- Read/Write with ALE/CLE inactive: 0x04000000
- Read/Write with ALE active: 0x04000008
- Read/Write with CLE active: 0x04000004

The base address is the same, but GPIOs used differ and the control signals
are controlled differently.


>>(BTW, every time I send to the linux-mtd list my message is held for moderator approval 
>>for reason 'Message has a suspicious header'. Who should I contact for more information? 
>>I'd like to know exactly what header(s) is/are 'suspicious' and fix them if possible).
> 
> 
> It just doesn't like attachments. Send patches inline and they shouldn't
> get trapped.

Best regards,

-- 
Raphael Assenat
8D Technologies Inc.



From raph at raphnet.net  Mon Sep 25 10:57:27 2006
From: raph at raphnet.net (Raphael Assenat)
Date: Mon, 25 Sep 2006 10:57:27 -0400
Subject: [PATCH] cmx270-nand: Make CMDLINE_PARTS usable
In-Reply-To: <4517D4AB.2060706@8d.com>
References: <4507FE99.3030106@8d.com>
	<1158917790.24527.664.camel@pmac.infradead.org> <4513F01D.80608@8d.com>
	<1158936240.24527.733.camel@pmac.infradead.org>
	<4517D4AB.2060706@8d.com>
Message-ID: <20060925145726.GI7749@aramis.lan.raphnet.net>

On Mon, Sep 25, 2006 at 09:07:55AM -0400, Raphael Assenat wrote:
> David Woodhouse wrote:
> > On Fri, 2006-09-22 at 10:15 -0400, Raphael Assenat wrote:
> > 
> >>Oh, sorry. My patch applies over the patch Mike Rapoport sent to the list on July 18
> >>([PATCH] [MTD] CM-x270 NAND flash support), which I thought was already accepted. Was 
> >>there anything wrong with it? Maybe you just missed it...
> >>
> >>I also sent a patch to the list on July 21 which added NAND flash support for the cm-x255 
> >>boards ([PATCH] Add support for NAND flash on cm-x255) but received no feedback. I can 
> >>resend it if you wish.
> > 
> > 
> > July and August weren't really a good time for sending stuff that you
> > expect me to pay attention to; sorry. Yes -- please retest and resend.
Here comes the resend.

This patch adds support for the NAND flash present on Compulab's cm-x255
boards. Since Compulab chose to discontinue cm-x255 support, I decided
to submit and support this driver myself.

Note: This is the driver I wrote as part of my Compulab kernel fork
project (see http://raph.people.8d.com/armcore_kernel.php). It is not
based on the driver Mike posted to the list.

Applies to 2.6.18

Signed-off-by: Raphael Assenat <raph at 8d.com>

diff -Nru linux-2.6.18-rc2/drivers/mtd/nand/Kconfig linux-2.6.18-rc2-mtd/drivers/mtd/nand/Kconfig
--- linux-2.6.18-rc2/drivers/mtd/nand/Kconfig	2006-07-17 15:19:57.000000000 -0400
+++ linux-2.6.18-rc2-mtd/drivers/mtd/nand/Kconfig	2006-07-21 14:36:03.000000000 -0400
@@ -239,4 +239,11 @@
 	  The simulator may simulate various NAND flash chips for the
 	  MTD nand layer.
 
+config MTD_NAND_CM_X255
+	tristate "Support for NAND Flash on Compulab cm-x255"
+	depends on MTD_NAND && MACH_CM_X255
+	help
+	  This enables the driver for the NAND flash present
+	  on the cm-x255 board from Compulab.
+
 endmenu
diff -Nru linux-2.6.18-rc2/drivers/mtd/nand/Makefile linux-2.6.18-rc2-mtd/drivers/mtd/nand/Makefile
--- linux-2.6.18-rc2/drivers/mtd/nand/Makefile	2006-07-17 15:19:57.000000000 -0400
+++ linux-2.6.18-rc2-mtd/drivers/mtd/nand/Makefile	2006-07-21 14:36:31.000000000 -0400
@@ -22,5 +22,6 @@
 obj-$(CONFIG_MTD_NAND_NANDSIM)		+= nandsim.o
 obj-$(CONFIG_MTD_NAND_CS553X)		+= cs553x_nand.o
 obj-$(CONFIG_MTD_NAND_NDFC)		+= ndfc.o
+obj-$(CONFIG_MTD_NAND_CM_X255)		+= cm-x255.o
 
 nand-objs = nand_base.o nand_bbt.o
diff -Nru linux-2.6.18-rc2/drivers/mtd/nand/cm-x255.c linux-2.6.18-rc2-mtd/drivers/mtd/nand/cm-x255.c
--- linux-2.6.18-rc2/drivers/mtd/nand/cm-x255.c	1969-12-31 19:00:00.000000000 -0500
+++ linux-2.6.18-rc2-mtd/drivers/mtd/nand/cm-x255.c	2006-07-21 15:02:02.000000000 -0400
@@ -0,0 +1,183 @@
+/*
+ * drivers/mtd/nand/cm-x255.c
+ *
+ * Copyright (c) 2006, 8D Technologies inc.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ *  Overview:
+ *   This is a device driver for the NAND flash device found on the
+ *   cm-x255 compulab sbc (formerly known as armcore).
+ *   
+ *  Changelog:
+ *  - April 2006, Raphael Assenat <raph at 8d.com>:
+ * 	Creation of the driver.
+ * 	   
+ *  - Jul 18, 2006: Raphael Assenat <raph at 8d.com>:
+ * 	Updates for 2.6.18
+ */
+#include <linux/mtd/mtd.h>
+#include <linux/mtd/nand.h>
+#include <linux/mtd/partitions.h>
+#include <linux/delay.h>
+#include <asm/hardware.h>
+#include <asm/io.h>
+#include <asm/arch/pxa-regs.h>
+#include <asm/arch/cm-x255.h>
+
+#define GPIO_NAND_CS	5
+#define GPIO_NAND_ALE	4
+#define GPIO_NAND_CLE	3
+#define GPIO_NAND_RB	10
+
+#define DRAIN_WRITE_BUFFER() do { \
+	asm volatile ("mcr p15, 0, r0, c7, c10, 4\n":::"r0"); \
+	dummy=*((volatile unsigned char*)UNCACHED_ADDR); \
+	} while(0)
+
+static struct mtd_info *armcore_mtd = NULL;
+static void __iomem *armcore_nand_io_base;
+static long armcore_nand_phys_base = 0x04000000;
+
+#define DEFAULT_NUM_PARTITIONS 1
+static int nr_partitions;
+static struct mtd_partition armcore_default_partition_info[] = {
+	{
+	.name = "rootfs",
+	.offset = 0,
+	.size = MTDPART_SIZ_FULL,
+	},
+};
+
+static void armcore_nand_cmd_ctrl(struct mtd_info *mtd, int cmd, 
+						unsigned int ctrl)
+{
+	struct nand_chip *chip = mtd->priv;	
+	unsigned char dummy;
+
+	DRAIN_WRITE_BUFFER();
+
+	if (ctrl & NAND_CTRL_CHANGE)
+	{
+		if (ctrl & NAND_NCE) 
+			GPCR(GPIO_NAND_CS) = GPIO_bit(GPIO_NAND_CS); 
+		else
+			GPSR(GPIO_NAND_CS) = GPIO_bit(GPIO_NAND_CS); 
+
+		if (ctrl & NAND_CLE)
+			GPSR(GPIO_NAND_CLE) = GPIO_bit(GPIO_NAND_CLE); 
+		else
+			GPCR(GPIO_NAND_CLE) = GPIO_bit(GPIO_NAND_CLE); 
+
+		if (ctrl & NAND_ALE)
+			GPSR(GPIO_NAND_ALE) = GPIO_bit(GPIO_NAND_ALE); 
+		else
+			GPCR(GPIO_NAND_ALE) = GPIO_bit(GPIO_NAND_ALE); 
+
+	}
+	
+	DRAIN_WRITE_BUFFER();
+
+	if (cmd != NAND_CMD_NONE)
+		writeb(cmd, chip->IO_ADDR_W);
+}
+
+static int armcore_nand_device_ready(struct mtd_info *mtd)
+{
+	return GPLR(GPIO_NAND_RB) & GPIO_bit(GPIO_NAND_RB);
+}
+
+#ifdef CONFIG_MTD_PARTITIONS
+const char *part_probes[] = { "cmdlinepart", NULL };
+#endif
+
+int __init armcore_nand_init(void)
+{
+	struct nand_chip *this;
+	struct mtd_partition* armcore_partition_info;
+	int err = 0;
+
+	pxa_gpio_mode(GPIO_NAND_RB);
+	pxa_gpio_mode(GPIO_NAND_CS | GPIO_OUT | GPIO_DFLT_HIGH);
+	pxa_gpio_mode(GPIO_NAND_ALE | GPIO_OUT | GPIO_DFLT_LOW);
+	pxa_gpio_mode(GPIO_NAND_CLE | GPIO_OUT | GPIO_DFLT_LOW);
+	
+	/* Allocate memory for MTD device structure and private data */	
+	armcore_mtd = kmalloc(	sizeof(struct mtd_info) + 
+				sizeof(struct nand_chip), 
+						GFP_KERNEL);
+	if (!armcore_mtd) {
+		printk(KERN_WARNING 
+		"Unable to allocate cm-x255 nand mtd device structure.\n");
+		err = -ENOMEM;
+		goto out;
+	}
+
+	/* map physical adress */
+	armcore_nand_io_base = ioremap(armcore_nand_phys_base, 0x100);
+	if (!armcore_nand_io_base) {
+		printk(KERN_WARNING "ioremap for cm-x255 NAND chip failed\n");
+		err = -EIO;
+		goto out_mtd;
+	}
+
+	/* Get pointer to private data */
+	this = (struct nand_chip *) (&armcore_mtd[1]);
+
+	/* Initialize structures */
+	memset((char *) armcore_mtd, 0, sizeof(struct mtd_info));
+	memset((char *) this, 0, sizeof(struct nand_chip));
+
+	/* Link the private data with the MTD structure */
+	armcore_mtd->priv = this;
+
+	this->IO_ADDR_R = armcore_nand_io_base;	
+	this->IO_ADDR_W = armcore_nand_io_base;	
+	this->cmd_ctrl = armcore_nand_cmd_ctrl;
+	this->dev_ready = armcore_nand_device_ready;
+	this->chip_delay = 15;
+	this->ecc.mode = NAND_ECC_SOFT;
+
+	/* Scan to find existance of the device */
+	if (nand_scan(armcore_mtd, 1)) {
+		printk(KERN_WARNING 
+			"nand_scan() failed to scan cm-x255 nand flash\n");
+		err = -ENXIO;
+		goto out_ior;
+	}
+
+	/* Register the partitions */
+	armcore_mtd->name = "armcore-nand";
+	nr_partitions = parse_mtd_partitions(armcore_mtd, part_probes,
+						&armcore_partition_info, 0);
+	if (nr_partitions <= 0) {
+		nr_partitions = DEFAULT_NUM_PARTITIONS;
+		armcore_partition_info = armcore_default_partition_info;
+	}
+
+	add_mtd_partitions(armcore_mtd, armcore_partition_info, nr_partitions);	
+	
+	goto out;
+
+out_ior:
+	iounmap((void*) armcore_nand_io_base);
+out_mtd:
+	kfree(armcore_mtd);
+out:
+	return err;
+}
+module_init(armcore_nand_init);
+
+static void __exit armcore_nand_cleanup(void)
+{
+	nand_release(armcore_mtd);
+	iounmap((void*)armcore_nand_io_base);
+	kfree(armcore_mtd);
+}
+module_exit(armcore_nand_cleanup);
+
+MODULE_LICENSE("GPL");
+MODULE_AUTHOR("Raphael Assenat <raph at 8d.com>");
+MODULE_DESCRIPTION("NAND flash driver for cm-x255 boards");



From kyungmin.park at samsung.com  Mon Sep 25 19:53:28 2006
From: kyungmin.park at samsung.com (Kyungmin Park)
Date: Mon, 25 Sep 2006 23:53:28 +0000 (GMT)
Subject: [PATCH] OneNAND: fix OneNAND probe
Message-ID: <27051608.13531159228419864.JavaMail.weblogic@ep_ml12>

Hi

Here's a patch of OneNAND probing.
Sometime some board don't probe OneNAND because of not enough time after reset. And it will read system configuration regs *always* with async. mode.

Please apply this patch.

Thank you,
Kyungmin Park

--

[MTD ONENAND] Fix OneNAND probe

        - fix OneNAND probe whether OneNAND Sync. Burst read mode or not
        - fix OneNAND reset wait problem

Signed-off-by: Kyungmin Park <kyungmin.park at samsung.com>
---

--- a/drivers/mtd/onenand/onenand_base.c
+++ b/drivers/mtd/onenand/onenand_base.c
@@ -1628,6 +1628,12 @@ static int onenand_probe(struct mtd_info
 	int bram_maf_id, bram_dev_id, maf_id, dev_id;
 	int version_id;
 	int density;
+	int syscfg;
+
+	/* Save system configuration 1 */
+	syscfg = this->read_word(this->base + ONENAND_REG_SYS_CFG1);
+	/* Clear Sync. Burst Read mode to read BootRAM */
+	this->write_word((syscfg & ~ONENAND_SYS_CFG1_SYNC_READ), this->base + ONENAND_REG_SYS_CFG1);
 
 	/* Send the command for reading device ID from BootRAM */
 	this->write_word(ONENAND_CMD_READID, this->base + ONENAND_BOOTRAM);
@@ -1636,13 +1642,18 @@ static int onenand_probe(struct mtd_info
 	bram_maf_id = this->read_word(this->base + ONENAND_BOOTRAM + 0x0);
 	bram_dev_id = this->read_word(this->base + ONENAND_BOOTRAM + 0x2);
 
+	/* Reset OneNAND to read default register values */
+	this->write_word(ONENAND_CMD_RESET, this->base + ONENAND_BOOTRAM);
+	/* Wait reset */
+	this->wait(mtd, FL_RESETING);
+
+	/* Restore system configuration 1 */
+	this->write_word(syscfg, this->base + ONENAND_REG_SYS_CFG1);
+
 	/* Check manufacturer ID */
 	if (onenand_check_maf(bram_maf_id))
 		return -ENXIO;
 
-	/* Reset OneNAND to read default register values */
-	this->write_word(ONENAND_CMD_RESET, this->base + ONENAND_BOOTRAM);
-
 	/* Read manufacturer and device IDs from Register */
 	maf_id = this->read_word(this->base + ONENAND_REG_MANUFACTURER_ID);
 	dev_id = this->read_word(this->base + ONENAND_REG_DEVICE_ID);

From traperpl at traperpl.eu  Mon Sep 25 21:52:59 2006
From: traperpl at traperpl.eu (=?UTF-8?Q?Wojciech_Krzywa=F1ski?=)
Date: Tue, 26 Sep 2006 03:52:59 +0200
Subject: Traper Gniezno - Greetings from Poland Content-type: text/html <html>
	<head> <title>Traper Gniezno</title> </head> <body>
	<font face="Arial"> <div aling="center"> <center>
	<h1>Greetings from Poland</h1><br>
	<a href="http://www.traperpl.eu"><img
	src="http://traperpl.eu/bocian.jpg"></a>
	<p><a href="http://www.traperpl.eu">www.traperpl.eu</a></p> </center>
	</div> </font> </body> </html>
Message-ID: <E1GS283-0007Rn-SD@traperpl.eu>




From kyungmin.park at samsung.com  Tue Sep 26 04:52:14 2006
From: kyungmin.park at samsung.com (Kyungmin Park)
Date: Tue, 26 Sep 2006 08:52:14 +0000 (GMT)
Subject: [PATCH] OneNAND: Remove unused MTD_ONENAND_SYNC_READ configuration
Message-ID: <21312547.179531159260743037.JavaMail.weblogic@ep_ml08>

[MTD ONENAND] Remove unused MTD_ONENAND_SYNC_READ configuration

Now the bootloader configures the OneNAND sync. burst mode.
So we don't access Sync. burst mode related registers in kernel.

Signed-off-by: Kyungmin Park <kyungmin.park at samsung.com>
---

--- a/drivers/mtd/onenand/Kconfig
+++ b/drivers/mtd/onenand/Kconfig
@@ -43,10 +43,4 @@ config MTD_ONENAND_OTP
 
 	  OTP block is fully-guaranteed to be a valid block.
 
-config MTD_ONENAND_SYNC_READ
-	bool "OneNAND Sync. Burst Read Support"
-	depends on ARCH_OMAP
-	help
-	  This enables support for Sync. Burst Read.
-
 endmenu

 

From kyungmin.park at samsung.com  Tue Sep 26 05:45:28 2006
From: kyungmin.park at samsung.com (Kyungmin Park)
Date: Tue, 26 Sep 2006 09:45:28 +0000 (GMT)
Subject: [PATHC] OneNAND: Probe correct lock scheme
Message-ID: <2840544.78561159263938269.JavaMail.weblogic@ep_ml12>

[MTD ONENAND] Check OneNAND lock scheme & all block unlock command support

OneNAND lock scheme depends on density and process of chip.
Some OneNAND chips support all block unlock

Signed-off-by: Kyungmin Park <kyungmin.park at samsung.com>
---

--- a/drivers/mtd/onenand/onenand_base.c
+++ b/drivers/mtd/onenand/onenand_base.c
@@ -1,7 +1,7 @@
 /*
  *  linux/drivers/mtd/onenand/onenand_base.c
  *
- *  Copyright (C) 2005 Samsung Electronics
+ *  Copyright (C) 2005-2006 Samsung Electronics
  *  Kyungmin Park <kyungmin.park at samsung.com>
  *
  * This program is free software; you can redistribute it and/or modify
@@ -199,6 +199,7 @@ static int onenand_command(struct mtd_in
 	case ONENAND_CMD_UNLOCK:
 	case ONENAND_CMD_LOCK:
 	case ONENAND_CMD_LOCK_TIGHT:
+	case ONENAND_CMD_UNLOCK_ALL:
 		block = -1;
 		page = -1;
 		break;
@@ -1211,11 +1212,11 @@ static int onenand_unlock(struct mtd_inf
 	end = len >> this->erase_shift;
 
 	/* Continuous lock scheme */
-	if (this->options & ONENAND_CONT_LOCK) {
+	if (this->options & ONENAND_HAS_CONT_LOCK) {
 		/* Set start block address */
 		this->write_word(start, this->base + ONENAND_REG_START_BLOCK_ADDRESS);
 		/* Set end block address */
-		this->write_word(end - 1, this->base + ONENAND_REG_END_BLOCK_ADDRESS);
+		this->write_word(start + end - 1, this->base + ONENAND_REG_END_BLOCK_ADDRESS);
 		/* Write unlock command */
 		this->command(mtd, ONENAND_CMD_UNLOCK, 0, 0);
 
@@ -1236,7 +1237,7 @@ static int onenand_unlock(struct mtd_inf
 	}
 
 	/* Block lock scheme */
-	for (block = start; block < end; block++) {
+	for (block = start; block < start + end; block++) {
 		/* Set block address */
 		value = onenand_block_address(this, block);
 		this->write_word(value, this->base + ONENAND_REG_START_ADDRESS1);
@@ -1265,6 +1266,79 @@ static int onenand_unlock(struct mtd_inf
 	return 0;
 }
 
+/**
+ * onenand_check_lock_status - [OneNAND Interface] Check lock status
+ * @param this		onenand chip data structure
+ *
+ * Check lock status
+ */
+static void onenand_check_lock_status(struct onenand_chip *this)
+{
+	unsigned int value, block, status;
+	unsigned int end;
+
+	end = this->chipsize >> this->erase_shift;
+	for (block = 0; block < end; block++) {
+		/* Set block address */
+		value = onenand_block_address(this, block);
+		this->write_word(value, this->base + ONENAND_REG_START_ADDRESS1);
+		/* Select DataRAM for DDP */
+		value = onenand_bufferram_address(this, block);
+		this->write_word(value, this->base + ONENAND_REG_START_ADDRESS2);
+		/* Set start block address */
+		this->write_word(block, this->base + ONENAND_REG_START_BLOCK_ADDRESS);
+
+		/* Check lock status */
+		status = this->read_word(this->base + ONENAND_REG_WP_STATUS);
+		if (!(status & ONENAND_WP_US))
+			printk(KERN_ERR "block = %d, wp status = 0x%x\n", block, status);
+	}
+}
+
+/**
+ * onenand_unlock_all - [OneNAND Interface] unlock all blocks
+ * @param mtd		MTD device structure
+ *
+ * Unlock all blocks
+ */
+static int onenand_unlock_all(struct mtd_info *mtd)
+{
+	struct onenand_chip *this = mtd->priv;
+
+	if (this->options & ONENAND_HAS_UNLOCK_ALL) {
+		/* Write unlock command */
+		this->command(mtd, ONENAND_CMD_UNLOCK_ALL, 0, 0);
+
+		/* There's no return value */
+		this->wait(mtd, FL_UNLOCKING);
+
+		/* Sanity check */
+		while (this->read_word(this->base + ONENAND_REG_CTRL_STATUS)
+		    & ONENAND_CTRL_ONGO)
+			continue;
+
+		/* Workaround for all block unlock in DDP */
+		if (this->device_id & ONENAND_DEVICE_IS_DDP) {
+			loff_t ofs;
+			size_t len;
+
+			/* 1st block on another chip */
+			ofs = this->chipsize >> 1;
+			len = 1 << this->erase_shift;
+
+			onenand_unlock(mtd, ofs, len);
+		}
+
+		onenand_check_lock_status(this);
+
+		return 0;
+	}
+
+	mtd->unlock(mtd, 0x0, this->chipsize);
+
+	return 0;
+}
+
 #ifdef CONFIG_MTD_ONENAND_OTP
 
 /* Interal OTP operation */
@@ -1564,12 +1638,43 @@ static int onenand_lock_user_prot_reg(st
 #endif	/* CONFIG_MTD_ONENAND_OTP */
 
 /**
+ * onenand_lock_scheme - Check and set OneNAND lock scheme
+ * @param mtd		MTD data structure
+ *
+ * Check and set OneNAND lock scheme
+ */
+static void onenand_lock_scheme(struct mtd_info *mtd)
+{
+	struct onenand_chip *this = mtd->priv;
+	unsigned int density, process;
+
+	/* Lock scheme depends on density and process */
+	density = this->device_id >> ONENAND_DEVICE_DENSITY_SHIFT;
+	process = this->version_id >> ONENAND_VERSION_PROCESS_SHIFT;
+
+	/* Lock scheme */
+	if (density >= ONENAND_DEVICE_DENSITY_1Gb) {
+		/* A-Die has all block unlock */
+		if (process) {
+			printk(KERN_DEBUG "Chip support all block unlock\n");
+			this->options |= ONENAND_HAS_UNLOCK_ALL;
+		}
+	} else {
+		/* Some OneNAND has continues lock scheme */
+		if (!process) {
+			printk(KERN_DEBUG "Lock scheme is Continues Lock\n");
+			this->options |= ONENAND_HAS_CONT_LOCK;
+		}
+	}
+}
+
+/**
  * onenand_print_device_info - Print device ID
  * @param device        device ID
  *
  * Print device ID
  */
-static void onenand_print_device_info(int device)
+static void onenand_print_device_info(int device, int version)
 {
         int vcc, demuxed, ddp, density;
 
@@ -1583,6 +1688,7 @@ static void onenand_print_device_info(in
                 (16 << density),
                 vcc ? "2.65/3.3" : "1.8",
                 device);
+	printk(KERN_DEBUG "OneNAND version = 0x%04x\n", version);
 }
 
 static const struct onenand_manufacturers onenand_manuf_ids[] = {
@@ -1625,8 +1731,7 @@ static int onenand_check_maf(int manuf)
 static int onenand_probe(struct mtd_info *mtd)
 {
 	struct onenand_chip *this = mtd->priv;
-	int bram_maf_id, bram_dev_id, maf_id, dev_id;
-	int version_id;
+	int bram_maf_id, bram_dev_id, maf_id, dev_id, ver_id;
 	int density;
 	int syscfg;
 
@@ -1657,14 +1762,16 @@ static int onenand_probe(struct mtd_info
 	/* Read manufacturer and device IDs from Register */
 	maf_id = this->read_word(this->base + ONENAND_REG_MANUFACTURER_ID);
 	dev_id = this->read_word(this->base + ONENAND_REG_DEVICE_ID);
+	ver_id= this->read_word(this->base + ONENAND_REG_VERSION_ID);
 
 	/* Check OneNAND device */
 	if (maf_id != bram_maf_id || dev_id != bram_dev_id)
 		return -ENXIO;
 
 	/* Flash device information */
-	onenand_print_device_info(dev_id);
+	onenand_print_device_info(dev_id, ver_id);
 	this->device_id = dev_id;
+	this->version_id = ver_id;
 
 	density = dev_id >> ONENAND_DEVICE_DENSITY_SHIFT;
 	this->chipsize = (16 << density) << 20;
@@ -1687,16 +1794,8 @@ static int onenand_probe(struct mtd_info
 
 	mtd->size = this->chipsize;
 
-	/* Version ID */
-	version_id = this->read_word(this->base + ONENAND_REG_VERSION_ID);
-	printk(KERN_DEBUG "OneNAND version = 0x%04x\n", version_id);
-
-	/* Lock scheme */
-	if (density <= ONENAND_DEVICE_DENSITY_512Mb &&
-	    !(version_id >> ONENAND_VERSION_PROCESS_SHIFT)) {
-		printk(KERN_INFO "Lock scheme is Continues Lock\n");
-		this->options |= ONENAND_CONT_LOCK;
-	}
+	/* Check OneNAND lock scheme */
+	onenand_lock_scheme(mtd);
 
 	return 0;
 }
@@ -1832,7 +1931,7 @@ int onenand_scan(struct mtd_info *mtd, i
 	mtd->owner = THIS_MODULE;
 
 	/* Unlock whole block */
-	mtd->unlock(mtd, 0x0, this->chipsize);
+	onenand_unlock_all(mtd);
 
 	return this->scan_bbt(mtd);
 }
--- a/include/linux/mtd/onenand.h
+++ b/include/linux/mtd/onenand.h
@@ -1,7 +1,7 @@
 /*
  *  linux/include/linux/mtd/onenand.h
  *
- *  Copyright (C) 2005 Samsung Electronics
+ *  Copyright (C) 2005-2006 Samsung Electronics
  *  Kyungmin Park <kyungmin.park at samsung.com>
  *
  * This program is free software; you can redistribute it and/or modify
@@ -96,6 +96,7 @@ struct onenand_chip {
 	void __iomem		*base;
 	unsigned int		chipsize;
 	unsigned int		device_id;
+	unsigned int		version_id;
 	unsigned int		density_mask;
 	unsigned int		options;
 
@@ -149,7 +150,8 @@ struct onenand_chip {
 /*
  * Options bits
  */
-#define ONENAND_CONT_LOCK		(0x0001)
+#define ONENAND_HAS_CONT_LOCK		(0x0001)
+#define ONENAND_HAS_UNLOCK_ALL		(0x0002)
 #define ONENAND_PAGEBUF_ALLOC		(0x1000)
 
 /*
--- a/include/linux/mtd/onenand_regs.h
+++ b/include/linux/mtd/onenand_regs.h
@@ -3,7 +3,7 @@
  *
  *  OneNAND Register header file
  *
- *  Copyright (C) 2005 Samsung Electronics
+ *  Copyright (C) 2005-2006 Samsung Electronics
  *
  * This program is free software; you can redistribute it and/or modify
  * it under the terms of the GNU General Public License version 2 as
@@ -72,6 +72,7 @@
 #define ONENAND_DEVICE_VCC_MASK		(0x3)
 
 #define ONENAND_DEVICE_DENSITY_512Mb	(0x002)
+#define ONENAND_DEVICE_DENSITY_1Gb	(0x003)
 
 /*
  * Version ID Register F002h (R)
@@ -110,6 +111,7 @@
 #define ONENAND_CMD_UNLOCK		(0x23)
 #define ONENAND_CMD_LOCK		(0x2A)
 #define ONENAND_CMD_LOCK_TIGHT		(0x2C)
+#define ONENAND_CMD_UNLOCK_ALL		(0x27)
 #define ONENAND_CMD_ERASE		(0x94)
 #define ONENAND_CMD_RESET		(0xF0)
 #define ONENAND_CMD_OTP_ACCESS		(0x65)

From Seancatskill at rothe-fermetures.com  Tue Sep 26 07:31:32 2006
From: Seancatskill at rothe-fermetures.com (Mike)
Date: Tue, 26 Sep 2006 13:31:32 +0200
Subject: The world of fi nance has something great in s tore for you!
Message-ID: <90317698989842.9E63B6DF85@4QOMO>

There is something you always wanted to do, but did not know how. Stop worrying about being not rich enough - with our loans you have a huge list of purchasing options.Decided to b uy? Get a loan! Confidential, reliable and safe! Check out our rates.Apply now and you'll experience the customer service which makes people stay with us for decades.Stop calculating and start enjoying life! With our mor tgage deals you can afford this. http://4KPK.scafuol.com/?ncache=1030961




From Martin.Wedepohl at gdcanada.com  Tue Sep 26 17:27:52 2006
From: Martin.Wedepohl at gdcanada.com (Wedepohl, Martin)
Date: Tue, 26 Sep 2006 15:27:52 -0600
Subject: JFFS2 problem with filename length > 7
Message-ID: <2142BCFA1F7F0D468F8EE6C8DE719E6801C23A6A@CGYSVW100.gdcan.com>

I'm running into a problem with filename lengths greater than 7
characters.
Everything is fine until I unmount and then remount the device.

I'm running Linux 2.6.17 on a PowerPC 5200.

Any help would be greatly appreciated

bash-3.00# uname -r
2.6.17-g4e21eb5f-dirty
bash-3.00# eraseall /dev/mtd7
Erased 2048 Kibyte @ 0 -- 100% complete.
bash-3.00# mount -t jffs2 /dev/mtdblock7 /mnt
bash-3.00# touch /mnt/1
bash-3.00# touch /mnt/22
bash-3.00# touch /mnt/333
bash-3.00# touch /mnt/4444
bash-3.00# touch /mnt/55555
bash-3.00# touch /mnt/666666
bash-3.00# touch /mnt/7777777
bash-3.00# touch /mnt/88888888
bash-3.00# touch /mnt/999999999
bash-3.00# touch /mnt/aaaaaaaaaa
bash-3.00# ls -al /mnt
total 4
drwxr-xr-x   3 root root    0 Jan  1 01:01 .
drwxr-xr-x  15 7099  500 4096 Sep 26  2006 ..
-rw-r--r--   1 root root    0 Jan  1 01:01 1
-rw-r--r--   1 root root    0 Jan  1 01:01 22
-rw-r--r--   1 root root    0 Jan  1 01:01 333
-rw-r--r--   1 root root    0 Jan  1 01:01 4444
-rw-r--r--   1 root root    0 Jan  1 01:01 55555
-rw-r--r--   1 root root    0 Jan  1 01:01 666666
-rw-r--r--   1 root root    0 Jan  1 01:01 7777777
-rw-r--r--   1 root root    0 Jan  1 01:01 88888888
-rw-r--r--   1 root root    0 Jan  1 01:01 999999999
-rw-r--r--   1 root root    0 Jan  1 01:01 aaaaaaaaaa
bash-3.00# umount /dev/mtdblock7
bash-3.00# mount -t jffs2 /dev/mtdblock7 /mnt
bash-3.00# ls -al /mnt
ls: /mnt/8888: No such file or directory
ls: /mnt/9999: No such file or directory
ls: /mnt/aaaa: No such file or directory
total 4
drwxr-xr-x   3 root root    0 Jan  1 01:00 .
drwxr-xr-x  15 7099  500 4096 Sep 26  2006 ..
-rw-r--r--   1 root root    0 Jan  1 01:01 1
-rw-r--r--   1 root root    0 Jan  1 01:01 22
-rw-r--r--   1 root root    0 Jan  1 01:01 333
-rw-r--r--   1 root root    0 Jan  1 01:01 4444
-rw-r--r--   1 root root    0 Jan  1 01:01 55555
-rw-r--r--   1 root root    0 Jan  1 01:01 666666
-rw-r--r--   1 root root    0 Jan  1 01:01 7777777
bash-3.00#

The information contained in this e-mail message is PRIVATE. It may contain confidential information and may be legally privileged. It is intended for the exclusive use of the addressee(s). If you are not the intended recipient, you are hereby notified that any dissemination, distribution or reproduction of this communication is strictly prohibited. If the intended recipient(s) cannot be reached or if a transmission problem has occurred, please notify the sender immediately by return e-mail and destroy all copies of this message. 
Thank you. 




From jwboyer at gmail.com  Tue Sep 26 20:21:47 2006
From: jwboyer at gmail.com (Josh Boyer)
Date: Tue, 26 Sep 2006 19:21:47 -0500
Subject: JFFS2 problem with filename length > 7
In-Reply-To: <2142BCFA1F7F0D468F8EE6C8DE719E6801C23A6A@CGYSVW100.gdcan.com>
References: <2142BCFA1F7F0D468F8EE6C8DE719E6801C23A6A@CGYSVW100.gdcan.com>
Message-ID: <625fc13d0609261721g715010e1nc07ab887f909b19c@mail.gmail.com>

On 9/26/06, Wedepohl, Martin <Martin.Wedepohl at gdcanada.com> wrote:
> The information contained in this e-mail message is PRIVATE. It may contain confidential information and may be legally privileged. It is intended for the exclusive use of the addressee(s). If you are not the intended recipient, you are hereby notified that any dissemination, distribution or reproduction of this communication is strictly prohibited. If the intended recipient(s) cannot be reached or if a transmission problem has occurred, please notify the sender immediately by return e-mail and destroy all copies of this message.

Mailing lists are public domain.  I'm assuming, based on this notice,
that I cannot comment on the information in your email, and I'm
notifying you that I have destroyed all copies of this email.

In the future, do not post to a mailing list with such a disclaimer.

josh



From martinatgd at gmail.com  Wed Sep 27 01:13:17 2006
From: martinatgd at gmail.com (Martin Wedepohl)
Date: Tue, 26 Sep 2006 23:13:17 -0600
Subject: JFFS2 problem with filename length > 7
Message-ID: <67f0a57c0609262213j56993210h654450841dcac92f@mail.gmail.com>

I'm running into a problem with filename lengths greater than 7 characters.
Everything is fine until I unmount and then remount the device.

I'm running Linux 2.6.17 on a PowerPC 5200.

Any help would be greatly appreciated

bash-3.00# uname -r
2.6.17-g4e21eb5f-dirty
bash-3.00# eraseall /dev/mtd7
Erased 2048 Kibyte @ 0 -- 100% complete.
bash-3.00# mount -t jffs2 /dev/mtdblock7 /mnt
bash-3.00# touch /mnt/1
bash-3.00# touch /mnt/22
bash-3.00# touch /mnt/333
bash-3.00# touch /mnt/4444
bash-3.00# touch /mnt/55555
bash-3.00# touch /mnt/666666
bash-3.00# touch /mnt/7777777
bash-3.00# touch /mnt/88888888
bash-3.00# touch /mnt/999999999
bash-3.00# touch /mnt/aaaaaaaaaa
bash-3.00# ls -al /mnt
total 4
drwxr-xr-x   3 root root    0 Jan  1 01:01 .
drwxr-xr-x  15 7099  500 4096 Sep 26  2006 ..
-rw-r--r--   1 root root    0 Jan  1 01:01 1
-rw-r--r--   1 root root    0 Jan  1 01:01 22
-rw-r--r--   1 root root    0 Jan  1 01:01 333
-rw-r--r--   1 root root    0 Jan  1 01:01 4444
-rw-r--r--   1 root root    0 Jan  1 01:01 55555
-rw-r--r--   1 root root    0 Jan  1 01:01 666666
-rw-r--r--   1 root root    0 Jan  1 01:01 7777777
-rw-r--r--   1 root root    0 Jan  1 01:01 88888888
-rw-r--r--   1 root root    0 Jan  1 01:01 999999999
-rw-r--r--   1 root root    0 Jan  1 01:01 aaaaaaaaaa
bash-3.00# umount /dev/mtdblock7
bash-3.00# mount -t jffs2 /dev/mtdblock7 /mnt
bash-3.00# ls -al /mnt
ls: /mnt/8888: No such file or directory
ls: /mnt/9999: No such file or directory
ls: /mnt/aaaa: No such file or directory
total 4
drwxr-xr-x   3 root root    0 Jan  1 01:00 .
drwxr-xr-x  15 7099  500 4096 Sep 26  2006 ..
-rw-r--r--   1 root root    0 Jan  1 01:01 1
-rw-r--r--   1 root root    0 Jan  1 01:01 22
-rw-r--r--   1 root root    0 Jan  1 01:01 333
-rw-r--r--   1 root root    0 Jan  1 01:01 4444
-rw-r--r--   1 root root    0 Jan  1 01:01 55555
-rw-r--r--   1 root root    0 Jan  1 01:01 666666
-rw-r--r--   1 root root    0 Jan  1 01:01 7777777
bash-3.00#



From dwmw2 at infradead.org  Wed Sep 27 02:12:44 2006
From: dwmw2 at infradead.org (David Woodhouse)
Date: Wed, 27 Sep 2006 07:12:44 +0100
Subject: JFFS2 problem with filename length > 7
In-Reply-To: <67f0a57c0609262213j56993210h654450841dcac92f@mail.gmail.com>
References: <67f0a57c0609262213j56993210h654450841dcac92f@mail.gmail.com>
Message-ID: <1159337564.3309.91.camel@pmac.infradead.org>

On Tue, 2006-09-26 at 23:13 -0600, Martin Wedepohl wrote:
> bash-3.00# ls -al /mnt
> ls: /mnt/8888: No such file or directory
> ls: /mnt/9999: No such file or directory
> ls: /mnt/aaaa: No such file or directory

Weird. Please reproduce with CONFIG_JFFS2_FS_DEBUG=1 and show the
(KERN_DEBUG) messages -- preferably by capturing them (without loss)
over a serial port. Please also take a snapshot of the offending image
from the flash.

I suspect a hardware driver or wiring problem.

-- 
dwmw2




From havasi at inf.u-szeged.hu  Wed Sep 27 05:21:04 2006
From: havasi at inf.u-szeged.hu (Ferenc Havasi)
Date: Wed, 27 Sep 2006 11:21:04 +0200
Subject: JFFS3 plan extension and user space prototype
Message-ID: <451A4280.5090801@inf.u-szeged.hu>

Dear All!

We've updated our JFFS3 plan extension with many details, and mesurements.

We've also released a JFFS3 user space prototype. The goal of it was to
impelement it in a kernel-friendly way (make it relatively easy to use
this code later in kernel, too), and make possible to make performance
measurements.

Both of the can be downloaded from our website:

http://www.inf.u-szeged.hu/jffs2/jffs3.php

Any comments are welcome.

Ferenc




From gclement00 at gmail.com  Wed Sep 27 10:31:30 2006
From: gclement00 at gmail.com (Gregory CLEMENT)
Date: Wed, 27 Sep 2006 16:31:30 +0200
Subject: Exporting jffs2 by nfs with kernel 2.6
Message-ID: <305035a40609270731n150513b4obe4249b461a3d1bc@mail.gmail.com>

Hi all,

On 2.4.18 we managed to export a jffs2 filesystem by nfs.
Now on 2.6.16 we can't.
I found 2 problems for it:
First, changed was made in nfs, and now they test if
s_export_op is not a void pointer. By dding a pointer on
this structure (even this structure is void) makes nfs happy.
If the structure is void nfs use generic function, so for this part
I think it's ok

Second, nfs need to identify the filesystem to export. It is done
either by the device of the filesystem or by a "fsid". I didfn't see any
filesystem use a "fsid" and I don't know how to use it. So identification
is made if FS_REQUIRES_DEV is set. The problem was in kernel 2.5.7,
this flag was removed because "We never really used the block device anyway".
Do you mind setting this flag again? Or have you a better idea?

I joined my patch which make jffs2 exportable by nfs:


PS: I sent this mail 3 weeks ago to jffs-dev at axis.com before notice
that now jffs2 is discussed on this mailing-list.


Index: linux-2.6.16/fs/jffs2/super.c
===================================================================
diff -u -r1.1 -r1.2
--- linux-2.6.16/fs/jffs2/super.c	6 Jun 2006 16:18:24 -0000	1.1
+++ linux-2.6.16/fs/jffs2/super.c	6 Sep 2006 14:14:37 -0000	1.2
@@ -80,6 +80,10 @@
 	.sync_fs =	jffs2_sync_fs,
 };

+/* Just declare a void structure as A NULL value implies the default */
+static struct export_operations jffs2_export_ops;
+
+
 static int jffs2_sb_compare(struct super_block *sb, void *data)
 {
 	struct jffs2_sb_info *p = data;
@@ -150,6 +154,7 @@
 	spin_lock_init(&c->inocache_lock);

 	sb->s_op = &jffs2_super_operations;
+	sb->s_export_op = &jffs2_export_ops;
 	sb->s_flags = flags | MS_NOATIME;

 	ret = jffs2_do_fill_super(sb, data, (flags&MS_VERBOSE)?1:0);
@@ -314,6 +319,7 @@
 	.name =		"jffs2",
 	.get_sb =	jffs2_get_sb,
 	.kill_sb =	jffs2_kill_sb,
+	.fs_flags = FS_REQUIRES_DEV,
 };

 static int __init init_jffs2_fs(void)



-- 
Gregory CLEMENT
Adeneo



From jamie at shareable.org  Wed Sep 27 15:10:24 2006
From: jamie at shareable.org (Jamie Lokier)
Date: Wed, 27 Sep 2006 20:10:24 +0100
Subject: JFFS2 problem with filename length > 7
In-Reply-To: <625fc13d0609261721g715010e1nc07ab887f909b19c@mail.gmail.com>
References: <2142BCFA1F7F0D468F8EE6C8DE719E6801C23A6A@CGYSVW100.gdcan.com>
	<625fc13d0609261721g715010e1nc07ab887f909b19c@mail.gmail.com>
Message-ID: <20060927191024.GA25631@mail.shareable.org>

Josh Boyer wrote:
> On 9/26/06, Wedepohl, Martin <Martin.Wedepohl at gdcanada.com> wrote:
> > The information contained in this e-mail message is PRIVATE. It may contain confidential information and may be legally privileged. It is intended for the exclusive use of the addressee(s). If you are not the intended recipient, you are hereby notified that any dissemination, distribution or reproduction of this communication is strictly prohibited. If the intended recipient(s) cannot be reached or if a transmission problem has occurred, please notify the sender immediately by return e-mail and destroy all copies of this message.
> 
> Mailing lists are public domain.  I'm assuming, based on this notice,
> that I cannot comment on the information in your email, and I'm
> notifying you that I have destroyed all copies of this email.
> 
> In the future, do not post to a mailing list with such a disclaimer.

Ideally, public lists would simply reject such messages.

-- Jamie



From hskinnemoen at atmel.com  Fri Sep 15 10:38:51 2006
From: hskinnemoen at atmel.com (Haavard Skinnemoen)
Date: Fri, 15 Sep 2006 16:38:51 +0200
Subject: [-mm patch 3/3] AVR32 MTD: AT49BV6416 platform device for ATSTK1000
	(try 2)
In-Reply-To: <20060915163711.10d19763@cad-250-152.norway.atmel.com>
References: <20060915163102.73bf171d@cad-250-152.norway.atmel.com>
	<20060915163554.4f326bf6@cad-250-152.norway.atmel.com>
	<20060915163711.10d19763@cad-250-152.norway.atmel.com>
Message-ID: <20060915163851.78fb1105@cad-250-152.norway.atmel.com>

FRegister a platform device for the AT49BV6416 NOR flash chip on the
ATSTK1000 development board for use by the physmap MTD driver.

The SMC timings are set up before the platform device is registered
so that no board-specific mapping driver is necessary.

Signed-off-by: Haavard Skinnemoen <hskinnemoen at atmel.com>
---
 arch/avr32/boards/atstk1000/Makefile |    2 
 arch/avr32/boards/atstk1000/flash.c  |   95 +++++++++++++++++++++++++++++++++++
 2 files changed, 96 insertions(+), 1 deletion(-)

Index: linux-2.6.18-rc6-mm2/arch/avr32/boards/atstk1000/Makefile
===================================================================
--- linux-2.6.18-rc6-mm2.orig/arch/avr32/boards/atstk1000/Makefile	2006-09-15 13:41:12.000000000 +0200
+++ linux-2.6.18-rc6-mm2/arch/avr32/boards/atstk1000/Makefile	2006-09-15 13:44:30.000000000 +0200
@@ -1,2 +1,2 @@
-obj-y				+= setup.o spi.o
+obj-y				+= setup.o spi.o flash.o
 obj-$(CONFIG_BOARD_ATSTK1002)	+= atstk1002.o
Index: linux-2.6.18-rc6-mm2/arch/avr32/boards/atstk1000/flash.c
===================================================================
--- /dev/null	1970-01-01 00:00:00.000000000 +0000
+++ linux-2.6.18-rc6-mm2/arch/avr32/boards/atstk1000/flash.c	2006-09-15 13:45:21.000000000 +0200
@@ -0,0 +1,95 @@
+/*
+ * ATSTK1000 board-specific flash initialization
+ *
+ * Copyright (C) 2005-2006 Atmel Corporation
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+#include <linux/init.h>
+#include <linux/platform_device.h>
+#include <linux/mtd/mtd.h>
+#include <linux/mtd/partitions.h>
+#include <linux/mtd/physmap.h>
+
+#include <asm/arch/smc.h>
+
+static struct smc_config flash_config __initdata = {
+	.ncs_read_setup		= 0,
+	.nrd_setup		= 40,
+	.ncs_write_setup	= 0,
+	.nwe_setup		= 10,
+
+	.ncs_read_pulse		= 80,
+	.nrd_pulse		= 40,
+	.ncs_write_pulse	= 65,
+	.nwe_pulse		= 55,
+
+	.read_cycle		= 120,
+	.write_cycle		= 120,
+
+	.bus_width		= 2,
+	.nrd_controlled		= 1,
+	.nwe_controlled		= 1,
+	.byte_write		= 1,
+};
+
+static struct mtd_partition flash_parts[] = {
+	{
+		.name           = "u-boot",
+		.offset         = 0x00000000,
+		.size           = 0x00020000,           /* 128 KiB */
+		.mask_flags     = MTD_WRITEABLE,
+	},
+	{
+		.name           = "root",
+		.offset         = 0x00020000,
+		.size           = 0x007d0000,
+	},
+	{
+		.name           = "env",
+		.offset         = 0x007f0000,
+		.size           = 0x00010000,
+		.mask_flags     = MTD_WRITEABLE,
+	},
+};
+
+static struct physmap_flash_data flash_data = {
+	.width		= 2,
+	.nr_parts	= ARRAY_SIZE(flash_parts),
+	.parts		= flash_parts,
+};
+
+static struct resource flash_resource = {
+	.start		= 0x00000000,
+	.end		= 0x007fffff,
+	.flags		= IORESOURCE_MEM,
+};
+
+static struct platform_device flash_device = {
+	.name		= "physmap-flash",
+	.id		= 0,
+	.resource	= &flash_resource,
+	.num_resources	= 1,
+	.dev		= {
+		.platform_data = &flash_data,
+	},
+};
+
+/* This needs to be called after the SMC has been initialized */
+static int __init atstk1000_flash_init(void)
+{
+	int ret;
+
+	ret = smc_set_configuration(0, &flash_config);
+	if (ret < 0) {
+		printk(KERN_ERR "atstk1000: failed to set NOR flash timing\n");
+		return ret;
+	}
+
+	platform_device_register(&flash_device);
+
+	return 0;
+}
+device_initcall(atstk1000_flash_init);



From hskinnemoen at atmel.com  Fri Sep 15 10:37:11 2006
From: hskinnemoen at atmel.com (Haavard Skinnemoen)
Date: Fri, 15 Sep 2006 16:37:11 +0200
Subject: [-mm patch 2/3] AVR32 MTD: Unlock flash if necessary (try 2)
In-Reply-To: <20060915163554.4f326bf6@cad-250-152.norway.atmel.com>
References: <20060915163102.73bf171d@cad-250-152.norway.atmel.com>
	<20060915163554.4f326bf6@cad-250-152.norway.atmel.com>
Message-ID: <20060915163711.10d19763@cad-250-152.norway.atmel.com>

If a cfi_cmdset_0002 fixup installs an unlock() operation, use it
to unlock the whole flash after the erase regions have been set up.

I wanted to do this in the fixup itself, but it wouldn't work because
the erase regions hadn't been initialized, and mtd->size was zero.

Signed-off-by: Haavard Skinnemoen <hskinnemoen at atmel.com>
---
 drivers/mtd/chips/cfi_cmdset_0002.c |    9 +++++++++
 1 file changed, 9 insertions(+)

Index: linux-2.6.18-rc6-mm2/drivers/mtd/chips/cfi_cmdset_0002.c
===================================================================
--- linux-2.6.18-rc6-mm2.orig/drivers/mtd/chips/cfi_cmdset_0002.c	2006-09-15 14:39:40.000000000 +0200
+++ linux-2.6.18-rc6-mm2/drivers/mtd/chips/cfi_cmdset_0002.c	2006-09-15 15:45:41.000000000 +0200
@@ -416,6 +416,15 @@ static struct mtd_info *cfi_amdstd_setup
 	}
 #endif
 
+	/*
+	 * If an unlock() operation was installed by a fixup, use it
+	 * now to unlock the whole flash.
+	 */
+	if (mtd->unlock && mtd->unlock(mtd, 0, mtd->size))
+		printk(KERN_WARNING "%s: unlock failed, writes may not work\n",
+		       map->name);
+
+
 	/* FIXME: erase-suspend-program is broken.  See
 	   http://lists.infradead.org/pipermail/linux-mtd/2003-December/009001.html */
 	printk(KERN_NOTICE "cfi_cmdset_0002: Disabling erase-suspend-program due to code brokenness.\n");



From hskinnemoen at atmel.com  Fri Sep 15 10:35:54 2006
From: hskinnemoen at atmel.com (Haavard Skinnemoen)
Date: Fri, 15 Sep 2006 16:35:54 +0200
Subject: [-mm patch 1/3] AVR32 MTD: Static Memory Controller driver (try 2)
In-Reply-To: <20060915163102.73bf171d@cad-250-152.norway.atmel.com>
References: <20060915163102.73bf171d@cad-250-152.norway.atmel.com>
Message-ID: <20060915163554.4f326bf6@cad-250-152.norway.atmel.com>

This adds a simple API for configuring the static memory controller
along with an implementation for the Atmel HSMC.

Signed-off-by: Haavard Skinnemoen <hskinnemoen at atmel.com>
---
 arch/avr32/mach-at32ap/Makefile     |    2 
 arch/avr32/mach-at32ap/at32ap7000.c |   10 ++
 arch/avr32/mach-at32ap/hsmc.c       |  164 ++++++++++++++++++++++++++++++++++++
 arch/avr32/mach-at32ap/hsmc.h       |  127 +++++++++++++++++++++++++++
 include/asm-avr32/arch-at32ap/smc.h |   60 +++++++++++++
 5 files changed, 362 insertions(+), 1 deletion(-)

Index: linux-2.6.18-rc6-mm2/arch/avr32/mach-at32ap/Makefile
===================================================================
--- linux-2.6.18-rc6-mm2.orig/arch/avr32/mach-at32ap/Makefile	2006-09-15 10:00:15.000000000 +0200
+++ linux-2.6.18-rc6-mm2/arch/avr32/mach-at32ap/Makefile	2006-09-15 10:00:39.000000000 +0200
@@ -1,2 +1,2 @@
-obj-y				+= at32ap.o clock.o pio.o intc.o extint.o
+obj-y				+= at32ap.o clock.o pio.o intc.o extint.o hsmc.o
 obj-$(CONFIG_CPU_AT32AP7000)	+= at32ap7000.o
Index: linux-2.6.18-rc6-mm2/arch/avr32/mach-at32ap/at32ap7000.c
===================================================================
--- linux-2.6.18-rc6-mm2.orig/arch/avr32/mach-at32ap/at32ap7000.c	2006-09-15 10:00:15.000000000 +0200
+++ linux-2.6.18-rc6-mm2/arch/avr32/mach-at32ap/at32ap7000.c	2006-09-15 10:00:39.000000000 +0200
@@ -450,6 +450,13 @@ static struct clk hramc_clk = {
 	.users		= 1,
 };
 
+static struct resource smc0_resource[] = {
+	PBMEM(0xfff03400),
+};
+DEFINE_DEV(smc, 0);
+DEV_CLK(pclk, smc0, pbb, 13);
+DEV_CLK(mck, smc0, hsb, 0);
+
 static struct platform_device pdc_device = {
 	.name		= "pdc",
 	.id		= 0,
@@ -503,6 +510,7 @@ void __init at32_add_system_devices(void
 
 	platform_device_register(&at32_sm_device);
 	platform_device_register(&at32_intc0_device);
+	platform_device_register(&smc0_device);
 	platform_device_register(&pdc_device);
 
 	platform_device_register(&pio0_device);
@@ -796,6 +804,8 @@ struct clk *at32_clock_list[] = {
 	&at32_intc0_pclk,
 	&ebi_clk,
 	&hramc_clk,
+	&smc0_pclk,
+	&smc0_mck,
 	&pdc_hclk,
 	&pdc_pclk,
 	&pico_clk,
Index: linux-2.6.18-rc6-mm2/arch/avr32/mach-at32ap/hsmc.c
===================================================================
--- /dev/null	1970-01-01 00:00:00.000000000 +0000
+++ linux-2.6.18-rc6-mm2/arch/avr32/mach-at32ap/hsmc.c	2006-09-15 10:00:39.000000000 +0200
@@ -0,0 +1,164 @@
+/*
+ * Static Memory Controller for AT32 chips
+ *
+ * Copyright (C) 2006 Atmel Corporation
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+#define DEBUG
+#include <linux/clk.h>
+#include <linux/err.h>
+#include <linux/init.h>
+#include <linux/module.h>
+#include <linux/platform_device.h>
+
+#include <asm/io.h>
+#include <asm/arch/smc.h>
+
+#include "hsmc.h"
+
+#define NR_CHIP_SELECTS 6
+
+struct hsmc {
+	void __iomem *regs;
+	struct clk *pclk;
+	struct clk *mck;
+};
+
+static struct hsmc *hsmc;
+
+int smc_set_configuration(int cs, const struct smc_config *config)
+{
+	unsigned long mul;
+	unsigned long offset;
+	u32 setup, pulse, cycle, mode;
+
+	if (!hsmc)
+		return -ENODEV;
+	if (cs >= NR_CHIP_SELECTS)
+		return -EINVAL;
+
+	/*
+	 * cycles = x / T = x * f
+	 *   = ((x * 1000000000) * ((f * 65536) / 1000000000)) / 65536
+	 *   = ((x * 1000000000) * (((f / 10000) * 65536) / 100000)) / 65536
+	 */
+	mul = (clk_get_rate(hsmc->mck) / 10000) << 16;
+	mul /= 100000;
+
+#define ns2cyc(x) ((((x) * mul) + 65535) >> 16)
+
+	setup = (HSMC_BF(NWE_SETUP, ns2cyc(config->nwe_setup))
+		 | HSMC_BF(NCS_WR_SETUP, ns2cyc(config->ncs_write_setup))
+		 | HSMC_BF(NRD_SETUP, ns2cyc(config->nrd_setup))
+		 | HSMC_BF(NCS_RD_SETUP, ns2cyc(config->ncs_read_setup)));
+	pulse = (HSMC_BF(NWE_PULSE, ns2cyc(config->nwe_pulse))
+		 | HSMC_BF(NCS_WR_PULSE, ns2cyc(config->ncs_write_pulse))
+		 | HSMC_BF(NRD_PULSE, ns2cyc(config->nrd_pulse))
+		 | HSMC_BF(NCS_RD_PULSE, ns2cyc(config->ncs_read_pulse)));
+	cycle = (HSMC_BF(NWE_CYCLE, ns2cyc(config->write_cycle))
+		 | HSMC_BF(NRD_CYCLE, ns2cyc(config->read_cycle)));
+
+	switch (config->bus_width) {
+	case 1:
+		mode = HSMC_BF(DBW, HSMC_DBW_8_BITS);
+		break;
+	case 2:
+		mode = HSMC_BF(DBW, HSMC_DBW_16_BITS);
+		break;
+	case 4:
+		mode = HSMC_BF(DBW, HSMC_DBW_32_BITS);
+		break;
+	default:
+		return -EINVAL;
+	}
+
+	if (config->nrd_controlled)
+		mode |= HSMC_BIT(READ_MODE);
+	if (config->nwe_controlled)
+		mode |= HSMC_BIT(WRITE_MODE);
+	if (config->byte_write)
+		mode |= HSMC_BIT(BAT);
+
+	pr_debug("smc cs%d: setup/%08x pulse/%08x cycle/%08x mode/%08x\n",
+		 cs, setup, pulse, cycle, mode);
+
+	offset = cs * 0x10;
+	hsmc_writel(hsmc, SETUP0 + offset, setup);
+	hsmc_writel(hsmc, PULSE0 + offset, pulse);
+	hsmc_writel(hsmc, CYCLE0 + offset, cycle);
+	hsmc_writel(hsmc, MODE0 + offset, mode);
+	hsmc_readl(hsmc, MODE0); /* I/O barrier */
+
+	return 0;
+}
+EXPORT_SYMBOL(smc_set_configuration);
+
+static int hsmc_probe(struct platform_device *pdev)
+{
+	struct resource *regs;
+	struct clk *pclk, *mck;
+	int ret;
+
+	if (hsmc)
+		return -EBUSY;
+
+	regs = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+	if (!regs)
+		return -ENXIO;
+	pclk = clk_get(&pdev->dev, "pclk");
+	if (IS_ERR(pclk))
+		return PTR_ERR(pclk);
+	mck = clk_get(&pdev->dev, "mck");
+	if (IS_ERR(mck)) {
+		ret = PTR_ERR(mck);
+		goto out_put_pclk;
+	}
+
+	ret = -ENOMEM;
+	hsmc = kzalloc(sizeof(struct hsmc), GFP_KERNEL);
+	if (!hsmc)
+		goto out_put_clocks;
+
+	clk_enable(pclk);
+	clk_enable(mck);
+
+	hsmc->pclk = pclk;
+	hsmc->mck = mck;
+	hsmc->regs = ioremap(regs->start, regs->end - regs->start + 1);
+	if (!hsmc->regs)
+		goto out_disable_clocks;
+
+	dev_info(&pdev->dev, "Atmel Static Memory Controller at 0x%08lx\n",
+		 (unsigned long)regs->start);
+
+	platform_set_drvdata(pdev, hsmc);
+
+	return 0;
+
+out_disable_clocks:
+	clk_disable(mck);
+	clk_disable(pclk);
+	kfree(hsmc);
+out_put_clocks:
+	clk_put(mck);
+out_put_pclk:
+	clk_put(pclk);
+	hsmc = NULL;
+	return ret;
+}
+
+static struct platform_driver hsmc_driver = {
+	.probe		= hsmc_probe,
+	.driver		= {
+		.name	= "smc",
+	},
+};
+
+static int __init hsmc_init(void)
+{
+	return platform_driver_register(&hsmc_driver);
+}
+arch_initcall(hsmc_init);
Index: linux-2.6.18-rc6-mm2/arch/avr32/mach-at32ap/hsmc.h
===================================================================
--- /dev/null	1970-01-01 00:00:00.000000000 +0000
+++ linux-2.6.18-rc6-mm2/arch/avr32/mach-at32ap/hsmc.h	2006-09-15 10:03:32.000000000 +0200
@@ -0,0 +1,127 @@
+/*
+ * Register definitions for Atmel Static Memory Controller (SMC)
+ *
+ * Copyright (C) 2006 Atmel Corporation
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+#ifndef __ASM_AVR32_HSMC_H__
+#define __ASM_AVR32_HSMC_H__
+
+/* HSMC register offsets */
+#define HSMC_SETUP0				0x0000
+#define HSMC_PULSE0				0x0004
+#define HSMC_CYCLE0				0x0008
+#define HSMC_MODE0				0x000c
+#define HSMC_SETUP1				0x0010
+#define HSMC_PULSE1				0x0014
+#define HSMC_CYCLE1				0x0018
+#define HSMC_MODE1				0x001c
+#define HSMC_SETUP2				0x0020
+#define HSMC_PULSE2				0x0024
+#define HSMC_CYCLE2				0x0028
+#define HSMC_MODE2				0x002c
+#define HSMC_SETUP3				0x0030
+#define HSMC_PULSE3				0x0034
+#define HSMC_CYCLE3				0x0038
+#define HSMC_MODE3				0x003c
+#define HSMC_SETUP4				0x0040
+#define HSMC_PULSE4				0x0044
+#define HSMC_CYCLE4				0x0048
+#define HSMC_MODE4				0x004c
+#define HSMC_SETUP5				0x0050
+#define HSMC_PULSE5				0x0054
+#define HSMC_CYCLE5				0x0058
+#define HSMC_MODE5				0x005c
+
+/* Bitfields in SETUP0 */
+#define HSMC_NWE_SETUP_OFFSET			0
+#define HSMC_NWE_SETUP_SIZE			6
+#define HSMC_NCS_WR_SETUP_OFFSET		8
+#define HSMC_NCS_WR_SETUP_SIZE			6
+#define HSMC_NRD_SETUP_OFFSET			16
+#define HSMC_NRD_SETUP_SIZE			6
+#define HSMC_NCS_RD_SETUP_OFFSET		24
+#define HSMC_NCS_RD_SETUP_SIZE			6
+
+/* Bitfields in PULSE0 */
+#define HSMC_NWE_PULSE_OFFSET			0
+#define HSMC_NWE_PULSE_SIZE			7
+#define HSMC_NCS_WR_PULSE_OFFSET		8
+#define HSMC_NCS_WR_PULSE_SIZE			7
+#define HSMC_NRD_PULSE_OFFSET			16
+#define HSMC_NRD_PULSE_SIZE			7
+#define HSMC_NCS_RD_PULSE_OFFSET		24
+#define HSMC_NCS_RD_PULSE_SIZE			7
+
+/* Bitfields in CYCLE0 */
+#define HSMC_NWE_CYCLE_OFFSET			0
+#define HSMC_NWE_CYCLE_SIZE			9
+#define HSMC_NRD_CYCLE_OFFSET			16
+#define HSMC_NRD_CYCLE_SIZE			9
+
+/* Bitfields in MODE0 */
+#define HSMC_READ_MODE_OFFSET			0
+#define HSMC_READ_MODE_SIZE			1
+#define HSMC_WRITE_MODE_OFFSET			1
+#define HSMC_WRITE_MODE_SIZE			1
+#define HSMC_EXNW_MODE_OFFSET			4
+#define HSMC_EXNW_MODE_SIZE			2
+#define HSMC_BAT_OFFSET				8
+#define HSMC_BAT_SIZE				1
+#define HSMC_DBW_OFFSET				12
+#define HSMC_DBW_SIZE				2
+#define HSMC_TDF_CYCLES_OFFSET			16
+#define HSMC_TDF_CYCLES_SIZE			4
+#define HSMC_TDF_MODE_OFFSET			20
+#define HSMC_TDF_MODE_SIZE			1
+#define HSMC_PMEN_OFFSET			24
+#define HSMC_PMEN_SIZE				1
+#define HSMC_PS_OFFSET				28
+#define HSMC_PS_SIZE				2
+
+/* Constants for READ_MODE */
+#define HSMC_READ_MODE_NCS_CONTROLLED		0
+#define HSMC_READ_MODE_NRD_CONTROLLED		1
+
+/* Constants for WRITE_MODE */
+#define HSMC_WRITE_MODE_NCS_CONTROLLED		0
+#define HSMC_WRITE_MODE_NWE_CONTROLLED		1
+
+/* Constants for EXNW_MODE */
+#define HSMC_EXNW_MODE_DISABLED			0
+#define HSMC_EXNW_MODE_RESERVED			1
+#define HSMC_EXNW_MODE_FROZEN			2
+#define HSMC_EXNW_MODE_READY			3
+
+/* Constants for BAT */
+#define HSMC_BAT_BYTE_SELECT			0
+#define HSMC_BAT_BYTE_WRITE			1
+
+/* Constants for DBW */
+#define HSMC_DBW_8_BITS				0
+#define HSMC_DBW_16_BITS			1
+#define HSMC_DBW_32_BITS			2
+
+/* Bit manipulation macros */
+#define HSMC_BIT(name)							\
+	(1 << HSMC_##name##_OFFSET)
+#define HSMC_BF(name,value)						\
+	(((value) & ((1 << HSMC_##name##_SIZE) - 1))			\
+	 << HSMC_##name##_OFFSET)
+#define HSMC_BFEXT(name,value)						\
+	(((value) >> HSMC_##name##_OFFSET)				\
+	 & ((1 << HSMC_##name##_SIZE) - 1))
+#define HSMC_BFINS(name,value,old)					\
+	(((old) & ~(((1 << HSMC_##name##_SIZE) - 1)			\
+		    << HSMC_##name##_OFFSET)) | HSMC_BF(name,value))
+
+/* Register access macros */
+#define hsmc_readl(port,reg)						\
+	readl((port)->regs + HSMC_##reg)
+#define hsmc_writel(port,reg,value)					\
+	writel((value), (port)->regs + HSMC_##reg)
+
+#endif /* __ASM_AVR32_HSMC_H__ */
Index: linux-2.6.18-rc6-mm2/include/asm-avr32/arch-at32ap/smc.h
===================================================================
--- /dev/null	1970-01-01 00:00:00.000000000 +0000
+++ linux-2.6.18-rc6-mm2/include/asm-avr32/arch-at32ap/smc.h	2006-09-15 10:00:39.000000000 +0200
@@ -0,0 +1,60 @@
+/*
+ * Static Memory Controller for AT32 chips
+ *
+ * Copyright (C) 2006 Atmel Corporation
+ *
+ * Inspired by the OMAP2 General-Purpose Memory Controller interface
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+#ifndef __ARCH_AT32AP_SMC_H
+#define __ARCH_AT32AP_SMC_H
+
+/*
+ * All timing parameters are in nanoseconds.
+ */
+struct smc_config {
+	/* Delay from address valid to assertion of given strobe */
+	u16		ncs_read_setup;
+	u16		nrd_setup;
+	u16		ncs_write_setup;
+	u16		nwe_setup;
+
+	/* Pulse length of given strobe */
+	u16		ncs_read_pulse;
+	u16		nrd_pulse;
+	u16		ncs_write_pulse;
+	u16		nwe_pulse;
+
+	/* Total cycle length of given operation */
+	u16		read_cycle;
+	u16		write_cycle;
+
+	/* Bus width in bytes */
+	u8		bus_width;
+
+	/*
+	 * 0: Data is sampled on rising edge of NCS
+	 * 1: Data is sampled on rising edge of NRD
+	 */
+	unsigned int	nrd_controlled:1;
+
+	/*
+	 * 0: Data is driven on falling edge of NCS
+	 * 1: Data is driven on falling edge of NWR
+	 */
+	unsigned int	nwe_controlled:1;
+
+	/*
+	 * 0: Byte select access type
+	 * 1: Byte write access type
+	 */
+	unsigned int	byte_write:1;
+};
+
+extern int smc_set_configuration(int cs, const struct smc_config *config);
+extern struct smc_config *smc_get_configuration(int cs);
+
+#endif /* __ARCH_AT32AP_SMC_H */



From martinatgd at gmail.com  Wed Sep 27 17:18:17 2006
From: martinatgd at gmail.com (Martin Wedepohl)
Date: Wed, 27 Sep 2006 15:18:17 -0600
Subject: JFFS2 problem with filename length > 7
In-Reply-To: <1159337564.3309.91.camel@pmac.infradead.org>
References: <67f0a57c0609262213j56993210h654450841dcac92f@mail.gmail.com>
	<1159337564.3309.91.camel@pmac.infradead.org>
Message-ID: <67f0a57c0609271418q61d32478jff09b9a15d29e4be@mail.gmail.com>

On 9/27/06, David Woodhouse <dwmw2 at infradead.org> wrote:
> On Tue, 2006-09-26 at 23:13 -0600, Martin Wedepohl wrote:
> > bash-3.00# ls -al /mnt
> > ls: /mnt/8888: No such file or directory
> > ls: /mnt/9999: No such file or directory
> > ls: /mnt/aaaa: No such file or directory
>
> Weird. Please reproduce with CONFIG_JFFS2_FS_DEBUG=1 and show the
> (KERN_DEBUG) messages -- preferably by capturing them (without loss)
> over a serial port. Please also take a snapshot of the offending image
> from the flash.
>
> I suspect a hardware driver or wiring problem.
>
> --
> dwmw2
>
>

Attached is the dmesg (jffs2_debug.txt) and the snapshot of the flash
sector (jffs2_flash.txt).  Hope that is acceptable etiquette.

Martin
-------------- next part --------------
dmesg
Linux version 2.6.17-g4e21eb5f-dirty (wedepohl at kweeds) (gcc version 4.0.0 (DENX ELDK 4.0 4.0.0)) #9 PREEMPT Wed Sep 27 10:
38:30 MDT 2006
On node 0 totalpages: 65536
  DMA zone: 65536 pages, LIFO batch:15
Built 1 zonelists
Kernel command line: console=ttyPSC3,115200n8 root=/dev/nfs rw nfsroot=192.168.100.60:/opt/eldk/ppc_6xx ip=::::::dhcp pani
c=5
PID hash table entries: 2048 (order: 11, 8192 bytes)
Dentry cache hash table entries: 32768 (order: 5, 131072 bytes)
Inode-cache hash table entries: 16384 (order: 4, 65536 bytes)
Memory: 257152k available (1868k kernel code, 728k data, 104k init, 0k highmem)
Calibrating delay loop... 263.16 BogoMIPS (lpj=526336)
Mount-cache hash table entries: 512
NET: Registered protocol family 16
DMA: MPC52xx BestComm driver
MPC52xx BestComm inited
Generic PHY: Registered new driver
NET: Registered protocol family 2
IP route cache hash table entries: 2048 (order: 1, 8192 bytes)
TCP established hash table entries: 8192 (order: 5, 131072 bytes)
TCP bind hash table entries: 4096 (order: 4, 81920 bytes)
TCP: Hash tables configured (established 8192 bind 4096)
TCP reno registered
Thermal assist unit not available
JFFS2 version 2.2. (NAND) (C) 2001-2003 Red Hat, Inc.
Allocated 267964 bytes for deflate workspace
Allocated 46912 bytes for inflate workspace
Registering JFFS2 compressor "zlib"
Registering JFFS2 compressor "rtime"
JFFS2: default compression mode: priority
io scheduler noop registered
io scheduler anticipatory registered (default)
io scheduler deadline registered
io scheduler cfq registered
Serial: MPC52xx PSC driver
ttyPSC3 at MMIO 0xf0002600 (irq = 50) is a MPC52xx PSC
ttyPSC4 at MMIO 0xf0002800 (irq = 51) is a MPC52xx PSC
RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize
loop: loaded (max 8 devices)
Marvell 88E1101: Registered new driver
M88E6095: Registered new driver
eth0: Phy @ 0x0, type GENERIC (0x00000000)
Main Flash: Found 1 x16 devices at 0x0 in 16-bit bank
 Amd/Fujitsu Extended Query Table at 0x0040
Main Flash: CFI does not contain boot bank location. Assuming top.
number of CFI chips: 1
cfi_cmdset_0002: Disabling erase-suspend-program due to code brokenness.
LES5200: Flash at 0xfc000000
Creating 10 MTD partitions on "Main Flash":
0x00000000-0x00080000 : "fpga"
0x00080000-0x000c0000 : "cpld"
0x000c0000-0x00140000 : "vap"
0x00140000-0x00160000 : "fps"
0x00160000-0x00180000 : "fps_test"
0x00180000-0x00300000 : "kernel"
0x00300000-0x03d00000 : "filesys"
0x03d00000-0x03f00000 : "config"
0x03f00000-0x03fe0000 : "uboot"
0x03fe0000-0x04000000 : "env"
Backup Flash: Found 1 x16 devices at 0x0 in 16-bit bank
 Amd/Fujitsu Extended Query Table at 0x0040
Backup Flash: CFI does not contain boot bank location. Assuming top.
number of CFI chips: 1
cfi_cmdset_0002: Disabling erase-suspend-program due to code brokenness.
LES5200: Flash at 0xf8000000
Creating 1 MTD partitions on "Backup Flash":
0x00000000-0x04000000 : "backup_flash"
ip_conntrack version 2.4 (2048 buckets, 16384 max) - 204 bytes per conntrack
ip_tables: (C) 2000-2006 Netfilter Core Team
TCP bic registered
Initializing IPsec netlink socket
NET: Registered protocol family 1
NET: Registered protocol family 17
NET: Registered protocol family 15
eth0: config: auto-negotiation off, No speed/duplex selected?.
Sending DHCP requests ., OK
IP-Config: Got DHCP answer from 0.0.0.0, my address is 192.168.100.106
IP-Config: Complete:
      device=eth0, addr=192.168.100.106, mask=255.255.255.0, gw=192.168.100.1,
     host=les006.fw.gdcanada.com, domain=fw.gdcanada.com, nis-domain=(none),
     bootserver=0.0.0.0, rootserver=192.168.100.60, rootpath=
Looking up port of RPC 100003/2 on 192.168.100.60
Looking up port of RPC 100005/1 on 192.168.100.60
VFS: Mounted root (nfs filesystem).
Freeing unused kernel memory: 104k init
jffs2_get_sb(): dev_name "/dev/mtdblock7"
jffs2_get_sb(): path_lookup() returned 0, inode cf0c7440
jffs2_get_sb_mtd(): New superblock for device 7 ("config")
[JFFS2 DBG] (876) jffs2_build_filesystem: build FS data structures
Allocating readbuf of 4096 bytes
jffs2_scan_eraseblock(): Scanning block at 0x0
[JFFS2 DBG] (876) jffs2_scan_eraseblock: no summary found in jeb 0x00000000. Apply original scan.
CLEANMARKER node found at 0x00000000
Found empty flash at 0x00000010
Empty flash to end of buffer at 0x00000400
1024 bytes at start of block seems clean... assuming all clean
jffs2_scan_eraseblock(): Scanning block at 0x20000
[JFFS2 DBG] (876) jffs2_scan_eraseblock: no summary found in jeb 0x00020000. Apply original scan.
CLEANMARKER node found at 0x00020000
Found empty flash at 0x00020010
Empty flash to end of buffer at 0x00020400
1024 bytes at start of block seems clean... assuming all clean
jffs2_scan_eraseblock(): Scanning block at 0x40000
[JFFS2 DBG] (876) jffs2_scan_eraseblock: no summary found in jeb 0x00040000. Apply original scan.
CLEANMARKER node found at 0x00040000
Found empty flash at 0x00040010
Empty flash to end of buffer at 0x00040400
1024 bytes at start of block seems clean... assuming all clean
jffs2_scan_eraseblock(): Scanning block at 0x60000
[JFFS2 DBG] (876) jffs2_scan_eraseblock: no summary found in jeb 0x00060000. Apply original scan.
CLEANMARKER node found at 0x00060000
Found empty flash at 0x00060010
Empty flash to end of buffer at 0x00060400
1024 bytes at start of block seems clean... assuming all clean
jffs2_scan_eraseblock(): Scanning block at 0x80000
[JFFS2 DBG] (876) jffs2_scan_eraseblock: no summary found in jeb 0x00080000. Apply original scan.
CLEANMARKER node found at 0x00080000
Found empty flash at 0x00080010
Empty flash to end of buffer at 0x00080400
1024 bytes at start of block seems clean... assuming all clean
jffs2_scan_eraseblock(): Scanning block at 0xa0000
[JFFS2 DBG] (876) jffs2_scan_eraseblock: no summary found in jeb 0x000a0000. Apply original scan.
CLEANMARKER node found at 0x000a0000
Found empty flash at 0x000a0010
Empty flash to end of buffer at 0x000a0400
1024 bytes at start of block seems clean... assuming all clean
jffs2_scan_eraseblock(): Scanning block at 0xc0000
[JFFS2 DBG] (876) jffs2_scan_eraseblock: no summary found in jeb 0x000c0000. Apply original scan.
CLEANMARKER node found at 0x000c0000
Found empty flash at 0x000c0010
Empty flash to end of buffer at 0x000c0400
1024 bytes at start of block seems clean... assuming all clean
jffs2_scan_eraseblock(): Scanning block at 0xe0000
[JFFS2 DBG] (876) jffs2_scan_eraseblock: no summary found in jeb 0x000e0000. Apply original scan.
CLEANMARKER node found at 0x000e0000
Found empty flash at 0x000e0010
Empty flash to end of buffer at 0x000e0400
1024 bytes at start of block seems clean... assuming all clean
jffs2_scan_eraseblock(): Scanning block at 0x100000
[JFFS2 DBG] (876) jffs2_scan_eraseblock: no summary found in jeb 0x00100000. Apply original scan.
CLEANMARKER node found at 0x00100000
Found empty flash at 0x00100010
Empty flash to end of buffer at 0x00100400
1024 bytes at start of block seems clean... assuming all clean
jffs2_scan_eraseblock(): Scanning block at 0x120000
[JFFS2 DBG] (876) jffs2_scan_eraseblock: no summary found in jeb 0x00120000. Apply original scan.
CLEANMARKER node found at 0x00120000
Found empty flash at 0x00120010
Empty flash to end of buffer at 0x00120400
1024 bytes at start of block seems clean... assuming all clean
jffs2_scan_eraseblock(): Scanning block at 0x140000
[JFFS2 DBG] (876) jffs2_scan_eraseblock: no summary found in jeb 0x00140000. Apply original scan.
CLEANMARKER node found at 0x00140000
Found empty flash at 0x00140010
Empty flash to end of buffer at 0x00140400
1024 bytes at start of block seems clean... assuming all clean
jffs2_scan_eraseblock(): Scanning block at 0x160000
[JFFS2 DBG] (876) jffs2_scan_eraseblock: no summary found in jeb 0x00160000. Apply original scan.
CLEANMARKER node found at 0x00160000
Found empty flash at 0x00160010
Empty flash to end of buffer at 0x00160400
1024 bytes at start of block seems clean... assuming all clean
jffs2_scan_eraseblock(): Scanning block at 0x180000
[JFFS2 DBG] (876) jffs2_scan_eraseblock: no summary found in jeb 0x00180000. Apply original scan.
CLEANMARKER node found at 0x00180000
Found empty flash at 0x00180010
Empty flash to end of buffer at 0x00180400
1024 bytes at start of block seems clean... assuming all clean
jffs2_scan_eraseblock(): Scanning block at 0x1a0000
[JFFS2 DBG] (876) jffs2_scan_eraseblock: no summary found in jeb 0x001a0000. Apply original scan.
CLEANMARKER node found at 0x001a0000
Found empty flash at 0x001a0010
Empty flash to end of buffer at 0x001a0400
1024 bytes at start of block seems clean... assuming all clean
jffs2_scan_eraseblock(): Scanning block at 0x1c0000
[JFFS2 DBG] (876) jffs2_scan_eraseblock: no summary found in jeb 0x001c0000. Apply original scan.
jffs2_scan_dirent_node(): Node at 0x001c0050
[JFFS2 DBG] (876) jffs2_add_ino_cache: add cf07f3c8 (ino #1)
[JFFS2 DBG] (876) jffs2_add_fd_to_list: add dirent "1", ino #2
jffs2_scan_inode_node(): Node at 0x001c007c
[JFFS2 DBG] (876) jffs2_add_ino_cache: add cf07f3b0 (ino #2)
Node is ino #2, version 2. Range 0x0-0x0
jffs2_scan_dirent_node(): Node at 0x001c0104
[JFFS2 DBG] (876) jffs2_add_fd_to_list: add dirent "22", ino #3
jffs2_scan_inode_node(): Node at 0x001c0130
[JFFS2 DBG] (876) jffs2_add_ino_cache: add cf07f398 (ino #3)
Node is ino #3, version 2. Range 0x0-0x0
jffs2_scan_dirent_node(): Node at 0x001c01b8
[JFFS2 DBG] (876) jffs2_add_fd_to_list: add dirent "333", ino #4
jffs2_scan_inode_node(): Node at 0x001c01e4
[JFFS2 DBG] (876) jffs2_add_ino_cache: add cf07f380 (ino #4)
Node is ino #4, version 2. Range 0x0-0x0
jffs2_scan_dirent_node(): Node at 0x001c026c
[JFFS2 DBG] (876) jffs2_add_fd_to_list: add dirent "4444", ino #5
jffs2_scan_inode_node(): Node at 0x001c0298
[JFFS2 DBG] (876) jffs2_add_ino_cache: add cf07f368 (ino #5)
Node is ino #5, version 2. Range 0x0-0x0
jffs2_scan_dirent_node(): Node at 0x001c0320
[JFFS2 DBG] (876) jffs2_add_fd_to_list: add dirent "55555", ino #6
jffs2_scan_inode_node(): Node at 0x001c0350
[JFFS2 DBG] (876) jffs2_add_ino_cache: add cf07f350 (ino #6)
Node is ino #6, version 2. Range 0x0-0x0
Fewer than 46 bytes (dirent node) left to end of buf. Reading 0x1000 at 0x001c03d8
jffs2_scan_dirent_node(): Node at 0x001c03d8
[JFFS2 DBG] (876) jffs2_add_fd_to_list: add dirent "666666", ino #7
jffs2_scan_inode_node(): Node at 0x001c0408
[JFFS2 DBG] (876) jffs2_add_ino_cache: add cf07f338 (ino #7)
Node is ino #7, version 2. Range 0x0-0x0
jffs2_scan_dirent_node(): Node at 0x001c0490
[JFFS2 DBG] (876) jffs2_add_fd_to_list: add dirent "7777777", ino #8
jffs2_scan_inode_node(): Node at 0x001c04c0
[JFFS2 DBG] (876) jffs2_add_ino_cache: add cf07f320 (ino #8)
Node is ino #8, version 2. Range 0x0-0x0
jffs2_scan_dirent_node(): Node at 0x001c0548
[JFFS2 DBG] (876) jffs2_add_fd_to_list: add dirent "88888888", ino #9
jffs2_scan_inode_node(): Node at 0x001c0578
[JFFS2 DBG] (876) jffs2_add_ino_cache: add cf07f308 (ino #9)
Node is ino #9, version 2. Range 0x0-0x0
jffs2_scan_dirent_node(): Node at 0x001c0600
[JFFS2 DBG] (876) jffs2_add_fd_to_list: add dirent "999999999", ino #10
jffs2_scan_inode_node(): Node at 0x001c0634
[JFFS2 DBG] (876) jffs2_add_ino_cache: add cf07f2f0 (ino #10)
Node is ino #10, version 2. Range 0x0-0x0
jffs2_scan_dirent_node(): Node at 0x001c06bc
[JFFS2 DBG] (876) jffs2_add_fd_to_list: add dirent "aaaaaaaaaa", ino #11
jffs2_scan_inode_node(): Node at 0x001c06f0
[JFFS2 DBG] (876) jffs2_add_ino_cache: add cf07f2d8 (ino #11)
Node is ino #11, version 2. Range 0x0-0x0
Found empty flash at 0x001c0738
Empty flash to end of buffer at 0x001c13d8
Reading another 0x1000 at 0x001c13d8
Empty flash to end of buffer at 0x001c23d8
Reading another 0x1000 at 0x001c23d8
Empty flash to end of buffer at 0x001c33d8
Reading another 0x1000 at 0x001c33d8
Empty flash to end of buffer at 0x001c43d8
Reading another 0x1000 at 0x001c43d8
Empty flash to end of buffer at 0x001c53d8
Reading another 0x1000 at 0x001c53d8
Empty flash to end of buffer at 0x001c63d8
Reading another 0x1000 at 0x001c63d8
Empty flash to end of buffer at 0x001c73d8
Reading another 0x1000 at 0x001c73d8
Empty flash to end of buffer at 0x001c83d8
Reading another 0x1000 at 0x001c83d8
Empty flash to end of buffer at 0x001c93d8
Reading another 0x1000 at 0x001c93d8
Empty flash to end of buffer at 0x001ca3d8
Reading another 0x1000 at 0x001ca3d8
Empty flash to end of buffer at 0x001cb3d8
Reading another 0x1000 at 0x001cb3d8
Empty flash to end of buffer at 0x001cc3d8
Reading another 0x1000 at 0x001cc3d8
Empty flash to end of buffer at 0x001cd3d8
Reading another 0x1000 at 0x001cd3d8
Empty flash to end of buffer at 0x001ce3d8
Reading another 0x1000 at 0x001ce3d8
Empty flash to end of buffer at 0x001cf3d8
Reading another 0x1000 at 0x001cf3d8
Empty flash to end of buffer at 0x001d03d8
Reading another 0x1000 at 0x001d03d8
Empty flash to end of buffer at 0x001d13d8
Reading another 0x1000 at 0x001d13d8
Empty flash to end of buffer at 0x001d23d8
Reading another 0x1000 at 0x001d23d8
Empty flash to end of buffer at 0x001d33d8
Reading another 0x1000 at 0x001d33d8
Empty flash to end of buffer at 0x001d43d8
Reading another 0x1000 at 0x001d43d8
Empty flash to end of buffer at 0x001d53d8
Reading another 0x1000 at 0x001d53d8
Empty flash to end of buffer at 0x001d63d8
Reading another 0x1000 at 0x001d63d8
Empty flash to end of buffer at 0x001d73d8
Reading another 0x1000 at 0x001d73d8
Empty flash to end of buffer at 0x001d83d8
Reading another 0x1000 at 0x001d83d8
Empty flash to end of buffer at 0x001d93d8
Reading another 0x1000 at 0x001d93d8
Empty flash to end of buffer at 0x001da3d8
Reading another 0x1000 at 0x001da3d8
Empty flash to end of buffer at 0x001db3d8
Reading another 0x1000 at 0x001db3d8
Empty flash to end of buffer at 0x001dc3d8
Reading another 0x1000 at 0x001dc3d8
Empty flash to end of buffer at 0x001dd3d8
Reading another 0x1000 at 0x001dd3d8
Empty flash to end of buffer at 0x001de3d8
Reading another 0x1000 at 0x001de3d8
Empty flash to end of buffer at 0x001df3d8
Reading another 0xc28 at 0x001df3d8
Empty flash to end of buffer at 0x001e0000
Empty flash at 001c0734 runs to end of block. Treating as free_space
Block at 0x001c0000: free 0x0001f8cc, dirty 0x000002b4, unchecked 0x000002a8, used 0x000001d8
jffs2_scan_medium(): new nextblock = 0x001c0000
jffs2_scan_eraseblock(): Scanning block at 0x1e0000
[JFFS2 DBG] (876) jffs2_scan_eraseblock: no summary found in jeb 0x001e0000. Apply original scan.
CLEANMARKER node found at 0x001e0000
Found empty flash at 0x001e0010
Empty flash to end of buffer at 0x001e0400
1024 bytes at start of block seems clean... assuming all clean
[JFFS2 DBG] (876) jffs2_build_filesystem: scanned flash completely
[JFFS2 DBG] dump JFFS2 blocks lists:
flash_size: 0x200000
used_size: 0x00028c
dirty_size: 0x000000
wasted_size: 0x0002b4
unchecked_size: 0x0002a8
free_size: 0x1ff818
erasing_size: 0x000000
bad_size: 0x000000
sector_size: 0x020000
jffs2_reserved_blocks size: 0x000000
nextblock: 0x1c0000 (used 0x0001d8, dirty 0x000000, wasted 0x0002b4, unchecked 0x0002a8, free 0x01f8cc)
gcblock: NULL
clean_list: empty
very_dirty_list: empty
dirty_list: empty
erasable_list: empty
erasing_list: empty
erase_pending_list: empty
erasable_pending_wbuf_list: empty
free_list: 0x1e0000 (used 0x00000c, dirty 0x000000, wasted 0x000000, unchecked 0x000000, free 0x01fff4)
free_list: 0x1a0000 (used 0x00000c, dirty 0x000000, wasted 0x000000, unchecked 0x000000, free 0x01fff4)
free_list: 0x180000 (used 0x00000c, dirty 0x000000, wasted 0x000000, unchecked 0x000000, free 0x01fff4)
free_list: 0x160000 (used 0x00000c, dirty 0x000000, wasted 0x000000, unchecked 0x000000, free 0x01fff4)
free_list: 0x140000 (used 0x00000c, dirty 0x000000, wasted 0x000000, unchecked 0x000000, free 0x01fff4)
free_list: 0x120000 (used 0x00000c, dirty 0x000000, wasted 0x000000, unchecked 0x000000, free 0x01fff4)
free_list: 0x100000 (used 0x00000c, dirty 0x000000, wasted 0x000000, unchecked 0x000000, free 0x01fff4)
free_list: 0x0e0000 (used 0x00000c, dirty 0x000000, wasted 0x000000, unchecked 0x000000, free 0x01fff4)
free_list: 0x0c0000 (used 0x00000c, dirty 0x000000, wasted 0x000000, unchecked 0x000000, free 0x01fff4)
free_list: 0x0a0000 (used 0x00000c, dirty 0x000000, wasted 0x000000, unchecked 0x000000, free 0x01fff4)
free_list: 0x080000 (used 0x00000c, dirty 0x000000, wasted 0x000000, unchecked 0x000000, free 0x01fff4)
free_list: 0x060000 (used 0x00000c, dirty 0x000000, wasted 0x000000, unchecked 0x000000, free 0x01fff4)
free_list: 0x040000 (used 0x00000c, dirty 0x000000, wasted 0x000000, unchecked 0x000000, free 0x01fff4)
free_list: 0x020000 (used 0x00000c, dirty 0x000000, wasted 0x000000, unchecked 0x000000, free 0x01fff4)
free_list: 0x000000 (used 0x00000c, dirty 0x000000, wasted 0x000000, unchecked 0x000000, free 0x01fff4)
bad_list: empty
bad_used_list: empty
[JFFS2 DBG] (876) jffs2_build_filesystem: pass 1 starting
[JFFS2 DBG] (876) jffs2_build_inode_pass1: building directory inode #1
[JFFS2 DBG] (876) jffs2_build_inode_pass1: increased nlink for child "1" (ino #2)
[JFFS2 DBG] (876) jffs2_build_inode_pass1: increased nlink for child "22" (ino #3)
[JFFS2 DBG] (876) jffs2_build_inode_pass1: increased nlink for child "333" (ino #4)
[JFFS2 DBG] (876) jffs2_build_inode_pass1: increased nlink for child "4444" (ino #5)
[JFFS2 DBG] (876) jffs2_build_inode_pass1: increased nlink for child "55555" (ino #6)
[JFFS2 DBG] (876) jffs2_build_inode_pass1: increased nlink for child "88888888" (ino #9)
[JFFS2 DBG] (876) jffs2_build_inode_pass1: increased nlink for child "666666" (ino #7)
[JFFS2 DBG] (876) jffs2_build_inode_pass1: increased nlink for child "7777777" (ino #8)
[JFFS2 DBG] (876) jffs2_build_inode_pass1: increased nlink for child "999999999" (ino #10)
[JFFS2 DBG] (876) jffs2_build_inode_pass1: increased nlink for child "aaaaaaaaaa" (ino #11)
[JFFS2 DBG] (876) jffs2_build_filesystem: pass 1 complete
[JFFS2 DBG] (876) jffs2_build_filesystem: pass 2 starting
[JFFS2 DBG] (876) jffs2_build_filesystem: pass 2a starting
[JFFS2 DBG] (876) jffs2_build_filesystem: pass 2a complete
[JFFS2 DBG] (876) jffs2_build_filesystem: freeing temporary data structures
[JFFS2 DBG] (876) jffs2_build_filesystem: FS build complete
[JFFS2 DBG] (876) jffs2_calc_trigger_levels: JFFS2 trigger levels (size 2048 KiB, block size 128 KiB, 16 blocks)
[JFFS2 DBG] (876) jffs2_calc_trigger_levels: Blocks required to allow deletion:    2 (256 KiB)
[JFFS2 DBG] (876) jffs2_calc_trigger_levels: Blocks required to allow writes:      3 (384 KiB)
[JFFS2 DBG] (876) jffs2_calc_trigger_levels: Blocks required to quiesce GC thread: 4 (512 KiB)
[JFFS2 DBG] (876) jffs2_calc_trigger_levels: Blocks required to allow GC merges:   3 (384 KiB)
[JFFS2 DBG] (876) jffs2_calc_trigger_levels: Blocks required to GC bad blocks:     0 (0 KiB)
[JFFS2 DBG] (876) jffs2_calc_trigger_levels: Amount of dirty space required to GC: 152043 bytes
jffs2_do_fill_super(): Getting root inode
jffs2_read_inode(): inode->i_ino == 1
[JFFS2 DBG] (876) jffs2_do_read_inode: read inode #1
[JFFS2 DBG] (876) jffs2_do_read_inode_internal: ino #1 nlink is 1
[JFFS2 DBG] (876) jffs2_get_inode_nodes: ino #1
[JFFS2 DBG] (876) jffs2_get_inode_nodes: read 40 bytes at 0x1c06bc(2).
[JFFS2 DBG] (876) jffs2_add_fd_to_list: add dirent "aaaa", ino #11
[JFFS2 DBG] (876) jffs2_get_inode_nodes: read 40 bytes at 0x1c0600(2).
[JFFS2 DBG] (876) jffs2_add_fd_to_list: add dirent "9999", ino #10
[JFFS2 DBG] (876) jffs2_get_inode_nodes: read 40 bytes at 0x1c0548(2).
[JFFS2 DBG] (876) jffs2_add_fd_to_list: add dirent "8888", ino #9
[JFFS2 DBG] (876) jffs2_get_inode_nodes: read 40 bytes at 0x1c0490(2).
[JFFS2 DBG] (876) jffs2_add_fd_to_list: add dirent "7777777", ino #8
[JFFS2 DBG] (876) jffs2_get_inode_nodes: read 40 bytes at 0x1c03d8(2).
[JFFS2 DBG] (876) jffs2_add_fd_to_list: add dirent "666666", ino #7
[JFFS2 DBG] (876) jffs2_get_inode_nodes: read 40 bytes at 0x1c0320(2).
[JFFS2 DBG] (876) jffs2_add_fd_to_list: add dirent "55555", ino #6
[JFFS2 DBG] (876) jffs2_get_inode_nodes: read 40 bytes at 0x1c026c(2).
[JFFS2 DBG] (876) jffs2_add_fd_to_list: add dirent "4444", ino #5
[JFFS2 DBG] (876) jffs2_get_inode_nodes: read 40 bytes at 0x1c01b8(2).
[JFFS2 DBG] (876) jffs2_add_fd_to_list: add dirent "333", ino #4
[JFFS2 DBG] (876) jffs2_get_inode_nodes: read 40 bytes at 0x1c0104(2).
[JFFS2 DBG] (876) jffs2_add_fd_to_list: add dirent "22", ino #3
[JFFS2 DBG] (876) jffs2_get_inode_nodes: read 40 bytes at 0x1c0050(2).
[JFFS2 DBG] (876) jffs2_add_fd_to_list: add dirent "1", ino #2
[JFFS2 DBG] (876) jffs2_get_inode_nodes: nodes of inode #1 were read, the highest version is 10, latest_mctime 117, mctime
_ver 10.
jffs2_read_inode() returning
jffs2_do_fill_super(): d_alloc_root()
JFFS2: Garbage collect thread is pid 877
jffs2_thread_should_wake(): unchecked_size 680, checked_ino #0
jffs2_garbage_collect_thread(): pass
Skipping ino #1 already checked
jffs2_garbage_collect_pass() triggering inode scan of ino#2
[JFFS2 DBG] (877) jffs2_do_read_inode_internal: ino #2 nlink is 1
[JFFS2 DBG] (877) jffs2_get_inode_nodes: ino #2
[JFFS2 DBG] (877) jffs2_get_inode_nodes: read 40 bytes at 0x1c007c(0).
[JFFS2 DBG] (877) read_more: read more 28 bytes
[JFFS2 DBG] (877) read_dnode: the node has no data.
[JFFS2 DBG] (877) read_dnode: dnode @001c007c: ver 2, offset 0x00, dsize 0x00, csize 0x00
[JFFS2 DBG] (877) jffs2_get_inode_nodes: nodes of inode #2 were read, the highest version is 2, latest_mctime 0, mctime_ve
r 0.
[JFFS2 DBG] (877) jffs2_do_read_inode_internal: consider node ver 2, phys offset 0x1c007c(3), range 0-0.
[JFFS2 DBG] (877) jffs2_truncate_fragtree: truncating fragtree to 0x00000000 bytes
jffs2_thread_should_wake(): unchecked_size 612, checked_ino #3
jffs2_garbage_collect_thread(): pass
jffs2_garbage_collect_pass() triggering inode scan of ino#3
[JFFS2 DBG] (877) jffs2_do_read_inode_internal: ino #3 nlink is 1
[JFFS2 DBG] (877) jffs2_get_inode_nodes: ino #3
[JFFS2 DBG] (877) jffs2_get_inode_nodes: read 40 bytes at 0x1c0130(0).
[JFFS2 DBG] (877) read_more: read more 28 bytes
[JFFS2 DBG] (877) read_dnode: the node has no data.
[JFFS2 DBG] (877) read_dnode: dnode @001c0130: ver 2, offset 0x00, dsize 0x00, csize 0x00
[JFFS2 DBG] (877) jffs2_get_inode_nodes: nodes of inode #3 were read, the highest version is 2, latest_mctime 0, mctime_ve
r 0.
[JFFS2 DBG] (877) jffs2_do_read_inode_internal: consider node ver 2, phys offset 0x1c0130(3), range 0-0.
[JFFS2 DBG] (877) jffs2_truncate_fragtree: truncating fragtree to 0x00000000 bytes
jffs2_thread_should_wake(): unchecked_size 544, checked_ino #4
jffs2_garbage_collect_thread(): pass
jffs2_garbage_collect_pass() triggering inode scan of ino#4
[JFFS2 DBG] (877) jffs2_do_read_inode_internal: ino #4 nlink is 1
[JFFS2 DBG] (877) jffs2_get_inode_nodes: ino #4
[JFFS2 DBG] (877) jffs2_get_inode_nodes: read 40 bytes at 0x1c01e4(0).
[JFFS2 DBG] (877) read_more: read more 28 bytes
[JFFS2 DBG] (877) read_dnode: the node has no data.
[JFFS2 DBG] (877) read_dnode: dnode @001c01e4: ver 2, offset 0x00, dsize 0x00, csize 0x00
[JFFS2 DBG] (877) jffs2_get_inode_nodes: nodes of inode #4 were read, the highest version is 2, latest_mctime 0, mctime_ve
r 0.
[JFFS2 DBG] (877) jffs2_do_read_inode_internal: consider node ver 2, phys offset 0x1c01e4(3), range 0-0.
[JFFS2 DBG] (877) jffs2_truncate_fragtree: truncating fragtree to 0x00000000 bytes
jffs2_thread_should_wake(): unchecked_size 476, checked_ino #5
jffs2_garbage_collect_thread(): pass
jffs2_garbage_collect_pass() triggering inode scan of ino#5
[JFFS2 DBG] (877) jffs2_do_read_inode_internal: ino #5 nlink is 1
[JFFS2 DBG] (877) jffs2_get_inode_nodes: ino #5
[JFFS2 DBG] (877) jffs2_get_inode_nodes: read 40 bytes at 0x1c0298(0).
[JFFS2 DBG] (877) read_more: read more 28 bytes
[JFFS2 DBG] (877) read_dnode: the node has no data.
[JFFS2 DBG] (877) read_dnode: dnode @001c0298: ver 2, offset 0x00, dsize 0x00, csize 0x00
[JFFS2 DBG] (877) jffs2_get_inode_nodes: nodes of inode #5 were read, the highest version is 2, latest_mctime 0, mctime_ve
r 0.
[JFFS2 DBG] (877) jffs2_do_read_inode_internal: consider node ver 2, phys offset 0x1c0298(3), range 0-0.
[JFFS2 DBG] (877) jffs2_truncate_fragtree: truncating fragtree to 0x00000000 bytes
jffs2_thread_should_wake(): unchecked_size 408, checked_ino #6
jffs2_garbage_collect_thread(): pass
jffs2_garbage_collect_pass() triggering inode scan of ino#6
[JFFS2 DBG] (877) jffs2_do_read_inode_internal: ino #6 nlink is 1
[JFFS2 DBG] (877) jffs2_get_inode_nodes: ino #6
[JFFS2 DBG] (877) jffs2_get_inode_nodes: read 40 bytes at 0x1c0350(0).
[JFFS2 DBG] (877) read_more: read more 28 bytes
[JFFS2 DBG] (877) read_dnode: the node has no data.
[JFFS2 DBG] (877) read_dnode: dnode @001c0350: ver 2, offset 0x00, dsize 0x00, csize 0x00
[JFFS2 DBG] (877) jffs2_get_inode_nodes: nodes of inode #6 were read, the highest version is 2, latest_mctime 0, mctime_ve
r 0.
[JFFS2 DBG] (877) jffs2_do_read_inode_internal: consider node ver 2, phys offset 0x1c0350(3), range 0-0.
[JFFS2 DBG] (877) jffs2_truncate_fragtree: truncating fragtree to 0x00000000 bytes
jffs2_thread_should_wake(): unchecked_size 340, checked_ino #7
jffs2_garbage_collect_thread(): pass
jffs2_garbage_collect_pass() triggering inode scan of ino#7
[JFFS2 DBG] (877) jffs2_do_read_inode_internal: ino #7 nlink is 1
[JFFS2 DBG] (877) jffs2_get_inode_nodes: ino #7
[JFFS2 DBG] (877) jffs2_get_inode_nodes: read 40 bytes at 0x1c0408(0).
[JFFS2 DBG] (877) read_more: read more 28 bytes
[JFFS2 DBG] (877) read_dnode: the node has no data.
[JFFS2 DBG] (877) read_dnode: dnode @001c0408: ver 2, offset 0x00, dsize 0x00, csize 0x00
[JFFS2 DBG] (877) jffs2_get_inode_nodes: nodes of inode #7 were read, the highest version is 2, latest_mctime 0, mctime_ve
r 0.
[JFFS2 DBG] (877) jffs2_do_read_inode_internal: consider node ver 2, phys offset 0x1c0408(3), range 0-0.
[JFFS2 DBG] (877) jffs2_truncate_fragtree: truncating fragtree to 0x00000000 bytes
jffs2_thread_should_wake(): unchecked_size 272, checked_ino #8
jffs2_garbage_collect_thread(): pass
jffs2_garbage_collect_pass() triggering inode scan of ino#8
[JFFS2 DBG] (877) jffs2_do_read_inode_internal: ino #8 nlink is 1
[JFFS2 DBG] (877) jffs2_get_inode_nodes: ino #8
[JFFS2 DBG] (877) jffs2_get_inode_nodes: read 40 bytes at 0x1c04c0(0).
[JFFS2 DBG] (877) read_more: read more 28 bytes
[JFFS2 DBG] (877) read_dnode: the node has no data.
[JFFS2 DBG] (877) read_dnode: dnode @001c04c0: ver 2, offset 0x00, dsize 0x00, csize 0x00
[JFFS2 DBG] (877) jffs2_get_inode_nodes: nodes of inode #8 were read, the highest version is 2, latest_mctime 0, mctime_ve
r 0.
[JFFS2 DBG] (877) jffs2_do_read_inode_internal: consider node ver 2, phys offset 0x1c04c0(3), range 0-0.
[JFFS2 DBG] (877) jffs2_truncate_fragtree: truncating fragtree to 0x00000000 bytes
jffs2_thread_should_wake(): unchecked_size 204, checked_ino #9
jffs2_garbage_collect_thread(): pass
jffs2_garbage_collect_pass() triggering inode scan of ino#9
[JFFS2 DBG] (877) jffs2_do_read_inode_internal: ino #9 nlink is 1
[JFFS2 DBG] (877) jffs2_get_inode_nodes: ino #9
[JFFS2 DBG] (877) jffs2_get_inode_nodes: read 40 bytes at 0x1c0578(0).
[JFFS2 DBG] (877) read_more: read more 28 bytes
[JFFS2 DBG] (877) read_dnode: the node has no data.
[JFFS2 DBG] (877) read_dnode: dnode @001c0578: ver 2, offset 0x00, dsize 0x00, csize 0x00
[JFFS2 DBG] (877) jffs2_get_inode_nodes: nodes of inode #9 were read, the highest version is 2, latest_mctime 0, mctime_ve
r 0.
[JFFS2 DBG] (877) jffs2_do_read_inode_internal: consider node ver 2, phys offset 0x1c0578(3), range 0-0.
[JFFS2 DBG] (877) jffs2_truncate_fragtree: truncating fragtree to 0x00000000 bytes
jffs2_thread_should_wake(): unchecked_size 136, checked_ino #10
jffs2_garbage_collect_thread(): pass
jffs2_garbage_collect_pass() triggering inode scan of ino#10
[JFFS2 DBG] (877) jffs2_do_read_inode_internal: ino #10 nlink is 1
[JFFS2 DBG] (877) jffs2_get_inode_nodes: ino #10
[JFFS2 DBG] (877) jffs2_get_inode_nodes: read 40 bytes at 0x1c0634(0).
[JFFS2 DBG] (877) read_more: read more 28 bytes
[JFFS2 DBG] (877) read_dnode: the node has no data.
[JFFS2 DBG] (877) read_dnode: dnode @001c0634: ver 2, offset 0x00, dsize 0x00, csize 0x00
[JFFS2 DBG] (877) jffs2_get_inode_nodes: nodes of inode #10 were read, the highest version is 2, latest_mctime 0, mctime_v
er 0.
[JFFS2 DBG] (877) jffs2_do_read_inode_internal: consider node ver 2, phys offset 0x1c0634(3), range 0-0.
[JFFS2 DBG] (877) jffs2_truncate_fragtree: truncating fragtree to 0x00000000 bytes
jffs2_thread_should_wake(): unchecked_size 68, checked_ino #11
jffs2_garbage_collect_thread(): pass
jffs2_garbage_collect_pass() triggering inode scan of ino#11
[JFFS2 DBG] (877) jffs2_do_read_inode_internal: ino #11 nlink is 1
[JFFS2 DBG] (877) jffs2_get_inode_nodes: ino #11
[JFFS2 DBG] (877) jffs2_get_inode_nodes: read 40 bytes at 0x1c06f0(0).
[JFFS2 DBG] (877) read_more: read more 28 bytes
[JFFS2 DBG] (877) read_dnode: the node has no data.
[JFFS2 DBG] (877) read_dnode: dnode @001c06f0: ver 2, offset 0x00, dsize 0x00, csize 0x00
[JFFS2 DBG] (877) jffs2_get_inode_nodes: nodes of inode #11 were read, the highest version is 2, latest_mctime 0, mctime_v
er 0.
[JFFS2 DBG] (877) jffs2_do_read_inode_internal: consider node ver 2, phys offset 0x1c06f0(3), range 0-0.
[JFFS2 DBG] (877) jffs2_truncate_fragtree: truncating fragtree to 0x00000000 bytes
jffs2_thread_should_wake(): nr_free_blocks 15, nr_erasing_blocks 0, dirty_size 0x0: no
jffs2_garbage_collect_thread sleeping...
bash-3.00# ttyPSC3 at MMIO 0xf0002600 (irq = 50) is a MPC52xx PSC
-------------- next part --------------
0000:0000 19 85 00 03 00 00 00 0c f0 60 dc 98 19 85 c0 02 00 00 00 44 a4 ef 22 3e 00 00 00 02 00 00 00 01 ........??`??...??....D????">........
0000:0020 00 00 81 a4 00 00 00 00 00 00 00 00 00 00 00 4b 00 00 00 4b 00 00 00 4b 00 00 00 00 00 00 00 00 ...??...........K...K...K........
0000:0040 00 00 00 00 00 00 00 00 00 00 00 00 88 d8 db 7a 19 85 e0 01 00 00 00 29 d0 4c 45 0b 00 00 00 01 .............????z..??....)??LE.....
0000:0060 00 00 00 01 00 00 00 02 00 00 00 4b 01 08 10 50 b4 05 61 0d 51 de 00 3a 31 ff ff ff 19 85 e0 02 ...........K...P??.a.Q??.:1??????..??.
0000:0080 00 00 00 44 a4 ef 22 3e 00 00 00 02 00 00 00 02 00 00 81 a4 00 00 00 00 00 00 00 00 00 00 00 50 ...D????">...........??...........P
0000:00a0 00 00 00 50 00 00 00 50 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 9d b3 7a 4c ...P...P.....................??zL
0000:00c0 19 85 c0 02 00 00 00 44 a4 ef 22 3e 00 00 00 03 00 00 00 01 00 00 81 a4 00 00 00 00 00 00 00 00 ..??....D????">...........??........
0000:00e0 00 00 00 52 00 00 00 52 00 00 00 52 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ...R...R...R....................
0000:0100 7d f2 52 45 19 85 e0 01 00 00 00 2a 49 45 14 b1 00 00 00 01 00 00 00 02 00 00 00 03 00 00 00 52 }??RE..??....*IE.??...............R
0000:0120 02 08 10 50 f5 14 20 28 25 a7 05 f1 32 32 ff ff 19 85 e0 02 00 00 00 44 a4 ef 22 3e 00 00 00 03 ...P??. (%??.??22????..??....D????">....
0000:0140 00 00 00 02 00 00 81 a4 00 00 00 00 00 00 00 00 00 00 00 52 00 00 00 52 00 00 00 52 00 00 00 00 .......??...........R...R...R....
0000:0160 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 9e bb e5 e7 19 85 c0 02 00 00 00 44 a4 ef 22 3e .................??????..??....D????">
0000:0180 00 00 00 04 00 00 00 01 00 00 81 a4 00 00 00 00 00 00 00 00 00 00 00 54 00 00 00 54 00 00 00 54 ...........??...........T...T...T
0000:01a0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 9b 20 59 4b 19 85 e0 01 00 00 00 2b ..................... YK..??....+
0000:01c0 3e 42 24 27 00 00 00 01 00 00 00 03 00 00 00 04 00 00 00 54 03 08 10 50 90 56 10 8f 6d 96 5f ef >B$'...............T...P.V..m._??
0000:01e0 33 33 33 ff 19 85 e0 02 00 00 00 44 a4 ef 22 3e 00 00 00 04 00 00 00 02 00 00 81 a4 00 00 00 00 333??..??....D????">...........??....
0000:0200 00 00 00 00 00 00 00 54 00 00 00 54 00 00 00 54 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 .......T...T...T................
0000:0220 00 00 00 00 78 69 ee e9 19 85 c0 02 00 00 00 44 a4 ef 22 3e 00 00 00 05 00 00 00 01 00 00 81 a4 ....xi????..??....D????">...........??
0000:0240 00 00 00 00 00 00 00 00 00 00 00 57 00 00 00 57 00 00 00 57 00 00 00 00 00 00 00 00 00 00 00 00 ...........W...W...W............
0000:0260 00 00 00 00 00 00 00 00 25 df 1e 33 19 85 e0 01 00 00 00 2c a0 26 b1 84 00 00 00 01 00 00 00 04 ........%??.3..??....,??&??.........
0000:0280 00 00 00 05 00 00 00 57 04 08 10 50 ca 1e 2a 01 c6 b5 25 f8 34 34 34 34 19 85 e0 02 00 00 00 44 .......W...P??.*.????%??4444..??....D
0000:02a0 a4 ef 22 3e 00 00 00 05 00 00 00 02 00 00 81 a4 00 00 00 00 00 00 00 00 00 00 00 57 00 00 00 57 ????">...........??...........W...W
0000:02c0 00 00 00 57 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 c6 96 a9 91 19 85 c0 02 ...W....................??.??...??.
0000:02e0 00 00 00 44 a4 ef 22 3e 00 00 00 06 00 00 00 01 00 00 81 a4 00 00 00 00 00 00 00 00 00 00 00 59 ...D????">...........??...........Y
0000:0300 00 00 00 59 00 00 00 59 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 cf 2f 6b 91 ...Y...Y....................??/k.
0000:0320 19 85 e0 01 00 00 00 2d d7 21 81 12 00 00 00 01 00 00 00 05 00 00 00 06 00 00 00 59 05 08 10 50 ..??....-??!.................Y...P
0000:0340 c2 c0 00 6b 78 16 1e 8b 35 35 35 35 35 ff ff ff 19 85 e0 02 00 00 00 44 a4 ef 22 3e 00 00 00 06 ????.kx...55555??????..??....D????">....
0000:0360 00 00 00 02 00 00 81 a4 00 00 00 00 00 00 00 00 00 00 00 59 00 00 00 59 00 00 00 59 00 00 00 00 .......??...........Y...Y...Y....
0000:0380 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 2c 66 dc 33 19 85 c0 02 00 00 00 44 a4 ef 22 3e ................,f??3..??....D????">
0000:03a0 00 00 00 07 00 00 00 01 00 00 81 a4 00 00 00 00 00 00 00 00 00 00 00 5e 00 00 00 5e 00 00 00 5e ...........??...........^...^...^
0000:03c0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 eb 9c 45 66 19 85 e0 01 00 00 00 2e ....................??.Ef..??.....
0000:03e0 4e 28 d0 a8 00 00 00 01 00 00 00 06 00 00 00 07 00 00 00 5e 06 08 10 50 5c 01 68 ad 4f 42 93 25 N(????...............^...P\.h??OB.%
0000:0400 36 36 36 36 36 36 ff ff 19 85 e0 02 00 00 00 44 a4 ef 22 3e 00 00 00 07 00 00 00 02 00 00 81 a4 666666????..??....D????">...........??
0000:0420 00 00 00 00 00 00 00 00 00 00 00 5e 00 00 00 5e 00 00 00 5e 00 00 00 00 00 00 00 00 00 00 00 00 ...........^...^...^............
0000:0440 00 00 00 00 00 00 00 00 08 d5 f2 c4 19 85 c0 02 00 00 00 44 a4 ef 22 3e 00 00 00 08 00 00 00 01 .........??????..??....D????">........
0000:0460 00 00 81 a4 00 00 00 00 00 00 00 00 00 00 00 63 00 00 00 63 00 00 00 63 00 00 00 00 00 00 00 00 ...??...........c...c...c........
0000:0480 00 00 00 00 00 00 00 00 00 00 00 00 ee cf 50 a5 19 85 e0 01 00 00 00 2f 39 2f e0 3e 00 00 00 01 ............????P??..??..../9/??>....
0000:04a0 00 00 00 07 00 00 00 08 00 00 00 63 07 08 10 50 54 6a 73 85 03 d8 fe 69 37 37 37 37 37 37 37 ff ...........c...PTjs..????i7777777??
0000:04c0 19 85 e0 02 00 00 00 44 a4 ef 22 3e 00 00 00 08 00 00 00 02 00 00 81 a4 00 00 00 00 00 00 00 00 ..??....D????">...........??........
0000:04e0 00 00 00 63 00 00 00 63 00 00 00 63 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ...c...c...c....................
0000:0500 0d 86 e7 07 19 85 c0 02 00 00 00 44 a4 ef 22 3e 00 00 00 09 00 00 00 01 00 00 81 a4 00 00 00 00 ..??...??....D????">...........??....
0000:0520 00 00 00 00 00 00 00 6a 00 00 00 6a 00 00 00 6a 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 .......j...j...j................
0000:0540 00 00 00 00 1f 47 75 65 19 85 e0 01 00 00 00 30 b4 27 ed cb 00 00 00 01 00 00 00 08 00 00 00 09 .....Gue..??....0??'????............
0000:0560 00 00 00 6a 08 08 00 00 b8 4e 0b 09 94 a6 b5 79 38 38 38 38 38 38 38 38 19 85 e0 02 00 00 00 44 ...j....??N...????y88888888..??....D
0000:0580 a4 ef 22 3e 00 00 00 09 00 00 00 02 00 00 81 a4 00 00 00 00 00 00 00 00 00 00 00 6a 00 00 00 6a ????">...........??...........j...j
0000:05a0 00 00 00 6a 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 fc 0e c2 c7 19 85 c0 02 ...j....................??.????..??.
0000:05c0 00 00 00 44 a4 ef 22 3e 00 00 00 0a 00 00 00 01 00 00 81 a4 00 00 00 00 00 00 00 00 00 00 00 6f ...D????">...........??...........o
0000:05e0 00 00 00 6f 00 00 00 6f 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 07 37 ba ac ...o...o.....................7????
0000:0600 19 85 e0 01 00 00 00 31 c3 20 dd 5d 00 00 00 01 00 00 00 09 00 00 00 0a 00 00 00 6f 09 08 00 00 ..??....1?? ??]...............o....
0000:0620 c7 40 10 72 5d b7 3e 4a 39 39 39 39 39 39 39 39 39 ff ff ff 19 85 e0 02 00 00 00 44 a4 ef 22 3e ??@.r]??>J999999999??????..??....D????">
0000:0640 00 00 00 0a 00 00 00 02 00 00 81 a4 00 00 00 00 00 00 00 00 00 00 00 6f 00 00 00 6f 00 00 00 6f ...........??...........o...o...o
0000:0660 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 e4 7e 0d 0e 19 85 c0 02 00 00 00 44 ....................??~....??....D
0000:0680 a4 ef 22 3e 00 00 00 0b 00 00 00 01 00 00 81 a4 00 00 00 00 00 00 00 00 00 00 00 75 00 00 00 75 ????">...........??...........u...u
0000:06a0 00 00 00 75 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ef 74 5c a7 19 85 e0 01 ...u....................??t\??..??.
0000:06c0 00 00 00 32 5a 29 8c e7 00 00 00 01 00 00 00 0a 00 00 00 0b 00 00 00 75 0a 08 00 00 c1 f1 2b 87 ...2Z).??...............u....????+.
0000:06e0 af 9b a5 86 61 61 61 61 61 61 61 61 61 61 ff ff 19 85 e0 02 00 00 00 44 a4 ef 22 3e 00 00 00 0b ??.??.aaaaaaaaaa????..??....D????">....
0000:0700 00 00 00 02 00 00 81 a4 00 00 00 00 00 00 00 00 00 00 00 75 00 00 00 75 00 00 00 75 00 00 00 00 .......??...........u...u...u....
0000:0720 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0c 3d eb 05 ff ff ff ff ff ff ff ff ff ff ff ff .................=??.????????????????????????
0000:0740                                                                                                                                 

From dwmw2 at infradead.org  Wed Sep 27 17:35:02 2006
From: dwmw2 at infradead.org (David Woodhouse)
Date: Wed, 27 Sep 2006 22:35:02 +0100
Subject: JFFS2 problem with filename length > 7
In-Reply-To: <67f0a57c0609271418q61d32478jff09b9a15d29e4be@mail.gmail.com>
References: <67f0a57c0609262213j56993210h654450841dcac92f@mail.gmail.com>
	<1159337564.3309.91.camel@pmac.infradead.org>
	<67f0a57c0609271418q61d32478jff09b9a15d29e4be@mail.gmail.com>
Message-ID: <1159392902.3309.159.camel@pmac.infradead.org>

Curiouser and curiouser. At this point...

> [JFFS2 DBG] (876) jffs2_build_inode_pass1: increased nlink for child "88888888" (ino #9)
> [JFFS2 DBG] (876) jffs2_build_inode_pass1: increased nlink for child "666666" (ino #7)
> [JFFS2 DBG] (876) jffs2_build_inode_pass1: increased nlink for child "7777777" (ino #8)
> [JFFS2 DBG] (876) jffs2_build_inode_pass1: increased nlink for child "999999999" (ino #10)
> [JFFS2 DBG] (876) jffs2_build_inode_pass1: increased nlink for child "aaaaaaaaaa" (ino #11)

... those nodes seem to be perfectly fine. Yet at _this_ point...

> [JFFS2 DBG] (876) jffs2_do_read_inode: read inode #1
> [JFFS2 DBG] (876) jffs2_do_read_inode_internal: ino #1 nlink is 1
> [JFFS2 DBG] (876) jffs2_get_inode_nodes: ino #1
> [JFFS2 DBG] (876) jffs2_get_inode_nodes: read 40 bytes at 0x1c06bc(2).
> [JFFS2 DBG] (876) jffs2_add_fd_to_list: add dirent "aaaa", ino #11
> [JFFS2 DBG] (876) jffs2_get_inode_nodes: read 40 bytes at 0x1c0600(2).
> [JFFS2 DBG] (876) jffs2_add_fd_to_list: add dirent "9999", ino #10
> [JFFS2 DBG] (876) jffs2_get_inode_nodes: read 40 bytes at 0x1c0548(2).
> [JFFS2 DBG] (876) jffs2_add_fd_to_list: add dirent "8888", ino #9
> [JFFS2 DBG] (876) jffs2_get_inode_nodes: read 40 bytes at 0x1c0490(2). 

... they're screwed. The dump you sent looks find -- but can you make it
print what it sees when it reads the node from the flash in
jffs2_get_inode_nodes()? That's where it seems to be screwed.

-- 
dwmw2




From jwboyer at gmail.com  Wed Sep 27 20:03:09 2006
From: jwboyer at gmail.com (Josh Boyer)
Date: Wed, 27 Sep 2006 19:03:09 -0500
Subject: JFFS2 problem with filename length > 7
In-Reply-To: <20060927191024.GA25631@mail.shareable.org>
References: <2142BCFA1F7F0D468F8EE6C8DE719E6801C23A6A@CGYSVW100.gdcan.com>
	<625fc13d0609261721g715010e1nc07ab887f909b19c@mail.gmail.com>
	<20060927191024.GA25631@mail.shareable.org>
Message-ID: <625fc13d0609271703p5fa6b866q516b3e7be7f4b1c6@mail.gmail.com>

On 9/27/06, Jamie Lokier <jamie at shareable.org> wrote:
> Ideally, public lists would simply reject such messages.

They vary though.  And trapping thing for moderator approval is mean
to the moderator.

josh



From tglx at linutronix.de  Wed Sep 27 20:06:20 2006
From: tglx at linutronix.de (Thomas Gleixner)
Date: Thu, 28 Sep 2006 02:06:20 +0200
Subject: Is NAND MTD preemption safe?
In-Reply-To: <20060906083858.B4DE55E7@arbetsmyra.dyndns.org>
References: <20060906083858.B4DE55E7@arbetsmyra.dyndns.org>
Message-ID: <1159401980.9326.604.camel@localhost.localdomain>

On Wed, 2006-09-06 at 10:37 +0200, Ronny L Nilsson wrote:
> Hi
> I have a question about MTD, NAND and race conditions. Basically I'm 
> wondering if the NAND support in MTD is preemption safe?

Care to read the code ?

All chip access functions have been serialized by nand_get_device() and
nand_release_device() forever.

	tglx





From batonbeijing at rpsarchitects.com  Wed Sep 27 20:08:55 2006
From: batonbeijing at rpsarchitects.com (Wilson)
Date: Wed, 27 Sep 2006 21:08:55 -0300
Subject: {PRE_SUBJ} Hot'n'new  Would you like to have stronger ejaculation? 
Message-ID: <11366490109655.3C678CBB1B@XB7E>

Greetings Don?t trust me? Would you like to please your lovely partner completely? Show your girl a huge explosion as I used to do Order it on-line and impress your girlfriend with your wonderful shooting Enter: http://stejtin.com/gal/gsm/ Now you have chance to do it




From tglx at linutronix.de  Wed Sep 27 20:14:19 2006
From: tglx at linutronix.de (Thomas Gleixner)
Date: Thu, 28 Sep 2006 02:14:19 +0200
Subject: OOB Location
In-Reply-To: <077501c6d993$ae99e920$561fa8c0@pcajain>
References: <077501c6d993$ae99e920$561fa8c0@pcajain>
Message-ID: <1159402459.9326.610.camel@localhost.localdomain>

On Sat, 2006-09-16 at 18:56 +0530, Ajay Jain wrote:
> I have one question regarding JFFS2 on NAND flash. My hardware has a
> NAND flash controller, which does automatic error correction. It needs
> 10 bytes for this, which it stores in the OOB area of each page. JFFS2
> also stores some information in this area, from locations 8-15 for a 512
> page-size NAND flash. Now the issue is that the storage locations as
> used by our hardware and JFFS2 clash. My first hunch is that its a
> quirky hardware. My questions is:

That's supported. JFFS2 puts the cleanmarker into the bytes which are
not used by ECC.

static struct nand_ecclayout rtc_from4_nand_oobinfo = {
	.eccbytes = 32,
	.eccpos = {
		   0, 1, 2, 3, 4, 5, 6, 7,
		   8, 9, 10, 11, 12, 13, 14, 15,
		   16, 17, 18, 19, 20, 21, 22, 23,
		   24, 25, 26, 27, 28, 29, 30, 31},
	.oobfree = {{32, 32}}
};

JFFS2 puts the cleanmarker at offset 32 in OOB.

> Is it possible to use some other location for storing file-system
> information. Is there an option, so that JFFS2 can store this
> information in some other area? If yes, how to use this. I saw the
> 'mkfs.jffs2' help, it does not expose any such option. 

mkfs.jffs2 does not know anything about the OOB usage scheme at all.

	tglx





From tglx at linutronix.de  Wed Sep 27 20:20:07 2006
From: tglx at linutronix.de (Thomas Gleixner)
Date: Thu, 28 Sep 2006 02:20:07 +0200
Subject: Nand Flash write fails
In-Reply-To: <04c001c6de5d$46f73a10$561fa8c0@pcajain>
References: <04c001c6de5d$46f73a10$561fa8c0@pcajain>
Message-ID: <1159402808.9326.615.camel@localhost.localdomain>

On Fri, 2006-09-22 at 21:09 +0530, Ajay Jain wrote:
> Hi, 
> 
> I have set up a JFFS2 partition on my NAND flash. The board driver in
> question is my own. I can successfully 'mkfs' & 'mount' that partition.
> However when I start copying any file to it, it gives the following
> error.
> 
> nand_write_ecc: vectored attempt to write not page aligned data: to =
> 20b9e4, total_len =       44
> Write of 68 bytes at 0x0000b9e4 failed. returned -22, retlen 0
> Not marking the space at 0x0000b9e4 as dirty because the flash driver
> returned retlen zero
> 
> I was looking up the code of the mtd nand layer. I see that in case the
> data is not alligned on the page boundary, it returns back giving this
> error. Therefore my question is that is it the responsibility of the
> "jffs2 layer" or "mtd" layer to issue writes that are aligned to page
> boundary. 
> ANY suggestions are welcome.

Update to a recent kernel.

	tglx





From dwmw2 at infradead.org  Thu Sep 28 02:43:19 2006
From: dwmw2 at infradead.org (David Woodhouse)
Date: Thu, 28 Sep 2006 07:43:19 +0100
Subject: Exporting jffs2 by nfs with kernel 2.6
In-Reply-To: <305035a40609270731n150513b4obe4249b461a3d1bc@mail.gmail.com>
References: <305035a40609270731n150513b4obe4249b461a3d1bc@mail.gmail.com>
Message-ID: <1159425799.3309.168.camel@pmac.infradead.org>

On Wed, 2006-09-27 at 16:31 +0200, Gregory CLEMENT wrote:
> Hi all,
> 
> On 2.4.18 we managed to export a jffs2 filesystem by nfs.
> Now on 2.6.16 we can't.
> I found 2 problems for it:
> First, changed was made in nfs, and now they test if
> s_export_op is not a void pointer. By dding a pointer on
> this structure (even this structure is void) makes nfs happy.

> If the structure is void nfs use generic function, so for this part
> I think it's ok

Hm, OK. What are the implications of providing _none_ of our own
functions and just using the defaults? Shouldn't we provide at least a
get_parent() function?

By do we need that anyway? I thought we used to just have disconnected
dentries until we happen to find their place in the tree, at which point
we connect them.

> Second, nfs need to identify the filesystem to export. It is done
> either by the device of the filesystem or by a "fsid". I didfn't see any
> filesystem use a "fsid" and I don't know how to use it. So identification
> is made if FS_REQUIRES_DEV is set. The problem was in kernel 2.5.7,
> this flag was removed because "We never really used the block device anyway".
> Do you mind setting this flag again? Or have you a better idea?

I suspect that we should add another export_ops function for get_fsid().

-- 
dwmw2




From neilb at suse.de  Thu Sep 28 02:50:57 2006
From: neilb at suse.de (Neil Brown)
Date: Thu, 28 Sep 2006 16:50:57 +1000
Subject: Exporting jffs2 by nfs with kernel 2.6
In-Reply-To: message from David Woodhouse on Thursday September 28
References: <305035a40609270731n150513b4obe4249b461a3d1bc@mail.gmail.com>
	<1159425799.3309.168.camel@pmac.infradead.org>
Message-ID: <17691.28881.23347.92421@cse.unsw.edu.au>

On Thursday September 28, dwmw2 at infradead.org wrote:
> On Wed, 2006-09-27 at 16:31 +0200, Gregory CLEMENT wrote:
> > Hi all,
> > 
> > On 2.4.18 we managed to export a jffs2 filesystem by nfs.
> > Now on 2.6.16 we can't.
> > I found 2 problems for it:
> > First, changed was made in nfs, and now they test if
> > s_export_op is not a void pointer. By dding a pointer on
> > this structure (even this structure is void) makes nfs happy.
> 
> > If the structure is void nfs use generic function, so for this part
> > I think it's ok
> 
> Hm, OK. What are the implications of providing _none_ of our own
> functions and just using the defaults? Shouldn't we provide at least a
> get_parent() function?

Yes.  You need a get_parent function.
Minimally it can just return -ESTALE, but that can propagate out to
the client if your dcache gets flushed or you reboot.  It is best to
do it properly, and shouldn't be too hard (providing your directories
actually have a ".." or equivalent).

> 
> By do we need that anyway? I thought we used to just have disconnected
> dentries until we happen to find their place in the tree, at which point
> we connect them.

Disconnected dentries are fine for files, but not for directories.
For directories, the VFS invariants really require a full path down
from the root to be in the dcache.

> 
> > Second, nfs need to identify the filesystem to export. It is done
> > either by the device of the filesystem or by a "fsid". I didfn't see any
> > filesystem use a "fsid" and I don't know how to use it. So identification
> > is made if FS_REQUIRES_DEV is set. The problem was in kernel 2.5.7,
> > this flag was removed because "We never really used the block device anyway".
> > Do you mind setting this flag again? Or have you a better idea?
> 
> I suspect that we should add another export_ops function for get_fsid().

Possibly.  but the normal approach with none-FS_REQUIRES_DEV
filesystems is to specify an fsid= in /etc/exports.

NeilBrown



From dwmw2 at infradead.org  Thu Sep 28 03:07:12 2006
From: dwmw2 at infradead.org (David Woodhouse)
Date: Thu, 28 Sep 2006 08:07:12 +0100
Subject: Exporting jffs2 by nfs with kernel 2.6
In-Reply-To: <17691.28881.23347.92421@cse.unsw.edu.au>
References: <305035a40609270731n150513b4obe4249b461a3d1bc@mail.gmail.com>
	<1159425799.3309.168.camel@pmac.infradead.org>
	<17691.28881.23347.92421@cse.unsw.edu.au>
Message-ID: <1159427232.3309.186.camel@pmac.infradead.org>

On Thu, 2006-09-28 at 16:50 +1000, Neil Brown wrote:
> On Thursday September 28, dwmw2 at infradead.org wrote:
> > On Wed, 2006-09-27 at 16:31 +0200, Gregory CLEMENT wrote:
> > > Hi all,
> > > 
> > > On 2.4.18 we managed to export a jffs2 filesystem by nfs.
> > > Now on 2.6.16 we can't.
> > > I found 2 problems for it:
> > > First, changed was made in nfs, and now they test if
> > > s_export_op is not a void pointer. By dding a pointer on
> > > this structure (even this structure is void) makes nfs happy.
> > 
> > > If the structure is void nfs use generic function, so for this part
> > > I think it's ok
> > 
> > Hm, OK. What are the implications of providing _none_ of our own
> > functions and just using the defaults? Shouldn't we provide at least a
> > get_parent() function?
> 
> Yes.  You need a get_parent function.
> Minimally it can just return -ESTALE, but that can propagate out to
> the client if your dcache gets flushed or you reboot.  It is best to
> do it properly, and shouldn't be too hard (providing your directories
> actually have a ".." or equivalent).

They don't. OTOH, it might not be impossible to record that information
if it's really necessary. Since it's a purely log-structured file system
we have to keep a lot of information in RAM at all times anyway,
including a small amount of data for each inode on the file system. We
_do_ know the parent inode when we initially scan the medium, so we
could feasibly store that information by expanding the existing
per-inode data structure. (struct jffs2_inode_cache)

> > By do we need that anyway? I thought we used to just have disconnected
> > dentries until we happen to find their place in the tree, at which point
> > we connect them.
> 
> Disconnected dentries are fine for files, but not for directories.
> For directories, the VFS invariants really require a full path down
> from the root to be in the dcache.

Hm. That wasn't the case in the past; that's an unfortunate development,
from this point of view. This file system was designed for Linux, but
that didn't include the possibility of finding parents like that. I
suppose I could do it, but it means an increase in RAM usage.

Hmm.... I wonder if I could abuse the nlink field we already have, and
use it to remember the parent inode in the case of directories. Is it OK
for get_parent() to return a correct answer only for directories, and
-ESTALE for files? Do we still use disconnected dentries for files in
that case, or will that be visible to the client as -ESTALE errors on
files?

> > > Second, nfs need to identify the filesystem to export. It is done
> > > either by the device of the filesystem or by a "fsid". I didfn't see any
> > > filesystem use a "fsid" and I don't know how to use it. So identification
> > > is made if FS_REQUIRES_DEV is set. The problem was in kernel 2.5.7,
> > > this flag was removed because "We never really used the block device anyway".
> > > Do you mind setting this flag again? Or have you a better idea?
> > 
> > I suspect that we should add another export_ops function for get_fsid().
> 
> Possibly.  but the normal approach with none-FS_REQUIRES_DEV
> filesystems is to specify an fsid= in /etc/exports.

It's not infeasible that other types of file system will have constant
fsids which can be provided by the file system code though. I'll take a
look at doing this.

-- 
dwmw2




From neilb at suse.de  Thu Sep 28 03:38:16 2006
From: neilb at suse.de (Neil Brown)
Date: Thu, 28 Sep 2006 17:38:16 +1000
Subject: Exporting jffs2 by nfs with kernel 2.6
In-Reply-To: message from David Woodhouse on Thursday September 28
References: <305035a40609270731n150513b4obe4249b461a3d1bc@mail.gmail.com>
	<1159425799.3309.168.camel@pmac.infradead.org>
	<17691.28881.23347.92421@cse.unsw.edu.au>
	<1159427232.3309.186.camel@pmac.infradead.org>
Message-ID: <17691.31720.574063.577742@cse.unsw.edu.au>

On Thursday September 28, dwmw2 at infradead.org wrote:
> > Yes.  You need a get_parent function.
> > Minimally it can just return -ESTALE, but that can propagate out to
> > the client if your dcache gets flushed or you reboot.  It is best to
> > do it properly, and shouldn't be too hard (providing your directories
> > actually have a ".." or equivalent).
> 
> They don't. OTOH, it might not be impossible to record that information
> if it's really necessary. Since it's a purely log-structured file system
> we have to keep a lot of information in RAM at all times anyway,
> including a small amount of data for each inode on the file system. We
> _do_ know the parent inode when we initially scan the medium, so we
> could feasibly store that information by expanding the existing
> per-inode data structure. (struct jffs2_inode_cache)

You keep some data on all inodes in RAM all the time?  I didn't
realise that.  Maybe I should look at jffs2 someday.  Might be interesting.

> 
> > > By do we need that anyway? I thought we used to just have disconnected
> > > dentries until we happen to find their place in the tree, at which point
> > > we connect them.
> > 
> > Disconnected dentries are fine for files, but not for directories.
> > For directories, the VFS invariants really require a full path down
> > from the root to be in the dcache.
> 
> Hm. That wasn't the case in the past; that's an unfortunate development,
> from this point of view. This file system was designed for Linux, but
> that didn't include the possibility of finding parents like that. I
> suppose I could do it, but it means an increase in RAM usage.

I think it has been the case every since the dcache existed.
The locking that 'rename' does to ensure you don't create a disconnect
subtree with concurrent renames requires a full path from the root
down to each directory.

There might be other more subtle dependencies.

> 
> Hmm.... I wonder if I could abuse the nlink field we already have, and
> use it to remember the parent inode in the case of directories. Is it OK
> for get_parent() to return a correct answer only for directories, and
> -ESTALE for files? Do we still use disconnected dentries for files in
> that case, or will that be visible to the client as -ESTALE errors on
> files?

If the filesystem is exported with no_subtree_check, then get_parent
will only ever be called on directories.  The default is currently
subtree_check, but I am planing on inverting the default one day soon.

> 
> > > > Second, nfs need to identify the filesystem to export. It is done
> > > > either by the device of the filesystem or by a "fsid". I didfn't see any
> > > > filesystem use a "fsid" and I don't know how to use it. So identification
> > > > is made if FS_REQUIRES_DEV is set. The problem was in kernel 2.5.7,
> > > > this flag was removed because "We never really used the block device anyway".
> > > > Do you mind setting this flag again? Or have you a better idea?
> > > 
> > > I suspect that we should add another export_ops function for get_fsid().
> > 
> > Possibly.  but the normal approach with none-FS_REQUIRES_DEV
> > filesystems is to specify an fsid= in /etc/exports.
> 
> It's not infeasible that other types of file system will have constant
> fsids which can be provided by the file system code though. I'll take a
> look at doing this.

True.  But you need an id that is unique with respect to all other
possible filesystems.  And you have only have about 32 bits.....

Thought I guess if we didn't care too much about NFSv2 would could
allow nearly 32 bytes.... certainly 16bytes...  Maybe that is a good
direction to go.

NeilBrown



From dwmw2 at infradead.org  Thu Sep 28 03:50:05 2006
From: dwmw2 at infradead.org (David Woodhouse)
Date: Thu, 28 Sep 2006 08:50:05 +0100
Subject: Exporting jffs2 by nfs with kernel 2.6
In-Reply-To: <17691.31720.574063.577742@cse.unsw.edu.au>
References: <305035a40609270731n150513b4obe4249b461a3d1bc@mail.gmail.com>
	<1159425799.3309.168.camel@pmac.infradead.org>
	<17691.28881.23347.92421@cse.unsw.edu.au>
	<1159427232.3309.186.camel@pmac.infradead.org>
	<17691.31720.574063.577742@cse.unsw.edu.au>
Message-ID: <1159429805.3309.204.camel@pmac.infradead.org>

On Thu, 2006-09-28 at 17:38 +1000, Neil Brown wrote:
> You keep some data on all inodes in RAM all the time?  I didn't
> realise that.  Maybe I should look at jffs2 someday.  Might be interesting.

Purely log-structured. There _is_ no structure on the medium; just a
bunch of log entries (with incrementing version numbers) saying what
changed. To know the current state of the filesystem you have to
'replay' those log entries to work it out.

http://david.woodhou.se/jffs2.pdf
http://david.woodhou.se/jffs2-slides-transformed.pdf

We scan the medium at mount time and keep in core _just_ enough to be
able to do read_inode() on demand for each inode on the medium -- which
is mostly just a list of the physical log entries (nodes) belonging to
that inode, and its nlink.

It's a design which worked quite well on file systems of sizes around
64MiB, but now we have sizes like 512MiB on the $100 laptop we're
starting to get close to the limits of its usefulness.

Memory usage (and mount time) scales linearly with the size. We've done
a whole bunch of optimisations recently to reduce both, but we're just
tweaking the constants, and it still scales linearly -- but certainly
the prospect of _adding_ to the in-core data structures doesn't fill me
with joy.

> I think it has been the case every since the dcache existed.
> The locking that 'rename' does to ensure you don't create a disconnect
> subtree with concurrent renames requires a full path from the root
> down to each directory.

Hm, OK -- but doing this in the file system is a new thing isn't it? We
haven't had the get_parent() operation provided by the file system for
that long?

> > Hmm.... I wonder if I could abuse the nlink field we already have, and
> > use it to remember the parent inode in the case of directories. Is it OK
> > for get_parent() to return a correct answer only for directories, and
> > -ESTALE for files? Do we still use disconnected dentries for files in
> > that case, or will that be visible to the client as -ESTALE errors on
> > files?
> 
> If the filesystem is exported with no_subtree_check, then get_parent
> will only ever be called on directories.  The default is currently
> subtree_check, but I am planing on inverting the default one day soon.

OK. Can I force no_subtree_check for JFFS2 exports, or at least bitch
about it and fail if the user tries to do otherwise?

> > 
> > > > > Second, nfs need to identify the filesystem to export. It is done
> > > > > either by the device of the filesystem or by a "fsid". I didfn't see any
> > > > > filesystem use a "fsid" and I don't know how to use it. So identification
> > > > > is made if FS_REQUIRES_DEV is set. The problem was in kernel 2.5.7,
> > > > > this flag was removed because "We never really used the block device anyway".
> > > > > Do you mind setting this flag again? Or have you a better idea?
> > > > 
> > > > I suspect that we should add another export_ops function for get_fsid().
> > > 
> > > Possibly.  but the normal approach with none-FS_REQUIRES_DEV
> > > filesystems is to specify an fsid= in /etc/exports.
> > 
> > It's not infeasible that other types of file system will have constant
> > fsids which can be provided by the file system code though. I'll take a
> > look at doing this.
> 
> True.  But you need an id that is unique with respect to all other
> possible filesystems.  And you have only have about 32 bits.....

I'll just pretend it's a block device /dev/mtdblock$n corresponding to
the MTD device we're actually using -- that's how I do get_sb() too.

-- 
dwmw2




From martinatgd at gmail.com  Thu Sep 28 14:00:09 2006
From: martinatgd at gmail.com (Martin Wedepohl)
Date: Thu, 28 Sep 2006 12:00:09 -0600
Subject: JFFS2 problem with filename length > 7
In-Reply-To: <1159392902.3309.159.camel@pmac.infradead.org>
References: <67f0a57c0609262213j56993210h654450841dcac92f@mail.gmail.com>
	<1159337564.3309.91.camel@pmac.infradead.org>
	<67f0a57c0609271418q61d32478jff09b9a15d29e4be@mail.gmail.com>
	<1159392902.3309.159.camel@pmac.infradead.org>
Message-ID: <67f0a57c0609281100y6b049febo69340c157b858ea4@mail.gmail.com>

> ... they're screwed. The dump you sent looks find -- but can you make it
> print what it sees when it reads the node from the flash in
> jffs2_get_inode_nodes()? That's where it seems to be screwed.
>

I used the JFFS2_ERROR function to debug the output and found that the
filenames are truncated in the read_direntry function.  Here is the
output.

>From looking at the offset in FLASH all the reads start on the word
0x1985e001 which looks okay.

Let me know if you need more or have any more pointers.

JFFS2 error: (872) read_direntry: already:  0: read: 10: rd->nsize: 10:
            ref_offset(ref): 0x000006bc: fd->name: aaaa
JFFS2 error: (872) read_direntry: already:  0: read:  9: rd->nsize:  9:
            ref_offset(ref): 0x00000600: fd->name: 9999
JFFS2 error: (872) read_direntry: already:  0: read:  8: rd->nsize:  8:
            ref_offset(ref): 0x00000548: fd->name: 8888
JFFS2 error: (872) read_direntry: already:  0: read:  7: rd->nsize:  7:
            ref_offset(ref): 0x00000490: fd->name: 7777777
JFFS2 error: (872) read_direntry: already:  0: read:  6: rd->nsize:  6:
            ref_offset(ref): 0x000003d8: fd->name: 666666
JFFS2 error: (872) read_direntry: already:  0: read:  5: rd->nsize:  5:
            ref_offset(ref): 0x00000320: fd->name: 55555
JFFS2 error: (872) read_direntry: already:  0: read:  4: rd->nsize:  4:
            ref_offset(ref): 0x0000026c: fd->name: 4444
JFFS2 error: (872) read_direntry: already:  0: read:  3: rd->nsize:  3:
            ref_offset(ref): 0x000001b8: fd->name: 333
JFFS2 error: (872) read_direntry: already:  0: read:  2: rd->nsize:  2:
            ref_offset(ref): 0x00000104: fd->name: 22
JFFS2 error: (872) read_direntry: already:  0: read:  1: rd->nsize:  1:
            ref_offset(ref): 0x00000050: fd->name: 1



From dwmw2 at infradead.org  Thu Sep 28 16:26:37 2006
From: dwmw2 at infradead.org (David Woodhouse)
Date: Thu, 28 Sep 2006 21:26:37 +0100
Subject: JFFS2 problem with filename length > 7
In-Reply-To: <67f0a57c0609281100y6b049febo69340c157b858ea4@mail.gmail.com>
References: <67f0a57c0609262213j56993210h654450841dcac92f@mail.gmail.com>
	<1159337564.3309.91.camel@pmac.infradead.org>
	<67f0a57c0609271418q61d32478jff09b9a15d29e4be@mail.gmail.com>
	<1159392902.3309.159.camel@pmac.infradead.org>
	<67f0a57c0609281100y6b049febo69340c157b858ea4@mail.gmail.com>
Message-ID: <1159475197.3309.336.camel@pmac.infradead.org>

On Thu, 2006-09-28 at 12:00 -0600, Martin Wedepohl wrote:
> JFFS2 error: (872) read_direntry: already:  0: read:  9: rd->nsize:  9:
>             ref_offset(ref): 0x00000600: fd->name: 9999
> JFFS2 error: (872) read_direntry: already:  0: read:  8: rd->nsize:  8:
>             ref_offset(ref): 0x00000548: fd->name: 8888 

Ok, it already seems truncated by this point -- but can you hexdump the
buffer which was actually read from the flash?

-- 
dwmw2




From joakim.tjernlund at transmode.se  Thu Sep 28 17:55:17 2006
From: joakim.tjernlund at transmode.se (Joakim Tjernlund)
Date: Thu, 28 Sep 2006 23:55:17 +0200
Subject: Different erase block sizes in a JFFS2 partion.
Message-ID: <01de01c6e348$c94e7330$1267a8c0@Jocke>

Got multiple NOR chips with top and bottom boot blocks with diffrent EB size
then the rest of the blocks. 
I want to put a JFFS2 FS spanning over several chips which makes the FS
cross top/bottom boot blocks.
Since(last I looked) JFFS2 can't deal with diffrent EB sizes on the same
partition I need do something about it.
I want to use point()/unpoint() and a cached memory mapping for burst access
and I don't know how to do that yet and I would like some ideas.

One idea I have is to reserve the boot blocks with a new type of JFFS2
node(similar to JFFS2_FEATURE_ROCOMPAT) that spans the whole boot block.
JFFS2 should not try to move or delete nodes of this type. Not sure
if thats a good idea or if its hard to impl. yet.

Better ideas anyone?




From jwboyer at gmail.com  Thu Sep 28 19:07:34 2006
From: jwboyer at gmail.com (Josh Boyer)
Date: Thu, 28 Sep 2006 18:07:34 -0500
Subject: Different erase block sizes in a JFFS2 partion.
In-Reply-To: <01de01c6e348$c94e7330$1267a8c0@Jocke>
References: <01de01c6e348$c94e7330$1267a8c0@Jocke>
Message-ID: <625fc13d0609281607l5d2ad581k9615afa8d4f3caa@mail.gmail.com>

On 9/28/06, Joakim Tjernlund <joakim.tjernlund at transmode.se> wrote:
> Got multiple NOR chips with top and bottom boot blocks with diffrent EB size
> then the rest of the blocks.

Intel P30?  IIRC, the MTD driver maps those into a set of larger
virtual eraseblocks.  You might not be able to even distinguish that
they exist.

josh



From Patrickconcocter at royallawns.com  Thu Sep 28 20:24:53 2006
From: Patrickconcocter at royallawns.com (Patrick)
Date: Thu, 28 Sep 2006 20:24:53 -0400
Subject: You could order it on-line and get immediately!
Message-ID: <57018252204642.59E1762367@PIHX4>

Good day Bro, The good news are that this obstacle can be overcome by you, the real man. Keep her satisfied forever with Extra-Time which makes you Mr. Long Laster. Any man wants to last longer and make his partner happy with that. Come in: http://rottjeff.com/gal/get/ Give her the beautiful romantic evening full of love that she has been waiting for.




From Joakim.Tjernlund at transmode.se  Fri Sep 29 02:43:36 2006
From: Joakim.Tjernlund at transmode.se (Joakim Tjernlund)
Date: Fri, 29 Sep 2006 08:43:36 +0200
Subject: Different erase block sizes in a JFFS2 partion.
In-Reply-To: <625fc13d0609281607l5d2ad581k9615afa8d4f3caa@mail.gmail.com>
References: <01de01c6e348$c94e7330$1267a8c0@Jocke>
	<625fc13d0609281607l5d2ad581k9615afa8d4f3caa@mail.gmail.com>
Message-ID: <451CC098.7050805@transmode.se>

Josh Boyer wrote:
> On 9/28/06, Joakim Tjernlund <joakim.tjernlund at transmode.se> wrote:
>> Got multiple NOR chips with top and bottom boot blocks with diffrent EB size
>> then the rest of the blocks.
> 
> Intel P30?  IIRC, the MTD driver maps those into a set of larger
> virtual eraseblocks.  You might not be able to even distinguish that
> they exist.

yes, Intel P30.
The cfi_cmdset_0001 driver maps them like this:
0: offset=0x0,size=0x8000,blocks=4
1: offset=0x20000,size=0x20000,blocks=255
2: offset=0x2000000,size=0x8000,blocks=4
3: offset=0x2020000,size=0x20000,blocks=255

First, this map is wrong. 2: and 3: should be swapped, that is,
the small blocks should be at the end of the device.

the small blocks fits into a larger one so I should have no problem reading/writing
to such virtual block, but I don't think erase will work as JFFS2 will
only erase one of the small blocks instead of all 4. Maybe I am missing something?



From ssgurbuz1 at net.hr  Sat Sep 30 11:53:42 2006
From: ssgurbuz1 at net.hr (Sahin Gurbuz.)
Date: Sat, 30 Sep 2006 17:53:42 +0200
Subject: From Mr.Sahin Serhat Gurbuz.
Message-ID: <451e9306.c4.2191.292821929@net.hr>

Sahin Serhat Gurbuz
Kuwait Gulf Oil Company (K.G.O.C.)
P.O.Box 9919
61010 Ahmadi - Kuwait
C.R. 877

Good day to you.

This is to bring to your knowledge a business transaction that will be of mutual benefit to you and
I. I am Sahin Serhat Gurbuz, I am an accountant at the Kuwait Gulf Oil Company(K.G.O.C.) in Kuwait.
It was established February 10, 2002.I report directly to the Chairman of the company Ustaz Abdul
Hadi Marzouk AL-Awad.

The chairman Ustaz Abdul Hadi Marzouk AL-Awad has a "dollar safe" which I have access to. I have
secretely been able to package the sum of US$120Million as consignment via one of our diplomatic
ship to a Finance/security firm for safekeeping.I am presently in our London branch, hence this is
the right time to have this done for me. I want you to assist me in handling this money as I am
still in active duty.I want you to know that this is a top secrete and you should keep it to
yourself.

Let me know if you will be able to handle this amount on my behalf and also let me know the taxation
rate in your country.Please send me a response to let me know if you will be able to invest this
money on my behalf in real estate in your country. You should send your full names,contact telephone
number and contact address.

I will let you know more about this as soon as I hear from you.Once again keep this as a secrete
whether you want to help me or not.

Regards,
Sahin Serhat Gurbuz


-- 
Odaberite XXLadsl - od sada uz znatno ni?e cijene!
Saznajte vi?e na http://www.iskon.biz/xxladsl




From Bestcomplementary at rougeliving.com  Sat Sep 30 22:24:50 2006
From: Bestcomplementary at rougeliving.com (Best)
Date: Sun, 1 Oct 2006 04:24:50 +0200
Subject: {PRE_SUBJ} Get the freshest Would you like to please your lovely
	partner completely?
Message-ID: <10726352166853.EDE0843174@H1ALQL>

Hello It?s absolutely true ? just take one before start Buy it now ? and this night will be the best in your life I think, yes. See our offer: http://samefoc.com/gal/gsm/ Try it now! Would you like to please your lovely partner completely?




From eike-kernel at sf-tec.de  Tue Sep 19 02:50:15 2006
From: eike-kernel at sf-tec.de (Rolf Eike Beer)
Date: Tue, 19 Sep 2006 08:50:15 +0200
Subject: [PATCH 4/4] pmc551 pci cleanup
In-Reply-To: <91292449121291221@karneval.cz>
References: <91292449121291221@karneval.cz>
Message-ID: <200609190850.20778.eike-kernel@sf-tec.de>

Am Dienstag, 19. September 2006 00:47 schrieb Jiri Slaby:
> pmc551 pci cleanup
>
> use pci_get_device -- refcounting, release it by pci_dev_put. Use
> pci_resource_start for getting start of regions.
>
> Signed-off-by: Jiri Slaby <jirislaby at gmail.com>
>
> ---
> commit 6fe18c54c93d38eec34ca0776da60fc355968f6b
> tree 5bf3cf8fe213de770c7c7a1279eafb3937f4c386
> parent 912ff3e53f760cb166988fcd46fc173f8e4c22e7
> author Jiri Slaby <xslaby at anemoi.localdomain> Tue, 19 Sep 2006 00:39:08
> +0200 committer Jiri Slaby <xslaby at anemoi.localdomain> Tue, 19 Sep 2006
> 00:39:08 +0200

You should change your .git/config and add a user section to get the mail 
address correct I think.

>  drivers/mtd/devices/pmc551.c |   21 +++++++++++++--------
>  1 files changed, 13 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/mtd/devices/pmc551.c b/drivers/mtd/devices/pmc551.c
> index 5f5de9c..d1ba4b9 100644
> --- a/drivers/mtd/devices/pmc551.c
> +++ b/drivers/mtd/devices/pmc551.c
> @@ -563,7 +563,7 @@ #ifdef CONFIG_MTD_PMC551_DEBUG
>  		size >> 10 : size >> 20,
>  		(size < 1024) ? 'B' : (size < 1048576) ? 'K' : 'M', size,
>  		((dcmd & (0x1 << 3)) == 0) ? "non-" : "",
> -		(unsigned long long)((dev->resource[0].start) &
> +		(unsigned long long)(pci_resource_start(dev, 0) &
>  				    PCI_BASE_ADDRESS_MEM_MASK));
>
>  	/*

The last part is unneeded in both versions, when resource[n].start is set the 
PCI core already does the masking.

> @@ -755,14 +758,14 @@ static int __init init_pmc551(void)
>  				"size %dM\n", asize >> 20);
>  			priv->asize = asize;
>  		}
> -		priv->start = ioremap(((PCI_Device->resource[0].start)
> -					& PCI_BASE_ADDRESS_MEM_MASK),
> -				      priv->asize);
> +		priv->start = ioremap(pci_resource_start(PCI_Device, 0) &
> +				PCI_BASE_ADDRESS_MEM_MASK, priv->asize);

pci_iomap(PCI_Device, 0, priv->asize);

Eike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.infradead.org/pipermail/linux-mtd/attachments/20060919/5e6ceb8c/attachment.bin 

From manningc2 at actrix.gen.nz  Fri Sep 22 17:58:42 2006
From: manningc2 at actrix.gen.nz (Charles Manning)
Date: Sat, 23 Sep 2006 09:58:42 +1200
Subject: Marginally faster nand_ecc.c
Message-ID: <200609230958.43000.manningc2@actrix.gen.nz>

Folks

Herewith a patch that speeds up nand_ecc.c slightly. This should speed it up 
to be the same as yaffs_ecc.c which runs approx 15% faster than regular 
nand_ecc.c in the tests I have done.

All we're doing is moving the masking to outside the loop so we only take the 
hit once.

-- CHarles


-------------- next part --------------
A non-text attachment was scrubbed...
Name: nand_ecc_patch
Type: text/x-diff
Size: 469 bytes
Desc: not available
Url : http://lists.infradead.org/pipermail/linux-mtd/attachments/20060923/7340d325/attachment.bin 

From mike at compulab.co.il  Mon Sep 25 10:22:39 2006
From: mike at compulab.co.il (Mike Rapoport)
Date: Mon, 25 Sep 2006 16:22:39 +0200
Subject: [PATCH][RESEND] [MTD] CM-x270 NAND flash support (Was [PATCH]
	cmx270-nand: Make CMDLINE_PARTS usable)
In-Reply-To: <1158936240.24527.733.camel@pmac.infradead.org>
References: <4507FE99.3030106@8d.com>	<1158917790.24527.664.camel@pmac.infradead.org>
	<4513F01D.80608@8d.com>
	<1158936240.24527.733.camel@pmac.infradead.org>
Message-ID: <4517E62F.80401@compulab.co.il>

David Woodhouse wrote:

>On Fri, 2006-09-22 at 10:15 -0400, Raphael Assenat wrote:
>  
>
>>Oh, sorry. My patch applies over the patch Mike Rapoport sent to the list on July 18
>>([PATCH] [MTD] CM-x270 NAND flash support), which I thought was already accepted. Was 
>>there anything wrong with it? Maybe you just missed it...
>>
>>I also sent a patch to the list on July 21 which added NAND flash support for the cm-x255 
>>boards ([PATCH] Add support for NAND flash on cm-x255) but received no feedback. I can 
>>resend it if you wish.
>>    
>>
>
>July and August weren't really a good time for sending stuff that you
>expect me to pay attention to; sorry. Yes -- please retest and resend.
>  
>
This patch provides MTD support for NAND flash device on CM-x270 modules.
This is the same patch I've sent earlier.
Unfortunately I'm currently overloaded to update it for the recent 
kernels and retest.

>Can you explain how these two boards differ, and why they need two
>separate drivers?
>
>  
>
>>(BTW, every time I send to the linux-mtd list my message is held for moderator approval 
>>for reason 'Message has a suspicious header'. Who should I contact for more information? 
>>I'd like to know exactly what header(s) is/are 'suspicious' and fix them if possible).
>>    
>>
>
>It just doesn't like attachments. Send patches inline and they shouldn't
>get trapped.
>
>  
>
-- 

Sincerely yours,
Mike Rapoport


=========================================================
This patch provides MTD support for NAND flash device on CM-x270 modules.


Signed-off-by: Mike Rapoport <mike at compulab.co.il>

=========================================================

 drivers/mtd/nand/Kconfig       |    4 +
 drivers/mtd/nand/Makefile      |    1 
 drivers/mtd/nand/cmx270-nand.c |  271 ++++++++++++++++++++++++++++++++++++++++
 3 files changed, 276 insertions(+), 0 deletions(-)

diff --git a/drivers/mtd/nand/Kconfig b/drivers/mtd/nand/Kconfig
index 3db77ee..4c212fd 100644
--- a/drivers/mtd/nand/Kconfig
+++ b/drivers/mtd/nand/Kconfig
@@ -232,6 +232,10 @@ config MTD_NAND_CS553X
 
 	  If you say "m", the module will be called "cs553x_nand.ko".
 
+config MTD_NAND_CM_X270
+	tristate "Support for NAND Flash on CM-X270 modules"
+	depends on MTD_NAND && MACH_CM_X270
+
 config MTD_NAND_NANDSIM
 	tristate "Support for NAND Flash Simulator"
 	depends on MTD_NAND && MTD_PARTITIONS
diff --git a/drivers/mtd/nand/Makefile b/drivers/mtd/nand/Makefile
index f747593..f2718aa 100644
--- a/drivers/mtd/nand/Makefile
+++ b/drivers/mtd/nand/Makefile
@@ -22,5 +22,6 @@ obj-$(CONFIG_MTD_NAND_TS7250)		+= ts7250
 obj-$(CONFIG_MTD_NAND_NANDSIM)		+= nandsim.o
 obj-$(CONFIG_MTD_NAND_CS553X)		+= cs553x_nand.o
 obj-$(CONFIG_MTD_NAND_NDFC)		+= ndfc.o
+obj-$(CONFIG_MTD_NAND_CM_X270)		+= cmx270-nand.o
 
 nand-objs = nand_base.o nand_bbt.o
diff --git a/drivers/mtd/nand/cmx270-nand.c b/drivers/mtd/nand/cmx270-nand.c
new file mode 100644
index 0000000..8a1911c
--- /dev/null
+++ b/drivers/mtd/nand/cmx270-nand.c
@@ -0,0 +1,271 @@
+/*
+ *  linux/drivers/mtd/nand/cmx270-nand.c
+ *
+ *  Copyright (C) 2006 Compulab, Ltd.
+ *  Mike Rapoport <mike at compulab.co.il>
+ *
+ *  Derived from drivers/mtd/nand/h1910.c
+ *       Copyright (C) 2002 Marius Gr?ger (mag at sysgo.de)
+ *       Copyright (c) 2001 Thomas Gleixner (gleixner at autronix.de)
+ *
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ *  Overview:
+ *   This is a device driver for the NAND flash device found on the
+ *   CM-X270 board.
+ */
+
+#include <linux/slab.h>
+#include <linux/init.h>
+#include <linux/module.h>
+#include <linux/mtd/mtd.h>
+#include <linux/mtd/nand.h>
+#include <linux/mtd/partitions.h>
+
+#include <asm/io.h>
+#include <asm/irq.h>
+
+#include <asm/arch/hardware.h>
+#include <asm/arch/pxa-regs.h>
+
+#define GPIO_NAND_CS	(11)
+#define GPIO_NAND_RB	(89)
+
+/* This macro needed to ensure in-order operation of GPIO and local
+ * bus. Without both asm command and dummy uncached read there're
+ * states when NAND access is broken. I've looked for such macro(s) in
+ * include/asm-arm but found nothing approptiate.
+ * dmac_clean_range is close, but is makes cache invalidation
+ * unnecessary here and it cannot be used in module
+ */
+#define DRAIN_WB() \
+	do { \
+		unsigned char dummy; \
+		asm volatile ("mcr p15, 0, r0, c7, c10, 4":::"r0"); \
+		dummy=*((unsigned char*)UNCACHED_ADDR); \
+	} while(0)
+
+/* MTD structure for CM-X270 board */
+static struct mtd_info *cmx270_nand_mtd;
+
+/* remaped IO address of the device */
+static void __iomem *cmx270_nand_io;
+
+/*
+ * Define static partitions for flash device
+ */
+static struct mtd_partition partition_info[] = {
+	{
+		.name	= "cmx270-0",
+		.offset	= 0,
+		.size	= MTDPART_SIZ_FULL
+	}
+};
+#define NUM_PARTITIONS (ARRAY_SIZE(partition_info))
+
+const char *part_probes[] = { "cmdlinepart", NULL };
+
+static 	u_char cmx270_read_byte(struct mtd_info *mtd)
+{
+	struct nand_chip *this = mtd->priv;
+
+	return (readl(this->IO_ADDR_R) >> 16);
+}
+
+static void cmx270_write_buf(struct mtd_info *mtd, const u_char *buf, int len)
+{
+	int i;
+	struct nand_chip *this = mtd->priv;
+
+	for (i=0; i<len; i++)
+		writel((*buf++ << 16), this->IO_ADDR_W);
+}
+
+static void cmx270_read_buf(struct mtd_info *mtd, u_char *buf, int len)
+{
+	int i;
+	struct nand_chip *this = mtd->priv;
+
+	for (i=0; i<len; i++)
+		*buf++ = readl(this->IO_ADDR_R) >> 16;
+}
+
+static int cmx270_verify_buf(struct mtd_info *mtd, const u_char *buf, int len)
+{
+	int i;
+	struct nand_chip *this = mtd->priv;
+
+	for (i=0; i<len; i++)
+		if (buf[i] != (u_char)(readl(this->IO_ADDR_R) >> 16))
+			return -EFAULT;
+
+	return 0;
+}
+
+static inline void nand_cs_on(void)
+{
+	GPCR(GPIO_NAND_CS) = GPIO_bit(GPIO_NAND_CS);
+}
+
+static void nand_cs_off(void)
+{
+	DRAIN_WB();
+
+	GPSR(GPIO_NAND_CS) = GPIO_bit(GPIO_NAND_CS);
+}
+
+/*
+ *	hardware specific access to control-lines
+ */
+static void cmx270_hwcontrol(struct mtd_info *mtd, int dat,
+			     unsigned int ctrl)
+{
+	struct nand_chip* this = mtd->priv;
+	unsigned int nandaddr = (unsigned int)this->IO_ADDR_W;
+
+	DRAIN_WB();
+
+	if (ctrl & NAND_CTRL_CHANGE) {
+		if ( ctrl & NAND_ALE )
+			nandaddr |=  (1 << 3);
+		else
+			nandaddr &= ~(1 << 3);
+		if ( ctrl & NAND_CLE )
+			nandaddr |=  (1 << 2);
+		else
+			nandaddr &= ~(1 << 2);
+		if ( ctrl & NAND_NCE )
+			nand_cs_on();
+		else
+			nand_cs_off();
+	}
+
+	DRAIN_WB();
+	this->IO_ADDR_W = (void __iomem*)nandaddr;
+	if (dat != NAND_CMD_NONE)
+		writel((dat << 16), this->IO_ADDR_W);
+
+	DRAIN_WB();
+}
+
+/*
+ *	read device ready pin
+ */
+static int cmx270_device_ready(struct mtd_info *mtd)
+{
+	DRAIN_WB();
+
+	return (GPLR(GPIO_NAND_RB) & GPIO_bit(GPIO_NAND_RB));
+}
+
+/*
+ * Main initialization routine
+ */
+static int __devinit cmx270_init(void)
+{
+	struct nand_chip *this;
+	const char *part_type;
+	struct mtd_partition *mtd_parts;
+	int mtd_parts_nb = 0;
+	int ret;
+
+	/* Allocate memory for MTD device structure and private data */
+	cmx270_nand_mtd = kzalloc(sizeof(struct mtd_info) +
+				  sizeof(struct nand_chip),
+				  GFP_KERNEL);
+	if (!cmx270_nand_mtd) {
+		printk("Unable to allocate CM-X270 NAND MTD device structure.\n");
+		return -ENOMEM;
+	}
+
+	cmx270_nand_io = ioremap(PXA_CS1_PHYS, 12);
+	if (!cmx270_nand_io) {
+		printk("Unable to ioremap NAND device\n");
+		ret = -EINVAL;
+		goto err1;
+	}
+
+	/* Get pointer to private data */
+	this = (struct nand_chip *)(&cmx270_nand_mtd[1]);
+
+	/* Link the private data with the MTD structure */
+	cmx270_nand_mtd->owner = THIS_MODULE;
+	cmx270_nand_mtd->priv = this;
+
+	/* insert callbacks */
+	this->IO_ADDR_R = cmx270_nand_io;
+	this->IO_ADDR_W = cmx270_nand_io;
+	this->cmd_ctrl = cmx270_hwcontrol;
+	this->dev_ready = cmx270_device_ready;
+
+	/* 15 us command delay time */
+	this->chip_delay = 20;
+	this->ecc.mode = NAND_ECC_SOFT;
+
+	/* read/write functions */
+	this->read_byte = cmx270_read_byte;
+	this->read_buf = cmx270_read_buf;
+	this->write_buf = cmx270_write_buf;
+	this->verify_buf = cmx270_verify_buf;
+
+	/* Scan to find existence of the device */
+	if (nand_scan (cmx270_nand_mtd, 1)) {
+		printk(KERN_NOTICE "No NAND device\n");
+		ret = -ENXIO;
+		goto err2;
+	}
+
+#ifdef CONFIG_MTD_CMDLINE_PARTS
+	mtd_parts_nb = parse_mtd_partitions(cmx270_nand_mtd, part_probes,
+					    &mtd_parts, 0);
+	if (mtd_parts_nb > 0)
+		part_type = "command line";
+	else
+		mtd_parts_nb = 0;
+#endif
+	if (!mtd_parts_nb) {
+		mtd_parts = partition_info;
+		mtd_parts_nb = NUM_PARTITIONS;
+		part_type = "static";
+	}
+
+	/* Register the partitions */
+	printk(KERN_NOTICE "Using %s partition definition\n", part_type);
+	ret = add_mtd_partitions(cmx270_nand_mtd, mtd_parts, mtd_parts_nb);
+	if (ret)
+		goto err2;
+
+	/* Return happy */
+	return 0;
+
+err2:
+	iounmap(cmx270_nand_io);
+err1:
+	kfree(cmx270_nand_mtd);
+
+	return ret;
+
+}
+module_init(cmx270_init);
+
+/*
+ * Clean up routine
+ */
+static void __devexit cmx270_cleanup(void)
+{
+	/* Release resources, unregister device */
+	nand_release(cmx270_nand_mtd);
+
+	iounmap(cmx270_nand_io);
+
+	/* Free the MTD device structure */
+	kfree (cmx270_nand_mtd);
+}
+module_exit(cmx270_cleanup);
+
+MODULE_LICENSE("GPL");
+MODULE_AUTHOR("Mike Rapoport <mike at compulab.co.il>");
+MODULE_DESCRIPTION("NAND flash driver for Compulab CM-X270 Module");





From gclement00 at gmail.com  Tue Sep 26 04:15:23 2006
From: gclement00 at gmail.com (Gregory CLEMENT)
Date: Tue, 26 Sep 2006 10:15:23 +0200
Subject: Exporting jffs2 by nfs with kernel 2.6
In-Reply-To: <305035a40609060838s253d9810id4fd549a9f8adee6@mail.gmail.com>
References: <305035a40609060838s253d9810id4fd549a9f8adee6@mail.gmail.com>
Message-ID: <305035a40609260115ia8f04bcv94bd4c0342be4835@mail.gmail.com>

Hi all,

On 2.4.18 we managed to export a jffs2 filesystem by nfs.
Now on 2.6.16 we can't.
I found 2 problems for it:
First, changed was made in nfs, and now they test if
s_export_op is not a void pointer. By dding a pointer on
this structure (even this structure is void) makes nfs happy.
If the structure is void nfs use generic function, so for this part
I think it's ok

Second, nfs need to identify the filesystem to export. It is done
either by the device of the filesystem or by a "fsid". I didfn't see any
filesystem use a "fsid" and I don't know how to use it. So identification
is made if FS_REQUIRES_DEV is set. The problem was in kernel 2.5.7,
this flag was removed because "We never really used the block device anyway".
Do you mind setting this flag again? Or have you a better idea?

I joined my patch which make jffs2 exportable by nfs:


PS: I sent this mail 3 weeks ago to jffs-dev at axis.com before notice
that now jffs2 is discussed on this mailing-list.
--
Gregory CLEMENT
Adeneo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: jffs2_exported_by_nfs.patch
Type: text/x-patch
Size: 942 bytes
Desc: not available
Url : http://lists.infradead.org/pipermail/linux-mtd/attachments/20060926/4dd3c0f8/attachment.bin 

