hwrm_req_hold(9)

πŸ“¦ version 7.3.1, in nixpkgs unstable

πŸ’… hwrm_req_hold(9) β€” the Kernel API Manual glow-up πŸŽ€

okay so bestie, we're reading hwrm_req_hold(9) from the Kernel API Manual today, and honestly? it's giving "small function, big responsibility" energy. let's get into it ✨


✨ NAME ✨

hwrm_req_hold β€” claim ownership of the request's resources. that's it, that's the whole vibe. you're basically adopting a request and now it's your problem 🫢


🌸 SYNOPSIS 🌸

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

look at that signature. void * in, void * out, no cap πŸ’…


πŸ¦‹ ARGUMENTS πŸ¦‹

  • bp β€” the driver context. you know her, you love her, she's the whole driver situation πŸ’–
  • req β€” a pointer to the request you wanna own. once you hold it, calls to hwrm_req_send will no longer consume it. it's yours now, bestie, like officially πŸ‘‘

πŸ”₯ DESCRIPTION πŸ”₯

so. you're taking ownership of the request. and ownership is not just a cute word here β€” it literally places the responsibility on the caller (that's you πŸ™ˆ) to free the resources associated with the request by calling hwrm_req_drop. no ghosting your responsibilities, okay?

when the caller takes ownership, that implies a subsequent call to hwrm_req_send will not consume the request β€” like, sending will not free the associated resources if the request is owned by the caller. iykyk 😌

taking ownership also returns a reference to the response. and ngl, retaining and accessing that response data is the most common reason to take ownership of the request in the first place. it's kinda the whole point πŸ’€

ownership can also be acquired in order to reuse the same request object across multiple invocations of hwrm_req_send. so like, one request, many send, main character energy honestly ⭐

the resources associated with the response stay available to the caller until ownership of the request is relinquished via a call to hwrm_req_drop. periodt. πŸŽ€

and here's the tea: it is not possible for hwrm_req_hold to return NULL if a valid request is provided. a returned NULL value would imply a driver bug, and the implementation will complain loudly in the logs to aid in detection. loud. in the logs. like a whole scene πŸ’€πŸ”Š

so it should not be necessary to check the result for NULL. you can just... not. slay ✨

lowkey important: this is a warning, not a flex β€” if you ever do see that NULL, something is genuinely broken and the logs will be screaming about it. πŸ™ˆ

πŸ’œ RETURN πŸ’œ

a pointer to the response object. that's the whole return value, iconic behavior πŸ‘‘


🌈 SEE ALSO 🌈

the whole friend group fr fr 🫢


okay and finally, credits where credits are due: this page came out of ./drivers/net/ethernet/broadco... β€” yes, it's abbreviated like that in the source, don't come for me 😭 β€” and it's dated October 2026. mwah, thanks for reading bestie, go free those requests πŸ’‹πŸ’–

πŸ“¦ where this page comes from