BUS_SPACE(9)

💅 BUS_SPACE(9) 💅

okay so this is the Kernel Developer's Manual page for BUS_SPACE(9) — aka the bus space manipulation functions. it's giving low-level hardware access, main character energy, and a whole lot of function names. no cap. ✨

---

🎀 NAME 🎀

bestie, the NAME section is literally a roster. here's every single one, exactly as the page lists them (yes, even the ones that look like a keyboard smash):

• bus_space, bus_space_barrier
• bus_space_copy_region_1, bus_space_copy_region_2, bus_space_copy_region_4, bus_space_copy_region_8
• bus_space_copy_region_stream_1, bus_space_copy_region_stream_2, bus_space_copy_region_stream_4, bus_space_copy_region_stream_8
• bus_space_free, bus_space_map
• bus_space_read_1, bus_space_read_2, bus_space_read_4, bus_space_read_8
• bus_space_read_multi_1, bus_space_read_multi_2, bus_space_read_multi_4, bus_space_read_multi_8
• bus_space_read_multi_stream_1, bus_space_read_multi_stream_2, bus_space_read_multi_stream_4, bus_space_read_multi_stream_8
• bus_space_read_region_1, bus_space_read_region_2, bus_space_read_region_4, bus_space_read_region_8
• bus_space_read_region_stream_1, bus_space_read_region_stream_2, bus_space_read_region_stream_4, bus_space_read_region_stream_8
• bus_space_read_stream_1, bus_space_read_stream_2, bus_space_read_stream_4, bus_space_read_stream_8
• bus_space_set_multi_1, bus_space_set_multi_2, bus_space_set_multi_4, bus_space_set_multi_8
• bus_space_set_multi_stream_1, bus_space_set_multi_stream_2, bus_space_set_multi_stream_4, bus_space_set_multi_stream_8
• bus_space_set_region_1, bus_space_set_region_2, bus_space_set_region_4, bus_space_set_region_8
• bus_space_set_region_stream_1, bus_space_set_region_stream_2, bus_space_set_region_stream_4, bus_space_set_region_stream_8
• bus_space_subregion, bus_space_unmap
• bus_space_write_1, bus_space_write_2, bus_space_write_4, bus_space_write_8
• bus_space_write_multi_1, bus_space_write_multi_2, bus_space_write_multi_4, bus_space_write_multi_8
• bus_space_write_multi_stream_1, bus_space_write_multi_stream_2, bus_space_write_multi_stream_4, bus_space_write_multi_stream_8
• bus_space_write_region_1, bus_space_write_region_2, bus_space_write_region_4, bus_space_write_region_8
• bus_space_write_region_stream_1, bus_space_write_region_stream_2, bus_space_write_region_stream_4, bus_space_write_region_stream_8
• bus_space_write_stream_1, bus_space_write_stream_2, bus_space_write_stream_4, bus_space_write_stream_8

— bus space manipulation functions 💖

---

✨ SYNOPSIS ✨

bestie, the synopsis is a whole mood. it's giving "I contain multitudes" because there are so many function signatures. here they are, exactly as written, no cap:

#include <machine/bus.h>

int
bus_space_map(bus_space_tag_t space, bus_addr_t address,
    bus_size_t size, int flags, bus_space_handle_t *handlep);

void
bus_space_unmap(bus_space_tag_t space, bus_space_handle_t handle,
    bus_size_t size);

int
bus_space_subregion(bus_space_tag_t space, bus_space_handle_t handle,
    bus_size_t offset, bus_size_t size, bus_space_handle_t *nhandlep);

int
bus_space_alloc(bus_space_tag_t space, bus_addr_t reg_start,
    bus_addr_t reg_end, bus_size_t size, bus_size_t alignment,
    bus_size_t boundary, int flags, bus_addr_t *addrp,
    bus_space_handle_t *handlep);

void
bus_space_free(bus_space_tag_t space, bus_space_handle_t handle,
    bus_size_t size);

uint8_t
bus_space_read_1(bus_space_tag_t space, bus_space_handle_t handle,
    bus_size_t offset);

uint16_t
bus_space_read_2(bus_space_tag_t space, bus_space_handle_t handle,
    bus_size_t offset);

uint32_t
bus_space_read_4(bus_space_tag_t space, bus_space_handle_t handle,
    bus_size_t offset);

uint64_t
bus_space_read_8(bus_space_tag_t space, bus_space_handle_t handle,
    bus_size_t offset);

uint8_t
bus_space_read_stream_1(bus_space_tag_t space,
    bus_space_handle_t handle, bus_size_t offset);

uint16_t
bus_space_read_stream_2(bus_space_tag_t space,
    bus_space_handle_t handle, bus_size_t offset);

uint32_t
bus_space_read_stream_4(bus_space_tag_t space,
    bus_space_handle_t handle, bus_size_t offset);

uint64_t
bus_space_read_stream_8(bus_space_tag_t space,
    bus_space_handle_t handle, bus_size_t offset);

void
bus_space_write_1(bus_space_tag_t space, bus_space_handle_t handle,
    bus_size_t offset, uint8_t value);

void
bus_space_write_2(bus_space_tag_t space, bus_space_handle_t handle,
    bus_size_t offset, uint16_t value);

void
bus_space_write_4(bus_space_tag_t space, bus_space_handle_t handle,
    bus_size_t offset, uint32_t value);

void
bus_space_write_8(bus_space_tag_t space, bus_space_handle_t handle,
    bus_size_t offset, uint64_t value);

void
bus_space_write_stream_1(bus_space_tag_t space,
    bus_space_handle_t handle, bus_size_t offset, uint8_t value);

void
bus_space_write_stream_2(bus_space_tag_t space,
    bus_space_handle_t handle, bus_size_t offset, uint16_t value);

void
bus_space_write_stream_4(bus_space_tag_t space,
    bus_space_handle_t handle, bus_size_t offset, uint32_t value);

void
bus_space_write_stream_8(bus_space_tag_t space,
    bus_space_handle_t handle, bus_size_t offset, uint64_t value);

void
bus_space_barrier(bus_space_tag_t space, bus_space_handle_t handle,
    bus_size_t offset, bus_size_t length, int flags);

void
bus_space_read_region_1(bus_space_tag_t space,
    bus_space_handle_t handle, bus_size_t offset, uint8_t *datap,
    bus_size_t count);

void
bus_space_read_region_2(bus_space_tag_t space,
    bus_space_handle_t handle, bus_size_t offset, uint16_t *datap,
    bus_size_t count);

void
bus_space_read_region_4(bus_space_tag_t space,
    bus_space_handle_t handle, bus_size_t offset, uint32_t *datap,
    bus_size_t count);

void
bus_space_read_region_8(bus_space_tag_t space,
    bus_space_handle_t handle, bus_size_t offset, uint64_t *datap,
    bus_size_t count);

void
bus_space_read_region_stream_1(bus_space_tag_t space,
    bus_space_handle_t handle, bus_size_t offset, uint8_t *datap,
    bus_size_t count);

void
bus_space_read_region_stream_2(bus_space_tag_t space,
    bus_space_handle_t handle, bus_size_t offset, uint16_t *datap,
    bus_size_t count);

void
bus_space_read_region_stream_4(bus_space_tag_t space,
    bus_space_handle_t handle, bus_size_t offset, uint32_t *datap,
    bus_size_t count);

void
bus_space_read_region_stream_8(bus_space_tag_t space,
    bus_space_handle_t handle, bus_size_t offset, uint64_t *datap,
    bus_size_t count);

void
bus_space_write_region_1(bus_space_tag_t space,
    bus_space_handle_t handle, bus_size_t offset, uint8_t *datap,
    bus_size_t count);

void
bus_space_write_region_2(bus_space_tag_t space,
    bus_space_handle_t handle, bus_size_t offset, uint16_t *datap,
    bus_size_t count);

void
bus_space_write_region_4(bus_space_tag_t space,
    bus_space_handle_t handle, bus_size_t offset, uint32_t *datap,
    bus_size_t count);

void
bus_space_write_region_8(bus_space_tag_t space,
    bus_space_handle_t handle, bus_size_t offset, uint64_t *datap,
    bus_size_t count);

void
bus_space_write_region_stream_1(bus_space_tag_t space,
    bus_space_handle_t handle, bus_size_t offset, uint8_t *datap,
    bus_size_t count);

void
bus_space_write_region_stream_2(bus_space_tag_t space,
    bus_space_handle_t handle, bus_size_t offset, uint16_t *datap,
    bus_size_t count);

void
bus_space_write_region_stream_4(bus_space_tag_t space,
    bus_space_handle_t handle, bus_size_t offset, uint32_t *datap,
    bus_size_t count);

void
bus_space_write_region_stream_8(bus_space_tag_t space,
    bus_space_handle_t handle, bus_size_t offset, uint64_t *datap,
    bus_size_t count);

void
bus_space_copy_region_1(bus_space_tag_t space,
    bus_space_handle_t srchandle, bus_size_t srcoffset,
    bus_space_handle_t dsthandle, bus_size_t dstoffset,
    bus_size_t count);

void
bus_space_copy_region_2(bus_space_tag_t space,
    bus_space_handle_t srchandle, bus_size_t srcoffset,
    bus_space_handle_t dsthandle, bus_size_t dstoffset,
    bus_size_t count);

void
bus_space_copy_region_4(bus_space_tag_t space,
    bus_space_handle_t srchandle, bus_size_t srcoffset,
    bus_space_handle_t dsthandle, bus_size_t dstoffset,
    bus_size_t count);

void
bus_space_copy_region_8(bus_space_tag_t space,
    bus_space_handle_t srchandle, bus_size_t srcoffset,
    bus_space_handle_t dsthandle, bus_size_t dstoffset,
    bus_size_t count);

void
bus_space_copy_region_stream_1(bus_space_tag_t space,
    bus_space_handle_t srchandle, bus_size_t srcoffset,
    bus_space_handle_t dsthandle, bus_size_t dstoffset,
    bus_size_t count);

void
bus_space_copy_region_stream_2(bus_space_tag_t space,
    bus_space_handle_t srchandle, bus_size_t srcoffset,
    bus_space_handle_t dsthandle, bus_size_t dstoffset,
    bus_size_t count);

void
bus_space_copy_region_stream_4(bus_space_tag_t space,
    bus_space_handle_t srchandle, bus_size_t srcoffset,
    bus_space_handle_t dsthandle, bus_size_t dstoffset,
    bus_size_t count);

void
bus_space_copy_region_stream_8(bus_space_tag_t space,
    bus_space_handle_t srchandle, bus_size_t srcoffset,
    bus_space_handle_t dsthandle, bus_size_t dstoffset,
    bus_size_t count);

void
bus_space_set_region_1(bus_space_tag_t space, bus_space_handle_t handle,
    bus_size_t offset, uint8_t value, bus_size_t count);

void
bus_space_set_region_2(bus_space_tag_t space, bus_space_handle_t handle,
    bus_size_t offset, uint16_t value, bus_size_t count);

void
bus_space_set_region_4(bus_space_tag_t space, bus_space_handle_t handle,
    bus_size_t offset, uint32_t value, bus_size_t count);

void
bus_space_set_region_8(bus_space_tag_t space, bus_space_handle_t handle,
    bus_size_t offset, uint64_t value, bus_size_t count);

void
bus_space_set_region_stream_1(bus_space_tag_t space,
    bus_space_handle_t handle, bus_size_t offset, uint8_t value,
    bus_size_t count);

void
bus_space_set_region_stream_2(bus_space_tag_t space,
    bus_space_handle_t handle, bus_size_t offset, uint16_t value,
    bus_size_t count);

void
bus_space_set_region_stream_4(bus_space_tag_t space,
    bus_space_handle_t handle, bus_size_t offset, uint32_t value,
    bus_size_t count);

void
bus_space_set_region_stream_8(bus_space_tag_t space,
    bus_space_handle_t handle, bus_size_t offset, uint64_t value,
    bus_size_t count);

void
bus_space_read_multi_1(bus_space_tag_t space, bus_space_handle_t handle,
    bus_size_t offset, uint8_t *datap, bus_size_t count);

void
bus_space_read_multi_2(bus_space_tag_t space, bus_space_handle_t handle,
    bus_size_t offset, uint16_t *datap, bus_size_t count);

void
bus_space_read_multi_4(bus_space_tag_t space, bus_space_handle_t handle,
    bus_size_t offset, uint32_t *datap, bus_size_t count);

void
bus_space_read_multi_8(bus_space_tag_t space, bus_space_handle_t handle,
    bus_size_t offset, uint64_t *datap, bus_size_t count);

void
bus_space_read_multi_stream_1(bus_space_tag_t space,
    bus_space_handle_t handle, bus_size_t offset, uint8_t *datap,
    bus_size_t count);

void
bus_space_read_multi_stream_2(bus_space_tag_t space,
    bus_space_handle_t handle, bus_size_t offset, uint16_t *datap,
    bus_size_t count);

void
bus_space_read_multi_stream_4(bus_space_tag_t space,
    bus_space_handle_t handle, bus_size_t offset, uint32_t *datap,
    bus_size_t count);

void
bus_space_read_multi_stream_8(bus_space_tag_t space,
    bus_space_handle_t handle, bus_size_t offset, uint64_t *datap,
    bus_size_t count);

void
bus_space_write_multi_1(bus_space_tag_t space,
    bus_space_handle_t handle, bus_size_t offset, uint8_t *datap,
    bus_size_t count);

void
bus_space_write_multi_2(bus_space_tag_t space,
    bus_space_handle_t handle, bus_size_t offset, uint16_t *datap,
    bus_size_t count);

void
bus_space_write_multi_4(bus_space_tag_t space,
    bus_space_handle_t handle, bus_size_t offset, uint32_t *datap,
    bus_size_t count);

void
bus_space_write_multi_8(bus_space_tag_t space,
    bus_space_handle_t handle, bus_size_t offset, uint64_t *datap,
    bus_size_t count);

void
bus_space_write_multi_stream_1(bus_space_tag_t space,
    bus_space_handle_t handle, bus_size_t offset, uint8_t *datap,
    bus_size_t count);

void
bus_space_write_multi_stream_2(bus_space_tag_t space,
    bus_space_handle_t handle, bus_size_t offset, uint16_t *datap,
    bus_size_t count);

void
bus_space_write_multi_stream_4(bus_space_tag_t space,
    bus_space_handle_t handle, bus_size_t offset, uint32_t *datap,
    bus_size_t count);

void
bus_space_write_multi_stream_8(bus_space_tag_t space,
    bus_space_handle_t handle, bus_size_t offset, uint64_t *datap,
    bus_size_t count);

void
bus_space_set_multi_1(bus_space_tag_t space, bus_space_handle_t handle,
    bus_size_t offset, uint8_t value, bus_size_t count);

void
bus_space_set_multi_2(bus_space_tag_t space, bus_space_handle_t handle,
    bus_size_t offset, uint16_t value, bus_size_t count);

void
bus_space_set_multi_4(bus_space_tag_t space, bus_space_handle_t handle,
    bus_size_t offset, uint32_t value, bus_size_t count);

void
bus_space_set_multi_8(bus_space_tag_t space, bus_space_handle_t handle,
    bus_size_t offset, uint64_t value, bus_size_t count);

void
bus_space_set_multi_stream_1(bus_space_tag_t space,
    bus_space_handle_t handle, bus_size_t offset, uint8_t value,
    bus_size_t count);

void
bus_space_set_multi_stream_2(bus_space_tag_t space,
    bus_space_handle_t handle, bus_size_t offset, uint16_t value,
    bus_size_t count);

void
bus_space_set_multi_stream_4(bus_space_tag_t space,
    bus_space_handle_t handle, bus_size_t offset, uint32_t value,
    bus_size_t count);

void
bus_space_set_multi_stream_8(bus_space_tag_t space,
    bus_space_handle_t handle, bus_size_t offset, uint64_t value,
    bus_size_t count);

---

✨ DESCRIPTION ✨

okay so bestie, here's the whole why of the bus_space functions: they exist so that device drivers can get at bus memory and register areas in a way that's machine-independent. 💅 Every single function and type in this page? You get them all by including the <machine/bus.h> header file. that's the ticket. 🎟️

So here's the tea 🍓: tons of common devices get used on multiple architectures, but you have to poke them differently on each one because of architectural constraints. Like, a device that's mapped in one system's I/O space might be mapped in memory space on a second system. And then on a third system, architectural limitations might change the way registers even need to be accessed (think: creating a non-linear register space, iconic of them honestly). And sometimes a single driver has to access the same type of device in multiple ways within a single system or architecture. 🙈

The whole goal of the bus_space functions is this: let a single driver source file manipulate a set of devices across different system architectures, and let a single driver object file manipulate a set of devices on multiple bus types on a single architecture. slay. 👑

• Not every bus has to implement every function described in this document — though honestly that's encouraged if the operations are logically supported by the bus.
• Unimplemented functions should cause compile-time errors if possible. (let the compiler yell at you, it's a love language 💀)

All the interface definitions in this doc are shown as function prototypes and discussed as if they had to be functions. Implementations are encouraged to implement prototyped (type-checked) versions of these interfaces, but they may implement them as macros if that's appropriate. 🪄

Machine-dependent types, variables, and functions should be marked clearly in <machine/bus.h> so nobody gets them confused with the machine-independent types and functions — and, if possible, they should get names that make the machine-dependence obvious. clarity is self-care, periodt. 🌸

---

🌈 CONCEPTS AND GUIDELINES 🌈

Bus spaces are described by bus space tags, and bestie, those can only be created by machine-dependent code. 🔒 A given machine might have several different types of bus space (say, memory space and I/O space), and so it may hand you multiple different bus space tags. Individual buses or devices on a machine may use more than one bus space tag — for instance, ISA devices get an ISA memory space tag and an ISA I/O space tag. Architectures can have several different tags representing the same type of space, like when there are multiple different host bus interface chipsets. the way there's always another chipset 😭

A range in bus space is described by a bus address and a bus size. The bus address = where the range starts in bus space. The bus size = how big the range is, in bytes. Buses that aren't byte addressable may require bus space ranges with appropriately aligned addresses and properly rounded sizes. don't fight it, just align it. 📏

Access to regions of bus space happens through bus space handles, which are usually created by mapping a specific range of a bus space. Handles can also be created by allocating and mapping a range of bus space, where the actual location gets picked by the implementation, inside bounds that the caller of the allocation function specifies. ✨

Every single bus space access function needs one bus_space_tag_t argument, at least one handle argument, and at least one offset argument (a bus size). The tag says which space, each handle says which region in that space, and each offset says how far into the region the actual location(s) you're accessing live. Offsets are given in bytes, though buses may impose alignment constraints. 🧮

The offset you use to access data relative to a given handle must be such that all the data being accessed is inside the mapped region that the handle describes. Trying to access data outside that region is an error. 🙅‍♀️

Because some architectures' memory systems use buffering to make memory and device access faster, there's a mechanism you can use to create “barriers” in the bus space read and write stream. There are three types of barriers: read, write, and read/write.

• All reads started to the region before a read barrier must complete before any reads after the read barrier are started.
• The analogous requirement is true for write barriers.
• Read/write barriers force all reads and writes started before the barrier to complete before any reads or writes after the barrier are started.

Correctly-written drivers will include all the appropriate barriers, and assume only the read/write ordering imposed by the barrier operations. no vibes-based ordering, bestie, only barrier-based ordering. 🚧

If you're trying to write portable drivers with the bus_space functions, make minimal assumptions about what the system allows. In particular, expect that:

• the system requires bus space addresses being accessed to be naturally aligned (i.e., base address of handle added to offset is a multiple of the access size), and
• the system does alignment checking on pointers (i.e., pointer to objects being read and written must point to properly-aligned data).

Every bus_space function description below assumes it's being called with proper arguments. Call it with invalid arguments or arguments that are out of range (like, trying to access data outside the region mapped when a given handle was created) and you get undefined behaviour. 😳

In that case they may cause the system to halt — either intentionally (via panic) or unintentionally (by causing a fatal trap or by some other means) — or they may cause improper operation that isn't immediately fatal. 💀

Functions that return void, or that return data read from bus space (i.e., functions that don't obviously return an error code), do not fail. They could only fail if given invalid arguments, and in that case their behaviour is undefined. And functions that take a count of bytes have undefined results if the specified count is zero. zero is not a vibe. 🙈

---

🎀 TYPES 🎀

Several types are defined in <machine/bus.h> to make life easier for drivers using the bus_space functions. let's meet the cast 🫶

bus_addr_t

The bus_addr_t type is used to describe bus addresses. It must be an unsigned integral type capable of holding the largest bus address usable by the architecture. This type is primarily used when mapping and unmapping bus space. 🗺️

bus_size_t

The bus_size_t type is used to describe sizes of ranges in bus space. It must be an unsigned integral type capable of holding the size of the largest bus address range usable on the architecture. This type gets used by virtually all of the bus_space functions — it describes sizes when mapping regions, and offsets into regions when doing space access operations. 📐

bus_space_tag_t

The bus_space_tag_t type is used to describe a particular bus space on a machine. Its contents are machine-dependent and should be considered opaque by machine-independent code. 🙈 Every bus_space function uses this type to name the space it's operating on. 🏷️

bus_space_handle_t

The bus_space_handle_t type is used to describe a mapping of a range of bus space. Its contents are machine-dependent and should be considered opaque by machine-independent code. This type is used when performing bus space access operations. 💫

🌸 MAPPING AND UNMAPPING BUS SPACE 🌸

okay so bestie, real talk first: this entire section is specific to the NetBSD version of these functions and it may or may not apply to the FreeBSD version. so like, know which one you're on, iykyk. 💅

Bus space has to be mapped before you can even use it, and it should be unmapped once you don't need it anymore. like, clean up after yourself, it's giving basic hygiene. bus_space_map() and bus_space_unmap() are the two functions that handle this whole situation.

Some drivers need to be able to hand a subregion of already-mapped bus space off to another driver, or to a module inside a driver. bus_space_subregion() is the function that lets you make those subregions happen. 🦋

---

bus_space_map(space, address, size, flags, handlep)

The bus_space_map() function maps the region of bus space named by the space, address, and size arguments. If it works, it returns zero and fills in the bus space handle pointed to by handlep with the handle you can use to access that mapped region. If it doesn't work, it returns non-zero and leaves the bus space handle pointed to by handlep in an undefined state. 🙈

The flags argument controls how the space gets mapped. The supported flags include:

• BUS_SPACE_MAP_CACHEABLE — try to map the space so that accesses can be cached and/or prefetched by the system. If you don't specify this flag, the implementation should map the space so it will not be cached or prefetched.

🚨 bestie heads up: this flag must have a value of 1 on all implementations, for backward compatibility. no cap.

• BUS_SPACE_MAP_LINEAR — try to map the space so its contents can be accessed linearly via normal memory access methods (e.g. pointer dereferencing and structure accesses). this is so useful when software wants to do direct access to a memory device, e.g. a frame buffer. If you specify this flag and linear mapping isn't possible, the bus_space_map() call should fail. If you don't specify it, the system may map the space in whatever way is most convenient. slay, flexible.

Not every combination of flags makes sense, and not every combination is supported with every space. For instance, BUS_SPACE_MAP_CACHEABLE may be meaningless when used on many systems' I/O port spaces, and on some systems BUS_SPACE_MAP_LINEAR without BUS_SPACE_MAP_CACHEABLE may never work. 💀 When the system hardware or firmware hands you hints about how spaces should be mapped (e.g. the PCI memory mapping registers' “prefetchable” bit), you should follow those hints for maximum compatibility. On some systems, requesting a mapping that can't be satisfied (e.g. asking for a non-cacheable mapping when the system can only give you a cacheable one) will cause the request to fail.

Some implementations may keep track of how bus space is being used, for some or all bus spaces, and refuse to allow duplicate allocations. This is encouraged for bus spaces that have no notion of slot-specific space addressing, like ISA, and for spaces that coexist with those spaces (e.g. PCI memory and I/O spaces co-existing with ISA memory and I/O spaces). 👑

Mapped regions may contain areas where there's no device on the bus. If space in those areas gets accessed, the results are bus-dependent. so like, don't. 😭

---

bus_space_unmap(space, handle, size)

The bus_space_unmap() function unmaps a region of bus space that was mapped with bus_space_map(). When you're unmapping a region, the size you specify should be the same size you gave to bus_space_map() when you mapped that region.

After bus_space_unmap() is called on a handle, that handle is no longer valid. (And if copies were made of the handle, those are no longer valid either.) 🙈

This function will never fail. If it would fail (e.g. because of an argument error), that indicates a software bug which should cause a panic. In that case, bus_space_unmap() will never return. 💀

---

bus_space_subregion(space, handle, offset, size, nhandlep)

The bus_space_subregion() function is a little convenience function that makes a new handle to some subregion of an already-mapped region of bus space. The subregion described by the new handle starts at byte offset offset into the region described by handle, with the size given by size, and it must be wholly contained within the original region. no partial overflow situations, bestie.

If it works, bus_space_subregion() returns zero and fills in the bus space handle pointed to by nhandlep. If it doesn't work, it returns non-zero and leaves the bus space handle pointed to by nhandlep in an undefined state. Either way, the handle described by handle stays valid and is unmodified. 🫶

When you're done with a handle created by bus_space_subregion(), you should just throw it away. Under no circumstances should bus_space_unmap() be used on that handle. Doing so may confuse any resource management being done on the space, and will result in undefined behaviour. And when bus_space_unmap() or bus_space_free() is called on a handle, all subregions of that handle become invalid. periodt.

---

✨ ALLOCATING AND FREEING BUS SPACE ✨

and again, this section is specific to the NetBSD version of these functions and may or may not apply to the FreeBSD version. 💅

Some devices require bus space to be allocated by the operating system for device use, or at least allow it. When the devices don't need the space anymore, the operating system should free it so other devices can use it. bus_space_alloc() and bus_space_free() are the functions that make this happen. 🎀

---

bus_space_alloc(space, reg_start, reg_end, size, alignment, boundary, flags, addrp, handlep)

The bus_space_alloc() function allocates and maps a region of bus space with the size given by size, corresponding to the given constraints. If it works, it returns zero, fills in the bus address pointed to by addrp with the bus space address of the allocated region, and fills in the bus space handle pointed to by handlep with the handle you can use to access that region. If it doesn't work, it returns non-zero and leaves the bus address pointed to by addrp and the bus space handle pointed to by handlep in an undefined state. 😭

The constraints on the allocation are given by the reg_start, reg_end, alignment, and boundary parameters. The allocated region will start at or after reg_start and end before or at reg_end. The alignment constraint must be a power of two, and the allocated region will start at an address that's an even multiple of that power of two. The boundary constraint, if it's non-zero, makes sure the region is allocated so that first address in region / boundary has the same value as last address in region / boundary. If the constraints can't be met, bus_space_alloc() will fail. And it is an error to specify a set of constraints that can never be met (for example, size greater than boundary). don't do that. 💀

The flags parameter is the same as the like-named parameter to bus_space_map(), the same flag values should be used, and they have the same meanings. 🌈

Handles created by bus_space_alloc() should only be freed with bus_space_free(). Trying to use bus_space_unmap() on them causes undefined behaviour. The bus_space_subregion() function can be used on handles created by bus_space_alloc(). 🦋

---

bus_space_free(space, handle, size)

The bus_space_free() function unmaps and frees a region of bus space that was mapped and allocated with bus_space_alloc(). When you're unmapping a region, the size you specify should be the same size you gave to bus_space_alloc() when you allocated the region.

After bus_space_free() is called on a handle, that handle is no longer valid. (And if copies were made of the handle, they are no longer valid either.) 🙈

This function will never fail. If it would fail (e.g. because of an argument error), that indicates a software bug which should cause a panic. In that case, bus_space_free() will never return. 💀

---

👑 READING AND WRITING SINGLE DATA ITEMS 👑

The simplest way to access bus space is to read or write a single data item. The bus_space_read_N() and bus_space_write_N() families of functions give you the ability to read and write 1, 2, 4, and 8 byte data items on buses that support those access sizes. so like, the little guys. the basics. the starter pack. 🍓

---

bus_space_read_1(space, handle, offset)

bus_space_read_2(space, handle, offset)

bus_space_read_4(space, handle, offset)

bus_space_read_8(space, handle, offset)

The bus_space_read_N() family of functions reads a 1, 2, 4, or 8 byte data item from the offset specified by offset into the region specified by handle of the bus space specified by space. The location being read must lie within the bus space region specified by handle.

For portability, the starting address of the region specified by handle plus the offset should be a multiple of the size of the data item being read. On some systems, not obeying this requirement may cause incorrect data to be read, and on others it may cause a system crash. 💀 so like, please align. for me.

Read operations done by the bus_space_read_N() functions may be executed out of order with respect to other pending read and write operations, unless order is enforced by use of the bus_space_barrier() function.

These functions will never fail. If they would fail (e.g. because of an argument error), that indicates a software bug which should cause a panic. In that case, they will never return. 🙈

---

bus_space_write_1(space, handle, offset, value)

bus_space_write_2(space, handle, offset, value)

bus_space_write_4(space, handle, offset, value)

bus_space_write_8(space, handle, offset, value)

The bus_space_write_N() family of functions writes a 1, 2, 4, or 8 byte data item to the offset specified by offset into the region specified by handle of the bus space specified by space. The location being written must lie within the bus space region specified by handle.

For portability, the starting address of the region specified by handle plus the offset should be a multiple of the size of the data item being written. On some systems, not obeying this requirement may cause incorrect data to be written, and on others it may cause a system crash. 💀 same energy as before, bestie. align your stuff.

Write operations done by the bus_space_write_N() functions may be executed out of order with respect to other pending read and write operations, unless order is enforced by use of the bus_space_barrier() function.

These functions will never fail. If they would fail (e.g. because of an argument error), that indicates a software bug which should cause a panic. In that case, they will never return. 🙈

🚧 BARRIERS 🚧

Okay so bestie, listen up, because this is the part where the vibes get real. 🦋

So like, high-performance buffering implementations want to be lazy (iconic behavior honestly) and skip bus activity on every single operation. But that means read and write ordering has to be specified explicitly by drivers when it actually matters. And that's exactly what the bus_space_barrier() function is for. It's giving "you want order? you gotta ask for it." ✨

---

🎀 bus_space_barrier(space, handle, offset, length, flags)

The bus_space_barrier() function enforces ordering of bus space read and write operations for the specified subregion — that subregion being described by the offset and length parameters — of the region named by handle in the space named by space. 💅

The flags argument controls what types of operations are to be ordered. Supported flags are:

• BUS_SPACE_BARRIER_READ — synchronize read operations.
• BUS_SPACE_BARRIER_WRITE — synchronize write operations.

Those flags can be combined (or-ed together) to enforce ordering on both read and write operations. Slay. 🔥

All of the specified type(s) of operation which are done to the region before the barrier operation are guaranteed to complete before any of the specified type(s) of operation done after the barrier. No cap.

---

🧚 Example time, because iykyk

Consider a hypothetical device with two single-byte ports, one write-only input port (at offset 0) and a read-only output port (at offset 1). Operation of the device is as follows: data bytes are written to the input port, and are placed by the device on a stack, the top of which is read by reading from the output port. The sequence to correctly write two data bytes to the device then read those two data bytes back would be:

/*
 * t and h are the tag and handle for the mapped device's
 * space.
 */
bus_space_write_1(t, h, 0, data0);
bus_space_barrier(t, h, 0, 1, BUS_SPACE_BARRIER_WRITE);  /* 1 */
bus_space_write_1(t, h, 0, data1);
bus_space_barrier(t, h, 0, 2,
    BUS_SPACE_BARRIER_READ|BUS_SPACE_BARRIER_WRITE);     /* 2 */
ndata1 = bus_space_read_1(t, h, 1);
bus_space_barrier(t, h, 1, 1, BUS_SPACE_BARRIER_READ);   /* 3 */
ndata0 = bus_space_read_1(t, h, 1);
/* data0 == ndata0, data1 == ndata1 */

Let me break down each of those three barriers for you, because they each ate and left no crumbs 💖

• The first barrier makes sure that the first write finishes before the second write is issued, so that two writes to the input port are done in order and are not collapsed into a single write. This ensures that the data bytes are written to the device correctly and in order. 👑
• The second barrier makes sure that the writes to the output port finish before any of the reads to the input port are issued, thereby making sure that all of the writes are finished before data is read. This ensures that the first byte read from the device really is the last one that was written.
• The third barrier makes sure that the first read finishes before the second read is issued, ensuring that data is read correctly and in order. ✨

The barriers in the example above are specified to cover the absolute minimum number of bus space locations. It is correct (and often easier) to make barrier operations cover the device's whole range of bus space — that is, to specify an offset of zero and the size of the whole region. 🌈

---

📦 REGION OPERATIONS 📦

So some devices use buffers which are mapped as regions in bus space. Often, drivers want to copy the contents of those buffers to or from memory, e.g. into mbufs which can be passed to higher levels of the system, or from mbufs to be output to a network. In order to allow drivers to do this as efficiently as possible, the bus_space_read_region_N() and bus_space_write_region_N() families of functions are provided. 🫶

Drivers occasionally need to copy one region of a bus space to another, or to set all locations in a region of bus space to contain a single value. The bus_space_copy_region_N() family of functions and the bus_space_set_region_N() family of functions allow drivers to perform these operations. 🌸

---

💜 bus_space_read_region_1(space, handle, offset, datap, count)

💜 bus_space_read_region_2(space, handle, offset, datap, count)

💜 bus_space_read_region_4(space, handle, offset, datap, count)

💜 bus_space_read_region_8(space, handle, offset, datap, count)

The bus_space_read_region_N() family of functions reads count 1, 2, 4, or 8 byte data items from bus space starting at byte offset offset in the region specified by handle of the bus space specified by space, and writes them into the array specified by datap. Each successive data item is read from an offset 1, 2, 4, or 8 bytes after the previous data item (depending on which function is used). All locations being read must lie within the bus space region specified by handle. 🎀

For portability, the starting address of the region specified by handle plus the offset should be a multiple of the size of data items being read, and the data array pointer should be properly aligned. On some systems, not obeying these requirements may cause incorrect data to be read; on others it may cause a system crash. 😭

Read operations done by the bus_space_read_region_N() functions may be executed in any order. They may also be executed out of order with respect to other pending read and write operations unless order is enforced by use of the bus_space_barrier() function. There is no way to insert barriers between reads of individual bus space locations executed by the bus_space_read_region_N() functions. That's just how it is, bestie.

These functions will never fail. If they would fail (e.g. because of an argument error), that indicates a software bug which should cause a panic. In that case, they will never return. 💀

---

💙 bus_space_write_region_1(space, handle, offset, datap, count)

💙 bus_space_write_region_2(space, handle, offset, datap, count)

💙 bus_space_write_region_4(space, handle, offset, datap, count)

💙 bus_space_write_region_8(space, handle, offset, datap, count)

The bus_space_write_region_N() family of functions reads count 1, 2, 4, or 8 byte data items from the array specified by datap and writes them to bus space starting at byte offset offset in the region specified by handle of the bus space specified by space. Each successive data item is written to an offset 1, 2, 4, or 8 bytes after the previous data item (depending on which function is used). All locations being written must lie within the bus space region specified by handle. ✨

For portability, the starting address of the region specified by handle plus the offset should be a multiple of the size of data items being written, and the data array pointer should be properly aligned. On some systems, not obeying these requirements may cause incorrect data to be written; on others it may cause a system crash. 😭

Write operations done by the bus_space_write_region_N() functions may be executed in any order. They may also be executed out of order with respect to other pending read and write operations unless order is enforced by use of the bus_space_barrier() function. There is no way to insert barriers between writes of individual bus space locations executed by the bus_space_write_region_N() functions.

These functions will never fail. If they would fail (e.g. because of an argument error), that indicates a software bug which should cause a panic. In that case, they will never return. 💀

---

🦋 bus_space_copy_region_1(space, srchandle, srcoffset, dsthandle, dstoffset, count)

🦋 bus_space_copy_region_2(space, srchandle, srcoffset, dsthandle, dstoffset, count)

🦋 bus_space_copy_region_4(space, srchandle, srcoffset, dsthandle, dstoffset, count)

🦋 bus_space_copy_region_8(space, srchandle, srcoffset, dsthandle, dstoffset, count)

The bus_space_copy_region_N() family of functions copies count 1, 2, 4, or 8 byte data items in bus space from the area starting at byte offset srcoffset in the region specified by srchandle of the bus space specified by space, to the area starting at byte offset dstoffset in the region specified by dsthandle in the same bus space. Each successive data item read or written has an offset 1, 2, 4, or 8 bytes after the previous data item (depending on which function is used). All locations being read and written must lie within the bus space region specified by their respective handles. 💅

For portability, the starting addresses of the regions specified by each handle plus its respective offset should be a multiple of the size of data items being copied. On some systems, not obeying this requirement may cause incorrect data to be copied; on others it may cause a system crash. 😭

Read and write operations done by the bus_space_copy_region_N() functions may be executed in any order. They may also be executed out of order with respect to other pending read and write operations unless order is enforced by use of the bus_space_barrier() function. There is no way to insert barriers between reads or writes of individual bus space locations executed by the bus_space_copy_region_N() functions.

Overlapping copies between different subregions of a single region of bus space are handled correctly by the bus_space_copy_region_N() functions. That's the one thing they got right for you. 🫶

These functions will never fail. If they would fail (e.g. because of an argument error), that indicates a software bug which should cause a panic. In that case, they will never return. 💀

---

🌸 bus_space_set_region_1(space, handle, offset, value, count)

🌸 bus_space_set_region_2(space, handle, offset, value, count)

🌸 bus_space_set_region_4(space, handle, offset, value, count)

🌸 bus_space_set_region_8(space, handle, offset, value, count)

The bus_space_set_region_N() family of functions writes the given value to count 1, 2, 4, or 8 byte data items in bus space starting at byte offset offset in the region specified by handle of the bus space specified by space. Each successive data item has an offset 1, 2, 4, or 8 bytes after the previous data item (depending on which function is used). All locations being written must lie within the bus space region specified by handle. 🎀

For portability, the starting address of the region specified by handle plus the offset should be a multiple of the size of data items being written. On some systems, not obeying this requirement may cause incorrect data to be written; on others it may cause a system crash. 😭

Write operations done by the bus_space_set_region_N() functions may be executed in any order. They may also be executed out of order with respect to other pending read and write operations unless order is enforced by use of the bus_space_barrier() function. There is no way to insert barriers between writes of individual bus space locations executed by the bus_space_set_region_N() functions. 🙈

These functions will never fail. If they would fail (e.g. because of an argument error), that indicates a software bug which should cause a panic. In that case, they will never return. 💀

✨ READING AND WRITING A SINGLE LOCATION MULTIPLE TIMES ✨

okay so some devices are lowkey extra and have single locations in bus space that you gotta read or write multiple times to actually move data around — think ethernet devices' packet buffer FIFOs, that kind of thing 💖. so that drivers can handle these divas as efficiently as possible, we got three whole families: bus_space_read_multi_N(), bus_space_set_multi_N(), and bus_space_write_multi_N(). and yes bestie, they're all here.

🌸 bus_space_read_multi_1(space, handle, offset, datap, count)

🌸 bus_space_read_multi_2(space, handle, offset, datap, count)

🌸 bus_space_read_multi_4(space, handle, offset, datap, count)

🌸 bus_space_read_multi_8(space, handle, offset, datap, count)

The bus_space_read_multi_N() family reads count 1, 2, 4, or 8 byte data items from bus space at byte offset offset in the region specified by handle of the bus space specified by space, and drops them into the array specified by datap. every single successive data item gets read from the same location in bus space, no cap. and that location being read? it has to lie within the bus space region specified by handle. periodt.

For portability, the starting address of the region specified by handle plus the offset should be a multiple of the size of data items being read, and the data array pointer should be properly aligned. on some systems, not obeying these requirements may cause incorrect data to be read, and on others it may cause a system crash 😭. so like, please align things.

Read operations done by the bus_space_read_multi_N() functions may be executed out of order with respect to other pending read and write operations unless order is enforced by use of the bus_space_barrier() function. but because the bus_space_read_multi_N() functions read the same bus space location multiple times, they place an implicit read barrier between each successive read of that bus space location. the way that works is honestly iconic.

These functions will never fail. if they would fail (e.g. because of an argument error), that indicates a software bug which should cause a panic. in that case, they will never return. 💀

🌈 bus_space_write_multi_1(space, handle, offset, datap, count)

🌈 bus_space_write_multi_2(space, handle, offset, datap, count)

🌈 bus_space_write_multi_4(space, handle, offset, datap, count)

🌈 bus_space_write_multi_8(space, handle, offset, datap, count)

The bus_space_write_multi_N() family reads count 1, 2, 4, or 8 byte data items from the array specified by datap and writes them into bus space at byte offset offset in the region specified by handle of the bus space specified by space. every successive data item goes to the same location in bus space. and the location being written must lie within the bus space region specified by handle. 🫶

For portability, the starting address of the region specified by handle plus the offset should be a multiple of the size of data items being written, and the data array pointer should be properly aligned. on some systems, not obeying these requirements may cause incorrect data to be written, on others it may cause a system crash 😭. yeah, same deal, be normal about your alignment.

Write operations done by the bus_space_write_multi_N() functions may be executed out of order with respect to other pending read and write operations unless order is enforced by use of the bus_space_barrier() function. because the bus_space_write_multi_N() functions write the same bus space location multiple times, they place an implicit write barrier between each successive write of that bus space location. slay.

These functions will never fail. if they would fail (e.g. because of an argument error), that indicates a software bug which should cause a panic. in that case, they will never return. 💀

🎀 bus_space_set_multi_1(space, handle, offset, value, count)

🎀 bus_space_set_multi_2(space, handle, offset, value, count)

🎀 bus_space_set_multi_4(space, handle, offset, value, count)

🎀 bus_space_set_multi_8(space, handle, offset, value, count)

The bus_space_set_multi_N() writes value into bus space at byte offset offset in the region specified by handle of the bus space specified by space, count times. the location being written must lie within the bus space region specified by handle. ✨

For portability, the starting address of the region specified by handle plus the offset should be a multiple of the size of data items being written and the data array pointer should be properly aligned. on some systems, not obeying these requirements may cause incorrect data to be written, on others it may cause a system crash 😭.

Write operations done by the bus_space_set_multi_N() functions may be executed out of order with respect to other pending read and write operations unless order is enforced by use of the bus_space_barrier() function. because the bus_space_set_multi_N() functions write the same bus space location multiple times, they place an implicit write barrier between each successive write of that bus space location.

These functions will never fail. if they would fail (e.g. because of an argument error), that indicates a software bug which should cause a panic. in that case, they will never return. 💀

---

🦋 STREAM FUNCTIONS 🦋

okay so most of the bus_space functions assume a host byte-order and a bus byte-order and handle all the translation for you, like the sweetest little helper. but sometimes hardware maps a FIFO or some other memory region where the caller wants multi-word but untranslated access. for those memory regions, you go through the bus_space_*_stream_N() functions. 🧚

• bus_space_read_stream_1()
• bus_space_read_stream_2()
• bus_space_read_stream_4()
• bus_space_read_stream_8()
• bus_space_read_multi_stream_1()
• bus_space_read_multi_stream_2()
• bus_space_read_multi_stream_4()
• bus_space_read_multi_stream_8()
• bus_space_read_region_stream_1()
• bus_space_read_region_stream_2()
• bus_space_read_region_stream_4()
• bus_space_read_region_stream_8()
• bus_space_write_stream_1()
• bus_space_write_stream_2()
• bus_space_write_stream_4()
• bus_space_write_stream_8()
• bus_space_write_multi_stream_1()
• bus_space_write_multi_stream_2()
• bus_space_write_multi_stream_4()
• bus_space_write_multi_stream_8()
• bus_space_write_region_stream_1()
• bus_space_write_region_stream_2()
• bus_space_write_region_stream_4()
• bus_space_write_region_stream_8()
• bus_space_copy_region_stream_1()
• bus_space_copy_region_stream_2()
• bus_space_copy_region_stream_4()
• bus_space_copy_region_stream_8()
• bus_space_set_multi_stream_1()
• bus_space_set_multi_stream_2()
• bus_space_set_multi_stream_4()
• bus_space_set_multi_stream_8()
• bus_space_set_region_stream_1()
• bus_space_set_region_stream_2()
• bus_space_set_region_stream_4()
• bus_space_set_region_stream_8()

These functions are defined just as their non-stream counterparts, except that they provide no byte-order translation. that's it, that's the whole plot twist 💅.

---

💜 COMPATIBILITY 💜

The current NetBSD version of the bus_space interface specification differs slightly from the original specification that came into wide use and FreeBSD adopted. a few of the function names and arguments have changed for consistency and increased functionality. so like, glow-up era, iykyk. 🌈

---

👑 SEE ALSO 👑

• bus_dma(9)

---

🌸 HISTORY 🌸

The bus_space functions were introduced in a different form (memory and I/O spaces were accessed via different sets of functions) in NetBSD 1.2. the functions were merged to work on generic “spaces” early in the NetBSD 1.3 development cycle, and many drivers were converted to use them. this document was written later during the NetBSD 1.3 development cycle, and the specification was updated to fix some consistency problems and to add some missing functionality. the evolution arc is honestly so real 🦋.

The manual page was then adapted to the version of the interface that FreeBSD imported for the CAM SCSI drivers, plus subsequent evolution. the FreeBSD bus_space version was imported in FreeBSD 3.0. main character energy fr fr.

---

⭐ AUTHORS ⭐

The bus_space interfaces were designed and implemented by the NetBSD developer community. primary contributors and implementors were Chris Demetriou, Jason Thorpe, and Charles Hannum, but the rest of the NetBSD developers and the user community played a significant role in development. squad goals 💖.

• Justin Gibbs ported these interfaces to FreeBSD.
• Chris Demetriou wrote this manual page.
• Warner Losh modified it for the FreeBSD implementation.

---

💀 BUGS 💀

This manual may not completely and accurately document the interface, and many parts of the interface are unspecified. 😭 no cap, bestie — read the source if you need the real real.

---

and that's the whole page, you made it to the end!! 🎀 this was the Debian rendering of BUS_SPACE(9), dated January 15, 2017, and yes i know that's basically ancient history in internet years but the knowledge still eats. go forth and map some bus space, you absolute icon. periodt. 💅✨