STRUCT PXA_EP(9)

๐Ÿ“ฆ version 7.3.1, in nixpkgs unstable

๐Ÿ’œ struct pxa_ep(9) โ€” the pxa endpoint, bestie edition ๐ŸŽ€

okay so this is a page from the Kernel API Manual about struct pxa_ep, and honestly? it's giving "old USB gadget driver lore" and i'm obsessed. let's get into it ๐Ÿ’…


โœจ SYNOPSIS โœจ

here's the whole struct, laid out exactly as it is, no cap:

struct pxa_ep {
    struct pxa_udc          *dev;
    struct list_head        queue;
    spinlock_t lock;
    unsigned enabled:1;
    unsigned in_handle_ep:1;
    unsigned idx:5;
    char *name;
    unsigned dir_in:1;
    unsigned addr:4;
    unsigned config:2;
    unsigned interface:3;
    unsigned alternate:3;
    unsigned fifo_size;
    unsigned type;
  #ifdef CONFIG_PM;
    u32 udccsr_value;
    u32 udccr_value;
  #endif;
    struct stats            stats;
 };

๐Ÿฆ‹ Members ๐Ÿฆ‹

bestie, meet the fields. every single one. line by line, no skipping ๐Ÿ™ˆ

  • dev โ€” the udc device ๐Ÿ’–
  • queue โ€” the requests queue ๐ŸŽ€
  • lock โ€” the lock that guards the pxa_ep data (that means the queues and the stats) ๐Ÿ”’
  • enabled โ€” true when the endpoint is enabled โ€” and to be clear, that means not stopped by the gadget layer โœจ
  • in_handle_ep โ€” the number of recursions of the handle_ep function. it exists to prevent deadlocks or infinite recursions of types:
irq->handle_ep->req_done->req.complete->pxa_ep_queue->handle_ep

or

pxa_ep_queue->handle_ep->req_done->req.complete->pxa_ep_queue

like, that's the whole reason. protecting us from ourselves ๐Ÿ˜ญ

  • idx โ€” the endpoint index (1 => epA, 2 => epB, ..., 24 => epX) ๐Ÿ”ข
  • name โ€” the endpoint name (for trace/debug purpose) ๐Ÿท๏ธ
  • dir_in โ€” 1 if it's an IN endpoint, 0 if it's an OUT endpoint ๐ŸŒˆ
  • addr โ€” the usb endpoint number ๐Ÿ“ฎ
  • config โ€” the configuration in which this endpoint is active โš™๏ธ
  • interface โ€” the interface in which this endpoint is active ๐Ÿ”Œ
  • alternate โ€” the altsetting in which this endpoint is active ๐ŸŒ€
  • fifo_size โ€” max packet size in the endpoint fifo ๐Ÿ“ฆ
  • type โ€” the endpoint type (bulk, iso, int, ...) ๐Ÿ‘‘
  • udccsr_value โ€” save register of UDCCSR0 for suspend/resume ๐Ÿ’พ
  • udccr_value โ€” save register of UDCCR for suspend/resume ๐Ÿ’พ
  • stats โ€” endpoint statistics ๐Ÿ“Š

๐Ÿ’€ Description ๐Ÿ’€

okay so this is where it gets real. the *PROBLEM* is that pxa's endpoint configuration scheme is both misdesigned and full of implementation bugs. misdesigned how? it cares about config/interface/altsetting, which places needless limits on device capability. and the bugs? they force it to be set up for use more or less like a pxa255. yeah. that's the situation. ๐Ÿ™ƒ

and because we define the pxa_ep statically, we must guess all needed pxa_ep for all gadget which may work with this udc driver. guessing. statically. iconic in the worst way ngl ๐Ÿ˜ญ

fr fr, that's the actual documented state of things โ€” i'm not adding drama, the manpage said *PROBLEM* with the asterisks and everything ๐Ÿ’€

๐ŸŒธ SEE ALSO ๐ŸŒธ

go read these too, bestie, they're in the kernel file ./drivers/usb/gadget/udc/pxa27x_udc.h ๐Ÿ‘€

  • struct udc_usb_ep(9)
  • struct pxa27x_request(9)
  • struct pxa_udc(9)

and that's the whole vibe check ๐Ÿซถ this page lives in ./drivers/usb/gadget/udc and it's dated October 2026 โ€” shoutout to the source, mwah ๐Ÿ’‹โœจ๐ŸŽ€

๐Ÿ“ฆ where this page comes from