[riot-notifications] [RIOT-OS/RIOT] mtd: add page addressed operations to allow access > 4GiB on SD cards (#14038)

benpicco notifications at github.com
Thu May 7 10:42:55 CEST 2020

@benpicco commented on this pull request.

> @@ -50,6 +50,21 @@ int mtd_read(mtd_dev_t *mtd, void *dest, uint32_t addr, uint32_t count)
+int mtd_read_page(mtd_dev_t *mtd, void *dest, uint32_t page, uint16_t offset, uint32_t count)
+    if (!mtd || !mtd->driver) {
+        return -ENODEV;
+    }

Yea I also noticed that with the current MTD API, the burden is on the *file system* adaption code to ensure writes to not exceed a page and implement the chunking.
This is of course a silly duplication and the point of the intermediate layer should be that the consumers don't have to care about the implementation details.

That's why I added WIP - I'll change the low-level `write_page` function to operate like the internal [`_write_page`](https://github.com/RIOT-OS/RIOT/blob/master/drivers/at25xxx/at25xxx.c#L84) in `at25xxx.c`. Write as many bytes as fit into the current page, don't try anything clever and return the number of written bytes.

`mtd_write_page()` will then use that to split up however many bytes the user wants to write (like [`at25xxx_write()`](https://github.com/RIOT-OS/RIOT/blob/master/drivers/at25xxx/at25xxx.c#L125)

That way we can pull that logic out of the drivers and into a common place - and users of the MTD API don't have to care about the properties of the underlying storage media.

You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.riot-os.org/pipermail/notifications/attachments/20200507/18638af9/attachment.htm>

More information about the notifications mailing list