| Submitter | Jiang Lu |
|---|---|
| Date | Aug. 8, 2012, 2:31 a.m. |
| Message ID | <1344393061-21037-1-git-send-email-lu.jiang@windriver.com> |
| Download | mbox | patch |
| Permalink | /patch/175839/ |
| State | New |
| Headers | show |
Comments
On Wed, Aug 8, 2012 at 4:31 AM, Jiang Lu <lu.jiang@windriver.com> wrote: > To implement rootfs on mtd device with UBIFS, kernel need create a > UBIFS device when booting: > > drivers/mtd/ubi/build.c ubi_init() > for (i = 0; i < mtd_devs; i++) { > ... > mtd = open_mtd_device(p->name); > if (IS_ERR(mtd)) { > err = PTR_ERR(mtd); > goto out_detach; > } > > ubi_attach_mtd_dev() > ... > } > module_init(ubi_init); > > Kernel can not create the UBIFS device without corresponding mtd > partiton. > > Some NAND device can not guarenteen the mtd patition created before > UBIFS deivce driver loading. Such as SPI NAND deivce, the mtd partition > will create after SPI bus driver loaded. > > UBI device driver must load after other mtd device drivers to make sure > the mtd partition already exist when creating UBI deivce. > > The patch updates the UBI device driver's initial routine to > late_initcall level. > > Signed-off-by: Jiang Lu <lu.jiang@windriver.com> > --- > drivers/mtd/ubi/build.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/mtd/ubi/build.c b/drivers/mtd/ubi/build.c > index 0fde9fc..efbcaef 100644 > --- a/drivers/mtd/ubi/build.c > +++ b/drivers/mtd/ubi/build.c > @@ -1275,7 +1275,7 @@ out: > ubi_err("UBI error: cannot initialize UBI, error %d", err); > return err; > } > -module_init(ubi_init); > +late_initcall(ubi_init); Cant we use a simple initrd in such a case? Within the initrd you can load the ubi module after your SPI NAND is done.
于 2012年08月09日 05:52, richard -rw- weinberger 写道: > On Wed, Aug 8, 2012 at 4:31 AM, Jiang Lu <lu.jiang@windriver.com> wrote: >> To implement rootfs on mtd device with UBIFS, kernel need create a >> UBIFS device when booting: >> >> drivers/mtd/ubi/build.c ubi_init() >> for (i = 0; i < mtd_devs; i++) { >> ... >> mtd = open_mtd_device(p->name); >> if (IS_ERR(mtd)) { >> err = PTR_ERR(mtd); >> goto out_detach; >> } >> >> ubi_attach_mtd_dev() >> ... >> } >> module_init(ubi_init); >> >> Kernel can not create the UBIFS device without corresponding mtd >> partiton. >> >> Some NAND device can not guarenteen the mtd patition created before >> UBIFS deivce driver loading. Such as SPI NAND deivce, the mtd partition >> will create after SPI bus driver loaded. >> >> UBI device driver must load after other mtd device drivers to make sure >> the mtd partition already exist when creating UBI deivce. >> >> The patch updates the UBI device driver's initial routine to >> late_initcall level. >> >> Signed-off-by: Jiang Lu <lu.jiang@windriver.com> >> --- >> drivers/mtd/ubi/build.c | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/drivers/mtd/ubi/build.c b/drivers/mtd/ubi/build.c >> index 0fde9fc..efbcaef 100644 >> --- a/drivers/mtd/ubi/build.c >> +++ b/drivers/mtd/ubi/build.c >> @@ -1275,7 +1275,7 @@ out: >> ubi_err("UBI error: cannot initialize UBI, error %d", err); >> return err; >> } >> -module_init(ubi_init); >> +late_initcall(ubi_init); > Cant we use a simple initrd in such a case? > Within the initrd you can load the ubi module after your SPI NAND is done. > This could be a workround. But for the ubi device driver, kernel should invoke ubi_init() after all mtd partition ready.
On Wed, 2012-08-08 at 10:31 +0800, Jiang Lu wrote: > diff --git a/drivers/mtd/ubi/build.c b/drivers/mtd/ubi/build.c > index 0fde9fc..efbcaef 100644 > --- a/drivers/mtd/ubi/build.c > +++ b/drivers/mtd/ubi/build.c > @@ -1275,7 +1275,7 @@ out: > ubi_err("UBI error: cannot initialize UBI, error %d", err); > return err; > } > -module_init(ubi_init); > +late_initcall(ubi_init); The problem is that UBIFS, which is usually used on top of UBI, also uses 'late_initcall()'. If we do this change, how do we guarantee that UBIFS is initialized after UBI?
On Fri, 2012-08-24 at 12:41 +0300, Artem Bityutskiy wrote: > On Wed, 2012-08-08 at 10:31 +0800, Jiang Lu wrote: > > diff --git a/drivers/mtd/ubi/build.c b/drivers/mtd/ubi/build.c > > index 0fde9fc..efbcaef 100644 > > --- a/drivers/mtd/ubi/build.c > > +++ b/drivers/mtd/ubi/build.c > > @@ -1275,7 +1275,7 @@ out: > > ubi_err("UBI error: cannot initialize UBI, error %d", err); > > return err; > > } > > -module_init(ubi_init); > > +late_initcall(ubi_init); > > The problem is that UBIFS, which is usually used on top of UBI, also > uses 'late_initcall()'. If we do this change, how do we guarantee that > UBIFS is initialized after UBI? It looks like the right way to fix the issue is to change the way UBI initializes. We should not try to open the MTD device, scan it and attach in the initcall. We should instead delay this till the first open. So when you open the device for the firs time, you actually end up with the scanning, etc.
On Fri, 2012-08-24 at 12:41 +0300, Artem Bityutskiy wrote: > On Wed, 2012-08-08 at 10:31 +0800, Jiang Lu wrote: > > diff --git a/drivers/mtd/ubi/build.c b/drivers/mtd/ubi/build.c > > index 0fde9fc..efbcaef 100644 > > --- a/drivers/mtd/ubi/build.c > > +++ b/drivers/mtd/ubi/build.c > > @@ -1275,7 +1275,7 @@ out: > > ubi_err("UBI error: cannot initialize UBI, error %d", err); > > return err; > > } > > -module_init(ubi_init); > > +late_initcall(ubi_init); > > The problem is that UBIFS, which is usually used on top of UBI, also > uses 'late_initcall()'. If we do this change, how do we guarantee that > UBIFS is initialized after UBI? Although, I think it is not really a problem and UBIFS can be initialized at any point - it does not depend on UBI being initialized.
于 2012年08月24日 19:24, Artem Bityutskiy 写道: > On Fri, 2012-08-24 at 12:41 +0300, Artem Bityutskiy wrote: >> On Wed, 2012-08-08 at 10:31 +0800, Jiang Lu wrote: >>> diff --git a/drivers/mtd/ubi/build.c b/drivers/mtd/ubi/build.c >>> index 0fde9fc..efbcaef 100644 >>> --- a/drivers/mtd/ubi/build.c >>> +++ b/drivers/mtd/ubi/build.c >>> @@ -1275,7 +1275,7 @@ out: >>> ubi_err("UBI error: cannot initialize UBI, error %d", err); >>> return err; >>> } >>> -module_init(ubi_init); >>> +late_initcall(ubi_init); >> The problem is that UBIFS, which is usually used on top of UBI, also >> uses 'late_initcall()'. If we do this change, how do we guarantee that >> UBIFS is initialized after UBI? > Although, I think it is not really a problem and UBIFS can be > initialized at any point - it does not depend on UBI being initialized. > Yes, it works fine with this change. UFIFS can be mount as rootfs device on SPI flash after ubi_init() change to late_initcall(). Jiang Lu
On Wed, 2012-08-08 at 10:31 +0800, Jiang Lu wrote: > To implement rootfs on mtd device with UBIFS, kernel need create a > UBIFS device when booting: Pushed to linux-ubi.git, thanks!
Patch
diff --git a/drivers/mtd/ubi/build.c b/drivers/mtd/ubi/build.c index 0fde9fc..efbcaef 100644 --- a/drivers/mtd/ubi/build.c +++ b/drivers/mtd/ubi/build.c @@ -1275,7 +1275,7 @@ out: ubi_err("UBI error: cannot initialize UBI, error %d", err); return err; } -module_init(ubi_init); +late_initcall(ubi_init); static void __exit ubi_exit(void) {
To implement rootfs on mtd device with UBIFS, kernel need create a UBIFS device when booting: drivers/mtd/ubi/build.c ubi_init() for (i = 0; i < mtd_devs; i++) { ... mtd = open_mtd_device(p->name); if (IS_ERR(mtd)) { err = PTR_ERR(mtd); goto out_detach; } ubi_attach_mtd_dev() ... } module_init(ubi_init); Kernel can not create the UBIFS device without corresponding mtd partiton. Some NAND device can not guarenteen the mtd patition created before UBIFS deivce driver loading. Such as SPI NAND deivce, the mtd partition will create after SPI bus driver loaded. UBI device driver must load after other mtd device drivers to make sure the mtd partition already exist when creating UBI deivce. The patch updates the UBI device driver's initial routine to late_initcall level. Signed-off-by: Jiang Lu <lu.jiang@windriver.com> --- drivers/mtd/ubi/build.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)