The cmsis implementations of osMutex was trying to inspect internal
k_mutex state (the owner and lock count) in the process of trying to
acquire the lock. This is unfixably racy, by definition other
contexts will be trying to do the same on the unsynchronized data.
As far as I can tell, the only purpose was to be able to synthesize
osMutex's specified error behavior, which we can do with the existing
return codes from k_mutex_lock(). Add similar logic to osSemaphore,
which didn't have the race but was likewise abusing access to kernel
internals.
Signed-off-by: Andy Ross <andyross@google.com>
The "limit" field of struct k_sem was in use in two places in the BTLE
host code, in one it was being used as a duplicate placeholder for the
"iso_max_num" field received in read_buffer_size_v2_complete[1]. In
another, it was just being tested for zero[2].
Those are pretty clear abuses of internal data, provide minimal value
beyond a few bytes of memory in struct bt_dev_le, and in any case
won't work with zync, where that field doesn't have the same name and
may not even exist depending on app configuration.
Copy the limit value into the struct where it belongs, and use it from
there.
[1] I strongly suspect there is a bug lurking there if the semaphore
maximum is being used to implement the kind of "packet buffer" this
code looks like. Calling k_sem_give() on a "full" semaphore WILL NOT
BLOCK. It will just drop the increment on the floor and return
synchronously. Semaphores aren't msgqs or ringbuffers! But disabling
the max value feature in zync does not result in test failures, so
maybe this usage is safe.
[2] Again, this seems suspicious; a valid k_sem should never have a
zero in that field. Presumably this is really a test for "is
initialized", and so implies there's a mixed up initialization path
somewhere?
Signed-off-by: Andy Ross <andyross@google.com>
The bridge subsystem was written with a ETH_BRIDGE_INITIALIZER that
assumed it could initialize a k_mutex with a zero-filled initializer.
That never worked. Unlike semaphores, mutexes have always required a
runtime call to k_mutex_init(). What happened instead is that
k_mutex_un/lock() returned error codes, which were ignored by the code
here. So no locking was happening.
This was discovered while migrating to zync, where an attempt to
unlock an unlocked mutex is a panic condition (and where zero-filled
initializers are legal, but represent an unfair semaphore and not a
mutex, so deadlock correctly).
Signed-off-by: Andy Ross <andyross@google.com>
This is a public API for the subsystem, can be called from app
context, unlocks the local k_mutex on one of its three exit paths, and
it's quite clear that nothing ever locks that mutex!
The code used to work because k_mutex simply returned an error if you
tried to unlock an unlocked object. Now zync will panic (when
CONFIG_ZYNC_VALIDATE=y) if you try that.
Signed-off-by: Andy Ross <andyross@google.com>
These were never being initialized by the test, leaving an embedded
k_mutex as bare memory. That used to work (I guess?), it doesn't with
k_zync.
Signed-off-by: Andy Ross <andyross@google.com>
This test case will call k_sem_give() twice and expect both to be
received by k_sem_take(), yet the semaphore is initialized with a
maximum count of one!
The reason this worked was an undocumented misfeature of k_sem: if
k_sem_take() was called on a semaphore with a pended thread, it would
wake up that thread synchronously instead of incrementing the count.
So you could call it once to wake up the thread and again to queue the
count and not overflow. The problem is that this is a priority bug (a
high priority runnable thread should have the chance to run and call
k_sem_take() before a low priority thread that got woken).
Zync corrects that, and so needs to have two slots if you want two
semaphore events.
Signed-off-by: Andy Ross <andyross@google.com>
Init result is stored as an 8-bit unsigned integer, so let's use
uint8_t. Docs have been clarified as well.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
Formatting in the file was inconsistent, results obtained using
clang-format (80 cols), with some minor tweaks.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
- Align to 80cols
- Fix some incorrect `@p` usages
- Use `@ref foo` to let Doxygen generate references to structs instead
of using <tt>...</tt>
- Use `@ref struct.field` to reference struct fields
- Use Markdown notation for literals
- use func_name()/MACRO_NAME() to let Doxygen generate references
automatically without `@ref`
- Fix some minor typos/formatting issues
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
struct pm_device was incorrectly hidden from docs, as well as
pm_device_action_cb_t and pm_device_action_failed_cb_t.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
struct device.pm was not exposed in the docs, make it visible to Doxygen
and document it is conditional to CONFIG_PM_DEVICE=y.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
The input parameter is a device identifier, not a name. Some macros are
used for all type of devices, DT and non-DT, so adjusted documentation
to be more precise where appropriated.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
Some Doxygen groups do not belong to a specific header, they are used to
group multiple other sub-groups defined in other headers. For this
purpose we have the groups.dox file, there's no need to use device.h for
that.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
Zephyrs Host has by default enabled automatic resume of advertising
in case of disconnection when peripheral role is enabled.
The feature becomes a bit problematic in case of multirole usage.
For example assume a use case where a device is working as peripheral
and central, where it may establish single connection for each role.
In case there are two connections established and connection in
central role is dropped by peer, Host will automatically resume
advertising. After that an application can resume scanning, e.g.
in disconnected callback. That should not happen.
If one of connections was used for central role, it should not
be stolen by Host to run peripheral role. Host should verify
if a disconnected connection role was peripheral and then resume
advertising.
This approach will not break backward compatibility and change
correct resume behavior. What more, Host will follow an application
decisions about use of connection objects.
Signed-off-by: Piotr Pryga <piotr.pryga@nordicsemi.no>
Add the testcase for running the test of the
stm32 eeprom driver on stm32 platforms like the nucleo_l152re
or nucleo_l073rz boards.
Signed-off-by: Francois Ramu <francois.ramu@st.com>
Doxygen docs for a macro need to be placed together with the macro being
documented (unless using `@def`).
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
Documentation for STM32*_PINMUX macros was incorrectly placed above the
macro, so it was in practice documenting the next macro (e.g.
STM32_MODE_SHIFT).
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
Since Doxygen 1.9.5 @ref enum::FIELD references will not work. Use the
`#FIELD` notation instead. Since enums place all of its entries to the
global namespace, adding the enum only adds redundant information
Doxygen can figure out on its own.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
Even though we use Doxygen 1.9.4, config file was never updated for it.
Changed made by `doxygen -u doc/zephyr.doxyfile.in`.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
Add MEC172x full duplex qmspi driver version to support full
duplex transfers as expected by the Zephyr spi driver model.
On every spi clock we transmit one bit and receive one bit.
This driver will work with Zephyr SPI NOR driver.
Signed-off-by: Jay Vasanth <jay.vasanth@microchip.com>
updated dts variables naming (hyphen instead of underscore).
moved all properties in microchip ldma yaml to a separate include file,
these properties will be common with the (to be added)
full duplex spi driver.
Signed-off-by: Jay Vasanth <jay.vasanth@microchip.com>
The include <zephyr/kernel.h> is missing from eeprom driver,
causing build error. This is fixing it like PR # 51246 or #51220.
Signed-off-by: Francois Ramu <francois.ramu@st.com>
The `audio init` should only initialize the audio (BAP)
stack. Furthermore, given that the `bt init` may do more
than just calling `bt_enable` it is generally for the best,
and more future proof, to let that command be the exclusive
way of calling `bt_enable` in the shell.
Signed-off-by: Emil Gydesen <emil.gydesen@nordicsemi.no>
It was possible to enter a state where setting the QoS
for a source stream after having released a sink stream
as the unicast client would cause a segmentation error.
This issue is related to how the unicast shell is using
the unicast group.
A fix has been added for it, and a check for
whether or not `audio init` (to register the needed
callback) has been added. This check has also been added
for the broadcast sink.
Signed-off-by: Emil Gydesen <emil.gydesen@nordicsemi.no>
The phys property was not considered during initialization of the
driver config, so that the transceiver was not enabled properly
in case it has an enable/standby pin.
Signed-off-by: Martin Jäger <martin@libre.solar>
CI tests were failing due to a recent change to zassume_true()
implementation.
While the test case is still skipped when assumption fails, but it is
now causing the final execution result to fail.
zassume_true() was replaced by ztest_test_skip() combined with
a conditional 'if' statement to get the required effect.
Signed-off-by: Ahmed Moheb <ahmed.moheb@nordicsemi.no>
Include the correct header file. This was uncovered due to
a recent change where zephyr/kernel.h include was removed
from init.h
Signed-off-by: Mahesh Mahadevan <mahesh.mahadevan@nxp.com>
If user has not specified any DNS servers in
CONFIG_DNS_SERVER_IP_ADDRESSES, then the DNS resolver will not be
initialized properly. So fix this by always calling dns_resolve_init()
so that DNS mutex get properly initialized.
Signed-off-by: Jukka Rissanen <jukka.rissanen@linux.intel.com>
Use z_user_to_copy() instead of directly writing to the user provided
pointer to validate that the user has write permission to underlying
memory location.
It is important to verify the memory not only for reads, but also for
writes, as otherwise the function can be abused by usermode code to
write to privileged read/write, unprivileged read-only memory partition.
Signed-off-by: Tomasz Moń <tomasz.mon@nordicsemi.no>
Adds proper support for having more than one PDU pool for the advertising
PDUs (to save memory)
- Introduces lll_adv_aux_data_init, lll_adv_aux_scan_rsp_alloc and
lll_adv_sync_data_init to indicate if the PDU is a primary/legacy PDU
or secondary/auxillary PDU
- Scan response PDUs are initialized later, since the correct pool to draw
from depends on whether the advertising is extended or legacy
Signed-off-by: Troels Nilsson <trnn@demant.com>
The device_service shell was missing the capability to list devices
registered in the EARLY init level.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
Not all C compilers understands how to use the address of a return
value as an argument to a function call. At least not our compiler.
Fix the issue by adding a variable to hold the converted value
before passing it to the function call.
Signed-off-by: Kim Sekkelund <ksek@oticon.com>
This fixes the output below by moving the closing bracket to "<Security
type (optional: valid only for secure SSIDs)>" after the enumeration of
security types "0:None, 1:PSK, 2:PSK-256, 3:SAE".
Fixes:
uart:~$ wifi
wifi - Wi-Fi commands
Subcommands:
connect :Connect to a Wi-Fi AP
"<SSID>"
<channel number (optional), 0 means all>
<PSK (optional: valid only for secure SSIDs)>
<Security type (optional: valid only for secure SSIDs)>
v----------------------^
0:None, 1:PSK, 2:PSK-256, 3:SAE
(...)
Signed-off-by: Gaël PORTAY <gael.portay@gmail.com>
Return to line after the first parameter to:
- have the second parameter in a single line (not splitted) and
- start every parameters from a brand new line (easier to read)
Signed-off-by: Gaël PORTAY <gael.portay@gmail.com>
This fixes the output below by adding the missing closing bracket to
"<MFP (optional): 0:Disable, 1:Optional, 2:Required":
Fixes:
uart:~$ wifi
wifi - Wi-Fi commands
Subcommands:
connect :Connect to a Wi-Fi AP
"<SSID>"
<channel number (optional), 0 means all>
<PSK (optional: valid only for secure SSIDs)>
<Security type (optional: valid only for secure SSIDs)>
0:None, 1:PSK, 2:PSK-256, 3:SAE
<MFP (optional): 0:Disable, 1:Optional, 2:Required
^-------------------------------------------------^
(...)
Signed-off-by: Gaël PORTAY <gael.portay@gmail.com>
This fixes the output below by returning to line after "Connect to a
Wi-Fi AP":
Fixes:
uart:~$ wifi
wifi - Wi-Fi commands
Subcommands:
connect :Connect to a Wi-Fi AP"<SSID>"
^------^
<channel number (optional), 0 means all>
(...)
Signed-off-by: Gaël PORTAY <gael.portay@gmail.com>
The TWAI peripheral needs a connected CAN transceiver also for testing
in loopback mode.
As there is no board available with this configuration, at least make
sure the CAN API test is built in CI for esp32c3_devkitm.
Signed-off-by: Martin Jäger <martin@libre.solar>
The board does not have a CAN transceiver on board, but the driver
can be tested in loopback mode with the CAN RX and TX pins shorted.
Signed-off-by: Martin Jäger <martin@libre.solar>
