Age | Commit message (Collapse) | Author | Files | Lines |
|
Currently we don't move the buffer along for a short read() or write()
and nor do we request only the remaining amount.
Fixes: c7c3a4cd53d libflash/file: Add a file access backend to for the blocklevel interface.
Signed-off-by: Cyril Bur <cyril.bur@au1.ibm.com>
Reviewed-by: Suraj Jitindar Singh <sjitindarsingh@gmail.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
Unfortunately not all drivers are created equal and several drivers on
which pflash relies block in the kernel for quite some time and ignore
signals.
This is really only a problem if pflash is to perform large erases. So
don't, perform these ops in small chunks.
An in kernel fix is possible in most cases but it takes time and systems
will be running older drivers for quite some time. Since sector erases
aren't significantly slower than whole chip erases there isn't much of a
performance penalty to breaking up the erase ioctl()s.
Signed-off-by: Cyril Bur <cyril.bur@au1.ibm.com>
Reviewed-by: Samuel Mendoza-Jonas <sam@mendozajonas.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
Signed-off-by: Cyril Bur <cyril.bur@au1.ibm.com>
Reviewed-by: Samuel Mendoza-Jonas <sam@mendozajonas.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
mostly missing prototypes and unused parameters.
Reviewed-by: Cyril Bur <cyril.bur@au1.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
We recently made MTD 64 bit safe in e5720d3fe94 which now requires the
64 bit MTD erase ioctl. Unfortunately this ioctl is not present in
older kernels used by some BMC vendors that use pflash.
This patch addresses this by only using the 64bit version of the erase
ioctl() if the parameters exceed 32bit in size.
If an erase requires the 64bit ioctl() on a kernel which does not
support it, the code will still attempt it. There is no way of knowing
beforehand if the kernel supports it. The ioctl() will fail and an error
will be returned from from the function.
Signed-off-by: Cyril Bur <cyril.bur@au1.ibm.com>
Signed-off-by: Michael Neuling <mikey@neuling.org>
|
|
While we'll 'never' have flash chips larger than 32bit, work was
recently done to blocklevel for it to be 64bit compatible for other
backends.
Since there is a 64bit ioctl() lets use it. There is currently no known
case where 32bit is not sufficient but this doesn't mean someone might
not do something strange in the future.
Signed-off-by: Cyril Bur <cyril.bur@au1.ibm.com>
Reviewed-by: Joel Stanley <joel@jms.id.au>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
This makes the size of flash 64 bit safe so that we can have flash
devices greater than 4GB. This is especially useful for mambo disks
passed through to Linux.
Fortunately the device tree interface and the linux device driver are
64bit safe so no changes are required there.
Userspace gard and flash tools are also updated to ensure "make check"
still passes.
Signed-off-by: Michael Neuling <mikey@neuling.org>
Reviewed-by: Cyril Bur <cyrilbur@gmail.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
If we had a truncated file where libflash would attempt to read past
the end, instead of erroring out, we'd get stuck in an infinite loop.
Why? Because we weren't acknowledging that read() returns 0 on EOF.
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
Reviewed-by: Cyril Bur <cyril.bur@au1.ibm.com>
|
|
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>
|
|
Signed-off-by: Samuel Mendoza-Jonas <sam.mj@au1.ibm.com>
Reviewed-by: Cyril Bur <cyrilbur@gmail.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
Currently libflash reads from files by using the dodgy file_flash.c which
implements a very flash hardware themed interface but subverts it to read,
write and erase from a file descriptor.
With the introduction of this file backend, this will no longer be needed.
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>
|