Prerequisites

• A configured kernel build tree (kernel source, cross toolchain, defconfig for your board)
• Comfort with basic Git and shell tooling (grep, find)
• Familiarity with what a device driver does at a high level

Why the Search Order Matters

Every embedded project eventually needs a driver for a piece of silicon that isn’t obviously supported. The instinct for a lot of engineers is to open an editor and start writing. That’s usually the slowest path. The Linux kernel tree already carries drivers for an enormous range of chips, and even when there’s no exact match, there is frequently a close relative that only needs a compatible string added to a device tree node. Spending fifteen minutes searching saves days of debugging a driver you didn’t need to write, and it also means you inherit years of upstream bug fixes instead of maintaining your own bug list forever.

Treat driver discovery as a funnel: start broad and cheap, and only escalate to expensive options (backporting, writing from scratch) once the cheap ones are exhausted.

Step 1: Search the Kernel You Already Have

Before looking anywhere else, check whether your own kernel tree already ships a driver. Mainline Linux carries thousands of drivers, and vendor kernels usually add more on top. The fastest way in is the configuration menu:

$ make ARCH=arm64 menuconfig
# Then use the search feature ('/') and type the chip name,
# e.g. "bq25890" or "lan8720"

If the exact part number doesn’t turn anything up, search more generically. Manufacturers reuse silicon across product families, so a driver named for a sibling chip may already cover yours through a compatible list. When menuconfig search comes up empty, go straight to the source tree with grep, which is often faster once you know roughly what you’re looking for:

$ grep -ril "bq25890" drivers/power/supply/
drivers/power/supply/bq25890_charger.c

$ grep -ril "lan8720\|lan87" drivers/net/phy/
drivers/net/phy/micrel.c

Two details matter here that are easy to overlook. First, always check that you’re building against a current kernel release for your board’s architecture — later releases routinely add device support that older ones lack, so a driver search on a five-year-old kernel branch can give a false negative. Second, remember that a driver being present in the source tree doesn’t mean it’s enabled in your defconfig; check .config for the matching CONFIG_* symbol before concluding it’s missing.

Step 2: Check the Manufacturer, With Realistic Expectations

If the kernel tree has nothing, the chip vendor’s support page is the next stop. Set expectations correctly going in: a large share of hardware manufacturers are not Linux-focused companies, and what they publish can be misleading, incomplete, or built against a kernel version several releases away from yours. What you’ll typically find falls into a few buckets:

Even when a vendor package looks usable, prefer an open-source, upstream-tracked driver whenever one exists over a binary blob — you get ongoing maintenance, security fixes, and the ability to actually debug problems.

Step 3: Search the Wider Community

If neither your kernel nor the vendor has what you need, search online: mailing list archives, forum threads for your board family, and other distributions that may have already solved the same problem. It’s common to find a driver written for a different kernel version than the one you’re running. That’s still useful — it just means the next step is backporting rather than writing from nothing.

Step 4: Decide Whether Backporting Is Worth It

Backporting means taking a driver written against one kernel API and adapting it to build and run against yours. How much work that is depends almost entirely on how far apart the two kernel versions are:

A practical way to gauge the gap without guessing: diff the subsystem header the driver depends on (for example include/linux/gpio/driver.h) between the driver’s original kernel tag and your target tag.

$ git diff v5.10..v6.9 -- include/linux/gpio/driver.h | diffstat

A short diffstat suggests a light backport; a long one is a signal to budget real time, bring in extra help, or reconsider writing fresh against the current API instead of fighting an old one.

Step 5: When to Write It Yourself

Only after the funnel above is exhausted — no mainline support, no usable vendor package, no backportable community driver — does writing an original driver become the right call. At that point you’re not starting from zero either: the kernel tree has dozens of drivers for similar device classes that serve as structural references for how probe, remove, and the relevant subsystem callbacks should look on a current kernel.

Common Mistakes

• Searching an old, cached copy of the kernel tree instead of a current checkout
• Assuming a missing menuconfig entry means “no driver exists” without also grepping the source
• Trusting a vendor binary blob for long-term production use without an upstream migration plan
• Attempting a backport across a multi-year gap without first measuring the API diff

Best Practices

• Always confirm you’re testing against the latest stable kernel for your board before declaring a driver missing
• Prefer upstream, in-tree drivers over binary blobs even when the blob “just works” today
• Measure a backport’s difficulty with a header diff before committing time to it
• Keep any backported driver’s changes minimal and well-commented so future kernel bumps are easier

Summary

Driver discovery is a search problem before it’s a coding problem. Check your own kernel tree first, treat vendor packages with healthy skepticism, look to the wider community next, and only backport or write fresh once the cheaper options are genuinely exhausted. This search discipline is one of the more underrated skills covered in any serious free linux kernel development course, because it saves far more engineering time than it costs.

FAQ