From a66f66c44d53a4bab4b6b2903fd271f13ce4101b Mon Sep 17 00:00:00 2001 From: Jesper Nilsson Date: Tue, 6 Nov 2007 08:40:24 +0000 Subject: [MTD] Provide mtdram.h with mtdram_init_device() prototype This is used by axisflashmap.c to boot from ram. Signed-off-by: Jesper Nilsson Acked-by: Mikael Starvik Signed-off-by: Andrew Morton Signed-off-by: David Woodhouse --- include/linux/mtd/mtdram.h | 8 ++++++++ 1 file changed, 8 insertions(+) create mode 100644 include/linux/mtd/mtdram.h (limited to 'include') diff --git a/include/linux/mtd/mtdram.h b/include/linux/mtd/mtdram.h new file mode 100644 index 00000000000..04fdc07b735 --- /dev/null +++ b/include/linux/mtd/mtdram.h @@ -0,0 +1,8 @@ +#ifndef __MTD_MTDRAM_H__ +#define __MTD_MTDRAM_H__ + +#include +int mtdram_init_device(struct mtd_info *mtd, void *mapped_address, + unsigned long size, char *name); + +#endif /* __MTD_MTDRAM_H__ */ -- cgit v1.2.3 From 393852ecfeec575ac78216b0eb58e4fd92f0816c Mon Sep 17 00:00:00 2001 From: Artem Bityutskiy Date: Thu, 6 Dec 2007 18:47:30 +0200 Subject: UBI: add ubi_leb_map interface The idea of this interface belongs to Adrian Hunter. The interface is extremely useful when one has to have a guarantee that an LEB will contain all 0xFFs even in case of an unclean reboot. UBI does have an 'ubi_leb_erase()' call which may do this, but it is stupid and ineffecient, because it flushes whole queue. I should be re-worked to just be a pair of unmap, map calls. The user of the interfaci is UBIFS at the moment. Signed-off-by: Artem Bityutskiy --- include/linux/mtd/ubi.h | 1 + 1 file changed, 1 insertion(+) (limited to 'include') diff --git a/include/linux/mtd/ubi.h b/include/linux/mtd/ubi.h index 3d967b6b120..c4abe035122 100644 --- a/include/linux/mtd/ubi.h +++ b/include/linux/mtd/ubi.h @@ -167,6 +167,7 @@ int ubi_leb_change(struct ubi_volume_desc *desc, int lnum, const void *buf, int len, int dtype); int ubi_leb_erase(struct ubi_volume_desc *desc, int lnum); int ubi_leb_unmap(struct ubi_volume_desc *desc, int lnum); +int ubi_leb_map(struct ubi_volume_desc *desc, int lnum, int dtype); int ubi_is_mapped(struct ubi_volume_desc *desc, int lnum); /* -- cgit v1.2.3 From 9b79cc0f84edecceb04b806b9014fcec1306c34d Mon Sep 17 00:00:00 2001 From: Artem Bityutskiy Date: Tue, 18 Dec 2007 18:22:16 +0200 Subject: UBI: introduce attach ioctls Signed-off-by: Artem Bityutskiy --- include/mtd/ubi-user.h | 80 +++++++++++++++++++++++++++++++++++++++++++++----- 1 file changed, 72 insertions(+), 8 deletions(-) (limited to 'include') diff --git a/include/mtd/ubi-user.h b/include/mtd/ubi-user.h index fe06ded0e6b..4d184a7f80a 100644 --- a/include/mtd/ubi-user.h +++ b/include/mtd/ubi-user.h @@ -22,6 +22,21 @@ #define __UBI_USER_H__ /* + * UBI device creation (the same as MTD device attachment) + * ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + * + * MTD devices may be attached using %UBI_IOCATT ioctl command of the UBI + * control device. The caller has to properly fill and pass + * &struct ubi_attach_req object - UBI will attach the MTD device specified in + * the request and return the newly created UBI device number as the ioctl + * return value. + * + * UBI device deletion (the same as MTD device detachment) + * ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + * + * An UBI device maybe deleted with %UBI_IOCDET ioctl command of the UBI + * control device. + * * UBI volume creation * ~~~~~~~~~~~~~~~~~~~ * @@ -60,11 +75,12 @@ */ /* - * When a new volume is created, users may either specify the volume number they - * want to create or to let UBI automatically assign a volume number using this - * constant. + * When a new UBI volume or UBI device is created, users may either specify the + * volume/device number they want to create or to let UBI automatically assign + * the number using these constants. */ #define UBI_VOL_NUM_AUTO (-1) +#define UBI_DEV_NUM_AUTO (-1) /* Maximum volume name length */ #define UBI_MAX_VOLUME_NAME 127 @@ -80,6 +96,15 @@ /* Re-size an UBI volume */ #define UBI_IOCRSVOL _IOW(UBI_IOC_MAGIC, 2, struct ubi_rsvol_req) +/* IOCTL commands of the UBI control character device */ + +#define UBI_CTRL_IOC_MAGIC 'o' + +/* Attach an MTD device */ +#define UBI_IOCATT _IOW(UBI_CTRL_IOC_MAGIC, 64, struct ubi_attach_req) +/* Detach an MTD device */ +#define UBI_IOCDET _IOW(UBI_CTRL_IOC_MAGIC, 65, int32_t) + /* IOCTL commands of UBI volume character devices */ #define UBI_VOL_IOC_MAGIC 'O' @@ -89,6 +114,9 @@ /* An eraseblock erasure command, used for debugging, disabled by default */ #define UBI_IOCEBER _IOW(UBI_VOL_IOC_MAGIC, 1, int32_t) +/* Maximum MTD device name length supported by UBI */ +#define MAX_UBI_MTD_NAME_LEN 127 + /* * UBI volume type constants. * @@ -97,19 +125,55 @@ */ enum { UBI_DYNAMIC_VOLUME = 3, - UBI_STATIC_VOLUME = 4 + UBI_STATIC_VOLUME = 4, +}; + +/** + * struct ubi_attach_req - attach MTD device request. + * @ubi_num: UBI device number to create + * @mtd_num: MTD device number to attach + * @vid_hdr_offset: VID header offset (use defaults if %0) + * @padding: reserved for future, not used, has to be zeroed + * + * This data structure is used to specify MTD device UBI has to attach and the + * parameters it has to use. The number which should be assigned to the new UBI + * device is passed in @ubi_num. UBI may automatically assing the number if + * @UBI_DEV_NUM_AUTO is passed. In this case, the device number is returned in + * @ubi_num. + * + * Most applications should pass %0 in @vid_hdr_offset to make UBI use default + * offset of the VID header within physical eraseblocks. The default offset is + * the next min. I/O unit after the EC header. For example, it will be offset + * 512 in case of a 512 bytes page NAND flash with no sub-page support. Or + * it will be 512 in case of a 2KiB page NAND flash with 4 512-byte sub-pages. + * + * But in rare cases, if this optimizes things, the VID header may be placed to + * a different offset. For example, the boot-loader might do things faster if the + * VID header sits at the end of the first 2KiB NAND page with 4 sub-pages. As + * the boot-loader would not normally need to read EC headers (unless it needs + * UBI in RW mode), it might be faster to calculate ECC. This is weird example, + * but it real-life example. So, in this example, @vid_hdr_offer would be + * 2KiB-64 bytes = 1984. Note, that this position is not even 512-bytes + * aligned, which is OK, as UBI is clever enough to realize this is 4th sub-page + * of the first page and add needed padding. + */ +struct ubi_attach_req { + int32_t ubi_num; + int32_t mtd_num; + int32_t vid_hdr_offset; + uint8_t padding[12]; }; /** * struct ubi_mkvol_req - volume description data structure used in - * volume creation requests. + * volume creation requests. * @vol_id: volume number * @alignment: volume alignment * @bytes: volume size in bytes * @vol_type: volume type (%UBI_DYNAMIC_VOLUME or %UBI_STATIC_VOLUME) - * @padding1: reserved for future, not used + * @padding1: reserved for future, not used, has to be zeroed * @name_len: volume name length - * @padding2: reserved for future, not used + * @padding2: reserved for future, not used, has to be zeroed * @name: volume name * * This structure is used by userspace programs when creating new volumes. The @@ -139,7 +203,7 @@ struct ubi_mkvol_req { int8_t padding1; int16_t name_len; int8_t padding2[4]; - char name[UBI_MAX_VOLUME_NAME+1]; + char name[UBI_MAX_VOLUME_NAME + 1]; } __attribute__ ((packed)); /** -- cgit v1.2.3 From de7921f01a407e0cb38143363995db89a5f9a5c5 Mon Sep 17 00:00:00 2001 From: Bartlomiej Sieka Date: Mon, 26 Nov 2007 18:55:18 +0100 Subject: [MTD] [NOR] Fix incorrect interface code for x16/x32 chips According to "Common Flash Memory Interface Publication 100" dated December 1, 2001, the interface code for x16/x32 chips is 0x0005, and not 0x0004 used so far. Signed-off-by: Bartlomiej Sieka Signed-off-by: David Woodhouse --- include/linux/mtd/cfi.h | 12 ++++++++++++ 1 file changed, 12 insertions(+) (limited to 'include') diff --git a/include/linux/mtd/cfi.h b/include/linux/mtd/cfi.h index e17c5343cf5..b0ddf4b2586 100644 --- a/include/linux/mtd/cfi.h +++ b/include/linux/mtd/cfi.h @@ -98,6 +98,18 @@ static inline int cfi_interleave_supported(int i) #define CFI_DEVICETYPE_X32 (32 / 8) #define CFI_DEVICETYPE_X64 (64 / 8) + +/* Device Interface Code Assignments from the "Common Flash Memory Interface + * Publication 100" dated December 1, 2001. + */ +#define CFI_INTERFACE_X8_ASYNC 0x0000 +#define CFI_INTERFACE_X16_ASYNC 0x0001 +#define CFI_INTERFACE_X8_BY_X16_ASYNC 0x0002 +#define CFI_INTERFACE_X32_ASYNC 0x0003 +#define CFI_INTERFACE_X16_BY_X32_ASYNC 0x0005 +#define CFI_INTERFACE_NOT_ALLOWED 0xffff + + /* NB: We keep these structures in memory in HOST byteorder, except * where individually noted. */ -- cgit v1.2.3 From 4ccf8cffa963c7b5bdc6d455ea9417084ee49aa8 Mon Sep 17 00:00:00 2001 From: Artem Bityutskiy Date: Wed, 16 Jan 2008 15:44:24 +0200 Subject: UBI: add auto-resize feature The problem: NAND flashes have different amount of initial bad physical eraseblocks (marked as bad by the manufacturer). For example, for 256MiB Samsung OneNAND flash there might be from 0 to 40 bad initial eraseblocks, which is about 2%. When UBI is used as the base system, one needs to know the exact amount of good physical eraseblocks, because this number is needed to create the UBI image which is put to the devices during production. But this number is not know, which forces us to use the minimum number of good physical eraseblocks. And UBI additionally reserves some percentage of physical eraseblocks for bad block handling (default is 1%), so we have 1-3% of PEBs reserved at the end, depending on the amount of initial bad PEBs. But it is desired to always have 1% (or more, depending on the configuration). Solution: this patch adds an "auto-resize" flag to the volume table. The volume which has the "auto-resize" flag will automatically be re-sized (enlarged) on the first UBI initialization. UBI clears the flag when the volume is re-sized. Only one volume may have the "auto-resize" flag. So, the production UBI image may have one volume with "auto-resize" flag set, and its size is automatically adjusted on the first boot of the device. Signed-off-by: Artem Bityutskiy --- include/mtd/ubi-header.h | 43 +++++++++++++++++++++++++++++++++++++++++-- 1 file changed, 41 insertions(+), 2 deletions(-) (limited to 'include') diff --git a/include/mtd/ubi-header.h b/include/mtd/ubi-header.h index 74efa776347..69d5d7e2289 100644 --- a/include/mtd/ubi-header.h +++ b/include/mtd/ubi-header.h @@ -57,6 +57,43 @@ enum { UBI_VID_STATIC = 2 }; +/* + * Volume flags used in the volume table record. + * + * @UBI_VTBL_AUTORESIZE_FLG: auto-resize this volume + * + * %UBI_VTBL_AUTORESIZE_FLG flag can be set only for one volume in the volume + * table. UBI automatically re-sizes the volume which has this flag and makes + * the volume to be of largest possible size. This means that if after the + * initialization UBI finds out that there are available physical eraseblocks + * present on the device, it automatically appends all of them to the volume + * (the physical eraseblocks reserved for bad eraseblocks handling and other + * reserved physical eraseblocks are not taken). So, if there is a volume with + * the %UBI_VTBL_AUTORESIZE_FLG flag set, the amount of available logical + * eraseblocks will be zero after UBI is loaded, because all of them will be + * reserved for this volume. Note, the %UBI_VTBL_AUTORESIZE_FLG bit is cleared + * after the volume had been initialized. + * + * The auto-resize feature is useful for device production purposes. For + * example, different NAND flash chips may have different amount of initial bad + * eraseblocks, depending of particular chip instance. Manufacturers of NAND + * chips usually guarantee that the amount of initial bad eraseblocks does not + * exceed certain percent, e.g. 2%. When one creates an UBI image which will be + * flashed to the end devices in production, he does not know the exact amount + * of good physical eraseblocks the NAND chip on the device will have, but this + * number is required to calculate the volume sized and put them to the volume + * table of the UBI image. In this case, one of the volumes (e.g., the one + * which will store the root file system) is marked as "auto-resizable", and + * UBI will adjust its size on the first boot if needed. + * + * Note, first UBI reserves some amount of physical eraseblocks for bad + * eraseblock handling, and then re-sizes the volume, not vice-versa. This + * means that the pool of reserved physical eraseblocks will always be present. + */ +enum { + UBI_VTBL_AUTORESIZE_FLG = 0x01, +}; + /* * Compatibility constants used by internal volumes. * @@ -289,7 +326,8 @@ struct ubi_vid_hdr { * @upd_marker: if volume update was started but not finished * @name_len: volume name length * @name: the volume name - * @padding2: reserved, zeroes + * @flags: volume flags (%UBI_VTBL_AUTORESIZE_FLG) + * @padding: reserved, zeroes * @crc: a CRC32 checksum of the record * * The volume table records are stored in the volume table, which is stored in @@ -324,7 +362,8 @@ struct ubi_vtbl_record { __u8 upd_marker; __be16 name_len; __u8 name[UBI_VOL_NAME_MAX+1]; - __u8 padding2[24]; + __u8 flags; + __u8 padding[23]; __be32 crc; } __attribute__ ((packed)); -- cgit v1.2.3 From 91f2d53cd75a8fa3557246af965155208c4c69a7 Mon Sep 17 00:00:00 2001 From: Artem Bityutskiy Date: Thu, 24 Jan 2008 11:23:23 +0200 Subject: UBI: add layout volume information Add more information about layout volume to make userspace tools use the macros instead of constants. Also rename UBI_LAYOUT_VOL_ID to make it consistent with other macros. Signed-off-by: Artem Bityutskiy --- include/mtd/ubi-header.h | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) (limited to 'include') diff --git a/include/mtd/ubi-header.h b/include/mtd/ubi-header.h index 69d5d7e2289..292f916ea56 100644 --- a/include/mtd/ubi-header.h +++ b/include/mtd/ubi-header.h @@ -299,7 +299,9 @@ struct ubi_vid_hdr { /* The layout volume contains the volume table */ -#define UBI_LAYOUT_VOL_ID UBI_INTERNAL_VOL_START +#define UBI_LAYOUT_VOLUME_ID UBI_INTERNAL_VOL_START +#define UBI_LAYOUT_VOLUME_TYPE UBI_VID_DYNAMIC +#define UBI_LAYOUT_VOLUME_ALIGN 1 #define UBI_LAYOUT_VOLUME_EBS 2 #define UBI_LAYOUT_VOLUME_NAME "layout volume" #define UBI_LAYOUT_VOLUME_COMPAT UBI_COMPAT_REJECT -- cgit v1.2.3 From 866136827b9a71c39dcb06d23ce523f719eab74b Mon Sep 17 00:00:00 2001 From: Artem Bityutskiy Date: Thu, 24 Jan 2008 16:15:14 +0200 Subject: UBI: introduce atomic LEB change ioctl We have to be able to change individual LEBs for utilities like ubifsck, ubifstune. For example, ubifsck has to be able to fix errors on the media, ubifstune has to be able to change the the superblock, hence this ioctl. Signed-off-by: Artem Bityutskiy --- include/linux/mtd/ubi.h | 17 ----------------- include/mtd/ubi-user.h | 51 +++++++++++++++++++++++++++++++++++++++++++++---- 2 files changed, 47 insertions(+), 21 deletions(-) (limited to 'include') diff --git a/include/linux/mtd/ubi.h b/include/linux/mtd/ubi.h index c4abe035122..f71201d0f3e 100644 --- a/include/linux/mtd/ubi.h +++ b/include/linux/mtd/ubi.h @@ -25,23 +25,6 @@ #include #include -/* - * UBI data type hint constants. - * - * UBI_LONGTERM: long-term data - * UBI_SHORTTERM: short-term data - * UBI_UNKNOWN: data persistence is unknown - * - * These constants are used when data is written to UBI volumes in order to - * help the UBI wear-leveling unit to find more appropriate physical - * eraseblocks. - */ -enum { - UBI_LONGTERM = 1, - UBI_SHORTTERM, - UBI_UNKNOWN -}; - /* * enum ubi_open_mode - UBI volume open mode constants. * diff --git a/include/mtd/ubi-user.h b/include/mtd/ubi-user.h index 4d184a7f80a..a7421f130cc 100644 --- a/include/mtd/ubi-user.h +++ b/include/mtd/ubi-user.h @@ -63,7 +63,7 @@ * * Volume update should be done via the %UBI_IOCVOLUP IOCTL command of the * corresponding UBI volume character device. A pointer to a 64-bit update - * size should be passed to the IOCTL. After then, UBI expects user to write + * size should be passed to the IOCTL. After this, UBI expects user to write * this number of bytes to the volume character device. The update is finished * when the claimed number of bytes is passed. So, the volume update sequence * is something like: @@ -72,6 +72,15 @@ * ioctl(fd, UBI_IOCVOLUP, &image_size); * write(fd, buf, image_size); * close(fd); + * + * Atomic eraseblock change + * ~~~~~~~~~~~~~~~~~~~~~~~~ + * + * Atomic eraseblock change operation is done via the %UBI_IOCEBCH IOCTL + * command of the corresponding UBI volume character device. A pointer to + * &struct ubi_leb_change_req has to be passed to the IOCTL. Then the user is + * expected to write the requested amount of bytes. This is similar to the + * "volume update" IOCTL. */ /* @@ -113,10 +122,29 @@ #define UBI_IOCVOLUP _IOW(UBI_VOL_IOC_MAGIC, 0, int64_t) /* An eraseblock erasure command, used for debugging, disabled by default */ #define UBI_IOCEBER _IOW(UBI_VOL_IOC_MAGIC, 1, int32_t) +/* An atomic eraseblock change command */ +#define UBI_IOCEBCH _IOW(UBI_VOL_IOC_MAGIC, 2, int32_t) /* Maximum MTD device name length supported by UBI */ #define MAX_UBI_MTD_NAME_LEN 127 +/* + * UBI data type hint constants. + * + * UBI_LONGTERM: long-term data + * UBI_SHORTTERM: short-term data + * UBI_UNKNOWN: data persistence is unknown + * + * These constants are used when data is written to UBI volumes in order to + * help the UBI wear-leveling unit to find more appropriate physical + * eraseblocks. + */ +enum { + UBI_LONGTERM = 1, + UBI_SHORTTERM = 2, + UBI_UNKNOWN = 3, +}; + /* * UBI volume type constants. * @@ -125,7 +153,7 @@ */ enum { UBI_DYNAMIC_VOLUME = 3, - UBI_STATIC_VOLUME = 4, + UBI_STATIC_VOLUME = 4, }; /** @@ -137,7 +165,7 @@ enum { * * This data structure is used to specify MTD device UBI has to attach and the * parameters it has to use. The number which should be assigned to the new UBI - * device is passed in @ubi_num. UBI may automatically assing the number if + * device is passed in @ubi_num. UBI may automatically assign the number if * @UBI_DEV_NUM_AUTO is passed. In this case, the device number is returned in * @ubi_num. * @@ -176,7 +204,7 @@ struct ubi_attach_req { * @padding2: reserved for future, not used, has to be zeroed * @name: volume name * - * This structure is used by userspace programs when creating new volumes. The + * This structure is used by user-space programs when creating new volumes. The * @used_bytes field is only necessary when creating static volumes. * * The @alignment field specifies the required alignment of the volume logical @@ -222,4 +250,19 @@ struct ubi_rsvol_req { int32_t vol_id; } __attribute__ ((packed)); +/** + * struct ubi_leb_change_req - a data structure used in atomic logical + * eraseblock change requests. + * @lnum: logical eraseblock number to change + * @bytes: how many bytes will be written to the logical eraseblock + * @dtype: data type (%UBI_LONGTERM, %UBI_SHORTTERM, %UBI_UNKNOWN) + * @padding: reserved for future, not used, has to be zeroed + */ +struct ubi_leb_change_req { + int32_t lnum; + int32_t bytes; + uint8_t dtype; + uint8_t padding[7]; +} __attribute__ ((packed)); + #endif /* __UBI_USER_H__ */ -- cgit v1.2.3 From e71f04fc9234b14636887ceb5862755f1690642c Mon Sep 17 00:00:00 2001 From: Kyungmin Park Date: Tue, 11 Dec 2007 11:23:45 +0900 Subject: [MTD] [OneNAND] Get correct density from device ID Use the higher bits for other purpose. Signed-off-by: Kyungmin Park --- include/linux/mtd/onenand_regs.h | 1 + 1 file changed, 1 insertion(+) (limited to 'include') diff --git a/include/linux/mtd/onenand_regs.h b/include/linux/mtd/onenand_regs.h index c46161f4eee..d1b310c92eb 100644 --- a/include/linux/mtd/onenand_regs.h +++ b/include/linux/mtd/onenand_regs.h @@ -67,6 +67,7 @@ /* * Device ID Register F001h (R) */ +#define ONENAND_DEVICE_DENSITY_MASK (0xf) #define ONENAND_DEVICE_DENSITY_SHIFT (4) #define ONENAND_DEVICE_IS_DDP (1 << 3) #define ONENAND_DEVICE_IS_DEMUX (1 << 2) -- cgit v1.2.3 From 9a310d21196f38f6ad0ad146057548653e495c09 Mon Sep 17 00:00:00 2001 From: Scott Wood Date: Tue, 15 Jan 2008 17:54:43 -0600 Subject: [MTD] Factor out OF partition support from the NOR driver. Signed-off-by: Scott Wood Signed-off-by: David Woodhouse --- include/linux/mtd/partitions.h | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-) (limited to 'include') diff --git a/include/linux/mtd/partitions.h b/include/linux/mtd/partitions.h index da6b3d6f12a..7c37d7e55ab 100644 --- a/include/linux/mtd/partitions.h +++ b/include/linux/mtd/partitions.h @@ -71,5 +71,12 @@ extern int parse_mtd_partitions(struct mtd_info *master, const char **types, #define put_partition_parser(p) do { module_put((p)->owner); } while(0) -#endif +struct device; +struct device_node; + +int __devinit of_mtd_parse_partitions(struct device *dev, + struct mtd_info *mtd, + struct device_node *node, + struct mtd_partition **pparts); +#endif -- cgit v1.2.3 From e619a75ff6201b567a539e787aa9af9bc63a3187 Mon Sep 17 00:00:00 2001 From: Justin Treon Date: Wed, 30 Jan 2008 10:25:49 -0800 Subject: [MTD] Unlocking all Intel flash that is locked on power up. Patch for unlocking all Intel flash that has instant locking on power up. The patch has been tested on Intel M18, P30 and J3D Strata Flash. 1. The automatic unlocking can be disabled for a particular partition in the map or the command line. a. For the bit mask in the map it should look like: .mask_flags = MTD_POWERUP_LOCK, b. For the command line parsing it should look like: mtdparts=0x80000(bootloader)lk 2. This will only unlock parts with instant individual block locking. Intel parts with legacy unlocking will not be unlocked. Signed-off-by: Justin Treon Signed-off-by: Jared Hulbert Acked-by: Nicolas Pitre Signed-off-by: David Woodhouse --- include/mtd/mtd-abi.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'include') diff --git a/include/mtd/mtd-abi.h b/include/mtd/mtd-abi.h index f71dac42039..615072c4da0 100644 --- a/include/mtd/mtd-abi.h +++ b/include/mtd/mtd-abi.h @@ -29,7 +29,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 */ +#define MTD_POWERUP_LOCK 0x2000 /* Always locked after reset */ // Some common devices / combinations of capabilities #define MTD_CAP_ROM 0 -- cgit v1.2.3 From 388bbb09b991c792310af2f6b49f6c55edb3dff0 Mon Sep 17 00:00:00 2001 From: Richard Purdie Date: Wed, 6 Feb 2008 10:17:15 +0000 Subject: [MTD] Add mtd panic_write function pointer MTDs are well suited for logging critical data and the mtdoops driver allows kernel panics/oops to be written to flash in a blackbox flight recorder fashion allowing better debugging and analysis of crashes. Any kernel oops in user context can be easily handled since the kernel continues as normal and any queued mtd writes are scheduled. Any kernel oops in interrupt context results in a panic and the delayed writes will not be scheduled however. The existing mtd->write function cannot be called in interrupt context so these messages can never be written to flash. This patch adds a panic_write function pointer that drivers can optionally implement which can be called in interrupt context. It is only intended to be called when its known the kernel is about to panic and we need to write to succeed. Since the kernel is not going to be running for much longer, this function can break locks and delay to ensure the write succeeds (but not sleep). Signed-off-by: Richard Purdie Signed-off-by: David Woodhouse --- include/linux/mtd/mtd.h | 9 +++++++++ 1 file changed, 9 insertions(+) (limited to 'include') diff --git a/include/linux/mtd/mtd.h b/include/linux/mtd/mtd.h index 783fc983417..0a13bb35f04 100644 --- a/include/linux/mtd/mtd.h +++ b/include/linux/mtd/mtd.h @@ -152,6 +152,15 @@ struct mtd_info { 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); + /* In blackbox flight recorder like scenarios we want to make successful + writes in interrupt context. panic_write() is only intended to be + called when its known the kernel is about to panic and we need the + write to succeed. Since the kernel is not going to be running for much + longer, this function can break locks and delay to ensure the write + succeeds (but not sleep). */ + + int (*panic_write) (struct mtd_info *mtd, loff_t to, size_t len, size_t *retlen, const u_char *buf); + int (*read_oob) (struct mtd_info *mtd, loff_t from, struct mtd_oob_ops *ops); int (*write_oob) (struct mtd_info *mtd, loff_t to, -- cgit v1.2.3