cdns3_trb_handled(9)

πŸ“¦ version 7.3.1, in nixpkgs unstable

πŸ’… cdns3_trb_handled(9) β€” from the Kernel API Manual, bestie

okay so picture this: we're deep in the Kernel API Manual and there's this lil function called cdns3_trb_handled, and honestly? it's giving "did DMA already do its thing or nah" energy. let's get into it πŸŽ€


✨ NAME ✨

cdns3_trb_handled β€” check whether trb has been handled by DMA

like literally just a vibe check on your TRB, no cap πŸ”₯


🌸 SYNOPSIS 🌸

bool cdns3_trb_handled (struct cdns3_endpoint *priv_ep , struct
       cdns3_request *priv_req );

πŸ¦‹ ARGUMENTS πŸ¦‹

  • priv_ep β€” extended endpoint object. your whole endpoint situation πŸ’–
  • priv_req β€” request object for checking. the request we're side-eyeing πŸ‘€

πŸ’œ DESCRIPTION πŸ’œ

okay so first thing's first: the endpoint must be selected before invoking this function. literally do not skip that step, bestie, it's not optional πŸ™ˆ

It returns false if the request has not been handled by DMA, else it returns true. simple as that ✨

now, the abbreviations, because we're about to speak in letters and you need to keep up πŸ’…:

  • SR β€” start ring
  • ER β€” end ring
  • DQ = priv_ep->dequeue β€” dequeue position
  • EQ = priv_ep->enqueue β€” enqueue position
  • ST = priv_req->start_trb β€” index of first TRB in transfer ring
  • ET = priv_req->end_trb β€” index of last TRB in transfer ring
  • CI = current_index β€” index of processed TRB by DMA

As first step, we check if the TRB is between the ST and ET. Then, we check if the cycle bit for index priv_ep->dequeue is correct. one-two punch, we love a two-step 🫢

the rules (yes there are rules, respect them) πŸ“‹

  1. priv_ep->dequeue never equals to current_index.
  2. priv_ep->enqueue never exceed priv_ep->dequeue
  3. exception: priv_ep->enqueue == priv_ep->dequeue and priv_ep->free_trbs is zero. This case indicate that TR is full.
⚠️ heads up: that third one is the exception case, and it indicate that the TR is full. write that down bestie 😭

when the request has been handled πŸ‘‘

At below two cases, the request have been handled.

Case 1 β€” priv_ep->dequeue < current_index

SR ... EQ ... DQ ... CI ... ER SR ... DQ ... CI ... EQ ... ER

Case 2 β€” priv_ep->dequeue > current_index

This situation takes place when CI go through the LINK TRB at the end of transfer ring.

SR ... CI ... EQ ... DQ ... ER

and that's the whole tea, no cap β˜•πŸ’€


🌈 SEE ALSO 🌈

Kernel file ./drivers/usb/cdns3/cdns3-gadget.c β€” go read it, iykyk πŸ“–

all the sibling functions, iconic lineup incoming πŸ‘‘:


and that's a wrap bestie πŸ“ this page lives at ./drivers/usb/cdns3, dated October 2026, and the whole thing answers to the name cdns3_trb_handled(9). go handle some TRBs, you got this πŸ’–βœ¨πŸ§š

πŸ“¦ where this page comes from