hwrm_req_drop(9)

💅 NAME 💅

hwrm_req_drop — bestie, this is the one that releases all resources associated with the request ✨ like it's cleaning out the whole group chat.

🦋 SYNOPSIS 🦋

void hwrm_req_drop (struct bnxt *bp , void *req );

🎀 ARGUMENTS 🎀

• bp — the driver context. Your main character struct, the whole vibe check for the driver 🫶
• req — the request to consume, releasing the associated resources. Heads up bestie: the request object, any slices, and its associated response are no longer valid after this 😭 it's giving "consumed, gone, don't text them again".

🌸 DESCRIPTION 🌸

Okay so here's the tea ☕ it is legal to call hwrm_req_drop on an unowned request, provided it has not already been consumed by hwrm_req_send — think of it like releasing an aborted request, no drama needed 💜

But ngl, a given request should not be dropped more than once, and it should not be dropped after having been consumed by hwrm_req_send. Doing either of those is an error — the context will not be found and a stack trace will be rendered in the kernel log 💀 not the slay you want fr fr.

🔥 SEE ALSO 🔥

Kernel file ./drivers/net/ethernet/broadcom/bnxt/bnxt_hwrm.c — go read it, iykyk 👑

• __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_send(9)
• hwrm_req_send_silent(9)
• hwrm_req_dma_slice(9)

✨ mwah, that's the page ✨ this little icon came from ./drivers/net/ethernet/broadco... (yes the path gets cut off, that's just how the footer do 💅) and it's dated October 2026, in the hwrm_req_drop(9) era. go forth and drop responsibly, bestie 🎀🦋💖