[FE training-materials-updates] Kernel labs: fix devm_related lab instructions
Michael Opdenacker
michael.opdenacker at free-electrons.com
Tue Feb 4 15:22:22 CET 2014
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
More information about the training-materials-updates
mailing list