[FE training-materials-updates] kernel i2c lab: use devm_input_allocate_polled_device()
Michael Opdenacker
michael.opdenacker at free-electrons.com
Tue Nov 29 14:30:59 CET 2016
Repository : git://git.free-electrons.com/training-materials.git
On branch : master
Link : http://git.free-electrons.com/training-materials/commit/?id=4d320127477afcd864bd2540f0073ca10a6f1a58
>---------------------------------------------------------------
commit 4d320127477afcd864bd2540f0073ca10a6f1a58
Author: Michael Opdenacker <michael.opdenacker at free-electrons.com>
Date: Tue Nov 29 14:30:59 2016 +0100
kernel i2c lab: use devm_input_allocate_polled_device()
Signed-off-by: Michael Opdenacker <michael.opdenacker at free-electrons.com>
>---------------------------------------------------------------
4d320127477afcd864bd2540f0073ca10a6f1a58
.../kernel-i2c-input-interface.tex | 43 +++++++++-------------
1 file changed, 17 insertions(+), 26 deletions(-)
diff --git a/labs/kernel-i2c-input-interface/kernel-i2c-input-interface.tex b/labs/kernel-i2c-input-interface/kernel-i2c-input-interface.tex
index 932e5e9..237f436 100644
--- a/labs/kernel-i2c-input-interface/kernel-i2c-input-interface.tex
+++ b/labs/kernel-i2c-input-interface/kernel-i2c-input-interface.tex
@@ -38,7 +38,7 @@ the steps to do it:
You can't use a global variable because your driver needs to be
able to support multiple devices.
\item Allocate such a structure in the same function, using the
- \code{input_allocate_polled_device()} function.
+ \code{devm_input_allocate_polled_device()} function.
\item Also declare a pointer to an \code{input_dev} structure. You can
call it \code{input}. We won't need to allocate it, because it
is already part of the \code{input_polled_dev} structure,
@@ -59,30 +59,27 @@ situations properly.
\begin{itemize}
\item Of course, test return values properly and log
the causes of errors.
-\item If the call to \code{input_register_polled_device()} fails,
- you must also free the \code{input_polled_dev} structure
- before returning an error. If you don't do that, you will create
- memory leaks in the kernel. In the general case, failure to
- release things that have been allocated or registered before
- can prevent you from reloading a module.
+\item In our case, we only allocated resources with \code{devm_}
+ functions. Thanks to this, in case of failure, all the
+ corresponding allocations are automatically released
+ before destroying the \code{device} structure for each
+ device. This greatly simplifies our error management code!
\end{itemize}
-To implement this correctly without duplicating or creating ugly code,
-it's recommended to use \code{goto} statements.
-
-See {\em Chapter 7: Centralized exiting of functions} in
-\code{Documentation/CodingStyle} for useful guidelines and an example.
-Implement this in your driver.
-
\section{Implement the remove() function}
-We now need to release the resources allocated and registered in the
-\code{probe()} routine.
+We now need to unregister and release the resources allocated
+and registered in the \code{probe()} routine.
-However, this is not trivial in the way we implemented the
-\code{probe()} routine. As we have to support multiple devices, we chose
-not to use global variables, and as a consequence, we can't use such
-global variables to release the corresponding resources.
+Releasing will be done automatically when the device structures
+are destroyed when the module is removed, thanks to the use
+of the \code{devm_} allocation functions,
+
+However, unregistration will not be trivial in the way we
+implemented the \code{probe()} routine. As we have to support
+multiple devices, we chose not to use global variables, and as a
+consequence, we can't use such global variables to access the
+corresponding resources.
This raises a very important aspect of the device model: the need to
keep pointers between {\em physical} devices (devices as handled by the
@@ -123,12 +120,6 @@ Then allocate one such instead for each new device:
Note that we haven't seen kernel memory allocator routines and flags
yet.
-All we can say for the moment is that with \code{devm_} functions,
-each allocation or registration
-is attached to a device structure. When a device or a module is removed,
-all such allocations or registrations are automatically undone. This
-allows to greatly simplify driver code.
-
We haven't explained the \code{dev_*} logging routines yet either
(they are basically used to tell which device a given log message is
associated to). For the moment, just use the above code. You will get
More information about the training-materials-updates
mailing list