linux-toradex.git/drivers/mtd/chips/fwh_lock.h, branch tegra-9.12.13 Linux kernel for Apalis and Colibri modules [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] Fix fwh_lock locking 2007-04-17T18:11:20+00:00 Shashi Rao shashi@sun.com 2007-03-28T22:56:28+00:00 e6be133b68ae2c8f89d46da25ed7b31b84793e7e This is on a custom board with a mapping driver access to an ST M50LPW080 chip. This chip is probed successfully with do_map_probe("jedec_probe",...). If I use the mtdchar interface to perform unlock->erase->program->lock on any of the 16 eraseblocks in the chip, the chip is left in FL_STATUS mode while the data structures believe that the chip is in FL_READY mode. Hence, any subsequent reads to any flash byte results in 0x80 being read. Signed-off-by: Shashi Rao <shashi@sun.com> Signed-off-by: David Woodhouse <dwmw2@infradead.org> 
This is on a custom board with a mapping driver access to an ST
M50LPW080 chip. This chip is probed successfully with
do_map_probe("jedec_probe",...). If I use the mtdchar interface to
perform unlock->erase->program->lock on any of the 16 eraseblocks in the
chip, the chip is left in FL_STATUS mode while the data structures
believe that the chip is in FL_READY mode. Hence, any subsequent reads
to any flash byte results in 0x80 being read.

Signed-off-by: Shashi Rao <shashi@sun.com>
Signed-off-by: David Woodhouse <dwmw2@infradead.org>
[MTD] chips: Clean up trailing white spaces 2005-11-07T13:45:15+00:00 Thomas Gleixner tglx@linutronix.de 2005-11-07T11:15:37+00:00 1f948b43f7b5cf721cf0d03f507843efc1a9bfad Signed-off-by: Thomas Gleixner <tglx@linutronix.de> 
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
[MTD] XIP for AMD CFI flash. 2005-06-29T12:18:40+00:00 Todd Poynor tpoynor@mvista.com 2005-06-06T23:04:39+00:00 02b15e343aeefb49f8cac949be599d78250a568f Author: Vitaly Wool <vwool@ru.mvista.com> Signed-off-by: Todd Poynor <tpoynor@mvista.com> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> 
Author: Vitaly Wool <vwool@ru.mvista.com>
Signed-off-by: Todd Poynor <tpoynor@mvista.com>
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!