release: Zephyr 2.3.0

Set version to 2.3.0 final.

Signed-off-by: Carles Cufi <carles.cufi@nordicsemi.no>

VERSION

@@ -2,4 +2,4 @@ VERSION_MAJOR = 2
 VERSION_MINOR = 3
 PATCHLEVEL = 0
 VERSION_TWEAK = 0
-EXTRAVERSION = rc2
+EXTRAVERSION =

doc/README.rst

@@ -132,16 +132,15 @@ folder, here are the commands to generate the html content locally:
 .. code-block:: console
 
    # On Linux/macOS
-   cd ~/zephyr
-   source zephyr-env.sh
-   mkdir -p doc/_build && cd doc/_build
+   cd ~/zephyr/doc
    # On Windows
-   cd %userprofile%\zephyr
-   zephyr-env.cmd
-   mkdir doc\_build & cd doc/_build
+   cd %userprofile%\zephyr\doc
 
    # Use cmake to configure a Ninja-based build system:
-   cmake -GNinja ..
+   cmake -GNinja -B_build .
+
+   # Enter the build directory
+   cd _build
 
    # To generate HTML output, run ninja on the generated build system:
    ninja htmldocs
@@ -181,7 +180,6 @@ there:
 .. code-block:: console
 
    cd ~/zephyr
-   source zephyr-env.sh
 
    # To generate HTML output
    make htmldocs
@@ -227,7 +225,6 @@ To enable this mode, set the following option when invoking cmake::
 or invoke make with the following target::
 
    cd ~/zephyr
-   source zephyr-env.sh
 
    # To generate HTML output without detailed Kconfig
    make htmldocs-fast

doc/conf.py

@@ -539,6 +539,7 @@ html_context = {
     'theme_logo_only': False,
     'current_version': version,
     'versions': (("latest", "/"),
+                 ("2.3.0", "/2.3.0/"),
                  ("2.2.0", "/2.2.0/"),
                  ("2.1.0", "/2.1.0/"),
                  ("2.0.0", "/2.0.0/"),

doc/guides/modules.rst

@@ -131,10 +131,10 @@ section.
    .. code-block:: cmake
 
       set(ZEPHYR_MODULES <path-to-module1> <path-to-module2> [...])
-      include($ENV{ZEPHYR_BASE}/cmake/app/boilerplate.cmake NO_POLICY_SCOPE)
+      find_package(Zephyr REQUIRED HINTS $ENV{ZEPHYR_BASE})
 
-   If you choose this option, make sure to set the variable **before** including
-   the boilerplate file, as shown above.
+   If you choose this option, make sure to set the variable **before**  calling
+   ``find_package(Zephyr ...)``, as shown above.
 
 #. In a separate CMake script which is pre-loaded to populate the CMake cache,
    like this:

doc/reference/overview.rst

@@ -27,7 +27,7 @@ current :ref:`stability level <api_lifecycle>`.
    * - :ref:`bluetooth_api`
      - Stable
      - 1.0
-     - 2.2
+     - 2.3
 
    * - :ref:`can_api`
      - Experimental
@@ -42,12 +42,12 @@ current :ref:`stability level <api_lifecycle>`.
    * - :ref:`device_model_api`
      - Stable
      - 1.0
-     - 2.2
+     - 2.3
 
    * - :ref:`devicetree_api`
      - Experimental
      - 2.2
-     - 2.2
+     - 2.3
 
    * - :ref:`display_api`
      - Unstable
@@ -62,7 +62,7 @@ current :ref:`stability level <api_lifecycle>`.
    * - :ref:`kernel_api`
      - Stable
      - 1.0
-     - 2.2
+     - 2.3
 
    * - :ref:`logging_api`
      - Stable
@@ -77,7 +77,7 @@ current :ref:`stability level <api_lifecycle>`.
    * - :ref:`networking_api`
      - Stable
      - 1.0
-     - 2.2
+     - 2.3
 
    * - :ref:`adc_api`
      - Stable
@@ -132,7 +132,7 @@ current :ref:`stability level <api_lifecycle>`.
    * - :ref:`hwinfo_api`
      - Stable
      - 1.14
-     - 1.14
+     - 2.3
 
    * - :ref:`i2c_eeprom_slave_api`
      - Stable
@@ -164,6 +164,11 @@ current :ref:`stability level <api_lifecycle>`.
      - 2.1
      - 2.2
 
+   * - :ref:`peci_api`
+     - Stable
+     - 2.1
+     - 2.2
+
    * - :ref:`pinmux_api`
      - Stable
      - 1.0
@@ -182,7 +187,7 @@ current :ref:`stability level <api_lifecycle>`.
    * - :ref:`sensor_api`
      - Stable
      - 1.2
-     - 2.0
+     - 2.3
 
    * - :ref:`spi_api`
      - Stable
@@ -227,7 +232,7 @@ current :ref:`stability level <api_lifecycle>`.
    * - :ref:`shell_api`
      - Stable
      - 1.14
-     - 2.2
+     - 2.3
 
    * - :ref:`disk_access_api`
      - Stable
@@ -252,7 +257,7 @@ current :ref:`stability level <api_lifecycle>`.
    * - :ref:`flash_map_api`
      - Stable
      - 1.11
-     - 2.0
+     - 2.3
 
    * - :ref:`nvs_api`
      - Stable
@@ -262,7 +267,7 @@ current :ref:`stability level <api_lifecycle>`.
    * - :ref:`usb_api`
      - Stable
      - 1.5
-     - 2.2
+     - 2.3
 
    * - :ref:`usermode_api`
      - Stable

doc/reference/peripherals/peci.rst

@@ -1,4 +1,4 @@
-.. _peci:
+.. _peci_api:
 
 PECI
 ####

doc/releases/release-notes-2.4.rst

@@ -0,0 +1,262 @@
+:orphan:
+
+.. _zephyr_2.4:
+
+Zephyr 2.4.0 (Working Draft)
+############################
+
+We are pleased to announce the release of Zephyr RTOS version 2.4.0.
+
+Major enhancements with this release include:
+
+
+The following sections provide detailed lists of changes by component.
+
+Security Vulnerability Related
+******************************
+
+The following CVEs are addressed by this release:
+
+
+More detailed information can be found in:
+https://docs.zephyrproject.org/latest/security/vulnerabilities.html
+
+Known issues
+************
+
+You can check all currently known issues by listing them using the GitHub
+interface and listing all issues with the `bug label
+<https://github.com/zephyrproject-rtos/zephyr/issues?q=is%3Aissue+is%3Aopen+label%3Abug>`_.
+
+
+API Changes
+***********
+
+Deprecated in this release
+==========================
+
+
+Removed APIs in this release
+============================
+
+
+Stable API changes in this release
+==================================
+
+
+Kernel
+******
+
+
+Architectures
+*************
+
+* ARC:
+
+
+* ARM:
+
+
+* POSIX:
+
+
+* RISC-V:
+
+
+* x86:
+
+
+Boards & SoC Support
+********************
+
+* Added support for these SoC series:
+
+
+* Added support for these ARM boards:
+
+
+* Made these changes in other boards
+
+
+* Added support for these following shields:
+
+
+Drivers and Sensors
+*******************
+
+* ADC
+
+
+* Audio
+
+
+* Bluetooth
+
+
+* CAN
+
+
+* Clock Control
+
+
+* Console
+
+
+* Counter
+
+
+* Crypto
+
+
+* DAC
+
+
+* Debug
+
+
+* Display
+
+
+* DMA
+
+
+* EEPROM
+
+
+* Entropy
+
+
+* ESPI
+
+
+* Ethernet
+
+
+* Flash
+
+
+* GPIO
+
+
+* Hardware Info
+
+
+* I2C
+
+
+* I2S
+
+
+* IEEE 802.15.4
+
+
+* Interrupt Controller
+
+
+* IPM
+
+
+* Keyboard Scan
+
+
+* LED
+
+
+* LED Strip
+
+
+* LoRa
+
+
+* Modem
+
+
+* PECI
+
+
+* Pinmux
+
+
+* PS/2
+
+
+* PWM
+
+
+* Sensor
+
+
+* Serial
+
+
+* SPI
+
+
+* Timer
+
+
+* USB
+
+
+* Video
+
+
+* Watchdog
+
+
+* WiFi
+
+
+
+Networking
+**********
+
+
+Bluetooth
+*********
+
+* Host:
+
+
+* BLE split software Controller:
+
+
+Build and Infrastructure
+************************
+
+* Devicetree
+
+Libraries / Subsystems
+**********************
+
+* Disk
+
+
+* Random
+
+
+* POSIX subsystem:
+
+
+* Power management:
+
+
+HALs
+****
+
+* HALs are now moved out of the main tree as external modules and reside in
+  their own standalone repositories.
+
+Documentation
+*************
+
+
+Tests and Samples
+*****************
+
+
+Issue Related Items
+*******************
+
+These GitHub issues were addressed since the previous 2.3.0 tagged
+release:

doc/security/vulnerabilities.rst

@@ -360,15 +360,90 @@ This issue has not been fixed.
 - `Zephyr project bug tracker ZEPSEC-37
   <https://zephyrprojectsec.atlassian.net/browse/ZEPSEC-37>`_
 
+CVE-2020-10061
+--------------
+
+Error handling invalid packet sequence
+
+Improper handling of the full-buffer case in the Zephyr Bluetooth
+implementation can result in memory corruption.
+
+This has been fixed in branches for v1.14.0, v2.2.0, and will be
+included in v2.3.0.
+
+- `CVE-2020-10061 <http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-10061>`_
+
+- `Zephyr project bug tracker ZEPSEC-75
+  <https://zephyrprojectsec.atlassian.net/browse/ZEPSEC-75>`_
+
+- `PR23516 fix for v2.3 (split driver)
+  <https://github.com/zephyrproject-rtos/zephyr/pull/23516>`_
+
+- `PR23517 fix for v2.3 (legacy driver)
+  <https://github.com/zephyrproject-rtos/zephyr/pull/23517>`_
+
+- `PR23091 fix for branch from v1.14.0
+  <https://github.com/zephyrproject-rtos/zephyr/pull/23091>`_
+
+- `PR23547 fix for branch from v2.2.0
+  <https://github.com/zephyrproject-rtos/zephyr/pull/23547>`_
+
 CVE-2020-10062
 --------------
 
-Under embargo until 2020/05/25
+Packet length decoding error in MQTT
+
+CVE: An off-by-one error in the Zephyr project MQTT packet length
+decoder can result in memory corruption and possible remote code
+execution. NCC-ZEP-031
+
+The MQTT packet header length can be 1 to 4 bytes. An off-by-one error
+in the code can result in this being interpreted as 5 bytes, which can
+cause an integer overflow, resulting in memory corruption.
+
+This has been fixed in master for v2.3.
+
+- `CVE-2020-10062 <http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-10062>`_
+
+- `Zephyr project bug tracker ZEPSEC-84
+  <https://zephyrprojectsec.atlassian.net/browse/ZEPSEC-84>`_
+
+- `commit 11b7a37d for v2.3
+  <https://github.com/zephyrproject-rtos/zephyr/pull/23821/commits/11b7a37d9a0b438270421b224221d91929843de4>`_
+
+- `NCC-ZEP report`_ (NCC-ZEP-031)
+
+.. _NCC-ZEP report: https://research.nccgroup.com/2020/05/26/research-report-zephyr-and-mcuboot-security-assessment
 
 CVE-2020-10063
 --------------
 
-Under embargo until 2020/05/25
+Remote Denial of Service in CoAP Option Parsing Due To Integer
+Overflow
+
+A remote adversary with the ability to send arbitrary CoAP packets to
+be parsed by Zephyr is able to cause a denial of service.
+
+This has been fixed in master for v2.3.
+
+- `CVE-2020-10063 <http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-10063>`_
+
+- `Zephyr project bug tracker ZEPSEC-55
+  <https://zephyrprojectsec.atlassian.net/browse/ZEPSEC-55>`_
+
+- `PR24435 fix in master for v2.3
+  <https://github.com/zephyrproject-rtos/zephyr/pull/24435>`_
+
+- `PR24531 fix for branch from v2.2
+  <https://github.com/zephyrproject-rtos/zephyr/pull/24531>`_
+
+- `PR24535 fix for branch from v2.1
+  <https://github.com/zephyrproject-rtos/zephyr/pull/24535>`_
+
+- `PR24530 fix for branch from v1.14
+  <https://github.com/zephyrproject-rtos/zephyr/pull/24530>`_
+
+- `NCC-ZEP report`_ (NCC-ZEP-032)
 
 CVE-2020-10067
 --------------
@@ -398,3 +473,105 @@ This has been fixed in releases v1.14.2, and v2.2.0.
 
 - `PR23239 fix for v2.2.0
   <https://github.com/zephyrproject-rtos/zephyr/pull/23239>`_
+
+CVE-2020-10068
+--------------
+
+Zephyr Bluetooth DLE duplicate requests vulnerability
+
+In the Zephyr project Bluetooth subsystem, certain duplicate and
+back-to-back packets can cause incorrect behavior, resulting in a
+denial of service.
+
+This has been fixed in branches for v1.14.0, v2.2.0, and will be
+included in v2.3.0.
+
+- `CVE-2020-10068 <http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-10068>`_
+
+- `Zephyr project bug tracker ZEPSEC-78
+  <https://zephyrprojectsec.atlassian.net/browse/ZEPSEC-78>`_
+
+- `PR23707 fix for v2.3 (split driver)
+  <https://github.com/zephyrproject-rtos/zephyr/pull/23707>`_
+
+- `PR23708 fix for v2.3 (legacy driver)
+  <https://github.com/zephyrproject-rtos/zephyr/pull/23708>`_
+
+- `PR23091 fix for branch from v1.14.0
+  <https://github.com/zephyrproject-rtos/zephyr/pull/23091>`_
+
+- `PR23964 fix for v2.2.0
+  <https://github.com/zephyrproject-rtos/zephyr/pull/23964>`_
+
+CVE-2020-10069
+--------------
+
+Zephyr Bluetooth unchecked packet data results in denial of service
+
+An unchecked parameter in bluetooth data can result in an assertion
+failure, or division by zero, resulting in a denial of service attack.
+
+This has been fixed in branches for v1.14.0, v2.2.0, and will be
+included in v2.3.0.
+
+- `CVE-2020-10069 <http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-10069>`_
+
+- `Zephyr project bug tracker ZEPSEC-81
+  <https://zephyrprojectsec.atlassian.net/browse/ZEPSEC-81>`_
+
+- `PR23705 fix for v2.3 (split driver)
+  <https://github.com/zephyrproject-rtos/zephyr/pull/23705>`_
+
+- `PR23706 fix for v2.3 (legacy driver)
+  <https://github.com/zephyrproject-rtos/zephyr/pull/23706>`_
+
+- `PR23091 fix for branch from v1.14.0
+  <https://github.com/zephyrproject-rtos/zephyr/pull/23091>`_
+
+- `PR23963 fix for branch from v2.2.0
+  <https://github.com/zephyrproject-rtos/zephyr/pull/23963>`_
+
+CVE-2020-10070
+--------------
+
+MQTT buffer overflow on receive buffer
+
+In the Zephyr Project MQTT code, improper bounds checking can result
+in memory corruption and possibly remote code execution.  NCC-ZEP-031
+
+When calculating the packet length, arithmetic overflow can result in
+accepting a receive buffer larger than the available buffer space,
+resulting in user data being written beyond this buffer.
+
+This has been fixed in master for v2.3.
+
+- `CVE-2020-10070 <http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-10070>`_
+
+- `Zephyr project bug tracker ZEPSEC-85
+  <https://zephyrprojectsec.atlassian.net/browse/ZEPSEC-85>`_
+
+- `commit 0b39cbf3 for v2.3
+  <https://github.com/zephyrproject-rtos/zephyr/pull/23821/commits/0b39cbf3c01d7feec9d0dd7cc7e0e374b6113542>`_
+
+- `NCC-ZEP report`_ (NCC-ZEP-031)
+
+CVE-2020-10071
+--------------
+
+Insufficient publish message length validation in MQTT
+
+The Zephyr MQTT parsing code performs insufficient checking of the
+length field on publish messages, allowing a buffer overflow and
+potentially remote code execution. NCC-ZEP-031
+
+This has been fixed in master for v2.3.
+
+- `CVE-2020-10071 <http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-10071>`_
+
+- `Zephyr project bug tracker ZEPSEC-86
+  <https://zephyrprojectsec.atlassian.net/browse/ZEPSEC-86>`_
+
+- `commit 989c4713 fix for v2.3
+  <https://github.com/zephyrproject-rtos/zephyr/pull/23821/commits/989c4713ba429aa5105fe476b4d629718f3e6082>`_
+
+- `NCC-ZEP report`_ (NCC-ZEP-031)

drivers/clock_control/Kconfig.nrf

@@ -46,9 +46,14 @@ config CLOCK_CONTROL_NRF_K32SRC_EXT_FULL_SWING
 endchoice
 
 config CLOCK_CONTROL_NRF_K32SRC_RC_CALIBRATION
-	bool
+	bool "Enable LF clock calibration"
 	depends on !SOC_SERIES_NRF91X
+	default n if BOARD_NRF5340PDK_NRF5340_CPUAPP || BOARD_NRF5340PDK_NRF5340_CPUAPPNS
 	default y if CLOCK_CONTROL_NRF_K32SRC_RC
+	help
+	  If calibration is disabled when RC is used for low frequency clock then
+	  accuracy of the low frequency clock will degrade. Disable on your own
+	  risk.
 
 if CLOCK_CONTROL_NRF_K32SRC_RC_CALIBRATION
 

drivers/timer/stm32_lptim_timer.c

@@ -30,13 +30,15 @@
 /* nb of LPTIM counter unit per kernel tick  */
 #define COUNT_PER_TICK (LPTIM_CLOCK / CONFIG_SYS_CLOCK_TICKS_PER_SEC)
 
+/* minimum nb of clock cycles to have to set autoreload register correctly */
+#define LPTIM_GUARD_VALUE 2
+
 /* A 32bit value cannot exceed 0xFFFFFFFF/LPTIM_TIMEBASE counting cycles.
  * This is for example about of 65000 x 2000ms when clocked by LSI
  */
 static u32_t accumulated_lptim_cnt;
 
 static struct k_spinlock lock;
-volatile u8_t  lptim_fired;
 
 static void lptim_irq_handler(struct device *unused)
 {
@@ -51,13 +53,6 @@ static void lptim_irq_handler(struct device *unused)
 		/* do not change ARR yet, z_clock_announce will do */
 		LL_LPTIM_ClearFLAG_ARRM(LPTIM1);
 
-		if (lptim_fired) {
-			lptim_fired = 0;
-#if defined(LPTIM_CR_COUNTRST)
-			LL_LPTIM_ResetCounter(LPTIM1);
-#endif
-		}
-
 		/* increase the total nb of autoreload count
 		 * used in the z_timer_cycle_get_32() function.
 		 * Reading the CNT register gives a reliable value
@@ -147,7 +142,6 @@ int z_clock_driver_init(struct device *device)
 	LL_LPTIM_ClearFlag_ARROK(LPTIM1);
 
 	accumulated_lptim_cnt = 0;
-	lptim_fired = 0;
 
 	/* Enable the LPTIM1 counter */
 	LL_LPTIM_Enable(LPTIM1);
@@ -183,11 +177,6 @@ void z_clock_set_timeout(s32_t ticks, bool idle)
 		return;
 	}
 
-	/* ARROK bit validates previous write operation to ARR register */
-	while (LL_LPTIM_IsActiveFlag_ARROK(LPTIM1) == 0) {
-	}
-	LL_LPTIM_ClearFlag_ARROK(LPTIM1);
-
 	if (ticks == K_TICKS_FOREVER) {
 		/* disable LPTIM */
 		LL_APB1_GRP1_ForceReset(LL_APB1_GRP1_PERIPH_LPTIM1);
@@ -217,6 +206,17 @@ void z_clock_set_timeout(s32_t ticks, bool idle)
 		lp_time = LL_LPTIM_GetCounter(LPTIM1);
 	}
 
+	u32_t autoreload = LL_LPTIM_GetAutoReload(LPTIM1);
+
+	if (LL_LPTIM_IsActiveFlag_ARRM(LPTIM1)
+	    || ((autoreload - lp_time) < LPTIM_GUARD_VALUE)) {
+		/* interrupt happens or happens soon.
+		 * It's impossible to set autoreload value.
+		 */
+		k_spin_unlock(&lock, key);
+		return;
+	}
+
 	/* calculate the next arr value (cannot exceed 16bit)
 	 * adjust the next ARR match value to align on Ticks
 	 * from the current counter value to first next Tick
@@ -232,16 +232,19 @@ void z_clock_set_timeout(s32_t ticks, bool idle)
 	if (next_arr > LPTIM_TIMEBASE) {
 		next_arr = LPTIM_TIMEBASE;
 	}
-
-	/* If we are close to the roll over of the ticker counter
-	 * change current tick so it can be compared with buffer.
-	 * If this event got outdated fire interrupt right now,
-	 * else schedule it normally.
+	/* The new autoreload value must be LPTIM_GUARD_VALUE clock cycles
+	 * after current lptim to make sure we don't miss
+	 * an autoreload interrupt
 	 */
-	if (next_arr <= ((lp_time + 1) & LPTIM_TIMEBASE)) {
-		NVIC_SetPendingIRQ(LPTIM1_IRQn);
-		lptim_fired = 1;
+	else if (next_arr < (lp_time + LPTIM_GUARD_VALUE)) {
+		next_arr = lp_time + LPTIM_GUARD_VALUE;
 	}
+
+	/* ARROK bit validates previous write operation to ARR register */
+	while (LL_LPTIM_IsActiveFlag_ARROK(LPTIM1) == 0) {
+	}
+	LL_LPTIM_ClearFlag_ARROK(LPTIM1);
+
 	/* run timer and wait for the reload match */
 	LL_LPTIM_SetAutoReload(LPTIM1, next_arr);
 

samples/drivers/peci/README.rst

@@ -6,7 +6,7 @@ PECI Interface
 Overview
 ********
 
-This sample demonstrates how to use the :ref:`PECI API <peci>`.
+This sample demonstrates how to use the :ref:`PECI API <peci_api>`.
 Callbacks are registered that will write to the console indicating PECI events.
 These events indicate PECI host interaction.
 

samples/subsys/usb/mass/src/main.c

@@ -15,6 +15,7 @@
 LOG_MODULE_REGISTER(main);
 
 #if CONFIG_DISK_ACCESS_FLASH
+#include <storage/flash_map.h>
 #if CONFIG_FAT_FILESYSTEM_ELM
 #include <fs/fs.h>
 #include <ff.h>
@@ -25,12 +26,12 @@ static FATFS fat_fs;
 static struct fs_mount_t fs_mnt = {
 	.type = FS_FATFS,
 	.mnt_point = FATFS_MNTP,
+	.storage_dev = (void *)FLASH_AREA_ID(storage),
 	.fs_data = &fat_fs,
 };
 #elif CONFIG_FILE_SYSTEM_LITTLEFS
 #include <fs/fs.h>
 #include <fs/littlefs.h>
-#include <storage/flash_map.h>
 
 FS_LITTLEFS_DECLARE_DEFAULT_CONFIG(storage);
 static struct fs_mount_t fs_mnt = {

subsys/net/lib/sockets/sockets.c

@@ -51,7 +51,7 @@ static inline void *get_sock_vtable(
 				      (const struct fd_op_vtable **)vtable);
 
 #ifdef CONFIG_USERSPACE
-	if (z_is_in_user_syscall()) {
+	if (ctx != NULL && z_is_in_user_syscall()) {
 		struct z_object *zo;
 		int ret;
 

tests/drivers/clock_control/clock_control_api/nrf_lfclk_rc.conf

@@ -1,2 +1,3 @@
 CONFIG_ZTEST=y
 CONFIG_CLOCK_CONTROL_NRF_K32SRC_RC=y
+CONFIG_CLOCK_CONTROL_NRF_K32SRC_RC_CALIBRATION=n

tests/kernel/timer/timer_api/src/main.c

@@ -28,6 +28,27 @@ struct timer_data {
  */
 #define INEXACT_MS_CONVERT ((CONFIG_SYS_CLOCK_TICKS_PER_SEC % MSEC_PER_SEC) != 0)
 
+#if CONFIG_NRF_RTC_TIMER
+/* On Nordic SOCs one or both of the tick and busy-wait clocks may
+ * derive from sources that have slews that sum to +/- 13%.
+ */
+#define BUSY_TICK_SLEW_PPM 130000U
+#else
+/* On other platforms assume the clocks are perfectly aligned. */
+#define BUSY_TICK_SLEW_PPM 0U
+#endif
+#define PPM_DIVISOR 1000000U
+
+/* If the tick clock is faster or slower than the busywait clock the
+ * remaining time for a partially elapsed timer in ticks will be
+ * larger or smaller than expected by a value that depends on the slew
+ * between the two clocks.  Produce a maximum error for a given
+ * duration in microseconds.
+ */
+#define BUSY_SLEW_THRESHOLD_TICKS(_us)				\
+	k_us_to_ticks_ceil32((_us) * BUSY_TICK_SLEW_PPM		\
+			     / PPM_DIVISOR)
+
 static void duration_expire(struct k_timer *timer);
 static void duration_stop(struct k_timer *timer);
 
@@ -174,12 +195,18 @@ void test_timer_period_0(void)
 {
 	init_timer_data();
 	/** TESTPOINT: set period 0 */
-	k_timer_start(&period0_timer, K_MSEC(DURATION), K_NO_WAIT);
+	k_timer_start(&period0_timer,
+		      K_TICKS(k_ms_to_ticks_floor32(DURATION)
+			      - BUSY_SLEW_THRESHOLD_TICKS(DURATION
+							  * USEC_PER_MSEC)),
+		      K_NO_WAIT);
 	tdata.timestamp = k_uptime_get();
 	busy_wait_ms(DURATION + 1);
 
 	/** TESTPOINT: ensure it is one-short timer */
-	TIMER_ASSERT(tdata.expire_cnt == 1, &period0_timer);
+	TIMER_ASSERT((tdata.expire_cnt == 1)
+		     || (INEXACT_MS_CONVERT
+			 && (tdata.expire_cnt == 0)), &period0_timer);
 	TIMER_ASSERT(tdata.stop_cnt == 0, &period0_timer);
 
 	/* cleanup environemtn */
@@ -541,6 +568,8 @@ void test_timer_remaining(void)
 	u32_t dur_ticks = k_ms_to_ticks_ceil32(DURATION);
 	u32_t target_rem_ticks = k_ms_to_ticks_ceil32(DURATION / 2) + 1;
 	u32_t rem_ms, rem_ticks, exp_ticks;
+	s32_t delta_ticks;
+	u32_t slew_ticks;
 	u64_t now;
 
 	k_usleep(1); /* align to tick */
@@ -566,16 +595,14 @@ void test_timer_remaining(void)
 	/* Half the value of DURATION in ticks may not be the value of
 	 * half DURATION in ticks, when DURATION/2 is not an integer
 	 * multiple of ticks, so target_rem_ticks is used rather than
-	 * dur_ticks/2.
-	 *
-	 * Also if the tick clock is faster or slower than the
-	 * busywait clock the remaining time in ticks will be larger
-	 * or smaller than expected, so relax the tolerance.  3 ticks
-	 * variance has been observed on hardware where the busywait
-	 * clock is 0.7% slow and the 32 KiHz tick clock is 60 ppm
-	 * fast relative to a stable external clock.
+	 * dur_ticks/2.  Also set a threshold based on expected clock
+	 * skew.
 	 */
-	zassert_true(abs((s32_t)(rem_ticks - target_rem_ticks)) <= 3, NULL);
+	delta_ticks = (s32_t)(rem_ticks - target_rem_ticks);
+	slew_ticks = BUSY_SLEW_THRESHOLD_TICKS(DURATION * USEC_PER_MSEC / 2U);
+	zassert_true(abs(delta_ticks) <= MAX(slew_ticks, 1U),
+		     "tick/busy slew %d larger than test threshold %u",
+		     delta_ticks, slew_ticks);
 
 	/* Note +1 tick precision: even though we're calcluating in
 	 * ticks, we're waiting in k_busy_wait(), not for a timer
@@ -632,7 +659,11 @@ void test_timeout_abs(void)
 	cap2_ticks = k_uptime_ticks();
 	k_timer_stop(&remain_timer);
 	zassert_true((cap_ticks + rem_ticks + 1 == exp_ticks)
-		     || (rem_ticks + cap2_ticks + 1 == exp_ticks),
+		     || (rem_ticks + cap2_ticks + 1 == exp_ticks)
+		     || (INEXACT_MS_CONVERT
+			 && (cap_ticks + rem_ticks == exp_ticks))
+		     || (INEXACT_MS_CONVERT
+			 && (rem_ticks + cap2_ticks == exp_ticks)),
 		     NULL);
 #endif
 }