summaryrefslogtreecommitdiffstats
path: root/drivers/mtd/inftlmount.c
diff options
context:
space:
mode:
authorMarc Kleine-Budde <mkl@pengutronix.de>2010-05-05 10:17:25 +0200
committerArtem Bityutskiy <Artem.Bityutskiy@nokia.com>2010-05-06 09:12:11 +0300
commitaf7ad7a0a6c0c1d8497a25b6b8b3b2ce9f52ff04 (patch)
tree3073f9591d82feb01e6138e6b5bbac5d76f78e5e /drivers/mtd/inftlmount.c
parent70d38b9625edba52a809308427f78831c3963f52 (diff)
downloadblackbird-op-linux-af7ad7a0a6c0c1d8497a25b6b8b3b2ce9f52ff04.tar.gz
blackbird-op-linux-af7ad7a0a6c0c1d8497a25b6b8b3b2ce9f52ff04.zip
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/inftlmount.c')
0 files changed, 0 insertions, 0 deletions
OpenPOWER on IntegriCloud