hwrm_req_replace(9)

💅 hwrm_req_replace(9) — from the Kernel API Manual, bestie

Okay so real talk, this page is literally called hwrm_req_replace, and it lives in the Kernel API Manual. It's a lil function in the bnxt driver that swaps out your request data, and honestly? It's giving "glow-up for a request object." Let's get into it 🎀

---

✨ NAME ✨

hwrm_req_replace — replace request data. That's it, that's the whole vibe.

---

🦋 SYNOPSIS 🦋

int hwrm_req_replace (struct bnxt *bp , void *req , void *new_req , u32
len );

---

🌸 ARGUMENTS 🌸

• bp — the driver context. Your main character struct, the whole reason we're here.
• req — the request you wanna modify. And okay, important: calling hwrm_req_replace is conceptually an assignment of new_req to req. So after this, when you hit up HWRM API functions like hwrm_req_send, you use req and NOT new_req. Fr fr. And actually — calls to HWRM API functions will fail if you pass non-managed request objects. So don't do that 🙈
• new_req — the pre-built request you're copying or referencing. The new fit ✨
• len — the length of new_req. Gotta know how big the outfit is.

---

💖 DESCRIPTION 💖

So what it does: replaces the request data in req with the data from new_req. Iconic.

This is lowkey perfect for those scenarios where a request object has already been constructed by a third party, before you even created a resource-managed request using hwrm_req_init. Like, the request walked in already dressed and you're just fitting it into the managed-request system.

Depending on the length, hwrm_req_replace will do one of two things:

• copy the new request data into the DMA memory allocated for req, or
• simply reference the new request and use it in lieu of req during subsequent calls to hwrm_req_send.

Either way, the resource management is associated with req, and it is independent of and does not apply to new_req. That's the key part, bestie 🫶

⚠️ The caller must ensure that the lifetime of new_req is at least as long as req. Like, not shorter. Don't let it ghost early. 😭

Also: any slices that may have been associated with the original request are released. Out with the old 💅

---

🔥 RETURN 🔥

• 0 on success 🎉
• A negative error code otherwise:
  • E2BIG — request is too large. It ate too much 🍓
  • EINVAL — invalid request to modify. Not it. 💀

---

👑 SEE ALSO 👑

Kernel file ./drivers/net/ethernet/broadcom/bnxt/bnxt_hwrm.c, plus the whole friend group:

__hwrm_req_init(9), hwrm_req_timeout(9), hwrm_req_alloc_flags(9), hwrm_req_flags(9), hwrm_req_hold(9), hwrm_req_drop(9), hwrm_req_send(9), hwrm_req_send_silent(9), hwrm_req_dma_slice(9)

---

Alright bestie, that's the page 🌈 it's from ./drivers/net/ethernet/broadco... (the path got a lil truncated, we don't gatekeep), dated October 2026, and the whole thing is signed hwrm_req_replace(9) top and bottom like a true signature scent. Slay, go manage those requests responsibly 💜🧚