This commit is controlling the WWDG during the Stop mode in debug.
WWDG1 is frozen while the core is in Debug mode, setting the bit
of the DBGMCU APB3 peripheral freeze register (DBGMCU_APB3FZ1)
for the stm32H7 soc devices.
Signed-off-by: Francois Ramu <francois.ramu@st.com>
Remove check if frequency is equal to zero. A value of `ODR = 0` is
explicitly allowed by manufacturer / datasheet.
This has prevented applications from using the lis2dh power-down-mode,
which is set via `ODR = 0`.
For reference see "Table 28. Data rate configuration" in datasheet p.33.
Fixes#35486.
Signed-off-by: Markus Brüx <markus.bruex@grandcentrix.net>
In case of MSIS selected as system clock source it is necessary
to set Voltage scaling (VOS) when freqency is greater than 24MHz
Signed-off-by: Alexandre Bourdiol <alexandre.bourdiol@st.com>
When MSI trimming values where set to 0,
and MSIS is used as system core clock and MSI > 4 MHz,
it causes uart to fail.
There is no need to set thoses trimming values.
So keep the default reset value. (keep ST Factory calibration)
Signed-off-by: Alexandre Bourdiol <alexandre.bourdiol@st.com>
Because on stm32u5 MSIS is the default clock after reset,
changing MSIS range means immediate frequency change.
Thus it is important to do it after flash latency change
in case of higher new frequency.
Signed-off-by: Alexandre Bourdiol <alexandre.bourdiol@st.com>
The device PM subsystem _depends_ on device, not vice-versa. Devices
only hold a reference to struct pm_device now, and initialize this
reference with the value provided in Z_DEVICE_DEFINE. This requirement
can be solved with a forward struct declaration, meaning there is no
need to include device PM headers.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
Make nrfx GPIO driver part of the PRE_KERNEL_1 initialization stage. As
a result, the GPIO driver can now be initialized before UART if
required, a device that is also initialized during PRE_KERNEL_1.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
This patch adds support for the new pinctrl API to the UART driver. The
old pin property based solution is still kept so that users have time to
transition to the new model.
Notes:
- A new property to disable RX has been introduced: disable-rx. It is no
longer possible to do it automatically depending on pin information,
since it's not available when using pinctrl.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
This patch adds support for the new pinctrl API to the UARTE driver. The
old pin property based solution is still kept so that users have time to
transition to the new model.
Notes:
- Some build assertions cannot be performed since the driver does not
have direct access to pin settings anymore. As a result user will not
be notified if HWFC is enabled but RTS/CTS pins are not configured.
- Hardware flow control can be enabled regardless of pin configuration,
it is now up to the user to configure RTS/CTS pins in DT.
- Some RX enable checks that were performed using pin information has
been replaced with a DT property that informs if RX is enabled or not.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
Add support for configuring UART/UARTE peripheral pins.
Co-authored-by: Andrzej Głąbek <andrzej.glabek@nordicsemi.no>
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
Add initial support for nRF pin controller driver. The implementation in
this patch does not yet support any peripheral. Only states
representation and basic driver functionality is introduced.
Note:
The nrf_pin_configure function has been marked as __unused since it may
not be used in certain scenarios until all peripherals are supported by
the pinctrl driver. For example, if only UART/E is supported but the
board does not enable UART, the function will never get called. However,
that board will likely have other peripherals that will gain support in
the future.
Thanks to Marti Bolivar for bindings documentation.
Co-authored-by: Marti Bolivar <marti.bolivar@nordicsemi.no>
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
commit 54907c7014
("drivers: spi: spi_context: improve support of multiple cs gpios")
added function to initialize all CS GPIOs defined in devicetree.
This function, spi_context_cs_configure_all, is intended to be
called during SPI driver initialization (POST_KERNEL init level).
It is also obvious that a SPI driver was not used at that time,
and no bus configuration (struct spi_config) is assigned to
SPI bus (spi_context.config).
The spi_context_cs_configure_all function has a homeopathic
ASSERT to validate CS levels, which causes a null pointer
dereferencing by ctx->config->operation if asserts are
enabled.
Signed-off-by: Johann Fischer <johann.fischer@nordicsemi.no>
Use the new pinctrl API to configure pins.
Since STM32F1 series require pinctrl option and required register
address is parent timer address in place of own node register address,
use PINCTRL_DT_INST_CUSTOM_REG_DEFINE in place of usual
PINCTRL_DT_INST_DEFINE for this specific series.
Additionally, remove the automatic selection of PINMUX API.
Signed-off-by: Erwan Gouriou <erwan.gouriou@linaro.org>
Use the new pinctrl API to configure pins.
Additionally, rename usb_pinctrl to usb_pcfg to better fit
new pinctrl API.
Signed-off-by: Erwan Gouriou <erwan.gouriou@linaro.org>
Use the new pinctrl API to configure pins.
Additionally, rename eth0_pins to eth0_pcfg to better fit
new pinctrl API.
Signed-off-by: Erwan Gouriou <erwan.gouriou@linaro.org>
Add initial version for STM32 pinctrl driver. Driver has been written
re-using many of the already existing parts in
drivers/pinmux/pinmux_stm32.c.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
Use nrfx_gpiote and nrfx_ppi allocators to allocate channels
at runtime instead of fixed, device-tree based allocation which
is harder to maintain.
Signed-off-by: Krzysztof Chruscinski <krzysztof.chruscinski@nordicsemi.no>
This adds :
- Generic PCIe Controller layer implementing the current PCIe API
- Generic PCIe Controller in ECAM mode driver
The Generic PCIe Controller layer provides:
- Configuration space read/write
- single bus endpoint enumerations
- Endpoint I/O, MEM & MEM64 BARs allocation
- Endpoint I/O, MEM & MEM64 BARs get & translation for drivers
The Generic PCIe Controller in ECAM mode driver provides:
- Raw DT RANGES properties into usable PCIe regions
- Configuration space read/write into ECAM config space
- PCIe regions allocation & translation
The limitations are:
- No support for PCIe prefetchable regions
- No support for PCIe bus configuration (only bus0 is supported)
- No support for multiple controllers (no domain-id in BDF)
Support has been designed to initially support Root Complexes with
Root Complex Integrated Endpoint, which was designed for Embedded
Systems with internal-only PCIe Endpoints on bus 0.
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
Replace unpacked in6_addr structures with raw buffers in net_ipv6_hdr
struct, to prevent compiler warnings about unaligned access.
Remove __packed parameter from `struct net_6lo_context` since the
structure isn't really serialized.
Signed-off-by: Robert Lubos <robert.lubos@nordicsemi.no>
Replace unpacked in_addr structures with raw buffers in net_ipv4_hdr
struct, to prevent compiler warnings about unaligned access.
Signed-off-by: Robert Lubos <robert.lubos@nordicsemi.no>
Change gpio_emul_input_set_masked_pend to log when it returns an error.
Changed all calls to gpio_emul_input_set_masked* to check the return
value.
Changed the function gpio_emul_input_set_masked_pend to apply the mask
to the provided values and not return an error if there are excess
values. In almost every call to that function, the value wasn't being
limited to bits set in the mask, so they were failing if there was more
than one gpio configured for INPUT|OUTPUT with a value of 1.
Fixes#40646
Signed-off-by: Jeremy Bettis <jbettis@google.com>
Since drivers implement a callback based on action and not the state,
we should be using the API based on the action instead of the one based
on the state.
Signed-off-by: Flavio Ceolin <flavio.ceolin@intel.com>
Fill in received bytes in USBIP_RET_SUBMIT packet
Currently this field is unconditionally set to 0 and therefore not
filled in conveniently. This may mislead the USB host which is correctly
acknowledged that the transaction was sucessful but it cannot check the
actual received bytes.
Test application:
```python
import usb
data = (0xFF, 0xFF)
print("Opening loopback device")
device = usb.core.find(idVendor=0x2FE3, idProduct=0x0009)
print("Writing test data", data)
written = device.write(0x1, data)
print("Written", written, "bytes")
```
Before:
```
$ ./test_loopback.py
Opening loopback device
Writing test data (255, 255)
Written 0 bytes
```
After:
```
$ ./test_loopback.py
Opening loopback device
Writing test data (255, 255)
Written 2 bytes
```
Signed-off-by: Raúl Sánchez Siles <rsanchezs@k-lagan.com>
Use DT_INST_ENUM_IDX_OR and always default to full-speed
if CONFIG_USB_DC_HAS_HS_SUPPORT is not set or maximum-speed
property is not defined.
Remove low-speed setting since device stack does not support it.
Signed-off-by: Johann Fischer <johann.fischer@nordicsemi.no>
In the current USB device support, the sizes of bulk endpoint
are mostly configure through Kconfig and do not care if a device
is high-speed capable. The information if a USB device controller
supports high-speed comes from devicetree. Add a Kconfig option to
map this information and configure bulk endpoint sizes
accordingly.
Signed-off-by: Johann Fischer <johann.fischer@nordicsemi.no>
Define a custom IEEE802154 based L2. The user can then use those symbols
to implement their own 802.15.4 based L2, based on those symbols, w/o a
need to modify the Zephyr tree.
Signed-off-by: Robert Lubos <robert.lubos@nordicsemi.no>
Some 802.15.4 L2 implementations expect that FCS length is included in
the overall packet length while others not. Allow to configure this
behavior, based on the selected upper layer.
Signed-off-by: Robert Lubos <robert.lubos@nordicsemi.no>
Introduce a common config for all 802.15.4 based L2 implementations.
This way, any custom 15.4 L2 implementation will be able to
automatically enable use 15.4 driver, w/o a need to modify the actual
Kconfig.
Signed-off-by: Robert Lubos <robert.lubos@nordicsemi.no>
The CAVS_IDC_IPM driver happens to be used only on non-2.5 hardware,
but it's best to be clear in the conditional compilation when we're
talking about hardware-dependencies and when we mean software
configuration. This was mixed up in a few spots.
Also fix a warning that creeps in on non-default drivers choices about
an undeclared ipm function.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
