Skip to content

GitLab

Switch branch/tag
  1. 11 Nov, 2021 2 commits
  3. 10 Nov, 2021 1 commit
    • Robert Lubos's avatar
      samples: net: http_get: Update root CA certificate · b7954c99
      Robert Lubos authored 
      
The root CA used so far (GlobalSign R2) is about to expire soon
(December 2021) and Google have switched to a new certificate, signed by
GlobalSign R1 (valid until 2028). Therefore we need to replace the
root CA used by the sample to the new one, in order to establish secure
connection to with google.com.

Additionally, the new certificate chain sent by Google is larger again,
so it's needed to increase mbed TLS max content length parameter in
order to process it correctly. This also implies an increase in heap
usage, so increase the heap size as well.
Signed-off-by: default avatarRobert Lubos <robert.lubos@nordicsemi.no>
      b7954c99
  5. 09 Nov, 2021 4 commits
  7. 08 Nov, 2021 2 commits
  9. 05 Nov, 2021 4 commits
  11. 29 Oct, 2021 1 commit
    • Andy Ross's avatar
      kernel/sched: Fix race with thread return values · 6a851f1f
      Andy Ross authored 
      There was a brief (but seen in practice on real apps on real
hardware!) race with the switch-based z_swap() implementation.  The
thread return value was being initialized to -EAGAIN after the
enclosing lock had been released.  But that lock is supposed to be
atomic with the thread suspend.

This opened a window for another racing thread to come by and "wake
up" our pending thread (which is fine on its own), set its return
value (e.g. to 0 for success) and then have that value clobbered by
the thread continuing to suspend itself outside the lock.

Melodramatic aside: I continue to hate this
arch_thread_return_value_set() API; it needs to die.  At best it's a
mild optimization on a handful of architectures (e.g. x86 implements
it by writing to the EAX register save slot in the context block).
Asynchronous APIs are almost always worse than synchronous ones, and
in this case it's an async operation that races against literal
context switch code that can't use t...
      6a851f1f
  13. 26 Oct, 2021 2 commits
  15. 25 Oct, 2021 1 commit
  17. 22 Oct, 2021 2 commits
    • Martin Jäger's avatar
      task_wdt: ensure hw wdt is started before being fed · 6f11b2d7
      Martin Jäger authored 
      
If a fallback hardware watchdog is used, it is fed together with the
task watchdog in task_wdt_feed. However, the hardware watchdog was
not yet set up before the first call to task_wdt_feed.

This commit fixes the order of wdt_setup and task_wdt_feed calls.

Fixes #39523
Signed-off-by: default avatarMartin Jäger <martin@libre.solar>
      6f11b2d7
    • Henrik Brix Andersen's avatar
      drivers: can: flexcan: fix timing parameter limits · 5166ff9f
      Henrik Brix Andersen authored 
      
Fix the limits for the timing parameter calculations.

The lower limit for the phase_seg2 value is wrongly specified as 1 to 7,
but 1U is substracted before writing it to the CTRL1:PSEG2 register
field. This results in register field values between 0 and 6, but 0 is
an invalid value for the PSEG2 register field.

The upper limits for several of the timing parameters are wrong as well,
but this does not result in invalid register field values being
calculated. It can, however, result in not being able to meet CAN timing
requirements.

The confusion in specifying the limits likely stems from the timing
calculations and timing limits using the "physical" values, whereas the
registers fields all use the "physical" value minus 1. When the
datasheet says "The valid programmable values are 1-7", the
corresponding limits should be set to 2 to 8 to take the "minus 1" into
account.

Fixes: #39541
Signed-off-by: default avatarHenrik Brix Andersen <hebad@vestas.com>
      5166ff9f
  19. 20 Oct, 2021 1 commit
  21. 19 Oct, 2021 2 commits
    • Jakub Rzeszutko's avatar
      shell: fix assert in panic mode · b7571100
      Jakub Rzeszutko authored 
      
In panic mode, the function: z_shell_fprintf is expected to be
called from an interrupt context. Therefore, the dedicated assert
cannot be checked in this case.

Fixes #38612
Signed-off-by: default avatarJakub Rzeszutko <jakub.rzeszutko@nordicsemi.no>
      b7571100
    • Torsten Rasmussen's avatar
      cmake: CMake compile features support · 61730131
      Torsten Rasmussen authored 
      
Fixes: #36558 #32577

This commit introduces CMAKE_C_COMPILE_FEATURES and
CMAKE_CXX_COMPILE_FEATURES.

This allows users to use the `target_compile_features()` in their own
code.

In Zephyr, the CMAKE_C/CXX_COMPILE_FEATURES are defined based on the
compiler and the Kconfig / CSTD setting.
Doing so ensures that a user compiling Zephyr with c99 and specifies
`target_compile_features(<target> ... c_std_11)` will get an error.
And similar if building Zephyr with C++ support and c++11, but testing
for `target_compile_features(<target> ... cxx_std_17)`.

For example in the C++ case, the user must ensure that Zephyr is
compiled with C++17, that is: CPLUSPLUS=y and STD_CPP17=y, in which case
the CMAKE_CXX_COMPILE_FEATURES will contain support for C++17 and thus
the `target_compile_features(<target> ... cxx_std_17)` will succeed.
Signed-off-by: default avatarTorsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
      61730131
  23. 18 Oct, 2021 2 commits
    • Maureen Helm's avatar
      soc: arm: Configure serial driver init priority for NXP SoCs · 5455bf4b
      Maureen Helm authored 
      
Configures the default serial driver initialization priority for NXP
SoCs to ensure that serial drivers initialize after clock control
drivers.
Signed-off-by: default avatarMaureen Helm <maureen.helm@intel.com>
      5455bf4b
    • Maureen Helm's avatar
      drivers: serial: Refactor drivers to use shared init priority Kconfig · c65645cc
      Maureen Helm authored 
      
Refactors all of the serial drivers to use a shared driver class
initialization priority configuration, CONFIG_SERIAL_INIT_PRIORITY, to
allow configuring serial drivers separately from other devices. This is
similar to other driver classes like I2C and SPI.

The default is set to CONFIG_KERNEL_INIT_PRIORITY_DEVICE to preserve the
existing default initialization priority for most drivers. The one
exception is uart_lpc11u6x.c which previously used
CONFIG_KERNEL_INIT_PRIORITY_OBJECTS.

This change was motivated by an issue on the frdm_k64f board where the
serial driver was incorrectly initialized before the clock control
driver.
Signed-off-by: default avatarMaureen Helm <maureen.helm@intel.com>
      c65645cc
  25. 17 Oct, 2021 6 commits
  27. 16 Oct, 2021 1 commit
  29. 15 Oct, 2021 6 commits
  31. 12 Oct, 2021 3 commits