Skip to content

Commit 1557b9e

Browse files
vapierdedekind
authored andcommitted
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 <[email protected]> Signed-off-by: Artem Bityutskiy <[email protected]>
1 parent 6fde0f3 commit 1557b9e

File tree

1 file changed

+5
-1
lines changed

1 file changed

+5
-1
lines changed

drivers/mtd/ubi/build.c

Lines changed: 5 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -1261,7 +1261,11 @@ static int __init ubi_init(void)
12611261
mtd = open_mtd_device(p->name);
12621262
if (IS_ERR(mtd)) {
12631263
err = PTR_ERR(mtd);
1264-
goto out_detach;
1264+
ubi_err("cannot open mtd %s, error %d", p->name, err);
1265+
/* See comment below re-ubi_is_module(). */
1266+
if (ubi_is_module())
1267+
goto out_detach;
1268+
continue;
12651269
}
12661270

12671271
mutex_lock(&ubi_devices_mutex);

0 commit comments

Comments
 (0)