linux-stable.git/include/linux/mtd/partitions.h, branch linux-2.6.29.y Linux kernel stable tree [MTD] Remove more strange u_intxx_t types 2008-12-10T14:08:56+00:00 David Woodhouse David.Woodhouse@intel.com 2008-12-10T14:08:12+00:00 26cdb67c74aedc22367e6d0271f7f955220cca65 Signed-off-by: David Woodhouse <David.Woodhouse@intel.com> 
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
[MTD] update internal API to support 64-bit device size 2008-12-10T13:37:21+00:00 Adrian Hunter ext-adrian.hunter@nokia.com 2008-12-10T13:37:21+00:00 69423d99fc182a81f3c5db3eb5c140acc6fc64be MTD internal API presently uses 32-bit values to represent device size. This patch updates them to 64-bits but leaves the external API unchanged. Extending the external API is a separate issue for several reasons. First, no one needs it at the moment. Secondly, whether the implementation is done with IOCTLs, sysfs or both is still debated. Thirdly external API changes require the internal API to be accepted first. Note that although the MTD API will be able to support 64-bit device sizes, existing drivers do not and are not required to do so, although NAND base has been updated. In general, changing from 32-bit to 64-bit values cause little or no changes to the majority of the code with the following exceptions: - printk message formats - division and modulus of 64-bit values - NAND base support - 32-bit local variables used by mtdpart and mtdconcat - naughtily assuming one structure maps to another in MEMERASE ioctl Signed-off-by: Adrian Hunter <ext-adrian.hunter@nokia.com> Signed-off-by: Artem Bityutskiy <Artem.Bityutskiy@nokia.com> Signed-off-by: David Woodhouse <David.Woodhouse@intel.com> 
MTD internal API presently uses 32-bit values to represent
device size.  This patch updates them to 64-bits but leaves
the external API unchanged.  Extending the external API
is a separate issue for several reasons.  First, no one
needs it at the moment.  Secondly, whether the implementation
is done with IOCTLs, sysfs or both is still debated.  Thirdly
external API changes require the internal API to be accepted
first.

Note that although the MTD API will be able to support 64-bit
device sizes, existing drivers do not and are not required
to do so, although NAND base has been updated.

In general, changing from 32-bit to 64-bit values cause little
or no changes to the majority of the code with the following
exceptions:
    	- printk message formats
    	- division and modulus of 64-bit values
    	- NAND base support
	- 32-bit local variables used by mtdpart and mtdconcat
	- naughtily assuming one structure maps to another
	in MEMERASE ioctl

Signed-off-by: Adrian Hunter <ext-adrian.hunter@nokia.com>
Signed-off-by: Artem Bityutskiy <Artem.Bityutskiy@nokia.com>
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
[MTD] remove unused mtd parameter in of_mtd_parse_partitions() 2008-10-13T14:01:42+00:00 Sebastian Andrzej Siewior bigeasy@linutronix.de 2008-10-12T14:18:36+00:00 69fd3a8d098faf41a04930afa83757c0555ee360 Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Signed-off-by: David Woodhouse <David.Woodhouse@intel.com> 
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
MTD/JFFS2: remove CVS keywords 2008-06-04T16:50:17+00:00 Adrian Bunk bunk@kernel.org 2008-05-19T22:03:52+00:00 59018b6d2acabb114ab58637e6ab95ba424a89d0 Once upon a time, the MTD repository was using CVS. This patch therefore removes all usages of the no longer updated CVS keywords from the MTD code. This also includes code that printed them to the user. Signed-off-by: Adrian Bunk <bunk@kernel.org> Signed-off-by: David Woodhouse <dwmw2@infradead.org> 
Once upon a time, the MTD repository was using CVS.

This patch therefore removes all usages of the no longer updated CVS
keywords from the MTD code.

This also includes code that printed them to the user.

Signed-off-by: Adrian Bunk <bunk@kernel.org>
Signed-off-by: David Woodhouse <dwmw2@infradead.org>
[MTD] Factor out OF partition support from the NOR driver. 2008-02-03T07:06:48+00:00 Scott Wood scottwood@freescale.com 2008-01-15T23:54:43+00:00 9a310d21196f38f6ad0ad146057548653e495c09 Signed-off-by: Scott Wood <scottwood@freescale.com> Signed-off-by: David Woodhouse <dwmw2@infradead.org> 
Signed-off-by: Scott Wood <scottwood@freescale.com>
Signed-off-by: David Woodhouse <dwmw2@infradead.org>
[MTD] NAND Replace oobinfo by ecclayout 2006-05-29T13:06:50+00:00 Thomas Gleixner tglx@cruncher.tec.linutronix.de 2006-05-27T20:16:10+00:00 5bd34c091a044d130601370c370f84b1c59f1627 The nand_oobinfo structure is not fitting the newer error correction demands anymore. Replace it by struct nand_ecclayout and fixup the users all over the place. Keep the nand_oobinfo based ioctl for user space compability reasons. Signed-off-by: Thomas Gleixner <tglx@linutronix.de> 
The nand_oobinfo structure is not fitting the newer error correction
demands anymore. Replace it by struct nand_ecclayout and fixup the users
all over the place. Keep the nand_oobinfo based ioctl for user space
compability reasons.

Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
[MTD] includes: Clean up trailing white spaces 2005-11-07T13:32:58+00:00 Thomas Gleixner tglx@linutronix.de 2005-11-07T11:15:31+00:00 61ecfa8777d0bc8e33dc0e5c2cca9b3247da2d37 Signed-off-by: Thomas Gleixner <tglx@linutronix.de> 
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Linux-2.6.12-rc2 2005-04-16T22:20:36+00:00 Linus Torvalds torvalds@ppc970.osdl.org 2005-04-16T22:20:36+00:00 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip! 
Initial git repository build. I'm not bothering with the full history,
even though we have it. We can create a separate "historical" git
archive of that later if we want to, and in the meantime it's about
3.2GB when imported into git - space that would just make the early
git days unnecessarily complicated, when we don't have a lot of good
infrastructure for it.

Let it rip!