linux.git/drivers/mtd/chips, branch v2.6.30

[MTD] [NOR] Fixup for Numonyx M29W128 chips

2009-04-06T14:23:26+00:00

Prevent NUMONYX M29W128G memories from using write buffer,
because it doesn't work properly.

Signed-off-by: Darius Augulis 
Signed-off-by: David Woodhouse

NOMMU: Present backing device capabilities for MTD chardevs

2009-03-24T09:00:19+00:00

Present backing device capabilities for MTD character device files to allow
NOMMU mmap to do direct mapping where possible.

Signed-off-by: David Howells 
Tested-by: Bernd Schmidt 
Signed-off-by: David Woodhouse

[MTD] [CHIPS] Add JEDEC probe support for the SST 39VF3201 flash chip

2009-03-20T18:50:26+00:00

Signed-off-by: Andrew Morton 
Signed-off-by: Yegor Yefremov 
Signed-off-by: David Woodhouse

[MTD] [CHIPS] cfi_cmdset_0001.c: Fix a bug in inval_cache_and_wait_for_operation().

2009-03-20T18:32:17+00:00

If the inval_cache_and_wait_for_operation() is re-entered by write operation when erase
operation is in progress, the chip->erase_suspended will be cleared, this cause the erase
timeo is not reset and will result time out error for erase.

Signed-off-by: Graff Yang 
Signed-off-by: David Woodhouse

[MTD] map_rom has NULL erase pointer

2009-01-11T19:56:46+00:00

Which means if inftl or similar are loaded with it (which is a dumb thing
to do admittedly) it may oops.

Closes #8108

[dwmw2: change error to -EROFS to match write-protected flash]
Signed-off-by: Alan Cox 
Signed-off-by: David Woodhouse

[MTD] CFI: remove major/minor version check for command set 0x0002

2009-01-09T12:16:28+00:00

The NOR Flash memory K8P2815UQB from Samsung uses the major version
number '0'. Add a quirk to cope with it.

Signed-off-by: Wolfgang Grandegger 
Signed-off-by: David Woodhouse

[MTD] update internal API to support 64-bit device size

2008-12-10T13:37:21+00:00

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 
Signed-off-by: Artem Bityutskiy 
Signed-off-by: David Woodhouse

[MTD] [NOR] Fix cfi_send_gen_cmd handling of x16 devices in x8 mode (v4)

2008-11-05T13:40:25+00:00

For "unlock" cycles to 16bit devices in 8bit compatibility mode we need
to use the byte addresses 0xaaa and 0x555. These effectively match
the word address 0x555 and 0x2aa, except the latter has its low bit set.

Most chips don't care about the value of the 'A-1' pin in x8 mode,
but some -- like the ST M29W320D -- do. So we need to be careful to
set it where appropriate.

cfi_send_gen_cmd is only ever passed addresses where the low byte
is 0x00, 0x55 or 0xaa. Of those, only addresses ending 0xaa are
affected by this patch, by masking in the extra low bit when the device
is known to be in compatibility mode.

[dwmw2: Do it only when (cmd_ofs & 0xff) == 0xaa]
v4: Fix  stupid typo in cfi_build_cmd_addr that failed to compile
    I'm writing this patch way to late at night.
v3: Bring all of the work back into cfi_build_cmd_addr
    including calling of map_bankwidth(map) and cfi_interleave(cfi)
    So every caller doesn't need to.
v2: Only modified the address if we our device_type is larger than our
    bus width.

Cc: stable@kernel.org
Signed-off-by: Eric W. Biederman 
Signed-off-by: David Woodhouse

[MTD] [NOR] AT49BV6416 has swapped erase regions

2008-10-18T11:53:15+00:00

The CFI information read from AT49BV6416 lists the erase regions in the
wrong order, causing problems when trying to erase or update the first
or last 64KiB block.

Work around this by inverting the "top boot" flag, which will
effectively reverse the order of the erase regions.

This chip is obsolete, but it's used in some existing designs.

Signed-off-by: Håvard Skinnemoen 
Signed-off-by: David Woodhouse

[MTD] cfi_cmdset_0002.c: Add Macronix CFI V1.0 TopBottom detection

2008-10-18T11:41:51+00:00

This patch adds TopBottom detection for most Macronix chips with CFI V1.0.

The main purpose of this patch is to add detection of the MX29LV400C B
used on the LaCie Ethernet Disk mini V2 NAS.

It detects the following parts correctly:-
MX28F640C3B T
MX29LV002C  B
MX29LV002NC B
MX29LV004C  T
MX29LV400C  T/B
MX29LV800C  T/B
MX29LV160C  T/B
MX29SL800C  T/B
MX29SL802C  T/B

It detects the following uniform part as bottom but it should work
correctly:-
MX29LV040C

For T parts it causes the erase block table to be reversed correctly.
For other parts it avoids the bogus "Assuming top" message.

It does not detect the following correctly:-
MX28F640C3B B
MX29LV002C  T
MX29LV002NC T
MX29LV004C  B
MX29SL400C  T/B
MX29SL402C  T/B

If desired I could supply a more complicated patch to handle these as
well.

Only the MX29LV400C B has been physically tested; others were checked
against their data sheets.

Signed-off-by: Christopher Moore 
Signed-off-by: David Woodhouse