[FE training-materials-updates] Kernel labs: fix devm_related lab instructions

[Michael Opdenacker]

Repository : git://git.free-electrons.com/training-materials.git

On branch  : master
Link       : http://git.free-electrons.com/training-materials/commit/?id=c347e9e0944f816038838179241b7a22d0d662a6

>---------------------------------------------------------------

commit c347e9e0944f816038838179241b7a22d0d662a6
Author: Michael Opdenacker <michael.opdenacker at free-electrons.com>
Date:   Tue Feb 4 15:18:24 2014 +0100

    Kernel labs: fix devm_related lab instructions
    
    Signed-off-by: Michael Opdenacker <michael.opdenacker at free-electrons.com>


>---------------------------------------------------------------

c347e9e0944f816038838179241b7a22d0d662a6
 .../kernel-i2c-input-interface.tex                 |   20 ++++++++++----------
 labs/kernel-serial-iomem/kernel-serial-iomem.tex   |   10 ++++------
 2 files changed, 14 insertions(+), 16 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 53a41ea..9253ea9 100644
--- a/labs/kernel-i2c-input-interface/kernel-i2c-input-interface.tex
+++ b/labs/kernel-i2c-input-interface/kernel-i2c-input-interface.tex
@@ -126,18 +126,18 @@ Then allocate one such instead for each new device:
 \end{verbatim}
 
 Note that we haven't seen kernel memory allocator routines and flags
-yet. 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
-the details later.
+yet.
 
-Note that with \code{devm_} functions it is not needed to free the
-allocated resources. They are automatically freed when the corresponding
-device in unprobed. 
+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.
 
-You will actually have to modify your code and the above lines to call 
-\code{kfree(nunchuk)} if one of the subsequent registration and
-allocation routines fail.
+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
+all the details later.
 
 Now implement the pointers: 
 
diff --git a/labs/kernel-serial-iomem/kernel-serial-iomem.tex b/labs/kernel-serial-iomem/kernel-serial-iomem.tex
index 871667c..76e8266 100644
--- a/labs/kernel-serial-iomem/kernel-serial-iomem.tex
+++ b/labs/kernel-serial-iomem/kernel-serial-iomem.tex
@@ -165,11 +165,9 @@ struct feserial_dev {
 \end{verbatim}
 
 The first thing to do is allocate such a structure at the beginning
-of the \code{probe()} routine. Let's do it with a \code{devm_} function.
-The advantage of such routines is that 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.
+of the \code{probe()} routine. Let's do it with the \code{devm_kzalloc}
+function again as in the previous lab. Again, resource deallocation is
+automatically taken care of when we use the \code{devm_} functions.
 
 So, add the below line to your code:
 
@@ -307,7 +305,7 @@ picocom -b 115200 /dev/ttyUSB1
 \end{verbatim}
 
 Load your module on the target. You should see the
-corresponding character in the new \code{picocom} installed,
+corresponding character in the new \code{picocom} instance,
 showing what was written to UART2.
 
 You can also check that you also get the same character on UART4