From 70d38b9625edba52a809308427f78831c3963f52 Mon Sep 17 00:00:00 2001 From: Kevin Cernekee Date: Tue, 13 Apr 2010 13:30:12 -0700 Subject: UBI: remove reboot notifier The UBI reboot notifier causes problems with hibernation. Move this functionality into the low-level MTD driver instead. Signed-off-by: Kevin Cernekee Signed-off-by: Artem Bityutskiy --- drivers/mtd/ubi/build.c | 35 ----------------------------------- drivers/mtd/ubi/ubi.h | 2 -- 2 files changed, 37 deletions(-) (limited to 'drivers') diff --git a/drivers/mtd/ubi/build.c b/drivers/mtd/ubi/build.c index 55c726dde942..3a59a1d0045e 100644 --- a/drivers/mtd/ubi/build.c +++ b/drivers/mtd/ubi/build.c @@ -42,7 +42,6 @@ #include #include #include -#include #include #include #include "ubi.h" @@ -831,34 +830,6 @@ static int autoresize(struct ubi_device *ubi, int vol_id) return 0; } -/** - * ubi_reboot_notifier - halt UBI transactions immediately prior to a reboot. - * @n: reboot notifier object - * @state: SYS_RESTART, SYS_HALT, or SYS_POWER_OFF - * @cmd: pointer to command string for RESTART2 - * - * This function stops the UBI background thread so that the flash device - * remains quiescent when Linux restarts the system. Any queued work will be - * discarded, but this function will block until do_work() finishes if an - * operation is already in progress. - * - * This function solves a real-life problem observed on NOR flashes when an - * PEB erase operation starts, then the system is rebooted before the erase is - * finishes, and the boot loader gets confused and dies. So we prefer to finish - * the ongoing operation before rebooting. - */ -static int ubi_reboot_notifier(struct notifier_block *n, unsigned long state, - void *cmd) -{ - struct ubi_device *ubi; - - ubi = container_of(n, struct ubi_device, reboot_notifier); - if (ubi->bgt_thread) - kthread_stop(ubi->bgt_thread); - ubi_sync(ubi->ubi_num); - return NOTIFY_DONE; -} - /** * ubi_attach_mtd_dev - attach an MTD device. * @mtd: MTD device description object @@ -1016,11 +987,6 @@ int ubi_attach_mtd_dev(struct mtd_info *mtd, int ubi_num, int vid_hdr_offset) wake_up_process(ubi->bgt_thread); spin_unlock(&ubi->wl_lock); - /* Flash device priority is 0 - UBI needs to shut down first */ - ubi->reboot_notifier.priority = 1; - ubi->reboot_notifier.notifier_call = ubi_reboot_notifier; - register_reboot_notifier(&ubi->reboot_notifier); - ubi_devices[ubi_num] = ubi; ubi_notify_all(ubi, UBI_VOLUME_ADDED, NULL); return ubi_num; @@ -1091,7 +1057,6 @@ int ubi_detach_mtd_dev(int ubi_num, int anyway) * Before freeing anything, we have to stop the background thread to * prevent it from doing anything on this device while we are freeing. */ - unregister_reboot_notifier(&ubi->reboot_notifier); if (ubi->bgt_thread) kthread_stop(ubi->bgt_thread); diff --git a/drivers/mtd/ubi/ubi.h b/drivers/mtd/ubi/ubi.h index 5176d4886518..a637f0283add 100644 --- a/drivers/mtd/ubi/ubi.h +++ b/drivers/mtd/ubi/ubi.h @@ -350,7 +350,6 @@ struct ubi_wl_entry; * @bgt_thread: background thread description object * @thread_enabled: if the background thread is enabled * @bgt_name: background thread name - * @reboot_notifier: notifier to terminate background thread before rebooting * * @flash_size: underlying MTD device size (in bytes) * @peb_count: count of physical eraseblocks on the MTD device @@ -436,7 +435,6 @@ struct ubi_device { struct task_struct *bgt_thread; int thread_enabled; char bgt_name[sizeof(UBI_BGT_NAME_PATTERN)+2]; - struct notifier_block reboot_notifier; /* I/O sub-system's stuff */ long long flash_size; -- cgit v1.2.3 From af7ad7a0a6c0c1d8497a25b6b8b3b2ce9f52ff04 Mon Sep 17 00:00:00 2001 From: Marc Kleine-Budde Date: Wed, 5 May 2010 10:17:25 +0200 Subject: UBI: init even if MTD device cannot be attached, if built into kernel UBI can be built into the kernel or be compiled as a kernel module. Further on the command line one can specify MTD devices to be attach to UBI while loading. In the current implementation the UBI driver refuses to load if one of the MTD devices cannot be attached. Consider: 1) UBI compiled into the kernel and 2) a MTD device specified on the command line and 3) this MTD device contains bogus data (for whatever reason). During init UBI tries to attach the MTD device is this fails the whole UBI subsystem isn't initialized. Later the userspace cannot attach any MTD to UBI because UBI isn't loaded. This patch keeps the current behaviour: if UBI is compiled as a module and a MTD device cannot be attached the UBI module cannot be loaded, but changes it for the UBI-is-built-into-the-kernel usecase. If UBI is builtin, a not attachable MTD device doen't stop UBI from initializing. This slightly modifies the behaviour if multiple MTD devices are specified on the command line. Now every MTD device is probed and, if possible, attached, i.e. a faulty MTD device doesn't stop the others from being attached. Artem: tweaked the patch Signed-off-by: Marc Kleine-Budde Signed-off-by: Artem Bityutskiy --- drivers/mtd/ubi/build.c | 25 +++++++++++++++++++++++-- 1 file changed, 23 insertions(+), 2 deletions(-) (limited to 'drivers') diff --git a/drivers/mtd/ubi/build.c b/drivers/mtd/ubi/build.c index 3a59a1d0045e..13b05cb33b08 100644 --- a/drivers/mtd/ubi/build.c +++ b/drivers/mtd/ubi/build.c @@ -49,6 +49,12 @@ /* Maximum length of the 'mtd=' parameter */ #define MTD_PARAM_LEN_MAX 64 +#ifdef CONFIG_MTD_UBI_MODULE +#define ubi_is_module() 1 +#else +#define ubi_is_module() 0 +#endif + /** * struct mtd_dev_param - MTD device parameter description data structure. * @name: MTD character device node path, MTD device name, or MTD device number @@ -1206,9 +1212,24 @@ static int __init ubi_init(void) p->vid_hdr_offs); mutex_unlock(&ubi_devices_mutex); if (err < 0) { - put_mtd_device(mtd); ubi_err("cannot attach mtd%d", mtd->index); - goto out_detach; + put_mtd_device(mtd); + + /* + * Originally UBI stopped initializing on any error. + * However, later on it was found out that this + * behavior is not very good when UBI is compiled into + * the kernel and the MTD devices to attach are passed + * through the command line. Indeed, UBI failure + * stopped whole boot sequence. + * + * To fix this, we changed the behavior for the + * non-module case, but preserved the old behavior for + * the module case, just for compatibility. This is a + * little inconsistent, though. + */ + if (ubi_is_module()) + goto out_detach; } } -- cgit v1.2.3 From 3f5026222e8a16daaa830eec4d72c6745b74407e Mon Sep 17 00:00:00 2001 From: Shinya Kuribayashi Date: Thu, 6 May 2010 19:21:47 +0900 Subject: UBI: fix s/then/than/ typos Signed-off-by: Shinya Kuribayashi Signed-off-by: Artem Bityutskiy --- drivers/mtd/ubi/Kconfig | 2 +- drivers/mtd/ubi/io.c | 2 +- drivers/mtd/ubi/kapi.c | 6 +++--- drivers/mtd/ubi/scan.c | 4 ++-- drivers/mtd/ubi/wl.c | 2 +- 5 files changed, 8 insertions(+), 8 deletions(-) (limited to 'drivers') diff --git a/drivers/mtd/ubi/Kconfig b/drivers/mtd/ubi/Kconfig index 0a8c7ea764ae..f702a163d8df 100644 --- a/drivers/mtd/ubi/Kconfig +++ b/drivers/mtd/ubi/Kconfig @@ -27,7 +27,7 @@ config MTD_UBI_WL_THRESHOLD The default value should be OK for SLC NAND flashes, NOR flashes and other flashes which have eraseblock life-cycle 100000 or more. However, in case of MLC NAND flashes which typically have eraseblock - life-cycle less then 10000, the threshold should be lessened (e.g., + life-cycle less than 10000, the threshold should be lessened (e.g., to 128 or 256, although it does not have to be power of 2). config MTD_UBI_BEB_RESERVE diff --git a/drivers/mtd/ubi/io.c b/drivers/mtd/ubi/io.c index 533b1a4b9af1..016ec1387bc2 100644 --- a/drivers/mtd/ubi/io.c +++ b/drivers/mtd/ubi/io.c @@ -65,7 +65,7 @@ * * A: because when writing a sub-page, MTD still writes a full 2K page but the * bytes which are no relevant to the sub-page are 0xFF. So, basically, writing - * 4x512 sub-pages is 4 times slower then writing one 2KiB NAND page. Thus, we + * 4x512 sub-pages is 4 times slower than writing one 2KiB NAND page. Thus, we * prefer to use sub-pages only for EV and VID headers. * * As it was noted above, the VID header may start at a non-aligned offset. diff --git a/drivers/mtd/ubi/kapi.c b/drivers/mtd/ubi/kapi.c index 17f287decc36..69fa4ef03c53 100644 --- a/drivers/mtd/ubi/kapi.c +++ b/drivers/mtd/ubi/kapi.c @@ -488,7 +488,7 @@ EXPORT_SYMBOL_GPL(ubi_leb_write); * * This function changes the contents of a logical eraseblock atomically. @buf * has to contain new logical eraseblock data, and @len - the length of the - * data, which has to be aligned. The length may be shorter then the logical + * data, which has to be aligned. The length may be shorter than the logical * eraseblock size, ant the logical eraseblock may be appended to more times * later on. This function guarantees that in case of an unclean reboot the old * contents is preserved. Returns zero in case of success and a negative error @@ -571,7 +571,7 @@ EXPORT_SYMBOL_GPL(ubi_leb_erase); * * This function un-maps logical eraseblock @lnum and schedules the * corresponding physical eraseblock for erasure, so that it will eventually be - * physically erased in background. This operation is much faster then the + * physically erased in background. This operation is much faster than the * erase operation. * * Unlike erase, the un-map operation does not guarantee that the logical @@ -590,7 +590,7 @@ EXPORT_SYMBOL_GPL(ubi_leb_erase); * * The main and obvious use-case of this function is when the contents of a * logical eraseblock has to be re-written. Then it is much more efficient to - * first un-map it, then write new data, rather then first erase it, then write + * first un-map it, then write new data, rather than first erase it, then write * new data. Note, once new data has been written to the logical eraseblock, * UBI guarantees that the old contents has gone forever. In other words, if an * unclean reboot happens after the logical eraseblock has been un-mapped and diff --git a/drivers/mtd/ubi/scan.c b/drivers/mtd/ubi/scan.c index dc5f688699da..aed19f33b8f3 100644 --- a/drivers/mtd/ubi/scan.c +++ b/drivers/mtd/ubi/scan.c @@ -231,7 +231,7 @@ static struct ubi_scan_volume *add_volume(struct ubi_scan_info *si, int vol_id, * case of success this function returns a positive value, in case of failure, a * negative error code is returned. The success return codes use the following * bits: - * o bit 0 is cleared: the first PEB (described by @seb) is newer then the + * o bit 0 is cleared: the first PEB (described by @seb) is newer than the * second PEB (described by @pnum and @vid_hdr); * o bit 0 is set: the second PEB is newer; * o bit 1 is cleared: no bit-flips were detected in the newer LEB; @@ -452,7 +452,7 @@ int ubi_scan_add_used(struct ubi_device *ubi, struct ubi_scan_info *si, if (cmp_res & 1) { /* - * This logical eraseblock is newer then the one + * This logical eraseblock is newer than the one * found earlier. */ err = validate_vid_hdr(vid_hdr, sv, pnum); diff --git a/drivers/mtd/ubi/wl.c b/drivers/mtd/ubi/wl.c index f64ddabd4ac8..ee7b1d8fbb92 100644 --- a/drivers/mtd/ubi/wl.c +++ b/drivers/mtd/ubi/wl.c @@ -350,7 +350,7 @@ static void prot_queue_add(struct ubi_device *ubi, struct ubi_wl_entry *e) * @max: highest possible erase counter * * This function looks for a wear leveling entry with erase counter closest to - * @max and less then @max. + * @max and less than @max. */ static struct ubi_wl_entry *find_wl_entry(struct rb_root *root, int max) { -- cgit v1.2.3 From be436f6238a17b8432b9de0212bcfc838afb1f85 Mon Sep 17 00:00:00 2001 From: Shinya Kuribayashi Date: Thu, 6 May 2010 19:22:09 +0900 Subject: UBI: misc comment fixes Signed-off-by: Shinya Kuribayashi Signed-off-by: Artem Bityutskiy --- drivers/mtd/ubi/io.c | 6 +++--- drivers/mtd/ubi/vtbl.c | 4 ++-- 2 files changed, 5 insertions(+), 5 deletions(-) (limited to 'drivers') diff --git a/drivers/mtd/ubi/io.c b/drivers/mtd/ubi/io.c index 016ec1387bc2..4b979e34b159 100644 --- a/drivers/mtd/ubi/io.c +++ b/drivers/mtd/ubi/io.c @@ -64,9 +64,9 @@ * device, e.g., make @ubi->min_io_size = 512 in the example above? * * A: because when writing a sub-page, MTD still writes a full 2K page but the - * bytes which are no relevant to the sub-page are 0xFF. So, basically, writing - * 4x512 sub-pages is 4 times slower than writing one 2KiB NAND page. Thus, we - * prefer to use sub-pages only for EV and VID headers. + * bytes which are not relevant to the sub-page are 0xFF. So, basically, + * writing 4x512 sub-pages is 4 times slower than writing one 2KiB NAND page. + * Thus, we prefer to use sub-pages only for EC and VID headers. * * As it was noted above, the VID header may start at a non-aligned offset. * For example, in case of a 2KiB page NAND flash with a 512 bytes sub-page, diff --git a/drivers/mtd/ubi/vtbl.c b/drivers/mtd/ubi/vtbl.c index cd90ff3b76b1..14c10bed94ee 100644 --- a/drivers/mtd/ubi/vtbl.c +++ b/drivers/mtd/ubi/vtbl.c @@ -414,7 +414,7 @@ static struct ubi_vtbl_record *process_lvol(struct ubi_device *ubi, * 0 contains more recent information. * * So the plan is to first check LEB 0. Then - * a. if LEB 0 is OK, it must be containing the most resent data; then + * a. if LEB 0 is OK, it must be containing the most recent data; then * we compare it with LEB 1, and if they are different, we copy LEB * 0 to LEB 1; * b. if LEB 0 is corrupted, but LEB 1 has to be OK, and we copy LEB 1 @@ -848,7 +848,7 @@ int ubi_read_volume_table(struct ubi_device *ubi, struct ubi_scan_info *si) goto out_free; /* - * Get sure that the scanning information is consistent to the + * Make sure that the scanning information is consistent to the * information stored in the volume table. */ err = check_scanning_info(ubi, si); -- cgit v1.2.3