[RFC/PATCH v2] ubi: Add ubiblock read-write driver

[Gupta, Pekon]

> On Thursday 18 April 2013 20:13:00 Ezequiel Garcia wrote:
> > On Thu, Apr 18, 2013 at 04:30:55PM -0400, Mike Frysinger wrote:
> > > i wonder if the write support should be put behind a CONFIG option.
> > > personally, the write support is kind of neat and semi-useful for
> > > development, but i don't plan on shipping anything on that :).  i just
> > > want read-only support to load an ext2 fs on top of UBI.
> >
> > Mmm... good input. Maybe putting write support behind a CONFIG
> and
> > showing a big fat warning when the module loads will do?
> > (something to prevent regular users from using this carelessly).
> >
[Pekon]: Permanent disabling of WRITE(s) may not be good approach. 
As it constrains you from updating on-field device remotely, especially
when your boot-loaders are not in your control.
OR Unless you have a back-door mechanism or loop-hole, which you 
can also share with your customers (unlikely). 

[Pekon]: Other options for S/W driven Write-access-control are:
(1) Using Write-Protect pin on NAND device, controlled via secure GPIO
(2) Using mtd_lock and mtd_unlock mechanism.
	(a) your device should support this feature,
	(b) I think this is not supported for MTDBLOCK devices, and
	(c) need to populate following functions accordingly.
	drivers/mtd/nand/nand_base.c
	int nand_scan_tail(struct mtd_info *mtd)
	-       mtd->_lock = NULL;
	-       mtd->_unlock = NULL;
	+       mtd->_lock = nand_lock;
	+       mtd->_unlock = nand_unlock;

-- Bit away from topic of discussion --
Currently for MTDBLOCK devices the readonly setting is decided
at device addition time.
drivers/mtd/mtdblock.c : mtdblock_add_mtd()
if (!(mtd->flags & MTD_WRITEABLE))
	dev->mbd.readonly = 1;

But I think a similar write-protection mechanism may be added 
for MTDBLOCK devices also, thereby giving low-level access control
Example:
if (mtd->_lock && mtd->_unlock)
	dev->mbd.supports_write_protection = 1;

Does anyone see a benefit in this?


with regards, pekon