diff --git a/README.rst b/README.rst
index 92c897944f2..546bd9d5cc3 100644
--- a/README.rst
+++ b/README.rst
@@ -1,7 +1,7 @@
-Zephyr™ Project
-###############
+Zephyr Project
+##############
 
-The Zephyr™ Project is a scalable real-time operating system (RTOS) supporting
+The Zephyr Project is a scalable real-time operating system (RTOS) supporting
 multiple hardware architectures, optimized for resource constrained devices,
 and built with security in mind.
 
@@ -29,11 +29,11 @@ Welcome to the Zephyr community!
 Resources
 *********
 
-Here’s a quick summary of resources to find your way around the Zephyr Project
+Here's a quick summary of resources to find your way around the Zephyr Project
 support systems:
 
 * **Zephyr Project Website**: The https://zephyrproject.org website is the
-  central source of information about the Zephyr Project. On this site, you’ll
+  central source of information about the Zephyr Project. On this site, you'll
   find background and current information about the project as well as all the
   relevant links to project material.  For a quick start, refer to the
   `Zephyr Introduction`_ and `Getting Started Guide`_.
diff --git a/boards/arc/arduino_101_sss/doc/board.rst b/boards/arc/arduino_101_sss/doc/board.rst
index 496ef981e08..e168de42562 100644
--- a/boards/arc/arduino_101_sss/doc/board.rst
+++ b/boards/arc/arduino_101_sss/doc/board.rst
@@ -6,7 +6,7 @@ Arduino/Genuino 101 (Sensor Subsystem)
 The Arduino 101 contains a 32 MHz Argonaut RISC Core (ARC)* EM processor as part
 of the Quark SE C1000 SoC within the Curie module.
 The ARC core is referenced as the digital signal processor (DSP) sensor hub or a
-sensor subsystem depending on what document you’re looking at.
+sensor subsystem depending on what document you're looking at.
 
 For more information about using the sensor subsystem with Zephyr, see
 :ref:`arduino_101`.
diff --git a/boards/arm/96b_carbon/doc/96b_carbon.rst b/boards/arm/96b_carbon/doc/96b_carbon.rst
index aeee615d344..17414453cf1 100644
--- a/boards/arm/96b_carbon/doc/96b_carbon.rst
+++ b/boards/arm/96b_carbon/doc/96b_carbon.rst
@@ -23,7 +23,7 @@ Hardware
 96Boards Carbon provides the following hardware components:
 
 - STM32F401RET6 in LQFP64 package
-- ARM®32-bit Cortex®-M4 CPU with FPU
+- ARM |reg| 32-bit Cortex |reg|-M4 CPU with FPU
 - 84 MHz max CPU frequency
 - VDD from 1.7 V to 3.6 V
 - 512 KB Flash
diff --git a/boards/arm/96b_nitrogen/doc/96b_nitrogen.rst b/boards/arm/96b_nitrogen/doc/96b_nitrogen.rst
index 4a6172bcefd..85f5d4dff0a 100644
--- a/boards/arm/96b_nitrogen/doc/96b_nitrogen.rst
+++ b/boards/arm/96b_nitrogen/doc/96b_nitrogen.rst
@@ -27,7 +27,7 @@ Hardware
 96Boards Nitrogen provides the following hardware components:
 
 - nRF52832 microcontroller with 512kB Flash, 64kB RAM
-- ARM®32-bit Cortex®-M4 CPU with FPU
+- ARM |reg| 32-bit Cortex |reg|-M4 CPU with FPU
 - Bluetooth LE
 - NFC
 - LPC11U35 on board SWD debugger
diff --git a/boards/arm/cc3200_launchxl/doc/cc3200_launchxl.rst b/boards/arm/cc3200_launchxl/doc/cc3200_launchxl.rst
index c57ee8f8778..864cad725d1 100644
--- a/boards/arm/cc3200_launchxl/doc/cc3200_launchxl.rst
+++ b/boards/arm/cc3200_launchxl/doc/cc3200_launchxl.rst
@@ -6,7 +6,7 @@ CC3200 LaunchXL
 Overview
 ********
 The SimpleLink CC3200 LaunchXL is a development board for the CC3200
-wireless microcontroller (MCU), the industry’s first single-chip
+wireless microcontroller (MCU), the industry's first single-chip
 programmable MCU with built-in Wi-Fi connectivity.
 
 Features:
@@ -29,7 +29,7 @@ Hardware
 
 The CC3200 SoC has two MCUs:
 
-#. Applications MCU - an ARM® Cortex®-M4 Core at 80 MHz, with 256Kb RAM,
+#. Applications MCU - an ARM |reg| Cortex |reg|-M4 Core at 80 MHz, with 256Kb RAM,
    and access to external serial 1Mb flash with bootloader and peripheral
    drivers in ROM.
 
diff --git a/boards/arm/cc3220sf_launchxl/doc/cc3220sf_launchxl.rst b/boards/arm/cc3220sf_launchxl/doc/cc3220sf_launchxl.rst
index a62c4d549f7..d5827163e86 100644
--- a/boards/arm/cc3220sf_launchxl/doc/cc3220sf_launchxl.rst
+++ b/boards/arm/cc3220sf_launchxl/doc/cc3220sf_launchxl.rst
@@ -34,7 +34,7 @@ Hardware
 
 The CC3220SF SoC has two MCUs:
 
-#. Applications MCU - an ARM® Cortex®-M4 Core at 80 MHz, with 256Kb RAM,
+#. Applications MCU - an ARM |reg| Cortex |reg|-M4 Core at 80 MHz, with 256Kb RAM,
    and access to external serial 1Mb flash with bootloader and peripheral
    drivers in ROM.
 
diff --git a/boards/arm/curie_ble/doc/board.rst b/boards/arm/curie_ble/doc/board.rst
index 9d2a48e6bad..96dcf1fe2e1 100644
--- a/boards/arm/curie_ble/doc/board.rst
+++ b/boards/arm/curie_ble/doc/board.rst
@@ -3,7 +3,7 @@
 Curie (BLE)
 ###########
 
-The Intel® Curie* module includes Bluetooth LE to enable developers to interact with
+The Intel |reg| Curie* module includes Bluetooth LE to enable developers to interact with
 Bluetooth enabled devices such as phones and tablets.
 
 See :ref:`arduino_101` for information how to use the BLE module with Zephyr on the Arduino
diff --git a/boards/arm/disco_l475_iot1/doc/disco_l475_iot1.rst b/boards/arm/disco_l475_iot1/doc/disco_l475_iot1.rst
index 44e982a1bf9..cf1bd3e31cf 100644
--- a/boards/arm/disco_l475_iot1/doc/disco_l475_iot1.rst
+++ b/boards/arm/disco_l475_iot1/doc/disco_l475_iot1.rst
@@ -9,15 +9,15 @@ Overview
 The B-L475E-IOT01A Discovery kit for IoT node allows users to develop
 applications with direct connection to cloud servers.
 The Discovery kit enables a wide diversity of applications by exploiting
-low-power communication, multiway sensing and ARM® Cortex® -M4 core-based
+low-power communication, multiway sensing and ARM |reg| Cortex |reg|-M4 core-based
 STM32L4 Series features.
 
 This kit provides:
 
 - 64-Mbit Quad-SPI (Macronix) Flash memory
-- Bluetooth® V4.1 module (SPBTLE-RF)
+- Bluetooth |reg| V4.1 module (SPBTLE-RF)
 - Sub-GHz (868 or 915 MHz) low-power-programmable RF module (SPSGRF-868 or SPSGRF-915)
-- Wi-Fi® module Inventek ISM43362-M3G-L44 (802.11 b/g/n compliant)
+- Wi-Fi |reg| module Inventek ISM43362-M3G-L44 (802.11 b/g/n compliant)
 - Dynamic NFC tag based on M24SR with its printed NFC antenna
 - 2 digital omni-directional microphones (MP34DT01)
 - Capacitive digital sensor for relative humidity and temperature (HTS221)
@@ -28,7 +28,7 @@ This kit provides:
 - 2 push-buttons (user and reset)
 - USB OTG FS with Micro-AB connector
 - Expansion connectors:
-        - Arduino™ Uno V3
+        - Arduino |trade| Uno V3
         - PMOD
 - Flexible power-supply options:
         - ST LINK USB VBUS or external sources
@@ -49,14 +49,15 @@ Hardware
 
 The STM32L475RG SoC provides the following hardware IPs:
 
-- Ultra-low-power with FlexPowerControl (down to 130 nA Standby mode and 100 μA/MHz run mode)
-- Core: ARM® 32-bit Cortex®-M4 CPU with FPU, frequency up to 80 MHz, 100DMIPS/1.25DMIPS/MHz (Dhrystone 2.1)
+- Ultra-low-power with FlexPowerControl (down to 130 nA Standby mode and 100 uA/MHz run mode)
+- Core: ARM |reg| 32-bit Cortex |reg|-M4 CPU with FPU, frequency up to 80 MHz, 100DMIPS/1.25DMIPS/MHz (Dhrystone 2.1)
 - Clock Sources:
         - 4 to 48 MHz crystal oscillator
         - 32 kHz crystal oscillator for RTC (LSE)
         - Internal 16 MHz factory-trimmed RC (±1%)
         - Internal low-power 32 kHz RC (±5%)
-        - Internal multispeed 100 kHz to 48 MHz oscillator, auto-trimmed by LSE (better than ±0.25 % accuracy)
+        - Internal multispeed 100 kHz to 48 MHz oscillator, auto-trimmed by
+          LSE (better than ±0.25 % accuracy)
         - 3 PLLs for system clock, USB, audio, ADC
 - RTC with HW calendar, alarms and calibration
 - Up to 24 capacitive sensing channels: support touchkey, linear and rotary touch sensors
@@ -75,7 +76,7 @@ The STM32L475RG SoC provides the following hardware IPs:
         - Quad SPI memory interface
 - 4x digital filters for sigma delta modulator
 - Rich analog peripherals (independent supply)
-        - 3x 12-bit ADC 5 MSPS, up to 16-bit with hardware oversampling, 200 μA/MSPS
+        - 3x 12-bit ADC 5 MSPS, up to 16-bit with hardware oversampling, 200 uA/MSPS
         - 2x 12-bit DAC, low-power sample and hold
         - 2x operational amplifiers with built-in PGA
         - 2x ultra-low-power comparators
@@ -90,7 +91,7 @@ The STM32L475RG SoC provides the following hardware IPs:
 - 14-channel DMA controller
 - True random number generator
 - CRC calculation unit, 96-bit unique ID
-- Development support: serial wire debug (SWD), JTAG, Embedded Trace Macrocell™
+- Development support: serial wire debug (SWD), JTAG, Embedded Trace Macrocell |trade|
 
 
 More information about STM32L476RG can be found here:
diff --git a/boards/arm/frdm_k64f/doc/frdm_k64f.rst b/boards/arm/frdm_k64f/doc/frdm_k64f.rst
index fc2a98c1678..67aff171a36 100644
--- a/boards/arm/frdm_k64f/doc/frdm_k64f.rst
+++ b/boards/arm/frdm_k64f/doc/frdm_k64f.rst
@@ -33,7 +33,7 @@ Hardware
 - RGB LED
 - FXOS8700CQ accelerometer and magnetometer
 - Two user push buttons
-- Flexible power supply option – OpenSDAv2 USB, Kinetis K64 USB, and external source
+- Flexible power supply option - OpenSDAv2 USB, Kinetis K64 USB, and external source
 - Easy access to MCU input/output through Arduino* R3 compatible I/O connectors
 - Programmable OpenSDAv2 debug circuit supporting the CMSIS-DAP Interface
   software that provides:
diff --git a/boards/arm/frdm_kw41z/doc/frdm_kw41z.rst b/boards/arm/frdm_kw41z/doc/frdm_kw41z.rst
index ef2d713d0a4..89ae8f0caca 100644
--- a/boards/arm/frdm_kw41z/doc/frdm_kw41z.rst
+++ b/boards/arm/frdm_kw41z/doc/frdm_kw41z.rst
@@ -6,14 +6,15 @@ NXP FRDM-KW41Z
 Overview
 ********
 
-The FRDM-KW41Z is a development kit enabled by the Kinetis® W series
-KW41Z/31Z/21Z (KW41Z) family built on ARM® Cortex®-M0+ processor with
-integrated 2.4 GHz transceiver supporting Bluetooth® Smart/Bluetooth®Low Energy
-(BLE) v4.2, Generic FSK, IEEE® 802.15.4 and Thread.
+The FRDM-KW41Z is a development kit enabled by the Kinetis |reg| W series
+KW41Z/31Z/21Z (KW41Z) family built on ARM |reg| Cortex |reg|-M0+ processor with
+integrated 2.4 GHz transceiver supporting Bluetooth |reg| Smart/Bluetooth
+|reg| Low Energy
+(BLE) v4.2, Generic FSK, IEEE |reg| 802.15.4 and Thread.
 
 The FRDM-KW41Z kit contains two Freedom boards that can be used as a
 development board or a shield to connect to a host processor. The FRDM-KW41Z is
-form-factor compatible with the Arduino™ R3 pin layout for more expansion
+form-factor compatible with the Arduino |trade| R3 pin layout for more expansion
 options.
 
 The FRDM-KW41Z highly-sensitive, optimized 2.4 GHz radio features a PCB
diff --git a/boards/arm/hexiwear_k64/doc/hexiwear_k64.rst b/boards/arm/hexiwear_k64/doc/hexiwear_k64.rst
index 9d101a593dd..2cf176019e1 100644
--- a/boards/arm/hexiwear_k64/doc/hexiwear_k64.rst
+++ b/boards/arm/hexiwear_k64/doc/hexiwear_k64.rst
@@ -9,7 +9,7 @@ Overview
 Hexiwear is powered by a Kinetis K64 microcontroller based on the ARM Cortex-M4
 core. Another Kinetis wireless MCU, the KW40Z, provides Bluetooth Low Energy
 connectivity. Hexiwear also integrates a wide variety of sensors, as well as a
-user interface consisting of a 1.1” 96px x 96px full color OLED display and six
+user interface consisting of a 1.1" 96px x 96px full color OLED display and six
 capacitive buttons with haptic feedback.
 
 - Eye-catching Smart Watch form factor with powerful, low power Kinetis K6x MCU
@@ -17,7 +17,7 @@ capacitive buttons with haptic feedback.
 - Designed for wearable applications with the onboard rechargeable battery,
   OLED screen and onboard sensors such as optical heart rate, accelerometer,
   magnetometer and gyroscope.
-- Designed for IoT end node applications with the onboard sensor’s such as
+- Designed for IoT end node applications with the onboard sensor's such as
   temperature, pressure, humidity and ambient light.
 - Flexibility to let you add the sensors of your choice nearly 200 additional
   sensors through click boards.
@@ -39,7 +39,7 @@ Hardware
 - Li-Ion/Li-Po Battery Charger NXP MC34671
 - Optical heart rate sensor Maxim MAX30101
 - Ambient Light sensor, Humidity and Temperature sensor
-- 1.1” full color OLED display
+- 1.1" full color OLED display
 - Haptic feedback engine
 - 190 mAh 2C Li-Po battery
 - Capacitive touch interface
diff --git a/boards/arm/nucleo_f401re/doc/nucleof401re.rst b/boards/arm/nucleo_f401re/doc/nucleof401re.rst
index 1b2efebac76..189bc84af73 100644
--- a/boards/arm/nucleo_f401re/doc/nucleof401re.rst
+++ b/boards/arm/nucleo_f401re/doc/nucleof401re.rst
@@ -36,7 +36,7 @@ Hardware
 Nucleo F401RE provides the following hardware components:
 
 - STM32F401RET6 in LQFP64 package
-- ARM®32-bit Cortex®-M4 CPU with FPU
+- ARM |reg| 32-bit Cortex |reg|-M4 CPU with FPU
 - 84 MHz max CPU frequency
 - VDD from 1.7 V to 3.6 V
 - 512 KB Flash
diff --git a/boards/arm/nucleo_f411re/doc/nucleof411re.rst b/boards/arm/nucleo_f411re/doc/nucleof411re.rst
index 6c837f8b718..dd5ea820459 100644
--- a/boards/arm/nucleo_f411re/doc/nucleof411re.rst
+++ b/boards/arm/nucleo_f411re/doc/nucleof411re.rst
@@ -36,7 +36,7 @@ Hardware
 Nucleo F411RE provides the following hardware components:
 
 - STM32F411RET6 in LQFP64 package
-- ARM®32-bit Cortex®-M4 CPU with FPU
+- ARM |reg| 32-bit Cortex |reg|-M4 CPU with FPU
 - 100 MHz max CPU frequency
 - VDD from 1.7 V to 3.6 V
 - 512 KB Flash
diff --git a/boards/arm/nucleo_l476rg/doc/nucleol476rg.rst b/boards/arm/nucleo_l476rg/doc/nucleol476rg.rst
index 3eb94a89f49..3e8e2a93c70 100644
--- a/boards/arm/nucleo_l476rg/doc/nucleol476rg.rst
+++ b/boards/arm/nucleo_l476rg/doc/nucleol476rg.rst
@@ -35,17 +35,18 @@ Hardware
 
 The STM32L476RG SoC provides the following hardware IPs:
 
-- Ultra-low-power with FlexPowerControl (down to 130 nA Standby mode and 100 μA/MHz run mode)
-- Core: ARM® 32-bit Cortex®-M4 CPU with FPU, frequency up to 80 MHz, 100DMIPS/1.25DMIPS/MHz (Dhrystone 2.1)
+- Ultra-low-power with FlexPowerControl (down to 130 nA Standby mode and 100 uA/MHz run mode)
+- Core: ARM |reg| 32-bit Cortex |reg|-M4 CPU with FPU, frequency up to 80 MHz, 100DMIPS/1.25DMIPS/MHz (Dhrystone 2.1)
 - Clock Sources:
         - 4 to 48 MHz crystal oscillator
         - 32 kHz crystal oscillator for RTC (LSE)
         - Internal 16 MHz factory-trimmed RC (±1%)
         - Internal low-power 32 kHz RC (±5%)
-        - Internal multispeed 100 kHz to 48 MHz oscillator, auto-trimmed by LSE (better than ±0.25 % accuracy)
+        - Internal multispeed 100 kHz to 48 MHz oscillator, auto-trimmed by
+          LSE (better than ±0.25 % accuracy)
         - 3 PLLs for system clock, USB, audio, ADC
 - RTC with HW calendar, alarms and calibration
-- LCD 8 × 40 or 4 × 44 with step-up converter
+- LCD 8 x 40 or 4 x 44 with step-up converter
 - Up to 24 capacitive sensing channels: support touchkey, linear and rotary touch sensors
 - 16x timers:
         - 2x 16-bit advanced motor-control
@@ -62,7 +63,7 @@ The STM32L476RG SoC provides the following hardware IPs:
         - Quad SPI memory interface
 - 4x digital filters for sigma delta modulator
 - Rich analog peripherals (independent supply)
-        - 3× 12-bit ADC 5 MSPS, up to 16-bit with hardware oversampling, 200 μA/MSPS
+        - 3x 12-bit ADC 5 MSPS, up to 16-bit with hardware oversampling, 200 uA/MSPS
         - 2x 12-bit DAC, low-power sample and hold
         - 2x operational amplifiers with built-in PGA
         - 2x ultra-low-power comparators
@@ -77,7 +78,7 @@ The STM32L476RG SoC provides the following hardware IPs:
 - 14-channel DMA controller
 - True random number generator
 - CRC calculation unit, 96-bit unique ID
-- Development support: serial wire debug (SWD), JTAG, Embedded Trace Macrocell™
+- Development support: serial wire debug (SWD), JTAG, Embedded Trace Macrocell |trade|
 
 
 More information about STM32L476RG can be found here:
diff --git a/boards/nios2/altera_max10/doc/board.rst b/boards/nios2/altera_max10/doc/board.rst
index dc9f9b9f2f1..aedf88a6f35 100644
--- a/boards/nios2/altera_max10/doc/board.rst
+++ b/boards/nios2/altera_max10/doc/board.rst
@@ -13,9 +13,9 @@ the Nios II Gen 2 soft CPU.
 .. figure:: img/max_10_dev_kit_top_photo.jpg
    :width: 442px
    :align: center
-   :alt: Altera’s MAX* 10
+   :alt: Altera's MAX* 10
 
-   Altera’s MAX* 10  (Credit: Altera)
+   Altera's MAX* 10  (Credit: Altera)
 
 Hardware
 ********
@@ -35,7 +35,7 @@ importance is SW2:
 .. image:: img/Altera_MAX10_switches.jpg
    :width: 442px
    :align: center
-   :alt: Altera’s MAX* 10 Switches
+   :alt: Altera's MAX* 10 Switches
 
 Other switches are user switches, their position is application-specific.
 
diff --git a/boards/x86/arduino_101/doc/board.rst b/boards/x86/arduino_101/doc/board.rst
index 011960a0629..b67d85798fa 100644
--- a/boards/x86/arduino_101/doc/board.rst
+++ b/boards/x86/arduino_101/doc/board.rst
@@ -7,7 +7,7 @@ Overview
 ********
 
 The Arduino/Genuino 101 is a learning and development board which contains an
-Intel® Curie™ Module. This board is designed to integrate the core's low
+Intel |reg| Curie |trade| Module. This board is designed to integrate the core's low
 power-consumption and high performance with the Arduino's ease-of-use. The
 Arduino 101 adds Bluetooth Low Energy capabilities and has an on-board 6-axis
 accelerometer/gyroscope, providing exciting opportunities for building creative
@@ -24,7 +24,7 @@ The Intel Quark* SE SoC in the Curie module contains a single core 32 MHz x86
 (Intel Quark* processor) and the 32 MHz Argonaut RISC Core (ARC)* EM processor.
 The two processors operate simultaneously and share memory. The ARC processor is
 also referenced as the digital signal processor (DSP) sensor hub or a sensor
-subsystem depending on what document you’re looking at. In theory, the DSP can
+subsystem depending on what document you're looking at. In theory, the DSP can
 run using a minimal amount of power, gathering and processing sensor data while
 the x86 processor waits in a low power mode, which would be ideal for always-on
 applications.
diff --git a/boards/x86/quark_d2000_crb/doc/quark_d2000_crb.rst b/boards/x86/quark_d2000_crb/doc/quark_d2000_crb.rst
index 302f1483153..78b473860c1 100644
--- a/boards/x86/quark_d2000_crb/doc/quark_d2000_crb.rst
+++ b/boards/x86/quark_d2000_crb/doc/quark_d2000_crb.rst
@@ -6,7 +6,7 @@ Quark D2000 Development Board
 Overview
 ********
 
-The Intel® Quark ™ microcontroller D2000 package is shipped as a 40-pin QFN
+The Intel |reg| Quark |trade| microcontroller D2000 package is shipped as a 40-pin QFN
 component.
 
 .. image:: quark-d2000-developers-kit.png
@@ -14,7 +14,7 @@ component.
    :align: center
    :alt: Quark D2000 Development Board
 
-Intel™ Quark® microcontroller D2000 contains the following items:
+Intel |reg| Quark |trade| microcontroller D2000 contains the following items:
 
 - On-board components:
 
@@ -23,11 +23,11 @@ Intel™ Quark® microcontroller D2000 contains the following items:
 
 - Expansion options:
 
-  - “Arduino Uno” compatible SIL sockets ( 3.3V IO Only )
+  - "Arduino Uno" compatible SIL sockets ( 3.3V IO Only )
 
 - Other connectors:
 
-  - 1x USB 2.0 Device Port – micro Type B
+  - 1x USB 2.0 Device Port - micro Type B
   - On-board coin cell battery holder
   - 5V input a screw terminal/header (external power or Li-ion)
   - EEMBC power input header
@@ -38,7 +38,7 @@ Hardware
 General information for the board can be found at the `Intel Website`_,
 which includes both `schematics`_ and BRD files.
 
-The Intel® Quark™ Microcontroller D2000 Development Platform supports the
+The Intel |reg| Quark |trade| Microcontroller D2000 Development Platform supports the
 familiar open standard Arduino Uno Rev 3.0 physical interface and is
 mechanically compatible with Uno Rev 3.0. It does not support the 6 pin ICSP
 Header.
diff --git a/boards/x86/tinytile/doc/board.rst b/boards/x86/tinytile/doc/board.rst
index 8952e8baa79..08f3c1c1fd3 100644
--- a/boards/x86/tinytile/doc/board.rst
+++ b/boards/x86/tinytile/doc/board.rst
@@ -20,8 +20,8 @@ See :ref:`arduino_101` for information how to use the tinyTILE board with Zephyr
 
 Features of the tinyTILE include:
 
-- Intel® Curie™ module dual-core (Intel® Quark* processor core and ARC* core)
-- Bluetooth® low energy, 6-axis combo sensor and pattern matching engine
+- Intel |reg| Curie |trade| module dual-core (Intel |reg| Quark* processor core and ARC* core)
+- Bluetooth |reg| low energy, 6-axis combo sensor and pattern matching engine
 - 14 digital input/output pins (four can be used as PWM output pins)
 - Four PWM output pins
 - Six analog input pins
diff --git a/boards/xtensa/xt-sim/doc/xt-sim.rst b/boards/xtensa/xt-sim/doc/xt-sim.rst
index 6ebbce5cb4a..8a9737d2ca6 100644
--- a/boards/xtensa/xt-sim/doc/xt-sim.rst
+++ b/boards/xtensa/xt-sim/doc/xt-sim.rst
@@ -48,8 +48,8 @@ The frequency of the clock under simulation is set to 25MHz.
 System requirements
 *******************
 
-Pre-requisites
-==============
+Prerequisites
+=============
 A Linux host system is required for Xtensa development work.
 We recommend using a __``Debian 9.x (Stretch)``__ or recent __``Ubuntu``__
 releases (with multilib support).
diff --git a/doc/api/kernel_api.rst b/doc/api/kernel_api.rst
index 957567dbdfd..ab0243fee94 100644
--- a/doc/api/kernel_api.rst
+++ b/doc/api/kernel_api.rst
@@ -117,7 +117,7 @@ with basic priority inheritance.
 Alerts
 ******
 
-Alerts enable an application to perform asynchronous signalling,
+Alerts enable an application to perform asynchronous signaling,
 somewhat akin to Unix-style signals.
 (See :ref:`alerts_v2`.)
 
diff --git a/doc/application/application.rst b/doc/application/application.rst
index c537fb0c2a1..5fcde357ac0 100644
--- a/doc/application/application.rst
+++ b/doc/application/application.rst
@@ -306,7 +306,8 @@ An application's :file:`.conf` file defines its default kernel configuration.
 The settings in this file override or augment the board configuration settings.
 
 The board configuration settings can be viewed
-in :file:`$ZEPHYR_BASE/boards/ARCHITECTURE/BOARD/BOARD_defconfig`.
+LENGTHlWRONGEPHY
+_BASE/boards/ARCHITECTURE/BOARD/BOARD_defconfig`.
 
 .. note::
 
diff --git a/doc/contribute/security.rst b/doc/contribute/security.rst
index 8c21cd82089..227bba4196b 100644
--- a/doc/contribute/security.rst
+++ b/doc/contribute/security.rst
@@ -78,8 +78,8 @@ help prevent security violations and limit their impact:
   and permitted only in specific conditions defined by the system
   protection scheme, e.g., after successful authentication.
   Furthermore, default settings for services shall be chosen in a way
-  to provide maximum security.  This corresponds to the “Secure by
-  Default” paradigm [MICRO12]_.
+  to provide maximum security.  This corresponds to the "Secure by
+  Default" paradigm [MICRO12]_.
 
 - **Separation of privilege** is the principle that two conditions or
   more need to be satisfied before access is granted. In the context
@@ -220,7 +220,7 @@ scripting, missing authentication, and missing authorization. See the
 Security Subcommittee
 =====================
 
-There shall be a “security subcommittee”, responsible for
+There shall be a "security subcommittee", responsible for
 enforcing this guideline, monitoring reviews, and improving these
 guidelines.
 
@@ -280,12 +280,12 @@ and approved by consensus.
 
 .. _attack: http://www.theverge.com/2016/10/21/13362354/dyn-dns-ddos-attack-cause-outage-status-explained
 
-.. [MICRO12] Microsoft Corporation, Security Development Lifecycle – SDL
+.. [MICRO12] Microsoft Corporation, Security Development Lifecycle - SDL
    Process Guidance Version 5.2, 2012.
 
 .. [PAUL09] M. Paul, "The Ten Best Practices for Secure Software
    Development," International Information Systems Security Certification
-   Consortium, Inc. [(ISC)2®], Palm Harbor, FL, USA, 2009.
+   Consortium, Inc. [(ISC)2], Palm Harbor, FL, USA, 2009.
 
 .. [SALT75] J. H. Saltzer and M. D. Schroeder, "The protection of
    information in computer systems," Proceedings of the IEEE,
diff --git a/doc/getting_started/getting_started.rst b/doc/getting_started/getting_started.rst
index df8e1b8e439..6d6b7296080 100644
--- a/doc/getting_started/getting_started.rst
+++ b/doc/getting_started/getting_started.rst
@@ -179,7 +179,7 @@ Running a Sample Application in QEMU
 ====================================
 
 To perform rapid testing of an application in the development environment you
-can use the qemu emulation board configuration available for both X86 and ARM
+can use the QEMU emulation board configuration available for both X86 and ARM
 Cortex-M3 architectures. This can be easily accomplished by calling a special
 target when building an application that invokes QEMU once the build process is
 completed.
diff --git a/doc/getting_started/installation_win.rst b/doc/getting_started/installation_win.rst
index 0d7dfe804fd..d28dd3b5842 100644
--- a/doc/getting_started/installation_win.rst
+++ b/doc/getting_started/installation_win.rst
@@ -70,7 +70,7 @@ up:
 
      .. note::
 
-        The ISSM toolset only supports development for Intel® Quark™
+        The ISSM toolset only supports development for Intel |reg| Quark |trade|
         Microcontrollers, for example, the Arduino 101 board.  (Check out the
         "Zephyr Development Environment
         Setup" in this `Getting Started on Arduino 101 with ISSM`_ document.)
@@ -118,7 +118,7 @@ up:
 #. Finally, you can try building the :ref:`hello_world` sample to check things
    out.
 
-   To build for the Intel® Quark™ (x86-based) Arduino 101:
+   To build for the Intel |reg| Quark |trade| (x86-based) Arduino 101:
 
     .. code-block:: console
 
@@ -198,7 +198,7 @@ Windows, you will need to build or install a toolchain:
 
    .. note::
 
-      The ISSM toolset only supports development for Intel® Quark™
+      The ISSM toolset only supports development for Intel |reg| Quark |trade|
       Microcontrollers, for example, the Arduino 101 board.  (Check out the
       "Zephyr Development Environment
       Setup" in this `Getting Started on Arduino 101 with ISSM`_ document.)
diff --git a/doc/kernel/data_passing/mailboxes.rst b/doc/kernel/data_passing/mailboxes.rst
index 8349c23a622..3721b093161 100644
--- a/doc/kernel/data_passing/mailboxes.rst
+++ b/doc/kernel/data_passing/mailboxes.rst
@@ -371,7 +371,7 @@ can examine the message descriptor to determine which thread sent the message,
 how much data was exchanged,
 and the application-defined info value supplied by the sending thread.
 
-Any number of receiving threads may wait simultaneously on a mailboxes's
+Any number of receiving threads may wait simultaneously on a mailboxes'
 receive queue. The threads are sorted according to their priority;
 threads of equal priority are sorted so that the one that started waiting
 first can receive a message first.
diff --git a/doc/kernel/memory/heap.rst b/doc/kernel/memory/heap.rst
index 14ceff3787d..36563fe674c 100644
--- a/doc/kernel/memory/heap.rst
+++ b/doc/kernel/memory/heap.rst
@@ -3,7 +3,7 @@
 Heap Memory Pool
 ################
 
-The :dfn:`heap memory pool` is a pre-defined memory pool object that allows
+The :dfn:`heap memory pool` is a predefined memory pool object that allows
 threads to dynamically allocate memory from a common memory region
 in a :cpp:func:`malloc()`-like manner.
 
diff --git a/doc/kernel/other/interrupts.rst b/doc/kernel/other/interrupts.rst
index 951fbbeb3d1..ae60301507e 100644
--- a/doc/kernel/other/interrupts.rst
+++ b/doc/kernel/other/interrupts.rst
@@ -86,7 +86,7 @@ is running.
     interrupted until it has explicitly unlocked its IRQ lock.
 
 Alternatively, a thread may temporarily **disable** a specified IRQ
-so its associated ISR does not execute when the IRQ is signalled.
+so its associated ISR does not execute when the IRQ is signaled.
 The IRQ must be subsequently **enabled** to permit the ISR to execute.
 
 .. important::
diff --git a/doc/kernel/overview/changes.rst b/doc/kernel/overview/changes.rst
index 994adfc6c0e..ed28115e647 100644
--- a/doc/kernel/overview/changes.rst
+++ b/doc/kernel/overview/changes.rst
@@ -103,7 +103,7 @@ in system clock ticks. This change makes things more intuitive for most
 developers. However, the kernel still implements timeouts using the
 tick-based system clock.
 
-The previous nanokernel timer and microkernel timer object types have beeni
+The previous nanokernel timer and microkernel timer object types have been
 merged into a single type.
 
 Memory Allocation
@@ -123,7 +123,7 @@ from a heap data pool.
 Synchronization
 ***************
 
-The prevous nanokernel semaphore and microkernel semaphore object types have been
+The previous nanokernel semaphore and microkernel semaphore object types have been
 merged into a single type. The new type can now be used as a binary semaphore,
 as well as a counting semaphore.
 
@@ -135,7 +135,7 @@ non-blocking manner or use an additional mechanism, such as an event object,
 to signal the application that one of the semaphores is available.
 
 The previous microkernel event object type is renamed to "alert" and is now presented as
-a relative to Unix-style signalling. Due to improvements to the implementation
+a relative to Unix-style signaling. Due to improvements to the implementation
 of semaphores, alerts are now less efficient to use for basic synchronization
 than semaphores; consequently, alerts should now be reserved for scenarios
 requiring the use of a callback function.
diff --git a/doc/kernel/overview/overview.rst b/doc/kernel/overview/overview.rst
index 73a76ec4e7f..8275fc1c16e 100644
--- a/doc/kernel/overview/overview.rst
+++ b/doc/kernel/overview/overview.rst
@@ -14,7 +14,7 @@ features needed by your application, making it ideal for systems with limited
 amounts of memory (as little as 2 KB!) or with simple multi-threading
 requirements (such as a set of interrupt handlers and a single background task).
 Examples of such systems include: embedded sensor hubs, environmental sensors,
-simple LED wearables, and store inventory tags.
+simple LED wearable, and store inventory tags.
 
 Applications requiring more memory (50 to 900 KB), multiple communication
 devices (like WiFi and Bluetooth Low Energy), and complex multi-threading,
diff --git a/doc/kernel/synchronization/alerts.rst b/doc/kernel/synchronization/alerts.rst
index 695585df569..024f24bcd68 100644
--- a/doc/kernel/synchronization/alerts.rst
+++ b/doc/kernel/synchronization/alerts.rst
@@ -4,7 +4,7 @@ Alerts
 ######
 
 An :dfn:`alert` is a kernel object that allows an application to perform
-asynchronous signalling when a condition of interest occurs.
+asynchronous signaling when a condition of interest occurs.
 
 .. contents::
     :local:
@@ -19,7 +19,7 @@ its memory address.
 An alert has the following key properties:
 
 * An **alert handler**, which specifies the action to be taken
-  when the alert is signalled. The action may instruct the system workqueue
+  when the alert is signaled. The action may instruct the system workqueue
   to execute a function to process the alert, mark the alert as pending
   so it can be processed later by a thread, or ignore the alert.
 
@@ -78,7 +78,7 @@ significant differences. The most notable of these are:
 * A Zephyr alert pends *after* it has been delivered to its alert handler,
   and only if an alert handler function does not consume the alert.
 
-* Zephyr has no pre-defined alerts or actions. All alerts are application
+* Zephyr has no predefined alerts or actions. All alerts are application
   defined, and all have a default action that pends the alert.
 
 Implementation
@@ -116,7 +116,7 @@ The following code has the same effect as the code segment above.
 Signaling an Alert
 ==================
 
-An alert is signalled by calling :cpp:func:`k_alert_send()`.
+An alert is signaled by calling :cpp:func:`k_alert_send()`.
 
 The following code illustrates how an ISR can signal an alert
 to indicate that a key press has occurred.
@@ -137,7 +137,7 @@ to indicate that a key press has occurred.
 Handling an Alert
 =================
 
-An alert handler function is used when a signalled alert should not be ignored
+An alert handler function is used when a signaled alert should not be ignored
 or immediately pended. It has the following form:
 
 .. code-block:: c
@@ -162,7 +162,7 @@ key presses detected by an ISR (as shown in the previous section).
         /* do complex processing of the keystroke */
 	...
 
-        /* signalled alert has been consumed */
+        /* signaled alert has been consumed */
         return 0;
     }
 
@@ -189,10 +189,10 @@ only when a numeric key is pressed.
         if ((c >= '0') && (c <= '9')) {
             /* save key press information */
             ...
-            /* signalled alert should be pended */
+            /* signaled alert should be pended */
             return 1;
         } else {
-            /* signalled alert has been consumed */
+            /* signaled alert has been consumed */
             return 0;
         }
     }
@@ -219,7 +219,7 @@ work to a thread to reduce the amount of time interrupts are locked.
 Use an alert to allow the kernel's system workqueue to handle an alert,
 rather than defining an application thread to handle it.
 
-Use an alert to allow the kernel's system workqueue to pre-process an alert,
+Use an alert to allow the kernel's system workqueue to preprocess an alert,
 prior to letting an application thread handle it.
 
 Configuration Options
diff --git a/doc/kernel/synchronization/mutexes.rst b/doc/kernel/synchronization/mutexes.rst
index cc55df8b89e..c3f8db0a4b3 100644
--- a/doc/kernel/synchronization/mutexes.rst
+++ b/doc/kernel/synchronization/mutexes.rst
@@ -36,7 +36,7 @@ by another thread, the requesting thread may choose to wait for the mutex
 to be unlocked.
 
 After locking a mutex, the thread may safely use the associated resource
-for as long as needed; however, it is considered good practise to hold the lock
+for as long as needed; however, it is considered good practice to hold the lock
 for as short a time as possible to avoid negatively impacting other threads
 that want to use the resource. When the thread no longer needs the resource
 it must **unlock** the mutex to allow other threads to use the resource.
diff --git a/doc/kernel/threads/lifecycle.rst b/doc/kernel/threads/lifecycle.rst
index 5b636ae28bb..194e2f742c4 100644
--- a/doc/kernel/threads/lifecycle.rst
+++ b/doc/kernel/threads/lifecycle.rst
@@ -52,9 +52,9 @@ instructed to delay execution of the thread by specifying a timeout
 value -- for example, to allow device hardware used by the thread
 to become available.
 
-The kernel allows a delayed start to be cancelled before the thread begins
+The kernel allows a delayed start to be canceled before the thread begins
 executing. A cancellation request has no effect if the thread has already
-started. A thread whose delayed start was successfully cancelled must be
+started. A thread whose delayed start was successfully canceled must be
 re-spawned before it can be used.
 
 Thread Termination
diff --git a/doc/kernel/threads/workqueues.rst b/doc/kernel/threads/workqueues.rst
index d87879284db..b27a042b78e 100644
--- a/doc/kernel/threads/workqueues.rst
+++ b/doc/kernel/threads/workqueues.rst
@@ -122,7 +122,7 @@ Attempting to cancel a delayed work item once its timeout has expired has
 no effect on the work item; the work item remains pending in the workqueue's
 queue, unless the work item has already been removed and processed by the
 workqueue's thread. Consequently, once a work item's timeout has expired
-the work item is always processed by the workqueue and cannot be cancelled.
+the work item is always processed by the workqueue and cannot be canceled.
 
 System Workqueue
 ================
@@ -224,7 +224,7 @@ A delayed work item is defined using a variable of type
 An initialized delayed work item can be submitted to the system workqueue by
 calling :cpp:func:`k_delayed_work_submit()`, or to a specified workqueue by
 calling :cpp:func:`k_delayed_work_submit_to_queue()`. A delayed work item
-that has been submitted but not yet consumed by its workqueue can be cancelled
+that has been submitted but not yet consumed by its workqueue can be canceled
 by calling :cpp:func:`k_delayed_work_cancel()`.
 
 Suggested Uses
diff --git a/doc/porting/board_porting.rst b/doc/porting/board_porting.rst
index f88bc921abc..eead0a92c3c 100644
--- a/doc/porting/board_porting.rst
+++ b/doc/porting/board_porting.rst
@@ -23,7 +23,7 @@ Hardware Configuration Hierarchy
 ********************************
 
 Hardware definitions in Zephyr follow a well-defined hierarchy of configurations
-and layers, below are thelayers from top to bottom:
+and layers, below are the layers from top to bottom:
 
 - Board
 - SoC
@@ -105,7 +105,7 @@ SoC Series
 ----------
 
 Moving closer to the SoC, the series is derived from an SoC family. A series is
-defined by a feautre set that serves the purpose of distinguishing different
+defined by a feature set that serves the purpose of distinguishing different
 SoCs belonging to the same family.
 
 SoC
diff --git a/doc/release-notes-1.5.rst b/doc/release-notes-1.5.rst
index 70bd08f43eb..fc0d7bc2438 100644
--- a/doc/release-notes-1.5.rst
+++ b/doc/release-notes-1.5.rst
@@ -83,9 +83,9 @@ Bluetooth
 Build and Infrastructure
 ************************
 
-- Added “qemugdb” target to start a local GDB on port 1234.
+- Added "qemugdb" target to start a local GDB on port 1234.
 - Added script to filter known issues in the build output.
-- Sanity: Added “-R” option to build all test with assertions.
+- Sanity: Added "-R" option to build all test with assertions.
 
 Libraries
 *********
@@ -101,7 +101,7 @@ Documentation
 - Fixed several typos, trademarks and grammar.
 - Moved all the boards documentation to the wiki.
 - Moved Code Contribution documentation to the wiki.
-- Added package “ncurses” to the list of requirements.
+- Added package "ncurses" to the list of requirements.
 - Updated Mac OS X instructions.
 
 Test and Samples
diff --git a/doc/subsystems/bluetooth/gap-pics.rst b/doc/subsystems/bluetooth/gap-pics.rst
index 6e48cb4eb83..e3cc1c71767 100644
--- a/doc/subsystems/bluetooth/gap-pics.rst
+++ b/doc/subsystems/bluetooth/gap-pics.rst
@@ -700,9 +700,9 @@ Central Simultaneous BR/EDR and LE Transports
 ==============	==============	=======================================
 Parameter Name	Selected	Description
 ==============	==============	=======================================
-TSPC_GAP_44_1	False (*)	Simultaneous BR/EDR and LE Transports – BR/EDR
+TSPC_GAP_44_1	False (*)	Simultaneous BR/EDR and LE Transports - BR/EDR
 				Slave to the same device (C.1)
-TSPC_GAP_44_2	False (*)	Simultaneous BR/EDR and LE Transports – BR/EDR
+TSPC_GAP_44_2	False (*)	Simultaneous BR/EDR and LE Transports - BR/EDR
 				Master to the same device (C.1)
 ==============	==============	=======================================
 
@@ -713,9 +713,9 @@ Peripheral Simultaneous BR/EDR and LE Transports
 ==============	==============	=======================================
 Parameter Name	Selected	Description
 ==============	==============	=======================================
-TSPC_GAP_45_1	False (*)	Simultaneous BR/EDR and LE Transports – BR/EDR
+TSPC_GAP_45_1	False (*)	Simultaneous BR/EDR and LE Transports - BR/EDR
 				Slave to the same device (C.1)
-TSPC_GAP_45_2	False (*)	Simultaneous BR/EDR and LE Transports – BR/EDR
+TSPC_GAP_45_2	False (*)	Simultaneous BR/EDR and LE Transports - BR/EDR
 				Master to the same device (C.1)
 ==============	==============	=======================================
 
diff --git a/doc/subsystems/bluetooth/l2cap-pics.rst b/doc/subsystems/bluetooth/l2cap-pics.rst
index 2c859f660e9..d1615cfb2a9 100644
--- a/doc/subsystems/bluetooth/l2cap-pics.rst
+++ b/doc/subsystems/bluetooth/l2cap-pics.rst
@@ -112,15 +112,15 @@ TSPC_L2CAP_3_6	False (*)	Support of flush timeout value for unreliable
 TSPC_L2CAP_3_7	False (*)	Support of bi-directional quality of service
 				(QoS) option field
 TSPC_L2CAP_3_8	False (*)	Negotiate QoS service type
-TSPC_L2CAP_3_9	False (*)	Negotiate and support service type ‘No traffic’
-TSPC_L2CAP_3_10	False (*)	Negotiate and support service type ‘Best effort’
-TSPC_L2CAP_3_11	False (*)	Negotiate and support service type ‘Guaranteed’
+TSPC_L2CAP_3_9	False (*)	Negotiate and support service type 'No traffic'
+TSPC_L2CAP_3_10	False (*)	Negotiate and support service type 'Best effort'
+TSPC_L2CAP_3_11	False (*)	Negotiate and support service type 'Guaranteed'
 TSPC_L2CAP_3_12	True		Support minimum MTU size 23 octets
-TSPC_L2CAP_3_13	False (*)	Negotiate and support service type ‘No traffic’
+TSPC_L2CAP_3_13	False (*)	Negotiate and support service type 'No traffic'
 				for Extended Flow Specification
-TSPC_L2CAP_3_14	False (*)	Negotiate and support service type ‘Best Effort'
+TSPC_L2CAP_3_14	False (*)	Negotiate and support service type 'Best Effort'
 				for Extended Flow Specification
-TSPC_L2CAP_3_15	False (*)	Negotiate and support service type ‘Guaranteed’
+TSPC_L2CAP_3_15	False (*)	Negotiate and support service type 'Guaranteed'
 				for Extended Flow Specification
 TSPC_L2CAP_3_16	True		Support Multiple Simultaneous LE Data Channels
 ===============	===========	=======================================
diff --git a/doc/subsystems/bluetooth/sm-pics.rst b/doc/subsystems/bluetooth/sm-pics.rst
index 03820a19ee8..eca06e0c1c0 100644
--- a/doc/subsystems/bluetooth/sm-pics.rst
+++ b/doc/subsystems/bluetooth/sm-pics.rst
@@ -68,7 +68,7 @@ Parameter Name	Selected	Description
 TSPC_SM_5_1	True		Encryption Setup using STK (C.3)
 TSPC_SM_5_2	True		Encryption Setup using LTK (O)
 TSPC_SM_5_3	True		Slave Initiated Security (C.1)
-TSPC_SM_5_4	True		Slave Initiated Security – Master response(C.2)
+TSPC_SM_5_4	True		Slave Initiated Security - Master response(C.2)
 ===============	===========	=======================================
 
 
diff --git a/doc/subsystems/logging/kernel_event_logger.rst b/doc/subsystems/logging/kernel_event_logger.rst
index 5e1e8a5bfcd..28b9350960a 100644
--- a/doc/subsystems/logging/kernel_event_logger.rst
+++ b/doc/subsystems/logging/kernel_event_logger.rst
@@ -20,14 +20,14 @@ application. The capacity of the kernel event logger is also configurable.
 By default, it has a ring buffer that can hold up to 128 32-bit words
 of event information.
 
-The kernel event logger is capable of recording the following pre-defined
+The kernel event logger is capable of recording the following predefined
 event types:
 
 * Interrupts.
 * Context switching of threads.
 * Kernel sleep events (i.e. entering and exiting a low power state).
 
-The kernel event logger only records the pre-defined event types it has been
+The kernel event logger only records the predefined event types it has been
 configured to record. Each event type can be enabled independently.
 
 An application can also define and record custom event types.
@@ -93,7 +93,7 @@ A **sleep event** has the following format:
     };
 
 A **custom event** must have a type ID that does not conflict with
-any existing pre-defined event type ID. The format of a custom event
+any existing predefined event type ID. The format of a custom event
 is application-defined, but must contain at least one 32-bit data word.
 A custom event may utilize a variable size, to allow different events
 of a single type to record differing amounts of information.
@@ -101,7 +101,7 @@ of a single type to record differing amounts of information.
 Timestamps
 ==========
 
-By default, the timestamp recorded with each pre-defined event is obtained from
+By default, the timestamp recorded with each predefined event is obtained from
 the kernel's :ref:`hardware clock <clocks_v2>`. This 32-bit clock counts up
 extremely rapidly, which means the timestamp value wraps around frequently.
 (For example, the Lakemont APIC timer for Quark SE wraps every 134 seconds.)
@@ -176,7 +176,7 @@ Adding a Custom Event Type
 ==========================
 
 A custom event type must use an integer type ID that does not duplicate
-an existing type ID. The type IDs for the pre-defined events can be found
+an existing type ID. The type IDs for the predefined events can be found
 in :file:`include/logging/kernel_event_logger.h`. If dynamic recording of
 events is enabled, the event type ID must not exceed 32.
 
diff --git a/doc/subsystems/networking/network-management-api.rst b/doc/subsystems/networking/network-management-api.rst
index 9e46800ee9c..43fb33d8c9a 100644
--- a/doc/subsystems/networking/network-management-api.rst
+++ b/doc/subsystems/networking/network-management-api.rst
@@ -69,7 +69,7 @@ will be found in the `include/net/net_mgmt.h` header file. But in case
 of an L2 technology, let's say Ethernet, these would be found in
 `include/net/ethernet.h`
 
-You define your handler modelled with this signature:
+You define your handler modeled with this signature:
 
 .. code-block:: c
 
diff --git a/doc/subsystems/networking/qemu_setup.rst b/doc/subsystems/networking/qemu_setup.rst
index 8b1dbf32805..b0d851123c9 100644
--- a/doc/subsystems/networking/qemu_setup.rst
+++ b/doc/subsystems/networking/qemu_setup.rst
@@ -1,6 +1,6 @@
 .. _networking_with_qemu:
 
-Networking with Qemu
+Networking with QEMU
 ####################
 
 This page describes how to set up a "virtual" networking between a (Linux) host
@@ -41,7 +41,7 @@ For the steps below, you will need at least 4 terminal windows:
 Step 1 - Create helper socket
 =============================
 
-Before starting QEMU with network emulation, a unix socket for the emulation
+Before starting QEMU with network emulation, a Unix socket for the emulation
 should be created.
 
 In terminal #2, type:
diff --git a/doc/subsystems/shell.rst b/doc/subsystems/shell.rst
index 4229cf51fb8..ede10924c4a 100644
--- a/doc/subsystems/shell.rst
+++ b/doc/subsystems/shell.rst
@@ -24,7 +24,7 @@ A shell interface exposing subsystem features is a shell module, multiple
 modules can be available at the same time.
 
 `MODULE_NAME COMMAND`
- One of the available modules is “KERNEL”, for the Kernel module.  More
+ One of the available modules is "KERNEL", for the Kernel module.  More
  information can be found in :c:macro:`SHELL_REGISTER`.
 
 Help commands
@@ -48,7 +48,7 @@ Select module commands
  command, you will not need to enter module name in further commands. If
  the selected module has set a default shell prompt during its initialization,
  the prompt will be changed to that one. Otherwise, the prompt will be
- changed to the selected module’s name to reflect the current module in use.
+ changed to the selected module's name to reflect the current module in use.
 
 `select`
  Clears selected module. Restores prompt as well.
@@ -71,7 +71,7 @@ Example:
 
 CONFIG_NET_SHELL=y
 
-In the subsystem’s code, the shell usage depends on this config parameter.
+In the subsystem's code, the shell usage depends on this config parameter.
 This subsystem specific flag should also depend on :option:`CONFIG_CONSOLE_SHELL` flag.
 
 Configuration steps to add shell functionality to a module
@@ -103,7 +103,7 @@ set a default module in code level. In this case, the function
 shell_register_default_module should be called after calling SHELL_REGISTER in
 application level.  If the function shell_register_prompt_handler was called as
 well, the prompt will be changed to that one.  Otherwise, the prompt will be
-changed to the selected module’s name, in order to reflect the current module in
+changed to the selected module's name, in order to reflect the current module in
 use.
 
 
diff --git a/samples/net/http_server/README.rst b/samples/net/http_server/README.rst
index 31f4e9c949d..c6be31e5a9e 100644
--- a/samples/net/http_server/README.rst
+++ b/samples/net/http_server/README.rst
@@ -129,7 +129,7 @@ wget will show:
 	Connecting to 192.168.1.101:80... connected.
 	HTTP request sent, awaiting response... 200 OK
 	Length: unspecified [text/html]
-	Saving to: ‘index.html’
+	Saving to: 'index.html'
 
 The HTML file generated by Zephyr and downloaded by wget is:
 
@@ -174,7 +174,7 @@ wget will show:
 	Connecting to 192.168.1.101:80... connected.
 	HTTP request sent, awaiting response... 200 OK
 	Length: unspecified [text/html]
-	Saving to: ‘index.html’
+	Saving to: 'index.html'
 
 This is the HTML file generated by Zephyr and downloaded by wget:
 
@@ -288,7 +288,7 @@ This will be shown on the screen
 	Unable to locally verify the issuer's authority.
 	HTTP request sent, awaiting response... 200 OK
 	Length: unspecified [text/html]
-	Saving to: ‘index.html’
+	Saving to: 'index.html'
 
 	index.html                                            [ <=> ]