ioremap(9)

πŸ“¦ version 7.3.1, in nixpkgs unstable

πŸ’… ioremap(9) β€” the kernel API manual glow-up

okay so bestie, buckle up, we're talking about ioremap β€” the ioremap(9) page from the Kernel API Manual. it maps bus memory into CPU space and honestly it's giving bridge-between-worlds main character energy πŸŒ‰βœ¨


🌸 NAME 🌸

ioremap β€” map bus memory into CPU space. literally its whole job, no cap πŸ’…


✨ SYNOPSIS ✨

void __iomem * ioremap (resource_size_t phys_addr , unsigned long size );

πŸŽ€ ARGUMENTS πŸŽ€

  • phys_addr β€” the bus address of the memory, i.e. where the thing lives on the bus 🚌
  • size β€” the size of the resource you wanna map, so the kernel knows how much to grab 🫢

πŸ¦‹ DESCRIPTION πŸ¦‹

okay so ioremap performs a platform specific sequence of operations to make bus memory CPU accessible via the readb/readw/readl/writeb/writew/writel functions and the other mmio helpers. slay. that's the entire point of it existing πŸ’–

but heads up: the returned address is not guaranteed to be usable directly as a virtual address. so like... don't just go dereferencing it raw, bestie, that's not the vibe πŸ™ˆ

this version of ioremap ensures that the memory is marked uncachable on the CPU as well as honouring existing caching rules from things like the PCI bus. note that there are other caches and buffers on many busses β€” so yes, ioremap did its part, but the world is bigger than one function 😭 in particular, driver authors should read up on PCI writes. fr fr, go read up on PCI writes, it's important.

it's useful if some control registers are in such an area and write combining or read caching is not desirable:

🚨 and like, the actual rule that matters most: must be freed with iounmap. no leaking, no leaving it mapped forever, we don't do that here πŸ’€

⭐ SEE ALSO ⭐


and that's the tea πŸ“ this icon came from ./arch/x86/mm and it's dated October 2026 β€” so yeah, freshly stamped and still iconic. go map responsibly, bestie πŸ’œβœ¨

πŸ“¦ where this page comes from