I've noted that some device drivers in Linux have a dependency on the device firmware. The firmware is usually a binary that the driver loads on the device (like a USB wifi dongle).

This question is based on the assumption that this kind of behavior from the Linux side is dictated by the device (a USB wifi dongle) that is dependent on that firmware being loaded.

My question is what would be the benefits of this approach from the point of the dongle manufacturer?

What benefits does designing a device that doesn't have even a minimal non volatile storage to keep the firmware on and needs an external cpu loading it on every boot?

Does it come down to costs reduction not having a minimal non volatile storage for the firmware gives? Or have I overlooked an important benefit?

  • \$\begingroup\$ One important benefit is that they don't have to have drivers on the device for every OS it runs on, Linux, Windows, Mac, not to mention other niche OS's. They can also work from a more generic driver model so that you don't have to install hundreds of drivers (think USB disk drives) for basically the same thing. \$\endgroup\$
    – Ron Beyer
    Nov 27, 2017 at 16:40
  • 1
    \$\begingroup\$ @RonBeyer I never heard of a bare metal firmware adopting itself to the operating system. You have any references on this? \$\endgroup\$ Nov 27, 2017 at 16:53
  • \$\begingroup\$ Keyboards are pretty common and run on generic drivers if that is what you mean. Same with USB disk drives. They don't "adopt themselves" to the OS, the OS uses a generic interface to talk to them, and the device understands/responds to that generic interface. \$\endgroup\$
    – Ron Beyer
    Nov 27, 2017 at 17:02
  • 1
    \$\begingroup\$ @RonBeyer I'll just point out my terminology so we can sync on it and I can follow you more clearly. driver software running on the main CPU, part of the OS, used to talk to a peripheral IC. firmware the software running on the peripheral IC. Given those terms, could you please clarify what you mean with a generic driver? \$\endgroup\$ Nov 27, 2017 at 17:16

2 Answers 2


just look at /lib/firmware for folks wondering what this is about.

These are my opinions and in reality there is no real answer it is all opinions, you would have to poll the teams at each of these vendors and you may find a different answer for each one. There is no rule here.

Yes you save on flash, flash costs money and if you can save on that better for you, sure you trade that for ram, but I think that is a fair trade cost wise.

Second you dont have to do field upgrades, you dont have to have the user download a firmware update and possibly brick the product. Ideally your firmware should be good enough at product release to never need a field upgrade, but we are in a post microsoft, reboot/reset and see if that fixes it world. So the firmware can both be specific to the operating system as it is tied to the driver for that operating system and second if/when the software updates on the operating system happen the firmware for the embedded devices can get a free ride.

In some cases it is just the product these products use a popular usb microcontroller for example that has for whatever reason become commonly used in a product line, or a product vendor does the devil you know vs the devil you dont and sticks with this solution.

With the IoT devices I doubt they have bulletproof firmware on product release and new hacks will come along to attack the IoT firmware for a product line so having a quick and easy way to update without bricking is desirable, granted having a file on a computer hard drive is another thing to attack to gain access to a network. So there are pros and cons from a security perspective.

as far as generic driver you have to look at the os and the product and how it enumerates, etc. If my keyboard and wifi dongle used the same part how would a generic driver know them apart? If a product family or enough devices somehow adopt a common enumeration/firmware load/reenumeration you could but dont have to write one driver to cover the firmware load. really is an implementation thing, thus operating system and version specific.

One of many drawbacks here is that you may have to write a loader for each operating system you support where if the firmware was in flash on the product you might not have to, depends on the product and the protocol to the host, etc. Likewise the firmware download protocol, etc. Even if a generic driver was used to do the firmware download you have to put extra work in providing an operating specific software package and installer to put the firmware in the location where that operating system and driver expect with whatever control files or registry entries that go along with it, where if the product had firmware in flash that is less you have to do for the product to work. It also just works the first time they plug it in rather than do a two step (there is a reason why some products you buy strongly say do not plug in until you install the driver, this is one reason, they want the firmware ready before the peripheral wants it once plugged in the first time).

there is no right answer it is personal design decisions, you trade work on one side for work on another. You can potentially save pennies to dollars on the product cost itself trading those for "bits" the user pays to store on their hard drive. So long as you dont trade that for tech support bills because you didnt get the overall system design right.


I think a primary benefit is that it removes the need to have to support and validate a (possibly large) range of driver/firmware version combinations. It's easy to imagine a situation where a driver needs to be sure the device is running a firmware version >= x, so then your options are to either prompt the user to upgrade the device's firmware, or have this capability built into the driver, and ship an appropriate firmware version with the driver. And if the driver needs to check and possibly load firmware every time anyway, why bother storing it on the device in the first place?


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.