STRUCT BUS_TYPE(9)

πŸ“¦ version 7.3.1, in nixpkgs unstable

🌈 struct bus_type(9) β€” the bus type of the device ✨

okay so this is a page straight outta the Kernel API Manual, and before we get into it: hi bestie, welcome, you're gonna do great 🫢


πŸ’– NAME πŸ’–

struct bus_type β€” literally just: the bus type of the device. that's the whole vibe. that's what it is. πŸ’…


πŸŽ€ SYNOPSIS πŸŽ€

struct bus_type {
    const char              *name;
    const char              *dev_name;
    const struct attribute_group *const *bus_groups;
    const struct attribute_group *const *dev_groups;
    const struct attribute_group *const *drv_groups;
    int (*match)(struct device *dev, const struct device_driver *drv);
    int (*uevent)(const struct device *dev, struct kobj_uevent_env *env);
    int (*probe)(struct device *dev);
    void (*sync_state)(struct device *dev);
    void (*remove)(struct device *dev);
    void (*shutdown)(struct device *dev);
    const struct cpumask *(*irq_get_affinity)(struct device *dev, unsigned int irq_vec);
    int (*online)(struct device *dev);
    int (*offline)(struct device *dev);
    int (*suspend)(struct device *dev, pm_message_t state);
    int (*resume)(struct device *dev);
    int (*num_vf)(struct device *dev);
    int (*dma_configure)(struct device *dev);
    void (*dma_cleanup)(struct device *dev);
    const struct dev_pm_ops *pm;
    bool driver_override;
    bool need_parent_lock;
 };

look at all those function pointers, she's iconic πŸ‘‘


🌸 Members (the main characters) 🌸

okay so this is the whole cast, let's meet them one by one πŸ’–

  • name β€” the name of the bus. that's it. that's her name. πŸŽ€
  • dev_name β€” used for subsystems to enumerate devices like ("foou", dev->id). yes the manual literally says foou. iykyk. πŸ“
  • bus_groups β€” the default attributes of the bus itself.
  • dev_groups β€” the default attributes of the devices on the bus.
  • drv_groups β€” the default attributes of the device drivers on the bus.
  • match β€” called, perhaps multiple times, whenever a new device or driver is added for this bus. she should return a positive value if the given device can be handled by the given driver, and zero otherwise. she may also return an error code if determining that the driver supports the device is not possible. and in the case of -EPROBE_DEFER she'll queue the device for deferred probing. she's doing a lot, ngl 😭
  • uevent β€” called when a device is added, removed, or a few other things that generate uevents, to add the environment variables.
  • probe β€” called when a new device or driver add to this bus, and callback the specific driver's probe to initial the matched device. (yes bestie, that's the original wording, i'm not touching it 🫢)
  • sync_state β€” called to sync device state to software state after all the state tracking consumers linked to this device (present at the time of late_initcall) have successfully bound to a driver. if the device has no consumers, this function will be called at late_initcall_sync level. and if the device has consumers that are never bound to a driver, this function will never get called until they do. literally never. the suspense. πŸ’€
  • remove β€” called when a device removed from this bus. bye bestie πŸ‘‹
  • shutdown β€” called at shut-down time to quiesce the device. quiet down queen, it's bedtime πŸŒ™
  • irq_get_affinity β€” get the IRQ affinity mask for the device on this bus.
  • online β€” called to put the device back online (after offlining it). welcome back πŸ‘‘
  • offline β€” called to put the device offline for hot-removal. may fail. πŸ™ˆ
  • suspend β€” called when a device on this bus wants to go to sleep mode. goodnight 😴
  • resume β€” called to bring a device on this bus out of sleep mode. rise and grind β˜€οΈ
  • num_vf β€” called to find out how many virtual functions a device on this bus supports. counting era πŸ”’
  • dma_configure β€” called to setup DMA configuration on a device on this bus.
  • dma_cleanup β€” called to cleanup DMA configuration on a device on this bus. we love a tidy queen 🧹
  • pm β€” power management operations of this bus, callback the specific device driver's pm-ops.
  • driver_override β€” set to true if this bus supports the driver_override mechanism, which allows userspace to force a specific driver to bind to a device via a sysfs attribute. forcing it. main character energy fr fr πŸ’…
  • need_parent_lock β€” when probing or removing a device on this bus, the device core should lock the device's parent. protective parent vibes, we respect it 🫢

⚠️ Note ⚠️

this callback may be invoked with or without the device lock held. yes, either way. prepare accordingly bestie πŸ’€

πŸ¦‹ Description πŸ¦‹

so like, what even is a bus? a bus is a channel between the processor and one or more devices. ✨

for the purposes of the device model, all devices are connected via a bus β€” even if it's an internal, virtual, "platform" bus. no exceptions, everyone's on a bus, we're all connected 🌈

buses can plug into each other. a USB controller is usually a PCI device, for example. it's giving nesting dolls, it's giving lore 🧚

the device model represents the actual connections between buses and the devices they control. and a bus is represented by the bus_type structure. she contains the name, the default attributes, the bus' methods, PM operations, and the driver core's private data. full package, no notes πŸ’œ


πŸ‘€ SEE ALSO πŸ‘€

kernel file ./include/linux/device/bus.h, plus the whole friend group:

go read them, they're all slay πŸ”₯


and that's the page babes!! brought to you by the fine folks at ./include/linux/device, from the October 2026 drop πŸŽ€ mwah, go forth and enumerate your devices πŸ’–βœ¨

πŸ“¦ where this page comes from