iudma_write(9)

💅 iudma_write(9) — like, the whole kernel API manual moment 🎀

okay so bestie, we're in the Kernel API Manual and today's main character is iudma_write. yes it's a function, yes it's (9) (kernel API section, iykyk), and yes I'm gonna tell you everything about it. sit down, hydrate, let's go ✨

---

🦋 NAME 🦋

iudma_write — queues up a single IUDMA transaction. that's it, that's the vibe. one transaction. putting it in the queue. slay 💅

---

🌸 SYNOPSIS 🌸

void iudma_write (struct bcm63xx_udc *udc , struct iudma_ch *iudma ,
       struct bcm63xx_req *breq );

like, return type is void, so it gives you nothing back — no cap. it just does the thing and you move on with your life 🫶

---

✨ ARGUMENTS ✨

• udc — a reference to the device controller. the big boss of the setup. you point at it, the function knows which controller we're talking to 👑
• iudma — the IUDMA channel to use. like picking which lane you're driving in 🚗
• breq — the request containing the transaction data. this is the actual payload, the whole reason we're here 🍓

---

💖 DESCRIPTION 💖

okay this is the part where it gets kind of iconic ngl, because the behaviour is different depending on whether you're on RX or TX. the way that these two do NOT act the same 😭

🌈 For RX IUDMA

For RX IUDMA, this will queue a single buffer descriptor. why just one? because RX IUDMA does not honor SOP/EOP, so the handling of multiple buffers is ambiguous. literally ambiguous. it's giving "we don't know what you meant" energy 💀

so like — iudma_write may be called several times to fulfill a single usb_request. yes bestie, several calls, one request. that's not a bug, that's just how it is 🙈

⭐ For TX IUDMA

For TX IUDMA, this can queue multiple buffer descriptors if needed. much more chill. much more "we can handle it" energy. obsessed 🫶

ngl the RX/TX split is the whole point of this page — don't mix them up or it's gonna be a whole thing 💅

---

🔥 SEE ALSO 🔥

okay so this function does NOT exist in a vacuum, and the docs are gonna let you know. first up, the source:

• Kernel file ./drivers/usb/gadget/udc/bcm63xx_udc.c

and then the entire extended friend group, no one left out, periodt 👑

• struct iudma_ch_cfg(9)
• struct iudma_ch(9)
• struct bcm63xx_ep(9)
• struct bcm63xx_req(9)
• struct bcm63xx_udc(9)
• bcm63xx_ep_dma_select(9)
• bcm63xx_set_stall(9)
• bcm63xx_fifo_setup(9)
• bcm63xx_fifo_reset_ep(9)
• bcm63xx_fifo_reset(9)
• bcm63xx_ep_init(9)
• bcm63xx_ep_setup(9)
• iudma_read(9)
• iudma_reset_channel(9)
• iudma_init_channel(9)
• iudma_init(9)
• iudma_uninit(9)
• bcm63xx_set_ctrl_irqs(9)
• bcm63xx_select_phy_mode(9)
• bcm63xx_select_pullup(9)
• bcm63xx_uninit_udc_hw(9)
• bcm63xx_init_udc_hw(9)
• bcm63xx_ep_enable(9)
• bcm63xx_ep_disable(9)
• bcm63xx_udc_alloc_request(9)
• bcm63xx_udc_free_request(9)
• bcm63xx_udc_queue(9)
• bcm63xx_udc_dequeue(9)
• bcm63xx_udc_set_halt(9)
• bcm63xx_udc_set_wedge(9)
• bcm63xx_ep0_setup_callback(9)
• bcm63xx_ep0_spoof_set_cfg(9)
• bcm63xx_ep0_spoof_set_iface(9)
• bcm63xx_ep0_map_write(9)
• bcm63xx_ep0_complete(9)
• bcm63xx_ep0_nuke_reply(9)
• bcm63xx_ep0_read_complete(9)
• bcm63xx_ep0_internal_request(9)
• bcm63xx_ep0_do_setup(9)
• bcm63xx_ep0_do_idle(9)
• bcm63xx_ep0_one_round(9)
• bcm63xx_ep0_process(9)
• bcm63xx_udc_get_frame(9)
• bcm63xx_udc_pullup(9)
• bcm63xx_udc_start(9)
• bcm63xx_udc_stop(9)
• bcm63xx_update_cfg_iface(9)
• bcm63xx_update_link_speed(9)
• bcm63xx_update_wedge(9)
• bcm63xx_udc_ctrl_isr(9)
• bcm63xx_udc_data_isr(9)
• bcm63xx_udc_init_debugfs(9)
• bcm63xx_udc_cleanup_debugfs(9)
• bcm63xx_udc_probe(9)
• bcm63xx_udc_remove(9)

like I said. everyone. the whole group chat 🫶

---

and that's the page!! this little gem lives in ./drivers/usb/gadget/udc, and it's dated October 2026 — yeah, future girlie hours, don't ask 🌸 mwah, go queue your transactions responsibly, ily 💜