hwrm_req_send(9)

💅 hwrm_req_send(9) — the "just send it already" kernel API page 🎀

okay bestie, welcome to hwrm_req_send(9), straight out of the Kernel API Manual. this is the one that actually fires off your HWRM command, and i'm gonna walk you through it like we're texting at 2am. no cap, every detail is staying. 💖

---

✨ NAME ✨

hwrm_req_send — Execute an HWRM command. that's it, that's the whole vibe. 🦋

---

🌸 SYNOPSIS 🌸

int hwrm_req_send (struct bnxt *bp , void *req );

look at that signature. iconic. 💅

---

🎀 ARGUMENTS 🎀

• bp — The driver context. your whole situation, basically. main character energy.
• req — A pointer to the request to send. and listen, this part matters: the DMA resources associated with the request will be released (ie. the request will be consumed) unless ownership of the request has been assumed by the caller via a call to hwrm_req_hold. so like… it eats your request unless you called dibs on it first. 🫶

---

🔥 DESCRIPTION 🔥

Send an HWRM request to the device and wait for a response. yes bestie, it waits. The request is consumed if it is not owned by the caller. This function will block until the request has either completed or times out due to an error. it's giving "i'm not hanging up until you answer me." 😭

The result is zero on success, otherwise the negative error code indicates one of the following errors:

• E2BIG: The request was too large. it did not fit. tragic. 💀
• EBUSY: The firmware is in a fatal state or the request timed out
• EACCESS: HWRM access denied. rude, honestly.
• ENOSPC: HWRM resource allocation error.
• EINVAL: Request parameters are invalid.
• ENOMEM: HWRM has no buffers. no thoughts, no buffers, head empty.
• EAGAIN: HWRM busy or reset in progress.
• EOPNOTSUPP: Invalid request type.
• EIO: Any other error.

Error handling is orthogonal to request ownership. read that again, fr fr. An unowned request will still be consumed on error. If the caller owns the request, then the caller is responsible for releasing the resources. Otherwise, hwrm_req_send will always consume the request. always. periodt. 👑

⚠️ real talk: whether it succeeds or fails, an unowned request is gone. if you held it with hwrm_req_hold, the cleanup is on you. don't say i didn't warn you. 🙈

---

⭐ RETURN ⭐

A result code. zero means slay, negative means something went sideways (see the whole list up there 👆). ✨

---

🌈 SEE ALSO 🌈

Kernel file ./drivers/net/ethernet/broadcom/bnxt/bnxt_hwrm.c — go read the source, iykyk 🧚

and the whole friend group:

• __hwrm_req_init(9)
• hwrm_req_timeout(9)
• hwrm_req_alloc_flags(9)
• hwrm_req_replace(9)
• hwrm_req_flags(9)
• hwrm_req_hold(9)
• hwrm_req_drop(9)
• hwrm_req_send_silent(9)
• hwrm_req_dma_slice(9)

---

and that's the page, bestie!! this queen lives at ./drivers/net/ethernet/broadco... and she was stamped October 2026, answering to the name hwrm_req_send(9). go send some requests, ily, mwah 💜💅