STRUCT EXTCON_DEV(9)

💅 struct extcon_dev(9) — like, the whole kernel API manual, but make it make sense 🎀

okay so bestie, this is a page straight out of the Kernel API Manual, and it's about struct extcon_dev — which lowkey is just ✨ an extcon device representing one external connector ✨. one connector. one vibe. iykyk.

---

🌸 NAME 🌸

struct extcon_dev — an extcon device represents one external connector, periodt. 🔌🫶

---

✨ SYNOPSIS ✨

here's the literal struct, copied exactly, no notes, no edits, we do not touch the source code in this house:

struct extcon_dev {
    const char *name;
    const unsigned int *supported_cable;
    const u32 *mutually_exclusive;
    struct device dev;
    unsigned int id;
    struct raw_notifier_head nh_all;
    struct raw_notifier_head *nh;
    struct list_head entry;
    int max_supported;
    spinlock_t lock;
    u32 state;
    struct device_type extcon_dev_type;
    struct extcon_cable *cables;
    struct attribute_group attr_g_muex;
    struct attribute **attrs_muex;
    struct device_attribute *d_attrs_muex;
 };

look at her. icon. 👑

---

🦋 Members 🦋

okay this is the part where we go field by field, and yes we're doing all of them, grab a snack 🍓

• name — the name of this extcon device. if it's NULL, the parent device name gets used instead. no name? the parent steps in, main character energy. ✨
• supported_cable — array of supported cable names, ending with EXTCON_NONE. and listen: if supported_cable is NULL, all the cable-name-related APIs are disabled. like, off. not a thing. 🙈
• mutually_exclusive — array of mutually exclusive sets of cables that cannot be attached simultaneously. the array has to end with 0, or just be NULL (which means no mutually exclusive cables at all). for example, if it's {0x7, 0x30, 0}, then {0, 1}, {0, 1, 2}, {0, 2}, {1, 2}, or {4, 5} cannot be attached simultaneously. {0x7, 0} is equivalent to {0x3, 0x6, 0x5, 0}. and if it's {0xFFFFFFFF, 0}, there can be no simultaneous connections — none, zero, absolutely not, we don't do that here 💀
• dev — device of this extcon. that's it. that's the field. 🫶
• id — unique device ID of this extcon. unique!! do not reuse, bestie. ⭐
• nh_all — notifier for the state change events for all supported external connectors from this extcon. the group chat of notifiers 📣
• nh — notifier for the state change events from this extcon. (no "all", just this one, she's focused) 💅
• entry — to support a list of extcon devices so users can search for extcon devices based on the extcon name. it's giving linked-list realness. 🌈
• max_supported — internal value to store the number of cables. internal! not for you! 🙈
• lock — protects device state and serialises device registration. spinlock doing spinlock things, no cap 🔒
• state — attach/detach state of this extcon. > do not provide this at register-time. like, genuinely, don't. the register function handles it.
• extcon_dev_type — device_type struct to provide attribute_groups customized for each extcon device. bespoke. tailored. cute. 🎀
• cables — sysfs subdirectories. each one represents one cable. one cable, one subdirectory, that's the whole deal 🗂️

---

💜 Description 💜

so here's the tea: in most cases, users only need to provide the "User initializing data" of this struct when registering an extcon. easy. slay. ✅

in some exceptional cases, optional callbacks may be needed. fancy, but rare. 🧚

BUT — and this is the important part — the values in "internal data" are overwritten by the register function. so don't get attached to them, they're not yours. 😭

---

👑 SEE ALSO 👑

• Kernel file ./drivers/extcon/extcon.h — go read it, i'm literally begging 🫶

---

okay that's the whole page!! sourced from ./drivers/extcon, dated October 2026, in the Kernel API Manual — that's struct extcon_dev(9), bestie, and she ate. 💅✨🎀