If IUT is acting as a central device and peer lost bond we need
to re-pair to restore bond. PTS is not sending any WID for this
so bonding needs to be initiated implicitly by IUT.
This was affecting GAP/SEC/AUT/BV-25-C qualification test case.
Signed-off-by: Szymon Janc <szymon.janc@codecoup.pl>
boilerplate.cmake contained a comment referring to CMake 3.13.1 but
minimal required version is 3.20, so update the comment to 3.20.
Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
Change the "yes/no" value to "true/false".
Otherwise pykwalify 1.8.0 will report below errors:
- Value: 'no' for required keyword must be a boolean:
Path: '/mapping/common'>
- Value: 'yes' for required keyword must be a boolean:
Path: '/mapping/sample/mapping/name'>
Signed-off-by: Shao Ming <ming.shao@intel.com>
1.Putting the PWM_CHANNEL_X, PWM_PRESCALER_CX information
in the description.
2.Use the common definition EC_FREQ.
3.Use the common macro IT8XXX2_DT_ALT_ITEMS_LIST.
4.Stop using DRV_CONFIG, DRV_REG macro.
Signed-off-by: Ruibin Chang <Ruibin.Chang@ite.com.tw>
Fix compile warning filling 24-bit value in 3 octets using
sys_put_le32, used sys_put_le24 instead.
Signed-off-by: Vinayak Kariappa Chettimada <vich@nordicsemi.no>
Remove misplaced declaration of ll_tx_ack_put in
ull_internal.h file while it is already present in
ull_conn_internal.h.
Signed-off-by: Vinayak Kariappa Chettimada <vich@nordicsemi.no>
Users will have to include dt-bindings/spi/spi.h in order to use the
relevant flags fol this property. For instance:
...
duplex = <SPI_HALF_DUPLEX>;
....
By default all SPI device are configured to be full duplex so the
property is optional. This property makes sense only for devices that
can be configured on either modes. Which, in such case, it will need to
use DT_INST_PROP(<instance number>, duplex) macro call to retrieve the
property value. Others can fully ignore it.
Signed-off-by: Tomasz Bursztyka <tomasz.bursztyka@linux.intel.com>
HTS221 is a humidity and temperature sensor (thus HTS) that can be wired
on i2c or SPI bus. On SPI bus however, it uses the 3-wire mode, aka:
half-duplex.
Now that SPI API exposes half duplex operation, let's enable the SPI bus
on that sensor.
Let's move to a better DTS integrated driver as well, and also use
stmemsc interface.
Signed-off-by: Tomasz Bursztyka <tomasz.bursztyka@linux.intel.com>
This is meant to expose half/full duplex configuration option on regular
configuration. So far, dual/quad/octal are not exactly supported, as it
would require extensions to the SPI buffer for a full support.
So moving these modes to an extended operation attribute
(32 vs 16 bits), disabled by default.
And exposing half/full duplex configuration bit. Full duplex being the
default option.
Fixes#19134
Signed-off-by: Tomasz Bursztyka <tomasz.bursztyka@linux.intel.com>
Increase main stack size (in 128 bytes) to make these tests run
successfully on qemu_x86 platform.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
Port some drivers to the recently introduced macros to showcase its
usage and be able to do some initial testing (nRF52840).
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
It is well known that PM subsystem has never been optimized in terms of
resource usage. The situation is particularly bad in case the PM runtime
API is enabled. What this patch does is to move the responsability of PM
resource definition to the device like this:
- Device is responsible to define PM resources, using a new set of
macros: PM_DEVICE_*DEFINE().
- DEVICE_*DEFINE macro accepts a reference to the device PM state, which
can be obtained using PM_DEVICE_*REF() set of macros. This
allows device to initialize the dev->pm reference.
This method decouples a bit more PM from devices since devices just keep
a reference to the device PM state. It also means that future PM changes
will have less chances to impact all devices, but only devices that
support PM.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
The macro already mentions in the docstrings that PM is not supported:
"Invokes DEVICE_DEFINE() with no power management support".
This patch removed the PM entry from the macro and ajusts its uses.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
Define the device using DEVICE_DEFINE macro, so that a single option can
be used regardless of PM being enabled or not.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
It will unlock and unhold the CS line. Note that the lock and the CS
being hold on are 2 separate config bits, so if only one is selected
spi_release() will only apply on this configuration.
Note: this has been already the case in the controller drivers, where
there implementation of spi_release() calls
spi_context_unlock_unconditionally(). And that function always forces
the CS line to an inactive state.
Signed-off-by: Tomasz Bursztyka <tomasz.bursztyka@linux.intel.com>
Add tests for the instance based enum macros DT_INST_ENUM_IDX and
DT_INST_ENUM_IDX_OR.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
The DT_ENUM_IDX and DT_ENUM_IDX_OR macros did not have the instance
based equivalents. With them many drivers can be simplified.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
GD32F4XX requires access to SoC definitions (e.g. GD32F450) when
including library header files, so expose them at Zephyr level.
Signed-off-by: Gerard Marull-Paretas <gerard@teslabs.com>
Despite the "F4" prefix, GD32F403 is an SoC with significant differences
compared to other F4 MCUs:
- It has a completely different HAL
- It has significant hardware differences, for example, the pinctrl
mechanism uses AFIO (all others use AF)
The grouping principles applied to other similar vendors such as ST
can't be applied for GD32 due to these reasons, so the approach taken
here is to define series based on the used HAL. A different HAL likely
means that there are significant hardware differences between, e.g. F403
and F405. The vendor likely chose a confusing naming scheme, but we need
to deal with it.
Signed-off-by: Gerard Marull-Paretas <gerard@teslabs.com>
