Currently work_buf is only NULL when MTD_DRIVER_FLAG_DIRECT_WRITE is
set, so it served as a proxy for that flag.
However, we might want to have a work buffer even when writes without
erase are possible.
Currently implementations of the MTD api are selecting the module,
this makes it easy for default backends to be selected. But the
correct modeling is simply selecting the MTD api and then selecting
a backend. BOARDs providing one of the backends can expose this and
then that backend can be selected by default.
There is also currently nothing preventing from using the MTD api
with no backend since a mock backend can easily be provided as is
done in all mtd tests.
If the underlying driver implements 'plain' read/write/erase
fucntions, don't convert them to pagewise functions and back.
Just use the old direct functions.
Currently read(), write() and erase() all use 32 bit addressing.
This is a problem when writing to media > 4 GiB, e.g. SD cards.
The current implementation would wrap around after 4 GiB and corrupt data.
To avoid this, add functions to the MTD subsystem that allow for page-wise
addressing. This is how most of the underling storage drivers and the
file-systems above work anyway.
In the future we should then deprecate the 32-bit functions if all drivers
are converted.
