onboard_dev_create_pdevs(9)

💖 onboard_dev_create_pdevs(9) — Kernel API Manual 💖

okay so bestie, we're in the Kernel API Manual today and this function is literally the friend who sets up the whole party before anyone else shows up. Let's get into it 🫶

---

✨ NAME ✨

onboard_dev_create_pdevs — creates platform devices for onboard USB devices 💅

---

🌸 SYNOPSIS 🌸

void onboard_dev_create_pdevs (struct usb_device *parent_hub , struct
list_head *pdev_list );

---

🎀 ARGUMENTS 🎀

• parent_hub — the parent hub we're scanning to find all the connected onboard devices 🔍
• pdev_list — the list of onboard platform devices that belong to the parent hub, iykyk 📋

---

🦋 DESCRIPTION 🦋

So what this does is, for every supported onboard device that's connected to the given parent_hub, it creates a platform device. Each platform device is the one in charge of initializing the device — like enabling regulators, taking the device out of reset, all that good stuff ✨. And for onboard hubs specifically, it can optionally control whether the device stays powered during system suspend or not. choices, honestly.

To keep track of the platform devices, they get added to a list that's owned by the parent hub. bookkeeping slay 💅

Now, some background on the logic in this function, because ngl it can be a bit hard to follow:

Root hubs don't have dedicated device tree nodes — they use the node of their HCD instead. And the primary and secondary HCD are usually represented by a single DT node. Which means the root hubs of the primary and secondary HCD share the same device tree node (the HCD node). Because of that, this function can literally get called twice with the same DT node for root hubs 😭. But we only want a single platform device for each physical onboard device, so for root hubs the loop only runs for the root hub of the primary HCD. And since the function scans through all child nodes, it still creates pdevs for onboard devices connected to the root hub of the secondary HCD if they're needed. best of both worlds fr 💖

Also: there must be only one platform device for onboard hubs that have a peer hub (the hub is a single physical device, periodt). To pull that off, two measures are taken:

• pdevs for onboard hubs with a peer are only created when the function is called on behalf of the parent hub that's connected to the primary HCD — either directly or through other hubs 🧚
• for onboard hubs connected to root hubs, the function processes the nodes of both peers, but a platform device is only created if the peer hub doesn't already have one 👑

---

🔥 SEE ALSO 🔥

• Kernel file ./drivers/usb/misc/onboard_usb_dev_pdevs.c
• onboard_dev_destroy_pdevs(9)

---

and that's the whole vibe check, bestie 🌈 this cutie lives in ./drivers/usb/misc (version vibes, October 2026) — go off, you're gonna do amazing 💜🎀🦋