Drivers

Purpose

drivers/ is the largest single area of the kernel — roughly 1.2 GB of source covering device drivers for every supported hardware class. It also contains the device model (drivers/base/) that organizes those drivers, bus subsystems, and the framework code that drivers plug into.

If you have ever heard "Linux supports X hardware," that support lives here.

Directory layout

drivers/ has ~140 immediate subdirectories. They cluster into a few rough categories:

Category	Examples
Device model	base/, bus/, dma/, dma-buf/, iommu/, irqchip/, clk/, reset/, regulator/, pinctrl/, gpio/, mfd/, power/, firmware/
Storage	nvme/, ata/, scsi/, block/, md/, cdrom/, mmc/, mtd/, nvmem/, target/, dax/, ufs/
Network	net/ (sub-divided into ethernet/, wireless/, wwan/, phy/, mdio/, pcs/, ppp/, vmxnet3/, virtio_net/, hundreds more)
Graphics & display	gpu/ (with drm/ underneath), video/ (legacy fbdev), accel/, accessibility/
Audio bridge	media/, staging/media/, plus much under sound/ (separate top-level)
Input & HID	input/, hid/
Buses	pci/, usb/, i2c/, spi/, pcmcia/, mmc/, cxl/, slimbus/, sdio/, cdx/, eisa/, firewire/, interconnect/, mailbox/, mux/, pcie-link/, bcma/, vmebus/, xen/, virtio/, vfio/, vdpa/, virt/
Power & thermal	cpufreq/, cpuidle/, thermal/, powercap/, hwmon/
Cryptographic accelerators	crypto/ (drivers; the API is in top-level crypto/)
Hypervisor/paravirt	xen/, hv/, vfio/, vhost/, vdpa/, virtio/, gnss/, ssb/
Security devices	tpm/ (under char/), tee/, siox/
Sensors & RTC	iio/, rtc/, hwmon/, counter/
Miscellaneous	char/, misc/, staging/, tty/, parport/, accessibility/, mailbox/, phy/, comedi/

Device model

The device-model spine lives in drivers/base/ and is built around these objects:

Object	File	Role
struct device	include/linux/device.h	A device of any kind.
struct device_driver	same	A driver registered with a bus.
struct bus_type	same	A bus, e.g. PCI, USB, platform.
struct class	same	A logical class of devices, e.g. block, tty.
struct kobject, struct kset	include/linux/kobject.h	Reference-counted objects, the basis for /sys.

Bus types implement match() and probe(). The probe function is called when a device is added to a bus and there's a matching driver. Drivers register with a bus via pci_register_driver, usb_register, platform_driver_register, etc.

graph LR
    BUS[Bus driver registers struct bus_type] -->|new device discovered| MATCH[bus_type.match]
    DRV[Driver: pci_register_driver / platform_driver_register / ...] -->|adds to bus| MATCH
    MATCH -->|on match| PROBE[driver.probe]
    PROBE -->|attach hardware| RUN[Driver attached]
    RUN -->|removal / unbind| REMOVE[driver.remove]

How drivers are written, in five lines

static int my_probe(struct platform_device *pdev) { ... }
static int my_remove(struct platform_device *pdev) { ... }
static const struct of_device_id my_of_match[] = { { .compatible = "foo,bar" }, {} };
static struct platform_driver my_driver = {
    .driver = { .name = "my-driver", .of_match_table = my_of_match },
    .probe = my_probe, .remove = my_remove,
};
module_platform_driver(my_driver);

A driver registers with a bus, declares the devices it supports (typically by of_device_id for device-tree, by PCI vendor/device IDs for PCI, etc.), and is invoked when a matching device is added.

Major sub-areas

drivers/gpu/

By far the biggest single area. Includes the Direct Rendering Manager (DRM) framework in drm/, with per-vendor drivers (amd/, i915/, nouveau/, xe/, msm/, panthor/, vc4/, v3d/, mediatek/, etc.). DRM provides modesetting (KMS), GEM/TTM memory managers, render command submission, GPU scheduling, and vendor-specific ioctls.

drivers/net/

Has its own organization roughly mirroring the network stack: per-vendor Ethernet (mlx5/, intel/i40e/, mellanox/mlx4/, broadcom/, realtek/, …), wireless (wireless/intel/iwlwifi/, wireless/ath/, …), WWAN, virtio-net, tun/tap, vxlan, geneve, etc. Drivers register net_devices with the Networking stack.

drivers/nvme/

NVMe host (initiator) and target (storage device behavior). Host transports: PCIe (host/pci.c), Fabrics over TCP/RDMA/FC. Target transports mirror the host. Implements both block/ and io_uring/ integration.

drivers/scsi/, drivers/ata/

Legacy storage stacks. SCSI is still the dominant API for many enterprise targets (SAS, FC, iSCSI, USB-mass-storage). ATA is for SATA / IDE / PATA.

drivers/usb/

Two halves: core/ is the USB stack (host controller drivers, device enumeration, class drivers), host/ and gadget/ are HCDs and the gadget framework respectively, plus per-class drivers like storage/, serial/, class/.

drivers/pci/

PCI / PCIe support. Configuration space, MSI/MSI-X, hotplug, IOV, ATS/PRI, PCI-AER (advanced error reporting), the host-bridge driver framework, and thousands of device-specific quirks in pci-quirks.c.

drivers/staging/

A "halfway house" for drivers that compile and have users but don't meet kernel coding/quality standards. The intent is to fix them up and graduate to drivers/<bus>/ or delete them. Many drivers have done both.

drivers/iommu/

IOMMU drivers (Intel VT-d, AMD-Vi, ARM SMMU, Apple DART, etc.) and the generic IOMMU API. Needed for DMA isolation, PCIe pass-through with VFIO/IOMMUFD.

drivers/clocksource/, drivers/cpufreq/, drivers/cpuidle/, drivers/thermal/

The platform side of the time and power subsystems.

drivers/firmware/

EFI runtime services, PSCI (ARM), SMCCC, ACPI helpers (with the bulk of ACPI in drivers/acpi/), platform vendor SMC blobs, etc.

drivers/dma-buf/

Cross-driver buffer sharing: struct dma_buf lets one driver export a buffer that another can import. Used heavily across GPU, V4L2, audio, and accelerator drivers.

drivers/vfio/ and drivers/vdpa/, drivers/vhost/

Userspace access to PCI devices (VFIO), virtual data-plane acceleration (vDPA), and the vhost-net/vhost-user accelerated paths used with QEMU.

drivers/iio/

Industrial I/O: ADCs, DACs, accelerometers, gyros, magnetometers, light sensors. Provides a uniform user-space interface in /sys/bus/iio/.

Integration points

Drivers are the largest consumer of:

• kernel/: request_irq, kthread_run, mutex_lock, dma_map_*, device_*, work queues.
• mm/: page allocation, dma-buf pinning, mmap.
• fs/: most drivers expose char devs (/dev/foo) implementing file_operations.
• block/: storage drivers register request_queues.
• net/: NIC drivers register net_devices.
• sound/: audio device drivers register with ALSA.
• security/: capability checks on most ioctls.

Key source files (entry points)

File	Purpose
drivers/base/core.c	Device-model heart: device_add, sysfs hookup.
drivers/base/bus.c	Bus-type registration and matching.
drivers/base/driver.c	Driver lifecycle.
drivers/base/dd.c	Device-driver matching, deferred probe.
drivers/base/platform.c	The "platform bus" used by SoC peripherals.
drivers/pci/probe.c	PCI bus walk.
drivers/usb/core/hub.c	USB hub driver — does enumeration.

Entry points for modification

• A new device driver: pick the right bus subdirectory. For an existing class (Ethernet, sound card, GPU, sensor), follow the conventions of an existing driver; the framework provides most of the work.
• A new bus type: rare. Register a bus_type and provide a match(). Examples: cdx/, cxl/, slimbus/.
• A new framework: very rare. Examples in living memory: drivers/iio/, drivers/cxl/, drivers/accel/.

Where to find what

Driver directories are named by hardware class. When unsure, git grep -l <DRIVER_NAME> or ./scripts/get_maintainer.pl against any file in the driver works.

Related pages

• Architecture support — per-arch low-level glue (interrupt routing, DMA topology).
• Block layer — storage drivers.
• Networking — NIC drivers.
• Sound — audio drivers.
• Virtualization — KVM, VFIO, virtio.
• Crypto — crypto API consumed by drivers/crypto/.