Improve devm * and get rid of boilerplate code

Revision as of 16:41, 1 October 2013 by Tim Bird (Talk | contribs)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search



Clean up, consolidate and improve the managed devices of the Linux kernel (devm_* functions) and make their usage more consistent. That also enables to remove boilerplate code and strings in drivers.



Wolfram Sang <>



Managed devices have a great potential to make writing device drivers easier and less error prone. The basic mechanisms are there, yet using these mechanisms has gone a bit wild and there is no maintainer to keep an eye on it. This project aims to improve the situation by:

  • Fix the callers

Fix the kernel tree to clearly represent the best-practices in using devm functions. This will usually remove code from the kernel.

  • Cleaning up

Remove superfluous or too shim devm-functions to have a well-known basic set of functions. This will remove code from the kernel.

  • Consolidate

On top of these functions, add convenience functions which combine typical procedures into seperate functions. An already existing example is devm_ioremap_resource() which does devm_request_mem_region() and devm_ioremap{_nocache} with proper error checking and giving proper error messages. This will remove code and *lots* of inconsistent error strings from the kernel. Also, most devm functions themselves use a similar pattern. Refactoring might be worth in that area, too.

  • Remove subtle issues

There are some devm functions missing. So for some subsystems, resource allocation is additionally done by hand. This can cause subtle bugs, especially in exit paths, since manually allocated resources might be not available anymore when devm allocated resource would still need them. Adding those functions will get things right. Also, the already existing action mechanism might be used to do things on removal which are otherwise often forgotten.

The huge bonus of such a cleaned up devm interface is that devices drivers will be smaller in size, easier to write, and less error-prone since typical patterns are outsourced to a trusted mechanism. And maintainers will spend less time reviewing because resource allocation is a neverending source of mistakes.

Related work


First steps have already been done:

Remove unneded checks with devm_ioremap_resource:

And bugs are found on the way, too:

Fixing wrong devres allocation in the PWM subsystem:

Fixing up wrong devm-conversions:

Cleaning up copy&paste mistake in the GPIO subsystem:



I think the main ideas can be discussed and implemented in 120 hours effort. If the duration is 1 or 2 months depends on how discussions with upstream go.

Contractor candidates


Given that I already started digging into the topic, have some designs sketched and already submitted initial patches, I recommend myself. I also think I have enough upstream experience to deal with such a major task.