Kconfig USB_DEVICE_REMOTE_WAKEUP option depends only on
USB device controller capability, but is not controlled
by the USB device controller drivers configuration.
Move USB_DEVICE_REMOTE_WAKEUP option to drivers and
make it promptless.
Signed-off-by: Johann Fischer <johann.fischer@nordicsemi.no>
Even if not used DMA HAL is required in L4/F7 SD HAL driver.
Add them for these specific series.
Signed-off-by: Erwan Gouriou <erwan.gouriou@linaro.org>
This commit adds shell commands for the reset cause API
- show: show the persistent reset cause
- clear: clear the persistent reset cause
- supported: list all supported reset causes
Signed-off-by: Alexander Wachter <alexander.wachter@leica-geosystems.com>
This commit changes the shell argument name from shell to sh
to satisfy the warning
"Violation to rule 5.7 (Tag name should be unique) tag: shell"
Signed-off-by: Alexander Wachter <alexander@wachter.cloud>
Rename the Zephyr chosen property for specifying the default CAN bus
controller from "zephyr,can-primary" to "zephyr,canbus".
The "zephyr,can-primary" property name was selected in antipation of
adding support for redundant CAN networks, which we have yet to
add. Meanwhile, the "primary" term causes confusion for non-redundant
CAN bus configurations (and the "can" term doesn't match the name of the
Zephyr CAN bus subsystem).
The CAN in Automation (CiA) 302-6, which deals with CANopen network
redundancy, uses the terms "default interface" and "redundant
interface". If/when we add support for redundant CAN networks, the
"zephyr,canbus" chosen property can be supplemented with a
"zephyr,canbus-redundant" chosen property.
Signed-off-by: Henrik Brix Andersen <hebad@vestas.com>
The previous bf68b67 commit incorrectly passes minfo.mdm_rssi
value to the modem context data_rssi member during the driver
initialization which causes the `modem info` shell command
to return 0 as RSSI value. Fix that by changing data_rssi
modem ctx member to a pointer that is assigned to the RSSI
variable stored within the modem driver context structure.
Signed-off-by: Bartosz Bilas <bartosz.bilas@hotmail.com>
add ledc to board dtsi file,
change compatible and device define in pwm driver,
add yaml for board ledc support,
fix missing include for board in gpio include
Signed-off-by: Andrei-Edward Popa <andrei_edward.popa@upb.ro>
Changed pwm_pin_set_cycles into pwm_pin_set_nsec
to decrease power consumption. Changed default
value for period to 100000. There is no need in having
period for pwm leds equal to 100 cycles as human eye has ~100 fps.
Signed-off-by: Jan Zyczkowski <jan.zyczkowski@nordicsemi.no>
CONFIG_UART_MUX_DEVICE_NAME is used as a prefix for the uart muxes
name. Pointer comparison will always return false
Fix#39774
Signed-off-by: Guillaume Lager <g.lager@innoseis.com>
drivers: modem: gsm: Quectel EC21 and BG9x act as a gsm modem without
problem, but COPS commands can returns just one value with 'mode'.
Format and oper are not mandatory. This modification reads 'mode'.
Also a modification on modem_cmd_read_cops_cmd is needed.
Signed-off-by: Jair Jack <jack@icatorze.com.br>
Use i2c_hal functions to enable support for
multiple SoCs.
Use DT compat to enable I2C from device
tree configuration
Signed-off-by: Sylvio Alves <sylvio.alves@espressif.com>
PCA9633 driver does not cunnetly support multiple devices.
Updated the driver to use DT_INST_FOREACH_STATUS_OKAY to
configure all devices defined in the device tree.
Convert driver to use `i2c_dt_spec` helpers.
Fixes#40076
Signed-off-by: Daniel N. Hansten <dnh2000@gmail.com>
This joins all clock control handling to same source
by using hal clock functions. It also brings ESP32C3
clock support.
Signed-off-by: Sylvio Alves <sylvio.alves@espressif.com>
This commit enables the HSI48 clock for the stm32U5 soc family
to use the USB device peripheral.
Enable the VDD USB voltage supply.
Signed-off-by: Francois Ramu <francois.ramu@st.com>
Since cs gpios are initialized during driver initialization
remove spi_context_cs_configure that is not longer need.
Signed-off-by: Bartosz Bilas <bartosz.bilas@hotmail.com>
In case when we have multiple devices connected to the
one SPI interface the initial state of CS gpios after
MCU reset is floating and it might be low that prevents us from
communicating between particular devices. Fix that by
initializing all provided cs gpios and setting them as inactive.
Signed-off-by: Bartosz Bilas <bartosz.bilas@hotmail.com>
In case when we have multiple devices connected to the
one SPI interface the initial state of CS gpios after
MCU reset is floating and it might be low that prevents us from
communicating between particular devices. Fix that by
initializing all provided cs gpios and setting them as inactive.
Signed-off-by: Bartosz Bilas <bartosz.bilas@hotmail.com>
In case when we have multiple devices connected to the
one SPI interface the initial state of CS gpios after
MCU reset is floating and it might be low that prevents us from
communicating between particular devices. Fix that by
initializing all provided cs gpios and setting them as inactive.
Signed-off-by: Bartosz Bilas <bartosz.bilas@hotmail.com>
In case when we have multiple devices connected to the
one SPI interface the initial state of CS gpios after
MCU reset is floating and it might be low that prevents us from
communicating between particular devices. Fix that by
initializing all provided cs gpios and setting them as inactive.
Signed-off-by: Bartosz Bilas <bartosz.bilas@hotmail.com>
In case when we have multiple devices connected to the
one SPI interface the initial state of CS gpios after
MCU reset is floating and it might be low that prevents us from
communicating between particular devices. Fix that by
initializing all provided cs gpios and setting them as inactive.
Signed-off-by: Bartosz Bilas <bartosz.bilas@hotmail.com>
In case when we have multiple devices connected to the
one SPI interface the initial state of CS gpios after
MCU reset is floating and it might be low that prevents us from
communicating between particular devices. Fix that by
initializing all provided cs gpios and setting them as inactive.
Signed-off-by: Bartosz Bilas <bartosz.bilas@hotmail.com>
In case when we have multiple devices connected to the
one SPI interface the initial state of CS gpios after
MCU reset is floating and it might be low that prevents us from
communicating between particular devices. Fix that by
initializing all provided cs gpios and setting them as inactive.
Signed-off-by: Bartosz Bilas <bartosz.bilas@hotmail.com>
In case when we have multiple devices connected to the
one SPI interface the initial state of CS gpios after
MCU reset is floating and it might be low that prevents us from
communicating between particular devices. Fix that by
initializing all provided cs gpios and setting them as inactive.
Signed-off-by: Bartosz Bilas <bartosz.bilas@hotmail.com>
In case when we have multiple devices connected to the
one SPI interface the initial state of CS gpios after
MCU reset is floating and it might be low that prevents us from
communicating between particular devices. Fix that by
initializing all provided cs gpios and setting them as inactive.
Signed-off-by: Bartosz Bilas <bartosz.bilas@hotmail.com>
In case when we have multiple devices connected to the
one SPI interface the initial state of CS gpios after
MCU reset is floating and it might be low that prevents us from
communicating between particular devices. Fix that by
initializing all provided cs gpios and setting them as inactive.
Signed-off-by: Bartosz Bilas <bartosz.bilas@hotmail.com>
In case when we have multiple devices connected to the
one SPI interface the initial state of CS gpios after
MCU reset is floating and it might be low that prevents us from
communicating between particular devices. Fix that by
initializing all provided cs gpios and setting them as inactive.
Signed-off-by: Bartosz Bilas <bartosz.bilas@hotmail.com>
In case when we have multiple devices connected to the
one SPI interface the initial state of CS gpios after
MCU reset is floating and it might be low that prevents us from
communicating between particular devices. Fix that by
initializing all provided cs gpios and setting them as inactive.
Signed-off-by: Bartosz Bilas <bartosz.bilas@hotmail.com>
In case when we have multiple devices connected to the
one SPI interface the initial state of CS gpios after
MCU reset is floating and it might be low that prevents us from
communicating between particular devices. Fix that by
initializing all provided cs gpios and setting them as inactive.
Signed-off-by: Bartosz Bilas <bartosz.bilas@hotmail.com>
In case when we have multiple devices connected to the
one SPI interface the initial state of CS gpios after
MCU reset is floating and it might be low that prevents us from
communicating between particular devices. Fix that by
initializing all provided cs gpios and setting them as inactive.
Signed-off-by: Bartosz Bilas <bartosz.bilas@hotmail.com>
In case when we have multiple devices connected to the
one SPI interface the initial state of CS gpios after
MCU reset is floating and it might be low that prevents us from
communicating between particular devices. Fix that by
initializing all provided cs gpios and setting them as inactive.
Signed-off-by: Bartosz Bilas <bartosz.bilas@hotmail.com>
In case when we have multiple devices connected to the
one SPI interface the initial state of CS gpios after
MCU reset is floating and it might be low that prevents us from
communicating between particular devices. Fix that by
initializing all provided cs gpios and setting them as inactive.
Signed-off-by: Bartosz Bilas <bartosz.bilas@hotmail.com>
In case when we have multiple devices connected to the
one SPI interface the initial state of CS gpios after
MCU reset is floating and it might be low that prevents us from
communicating between particular devices. Fix that by
initializing all provided cs gpios and setting them as inactive.
Signed-off-by: Bartosz Bilas <bartosz.bilas@hotmail.com>
In case when we have multiple devices connected to the
one SPI interface the initial state of CS gpios after
MCU reset is floating and it might be low that prevents us from
communicating between particular devices. Fix that by
initializing all provided cs gpios and setting them as inactive.
Signed-off-by: Bartosz Bilas <bartosz.bilas@hotmail.com>
In case when we have multiple devices connected to the
one SPI interface the initial state of CS gpios after
MCU reset is floating and it might be low that prevents us from
communicating between particular devices. Fix that by
initializing all provided cs gpios and setting them as inactive.
Signed-off-by: Bartosz Bilas <bartosz.bilas@hotmail.com>
Add extra cs_gpios and num_cs_gpios members into
spi_context structure that will be used to
initialize all defined cs gpios during the driver
initialization using SPI_CONTEXT_CS_GPIOS_INITIALIZE macro.
While at it add a new spi_context_cs_configure_all
function that allows the user to configure
all available cs gpios in inactive mode.
Signed-off-by: Bartosz Bilas <bartosz.bilas@hotmail.com>
A couple of SPI drivers use CONFIG_KERNEL_INIT_PRIORITY_DEVICE
as init priority for driver initialization. Let's change
it to the dedicated CONFIG_SPI_INIT_PRIORITY to make it
compatible with other ones.
Signed-off-by: Bartosz Bilas <bartosz.bilas@hotmail.com>
Any exposed PTM root device will by default see their root capability
enabled so they will become PTM responder.
Signed-off-by: Tomasz Bursztyka <tomasz.bursztyka@linux.intel.com>
Such module is missing and will prove to be useful for future features
and/or printing out debug messages on existing ones.
Signed-off-by: Tomasz Bursztyka <tomasz.bursztyka@linux.intel.com>
When the "Read data register not empty" irq occurs,
this commit is cleaning the RXNE flag by flushing the RX register
since the Receive Data Reg. (USART_RDR) has not be read previously
This could be the case when aborting a Rx for example.
Signed-off-by: Francois Ramu <francois.ramu@st.com>
During SDMMC card init, HW_FC is disabled by default, overwriting
driver configuration.
To avoid this, move HW FC configuration after card init.
Signed-off-by: Erwan Gouriou <erwan.gouriou@linaro.org>
Deinitialize the nrfx_qspi driver for periods when the device
is suspended. For flash chips with "has-dpd" property set, when
suspending/resuming the device, issue also the enter/exit Deep
Power-down Mode command, respectively.
Signed-off-by: Andrzej Głąbek <andrzej.glabek@nordicsemi.no>
Use the read-only device config structure (so far used only for storing
the flash chip size and its JEDEC ID) to store the nrfx_qspi driver
configuration (it is not modified after initialization, so there is no
need to keep it in RAM) and fill it with settings read from devicetree,
processing them all at compile time (e.g. use the DT_STRING_UPPER_TOKEN
macro instead of switch-case blocks for getting values of "readoc" and
"writeoc" properties).
Signed-off-by: Andrzej Głąbek <andrzej.glabek@nordicsemi.no>
Refactors all of the EEPROM drivers to use a shared driver class
initialization priority configuration, CONFIG_EEPROM_INIT_PRIORITY, to
allow configuring EEPROM drivers separately from other devices. This is
similar to other driver classes like I2C and SPI.
The default is set to CONFIG_KERNEL_INIT_PRIORITY_DEVICE to preserve the
existing default initialization priority for most drivers. The
exceptions are at2x and emul drivers which have dependencies on SPI,
I2C, or flash drivers and must therefore initialize later than the
default device priority.
Signed-off-by: Maureen Helm <maureen.helm@intel.com>
The commit removes redundant flash_id argument that the function
can obtain itself from dev.
Signed-off-by: Dominik Ermel <dominik.ermel@nordicsemi.no>
