We now 'select I2C' and/or SPI bus in Kconfig in the sensor driver
Kconfig's so there is no need to have boards do the following:
config I2C
default y if SENSOR
config SPI
default y if SENSOR
Signed-off-by: Kumar Gala <galak@kernel.org>
Now that serial drivers are enabled based on devicetree
we need to remove any cases of them getting enabled by
Kconfig.defconfig* files as this can lead to errors.
Typically the Kconfig.defconfig* will blindly enable a
sensor and not respect the devicetree state of the serial.
Additionally we can get problems with prj.conf/defconfig
getting incorrectly overridden.
Signed-off-by: Kumar Gala <galak@kernel.org>
For all boards that have a magnetometer devicetree alias, configure the
appropriate bus (I2C or SPI) default to be enabled when the sensor
driver class is enabled. This will simplify enabling the magn_polling
sample application for these boards (and using the magnetometer in
general) because it will eliminate the need to add a bunch of
board-specific configuration overlays to the application.
Signed-off-by: Maureen Helm <maureen.helm@intel.com>
The defconfig files are just used to change defaults, not to define any
new Kconfig nodes.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
This patch adds the selection of the necessary CONFIG_*
options for allowing the use of privacy on VEGA platform
Signed-off-by: Jeanina Dragusin <ancajeanina.dragusin@nxp.com>
Per instance Kconfig symbols aren't used by the rv32m1 lpspi driver
so remove the unnecessary setting of PWM_2.
Signed-off-by: Kumar Gala <kumar.gala@linaro.org>
Convert driver to use DT_INST macros and remove related board per
instance Kconfig symbol usage.
Updated the openisa,rv32m1_vega-pinmux binding to require the label
property and updated the rv32m1.dtsi to add label properties for the
pinmux nodes.
Also update gpio_basic_api test to use DT_NODELABEL.
Signed-off-by: Kumar Gala <kumar.gala@linaro.org>
Created unit tests for the encryption and decryption functions.
Tested with the peripheral and with central_hr samples.
Due to latency of CAUv3 when used as CCM inline accelerator
only one of the PDU can be encrypted/decrypted within an
bilateral exchange M->S + S->M in a connection event.
If the RXed PDU is encrypted, the TXed PDU must be empty
with More Data if there is data in the LLL queue.
The TXed PDU will be encrypted when an empty PDU is RXed.
Signed-off-by: Cristi Caciuloiu <cristian.caciuloiu@nxp.com>
Same deal as in commit eddd98f ("kconfig: Replace some single-symbol
'if's with 'depends on'"), for all symbols defined within defconfig
files. See that commit for an explanation.
Maybe 'if's were used originally to mirror the 'if's in the main Kconfig
files, and then it got copied around by people assuming 'if' must work
differently from 'depends on'. It doesn't match in every spot at least.
Better to keep it simple and just consistently use 'depends on' when
it's a single symbol/choice I think. Helps reinforce that 'if' isn't
magic too.
Verified by printing all Kconfig menu nodes (symbols, choices, menus,
etc.) before and after the change and diffing (should show no
difference).
Signed-off-by: Ulf Magnusson <Ulf.Magnusson@nordicsemi.no>
Specific SW defined BLE LL parameters need to be set
if the user enables it on this platform. As such, conditionally
enable them directly into the defconfig.
INTMUX CH2 and CH3 are not available to be used if BT support
is enabled on Vega, because they are used internally by the
BLE SW LL
Signed-off-by: David Leach <david.leach@nxp.com>
Enable the MX25R32 SPI NOR Flash on the VEGAboard and provide board
config file for the spi_flash sample.
Signed-off-by: Karsten Koenig <karsten.koenig.030@gmail.com>
Same deal as in commit 7fdb525754 ("kconfig: Use 'default' instead of
'def_bool' in Kconfig.defconfig files"), but I hacked Kconfiglib to also
find cases where the type is given separately as e.g.
config FOO
int
default 3
Motivation (from a note in
https://docs.zephyrproject.org/latest/guides/kconfig/index.html):
For a symbol defined in multiple locations (e.g., in a
Kconfig.defconfig file in Zephyr), it is best to only give the
symbol type for the "base" definition of the symbol, and to use
'default' (instead of 'def_<type>' value) for the remaining
definitions. That way, if the base definition of the symbol is
removed, the symbol ends up without a type, which generates a
warning that points to the other definitions. That makes the extra
definitions easier to discover and remove.
It's also nice if 'def_bool' and the like turn into a semi-reliable flag
that the symbol is only defined in Kconfig.defconfig files. That might
be a sign that things could be cleaned up.
Will do a separate pass later to remove some symbols only defined in
Kconfig.defconfig files.
Signed-off-by: Ulf Magnusson <Ulf.Magnusson@nordicsemi.no>
With the upcoming riscv64 support, it is best to use "riscv" as the
subdirectory name and common symbols as riscv32 and riscv64 support
code is almost identical. Then later decide whether 32-bit or 64-bit
compilation is wanted.
Redirects for the web documentation are also included.
Then zephyrbot complained about this:
"
New files added that are not covered in CODEOWNERS:
dts/riscv/microsemi-miv.dtsi
dts/riscv/riscv32-fe310.dtsi
Please add one or more entries in the CODEOWNERS file to cover
those files
"
So I assigned them to those who created them. Feel free to readjust
as necessary.
Signed-off-by: Nicolas Pitre <npitre@baylibre.com>
Kumar Gala