aboutsummaryrefslogtreecommitdiffstats
path: root/drivers/mtd/ubi
diff options
context:
space:
mode:
authorMarc Kleine-Budde <mkl@pengutronix.de>2010-05-05 04:17:25 -0400
committerArtem Bityutskiy <Artem.Bityutskiy@nokia.com>2010-05-06 02:12:11 -0400
commitaf7ad7a0a6c0c1d8497a25b6b8b3b2ce9f52ff04 (patch)
tree3073f9591d82feb01e6138e6b5bbac5d76f78e5e /drivers/mtd/ubi
parent70d38b9625edba52a809308427f78831c3963f52 (diff)
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 <mkl@pengutronix.de> Signed-off-by: Artem Bityutskiy <Artem.Bityutskiy@nokia.com>
Diffstat (limited to 'drivers/mtd/ubi')
-rw-r--r--drivers/mtd/ubi/build.c25
1 files changed, 23 insertions, 2 deletions
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 @@
49/* Maximum length of the 'mtd=' parameter */ 49/* Maximum length of the 'mtd=' parameter */
50#define MTD_PARAM_LEN_MAX 64 50#define MTD_PARAM_LEN_MAX 64
51 51
52#ifdef CONFIG_MTD_UBI_MODULE
53#define ubi_is_module() 1
54#else
55#define ubi_is_module() 0
56#endif
57
52/** 58/**
53 * struct mtd_dev_param - MTD device parameter description data structure. 59 * struct mtd_dev_param - MTD device parameter description data structure.
54 * @name: MTD character device node path, MTD device name, or MTD device number 60 * @name: MTD character device node path, MTD device name, or MTD device number
@@ -1206,9 +1212,24 @@ static int __init ubi_init(void)
1206 p->vid_hdr_offs); 1212 p->vid_hdr_offs);
1207 mutex_unlock(&ubi_devices_mutex); 1213 mutex_unlock(&ubi_devices_mutex);
1208 if (err < 0) { 1214 if (err < 0) {
1209 put_mtd_device(mtd);
1210 ubi_err("cannot attach mtd%d", mtd->index); 1215 ubi_err("cannot attach mtd%d", mtd->index);
1211 goto out_detach; 1216 put_mtd_device(mtd);
1217
1218 /*
1219 * Originally UBI stopped initializing on any error.
1220 * However, later on it was found out that this
1221 * behavior is not very good when UBI is compiled into
1222 * the kernel and the MTD devices to attach are passed
1223 * through the command line. Indeed, UBI failure
1224 * stopped whole boot sequence.
1225 *
1226 * To fix this, we changed the behavior for the
1227 * non-module case, but preserved the old behavior for
1228 * the module case, just for compatibility. This is a
1229 * little inconsistent, though.
1230 */
1231 if (ubi_is_module())
1232 goto out_detach;
1212 } 1233 }
1213 } 1234 }
1214 1235