STRUCT FSL_MC_DEVICE(9)

💖 NAME 💖

okay so bestie, welcome to the struct fsl_mc_device(9) glow-up — this is the MC object device object. that's it, that's the name, it's giving "device object for MC object devices" and honestly she ate 💅

this page lives in the Kernel API Manual and it's all about one little struct, so grab a strawberry drink 🍓 and let's go.

---

✨ SYNOPSIS ✨

struct fsl_mc_device {
    struct device dev;
    u64 dma_mask;
    u16 flags;
    u32 icid;
    u16 mc_handle;
    struct fsl_mc_io *mc_io;
    struct fsl_mc_obj_desc obj_desc;
    struct resource *regions;
    struct fsl_mc_device_irq **irqs;
    struct fsl_mc_resource *resource;
    struct device_link *consumer_link;
 };

look at her. all those fields. main character energy fr fr 👑

---

🎀 Members 🎀

every field gets her moment, no crumbs:

• dev — the Linux driver model device object. the literal foundation of the whole thing, iconic.
• dma_mask — the default DMA mask. yes ma'am, set your mask 💅
• flags — MC object device flags. little flags, big vibes.
• icid — the isolation context ID for the device. think of it as her designated safe space 🔒
• mc_handle — the MC handle for the corresponding MC object opened. it's the handle, bestie, hold it gently 🫶
• mc_io — pointer to the MC IO object assigned to this device, or NULL if none. so like... it might be there, it might not be, no pressure.
• obj_desc — the MC description of the DPAA device. it's giving "describe yourself in one struct" ✨
• regions — pointer to an array of MMIO region entries. plural. an array. a whole lil collection 🌸
• irqs — pointer to an array of pointers to interrupts allocated to this device. pointer-to-pointer-to-interrupt realness, we love a nested situation 😭
• resource — the generic resource associated with this MC object device, if any. "if any" — she's flexible, she's chill.

---

🦋 Description 🦋

this is the generic device object for MC object devices that are "attached" to an MC bus. that's the whole vibe: generic, attached, living her MC bus life 🌈

---

🔥 NOTES 🔥

okay bestie, these are the important bits, pay attention, i'm serious 🙈

• For a non-DPRC object, its icid is the same as its parent DPRC's icid. so she literally inherited it. generational 💜
• The SMMU notifier callback gets invoked after device_add has been called for an MC object device, but before the device-specific probe callback gets called. timing is everything, ngl — get that order wrong and it's not cute.
• DP_OBJ_DPRC objects are the only MC objects that have built-in MC portals. for all other MC objects, their device drivers are responsible for allocating MC portals for them by calling fsl_mc_portal_allocate. like, no portal for you unless you build one yourself, sorry babe 💀
• Some types of MC objects (e.g., DP_OBJ_DPBP, DP_OBJ_DPCON) are treated as resources that can be allocated/deallocated from the corresponding resource pool in the object's parent DPRC, using the fsl_mc_object_allocate/fsl_mc_object_free functions. these MC objects are known as "allocatable" objects. For them, the corresponding fsl_mc_device's 'resource' points to the associated resource object. For MC objects that are not allocatable (e.g., DP_OBJ_DPRC, DP_OBJ_DPNI),

yeah 😭 the page itself cuts off right there, mid-sentence, with that trailing comma. that's genuinely all the original gives us — no cap, i'm not hiding anything from you bestie. if it's not in the source, it's not in my rewrite. periodt. 🎀

---

⭐ SEE ALSO ⭐

go read these next, i'm obsessed with a well-linked manpage:

• Kernel file ./include/linux/fsl/mc.h
• struct fsl_mc_driver(9)
• enum fsl_mc_pool_type(9)
• struct fsl_mc_resource(9)
• struct fsl_mc_device_irq(9)
• struct fsl_mc_obj_desc(9)
• struct fsl_mc_io(9)
• struct fsl_mc_version(9)
• struct dpbp_attr(9)
• struct dpcon_attr(9)
• struct dpcon_notification_cfg(9)

---

and that's the page!! 🧚 source is ./include/linux/fsl, dated October 2026, and she's filed right back under struct fsl_mc_device(9) — slay, bye bestie 💖✨