The parameter doc string for hda was incorrect as the parameters
had been updated to take the IP base address, block size, and stream id
instead. Updates all doc string comments to account for the change.
Signed-off-by: Tom Burdick <thomas.burdick@intel.com>
The DMA API contract specifies that start/stop may be called multiple
times. Prior to adding power management this was perfectly fine as it was.
In adding power management, there are additional side effects that can
cause issues. Instead check the state of the channel prior to start/stop
and do nothing if already in the desired state.
Signed-off-by: Tom Burdick <thomas.burdick@intel.com>
Ensures that the documented behavior of the API is met by implementations
through testing. By calling stop on a stopped channel the expectation is no
error occurs and is checked.
Calling start after a channel has been started is difficult to test for
as there is transfer timing involved. A once shot transfer may have
completed and the channel transition to an inactive state by itself by
the time the second start call is performed. This isn't supported by at
least gpdma today and isn't documented behaviorally so should not be
tested.
Signed-off-by: Tom Burdick <thomas.burdick@intel.com>
The DMA API expects drivers in effect to maintain their own internal
state of channels. A channel that is already started may have dma_start
called on it again without effect. A channel that is already stopped may
have dma_stop called on it without effect.
In essence, start and stop are expected to act like events a DMA channels
finite state machine reacts to and if the state is already at the desired
one then nothing is to be done and no error has occurred.
Signed-off-by: Tom Burdick <thomas.burdick@intel.com>
Currently, the s32z270dc2_r52 board only supports running on RAM,
so samples or tests watchdogs that perform SoC reset will not produce
results. Set the build only for these samples and tests until the
reset SoC function is supported.
Signed-off-by: Quang Bui Trong <quang.buitrong@nxp.com>
`<fcntl.h>`, `<net/if.h>`, and `<netinet/tcp.h>` were missing
`extern "C" { .. }"` which is required to avoid C++ name
mangling.
Signed-off-by: Chris Friedt <cfriedt@meta.com>
Add a trivial suite that simply ensures headers exist and that
they supply standard symbols and constants.
These tests are intended to be ordered exactly as the respective
feature appears in the respective specification at
https://pubs.opengroup.org/onlinepubs/9699919799
Over time, as POSIX support improves, we can enable additional
checks.
If `CONFIG_POSIX_API=n`, then we simply ensure that the header
can be included, that constants and structures exist, including
the existence of required fields in each structure.
We check that a constant exist, by comparing its value against
an arbitrary number. If the constant does not exist, it would
of course be a compile error.
```
zassert_not_equal(-1, POLLIN);
```
We check that a structure contains required fields by
comparing the field offset with an arbitrary number. If
the field does not exist, of course, there would be a
compile error.
```
zassert_not_equal(-1, offsetof(struct pollfd, fd));
```
For non-scalar constants, we simply attempt to assign
a value to the specific type:
```
struct in6_addr any6 = IN6ADDR_ANY_INIT;
```
If `CONFIG_POSIX_API=y`, then we additionally check that required
functions are non-NULL (limited to what is currently supported in
Zephyr).
```
zassert_not_null(pthread_create);
```
Note: functional verification tests should be done outside of this
test suite.
Signed-off-by: Chris Friedt <cfriedt@meta.com>
The POSIX spec requires that `SO_LINGER`, `SO_RCVLOWAT`,
and `SO_SNDLOWAT`, and `SOMAXCONN` are defined in
`<sys/socket.h>`. However, most of the existing socket
options and related constants are defined in
`<zephyr/net/socket.h>`.
For now, we'll co-locate them. It would be
good to properly namespace things.
Additionally, a no-op for setsockopt for `SO_LINGER` to
make things Just Work (TM) for now.
Signed-off-by: Chris Friedt <cfriedt@meta.com>
The `<netdb.h>` header typically defines `NI_MAXSERV` as a
reasonable default buffer size to use in applications that
use `getnameinfo()` to query a service name.
Most GNU and BSD systems define it by default so provide
it as a convenience so applications and 3rd-party libraries
do not encounter a compile error.
Signed-off-by: Chris Friedt <cfriedt@meta.com>
The spec requires `<sys/socket.h>` to declare
struct linger. Define it so that applications
and libraries do not get compile errors when
building against Zephyr.
Signed-off-by: Chris Friedt <cfriedt@meta.com>
The `FIONREAD` ioctl is usually used to query how many bytes
are available to read immediately from a specific file
descriptor. It's quite useful.
Define it here so that it can be used by applications.
Signed-off-by: Chris Friedt <cfriedt@meta.com>
Constants like `EAI_SYSTEM` should be defined in `<netdb.h>`
according to the spec.
In Zephyr, they should be defined via appropriately
namespaced z-variants (currently `DNS_EAI_SYSTEM` and so on).
Signed-off-by: Chris Friedt <cfriedt@meta.com>
The spec requires that `in_addr_t` and `in_port_t` are both
defined when `<arpa/inet.h>` is included.
They were added to `<netinet/in.h>` in the previous commit.
Signed-off-by: Chris Friedt <cfriedt@meta.com>
The `<sys/ioctl.h>` header never actually declared
the `ioctl(2)` function prototype, so this fixes that.
Signed-off-by: Chris Friedt <cfriedt@meta.com>
The networking subsystem defines a rather large amount of POSIX
prototypes. However, it's done in a somewhat subversive way via
```
CONFIG_NET_SOCKETS_POSIX_NAMES
```
This option should be removed (or moved to POSIX) and the
networking implementations should be properly namespaced.
With that, the POSIX interface for network-related functions
can simply be a thin wrapper around the z-namespaced variants,
where applicable, or proper POSIX functions should actually
be moved to `lib/posix`.
This will also require a better solution to testing network
functionality on `native_posix` though. The ability to run
those tests and the supposed incompatibility between
`CONFIG_ARCH_POSIX` and `CONFIG_POSIX_API` was the main
motivation for adding `CONFIG_NET_SOCKETS_POSIX_NAMES`.
Eventually, with proper namespacing, these preprocessor
guards against redefining the same symbols can be
removed.
Signed-off-by: Chris Friedt <cfriedt@meta.com>
Although the eventfd API is not (yet) a part of POSIX,
it's pretty well ubiquitous on POSIX systems now.
Enable it by default when `CONFIG_POSIX_API=y`.
Signed-off-by: Chris Friedt <cfriedt@meta.com>
The `getopt()` function is part of POSIX and should be
available when applications choose to enable general POSIX
API support.
Signed-off-by: Chris Friedt <cfriedt@meta.com>
With the `<zephyr/posix/...> prefix, it became
exponentially more difficult to integrate 3rd-party
libraries that depend on the POSIX API.
Standard POSIX headers should be available in standard
include paths - and that should most certainly the case
when `CONFIG_POSIX_API=y`.
With this change:
* When `CONFIG_POSIX_API=y`
- applications have explicitly chosen to use
POSIX APIs.
- all standard POSIX includes are in the default
include path.
* When `CONFIG_POSIX_API=n`
- applications *may* include POSIX headers
explicitly with the namespaced prefix
- e.g. `#include <zephyr/posix/unistd.h>`
- individual Kconfig options can be used to
enable POSIX features selectively, such as
`getopt` or `eventfd`.
Signed-off-by: Chris Friedt <cfriedt@meta.com>
When transceiver is overload on reception a frame can be stored on
the internal buffer without processing a frame start interrupt. The
frame will complete and system will received a interrupt and signal
receiver thread with an isr_status equal to 0x2c.
The current implementation process one flag at time and it may hang
when status is 0x2c. This issue can be reproduced using two nodes
where one perform a regular TX broadcast and tThe other one should
be wait for frames. The receptor should run on debug mode and system
should be started normally. The problem happens when pressing CTRL+C
on the debugger, which will cause system to stop. However, the
transceiver still can receive one last frame. After a few transmission
user can continue application and a isr_status of 0x2c will be visible
if CONFIG_IEEE802154_DRIVER_LOG_DEBUG is enabled.
This fixes the current issue by processing all RF2XX_TRX_END events.
Signed-off-by: Gerson Fernando Budke <nandojve@gmail.com>
Since SHIELD_DIRS gets added to DTS_ROOT in dts.cmake, any shield
directories are also places where we look for bindings by default.
This feature is not used in upstream Zephyr, but it is supported,
so document it.
Suggested-by: Jamie McCrae <jamie.mccrae@nordicsemi.no>
Signed-off-by: Marti Bolivar <marti.bolivar@nordicsemi.no>
We have established a convention that the zephyr, prefix in property
names indicates some sort of zephyr-specific extension to a common
binding, or a zephyr-specific driver configuration knob. We also have
established a convention that compatibles which begin with "zephyr,"
are specific to our operating system. Document these facts.
Signed-off-by: Marti Bolivar <marti.bolivar@nordicsemi.no>
Splitting up the 'general rules' section into subsections makes it
possible to link directly to a particular rule. This is useful when
pointing out an issue during code review, sharing with another
colleague, etc. Adding a local table of contents makes the page
skimmable (it's buried too deeply in the toctree to have sections
listed in the HTML sidebar).
Signed-off-by: Marti Bolivar <marti.bolivar@nordicsemi.no>
Now that this information is in a separate page instead of buried at
the bottom of the DT bindings documentation, it's more convenient to
split it up into subsections for readability.
Signed-off-by: Marti Bolivar <marti.bolivar@nordicsemi.no>
There's been some confusion about what we mean by hardware
description. We're really talking about the user-facing inputs that
need to be configured per SoC, application, etc. It's fine to do
things like use ifdeffery on a CMSIS header in an aarch32 support file
to decide if the current target has some feature, for instance -- that
sort of thing doesn't *have* to come from DT.
At the same time, we don't want to encourage vendor-specific hardware
configuration languages from creeping into upstream zephyr, so keep
the language strong in an effort to avoid that misinterpretation.
Signed-off-by: Marti Bolivar <marti.bolivar@nordicsemi.no>
Phandles, specifier spaces, and cell names are simultaneously
extremely common and woefully underdocumented. Address that by:
- reworking our existing documentation on these subjects in
bindings-syntax.rst, fixing missing information in the
property syntax template as well
- adding a standalone guide which describes how all the pieces
fit together, providing a bridge for the gap between
DTS/bindings and C APIs
My goal is not to eventually make this a comprehensive place
where *all* specifier spaces are documented. It would be better (more
scalable, more discoverable) to improve the individual API pages to
cover the devicetree-related conventions that apply in each case.
That's a problem for someone else and another day, but we do need a
few concrete references in the DTS guides to keep the motivation
clear.
Signed-off-by: Marti Bolivar <marti.bolivar@nordicsemi.no>
The devicetree introduction page is too big. Split it up to improve
readability and restore maintainability. Add more section headers and
do some other rearranging now that it's more convenient to do so.
Signed-off-by: Marti Bolivar <marti.bolivar@nordicsemi.no>
Generic improvements:
- clean up some language that needs adjusting
- rename some section headers and reorder some content to
improve readability
- add a table of contents to ease search
Signed-off-by: Marti Bolivar <marti.bolivar@nordicsemi.no>
The bindings.rst page has gotten too big. Split it up into
sub-documents to improve readability and restore maintainability.
As part of this effort, move the /zephyr,user node documentation into
its own page in the guide. This page has proven extremely difficult
for users to spot in my experience, and it's meant as a convenience,
so let's make the documentation more convenient as well.
Signed-off-by: Marti Bolivar <marti.bolivar@nordicsemi.no>
Use the macro as defined by the
include/zephyr/dt-bindings/dma/stm32_dma.h to configure the
dma channel.
Signed-off-by: Francois Ramu <francois.ramu@st.com>
Use the macro as defined by the
include/zephyr/dt-bindings/dma/stm32_dma.h to configure the
dma channel.
Use the STM32_DMA_PERIPH_TX or STM32_DMA_PERIPH_RX value.
Signed-off-by: Francois Ramu <francois.ramu@st.com>
Defines DMA macro to help channel configuration and feature for the stm32
devices. Add one default value for most of the usecases
of peripheral DMA settings.
Signed-off-by: Francois Ramu <francois.ramu@st.com>
Add check preventing Out of band access. There are tests trying to
access out of band handle like:
test_sink_invalid_ref and test_source_invalid_ref trying to access
handle 99.
Signed-off-by: Andrei Emeltchenko <andrei.emeltchenko@intel.com>
Adds the BT_AUDIO_METADATA_TYPE_AUDIO_STATE and
BT_AUDIO_METADATA_TYPE_BROADCAST_IMMEDIATE metadata types from
the LE Audio assigned numbers document.
Signed-off-by: Emil Gydesen <emil.gydesen@nordicsemi.no>
