MTD_DRIVER_FLAG_DIRECT_WRITE is still correct - you don't need to erase a sector to write it.
I do wonder how fatfs does unaligned writes though, mtd_diskio.c always operates on whole pages.

You are right, simply removing the flag does not work actually. Don´t know how it worked before.

It fails here:

Is then simply the if condition wrong here?

Compared to:

I am missing the check for unaligned memory access based on write_size in the MTD layer.

Should
int mtd_write_page_raw(mtd_dev_t *mtd, const void *src, uint32_t page, uint32_t offset, uint32_t count)

check for unaligned access and then if MODULE_MTD_WRITE_PAGE is used take care of calling that instead?

For mtd_flashpage there is this kind of "work_area":

        uint8_t tmp[FLASHPAGE_WRITE_BLOCK_SIZE]
                __attribute__ ((aligned (FLASHPAGE_WRITE_BLOCK_ALIGNMENT)));

The allocation of work_area could be moved to the storage driver.
If in mtd_init(), the driver->init() did not allocate a work area, then the MTD layer can call malloc.

It fails here

Do you mean the

     if (IS_USED(MODULE_SDMMC_MMC) && (dev->type == SDMMC_CARD_TYPE_MMC)) { 
         /* MMCs don't support the erase of a single block but only the erase of 
          * a group of blocks. Blocks are erased implicitly on write. */ 
         DEBUG("[sdmmc] MMCs don't support the erase of single blocks\n"); 
         return -ENOTSUP; 
     } 

again, with fatfs this shouldn't be an issue as we always use mtd_write_sector() which with MTD_DRIVER_FLAG_DIRECT_WRITE should never call mtd_erase_sector().

What filesystem are you trying to use? Or are you using a raw MTD device without a filesystem?

That's where it fails when I remove the MTD_DRIVER_FLAG_DIRECT_WRITE flag, yes.
I am using fatfs. I also tried lwext4, but it did not work. I did not spend much time to investigate why.

with fatfs this shouldn't be an issue as we always use mtd_write_sector()

For whatever reason I land here:

static int mtd_sdmmc_write_page(mtd_dev_t *dev, const void *buff, uint32_t page,
                                 uint32_t offset, uint32_t size)
{
    mtd_sdmmc_t *mtd_sd = (mtd_sdmmc_t*)dev;

    DEBUG("mtd_sdmmc_write_page: page:%" PRIu32 " offset:%" PRIu32 " size:%" PRIu32 "\n",
          page, offset, size);

    if (offset || size % SDMMC_SDHC_BLOCK_SIZE) {
#if IS_USED(MODULE_MTD_WRITE_PAGE)
        if (dev->work_area == NULL) {
            DEBUG("mtd_sdmmc_write_page: no work area\n");
            return -ENOTSUP;
        }

Can you enable debug? What are offset and size?

I wanted to debug. But suddenly it works with two different boards. I do not 100% trust it still. Its very strange.
But I think a check if work_area already exists is preventing an accidental double allocation when mtd_init is called multiple times.
I will change title and description of this PR.

There is still something else required. The fatfs filesystem does only do aligned reads and writes, but when I want to call mtd_read_page in a test, it fails for unaligned size, because the work are is not there.

Proposal: allocate work_area when write_size is not 1?

Proposal: allocate work_area when write_size is not 1?

still should be depended on a module (and then on init) - you don't want to pull on all that malloc and copy-on-write code if you just have a fatfs and don't want to interact with the raw MTD

Murdock results

✔️ PASSED

9e7a269 drivers/mtd: prevent work_area double allocation

Artifacts

• Documentation preview