Introducing PPP dialup features to enable e.g. usage of nrf9160
based board as a dialup modem for transferring ip data over PPP
(e.g. windows dial up), i.e. usage of Zephyr PPP as a server for
providing MTU/MRU, IP address and DNS addresses for a PC:
- PPP LCP MRU option (configurable)
- PPP server: IPCP ip and dns address peer options to enable
providing IP and DNS addresses for PPP peer.
Signed-off-by: Jani Hirsimäki <jani.hirsimaki@nordicsemi.no>
Use a combination of fixed-clock and fixed-factor-clock devicetree
nodes for describing the clock dividers/multipliers of the NXP Kinetis
System Clock Generator (SCG) present in the KE1xF SoC series.
Signed-off-by: Henrik Brix Andersen <hebad@vestas.com>
Split ARM and ARM64 architectures.
Details:
- CONFIG_ARM64 is decoupled from CONFIG_ARM (not a subset anymore)
- Arch and include AArch64 files are in a dedicated directory
(arch/arm64 and include/arch/arm64)
- AArch64 boards and SoC are moved to soc/arm64 and boards/arm64
- AArch64-specific DTS files are moved to dts/arm64
- The A72 support for the bcm_vk/viper board is moved in the
boards/bcm_vk/viper directory
Signed-off-by: Carlo Caione <ccaione@baylibre.com>
Return -ENOSYS when implementation is missing and -ENOTSUP if the
feature is not supported. Those are 2 things. Missing implementation
(-ENOSYS) means that the driver is lacking support for the feature,
-ENOTSUP means we have an implementation but some parameters or
conditions makes the request unsupported.
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
Return -ENOSYS when implementation is missing and -ENOTSUP if the
feature is not supported. Those are 2 things. Missing implementation
(-ENOSYS) means that the driver is lacking support for the feature,
-ENOTSUP means we have an implementation but some parameters or
conditions makes the request unsupported.
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
Return -ENOSYS when implementation is missing and -ENOTSUP if the
feature is not supported. Those are 2 things. Missing implementation
(-ENOSYS) means that the driver is lacking support for the feature,
-ENOTSUP means we have an implementation but some parameters or
conditions makes the request unsupported.
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
Return -ENOSYS when implementation is missing and -ENOTSUP if the
feature is not supported. Those are 2 things. Missing implementation
(-ENOSYS) means that the driver is lacking support for the feature,
-ENOTSUP means we have an implementation but some parameters or
conditions makes the request unsupported.
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
Return -ENOSYS when implementation is missing and -ENOTSUP if the
feature is not supported. Those are 2 things. Missing implementation
(-ENOSYS) means that the driver is lacking support for the feature,
-ENOTSUP means we have an implementation but some parameters or
conditions makes the request unsupported.
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
Return -ENOSYS when implementation is missing and -ENOTSUP if the
feature is not supported. Those are 2 things. Missing implementation
(-ENOSYS) means that the driver is lacking support for the feature,
-ENOTSUP means we have an implementation but some parameters or
conditions makes the request unsupported.
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
Return -ENOSYS when implementation is missing and -ENOTSUP if the
feature is not supported. Those are 2 things. Missing implementation
(-ENOSYS) means that the driver is lacking support for the feature,
-ENOTSUP means we have an implementation but some parameters or
conditions makes the request unsupported.
Also, explicitly check for NULL.
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
Return -ENOSYS when implementation is missing and -ENOTSUP if the
feature is not supported. Those are 2 things. Missing implementation
(-ENOSYS) means that the driver is lacking support for the feature,
-ENOTSUP means we have an implementation but some parameters or
conditions makes the request unsupported.
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
Return -ENOSYS when implementation is missing and -ENOTSUP if the
feature is not supported. Those are 2 things. Missing implementation
(-ENOSYS) means that the driver is lacking support for the feature,
-ENOTSUP means we have an implementation but some parameters or
conditions makes the request unsupported.
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
Return -ENOSYS when implementation is missing and -ENOTSUP if the
feature is not supported. Those are 2 things. Missing implementation
(-ENOSYS) means that the driver is lacking support for the feature,
-ENOTSUP means we have an implementation but some parameters or
conditions makes the request unsupported.
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
The commit adds macro that, using the DTS identifier, allows to
extract flash area label from DTS.
Signed-off-by: Dominik Ermel <dominik.ermel@nordicsemi.no>
Write this in terms of DT_GPIO_CTLR_BY_IDX instead of the lower level
DT_PHANDLE_BY_IDX for clarity and parallelism with things like
DT_SPI_DEV_CS_GPIOS_PIN, which is written using DT_GPIO_PIN_BY_IDX
instead of DT_PHA_BY_IDX.
Signed-off-by: Martí Bolívar <marti.bolivar@nordicsemi.no>
The API is deprecated as it was decided to build in the flash protection
service into write and erase procedures.
This is solution chosen for fix following issue:
When two or more threads writes to flash device it is
possible that flash protection will be enabled by one of
threads despite another thread(s) still needs it disabled.
fixes#3127
Signed-off-by: Andrzej Puzdrowski <andrzej.puzdrowski@nordicsemi.no>
Made write_protection handler not mandatory.
flash_write_protection_set() becomes no-operation.
If write_protection handler is provided by the driver implementation
it will be called within flash_writ() and flash_erase().
Signed-off-by: Andrzej Puzdrowski <andrzej.puzdrowski@nordicsemi.no>
This is a helper which allows you to skip the intricacies of instance
numbers to express the intent of "give me a random enabled node with
this compatible; I don't care which one".
Signed-off-by: Martí Bolívar <marti.bolivar@nordicsemi.no>
Our description of 'compat' parameters is all over the place.
Make it consistent by picking one.
Signed-off-by: Martí Bolívar <marti.bolivar@nordicsemi.no>
Unified define used for handling sparc case in static and
runtime packaging. Reworked macro for storing argument in
static packaging.
Signed-off-by: Krzysztof Chruscinski <krzysztof.chruscinski@nordicsemi.no>
Added parameter to CBPRINTF_STATIC_PACKAGE which indicates buffer
alignment offset compared to CBPRINTF_PACKAGE_ALIGNMENT. When offset
is set to 0, macro assumes that input buffer is aligned to
CBPRINTF_PACKAGE_ALIGNMENT. When offset is positive, macro assumes
that buffer address is shifted by given number of bytes to
CBPRINTF_PACKAGE_ALIGNMENT alignment.
Extended cbprintf_package to use len argument as alignment offset
indicator when calculating length only (package pointer is null).
Features are not available for xtensa platform which seems to
require 16 byte alignment from the package. It is only an assumption
due to lack of the documentation and may be fixed in the future.
Feature allows to avoid unnecessary padding when package is part of
a message and preceeded by a header of a known size. For example,
message header on 32 bit architecture has 12 bytes, long doubles are
not used so cbprintf requires 8 byte alignment. Without alignment
offset indicator, package containing just a string with one argument
would need 4 byte padding after the header and 4 byte padding after
the package. Message would be 32 bytes long. With alignment offset
indication both paddings are not needed and message is only 24 bytes
long.
Signed-off-by: Krzysztof Chruscinski <krzysztof.chruscinski@nordicsemi.no>
