STRUCT NAND_PAGE_IO_REQ(9)
β¨ struct nand_page_io_req β the NAND I/O request object π
okay so bestie, welcome to the Kernel API Manual, we're talking about struct nand_page_io_req today and it's genuinely iconic β it's the little bundle of info that carries one single page I/O request down into the NAND sub-layers. π
πΈ SYNOPSIS πΈ
struct nand_page_io_req {
enum nand_page_io_req_type type;
struct nand_pos pos;
unsigned int dataoffs;
unsigned int datalen;
union {
const void *out;
void *in;
} databuf;
unsigned int ooboffs;
unsigned int ooblen;
union {
const void *out;
void *in;
} oobbuf;
int mode;
bool continuous;
};
no cap, that's the whole vibe. now let's meet the members one by one π«Ά
π MEMBERS π
typeβ the type of page I/O, likeβ¦ are we reading or writing? that's literally it, that's the whole personality πposβ the position this I/O request is targeting π«dataoffsβ the offset within the page βdatalenβ number of data bytes to read from/write to this page π₯databufβ buffer to store data in or get data from, depending on which way the vibes flow πooboffsβ the OOB offset within the page π¦ooblenβ the number of OOB bytes to read from/write to this page πΈoobbufβ buffer to store OOB data in or get OOB data from πmodeβ one of theMTD_OPS_XXXmode πcontinuousβ no need to start over the operation at the end of each page, the NAND device will automatically prepare the next one π (this one is lowkey main character energy, it just keeps going)
π¦ DESCRIPTION π¦
So this object is what you use to pass per-page I/O requests to the NAND sub-layers. β¨
The way that works is kind of genius actually: all the useful information is already formatted in a useful way, so specific NAND layers can just focus on translating that info into specific commands/operations instead of doing a whole scavenger hunt. ate and left no crumbs. π
π SEE ALSO π
Kernel file ./include/linux/mtd/nand.h struct, plus literally the entire friend group:
nand_memory_organization(9)struct nand_row_converter(9)struct nand_pos(9)enum nand_page_io_req_type(9)enum nand_ecc_engine_type(9)enum nand_ecc_placement(9)enum nand_ecc_algo(9)struct nand_ecc_props(9)struct nand_bbt(9)struct nand_ops(9)struct nand_ecc_context(9)struct nand_ecc_engine_ops(9)enum nand_ecc_engine_integration(9)struct nand_ecc_engine(9)struct nand_ecc_req_tweak_ctx(9)struct nand_ecc(9)struct nand_device(9)struct nand_io_iter(9)mtd_to_nanddev(9)nanddev_to_mtd(9)nanddev_page_size(9)nanddev_per_page_oobsize(9)nanddev_pages_per_eraseblock(9)nanddev_pages_per_target(9)nanddev_eraseblocks_per_lun(9)nanddev_eraseblocks_per_target(9)nanddev_target_size(9)nanddev_neraseblocks(9)nanddev_size(9)nanddev_get_memorg(9)nanddev_get_ecc_conf(9)nanddev_get_ecc_nsteps(9)nanddev_get_ecc_bytes_per_step(9)nanddev_get_ecc_requirements(9)nanddev_set_ecc_requirements(9)nanddev_register(9)nanddev_unregister(9)nanddev_set_of_node(9)nanddev_get_of_node(9)nanddev_offs_to_pos(9)nanddev_pos_cmp(9)nanddev_pos_to_offs(9)nanddev_pos_to_row(9)nanddev_pos_next_target(9)nanddev_pos_next_lun(9)nanddev_pos_next_eraseblock(9)nanddev_pos_next_page(9)nanddev_bbt_pos_to_entry(9)nanddev_bbt_is_initialized(9)
okay that's the whole page bestie, ily, go read some NAND headers π
this lil manifesto lives in ./include/linux/mtd and it's dated October 2026 β so yeah, mark your calendars, the future is now, periodt. π§ββοΈβπ
π¦ where this page comes from
- nixpkgs unstable: linux-manual 7.3.1
- π girlified by deepseek-ai/DeepSeek-V4.1-Flash-1017 on : a language model's rewrite of the original, under its terms