This change marks each instance of the 'api' as 'static const'.
The rationale is that 'api' is used for declaring internal
module interfaces and is not intended to be modified at runtime.
By using 'static const', we ensure immutability, leading to usage of only
.rodata and a reduction in the .data area.
Signed-off-by: Pisit Sawangvonganan <pisit@ndrsolution.com>
rand32.h does not make much sense, since the random subsystem
provides more APIs than just getting a random 32 bits value.
Rename it to random.h and get consistently with other
subsystems.
Signed-off-by: Flavio Ceolin <flavio.ceolin@intel.com>
A little refactoring that simplifies dealing with nanosecond timestamp
values in packets and further decouples calling code from PTP:
Benefits:
- simplifies calling code by removing redundant conversions.
- prepares for removing PTP dependencies from net_pkt.
Signed-off-by: Florian Grandel <fgrandel@code-for-humans.de>
Replaces the previous approach to define bands via hardware capabilities
by the standard conforming concept of channel pages.
In the short term this allows us to correctly calculate the PHY specific
symbol rate and several parameters that directly depend from the symbol
rate and were previously not being correctly calculated for some of the
drivers whose channel pages could not be represented previously:
* We now support sub-nanosecond precision symbol rates for UWB. Rounding
errors are being minimized by switching from a divide-then-multiply
approach to a multiply-then-divide approach.
* UWB HRP: symbol rate depends on channel page specific preamble symbol
rate which again requires the pulse repetition value to be known
* Several MAC timings are being corrected based on the now correctly
calculated symbol rates, namely aTurnaroundTime, aUnitBackoffPeriod,
aBaseSuperframeDuration.
In the long term, this change unlocks such highly promising functional
areas as UWB ranging and SUN-PHY channel hopping in the SubG area (plus
of course any other PHY specific feature).
Signed-off-by: Florian Grandel <fgrandel@code-for-humans.de>
Acknowledgment is mandatory if legitimately requested by the package's
"ACK requested" flag. The L2 layer will have to ensure that compliant
ACK packages will always be sent out automatically as required by the
standard.
For IEEE 802.15.4 compliance, the NET_L2_IEEE802154_ACK_REPLY option is
therefore being deprecated.
Signed-off-by: Florian Grandel <fgrandel@code-for-humans.de>
The method ieee802154_radio_handle_ack() does not belong to the
PHY/radio layer but to the L2 layer. It is a callback called from the
radio layer into the L2 layer and to be implemented by all L2 stacks.
This is the same pattern as is used for ieee802154_init(). The
'_radio_' infix in this function is therefore confusing and
conceptually wrong.
This change fixes the naming inconsistency and extensively documents
its rationale.
It is assumed that the change can be made without prior deprecation of the
existing method as in the rare cases where users have implemented custom
radio drivers these will break in obvious ways and can easily be fixed.
Nevertheless such a rename would not be justified on its own if it were
not for an important conceptual reason:
The renamed function represents a generic "inversion-of-control" pattern
which will become important in the TSCH context: It allows for clean
separation of concerns between the PHY/radio driver layer and the
MAC/L2 layer even in situations where the radio driver needs to be
involved for performance or deterministic timing reasons. This
"inversion-of-control" pattern can be applied to negotiate timing
sensitive reception and transmission windows, it let's the L2 layer
deterministically timestamp information elements just-in-time with
internal radio timer counter values, etc.
Signed-off-by: Florian Grandel <fgrandel@code-for-humans.de>
The RSSI value in net_pkt (net_pkt_cb_ieee802154.rssi) was used
inconsistently across drivers. Some drivers did cast a signed dBm value
directly to net_pkt's unsigned byte value. Others were assigning the
negative value of the signed dBm value and again others were offsetting
and stretching the signed dBm value linearly onto the full unsigned byte
range.
This change standardizes net_pkt's rssi attribute to represent RSSI on
the RX path as an unsigned integer ranging from 0 (–174 dBm) to 254 (80
dBm) and lets 255 represent an "unknown RSSI" (IEEE 802.15.4-2020,
section 6.16.2.8). On the TX path the rssi attribute will always be
zero. Out-of-range values will be truncated to max/min values.
The change also introduces conversion functions to and from signed dBm
values and introduces these consistently to all existing call sites. The
"unknown RSSI" value is represented as INT16_MIN in this case.
In some cases drivers had to be changed to calculate dBm values from
internal hardware specific representations.
The conversion functions are fully covered by unit tests.
Fixes: #58494
Signed-off-by: Florian Grandel <fgrandel@code-for-humans.de>
`spi_is_ready` function is being deprecated in favor of
`spi_is_ready_dt` so let's replace the old usage in the tree.
Signed-off-by: Bartosz Bilas <bartosz.bilas@hotmail.com>
Several IEEE 802154 drivers allocated RX packets from the TX pool.
This may seem like a minor problem at first sight but it may become
problematic if the pool is used to distinguish package types as is the
case in some code paths, e.g. for packet priority or determination of
the packet buffer pool.
This bug also has the potential of starving the TX pool capacity which
even may make devices vulnerable to DoS attacks as sending may be
prohibited by addressing enough RX packets to a device to let it run out
of TX capacity.
Fixes: #51261
Signed-off-by: Florian Grandel <jerico.dev@gmail.com>
In order to bring consistency in-tree, migrate all drivers to the new
prefix <zephyr/...>. Note that the conversion has been scripted, refer
to #45388 for more details.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
Simplify driver implementation by using spi_dt_spec. Note that driver
has 2 SPI configurations, identical except the speed. For this reason,
the slow config is still kept in RAM and copied from the one obtained
via the SPI dt_spec macros. A better solution would be to have macros
that allow to override the SPI frequency, but this can be improved
later. Most internal helpers have been adjusted to accept a device
reference to make SPI (and future GPIO) transition easier.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
Driver has dedicated workqueue for IRQ processing.
Submit work to dedicated workqueue intead of system workqueue.
It also fixes driver functionality when NET_TC_TX_COUNT is set to 0.
Signed-off-by: Johann Fischer <johann.fischer@nordicsemi.no>
Replace all existing deprecated API with the recommended alternative.
Be aware that this does not address architectural errors in the use
of the work API.
Signed-off-by: Peter Bigot <peter.bigot@nordicsemi.no>
Now that device_api attribute is unmodified at runtime, as well as all
the other attributes, it is possible to switch all device driver
instance to be constant.
A coccinelle rule is used for this:
@r_const_dev_1
disable optional_qualifier
@
@@
-struct device *
+const struct device *
@r_const_dev_2
disable optional_qualifier
@
@@
-struct device * const
+const struct device *
Fixes#27399
Signed-off-by: Tomasz Bursztyka <tomasz.bursztyka@linux.intel.com>
Since commit 5963ebaf33
("drivers: spi: CS configuration through devicetree")
the SPI GPIO CS flags are obtained from DT,
but the patch series has missed the necessary changes
for the ieee802154_dw1000 driver and decawave_dwm1001_dev board.
Signed-off-by: Johann Fischer <j.fischer@phytec.de>
Add initial support for Decawave DW1000
IEEE 802.15.4-2011 UWB transceiver.
Driver has basic functionality. Additional functions such
as reading out timestamps and delayed TX were implemented
for test purposes, but also require support in the 802154
subsystem.
Register, sub-register, and defaults defines in the file
ieee802154_dw1000_regs.h are taken from the Decawave's
DW1000 driver for the Mynewt OS.
Signed-off-by: Johann Fischer <j.fischer@phytec.de>
