[FE training-materials-updates] Kernel slides: misc updates

Michael Opdenacker michael.opdenacker at free-electrons.com
Tue Mar 8 18:36:23 CET 2016

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


commit 9485c3bd00cbd690826c4e9fd6f5cbef22121ed1
Author: Michael Opdenacker <michael.opdenacker at free-electrons.com>
Date:   Tue Mar 8 18:36:23 2016 +0100

    Kernel slides: misc updates
    Signed-off-by: Michael Opdenacker <michael.opdenacker at free-electrons.com>


 slides/kernel-device-model/kernel-device-model.tex | 5 +++--
 slides/kernel-frameworks/kernel-frameworks.tex     | 2 +-
 slides/kernel-pinmuxing/kernel-pinmuxing.tex       | 2 +-
 slides/sysdev-device-files/sysdev-device-files.tex | 6 +++---
 4 files changed, 8 insertions(+), 7 deletions(-)

diff --git a/slides/kernel-device-model/kernel-device-model.tex b/slides/kernel-device-model/kernel-device-model.tex
index 583743b..d256400 100644
--- a/slides/kernel-device-model/kernel-device-model.tex
+++ b/slides/kernel-device-model/kernel-device-model.tex
@@ -366,10 +366,10 @@ static void __exit imx_serial_cleanup(void) {
     defined statically
     \item By direct instantiation of \kstruct{platform_device}
-      structures, as done on some ARM platforms. Definition done in
+      structures, as done on a few old ARM platforms. Definition done in
       the board-specific or SoC specific code.
     \item By using a \emph{device tree}, as done on Power PC (and on
-      some ARM platforms) from which \kstruct{platform_device}
+      most ARM platforms) from which \kstruct{platform_device}
       structures are created
   \item Example on ARM, where the instantiation is done in
@@ -734,6 +734,7 @@ static struct platform_driver serial_omap_driver = {
          \item \kerneldoc{devicetree/}
          \item \kerneldoc{filesystems/sysfs.txt}
+      \item \url{http://devicetree.org}
        \item The kernel source code
          \item Full of examples of other drivers!
diff --git a/slides/kernel-frameworks/kernel-frameworks.tex b/slides/kernel-frameworks/kernel-frameworks.tex
index c9247be..db6b4dc 100644
--- a/slides/kernel-frameworks/kernel-frameworks.tex
+++ b/slides/kernel-frameworks/kernel-frameworks.tex
@@ -47,7 +47,7 @@
   \item The {\em major number} typically indicates the family of the
   \item The {\em minor number} typically indicates the number of the
-    device (when they are for example several serial ports)
+    device (when there are for example several serial ports)
   \item Most major and minor numbers are statically allocated, and
     identical across all Linux systems.
   \item They are defined in \kerneldoc{devices.txt}.
diff --git a/slides/kernel-pinmuxing/kernel-pinmuxing.tex b/slides/kernel-pinmuxing/kernel-pinmuxing.tex
index 88cb268..d0a4a1a 100644
--- a/slides/kernel-pinmuxing/kernel-pinmuxing.tex
+++ b/slides/kernel-pinmuxing/kernel-pinmuxing.tex
@@ -28,9 +28,9 @@
   \item This subsystem, located in \kpath{drivers/pinctrl} provides a
     generic subsystem to handle pin muxing. It offers:
-    \item A pin muxing consumer interface, for device drivers.
     \item A pin muxing driver interface, to implement the system-on-chip
       specific drivers that configure the muxing.
+    \item A pin muxing consumer interface, for device drivers.
   \item Most {\em pinctrl} drivers provide a Device Tree binding, and
     the pin muxing must be described in the Device Tree.
diff --git a/slides/sysdev-device-files/sysdev-device-files.tex b/slides/sysdev-device-files/sysdev-device-files.tex
index 8446a97..9695b61 100644
--- a/slides/sysdev-device-files/sysdev-device-files.tex
+++ b/slides/sysdev-device-files/sysdev-device-files.tex
@@ -1,9 +1,9 @@
   \frametitle{Devices: everything is a file}
-  \item A very important Unix design decision was to represent most of
-    the ``system objects'' as files
-  \item It allows applications to manipulate all “system objects” with
+  \item A very important Unix design decision was to represent most
+    {\em system objects} as files
+  \item It allows applications to manipulate all {\em system objects} with
     the normal file API (\code{open}, \code{read}, \code{write},
     \code{close}, etc.)
   \item So, devices had to be represented as files to the applications

More information about the training-materials-updates mailing list