| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
Currently the file backend will keep a file descriptor open until the
structure is destroyed. This is undesirable for daemons and long running
processes that only have a very occasional need to access the file. Keeping
the file open requires users of blocklevel to close and reinit their
structures every time, doing is isn't disastrous but can easily be
managed at the interface level.
This has been done at the blocklevel_device interface so as to provide
minimal changes to arch_flash_init().
At the moment there isn't a need for the actually flash driver to be able
to do this, this remains unimplmented there.
Signed-off-by: Cyril Bur <cyril.bur@au1.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
Blocklevel_smart_write() can write in a smart fashion which avoids the need
for the caller to erase the flash before writing, except it never actually
does the erase if it needs to.
Furthermore, a very simple optimisation can be made where it should detect
if it doesn't actually need to clear the flash, but still needs to write.
This optimisation is from flash_smart_write(), which, for reasons, should
continue to exist at least for now.
In the process, this also addresses a bug. blocklevel_smart_write()
operates on erase block covered by the write, detects to see if an erase
needs to be performed and if so, performs the erase and then performs the
write.
Currently blocklevel_smart_write() won't detect that a write can span two
erase blocks and that it should split this process in two. This patch fixes
that.
Signed-off-by: Cyril Bur <cyril.bur@au1.ibm.com>
Reviewed-by: Samuel Mendoza-Jonas <sam.mj@au1.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
If an ECC check fails in blocklevel_read(), the return code from
blocklevel_read() won't be correct.
Signed-off-by: Cyril Bur <cyril.bur@au1.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
See https://github.com/lucasdemarchi/codespel
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
writing
For consumers who can't do better or who aren't to phased about
performance, having to book keep erasing in order to be able to write data
can be painful. Blocklevel can do it, possibly naively but its a convenience
function
Reviewed-By: Alistair Popple <alistair@popple.id.au>
Signed-off-by: Cyril Bur <cyril.bur@au1.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
At the moment ECC reads and writes are still being handled by the low level
core of libflash. ECC should be none of libflashes concern, it is primarily
a hardware access backend.
It makes sense for blocklevel to take care of ECC but currently it has no
way of knowing. With some simple modifications (which are rudimentary at
the moment and will need a performance improvement) blocklevel can handle
ECC, and with a little more effort this can be extended to provide read and
write protection in blocklevel.
Reviewed-By: Alistair Popple <alistair@popple.id.au>
Signed-off-by: Cyril Bur <cyril.bur@au1.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
Blocklevel has no way to check that backends init the erase_mask correctly
and as such must trust them.
When a user calls blocklevel_get_info(), blocklevel has a chance to inspect
the return value and warn if the values do not match. This check happens on
every call which should be fine as it is doubtful that
blocklevel_get_info() will be called much.
Signed-off-by: Cyril Bur <cyril.bur@au1.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
Currently blocklevel_erase() will let any erase of any size get passed down
to the backend. Not strictly a problem since libflash does do this check
as well, however, not all future backends will.
This is very much a sanity check to save from a likely mistake.
Signed-off-by: Cyril Bur <cyril.bur@au1.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
libflash core is really good at accessing hardware flash devices. libffs is
really good at read FFS partitioned data and has been designed to use libflash
to read data.
Problems arise when FFS partitioned data exists on something other than
flash hardware, or the hardware cannot be accessed directly.
This interface should bridge the gap, allowing libffs to be used no matter
what the backing is for the data. This should allow for greater flexibility
for reading and writing, such as adding support read-only areas at a global
level as well as more straight forward usage of libffs for userspace bypassing
libflash entirely.
Signed-off-by: Cyril Bur <cyril.bur@au1.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
