__hwrm_req_init(9)

📦 version 7.3.1, in nixpkgs unstable

💅 __hwrm_req_init(9) — like, the HWRM request glow-up era begins

okay bestie, grab your matcha 🍵 because this is a Kernel API Manual page and it's honestly kind of iconic. We're in __hwrm_req_init territory, aka the function that sets your HWRM request up so it can actually slay later. No cap.

✨ SYNOPSIS ✨

int __hwrm_req_init (struct bnxt *bp , void **req , u16 req_type , u32 req_len );

that's the whole vibe. four args, one int coming back at you 🫶

🎀 ARGUMENTS 🎀

  • bp — the driver context. your main character struct, fr.
  • req — a pointer to the request pointer you're initializing. yes, a pointer to a pointer, we love a double-pointer moment 💅
  • req_type — the request type. heads up: this gets converted to little endian before it's written to the req_type field of the request you get back. so don't come for it later asking why it looks different 🙈
  • req_len — the length of the request to be allocated. size matters, lowkey.

🦋 DESCRIPTION 🦋

So what actually happens? This bad boy allocates DMA resources and initializes a brand-new HWRM request object of the type you passed in. It's giving construction era. 🏗️

The response address field in the request gets configured with the DMA bus address that's been mapped for the response, and the request pointer you passed in gets pointed at kernel virtual memory mapped for the request — which is literally so that short_input indirection can be accomplished without copying. the way that saves a copy… obsessed. 😭✨

The request's target and completion ring are initialized to default values, and you can override them by writing to the returned request object directly. your request, your rules.

You can also customize the initialized request further by writing to its fields directly — just take care to convert such fields to little endian, okay? don't embarrass us. 🫶

Now the important part, listen up:

The request object will be consumed (and all its associated resources released) when you pass it to hwrm_req_send — unless ownership of the request has been claimed by the caller via a call to hwrm_req_hold. 💀

And if the request is not consumed — either because it's never sent, or because ownership has been claimed — then it must be released by a call to hwrm_req_drop. no ghosting your requests, bestie, they will leak. 🕯️

🌸 RETURN 🌸

  • zero on success 🎉
  • a negative error code otherwise:
    • E2BIG — the type of request pointer is too large to fit. it's giving "couldn't fit into the dress" energy 💀
    • ENOMEM — an allocation failure occurred. the malloc said no. 😭

🔥 SEE ALSO 🔥

the kernel file is right here, go read it:

./drivers/net/ethernet/broadcom/bnxt/bnxt_hwrm.c

and the whole friend group:

alright that's the page 💖 this came out of the ./drivers/net/ethernet/broadco... source tree, dated October 2026, and it's filed under __hwrm_req_init(9). go forth and initialize responsibly, bestie 🌈👑

📦 where this page comes from