summaryrefslogtreecommitdiff
path: root/drivers
diff options
context:
space:
mode:
authorMike Frysinger <vapier@gentoo.org>2013-04-22 21:40:16 -0400
committerArtem Bityutskiy <artem.bityutskiy@linux.intel.com>2013-07-05 18:54:31 +0300
commitf08cdd4be3bf5ae2620716ed7779c56900ba30eb (patch)
treefeded0ea53c60f6c21152ed9a91c7830e1fd9514 /drivers
parentb16cdf1b8d60c4c64605bca6e63fe3d1d57c6edb (diff)
UBI: do not abort init when ubi.mtd devices cannot be found
The current ubi.mtd parsing logic will warn & continue on when attaching the specified mtd device fails (for any reason). It doesn't however skip things when the specified mtd device can't be opened. This scenario can be hit in a couple of different ways such as: - build NAND controller driver as a module - build UBI into the kernel - include ubi.mtd on the kernel command line - boot the system - MTD devices don't exist, so UBI init fails This is problematic because failing init means the entire UBI layer is unavailable until you reboot and modify the kernel command line. If we just warn and continue on, /dev/ubi_ctrl is available for userland to add UBI volumes on the fly once it loads the NAND driver. Signed-off-by: Mike Frysinger <vapier@gentoo.org> Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
Diffstat (limited to 'drivers')
-rw-r--r--drivers/mtd/ubi/build.c6
1 files changed, 5 insertions, 1 deletions
diff --git a/drivers/mtd/ubi/build.c b/drivers/mtd/ubi/build.c
index 77d70f7502bd..52f3ff5570e0 100644
--- a/drivers/mtd/ubi/build.c
+++ b/drivers/mtd/ubi/build.c
@@ -1261,7 +1261,11 @@ static int __init ubi_init(void)
mtd = open_mtd_device(p->name);
if (IS_ERR(mtd)) {
err = PTR_ERR(mtd);
- goto out_detach;
+ ubi_err("cannot open mtd %s, error %d", p->name, err);
+ /* See comment below re-ubi_is_module(). */
+ if (ubi_is_module())
+ goto out_detach;
+ continue;
}
mutex_lock(&ubi_devices_mutex);