Device Driver Developer Interview Questions

A module is a unit of loadable kernel code; a driver is code that binds to devices. Most drivers are built as modules, but a driver can be built into the kernel, and many modules are not drivers at all (file systems, crypto algorithms, helpers).

When you run insmod or modprobe, the kernel copies the ELF object in, checks the version magic and, if enabled, the module signature, resolves its undefined symbols against exported kernel symbols, applies relocations and then calls the function registered with module_init(). For a driver that function usually just registers a struct pci_driver, platform_driver or similar. Registration makes the driver core walk existing devices on that bus and call probe() for each match, so probe can run before module_init() returns. modprobe differs from insmod in that it reads modules.dep and loads dependencies first.

Likely follow-up. What does module_platform_driver() expand to, and why is it preferred?

A dev_t holds a major and a minor number. Historically the major picked the driver and the minor picked the instance; today the kernel just maps a range of dev_t values to a struct cdev, and the driver uses the minor to find its per-device state.

The usual sequence is:

1. alloc_chrdev_region() to get a dynamic major and a block of minors.
2. cdev_init() with your file_operations, then cdev_add() (or cdev_device_add(), which also adds the struct device).
3. class_create() once and device_create() per instance, so a uevent fires and udev or devtmpfs creates the /dev node.

Teardown runs in reverse. For a single simple node, a misc device (misc_register()) does all of this with one shared major. A strong answer also notes that cdev_add() makes the device live immediately, so all state the file operations need must be ready before that call.

Likely follow-up. Why should cdev_add() be one of the last steps in probe?

Every device and every driver sits on a bus type (pci_bus_type, platform_bus_type, usb_bus_type and so on). When either a device or a driver is registered, the driver core calls the bus's match() callback for each candidate pair. The match uses whatever identity the bus has: vendor and device IDs for PCI, interface class and IDs for USB, and for platform devices the compatible string from device tree, an ACPI ID or a name.

On a match the core binds the pair and calls the bus probe(), which calls the driver's probe(). If probe returns 0 the device is bound, its driver pointer is set and it shows up under the driver in sysfs. If it returns -EPROBE_DEFER the core retries later. Any other error leaves the device unbound. You can bind and unbind by hand through the bind and unbind files in the driver's sysfs directory, which is also a quick way to test your remove path.

devm_ functions record a release action on the device, and the driver core runs those actions in reverse order when probe fails or after remove() returns. They remove most error unwinding from probe and make leaks on failure paths rare.

They are wrong when the resource's lifetime is not the binding's lifetime:

• Memory reachable from an open file. If user space holds the file open after unbind, a devm_kzalloc() buffer is freed while read() can still touch it. Use a refcounted object freed in release().
• Ordering against non-managed teardown. devm_request_irq() frees the interrupt after remove() has run, so the handler can fire after you have stopped clocks or freed a workqueue that remove() handled by hand. Either make everything managed in the right order or free the IRQ by hand.
• Resources created outside probe, for example on every open(), which would only be released at unbind.

The rule: devm_ is for things whose lifetime is exactly "while bound".

Likely follow-up. How would you add a custom cleanup step to the devm_ list?

Undo exactly what has been done, in reverse order, and return the error code, not a made-up one. Without devm_, the kernel idiom is a ladder of labels:

ret = clk_prepare_enable(priv->clk);
if (ret)
	return ret;
ret = request_irq(irq, my_irq, 0, "mydev", priv);
if (ret)
	goto err_clk;
ret = misc_register(&priv->misc);
if (ret)
	goto err_irq;
return 0;
err_irq:
	free_irq(irq, priv);
err_clk:
	clk_disable_unprepare(priv->clk);
	return ret;

Two points interviewers look for. First, the user-visible registration (misc device, net device, input device) comes last, because once it exists user space can call into you. Second, use dev_err_probe() for errors that might be -EPROBE_DEFER: it stays quiet for deferral, records the reason for the deferred list and prints everything else.

Separate the lifetime of the hardware from the lifetime of your driver object. The device can go away at any time (unbind, hot unplug, module removal), but a file descriptor can stay open indefinitely, so the object that file->private_data points to must outlive the hardware.

The standard design is:

• Put a struct kref (or embed the struct device and use its refcount) in the per-device object. open() takes a reference, release() drops it, and the final put frees the object.
• Keep a "gone" flag and the hardware pointers under a lock or rw_semaphore. remove() takes the lock for write, sets the flag, clears the pointers and wakes any sleepers. Every file operation takes the lock for read and returns -ENODEV if the flag is set.
• Use cdev_device_add() and cdev_device_del() so the cdev cannot be opened after removal starts.

This is why devm_ memory must not hold state reachable from file operations.

Device tree is a data structure, passed by the boot loader, that describes hardware that cannot be discovered: which peripherals exist, their register addresses, interrupts, clocks, pins and how they connect. It is compiled from .dts and .dtsi sources into a binary blob (.dtb).

Matching uses the compatible property. A node lists one or more strings from most specific to most generic, such as "vendor,soc-uart", "vendor,generic-uart". The driver provides an of_device_id table with the strings it supports and points driver.of_match_table at it. The platform bus tries each compatible string in order, so a driver for the specific variant wins over a generic one. MODULE_DEVICE_TABLE(of, ...) exports the table so the module can be autoloaded. In probe, of_device_get_match_data() or device_get_match_data() returns the per-variant data attached to the matching entry, which is the clean way to handle small hardware differences.

Through the resource APIs, almost always the managed versions, in probe:

base = devm_platform_ioremap_resource(pdev, 0);
if (IS_ERR(base))
	return PTR_ERR(base);
irq = platform_get_irq(pdev, 0);
if (irq < 0)
	return irq;
clk = devm_clk_get(&pdev->dev, "core");
if (IS_ERR(clk))
	return dev_err_probe(&pdev->dev, PTR_ERR(clk), "no clock\n");
vdd = devm_regulator_get(&pdev->dev, "vdd");

Names such as "core" and "vdd" refer to clock-names and vdd-supply in the node. Simple properties come from device_property_read_u32() and friends, and GPIOs from devm_gpiod_get(). Two details matter: platform_get_irq() returns a negative error (never 0) on failure, so test < 0, and getting a clock does not enable it; you still call clk_prepare_enable() or use devm_clk_get_enabled().

Likely follow-up. What does devm_clk_get_optional() return when the clock is absent?

A binding describes the hardware, not the driver's configuration or Linux internals. Reviewers reject properties such as "use DMA mode 2" or "buffer size", because those are software policy and would tie the binding to one operating system.

A good binding:

• Uses a specific compatible with a registered vendor prefix, plus a fallback only where the hardware really is compatible.
• Lists every resource the hardware has (registers, all interrupts, clocks, resets, supplies) even if today's driver does not use them all, because the binding is an ABI that outlives the driver.
• Uses standard property names and units (-microvolt, -hz) and the common schemas for things like interrupts and pin control.
• Is written as a YAML schema and passes make dt_binding_check, with example DTS that passes dtbs_check.

Bindings go to the device tree maintainers as a separate patch, before the driver patch in the series.

Use the firmware-independent property API instead of of_ functions. device_property_read_u32(), device_property_present(), fwnode_ iterators and device_get_match_data() work against a fwnode_handle, which can be backed by a DT node, an ACPI node or software nodes. Resources such as memory, IRQs, GPIOs and clocks already come through generic platform and descriptor APIs.

Then add both match tables: an of_device_id table and an acpi_device_id table keyed by the ACPI _HID. ACPI can carry DT-style properties through _DSD, which lets one property name serve both. Where ACPI provides power control through methods such as _PS0 and _PS3, the ACPI power domain usually handles it, and the driver's runtime PM calls still work. Keep any #ifdef CONFIG_OF blocks out of the driver; the generic API makes them unnecessary.

The old integer API used a global GPIO number space that depended on probe order and board configuration, so numbers were fragile and drivers often hard-coded them. The descriptor API (gpiod_) gives the driver an opaque struct gpio_desc looked up by function name from DT or ACPI, such as reset-gpios.

The biggest practical gain is polarity. The DT flag GPIO_ACTIVE_LOW is part of the description, and gpiod_set_value() works in logical terms: setting 1 means "asserted", and the library inverts the line if the pin is active low. The driver writes gpiod_set_value(reset, 1) to assert reset whatever the board wiring. The raw functions exist when you really need the physical level. Use the _cansleep variants when the GPIO may sit behind an I2C expander, and request the line with the right initial direction and value, for example devm_gpiod_get(dev, "reset", GPIOD_OUT_HIGH) to hold the device in reset from the start.

Follow the hardware sequence in the datasheet, which is usually: enable supplies, wait for them to settle, enable clocks, release reset, wait for the reset time, then access registers.

ret = regulator_enable(vdd);
...
ret = clk_prepare_enable(clk);
...
reset_control_deassert(rst);
usleep_range(10, 20);   /* datasheet reset release time */
id = readl(base + REG_ID);

Getting it wrong is not a gentle failure. On many ARM SoCs a read from a peripheral whose clock is gated or whose power domain is off stalls the bus or raises an asynchronous external abort, which shows up as a hang or a confusing oops far from the cause. A device held in reset may read as all zeros, so an ID check fails. With runtime PM, the same sequence lives in the resume callback, and probe calls it through pm_runtime_resume_and_get(). A good habit is to read and check an ID or version register right after power-up and fail probe with a clear message if it is wrong.

Because a user pointer is untrusted and may not point to valid, resident memory. copy_to_user() and copy_from_user() check that the range is inside the user part of the address space, so a malicious caller cannot pass a kernel address and read or overwrite kernel memory. They also handle page faults: if the page is swapped out or not yet allocated, the copy faults it in, and if the address is invalid the copy stops and returns the number of bytes it could not copy instead of crashing the kernel.

On modern CPUs there is a hardware layer too. SMAP on x86 and PAN on ARM make the kernel fault if it touches user memory outside the special accessor windows, so a plain dereference oopses even when the address is valid. Two consequences follow: the copy functions can sleep, so never call them under a spinlock, and a non-zero return should become -EFAULT.

Likely follow-up. What does copy_from_user() leave in the destination when it fails part-way?

Treat it as a permanent ABI and design it like one:

• Build command numbers with _IO, _IOR, _IOW and _IOWR, which encode a type letter, number, direction and argument size, and check the letter is not already heavily used.
• Use fixed-width types (__u32, __u64) in structures, never long or pointers. Pass pointers as __u64 so 32-bit and 64-bit callers see the same layout and no compat_ioctl translation is needed beyond compat_ptr_ioctl.
• Lay structures out with explicit padding so there are no hidden holes, and require reserved fields and flags to be zero so you can give them meaning later.
• Consider a size or version field for extensible structures.
• Return -ENOTTY for unknown commands, -EINVAL for bad arguments and -EFAULT for bad pointers.

Also ask whether ioctl is right at all. A single tunable belongs in sysfs, and networking configuration usually belongs in netlink.

Likely follow-up. Why is -ENOTTY, not -EINVAL, the right error for an unknown command?

Choose by who uses the interface and how stable it must be:

• sysfs: one value per file describing or controlling a device attribute, such as a threshold or a firmware version. It is ABI, so document it under Documentation/ABI, and use sysfs_emit() for output.
• debugfs: anything for developers, such as register dumps or fault injection. It has no ABI promise and is often not mounted on production systems, so never make a tool depend on it.
• ioctl: commands with structured arguments or performance needs on a device node, such as submitting a job to an accelerator.
• configfs: user space creating and configuring kernel objects, such as USB gadget functions.
• netlink: networking configuration and asynchronous events to many listeners.

A common review comment is "this binary blob in sysfs should be an ioctl" or the reverse. Also register sysfs attributes through dev_groups in the driver structure, so they exist before the uevent tells user space the device is there.

Keep a wait queue in the device and implement .poll like this:

static __poll_t mydev_poll(struct file *f, poll_table *pt)
{
	struct mydev *d = f->private_data;
	__poll_t mask = 0;

	poll_wait(f, &d->wq, pt);
	if (fifo_has_data(d))
		mask |= EPOLLIN | EPOLLRDNORM;
	if (fifo_has_space(d))
		mask |= EPOLLOUT | EPOLLWRNORM;
	return mask;
}

poll_wait() does not sleep. It registers the caller on the wait queue so that a later wake_up_interruptible(&d->wq), typically from the interrupt or completion path when data arrives, makes the core call .poll again. The poll function must be cheap, must not block, and must recheck the real state each time. Return EPOLLERR or EPOLLHUP when the device has gone so waiters do not hang after removal.

Implement .mmap and map physical pages into the caller's VMA, after checking the request against what you own.

For MMIO, the simplest safe call is vm_iomap_memory(vma, phys_base, size), which checks vm_pgoff and the length against the region and maps it with io_remap_pfn_range(). Set the page protection first, usually pgprot_noncached() for registers or pgprot_writecombine() for frame buffers. For a buffer from dma_alloc_coherent(), use dma_mmap_coherent(), which picks the right attributes for the platform. For ordinary kernel pages you can use remap_pfn_range() or vm_insert_page(), or provide a .fault handler that inserts pages on demand.

The pitfalls interviewers probe: never trust vm_pgoff and the VMA size without checking, never map more than whole pages you own (a partial page leaks neighbouring data), and think about what happens to the mapping when the device is removed. Exposing registers to user space also exposes DMA engines, which can then write anywhere unless an IOMMU confines the device.

The common findings are:

• Missing permission checks. Privileged operations need capable(CAP_SYS_ADMIN) or a narrower capability, checked in the ioctl, not only by file mode.
• Information leaks. Copying a stack structure to user space with uninitialised padding or unused fields leaks kernel memory. Zero it first with = {} or memset().
• Integer overflow. count * sizeof(elem) can wrap. Use array_size(), check_mul_overflow() or kmalloc_array().
• Unchecked indices. A user-supplied index used to read an array needs a bounds check, and on hot paths array_index_nospec() to stop speculative out-of-bounds reads.
• Double fetch and races. Copy once, and hold the right lock while you act on device state.
• Unbounded allocations. Cap sizes so a user cannot make the kernel allocate gigabytes.

Fuzzing with syzkaller, which knows ioctl argument formats through descriptions, finds many of these automatically.

A hard interrupt handler runs in atomic context: it interrupted whatever the CPU was doing, there is no process to put to sleep, and on the local CPU that interrupt line (and often all interrupts) is masked. So you must not:

• Sleep or call anything that might: mutex_lock(), msleep(), copy_to_user(), kmalloc(GFP_KERNEL), most I2C and SPI transfers, wait_event().
• Take a lock that process context holds without disabling interrupts, or you deadlock on the same CPU.
• Spend long. Interrupt latency for everything else on that CPU grows with your handler time.

What a handler should do: read and acknowledge the device status so the line drops, capture the minimum data, and hand the rest to a threaded handler, workqueue or NAPI poll. It returns IRQ_HANDLED if its device raised the interrupt and IRQ_NONE otherwise.

Likely follow-up. Where would you put a 2 ms I2C read that the interrupt triggers?

Use a threaded interrupt when handling the event needs to sleep or takes long, which is almost always the case for devices on I2C or SPI and common for anything with a slow command path. You pass two functions: a primary handler that runs in hard interrupt context and a thread function that runs in a dedicated kernel thread with a real-time priority.

The primary handler returns IRQ_WAKE_THREAD to run the thread. If you pass NULL as the primary, the core uses a default that just wakes the thread. In that case you must set IRQF_ONESHOT, which keeps the interrupt line masked until the thread function returns. Without it, a level-triggered line from a device you have not yet serviced would fire again immediately and the CPU would never reach the thread. With a real primary handler you can avoid ONESHOT if that handler silences the device itself. devm_request_threaded_irq() is the managed form.

• Softirqs run in interrupt context after hard interrupts or in the ksoftirqd threads. The set is fixed at compile time (networking receive and transmit, block completion, timers, RCU). Drivers do not add new ones; NAPI is how network drivers use them.
• Tasklets are built on softirqs. A given tasklet never runs on two CPUs at once, but it still cannot sleep. They are discouraged for new code because they give poor latency control.
• Workqueues run functions in kernel worker threads in process context, so they can sleep, take mutexes and do I2C transfers.
• Threaded interrupts are a dedicated thread per handler, tied to the interrupt, with the line masked while it runs if ONESHOT is set. They are the default answer for slow devices.

The decision rule: if you need to sleep, use a threaded IRQ or a workqueue; if you need high throughput with batching on a network or block path, use the subsystem mechanism (NAPI, blk-mq completion).

A level-triggered line stays asserted as long as the device has an unserviced event, so the controller keeps signalling until the handler clears the cause. An edge-triggered line signals once on a transition. Level is safer for sharing and for not missing events, edge is simpler for things like a button or a pulse output.

The classic lost edge: the device raises its line for event A, the handler starts, reads the status, and while it is handling A the device finishes event B. If the device's output only produces a new edge when it goes from idle to active, and the line never dropped between A and B, no new edge arrives and B sits unhandled until something else happens. Fixes are to loop in the handler, re-reading status until it is clear before returning, to clear the status bits you have read before processing them, and to use the device's level mode if it has one. Interviewers also like the converse bug for level mode: forgetting to clear the cause, which causes an interrupt storm.

Start by finding which line is firing. Read /proc/interrupts twice a second apart: the count that is climbing by tens of thousands is the storm. /proc/irq/N/ and the handler name tell you whose it is.

Then the usual causes, in order of likelihood:

• The cause is never cleared. A level-triggered interrupt whose status bit the handler does not write back, or writes to the wrong register (write-one-to-clear versus write-zero), keeps the line asserted.
• Wrong trigger type in DT, such as level-high on a line that is active low, so the line looks asserted when idle.
• Clearing the status before the source. Some devices need the internal event source handled first, otherwise the status bit sets again at once.
• A threaded IRQ without ONESHOT on a level line.
• Returning IRQ_HANDLED on a shared line for an interrupt you did not handle.

Tools that help: ftrace with the irq:irq_handler_entry and irq_handler_exit events to see the rate and return values, and a quick printk of the status register with rate limiting.

disable_irq() masks the line and then waits, through synchronize_irq(), for any running instance of the handler to finish. Called from inside that handler, it waits for itself and never returns. Inside the handler use disable_irq_nosync(), which masks the line without waiting.

For remove, the safe order is:

1. Tell the device to stop generating interrupts by clearing its interrupt enable register.
2. Free the interrupt with free_irq(), or call synchronize_irq() if you keep it, which guarantees no handler is still running on another CPU.
3. Cancel deferred work that the handler might have queued, with the _sync cancel functions.
4. Only now free buffers and structures the handler used, and turn off clocks.

If you free the IRQ while the device can still assert a shared line, or free memory before the handler has finished on another CPU, you get use-after-free crashes that only show up under load.

Use a mutex when the critical section may sleep or is long, and every user is in process context. Use a spinlock when any user runs in atomic context (an interrupt handler, softirq or timer callback) or when the critical section is a few instructions.

The reasons: a mutex puts a waiting task to sleep, which cannot happen in interrupt context, and it is cheaper than spinning when the holder may sleep or take a long time. A spinlock busy-waits and disables preemption while held, so the holder must never sleep: if it did, another task on the same CPU could spin forever waiting for it. Spinlock critical sections should be short and contain no copy_to_user(), no allocation with GFP_KERNEL and no bus transfers on I2C or SPI.

A typical driver uses both: a mutex to serialise configuration from ioctl and sysfs, and a spinlock to protect the small state shared with the interrupt handler, such as a FIFO index.

It depends on which contexts take the lock:

• Only process context: spin_lock() is enough, or a mutex.
• Process context and softirq or tasklet or timer: process context uses spin_lock_bh(), which disables bottom halves on the local CPU so a softirq cannot interrupt the holder and spin on the same lock. The softirq itself uses plain spin_lock().
• Any context and a hard interrupt handler: the non-interrupt side uses spin_lock_irqsave(), which disables local interrupts and saves the previous state. Otherwise the interrupt could arrive on the same CPU while the lock is held, and its handler would spin forever. Inside the hard handler plain spin_lock() is enough because the line is already masked.

spin_lock_irq() is a variant that disables and later enables interrupts unconditionally; it is only correct when you know interrupts were enabled on entry. Use irqsave when in doubt. Lockdep reports the wrong choice as an "inconsistent lock state" warning.

Atomic context is any code path where the scheduler cannot be called: hard and soft interrupt handlers, code holding a spinlock, code with preemption or interrupts disabled, and RCU read-side critical sections for normal RCU. Sleeping there either deadlocks or corrupts scheduler state.

You cannot reliably test for it at run time. in_atomic() does not see a held spinlock on kernels built without preemption counting, which is why drivers should not change behaviour based on it. Instead, design so each function is documented to run in one context, and pass allocation flags down (GFP_ATOMIC versus GFP_KERNEL) when a helper serves both.

To find violations, enable CONFIG_DEBUG_ATOMIC_SLEEP. Functions that may sleep call might_sleep(), which then prints "BUG: sleeping function called from invalid context" with a stack trace the first time it happens, even if it would not have actually slept. Add might_sleep() to your own helpers that can block so the check covers them too. Lockdep and CONFIG_PROVE_LOCKING catch the related problems.

Read-copy-update lets readers access shared data with almost no cost and no locks, while writers make changes by publishing a new version and freeing the old one only after every reader that might see it has finished.

Readers wrap access in rcu_read_lock() and rcu_read_unlock() and load pointers with rcu_dereference(). A writer, serialised against other writers by an ordinary lock, builds a new copy, publishes it with rcu_assign_pointer(), then waits for a grace period with synchronize_rcu() or defers the free with call_rcu() or kfree_rcu(). A grace period ends once every CPU has passed through a quiescent state, so every pre-existing reader is done.

It suits read-mostly data on hot paths: a table of registered handlers, a list of active devices looked up on every packet, a configuration pointer read in the interrupt handler. It is the wrong tool when writes are frequent or readers need to sleep (use SRCU or a lock). The common bug is touching the old object after publishing, or freeing it directly instead of after a grace period.

They order different things:

• smp_mb(), smp_rmb(), smp_wmb() order memory accesses between CPUs. On a uniprocessor build they become compiler barriers only. Use them for lock-free data shared between CPUs, usually paired: a write barrier on the producer matched by a read barrier on the consumer. smp_store_release() and smp_load_acquire() express the same thing more precisely.
• mb(), rmb(), wmb() are mandatory barriers that also order accesses against devices, including MMIO. Drivers rarely need them directly because writel() and readl() already contain the needed ordering.
• dma_wmb() and dma_rmb() order accesses to coherent DMA memory as seen by a device. The classic use: write descriptor fields, dma_wmb(), then set the ownership bit; and read the ownership bit, dma_rmb(), then read the other fields.
• READ_ONCE() and WRITE_ONCE() stop the compiler from tearing, merging, repeating or caching an access. They give no CPU ordering on their own.

A strong candidate says which pair of accesses must stay in order, and to which observer, before picking a barrier.

Likely follow-up. Do you need a wmb() between filling a descriptor in coherent memory and the writel() to the doorbell?

A completion is for "wait until this one event has happened", which is the shape of most driver command paths: send a command to the device, wait for the interrupt that says it finished.

reinit_completion(&d->cmd_done);
writel(CMD_START, d->base + REG_CMD);
if (!wait_for_completion_timeout(&d->cmd_done, msecs_to_jiffies(100)))
	return -ETIMEDOUT;

The interrupt handler calls complete(&d->cmd_done). Completions handle the race where the event happens before the waiter sleeps, because the completion counts done events. A bare wait queue needs you to manage the condition variable yourself, which is right when the condition is something richer, such as "the FIFO has data or the device has gone". Semaphores are rarely appropriate in new driver code: as a lock a mutex is better, and as an event a completion is clearer.

Note the timeout. Hardware fails, and an untimed wait on a device that never answers creates an unkillable task. After a timeout, also make sure a late interrupt cannot complete a later command.

Register memory is not normal memory, and the accessors encode what the compiler and CPU must do with it:

• Mapping. You get a virtual address for registers with ioremap() or devm_platform_ioremap_resource(), which maps the physical range with device memory attributes (uncached, no speculative access). The result is a void __iomem *, and the sparse checker (make C=1) warns if you dereference it directly.
• Exactly one access of the right width. The compiler must not merge, split, cache or reorder register accesses. A 32-bit status register must be read with one 32-bit load.
• Ordering. writel() contains a barrier so earlier writes to normal memory, such as DMA descriptors, are visible to the device before the register write. readl() completes before later memory reads.
• Endianness. readl() assumes a little-endian device and converts on big-endian CPUs. For big-endian registers use ioread32be().

Port I/O on x86 uses inb() and outb(); ioread32() works for both mapped memory and ports.

The relaxed accessors still perform one access of the right size, in order with other accesses to the same device, but they drop the barrier that orders them against normal memory accesses. writel_relaxed() can become visible to the device before an earlier write to a DMA buffer, and readl_relaxed() can let a later read of DMA memory see stale data. They are useful in tight loops of register-only accesses, such as programming a block of configuration registers, where the barriers cost time and add nothing.

Reading a register after writing is a different issue: posted writes. On PCI and many SoC interconnects, a write can sit in a bridge buffer after the CPU has moved on. If the code needs the write to have reached the device before continuing, for example disabling interrupts before freeing the handler's data, or before a delay that the datasheet requires, a read from the same device flushes it, because the read cannot pass the earlier write on the way. The read is not about the value; it is about the ordering.

Coherent (consistent) memory comes from dma_alloc_coherent(). It returns a CPU virtual address and a dma_addr_t for the device, and both sides can access it at any time and see each other's writes without explicit cache maintenance. On systems without hardware coherency this is achieved by mapping the memory uncached, which makes CPU access slow. It suits long-lived shared structures: descriptor rings, command queues, status blocks.

Streaming mappings use dma_map_single(), dma_map_page() or dma_map_sg() on memory the driver already has, such as a network packet buffer. The mapping has a direction and an ownership rule: after mapping, the device owns the buffer, and the CPU must not touch it until dma_unmap_*() or dma_sync_*_for_cpu(). The calls do the cache cleaning or invalidating, or bouncing, that the platform needs. Streaming mappings keep normal cached memory for the CPU and are the right choice for data buffers that change for every transfer.

Always check dma_mapping_error() after a streaming map.

A mapped streaming buffer belongs either to the device or to the CPU, and the sync calls move it between them without unmapping:

dma = dma_map_single(dev, buf, len, DMA_FROM_DEVICE);
/* device owns buf: start the transfer, wait for completion */
dma_sync_single_for_cpu(dev, dma, len, DMA_FROM_DEVICE);
process(buf);                         /* CPU owns buf */
dma_sync_single_for_device(dev, dma, len, DMA_FROM_DEVICE);
/* device owns it again for the next transfer */

On a non-coherent system, for_device with DMA_TO_DEVICE cleans (writes back) the CPU caches so the device reads what the CPU wrote, and for_cpu with DMA_FROM_DEVICE invalidates the caches so the CPU does not read stale lines. With bounce buffers, the same calls copy data. On a coherent x86 system they may do almost nothing, which is exactly why missing sync calls pass testing on x86 and corrupt data on ARM.

Use the most precise direction; DMA_BIDIRECTIONAL costs more maintenance. Never touch the buffer from the CPU while the device owns it, not even to read it.

For a correctly written driver, almost nothing in the code, and a lot in behaviour.

The IOMMU translates addresses the device emits (IO virtual addresses) to physical addresses using page tables the kernel controls. The DMA API returns an IOVA in dma_addr_t instead of a physical address. Consequences:

• Isolation. A device can only reach memory currently mapped for it. A buggy DMA engine faults instead of overwriting random kernel memory, and the IOMMU driver logs the faulting address, which is a powerful debugging aid.
• Mapping lifetime matters. Using a DMA address after unmap, which went unnoticed without an IOMMU, now faults or hits another buffer.
• Scatter-gather merging. Scattered pages can appear contiguous to the device.
• Cost. Map and unmap need page table updates and TLB invalidations, which shows up in high-rate drivers.

The rules for drivers follow from this: always use the DMA API, never virt_to_phys() for device addresses, and never assume a dma_addr_t equals a physical address.

Pin the user pages, build a scatter list, map it, and undo everything when the transfer completes:

1. Validate the address and length, then call pin_user_pages_fast() with FOLL_WRITE if the device will write. Pinning stops the pages from being migrated or swapped while the device uses them.
2. Build a table with sg_alloc_table_from_pages(), which merges physically adjacent pages.
3. Map with dma_map_sgtable(), check the result and program the device with each mapped segment, respecting its maximum segment size.
4. On completion, dma_unmap_sgtable(), then unpin_user_pages_dirty_lock() for pages the device wrote so the kernel knows they changed, and free the table.

Points that matter in an interview: the user buffer is usually not page aligned, so the first and last pages are partial, and the process can exit or unmap the range while DMA is running, so the pin, not the user mapping, is what keeps the pages alive. For buffers shared between devices, such as a camera and a GPU, the kernel's dma-buf framework is the standard alternative.

A typical order, using managed helpers where they exist:

1. pcim_enable_device() to wake the device and enable memory decoding.
2. Request and map the BARs you use, with pci_request_regions() and pci_iomap() or their managed equivalents, so no other driver claims the same resources.
3. pci_set_master() so the device may initiate DMA.
4. Set the DMA mask with dma_set_mask_and_coherent().
5. Read and check a version or capability register, and reset the device to a known state.
6. Allocate interrupt vectors with pci_alloc_irq_vectors() and request handlers.
7. Allocate rings and other DMA memory.
8. Register with the subsystem last: register_netdev(), a block disk, a char device. From this moment requests can arrive.

remove() does the reverse: unregister from the subsystem first, so no new requests come in, then quiesce the device, free interrupts, free DMA memory and disable the device. Interviewers watch for registration too early and for DMA being enabled before the rings exist.

A USB device exposes interfaces, and each interface has endpoints, which are one-directional pipes identified by number and direction. Endpoint 0 is the bidirectional control pipe every device has. The other endpoints have one of four transfer types:

• Control for setup and configuration requests.
• Bulk for large data with guaranteed delivery but no timing guarantee, such as storage.
• Interrupt for small, latency-bounded polling, such as a keyboard or a status endpoint.
• Isochronous for streaming with reserved bandwidth and no retries, such as audio and video.

A Linux USB driver binds to an interface, not a device. It moves data with URBs: allocate with usb_alloc_urb(), fill with usb_fill_bulk_urb() and friends, giving a buffer and a completion callback, and submit with usb_submit_urb(). The completion runs in atomic context and reports status in urb->status, where -ENOENT, -ECONNRESET and -ESHUTDOWN mean "cancelled" or "device gone" rather than errors to retry. In disconnect(), kill outstanding URBs with usb_kill_urb() or an anchor before freeing anything.

The stack calls ndo_start_xmit(skb, netdev) with the queue lock held and bottom halves disabled, so it must not sleep. The driver:

1. Maps the packet's head and fragments for DMA (dma_map_single() and skb_frag_dma_map()), checking for mapping errors.
2. Fills one or more TX descriptors, sets the ownership bit last after dma_wmb(), and records the skb so it can be freed later.
3. Writes the tail or doorbell register.
4. If the ring no longer has room for a maximum-size packet, calls netif_stop_queue() (or the per-queue variant) so the stack stops sending.
5. Returns NETDEV_TX_OK.

Completion happens later, usually in NAPI poll: the driver walks the ring, unmaps buffers, frees skbs with napi_consume_skb(), updates statistics, and when enough space is free calls netif_wake_queue(). Returning NETDEV_TX_BUSY is treated as a driver bug in most cases; stopping the queue early avoids it.

NAPI is the network stack's interrupt mitigation scheme. A purely interrupt-driven receive path takes one interrupt per packet, and at high packet rates the CPU spends all its time entering and leaving interrupt handlers and never gets to process the packets, a condition called receive livelock.

With NAPI, the receive interrupt handler disables further receive interrupts from the device and calls napi_schedule(). The poll function then runs in softirq context with a budget, typically 64 packets. It processes up to that many completed receive descriptors, hands packets up with napi_gro_receive(), and refills the ring. If it used less than the budget, the ring is drained: it calls napi_complete_done() and re-enables the device interrupt. If it used the whole budget, it returns without re-enabling, and the core polls it again later, sharing the CPU fairly with other devices.

So under light load you get interrupt latency, and under heavy load you get polling efficiency. A common bug is re-enabling interrupts before napi_complete_done() returns true, which can lose a wake-up.

Every register access on I2C or SPI is a bus transaction through a controller driver, and those transfers sleep. So register access is slow (tens to hundreds of microseconds), can fail with an error code, and is forbidden in atomic context. Interrupt handling therefore uses a threaded IRQ, and anything polled uses delayed work.

regmap is an abstraction over register maps that most such drivers use. You describe the register width, value width and bus in a regmap_config, create it with devm_regmap_init_i2c() or the SPI equivalent, then use regmap_read(), regmap_write() and regmap_update_bits(). It gives:

• Locking around read-modify-write sequences.
• An optional register cache, which saves bus traffic and lets you restore all registers after a power loss with regcache_sync().
• Volatile, readable and writeable register lists, so mistakes are caught.
• Debugfs dumps of register contents, and the same driver code for I2C and SPI variants of a chip.

There is also regmap_irq for chips with an interrupt status and mask register block.

The driver allocates a tag set that describes its hardware queues, the depth of each and the size of a per-request private area, with blk_mq_alloc_tag_set(). From it, it creates a disk with its request queue. The block layer hands requests to the driver's queue_rq() callback.

In queue_rq() the driver calls blk_mq_start_request(), translates the request into device commands, maps its data with blk_rq_map_sg() and the DMA API, uses the request's tag as the command identifier, and rings the doorbell. If the device has no room it returns BLK_STS_RESOURCE (or BLK_STS_DEV_RESOURCE) and the core retries later; any other non-OK status fails the request.

On completion, usually from an interrupt, the driver looks up the request from the tag with blk_mq_tag_to_rq(), records the status and calls blk_mq_complete_request(), which can redirect completion to the submitting CPU, and the complete callback ends it with blk_mq_end_request(). A timeout callback handles commands the device never finished. NVMe is the reference design for this model.

System sleep (suspend to RAM, suspend to idle, hibernation) is a whole-system transition started by user space or a policy daemon. The PM core freezes user space, then calls every driver's suspend callbacks in an order derived from the device hierarchy and device links, and later the resume callbacks in reverse. The driver must stop all activity and save whatever state will be lost.

Runtime PM is per device and happens while the system is running. A driver powers its device down when it is idle and up again when it is needed, through runtime_suspend and runtime_resume callbacks. The PM core tracks a usage count and calls the callbacks when the count reaches zero, optionally after an autosuspend delay so that bursts of activity do not cause constant power cycling.

Many drivers implement system sleep by reusing runtime PM, with pm_runtime_force_suspend() and pm_runtime_force_resume().

In probe, enable runtime PM with autosuspend, then in each I/O path take a reference while you use the hardware:

/* probe */
pm_runtime_set_autosuspend_delay(dev, 200);
pm_runtime_use_autosuspend(dev);
devm_pm_runtime_enable(dev);

/* I/O path */
ret = pm_runtime_resume_and_get(dev);
if (ret)
	return ret;
val = readl(priv->base + REG_DATA);
pm_runtime_mark_last_busy(dev);
pm_runtime_put_autosuspend(dev);

The trap interviewers look for: pm_runtime_get_sync() increments the usage count even when resume fails, so code that returns on error without calling pm_runtime_put_noidle() leaks a reference and the device never suspends again. pm_runtime_resume_and_get() drops the count itself on failure, which is why it is preferred. Every get must have exactly one put on every path, including error paths.

Suspend must leave the device quiet and its state recoverable:

• Stop accepting new work and wait for or cancel work in flight, including timers and work items.
• Disable the device's interrupts at the device so it does not fire during the transition.
• Save any register state that will be lost, unless a regmap cache holds it.
• Configure wake-up if the device is a wake source, and select the sleep pin state.
• Gate clocks and disable regulators in the order the hardware needs.

Resume reverses it: power, clocks, reset if required, restore registers (often regcache_sync()), re-enable interrupts and restart queues. Resume must assume the device lost all state, because on many platforms it did, and must handle the device not coming back by failing cleanly rather than hanging.

The PM core offers phases: prepare, suspend, suspend_late, suspend_noirq and the matching resume phases.

A wake source is an interrupt that stays armed while the system sleeps and brings it back, such as a power button, an RTC alarm, a network magic packet or a modem.

The driver's part:

• Declare the capability with device_init_wakeup(dev, true) in probe if the hardware and board support it, often from a wakeup-source DT property. This creates the power/wakeup file that lets user space enable or disable wake-up.
• In suspend, if device_may_wakeup(dev) is true, configure the device to signal on the wake event and call enable_irq_wake(irq) so the interrupt controller keeps the line armed. Disable everything else.
• In resume, call disable_irq_wake(irq) and restore normal operation.
• When the wake interrupt arrives, call pm_wakeup_event() or hold a wakeup source while processing the event, so the system does not go back to sleep before user space has handled it.

The usual bugs are unbalanced enable_irq_wake() calls and wake events lost because resume cleared the status without reporting it.

The clock API is split into two halves. clk_prepare() and clk_unprepare() may sleep, because preparing a clock can involve starting a PLL or talking to a power management IC over I2C. clk_enable() and clk_disable() must not sleep and can be called in atomic context. clk_prepare_enable() does both and so may sleep. Regulator calls generally may sleep.

That matters because runtime PM callbacks normally run in process context, where sleeping is fine, but some drivers mark themselves pm_runtime_irq_safe() so they can resume the device from an interrupt handler. Then the callbacks run with interrupts disabled and may only use non-sleeping operations: keep clocks prepared from probe and only enable and disable them in the callbacks. The cost is that the parent device is kept permanently powered, so IRQ-safe runtime PM should be a deliberate exception. A strong candidate also mentions that power domains, attached through the PM domain framework, handle much of the switching without the driver calling the regulator directly.

On a shared interrupt line, or if a wake-up interrupt fires during the resume transition, the handler can run while your device's clocks are off. Reading a register then returns garbage or stalls the bus.

Options, depending on the design:

• In the handler, use pm_runtime_get_if_active() (or pm_runtime_get_if_in_use()), which takes a reference only if the device is already active. If it fails, return IRQ_NONE because your device could not have raised the interrupt while suspended.
• Keep a driver flag, set in runtime_suspend after disabling the device's interrupt output and cleared in runtime_resume, protected by the same spinlock the handler takes.
• Disable the interrupt with disable_irq() in runtime_suspend, if the line is not shared, and enable it in runtime_resume.

Whatever you choose, the device's own interrupt enable bits must be cleared before power goes off, and pending status must be cleared on resume before enabling, or you get a spurious interrupt at a bad moment.

Use the device-aware helpers: dev_err(), dev_warn(), dev_info() and dev_dbg(). They prefix the driver and device name, so logs from several instances can be told apart. Use pr_ variants only where there is no device. Error messages should say what failed and include the error code, and should not fire for normal conditions such as deferral.

dev_dbg() compiles to nothing unless DEBUG is defined, or, more usefully, CONFIG_DYNAMIC_DEBUG is enabled. Then each call site can be switched on at run time:

echo 'module mydrv +p' > /sys/kernel/debug/dynamic_debug/control
echo 'file mydrv_core.c line 210 +p' > /sys/kernel/debug/dynamic_debug/control

It can also be enabled at boot with dyndbg= parameters. For messages that could repeat at interrupt rate, use dev_err_ratelimited() or dev_warn_once(), since a flood of console output can itself cause timing problems and lockups on slow serial consoles. trace_printk() is a faster option during development because it writes into the ftrace buffer instead of the console.

Read the header first: the type of fault (NULL pointer dereference, paging request at a given address, BUG at file:line), the CPU and process, and the Tainted flags, which show whether out-of-tree or previously warned code is involved. Then the program counter, printed as function+offset/length, and the call trace.

To get a source line, you need the exact module binary with debug information:

./scripts/faddr2line drivers/foo/mydrv.ko mydrv_irq+0x4c/0x120
./scripts/decode_stacktrace.sh vmlinux . drivers/foo < oops.txt

Or use gdb with list *(mydrv_irq+0x4c). Then reason from the register dump: a faulting address of 0x0000000000000010 means a NULL structure pointer with the accessed field at offset 0x10, which usually identifies the field and therefore the pointer. Address patterns such as 0x6b6b6b6b (slab poison) point to a use-after-free. Finally ask what context the code ran in and what else could have freed or changed the object, which is where the real cause usually is.

ftrace is the kernel's built-in tracer, controlled through /sys/kernel/tracing or the trace-cmd front end. The parts drivers use most:

• Function and function_graph tracers. Set set_ftrace_filter to your driver's functions and see every call with timing. function_graph shows nesting and duration, which is the fastest way to see where probe or resume spends its time.
• Tracepoints. Events such as irq:irq_handler_entry, workqueue:workqueue_execute_start, i2c:i2c_write or block:block_rq_issue show what subsystems are doing without changing code. Drivers can define their own with TRACE_EVENT().
• trace_printk(). A cheap printf into the trace buffer that does not disturb timing the way printk to a console does.
• Latency tracers such as irqsoff and preemptoff, which find the longest sections with interrupts or preemption disabled.

Because trace data goes into a per-CPU ring buffer, it captures interleavings across CPUs, so it is the right tool for races between an interrupt and process context.

A debug configuration for driver work usually includes:

• KASAN: out-of-bounds accesses and use-after-free on heap, stack and globals, with allocation and free stack traces. Large overhead, so development only.
• KFENCE: a low-overhead sampling version of the same idea, suitable for production.
• Lockdep and PROVE_LOCKING: lock order and context bugs before they deadlock.
• DEBUG_ATOMIC_SLEEP: sleeping in atomic context.
• KCSAN: data races between CPUs on plain accesses.
• UBSAN: undefined behaviour such as shifts too large and signed overflow.
• kmemleak: memory that is no longer referenced, reported through debugfs.
• DMA_API_DEBUG: unmapping with the wrong size or direction, CPU access to buffers the device owns, leaked mappings at unbind.
• DEBUG_OBJECTS for timers and work, and SLUB debugging with poisoning.

Pair these with fuzzing through syzkaller for the user interface and repeated bind and unbind or module load and unload loops for lifetime bugs. A candidate who uses DMA API debugging stands out, because few people know it exists.

First decide what kind of hang it is, because the tools differ:

• One CPU stuck with interrupts disabled (spinning on a lock with interrupts off, a loop in a hard interrupt handler): the hard lockup detector, driven by the NMI watchdog, prints a backtrace. Enable it and make sure the console reaches you, through a serial port or netconsole.
• A CPU stuck in the kernel without scheduling: the soft lockup detector reports it after about twenty seconds.
• Tasks blocked forever in uninterruptible sleep, typically waiting on a mutex or a completion: the hung task detector reports them with stacks after a timeout, and SysRq w dumps all blocked tasks on demand. SysRq l shows backtraces on all CPUs.
• Completely dead machine: configure kdump so a panic, which you can force with the panic_on_ sysctls or SysRq c, boots a capture kernel that saves memory. Then use the crash tool to inspect stacks, locks and your driver's structures.

Then make it reproducible and smaller: lockdep often explains a deadlock that the watchdogs only detect.

Prepare a clean patch series against the maintainer's tree for that subsystem, not an old stable release:

1. Split the work into logical, bisectable patches: device tree binding first, then the driver, then the DTS changes, each building on its own.
2. Run scripts/checkpatch.pl --strict, build with W=1 and C=1 for sparse, and for bindings run make dt_binding_check.
3. Write commit messages that say why the change is needed, not only what it does, and add a Signed-off-by: line, which certifies the Developer Certificate of Origin.
4. Find recipients with scripts/get_maintainer.pl and send plain-text patches with git send-email, with a cover letter for a series.
5. Respond to every review comment, either by changing the code or explaining why not. Send the next version with a v2 prefix and a changelog below the --- line.

Patience and courtesy matter as much as code. Maintainers are busy; a polite reminder after a couple of weeks is normal, while resending unchanged or arguing every point is not.

IRQL (interrupt request level) is the Windows kernel's priority scheme for the processor. Code at a given IRQL can only be interrupted by something at a higher level. The levels a driver meets are:

• PASSIVE_LEVEL: normal thread context. You can wait, take any lock, touch pageable memory and call almost any routine.
• APC_LEVEL: asynchronous procedure calls are masked, used inside some locks and paging I/O.
• DISPATCH_LEVEL: the scheduler cannot run on this CPU. Deferred procedure calls run here, and spin locks raise to it. You cannot wait on objects with a non-zero timeout and must not touch pageable code or data, because a page fault cannot be serviced.
• DIRQL: device interrupt levels, where the interrupt service routine runs.

The rule maps closely to Linux: DISPATCH_LEVEL behaves like atomic context and PASSIVE_LEVEL like process context. Breaking it gives the well-known IRQL_NOT_LESS_OR_EQUAL bug check. Driver Verifier, run during development, makes these errors show up reliably.

WDM is the original Windows Driver Model. Drivers handle I/O request packets and Plug and Play and power IRPs directly, and getting the PnP and power state machines and cancellation right is famously difficult.

KMDF, part of the Windows Driver Frameworks, runs in the kernel on top of WDM. It provides objects with reference counting and parent-child lifetimes, queues that handle request flow and cancellation, and default PnP and power handling, so a driver writes event callbacks such as EvtDevicePrepareHardware and EvtIoRead instead of state machines. Most new kernel-mode drivers use KMDF.

UMDF version 2 uses nearly the same programming model but runs the driver in a user-mode host process. A crash takes down the host, not the system, and debugging is simpler, at the cost of extra latency and no direct access to some kernel facilities. It suits USB peripherals, sensors and other devices without hard latency needs. The interview point is choosing the least privileged model that meets the device's needs, in the same way a Linux engineer might consider a user-space driver.

They have the same shape. The Windows interrupt service routine runs at device IRQL, checks whether its device interrupted, silences it, saves the minimum state and returns TRUE or FALSE, like IRQ_HANDLED or IRQ_NONE. It then queues a deferred procedure call, which runs later at DISPATCH_LEVEL with device interrupts enabled. That corresponds to a Linux tasklet or softirq: atomic, not allowed to sleep, used to complete requests.

Work that must wait or call routines that only work at PASSIVE_LEVEL goes to a work item, the counterpart of a Linux workqueue, or KMDF's passive-level interrupt handling, which is close in spirit to a Linux threaded interrupt.

In KMDF, the callbacks are EvtInterruptIsr and EvtInterruptDpc, and the ISR queues the DPC with WdfInterruptQueueDpcForIsr(). Data shared between the ISR and other code is protected by the interrupt lock (WdfInterruptAcquireLock()), the counterpart of spin_lock_irqsave(). If you can explain this mapping, you show that you understand the concepts rather than one API.

Zephyr builds the device list at compile time from device tree. The build turns the DTS into generated C macros, and a driver uses them instead of parsing anything at run time. A driver sets DT_DRV_COMPAT to its compatible string, defines a config structure (constant data such as base address and IRQ from DT_INST_REG_ADDR() and similar macros) and a data structure (run-time state), and instantiates one device per enabled node with DEVICE_DT_INST_DEFINE() inside DT_INST_FOREACH_STATUS_OKAY().

Each device has an init function run at a chosen level (PRE_KERNEL_1, PRE_KERNEL_2, POST_KERNEL, APPLICATION) with a priority, which orders dependencies. Device classes define an API structure of function pointers, such as the I2C or sensor API, and applications call the class API, which dispatches to the driver. Applications get a device with DEVICE_DT_GET() and must check device_is_ready().

Compared with Linux there is no probe, no hot plug and no dynamic binding: everything is resolved at build time, which saves RAM and flash but means the image is built for one board description.

Keep the ISR short and signal a task with an ISR-safe primitive. In FreeRTOS, only the FromISR API variants may be called from an interrupt, and they report whether a higher priority task was woken so you can request a context switch on exit:

void UART_IRQHandler(void)
{
	BaseType_t woken = pdFALSE;
	uint8_t b = UART->DR;            /* reading clears the flag */

	xQueueSendFromISR(rx_queue, &b, &woken);
	portYIELD_FROM_ISR(woken);
}

For a single "something happened" event, a direct-to-task notification is lighter than a queue or semaphore. In Zephyr, ISRs can call k_sem_give(), k_msgq_put() with K_NO_WAIT, or submit a k_work item to a work queue.

Also cover interrupt priorities on Cortex-M: in FreeRTOS, ISRs that call the kernel API must run at or below configMAX_SYSCALL_INTERRUPT_PRIORITY, otherwise they can corrupt kernel state. ISRs above that level are allowed for very low latency work but cannot use any RTOS calls.

The device knowledge stays the same: register map, power-up sequence, conversion formulas, quirks and errata. That is usually most of the value in the old driver, so I would first separate it into plain functions that take a "read register" and "write register" callback.

What changes:

• Binding and resources. Probe disappears. Configuration comes from devicetree macros at build time, and the SPI bus and chip select come from SPI_DT_SPEC_INST_GET().
• Bus access. spi_write_dt() and spi_transceive_dt() replace spi_sync() or regmap.
• Interrupts. The data-ready GPIO uses gpio_pin_interrupt_configure_dt() and a callback that gives a semaphore or submits work, instead of a threaded IRQ.
• Subsystem API. The Linux IIO interface becomes the Zephyr sensor API, sample_fetch and channel_get, with values in struct sensor_value.
• Memory and power. No dynamic allocation; state is in per-instance data structures. Power management uses Zephyr's device PM hooks.

Licensing also matters: Linux drivers are GPL and Zephyr is Apache 2.0, so copying code across needs the copyright holder's agreement.

Work on three things in parallel. First, C fluency without a standard library: pointers, bit manipulation, intrusive lists, ring buffers and concurrency with atomics, practised under time pressure. Second, kernel concepts explained out loud: execution contexts, locking choices, DMA ownership, the driver model and power management, which this page's sections cover. Third, real code: write a small driver for a device you can test, such as a QEMU emulated device, an I2C sensor on a development board, or a virtual char device, and read one mature driver in the kernel tree for the device class the job involves.

Before the interview, prepare two or three stories about bugs you found and fixed, with the tools you used and how you proved the fix. Those stories carry the behavioural part of most driver interviews.

Mostly C problems close to driver work rather than abstract puzzles: bit and register manipulation, endianness and parsing of binary formats, linked lists with container_of, ring buffers, bitmap allocators, memory allocators, and string or buffer handling with careful bounds. Senior loops often add a concurrency problem, such as a lock-free queue or a reader-writer scheme, and ask about memory ordering.

Some companies also ask you to write or sketch kernel code on a whiteboard: a char driver's read and write, an interrupt handler with deferred work, or a probe function with error handling. You will not be marked down for an imperfect API name if the structure, context rules and error handling are right. General algorithm questions appear too, usually at an easier level than in pure software roles.

No, but they help a great deal. Many driver engineers work on product kernels and never send patches upstream, and interviewers know that. What they look for is evidence that you have worked with real kernel code: debugging an oops, bringing up hardware, changing a driver and understanding the consequences.

Upstream patches are strong evidence because they have passed public review, and they give you concrete material for interviews. Even a few small, accepted fixes, such as error path corrections or conversions to newer APIs in a driver you can test, show that you can read kernel code, follow the process and take review. If you do not have them, a well-documented personal driver project with a clear README and tests serves a similar purpose.

A driver developer usually works inside an operating system kernel, mostly Linux, and the job is to make hardware work through that kernel's frameworks: the driver model, DMA API, interrupt subsystem, power management and the device class subsystems. Interviews therefore test kernel concepts and concurrency heavily.

A firmware developer works on bare metal or a small RTOS, often owning the whole software image of a microcontroller, and interviews focus on startup code, peripherals, memory limits and real-time behaviour. An embedded systems engineer role is broader and may include hardware, firmware, Linux user space and system integration. There is plenty of overlap, especially in C, hardware reading and debugging. See the Firmware Developer and Embedded Systems Engineer pages for those interviews.