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.

V2: integrated comments from Artem Bityutskiy:
    use defines instead of static inline functions

Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
---
 drivers/mtd/ubi/build.c |   12 ++++++++++--
 1 files changed, 10 insertions(+), 2 deletions(-)

diff --git a/drivers/mtd/ubi/build.c b/drivers/mtd/ubi/build.c
index fad40aa..d0447a5 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
@@ -1240,9 +1246,11 @@ static int __init ubi_init(void)
 					 p->vid_hdr_offs);
 ...
[ message continues ]

We should put the MTD device even if we continue, because we did not

I've added a comment and fixed your patch, and pushed to ubi-2.6.git.
From: Marc Kleine-Budde <mkl@pengutronix.de>
Date: Wed, 5 May 2010 10:17:25 +0200
Subject: [PATCH] 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>
---
 drivers/mtd/ubi/build.c |   25 +++++++++++++++++++++++--
 1 files changed, 23 insertions(+), 2 deletions(-)

diff --git a/drivers/mtd/ubi/build.c b/drivers/mtd/ubi/build.c
index 3a59a1d..13b05cb 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() ...
[ message continues ]