[FE training-materials-updates] kernel i2c lab: use devm_input_allocate_polled_device()

[Michael Opdenacker]

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