[BL training-materials-updates] Some company renaming work

Michael Opdenacker michael.opdenacker at bootlin.com
Thu May 31 15:21:50 CEST 2018

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


commit 6779a0804252e97432c4072a3b84208ae726599d
Author: Michael Opdenacker <michael.opdenacker at free-electrons.com>
Date:   Thu May 31 15:21:50 2018 +0200

    Some company renaming work
    Signed-off-by: Michael Opdenacker <michael.opdenacker at free-electrons.com>


 .../modules/nfsroot/root/serial/Makefile           |  2 +-
 .../modules/nfsroot/root/serial/feserial.c         | 18 ++++++++--------
 labs/kernel-locking/kernel-locking.tex             |  2 +-
 .../kernel-serial-interrupt.tex                    | 12 +++++------
 labs/kernel-serial-iomem/kernel-serial-iomem.tex   | 14 ++++++-------
 labs/kernel-serial-iomem/uarts.dts                 |  4 ++--
 labs/kernel-serial-output/kernel-serial-output.tex | 24 +++++++++++-----------
 slides/about-us/about-us.tex                       |  2 +-
 .../android-adb-examples/android-adb-examples.tex  |  2 +-
 .../kernel-driver-development-debugging.tex        |  4 ++--
 10 files changed, 42 insertions(+), 42 deletions(-)

diff --git a/lab-data/linux-kernel/modules/nfsroot/root/serial/Makefile b/lab-data/linux-kernel/modules/nfsroot/root/serial/Makefile
index 948956c..8e92e0f 100644
--- a/lab-data/linux-kernel/modules/nfsroot/root/serial/Makefile
+++ b/lab-data/linux-kernel/modules/nfsroot/root/serial/Makefile
@@ -1,5 +1,5 @@
 ifneq ($(KERNELRELEASE),)
-obj-m := feserial.o
+obj-m := serial.o
 KDIR := $(HOME)/linux-kernel-labs/src/linux
diff --git a/lab-data/linux-kernel/modules/nfsroot/root/serial/feserial.c b/lab-data/linux-kernel/modules/nfsroot/root/serial/feserial.c
index 9b55d30..763a7a0 100644
--- a/lab-data/linux-kernel/modules/nfsroot/root/serial/feserial.c
+++ b/lab-data/linux-kernel/modules/nfsroot/root/serial/feserial.c
@@ -4,26 +4,26 @@
 /* Add your code here */
-static int feserial_probe(struct platform_device *pdev)
+static int serial_probe(struct platform_device *pdev)
-	pr_info("Called feserial_probe\n");
+	pr_info("Called serial_probe\n");
 	return 0;
-static int feserial_remove(struct platform_device *pdev)
+static int serial_remove(struct platform_device *pdev)
-	pr_info("Called feserial_remove\n");
+	pr_info("Called serial_remove\n");
         return 0;
-static struct platform_driver feserial_driver = {
+static struct platform_driver serial_driver = {
         .driver = {
-                .name = "feserial",
+                .name = "serial",
                 .owner = THIS_MODULE,
-        .probe = feserial_probe,
-        .remove = feserial_remove,
+        .probe = serial_probe,
+        .remove = serial_remove,
diff --git a/labs/kernel-locking/kernel-locking.tex b/labs/kernel-locking/kernel-locking.tex
index e8f03ea..d5e817f 100644
--- a/labs/kernel-locking/kernel-locking.tex
+++ b/labs/kernel-locking/kernel-locking.tex
@@ -9,7 +9,7 @@ During this lab, you will:
-Continue to work with the \code{feserial} driver.
+Continue to work with the \code{serial} driver.
 You need to have completed the previous two labs to perform this one.
diff --git a/labs/kernel-serial-interrupt/kernel-serial-interrupt.tex b/labs/kernel-serial-interrupt/kernel-serial-interrupt.tex
index 369f29d..d9cbfd6 100644
--- a/labs/kernel-serial-interrupt/kernel-serial-interrupt.tex
+++ b/labs/kernel-serial-interrupt/kernel-serial-interrupt.tex
@@ -31,10 +31,10 @@ hardware interrupt number. This virtual number is created through the
 \code{irqdomain} mechanism. The hardware IRQ number to use is found in
 the device tree.
-First, add an \code{irq} field to your \code{feserial_dev} structure:
+First, add an \code{irq} field to your \code{serial_dev} structure:
-struct feserial_dev {
+struct serial_dev {
         struct miscdevice miscdev;
         void __iomem *regs;
         int irq;
@@ -95,7 +95,7 @@ receive the characters from the serial port.
 First, we need a communication mechanism between the interrupt handler
 and the \code{read()} operation. We will implement a very simple
 circular buffer. So let's add a device-specific buffer to our
-\code{feserial_dev} structure.
+\code{serial_dev} structure.
 Let's also add two integers that will contain the next location
 in the circular buffer that we can write to, and the next location
@@ -104,7 +104,7 @@ we can read from:
 #define SERIAL_BUFSIZE 16
-struct feserial_dev {
+struct serial_dev {
         void __iomem *regs;
         struct miscdevice miscdev;
         int irq;
@@ -131,7 +131,7 @@ Now, what happens in our \code{read()} function if no character is
 available for reading (i.e, if \code{serial_buf_wr} is equal to
 \code{serial_buf_rd})? We should put the process to sleep!
-To do so, add a wait queue to our \code{feserial_dev} structure,
+To do so, add a wait queue to our \code{serial_dev} structure,
 named for example \code{serial_wait}. In the \code{read()} function,
 keep things simple by directly using \code{wait_event_interruptible()}
 right from the start, to wait until \code{serial_buf_wr}
@@ -144,7 +144,7 @@ Last but not least, in the interrupt handler,
 after storing the received characters in the circular buffer, use
 \code{wake_up()} to wake up all processes waiting on the wait queue.
-Compile and load your driver. Run \code{cat /dev/feserial-48024000}
+Compile and load your driver. Run \code{cat /dev/serial-48024000}
 on the target, and then in \code{picocom} on the development
 workstation side, type some characters. They should appear on the
 remote side if everything works correctly!
diff --git a/labs/kernel-serial-iomem/kernel-serial-iomem.tex b/labs/kernel-serial-iomem/kernel-serial-iomem.tex
index 12cdeb0..ba0fdf1 100644
--- a/labs/kernel-serial-iomem/kernel-serial-iomem.tex
+++ b/labs/kernel-serial-iomem/kernel-serial-iomem.tex
@@ -78,7 +78,7 @@ Compile and update your DTB.
 \section{Operate a platform device driver}
 Go to the \code{~/linux-kernel-labs/modules/nfsroot/root/serial/} directory.
-You will find a \code{feserial.c} file which already provides a platform
+You will find a \code{serial.c} file which already provides a platform
 driver skeleton.
 Add the code needed to match the driver with the devices which you have
@@ -127,7 +127,7 @@ each device (obtained through \code{ioremap()}), let's declare this
 structure as follows:
-struct feserial_dev {
+struct serial_dev {
         void __iomem *regs;
@@ -140,9 +140,9 @@ automatically taken care of when we use the \code{devm_} functions.
 So, add the below line to your code:
-struct feserial_dev *dev;
+struct serial_dev *dev;
-dev = devm_kzalloc(&pdev->dev, sizeof(struct feserial_dev), GFP_KERNEL);
+dev = devm_kzalloc(&pdev->dev, sizeof(struct serial_dev), GFP_KERNEL);
 You can now get a virtual address for your device's base physical
@@ -172,7 +172,7 @@ devices. Of course, this will be done in the \code{probe()} routine.
 As we will have multiple registers to read, create a \code{reg_read()}
 routine, returning an \code{unsigned int} value, and  taking a \code{dev}
-pointer to an \code{feserial_dev} structure and an \code{offset} integer
+pointer to an \code{serial_dev} structure and an \code{offset} integer
 In this function, read from a 32 bits register at the base virtual
@@ -189,7 +189,7 @@ the device base virtual address. The following code samples are using
 the \code{writel()} convention of passing the value first, then the
 offset. Your prototype should look like:
-static void reg_write(struct feserial_dev *dev, int val, int off);
+static void reg_write(struct serial_dev *dev, int val, int off);
 In the next sections, we will tell you what register offsets to use
@@ -234,7 +234,7 @@ better what we are doing here.
 \section{Standalone write routine}
-Implement a C routine taking a pointer to an \code{feserial_dev}
+Implement a C routine taking a pointer to an \code{serial_dev}
 structure and one character as parameters, and writing
 this character to the serial port, using the following steps:
diff --git a/labs/kernel-serial-iomem/uarts.dts b/labs/kernel-serial-iomem/uarts.dts
index f3012c7..8e90a23 100644
--- a/labs/kernel-serial-iomem/uarts.dts
+++ b/labs/kernel-serial-iomem/uarts.dts
@@ -1,12 +1,12 @@
 &uart2 {
-	compatible = "free-electrons,serial";
+	compatible = "bootlin,serial";
         status = "okay";
         pinctrl-names = "default";
         pinctrl-0 = <&uart2_pins>;
 &uart4 {
-	compatible = "free-electrons,serial";
+	compatible = "bootlin,serial";
         status = "okay";
         pinctrl-names = "default";
         pinctrl-0 = <&uart4_pins>;
diff --git a/labs/kernel-serial-output/kernel-serial-output.tex b/labs/kernel-serial-output/kernel-serial-output.tex
index 03ca661..fdd6b5e 100644
--- a/labs/kernel-serial-output/kernel-serial-output.tex
+++ b/labs/kernel-serial-output/kernel-serial-output.tex
@@ -29,12 +29,12 @@ driver.
 The first thing to do is to create:
-\item An \code{feserial_write()} write file operation stub.
+\item An \code{serial_write()} write file operation stub.
       See the slides or the code for the prototype to use.
       Just place a \code{return -EINVAL;} statement in the function
       body so far, to signal that there is something wrong with this
       function so far.
-\item Similarly, an \code{feserial_read()} read file operation stub.
+\item Similarly, an \code{serial_read()} read file operation stub.
 \item A \code{file_operations} structure declaring these file
@@ -45,7 +45,7 @@ devices. Like in the Nunchuk driver, we have to add such a structure
 to our device specific private data structure:
-struct feserial_dev {
+struct serial_dev {
         struct miscdevice miscdev;
         void __iomem *regs;
@@ -64,7 +64,7 @@ for each found device:
 \item To get an automatically assigned minor number.
 \item To specify a name for the device file in {\em devtmpfs}. We
   propose to use {\tt devm\_kasprintf(\&pdev->dev, GFP\_KERNEL,
-  "feserial-\%x", res->start)}. \code{devm_kasprintf()} allocates a
+  "serial-\%x", res->start)}. \code{devm_kasprintf()} allocates a
   buffer and runs \code{ksprintf()} to fill its contents.
 \item To pass the file operations structure that you defined.
@@ -74,7 +74,7 @@ See the lectures for details if needed!
 The last things to do (at least to have a {\em misc} driver, even if
 its file operations are not ready yet), are to add the registration and
 deregistration routines. That's typically the time when you will need
-to access the \code{feserial_dev} structure for each device from the
+to access the \code{serial_dev} structure for each device from the
 \code{pdev} structure passed to the \code{remove()} routine.
 Make sure that your driver compiles and loads well, and that you
@@ -89,20 +89,20 @@ there are any.
 Now, add code to your write function, to copy user data to the serial
 port, writing characters one by one.
-The first thing to do is to retrieve the \code{feserial_dev} structure
+The first thing to do is to retrieve the \code{serial_dev} structure
 from the \code{miscdevice} structure itself, accessible through the
 \code{private_data} field of the open file structure (\code{file}).
 At the time we registered our {\em misc} device, we didn't keep any
-pointer to the \code{feserial_dev} structure. However, as the
+pointer to the \code{serial_dev} structure. However, as the
 \code{miscdevice} structure is accessible through
 \code{file->private_data}, and is a member of the
-\code{feserial_dev} structure, we can use a magic macro to compute
+\code{serial_dev} structure, we can use a magic macro to compute
 the address of the parent structure:
-struct feserial_dev *dev =
-	container_of(file->private_data, struct feserial_dev, miscdev);
+struct serial_dev *dev =
+	container_of(file->private_data, struct serial_dev, miscdev);
 See \url{http://radek.io/2012/11/10/magical-container_of-macro/}
@@ -110,7 +110,7 @@ for interesting implementation details about this macro.
 This wouldn't have been possible if the \code{miscdevice} structure
 was allocated separately and was just referred to by a pointer in
-\code{feserial_dev}, instead of being a member of it.
+\code{serial_dev}, instead of being a member of it.
 Now, add code that copies (in a secure way) each character from the
 user space buffer to the UART device.
@@ -119,7 +119,7 @@ Once done, compile and load your module. Test that your \code{write} function
 works properly by using (example for UART2):
-echo "test" > /dev/feserial-48024000
+echo "test" > /dev/serial-48024000
 The \code{test} string should appear on the remote side (i.e in
diff --git a/slides/about-us/about-us.tex b/slides/about-us/about-us.tex
index 0717afe..3bdf508 100644
--- a/slides/about-us/about-us.tex
+++ b/slides/about-us/about-us.tex
@@ -26,7 +26,7 @@
     \item Technical blog:\\
     \item Quarterly newsletter:\\
- 	  \url{http://lists.free-electrons.com/mailman/listinfo/newsletter}
+ 	  \url{http://lists.bootlin.com/mailman/listinfo/newsletter}
     \item News and discussions (Google +):\\
     \item News and discussions (LinkedIn):\\
diff --git a/slides/android-adb-examples/android-adb-examples.tex b/slides/android-adb-examples/android-adb-examples.tex
index 0563f28..be19353 100644
--- a/slides/android-adb-examples/android-adb-examples.tex
+++ b/slides/android-adb-examples/android-adb-examples.tex
@@ -25,7 +25,7 @@
   \item Test an application by sending random user input
-    \item \code{adb shell monkey -v -p com.free-electrons.foobar 500}
+    \item \code{adb shell monkey -v -p com.bootlin.foobar 500}
   \item Filter system logs
diff --git a/slides/kernel-driver-development-debugging/kernel-driver-development-debugging.tex b/slides/kernel-driver-development-debugging/kernel-driver-development-debugging.tex
index fa9877d..3e9701f 100644
--- a/slides/kernel-driver-development-debugging/kernel-driver-development-debugging.tex
+++ b/slides/kernel-driver-development-debugging/kernel-driver-development-debugging.tex
@@ -44,8 +44,8 @@ pr_info("Booting CPU %d\n", cpu);
 dev_info(&pdev->dev, "in probe\n");
-[   25.878382] feserial 48024000.serial: in probe
-[   25.884873] feserial 481a8000.serial: in probe
+[   25.878382] serial 48024000.serial: in probe
+[   25.884873] serial 481a8000.serial: in probe

More information about the training-materials-updates mailing list