typec_plug_register_altmode(9)

πŸ“¦ version 7.3.1, in nixpkgs unstable

πŸ’… typec_plug_register_altmode β€” like, the Kernel API Manual page, bestie ✨

okay so picture this: you're deep in the USB Type-C trenches, and this little function is the one that gets your cable plug's alternate modes officially on the guest list. no cap, it's giving backstage-pass energy πŸŽ€


🌸 SYNOPSIS 🌸

struct typec_altmode * typec_plug_register_altmode (struct typec_plug
*plug , const struct typec_altmode_desc *desc );

🫢 ARGUMENTS 🫢

  • plug β€” the USB Type-C Cable Plug that supports the alternate mode. yeah, that one. the plug in question πŸ’–
  • desc β€” the description of the alternate mode. literally the whole vibe of the mode, written down ✨

πŸ”₯ DESCRIPTION πŸ”₯

okay so here's the tea: this routine is what you call to register each alternate mode individually β€” one at a time, no bundling β€” that plug has listed in response to the Discover SVIDs command. iconic behavior, honestly πŸ‘‘

and listen, this part matters: the modes for a SVID that the plug lists in response to the Discover Modes command need to be listed in an array in desc. not scattered, not vibes-based β€” an actual array. iykyk 🧚

on success you get back a handle to the alternate mode. on failure? ERR_PTR. not great, not terrible, just how it is 😭

bestie please check that return value, ERR_PTR is not a mood you wanna ignore πŸ’€

🌈 SEE ALSO 🌈

Kernel file ./drivers/usb/typec/class.c β€” and the whole extended friend group:


and that's the whole page, bestie 🫢 brought to you by ./drivers/usb/typec, dated October 2026, and yeah β€” it's a <rainbow>typec_plug_register_altmode(9)</rainbow> situation from start to finish. slay πŸ’…βœ¨

πŸ“¦ where this page comes from