Understanding Linux /sys/bus: Principles and Practical Exploration

1. /sys/bus organization

/sys/bus is a top‑level sysfs directory that lists every bus type registered in the kernel (e.g., usb, pci, platform). Each bus type corresponds to a struct bus_type instance registered via bus_register(). The directory contains subdirectories such as devices and drivers:

geduer@ulan:/sys/bus/usb$ ls
device  drivers  drivers_autoprobe  drivers_probe  uevent

The devices entries are symbolic links to actual device nodes under /sys/devices. The drivers directory holds a subdirectory for each registered driver (e.g., usbhid, hub) and provides bind and unbind interfaces.

2. Kernel construction of /sys/bus

The organization stems from the core Linux device model, which links three structures: struct bus_type, struct device, and struct device_driver. A struct bus_type defines matching rules, lifecycle callbacks, sysfs attributes, and power‑management behavior for its bus.

Example: inspecting spi_bus_type with NanoCode commands:

Run x lk!spi_bus_type to obtain the address.

Run dt lk!bus_type 0xffff8000`0aae35f8 to dump the structure, revealing fields such as .name, .match, and .probe.

The registration process creates a global bus_kset (a top‑level kset) and per‑bus ksets for devices and drivers, initializing two klist lists ( klist_devices and klist_drivers) to safely track objects during hot‑plug and module unload.

kset vs. klist

kset builds the sysfs hierarchy visible to users.

klist manages kernel‑internal object lists with reference‑count protection.

3. Device‑driver matching based on the bus

When a new device is added, device_add() calls bus_probe_device(), which invokes the bus’s .match() function to find a suitable driver. If drivers_autoprobe is enabled, the driver is automatically bound and its probe() method is executed.

Matching flow (call chain):

device_initial_probe() → __device_attach() → bus_for_each_drv() → __device_attach_driver()
    → driver_match_device() → drv->bus->match(drv, dev)
    → driver_probe_device() → __driver_probe_device() → really_probe() → call_driver_probe()

call_driver_probe()

finally runs the driver’s .probe implementation.

USB storage example

Inserting a USB flash drive triggers the USB core to bind usb_storage_driver, which calls storage_probe(). storage_probe() performs three key tasks:

Protocol selection – prefers UAS if supported.

Quirk handling – applies vendor‑specific patches.

Asynchronous start – allocates us_data and schedules a worker thread.

The block device appears only after sd_probe() (invoked by the SCSI subsystem) creates scsi_disk and gendisk structures and registers the device with device_add_disk(), exposing /dev/sdX to user space.

4. NanoCode traversal practice

A NanoCode script recursively traverses all bus directories under /sys/bus and lists each bus’s devices and drivers. Example output for the USB bus:

usb5  0xffff0001078388a8  [usb: 0xffff80000aaed490]
│   │                │
▼   ▼                ▼
DeviceName  DeviceAddress  DriverName  DriverAddress

Additional command dt lk!device 0xffff0001078388a8 displays the full device structure.

5. Summary

/sys/bus serves as the scheduling hub of Linux’s hardware ecosystem. By classifying devices and drivers under distinct bus types, the kernel maintains order, supports a growing variety of hardware, and offers a clear sysfs view and manual control over binding and unbinding.