Up until now, Zephyr has patched Kconfig to use the last 'default' with
a satisfied condition, instead of the first one. I'm not sure why the
patch was added (it predates Kconfiglib), but I suspect it's related to
Kconfig.defconfig files.
There are at least three problems with the patch:
1. It's inconsistent with how Kconfig works in other projects, which
might confuse newcomers.
2. Due to oversights, earlier 'range' properties are still preferred,
as well as earlier 'default' properties on choices.
In addition to being inconsistent, this makes it impossible to
override 'range' properties and choice 'default' properties if the
base definition of the symbol/choice already has 'range'/'default'
properties.
I've seen errors caused by the inconsistency, and I suspect there
are more.
3. A fork of Kconfiglib that adds the patch needs to be maintained.
Get rid of the patch and go back to standard Kconfig behavior, as
follows:
1. Include the Kconfig.defconfig files first instead of last in
Kconfig.zephyr.
2. Include boards/Kconfig and arch/<arch>/Kconfig first instead of
last in arch/Kconfig.
3. Include arch/<arch>/soc/*/Kconfig first instead of last in
arch/<arch>/Kconfig.
4. Swap a few other 'source's to preserve behavior for some scattered
symbols with multiple definitions.
Swap 'source's in some no-op cases too, where it might match the
intent.
5. Reverse the defaults on symbol definitions that have more than one
default.
Skip defaults that are mutually exclusive, e.g. where each default
has an 'if <some board>' condition. They are already safe.
6. Remove the prefer-later-defaults patch from Kconfiglib.
Testing was done with a Python script that lists all Kconfig
symbols/choices with multiple defaults, along with a whitelist of fixed
symbols. The script also verifies that there are no "unreachable"
defaults hidden by defaults without conditions
As an additional test, zephyr/.config was generated before and after the
change for several samples and checked to be identical (after sorting).
This commit includes some default-related cleanups as well:
- Simplify some symbol definitions, e.g. where a default has 'if FOO'
when the symbol already has 'depends on FOO'.
- Remove some redundant 'default ""' for string symbols. This is the
implicit default.
Piggyback fixes for swapped ranges on BT_L2CAP_RX_MTU and
BT_L2CAP_TX_MTU (caused by confusing inconsistency).
Piggyback some fixes for style nits too, e.g. unindented help texts.
Signed-off-by: Ulf Magnusson <Ulf.Magnusson@nordicsemi.no>
Being stopped or not should not be a blocker on these settings (real
hardware can get these settings configured while not being in rx/tx
mode for instance).
Fixes#8528
Signed-off-by: Tomasz Bursztyka <tomasz.bursztyka@linux.intel.com>
Bool symbols implicitly default to 'n'.
A 'default n' can make sense e.g. in a Kconfig.defconfig file, if you
want to override a 'default y' on the base definition of the symbol. It
isn't used like that on any of these symbols though, and is
inconsistent.
This will make the auto-generated Kconfig documentation have "No
defaults. Implicitly defaults to n." as well, which is clearer than
'default n if ...'
Signed-off-by: Ulf Magnusson <Ulf.Magnusson@nordicsemi.no>
This makes it easier to distinguish them from "true" undefined symbols.
Internally, all int/hex literals are treated as undefined symbols, which
always get their name as their value. The C tools work the same way.
The plan is to turn references to undefined Kconfig symbols into an
error later.
Signed-off-by: Ulf Magnusson <Ulf.Magnusson@nordicsemi.no>
These symbols were removed by commit 4e8f29f319 ("gpio: Refactor the
mcux gpio driver to use dts"). The settings should come from DTS now.
Signed-off-by: Ulf Magnusson <Ulf.Magnusson@nordicsemi.no>
ACK frames are handled on hardware level, so let's expose this
capability in order to avoid L2 waiting for these.
Signed-off-by: Tomasz Bursztyka <tomasz.bursztyka@linux.intel.com>
L2 could take advantage of such hardware capability, when supported by
the device. This is also required for OpenThread.
Fixes#5714
Signed-off-by: Tomasz Bursztyka <tomasz.bursztyka@linux.intel.com>
Adds dts bindings for the mcr20a wireless transceiver. The frdm_k64f
board supports the mcr20a via an Arduino shield, therefore the dts node
is added to the board dts. The kw2xd is a SiP and thus the mcr20a dts
node is added to the soc dts.
The networking samples using prj_frdm_k64f_mcr20a.conf have been broken
since the refactoring of the mcux gpio driver to dts in commit
4e8f29f319. The sample is now fixed.
Signed-off-by: Maureen Helm <maureen.helm@nxp.com>
And adding support for GPIO CS as well.
It looks like the driver could benefit from centralizing all SPI access
into a unique function, the protocol does not seem too convoluted to do
so, like CC2520 or CC1200.
Signed-off-by: Tomasz Bursztyka <tomasz.bursztyka@linux.intel.com>
tx_bufs/tx_count and rx_bufs/rx_count can be hold in another dedicated
structure, thus reducing the number of parameters to transceive. This
permits to avoid using the stack when calling transceive.
Since we saved parameters, we can expose back the struct device pointer,
to stay consistent with other device driver APIs.
Fixes#5839
Signed-off-by: Tomasz Bursztyka <tomasz.bursztyka@linux.intel.com>
Move IP address settings from net_if to separate structs.
This is needed for VLAN support.
Signed-off-by: Jukka Rissanen <jukka.rissanen@linux.intel.com>
Fix Kconfig help sections and add spacing to be consistent across all
Kconfig file. In a previous run we missed a few.
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
Driver is 'Busy' can be a warning message which can be enabled with
minimum debug level CONFIG_SYS_LOG_IEEE802154_DRIVER_LEVEL=2.
Signed-off-by: Ravi kumar Veeramally <ravikumar.veeramally@linux.intel.com>
CC1200 is a sub-ghz chip supporting 6 ISM & SRD bands: 169, 433, 470,
868, 915 and 920 MHz, with features dedicated to IEEE 802.15.4(g).
Current driver enables CC1200 against actual IEEE 802.15.4 Soft-MAC. 'g'
version support in the Soft-MAC will follow later.
The chip itself is closer to a bare metal radio modem than to a usual
15.4 chip: up to the user to provide the right RF settings for the
carrier band. Such settings can be generaten through TI's SmartRF tool.
Hopefully, for channel selection, this driver will be clever enough to
compute the proper register change without any special input from the
user. This will work for all the bands supported by the chip.
Signed-off-by: Tomasz Bursztyka <tomasz.bursztyka@linux.intel.com>
Old reference on driver's specific raw mode was still lurking around.
Removing those.
Fixes#5270
Signed-off-by: Tomasz Bursztyka <tomasz.bursztyka@linux.intel.com>
A very old reference to former net stack was still lurking around.
Removing it.
Taking the opportunity to clear up dependencies.
Signed-off-by: Tomasz Bursztyka <tomasz.bursztyka@linux.intel.com>
This fixes a regression from
https://github.com/zephyrproject-rtos/zephyr/pull/5018
The ieee802154 driver wouldn't build because nrf drivers/ieee802154
depends on the nordic ext drivers to build.
Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
- Renaming NET_L2_RAW_CHANNEL to NET_RAW_MODE
- Create a generic IEEE 802.15.4 raw mode for drivers
- Modify the IEEE 802.15.4 drivers so it passes the packet unmodified,
up to code using that mode to apply the necessary changes on the
received net_pkt according to their needs
- Modify wpanusb/wpan_serial relevantly
Fixes#5004
Signed-off-by: Tomasz Bursztyka <tomasz.bursztyka@linux.intel.com>
The interrupt priority on KW41Z is from 0..3. The value of 0x80 is
invalid, so lets set it to 0 for now as all the other interrupt
priorities default to 0 right now.
Signed-off-by: Kumar Gala <kumar.gala@linaro.org>
Added conditionally enabled event state tracing support.
Needed for enhanced debug visibility of tight timed events where
normal print debug messages affect the timing of things. This is a
simple buffer that allows post analysis via gdb of what sequencer
events occurred.
Signed-off-by: David Leach <david.leach@nxp.com>
Signed-off-by: Kumar Gala <kumar.gala@linaro.org>
- Removed some debug output and changed the level of others to reduce
the amount of information logged. The reason is that some of this is
causing false positive distractions.
- Removed enabling of FILTER error IRQ events. It isn't needed and is
only informational.
- Changed frame control AR bit inspection to use native retrieval
routine.
- Addressed some coding style issues.
Signed-off-by: David Leach <david.leach@nxp.com>
Changed the logic to reset the sequencer when a RX filter
failure has been detected. This also disables the RX timer
until the next watermark detection.
Signed-off-by: David Leach <david.leach@nxp.com>
- Reworked the driver logic around TX/RX to correctly handle the
expectations of the underlying 802.15.4 hardware IP.
- Fixed a problem with TX always reporting an error to the stack
which resulted in constant retries.
- Fixed bug in RX to TX transition which would occasionally cause the
driver to error the TX.
- Changed RX logic to ensure that invalid RX frames were not passed up
the stack.
- Simplified hardware timer usage to only use TMR3.
- Added RX watermark and TMR3 support to fix a hardware problem where
the hw IP can get stuck on a receive in noisy environments.
- Modified samples/net/echo_client and echo_server kw41z project config
files to provide enanced debug visibility into stacks and threads.
Signed-off-by: David Leach <david.leach@nxp.com>
Introducing CMake is an important step in a larger effort to make
Zephyr easy to use for application developers working on different
platforms with different development environment needs.
Simplified, this change retains Kconfig as-is, and replaces all
Makefiles with CMakeLists.txt. The DSL-like Make language that KBuild
offers is replaced by a set of CMake extentions. These extentions have
either provided simple one-to-one translations of KBuild features or
introduced new concepts that replace KBuild concepts.
This is a breaking change for existing test infrastructure and build
scripts that are maintained out-of-tree. But for FW itself, no porting
should be necessary.
For users that just want to continue their work with minimal
disruption the following should suffice:
Install CMake 3.8.2+
Port any out-of-tree Makefiles to CMake.
Learn the absolute minimum about the new command line interface:
$ cd samples/hello_world
$ mkdir build && cd build
$ cmake -DBOARD=nrf52_pca10040 ..
$ cd build
$ make
PR: zephyrproject-rtos#4692
docs: http://docs.zephyrproject.org/getting_started/getting_started.html
Signed-off-by: Sebastian Boe <sebastian.boe@nordicsemi.no>
Some "random" drivers are not drivers at all: they just implement the
function `sys_rand32_get()`. Move those to a random subsystem in
preparation for a reorganization.
Signed-off-by: Leandro Pereira <leandro.pereira@intel.com>
Waiting for tx to complete should timeout after 10ms
instead of blocking forever in case ack is not received.
Signed-off-by: Kamil Sroka <kamil.sroka@nordicsemi.no>
Issue a error message, if the _mcr20a_read_reg fails.
Do not execute SPI burst read/write if the buffer is too small.
Unlock mutex if set_pan_id, set_short_addr or set_ieee_addr
fail.
Force abort of the sequence when the higher level changes the channel
even though a T or TR sequence is in progress.
Signed-off-by: Johann Fischer <j.fischer@phytec.de>
No need to send FCS bytes as the monitor_15_4 is configured to not
expect them. If we change the monitor_15_4 to use them, then we would
need to put correct values into these two FCS bytes.
So cleanest solution is not to send FCS bytes at all.
Signed-off-by: Jukka Rissanen <jukka.rissanen@linux.intel.com>
set_ieee_addr, set_short_addr and set_pan_id are now unused by L2, so
removing their exposure through the radio API.
Signed-off-by: Tomasz Bursztyka <tomasz.bursztyka@linux.intel.com>
Further support will need work per-driver basis, as soon as the L2 will
be able to make usage of such support.
Signed-off-by: Tomasz Bursztyka <tomasz.bursztyka@linux.intel.com>
802.15.4 is the networking hardware available in KW41Z SoC (and
supported by Zephyr). So, if networking in enabled, automatically
select the corresponding driver. This is similar to how frdm_k64f
automatically selects Ethernet driver, 96b_carbon selects BLE/IPSP
drivers, etc. (But we apply it on SoC level to reuse across the
boards.)
Signed-off-by: Paul Sokolovsky <paul.sokolovsky@linaro.org>
The stack address was incorrectly specified when stack usage
was being debugged. This caused compiler to emit this warning
drivers/ieee802154/ieee802154_cc2520.c:1136:16: warning:
dereferencing type-punned pointer will break strict-aliasing
rules [-Wstrict-aliasing]
((struct cc2520_context *)(&__device_cc2520))->
^
Signed-off-by: Jukka Rissanen <jukka.rissanen@linux.intel.com>
