BUS_ALLOC_RESOURCE(9)

πŸ’– BUS_ALLOC_RESOURCE πŸ’–

okay bestie, welcome to BUS_ALLOC_RESOURCE(9), straight out of the Kernel Developer's Manual ✨ this is the page about grabbing resources off your parent bus, and it's genuinely so useful. let's get into it 🫢


🌸 NAME 🌸

bus_alloc_resource, bus_alloc_resource_any, bus_alloc_resource_anywhere β€” allocate resources from a parent bus πŸ’…


✨ SYNOPSIS ✨

#include <sys/param.h>
#include <sys/bus.h>

#include <machine/bus.h>
#include <sys/rman.h>
#include <machine/resource.h>

struct resource *
bus_alloc_resource(device_t dev, int type, int *rid, rman_res_t start,
    rman_res_t end, rman_res_t count, u_int flags);

struct resource *
bus_alloc_resource_any(device_t dev, int type, int *rid, u_int flags);

struct resource *
bus_alloc_resource_anywhere(device_t dev, int type, int *rid,
    rman_res_t count, u_int flags);

πŸ‘‘ DESCRIPTION πŸ‘‘

so this is the easy-peasy interface to the resource-management functions β€” it hides all the indirection through the parent's method table (the way it just... skips the middleman? iconic πŸ’…). generally you should call this in attach, but (except in some rare cases) never earlier. fr fr, timing matters.

the bus_alloc_resource_any() and bus_alloc_resource_anywhere() functions are convenience wrappers for bus_alloc_resource():

  • bus_alloc_resource_any() sets start, end, and count to the default resource (peep the description of start below πŸ‘‡).
  • bus_alloc_resource_anywhere() sets start and end to the default resource and uses the provided count argument.

the arguments are as follows, bestie, listen up πŸŽ€:

  • dev β€” the device that requests ownership of the resource. before allocation, the resource is owned by the parent bus. not you. the bus. πŸ™ˆ
  • type β€” the type of resource you want to allocate. it is one of:
    • PCI_RES_BUS β€” for PCI bus numbers
    • SYS_RES_IRQ β€” for IRQs
    • SYS_RES_DRQ β€” for ISA DMA lines
    • SYS_RES_IOPORT β€” for I/O ports
    • SYS_RES_MEMORY β€” for I/O memory
  • rid β€” points to a bus specific handle that identifies the resource being allocated. for ISA this is an index into an array of resources that have been setup for this device by either the PnP mechanism, or via the hints mechanism. for PCCARD, this is an index into the array of resources described by the PC Card's CIS entry. for PCI, the offset into PCI config space which has the BAR to use to access the resource. 🫢
⚠️ the bus methods are free to change the RIDs that they are given as a parameter. you must not depend on the value you gave it earlier. it's giving "moving on without you" energy, and you just have to accept it 😭
  • start and end β€” the start/end addresses of the resource. if you specify values of 0ul for start and ~0ul for end and 1 for count, the default values for the bus are calculated. ✨
  • count β€” the size of the resource. for example, the size of an I/O port is usually 1 byte (but some devices override this). if you specified the default values for start and end, then the default value of the bus is used if count is smaller than the default value and count is used, if it is bigger than the default value. the way it just picks the bigger one?? lowkey fair πŸ’…
  • flags β€” sets the flags for the resource. you can set one or more of these flags:
    • RF_ALLOCATED β€” resource has been reserved. the resource still needs to be activated with bus_activate_resource(9). not done yet, babes, one more step 🧚
    • RF_ACTIVE β€” activate resource atomically. ⚑
    • RF_PREFETCHABLE β€” resource is prefetchable.
    • RF_SHAREABLE β€” resource permits contemporaneous sharing. it should always be set unless you know that the resource cannot be shared. it is the bus driver's task to filter out the flag if the bus does not support sharing. for example, pccard(4) cannot share IRQs while cardbus(4) can. sharing is caring but only sometimes 🫢
    • RF_UNMAPPED β€” do not establish implicit mapping when activated via bus_activate_resource(9).

🌈 RETURN VALUES 🌈

a pointer to struct resource is returned on success, a null pointer otherwise. so like... check it. please. for me. πŸ₯Ί


πŸ“ EXAMPLES πŸ“

here's some example code that allocates a 32 byte I/O port range and an IRQ. the values of portid and irqid should be saved in the softc of the device after these calls. save them, bestie, they're precious πŸ’–

struct resource *portres, *irqres;
int portid, irqid;

portid = 0;
irqid = 0;
portres = bus_alloc_resource(dev, SYS_RES_IOPORT, &portid,
                0ul, ~0ul, 32, RF_ACTIVE);
irqres = bus_alloc_resource_any(dev, SYS_RES_IRQ, &irqid,
                RF_ACTIVE | RF_SHAREABLE);

πŸ‘€ SEE ALSO πŸ‘€

bus_activate_resource(9), bus_adjust_resource(9), bus_map_resource(9), bus_release_resource(9), device(9), driver(9)


πŸ’œ AUTHORS πŸ’œ

this manual page was written by Alexander Langer <alex@big.endian.de> with parts by Warner Losh <imp@FreeBSD.org>. absolute legends, we stan 🌟


okay that's the whole page, you ate it, periodt πŸ’… this was BUS_ALLOC_RESOURCE(9) from the Debian build, dated May 20, 2016 β€” go forth and allocate responsibly, no cap πŸ¦‹πŸ’–

πŸ“¦ where this page comes from