[PATCH 08/16] UBI: Fastmap: Address another TOOD

[Richard Weinberger]

This will be "fixed" upon ubinize has fastmap support.

Signed-off-by: Richard Weinberger <richard at nod.at>
---
 drivers/mtd/ubi/attach.c |   15 ---------------
 1 files changed, 0 insertions(+), 15 deletions(-)

diff --git a/drivers/mtd/ubi/attach.c b/drivers/mtd/ubi/attach.c
index 068f11a..1ac58ec 100644
--- a/drivers/mtd/ubi/attach.c
+++ b/drivers/mtd/ubi/attach.c
@@ -1250,21 +1250,6 @@ int ubi_attach(struct ubi_device *ubi, int force_scan)
 	if (err)
 		goto out_ai;
 
-	/* TODO: currently the fastmap code assumes that the fastmap data
-	 * structures are created only by the kernel when the kernel attaches
-	 * an fastmap-less image. However, this assumption is too limiting and
-	 * for sure people will want to pre-create UBI images with fastmap
-	 * using the ubinize tool. Then they wont have to waste a lot of time
-	 * waiting for full scan and fastmap initializetion during the first
-	 * boot. This is a very important feature for the factory production
-	 * line where every additional minute per device costs a lot.
-	 *
-	 * When you are attaching an MTD device which contains an image
-	 * generated by ubinize with a fastmap, you will not know the
-	 * 'bad_peb_count' value. Most probably it will contain something like
-	 * -1. The same is true for the per-PEB information in the fastmap - it
-	 * won't tell which PEBs are bad. So we need to detect this and iterate
-	 * over all PEBs, find out which are bad, and update 'ai' here. */
 	ubi->bad_peb_count = ai->bad_peb_count;
 	ubi->good_peb_count = ubi->peb_count - ubi->bad_peb_count;
 	ubi->corr_peb_count = ai->corr_peb_count;
-- 
1.7.6.5