2021-08-10 11:22:31 +02:00
|
|
|
/*
|
|
|
|
|
* Copyright (c) 2021 Nordic Semiconductor ASA
|
|
|
|
|
*
|
|
|
|
|
* SPDX-License-Identifier: Apache-2.0
|
|
|
|
|
*/
|
|
|
|
|
|
2022-05-06 10:25:46 +02:00
|
|
|
#include <zephyr/drivers/pinctrl.h>
|
2021-08-10 11:22:31 +02:00
|
|
|
|
|
|
|
|
#include <hal/nrf_gpio.h>
|
|
|
|
|
|
|
|
|
|
BUILD_ASSERT(((NRF_PULL_NONE == NRF_GPIO_PIN_NOPULL) &&
|
|
|
|
|
(NRF_PULL_DOWN == NRF_GPIO_PIN_PULLDOWN) &&
|
|
|
|
|
(NRF_PULL_UP == NRF_GPIO_PIN_PULLUP)),
|
|
|
|
|
"nRF pinctrl pull settings do not match HAL values");
|
|
|
|
|
|
2023-10-30 15:56:34 +01:00
|
|
|
#if defined(GPIO_PIN_CNF_DRIVE_E0E1) || defined(GPIO_PIN_CNF_DRIVE0_E0)
|
|
|
|
|
#define NRF_DRIVE_COUNT (NRF_DRIVE_E0E1 + 1)
|
|
|
|
|
#else
|
|
|
|
|
#define NRF_DRIVE_COUNT (NRF_DRIVE_H0D1 + 1)
|
|
|
|
|
#endif
|
|
|
|
|
static const nrf_gpio_pin_drive_t drive_modes[NRF_DRIVE_COUNT] = {
|
|
|
|
|
[NRF_DRIVE_S0S1] = NRF_GPIO_PIN_S0S1,
|
|
|
|
|
[NRF_DRIVE_H0S1] = NRF_GPIO_PIN_H0S1,
|
|
|
|
|
[NRF_DRIVE_S0H1] = NRF_GPIO_PIN_S0H1,
|
|
|
|
|
[NRF_DRIVE_H0H1] = NRF_GPIO_PIN_H0H1,
|
|
|
|
|
[NRF_DRIVE_D0S1] = NRF_GPIO_PIN_D0S1,
|
|
|
|
|
[NRF_DRIVE_D0H1] = NRF_GPIO_PIN_D0H1,
|
|
|
|
|
[NRF_DRIVE_S0D1] = NRF_GPIO_PIN_S0D1,
|
|
|
|
|
[NRF_DRIVE_H0D1] = NRF_GPIO_PIN_H0D1,
|
|
|
|
|
#if defined(GPIO_PIN_CNF_DRIVE_E0E1) || defined(GPIO_PIN_CNF_DRIVE0_E0)
|
|
|
|
|
[NRF_DRIVE_E0E1] = NRF_GPIO_PIN_E0E1,
|
|
|
|
|
#endif
|
|
|
|
|
};
|
2021-08-10 11:22:31 +02:00
|
|
|
|
2022-08-11 15:16:27 +02:00
|
|
|
/* value to indicate pin level doesn't need initialization */
|
|
|
|
|
#define NO_WRITE UINT32_MAX
|
|
|
|
|
|
drivers: pinctrl_nrf: Fix disconnecting of pins
This is a follow-up to commit 223cc3c6bd95821f19c4f2e473f786076667e399.
When a peripheral pin is disconnected, the pinctrl driver should skip
applying of GPIO configuration, as there is no pin number available in
such case, but due to an incorrect check, it actually did not skip it
and used an incorrect pin number for that. In nrfx prior to 3.0.0, this
caused an assertion failure, but because of a fallback routine, things
could still work in most cases (when assertions were disabled) as that
GPIO configuration was just applied to P0.31. Hence the bug was not
discovered until now. In the recent nrfx, this causes a null pointer
dereference, so always a crash.
This commit corrects the mentioned check and also uses the term "psel"
instead of "pin" where it is possible that the value is not a correct
pin number, in the hope of preventing a similar problem in the future.
Signed-off-by: Andrzej Głąbek <andrzej.glabek@nordicsemi.no>
2023-05-08 15:51:31 +02:00
|
|
|
#define PSEL_DISCONNECTED 0xFFFFFFFFUL
|
|
|
|
|
|
2021-08-10 11:24:54 +02:00
|
|
|
#if DT_HAS_COMPAT_STATUS_OKAY(nordic_nrf_uart)
|
|
|
|
|
#define NRF_PSEL_UART(reg, line) ((NRF_UART_Type *)reg)->PSEL##line
|
|
|
|
|
#elif DT_HAS_COMPAT_STATUS_OKAY(nordic_nrf_uarte)
|
2024-03-12 16:19:55 +01:00
|
|
|
#include <hal/nrf_uarte.h>
|
2021-08-10 11:24:54 +02:00
|
|
|
#define NRF_PSEL_UART(reg, line) ((NRF_UARTE_Type *)reg)->PSEL.line
|
|
|
|
|
#endif
|
|
|
|
|
|
2022-02-24 15:34:15 +01:00
|
|
|
#if DT_HAS_COMPAT_STATUS_OKAY(nordic_nrf_spi)
|
|
|
|
|
#define NRF_PSEL_SPIM(reg, line) ((NRF_SPI_Type *)reg)->PSEL##line
|
|
|
|
|
#elif DT_HAS_COMPAT_STATUS_OKAY(nordic_nrf_spim)
|
2024-03-12 16:19:55 +01:00
|
|
|
#include <hal/nrf_spim.h>
|
2022-02-24 15:34:15 +01:00
|
|
|
#define NRF_PSEL_SPIM(reg, line) ((NRF_SPIM_Type *)reg)->PSEL.line
|
|
|
|
|
#endif
|
|
|
|
|
|
|
|
|
|
#if DT_HAS_COMPAT_STATUS_OKAY(nordic_nrf_spis)
|
2024-03-12 16:19:55 +01:00
|
|
|
#include <hal/nrf_spis.h>
|
2022-02-24 15:34:15 +01:00
|
|
|
#if defined(NRF51)
|
|
|
|
|
#define NRF_PSEL_SPIS(reg, line) ((NRF_SPIS_Type *)reg)->PSEL##line
|
|
|
|
|
#else
|
|
|
|
|
#define NRF_PSEL_SPIS(reg, line) ((NRF_SPIS_Type *)reg)->PSEL.line
|
|
|
|
|
#endif
|
|
|
|
|
#endif /* DT_HAS_COMPAT_STATUS_OKAY(nordic_nrf_spis) */
|
|
|
|
|
|
|
|
|
|
#if DT_HAS_COMPAT_STATUS_OKAY(nordic_nrf_twi)
|
2022-03-17 19:54:43 +01:00
|
|
|
#if !defined(TWI_PSEL_SCL_CONNECT_Pos)
|
2022-02-24 15:34:15 +01:00
|
|
|
#define NRF_PSEL_TWIM(reg, line) ((NRF_TWI_Type *)reg)->PSEL##line
|
2022-03-17 19:54:43 +01:00
|
|
|
#else
|
|
|
|
|
#define NRF_PSEL_TWIM(reg, line) ((NRF_TWI_Type *)reg)->PSEL.line
|
|
|
|
|
#endif
|
2022-02-24 15:34:15 +01:00
|
|
|
#elif DT_HAS_COMPAT_STATUS_OKAY(nordic_nrf_twim)
|
2024-03-12 16:19:55 +01:00
|
|
|
#include <hal/nrf_twim.h>
|
2022-02-24 15:34:15 +01:00
|
|
|
#define NRF_PSEL_TWIM(reg, line) ((NRF_TWIM_Type *)reg)->PSEL.line
|
|
|
|
|
#endif
|
|
|
|
|
|
2022-03-01 17:01:44 +01:00
|
|
|
#if DT_HAS_COMPAT_STATUS_OKAY(nordic_nrf_i2s)
|
|
|
|
|
#define NRF_PSEL_I2S(reg, line) ((NRF_I2S_Type *)reg)->PSEL.line
|
|
|
|
|
#endif
|
|
|
|
|
|
|
|
|
|
#if DT_HAS_COMPAT_STATUS_OKAY(nordic_nrf_pdm)
|
|
|
|
|
#define NRF_PSEL_PDM(reg, line) ((NRF_PDM_Type *)reg)->PSEL.line
|
|
|
|
|
#endif
|
|
|
|
|
|
2022-03-04 17:11:37 +01:00
|
|
|
#if DT_HAS_COMPAT_STATUS_OKAY(nordic_nrf_pwm)
|
|
|
|
|
#define NRF_PSEL_PWM(reg, line) ((NRF_PWM_Type *)reg)->PSEL.line
|
|
|
|
|
#endif
|
|
|
|
|
|
|
|
|
|
#if DT_HAS_COMPAT_STATUS_OKAY(nordic_nrf_qdec)
|
|
|
|
|
#define NRF_PSEL_QDEC(reg, line) ((NRF_QDEC_Type *)reg)->PSEL.line
|
|
|
|
|
#endif
|
|
|
|
|
|
|
|
|
|
#if DT_HAS_COMPAT_STATUS_OKAY(nordic_nrf_qspi)
|
|
|
|
|
#define NRF_PSEL_QSPI(reg, line) ((NRF_QSPI_Type *)reg)->PSEL.line
|
|
|
|
|
#endif
|
|
|
|
|
|
2021-08-10 11:22:31 +02:00
|
|
|
int pinctrl_configure_pins(const pinctrl_soc_pin_t *pins, uint8_t pin_cnt,
|
|
|
|
|
uintptr_t reg)
|
|
|
|
|
{
|
|
|
|
|
for (uint8_t i = 0U; i < pin_cnt; i++) {
|
2023-10-30 15:56:34 +01:00
|
|
|
nrf_gpio_pin_drive_t drive;
|
|
|
|
|
uint8_t drive_idx = NRF_GET_DRIVE(pins[i]);
|
drivers: pinctrl_nrf: Fix disconnecting of pins
This is a follow-up to commit 223cc3c6bd95821f19c4f2e473f786076667e399.
When a peripheral pin is disconnected, the pinctrl driver should skip
applying of GPIO configuration, as there is no pin number available in
such case, but due to an incorrect check, it actually did not skip it
and used an incorrect pin number for that. In nrfx prior to 3.0.0, this
caused an assertion failure, but because of a fallback routine, things
could still work in most cases (when assertions were disabled) as that
GPIO configuration was just applied to P0.31. Hence the bug was not
discovered until now. In the recent nrfx, this causes a null pointer
dereference, so always a crash.
This commit corrects the mentioned check and also uses the term "psel"
instead of "pin" where it is possible that the value is not a correct
pin number, in the hope of preventing a similar problem in the future.
Signed-off-by: Andrzej Głąbek <andrzej.glabek@nordicsemi.no>
2023-05-08 15:51:31 +02:00
|
|
|
uint32_t psel = NRF_GET_PIN(pins[i]);
|
2022-08-11 15:16:27 +02:00
|
|
|
uint32_t write = NO_WRITE;
|
|
|
|
|
nrf_gpio_pin_dir_t dir;
|
|
|
|
|
nrf_gpio_pin_input_t input;
|
2024-03-12 16:19:55 +01:00
|
|
|
#if NRF_GPIO_HAS_CLOCKPIN
|
|
|
|
|
bool clockpin = false;
|
|
|
|
|
#endif
|
2022-08-11 15:16:27 +02:00
|
|
|
|
2023-10-30 15:56:34 +01:00
|
|
|
if (drive_idx < ARRAY_SIZE(drive_modes)) {
|
|
|
|
|
drive = drive_modes[drive_idx];
|
|
|
|
|
} else {
|
|
|
|
|
return -EINVAL;
|
|
|
|
|
}
|
|
|
|
|
|
drivers: pinctrl_nrf: Fix disconnecting of pins
This is a follow-up to commit 223cc3c6bd95821f19c4f2e473f786076667e399.
When a peripheral pin is disconnected, the pinctrl driver should skip
applying of GPIO configuration, as there is no pin number available in
such case, but due to an incorrect check, it actually did not skip it
and used an incorrect pin number for that. In nrfx prior to 3.0.0, this
caused an assertion failure, but because of a fallback routine, things
could still work in most cases (when assertions were disabled) as that
GPIO configuration was just applied to P0.31. Hence the bug was not
discovered until now. In the recent nrfx, this causes a null pointer
dereference, so always a crash.
This commit corrects the mentioned check and also uses the term "psel"
instead of "pin" where it is possible that the value is not a correct
pin number, in the hope of preventing a similar problem in the future.
Signed-off-by: Andrzej Głąbek <andrzej.glabek@nordicsemi.no>
2023-05-08 15:51:31 +02:00
|
|
|
if (psel == NRF_PIN_DISCONNECTED) {
|
|
|
|
|
psel = PSEL_DISCONNECTED;
|
2022-08-11 15:16:27 +02:00
|
|
|
}
|
2022-07-01 12:08:06 +02:00
|
|
|
|
2021-08-10 11:22:31 +02:00
|
|
|
switch (NRF_GET_FUN(pins[i])) {
|
2021-08-10 11:24:54 +02:00
|
|
|
#if defined(NRF_PSEL_UART)
|
|
|
|
|
case NRF_FUN_UART_TX:
|
drivers: pinctrl_nrf: Fix disconnecting of pins
This is a follow-up to commit 223cc3c6bd95821f19c4f2e473f786076667e399.
When a peripheral pin is disconnected, the pinctrl driver should skip
applying of GPIO configuration, as there is no pin number available in
such case, but due to an incorrect check, it actually did not skip it
and used an incorrect pin number for that. In nrfx prior to 3.0.0, this
caused an assertion failure, but because of a fallback routine, things
could still work in most cases (when assertions were disabled) as that
GPIO configuration was just applied to P0.31. Hence the bug was not
discovered until now. In the recent nrfx, this causes a null pointer
dereference, so always a crash.
This commit corrects the mentioned check and also uses the term "psel"
instead of "pin" where it is possible that the value is not a correct
pin number, in the hope of preventing a similar problem in the future.
Signed-off-by: Andrzej Głąbek <andrzej.glabek@nordicsemi.no>
2023-05-08 15:51:31 +02:00
|
|
|
NRF_PSEL_UART(reg, TXD) = psel;
|
2022-08-11 15:16:27 +02:00
|
|
|
write = 1U;
|
|
|
|
|
dir = NRF_GPIO_PIN_DIR_OUTPUT;
|
|
|
|
|
input = NRF_GPIO_PIN_INPUT_DISCONNECT;
|
2024-03-12 16:19:55 +01:00
|
|
|
#if NRF_GPIO_HAS_CLOCKPIN && defined(NRF_UARTE_CLOCKPIN_TXD_NEEDED)
|
|
|
|
|
clockpin = true;
|
|
|
|
|
#endif
|
2021-08-10 11:24:54 +02:00
|
|
|
break;
|
|
|
|
|
case NRF_FUN_UART_RX:
|
drivers: pinctrl_nrf: Fix disconnecting of pins
This is a follow-up to commit 223cc3c6bd95821f19c4f2e473f786076667e399.
When a peripheral pin is disconnected, the pinctrl driver should skip
applying of GPIO configuration, as there is no pin number available in
such case, but due to an incorrect check, it actually did not skip it
and used an incorrect pin number for that. In nrfx prior to 3.0.0, this
caused an assertion failure, but because of a fallback routine, things
could still work in most cases (when assertions were disabled) as that
GPIO configuration was just applied to P0.31. Hence the bug was not
discovered until now. In the recent nrfx, this causes a null pointer
dereference, so always a crash.
This commit corrects the mentioned check and also uses the term "psel"
instead of "pin" where it is possible that the value is not a correct
pin number, in the hope of preventing a similar problem in the future.
Signed-off-by: Andrzej Głąbek <andrzej.glabek@nordicsemi.no>
2023-05-08 15:51:31 +02:00
|
|
|
NRF_PSEL_UART(reg, RXD) = psel;
|
2022-08-11 15:16:27 +02:00
|
|
|
dir = NRF_GPIO_PIN_DIR_INPUT;
|
|
|
|
|
input = NRF_GPIO_PIN_INPUT_CONNECT;
|
2021-08-10 11:24:54 +02:00
|
|
|
break;
|
|
|
|
|
case NRF_FUN_UART_RTS:
|
drivers: pinctrl_nrf: Fix disconnecting of pins
This is a follow-up to commit 223cc3c6bd95821f19c4f2e473f786076667e399.
When a peripheral pin is disconnected, the pinctrl driver should skip
applying of GPIO configuration, as there is no pin number available in
such case, but due to an incorrect check, it actually did not skip it
and used an incorrect pin number for that. In nrfx prior to 3.0.0, this
caused an assertion failure, but because of a fallback routine, things
could still work in most cases (when assertions were disabled) as that
GPIO configuration was just applied to P0.31. Hence the bug was not
discovered until now. In the recent nrfx, this causes a null pointer
dereference, so always a crash.
This commit corrects the mentioned check and also uses the term "psel"
instead of "pin" where it is possible that the value is not a correct
pin number, in the hope of preventing a similar problem in the future.
Signed-off-by: Andrzej Głąbek <andrzej.glabek@nordicsemi.no>
2023-05-08 15:51:31 +02:00
|
|
|
NRF_PSEL_UART(reg, RTS) = psel;
|
2022-08-11 15:16:27 +02:00
|
|
|
write = 1U;
|
|
|
|
|
dir = NRF_GPIO_PIN_DIR_OUTPUT;
|
|
|
|
|
input = NRF_GPIO_PIN_INPUT_DISCONNECT;
|
2024-03-12 16:19:55 +01:00
|
|
|
#if NRF_GPIO_HAS_CLOCKPIN && defined(NRF_UARTE_CLOCKPIN_RTS_NEEDED)
|
|
|
|
|
clockpin = true;
|
|
|
|
|
#endif
|
2021-08-10 11:24:54 +02:00
|
|
|
break;
|
|
|
|
|
case NRF_FUN_UART_CTS:
|
drivers: pinctrl_nrf: Fix disconnecting of pins
This is a follow-up to commit 223cc3c6bd95821f19c4f2e473f786076667e399.
When a peripheral pin is disconnected, the pinctrl driver should skip
applying of GPIO configuration, as there is no pin number available in
such case, but due to an incorrect check, it actually did not skip it
and used an incorrect pin number for that. In nrfx prior to 3.0.0, this
caused an assertion failure, but because of a fallback routine, things
could still work in most cases (when assertions were disabled) as that
GPIO configuration was just applied to P0.31. Hence the bug was not
discovered until now. In the recent nrfx, this causes a null pointer
dereference, so always a crash.
This commit corrects the mentioned check and also uses the term "psel"
instead of "pin" where it is possible that the value is not a correct
pin number, in the hope of preventing a similar problem in the future.
Signed-off-by: Andrzej Głąbek <andrzej.glabek@nordicsemi.no>
2023-05-08 15:51:31 +02:00
|
|
|
NRF_PSEL_UART(reg, CTS) = psel;
|
2022-08-11 15:16:27 +02:00
|
|
|
dir = NRF_GPIO_PIN_DIR_INPUT;
|
|
|
|
|
input = NRF_GPIO_PIN_INPUT_CONNECT;
|
2021-08-10 11:24:54 +02:00
|
|
|
break;
|
|
|
|
|
#endif /* defined(NRF_PSEL_UART) */
|
2022-02-24 15:34:15 +01:00
|
|
|
#if defined(NRF_PSEL_SPIM)
|
|
|
|
|
case NRF_FUN_SPIM_SCK:
|
drivers: pinctrl_nrf: Fix disconnecting of pins
This is a follow-up to commit 223cc3c6bd95821f19c4f2e473f786076667e399.
When a peripheral pin is disconnected, the pinctrl driver should skip
applying of GPIO configuration, as there is no pin number available in
such case, but due to an incorrect check, it actually did not skip it
and used an incorrect pin number for that. In nrfx prior to 3.0.0, this
caused an assertion failure, but because of a fallback routine, things
could still work in most cases (when assertions were disabled) as that
GPIO configuration was just applied to P0.31. Hence the bug was not
discovered until now. In the recent nrfx, this causes a null pointer
dereference, so always a crash.
This commit corrects the mentioned check and also uses the term "psel"
instead of "pin" where it is possible that the value is not a correct
pin number, in the hope of preventing a similar problem in the future.
Signed-off-by: Andrzej Głąbek <andrzej.glabek@nordicsemi.no>
2023-05-08 15:51:31 +02:00
|
|
|
NRF_PSEL_SPIM(reg, SCK) = psel;
|
2022-08-11 15:16:27 +02:00
|
|
|
write = 0U;
|
|
|
|
|
dir = NRF_GPIO_PIN_DIR_OUTPUT;
|
|
|
|
|
input = NRF_GPIO_PIN_INPUT_CONNECT;
|
2024-03-12 16:19:55 +01:00
|
|
|
#if NRF_GPIO_HAS_CLOCKPIN && defined(NRF_SPIM_CLOCKPIN_SCK_NEEDED)
|
|
|
|
|
clockpin = true;
|
|
|
|
|
#endif
|
2022-02-24 15:34:15 +01:00
|
|
|
break;
|
|
|
|
|
case NRF_FUN_SPIM_MOSI:
|
drivers: pinctrl_nrf: Fix disconnecting of pins
This is a follow-up to commit 223cc3c6bd95821f19c4f2e473f786076667e399.
When a peripheral pin is disconnected, the pinctrl driver should skip
applying of GPIO configuration, as there is no pin number available in
such case, but due to an incorrect check, it actually did not skip it
and used an incorrect pin number for that. In nrfx prior to 3.0.0, this
caused an assertion failure, but because of a fallback routine, things
could still work in most cases (when assertions were disabled) as that
GPIO configuration was just applied to P0.31. Hence the bug was not
discovered until now. In the recent nrfx, this causes a null pointer
dereference, so always a crash.
This commit corrects the mentioned check and also uses the term "psel"
instead of "pin" where it is possible that the value is not a correct
pin number, in the hope of preventing a similar problem in the future.
Signed-off-by: Andrzej Głąbek <andrzej.glabek@nordicsemi.no>
2023-05-08 15:51:31 +02:00
|
|
|
NRF_PSEL_SPIM(reg, MOSI) = psel;
|
2022-08-11 15:16:27 +02:00
|
|
|
write = 0U;
|
|
|
|
|
dir = NRF_GPIO_PIN_DIR_OUTPUT;
|
|
|
|
|
input = NRF_GPIO_PIN_INPUT_DISCONNECT;
|
2024-03-12 16:19:55 +01:00
|
|
|
#if NRF_GPIO_HAS_CLOCKPIN && defined(NRF_SPIM_CLOCKPIN_MOSI_NEEDED)
|
|
|
|
|
clockpin = true;
|
|
|
|
|
#endif
|
2022-02-24 15:34:15 +01:00
|
|
|
break;
|
|
|
|
|
case NRF_FUN_SPIM_MISO:
|
drivers: pinctrl_nrf: Fix disconnecting of pins
This is a follow-up to commit 223cc3c6bd95821f19c4f2e473f786076667e399.
When a peripheral pin is disconnected, the pinctrl driver should skip
applying of GPIO configuration, as there is no pin number available in
such case, but due to an incorrect check, it actually did not skip it
and used an incorrect pin number for that. In nrfx prior to 3.0.0, this
caused an assertion failure, but because of a fallback routine, things
could still work in most cases (when assertions were disabled) as that
GPIO configuration was just applied to P0.31. Hence the bug was not
discovered until now. In the recent nrfx, this causes a null pointer
dereference, so always a crash.
This commit corrects the mentioned check and also uses the term "psel"
instead of "pin" where it is possible that the value is not a correct
pin number, in the hope of preventing a similar problem in the future.
Signed-off-by: Andrzej Głąbek <andrzej.glabek@nordicsemi.no>
2023-05-08 15:51:31 +02:00
|
|
|
NRF_PSEL_SPIM(reg, MISO) = psel;
|
2022-08-11 15:16:27 +02:00
|
|
|
dir = NRF_GPIO_PIN_DIR_INPUT;
|
|
|
|
|
input = NRF_GPIO_PIN_INPUT_CONNECT;
|
2022-02-24 15:34:15 +01:00
|
|
|
break;
|
|
|
|
|
#endif /* defined(NRF_PSEL_SPIM) */
|
|
|
|
|
#if defined(NRF_PSEL_SPIS)
|
|
|
|
|
case NRF_FUN_SPIS_SCK:
|
drivers: pinctrl_nrf: Fix disconnecting of pins
This is a follow-up to commit 223cc3c6bd95821f19c4f2e473f786076667e399.
When a peripheral pin is disconnected, the pinctrl driver should skip
applying of GPIO configuration, as there is no pin number available in
such case, but due to an incorrect check, it actually did not skip it
and used an incorrect pin number for that. In nrfx prior to 3.0.0, this
caused an assertion failure, but because of a fallback routine, things
could still work in most cases (when assertions were disabled) as that
GPIO configuration was just applied to P0.31. Hence the bug was not
discovered until now. In the recent nrfx, this causes a null pointer
dereference, so always a crash.
This commit corrects the mentioned check and also uses the term "psel"
instead of "pin" where it is possible that the value is not a correct
pin number, in the hope of preventing a similar problem in the future.
Signed-off-by: Andrzej Głąbek <andrzej.glabek@nordicsemi.no>
2023-05-08 15:51:31 +02:00
|
|
|
NRF_PSEL_SPIS(reg, SCK) = psel;
|
2022-08-11 15:16:27 +02:00
|
|
|
dir = NRF_GPIO_PIN_DIR_INPUT;
|
|
|
|
|
input = NRF_GPIO_PIN_INPUT_CONNECT;
|
2024-03-12 16:19:55 +01:00
|
|
|
#if NRF_GPIO_HAS_CLOCKPIN && defined(NRF_SPIS_CLOCKPIN_SCK_NEEDED)
|
|
|
|
|
clockpin = true;
|
|
|
|
|
#endif
|
2022-02-24 15:34:15 +01:00
|
|
|
break;
|
|
|
|
|
case NRF_FUN_SPIS_MOSI:
|
drivers: pinctrl_nrf: Fix disconnecting of pins
This is a follow-up to commit 223cc3c6bd95821f19c4f2e473f786076667e399.
When a peripheral pin is disconnected, the pinctrl driver should skip
applying of GPIO configuration, as there is no pin number available in
such case, but due to an incorrect check, it actually did not skip it
and used an incorrect pin number for that. In nrfx prior to 3.0.0, this
caused an assertion failure, but because of a fallback routine, things
could still work in most cases (when assertions were disabled) as that
GPIO configuration was just applied to P0.31. Hence the bug was not
discovered until now. In the recent nrfx, this causes a null pointer
dereference, so always a crash.
This commit corrects the mentioned check and also uses the term "psel"
instead of "pin" where it is possible that the value is not a correct
pin number, in the hope of preventing a similar problem in the future.
Signed-off-by: Andrzej Głąbek <andrzej.glabek@nordicsemi.no>
2023-05-08 15:51:31 +02:00
|
|
|
NRF_PSEL_SPIS(reg, MOSI) = psel;
|
2022-08-11 15:16:27 +02:00
|
|
|
dir = NRF_GPIO_PIN_DIR_INPUT;
|
|
|
|
|
input = NRF_GPIO_PIN_INPUT_CONNECT;
|
2022-02-24 15:34:15 +01:00
|
|
|
break;
|
|
|
|
|
case NRF_FUN_SPIS_MISO:
|
drivers: pinctrl_nrf: Fix disconnecting of pins
This is a follow-up to commit 223cc3c6bd95821f19c4f2e473f786076667e399.
When a peripheral pin is disconnected, the pinctrl driver should skip
applying of GPIO configuration, as there is no pin number available in
such case, but due to an incorrect check, it actually did not skip it
and used an incorrect pin number for that. In nrfx prior to 3.0.0, this
caused an assertion failure, but because of a fallback routine, things
could still work in most cases (when assertions were disabled) as that
GPIO configuration was just applied to P0.31. Hence the bug was not
discovered until now. In the recent nrfx, this causes a null pointer
dereference, so always a crash.
This commit corrects the mentioned check and also uses the term "psel"
instead of "pin" where it is possible that the value is not a correct
pin number, in the hope of preventing a similar problem in the future.
Signed-off-by: Andrzej Głąbek <andrzej.glabek@nordicsemi.no>
2023-05-08 15:51:31 +02:00
|
|
|
NRF_PSEL_SPIS(reg, MISO) = psel;
|
2022-08-11 15:16:27 +02:00
|
|
|
dir = NRF_GPIO_PIN_DIR_INPUT;
|
|
|
|
|
input = NRF_GPIO_PIN_INPUT_DISCONNECT;
|
2024-03-12 16:19:55 +01:00
|
|
|
#if NRF_GPIO_HAS_CLOCKPIN && defined(NRF_SPIS_CLOCKPIN_MISO_NEEDED)
|
|
|
|
|
clockpin = true;
|
|
|
|
|
#endif
|
2022-02-24 15:34:15 +01:00
|
|
|
break;
|
|
|
|
|
case NRF_FUN_SPIS_CSN:
|
drivers: pinctrl_nrf: Fix disconnecting of pins
This is a follow-up to commit 223cc3c6bd95821f19c4f2e473f786076667e399.
When a peripheral pin is disconnected, the pinctrl driver should skip
applying of GPIO configuration, as there is no pin number available in
such case, but due to an incorrect check, it actually did not skip it
and used an incorrect pin number for that. In nrfx prior to 3.0.0, this
caused an assertion failure, but because of a fallback routine, things
could still work in most cases (when assertions were disabled) as that
GPIO configuration was just applied to P0.31. Hence the bug was not
discovered until now. In the recent nrfx, this causes a null pointer
dereference, so always a crash.
This commit corrects the mentioned check and also uses the term "psel"
instead of "pin" where it is possible that the value is not a correct
pin number, in the hope of preventing a similar problem in the future.
Signed-off-by: Andrzej Głąbek <andrzej.glabek@nordicsemi.no>
2023-05-08 15:51:31 +02:00
|
|
|
NRF_PSEL_SPIS(reg, CSN) = psel;
|
2022-08-11 15:16:27 +02:00
|
|
|
dir = NRF_GPIO_PIN_DIR_INPUT;
|
|
|
|
|
input = NRF_GPIO_PIN_INPUT_CONNECT;
|
2022-02-24 15:34:15 +01:00
|
|
|
break;
|
|
|
|
|
#endif /* defined(NRF_PSEL_SPIS) */
|
|
|
|
|
#if defined(NRF_PSEL_TWIM)
|
|
|
|
|
case NRF_FUN_TWIM_SCL:
|
drivers: pinctrl_nrf: Fix disconnecting of pins
This is a follow-up to commit 223cc3c6bd95821f19c4f2e473f786076667e399.
When a peripheral pin is disconnected, the pinctrl driver should skip
applying of GPIO configuration, as there is no pin number available in
such case, but due to an incorrect check, it actually did not skip it
and used an incorrect pin number for that. In nrfx prior to 3.0.0, this
caused an assertion failure, but because of a fallback routine, things
could still work in most cases (when assertions were disabled) as that
GPIO configuration was just applied to P0.31. Hence the bug was not
discovered until now. In the recent nrfx, this causes a null pointer
dereference, so always a crash.
This commit corrects the mentioned check and also uses the term "psel"
instead of "pin" where it is possible that the value is not a correct
pin number, in the hope of preventing a similar problem in the future.
Signed-off-by: Andrzej Głąbek <andrzej.glabek@nordicsemi.no>
2023-05-08 15:51:31 +02:00
|
|
|
NRF_PSEL_TWIM(reg, SCL) = psel;
|
2023-10-30 15:56:34 +01:00
|
|
|
if (drive == NRF_GPIO_PIN_S0S1) {
|
2022-07-01 12:08:06 +02:00
|
|
|
/* Override the default drive setting with one
|
|
|
|
|
* suitable for TWI/TWIM peripherals (S0D1).
|
|
|
|
|
* This drive cannot be used always so that
|
|
|
|
|
* users are able to select e.g. H0D1 or E0E1
|
|
|
|
|
* in devicetree.
|
|
|
|
|
*/
|
2023-10-30 15:56:34 +01:00
|
|
|
drive = NRF_GPIO_PIN_S0D1;
|
2022-07-01 12:08:06 +02:00
|
|
|
}
|
2022-08-11 15:16:27 +02:00
|
|
|
dir = NRF_GPIO_PIN_DIR_INPUT;
|
|
|
|
|
input = NRF_GPIO_PIN_INPUT_CONNECT;
|
2024-03-12 16:19:55 +01:00
|
|
|
#if NRF_GPIO_HAS_CLOCKPIN && defined(NRF_TWIM_CLOCKPIN_SCL_NEEDED)
|
|
|
|
|
clockpin = true;
|
|
|
|
|
#endif
|
2022-02-24 15:34:15 +01:00
|
|
|
break;
|
|
|
|
|
case NRF_FUN_TWIM_SDA:
|
drivers: pinctrl_nrf: Fix disconnecting of pins
This is a follow-up to commit 223cc3c6bd95821f19c4f2e473f786076667e399.
When a peripheral pin is disconnected, the pinctrl driver should skip
applying of GPIO configuration, as there is no pin number available in
such case, but due to an incorrect check, it actually did not skip it
and used an incorrect pin number for that. In nrfx prior to 3.0.0, this
caused an assertion failure, but because of a fallback routine, things
could still work in most cases (when assertions were disabled) as that
GPIO configuration was just applied to P0.31. Hence the bug was not
discovered until now. In the recent nrfx, this causes a null pointer
dereference, so always a crash.
This commit corrects the mentioned check and also uses the term "psel"
instead of "pin" where it is possible that the value is not a correct
pin number, in the hope of preventing a similar problem in the future.
Signed-off-by: Andrzej Głąbek <andrzej.glabek@nordicsemi.no>
2023-05-08 15:51:31 +02:00
|
|
|
NRF_PSEL_TWIM(reg, SDA) = psel;
|
2023-10-30 15:56:34 +01:00
|
|
|
if (drive == NRF_GPIO_PIN_S0S1) {
|
|
|
|
|
drive = NRF_GPIO_PIN_S0D1;
|
2022-07-01 12:08:06 +02:00
|
|
|
}
|
2022-08-11 15:16:27 +02:00
|
|
|
dir = NRF_GPIO_PIN_DIR_INPUT;
|
|
|
|
|
input = NRF_GPIO_PIN_INPUT_CONNECT;
|
2024-03-12 16:19:55 +01:00
|
|
|
#if NRF_GPIO_HAS_CLOCKPIN && defined(NRF_TWIM_CLOCKPIN_SDA_NEEDED)
|
|
|
|
|
clockpin = true;
|
|
|
|
|
#endif
|
2022-02-24 15:34:15 +01:00
|
|
|
break;
|
|
|
|
|
#endif /* defined(NRF_PSEL_TWIM) */
|
2022-03-01 17:01:44 +01:00
|
|
|
#if defined(NRF_PSEL_I2S)
|
|
|
|
|
case NRF_FUN_I2S_SCK_M:
|
drivers: pinctrl_nrf: Fix disconnecting of pins
This is a follow-up to commit 223cc3c6bd95821f19c4f2e473f786076667e399.
When a peripheral pin is disconnected, the pinctrl driver should skip
applying of GPIO configuration, as there is no pin number available in
such case, but due to an incorrect check, it actually did not skip it
and used an incorrect pin number for that. In nrfx prior to 3.0.0, this
caused an assertion failure, but because of a fallback routine, things
could still work in most cases (when assertions were disabled) as that
GPIO configuration was just applied to P0.31. Hence the bug was not
discovered until now. In the recent nrfx, this causes a null pointer
dereference, so always a crash.
This commit corrects the mentioned check and also uses the term "psel"
instead of "pin" where it is possible that the value is not a correct
pin number, in the hope of preventing a similar problem in the future.
Signed-off-by: Andrzej Głąbek <andrzej.glabek@nordicsemi.no>
2023-05-08 15:51:31 +02:00
|
|
|
NRF_PSEL_I2S(reg, SCK) = psel;
|
2022-08-11 15:16:27 +02:00
|
|
|
write = 0U;
|
|
|
|
|
dir = NRF_GPIO_PIN_DIR_OUTPUT;
|
|
|
|
|
input = NRF_GPIO_PIN_INPUT_DISCONNECT;
|
2022-03-01 17:01:44 +01:00
|
|
|
break;
|
|
|
|
|
case NRF_FUN_I2S_SCK_S:
|
drivers: pinctrl_nrf: Fix disconnecting of pins
This is a follow-up to commit 223cc3c6bd95821f19c4f2e473f786076667e399.
When a peripheral pin is disconnected, the pinctrl driver should skip
applying of GPIO configuration, as there is no pin number available in
such case, but due to an incorrect check, it actually did not skip it
and used an incorrect pin number for that. In nrfx prior to 3.0.0, this
caused an assertion failure, but because of a fallback routine, things
could still work in most cases (when assertions were disabled) as that
GPIO configuration was just applied to P0.31. Hence the bug was not
discovered until now. In the recent nrfx, this causes a null pointer
dereference, so always a crash.
This commit corrects the mentioned check and also uses the term "psel"
instead of "pin" where it is possible that the value is not a correct
pin number, in the hope of preventing a similar problem in the future.
Signed-off-by: Andrzej Głąbek <andrzej.glabek@nordicsemi.no>
2023-05-08 15:51:31 +02:00
|
|
|
NRF_PSEL_I2S(reg, SCK) = psel;
|
2022-08-11 15:16:27 +02:00
|
|
|
dir = NRF_GPIO_PIN_DIR_INPUT;
|
|
|
|
|
input = NRF_GPIO_PIN_INPUT_CONNECT;
|
2022-03-01 17:01:44 +01:00
|
|
|
break;
|
|
|
|
|
case NRF_FUN_I2S_LRCK_M:
|
drivers: pinctrl_nrf: Fix disconnecting of pins
This is a follow-up to commit 223cc3c6bd95821f19c4f2e473f786076667e399.
When a peripheral pin is disconnected, the pinctrl driver should skip
applying of GPIO configuration, as there is no pin number available in
such case, but due to an incorrect check, it actually did not skip it
and used an incorrect pin number for that. In nrfx prior to 3.0.0, this
caused an assertion failure, but because of a fallback routine, things
could still work in most cases (when assertions were disabled) as that
GPIO configuration was just applied to P0.31. Hence the bug was not
discovered until now. In the recent nrfx, this causes a null pointer
dereference, so always a crash.
This commit corrects the mentioned check and also uses the term "psel"
instead of "pin" where it is possible that the value is not a correct
pin number, in the hope of preventing a similar problem in the future.
Signed-off-by: Andrzej Głąbek <andrzej.glabek@nordicsemi.no>
2023-05-08 15:51:31 +02:00
|
|
|
NRF_PSEL_I2S(reg, LRCK) = psel;
|
2022-08-11 15:16:27 +02:00
|
|
|
write = 0U;
|
|
|
|
|
dir = NRF_GPIO_PIN_DIR_OUTPUT;
|
|
|
|
|
input = NRF_GPIO_PIN_INPUT_DISCONNECT;
|
2022-03-01 17:01:44 +01:00
|
|
|
break;
|
|
|
|
|
case NRF_FUN_I2S_LRCK_S:
|
drivers: pinctrl_nrf: Fix disconnecting of pins
This is a follow-up to commit 223cc3c6bd95821f19c4f2e473f786076667e399.
When a peripheral pin is disconnected, the pinctrl driver should skip
applying of GPIO configuration, as there is no pin number available in
such case, but due to an incorrect check, it actually did not skip it
and used an incorrect pin number for that. In nrfx prior to 3.0.0, this
caused an assertion failure, but because of a fallback routine, things
could still work in most cases (when assertions were disabled) as that
GPIO configuration was just applied to P0.31. Hence the bug was not
discovered until now. In the recent nrfx, this causes a null pointer
dereference, so always a crash.
This commit corrects the mentioned check and also uses the term "psel"
instead of "pin" where it is possible that the value is not a correct
pin number, in the hope of preventing a similar problem in the future.
Signed-off-by: Andrzej Głąbek <andrzej.glabek@nordicsemi.no>
2023-05-08 15:51:31 +02:00
|
|
|
NRF_PSEL_I2S(reg, LRCK) = psel;
|
2022-08-11 15:16:27 +02:00
|
|
|
dir = NRF_GPIO_PIN_DIR_INPUT;
|
|
|
|
|
input = NRF_GPIO_PIN_INPUT_CONNECT;
|
2022-03-01 17:01:44 +01:00
|
|
|
break;
|
|
|
|
|
case NRF_FUN_I2S_SDIN:
|
drivers: pinctrl_nrf: Fix disconnecting of pins
This is a follow-up to commit 223cc3c6bd95821f19c4f2e473f786076667e399.
When a peripheral pin is disconnected, the pinctrl driver should skip
applying of GPIO configuration, as there is no pin number available in
such case, but due to an incorrect check, it actually did not skip it
and used an incorrect pin number for that. In nrfx prior to 3.0.0, this
caused an assertion failure, but because of a fallback routine, things
could still work in most cases (when assertions were disabled) as that
GPIO configuration was just applied to P0.31. Hence the bug was not
discovered until now. In the recent nrfx, this causes a null pointer
dereference, so always a crash.
This commit corrects the mentioned check and also uses the term "psel"
instead of "pin" where it is possible that the value is not a correct
pin number, in the hope of preventing a similar problem in the future.
Signed-off-by: Andrzej Głąbek <andrzej.glabek@nordicsemi.no>
2023-05-08 15:51:31 +02:00
|
|
|
NRF_PSEL_I2S(reg, SDIN) = psel;
|
2022-08-11 15:16:27 +02:00
|
|
|
dir = NRF_GPIO_PIN_DIR_INPUT;
|
|
|
|
|
input = NRF_GPIO_PIN_INPUT_CONNECT;
|
2022-03-01 17:01:44 +01:00
|
|
|
break;
|
|
|
|
|
case NRF_FUN_I2S_SDOUT:
|
drivers: pinctrl_nrf: Fix disconnecting of pins
This is a follow-up to commit 223cc3c6bd95821f19c4f2e473f786076667e399.
When a peripheral pin is disconnected, the pinctrl driver should skip
applying of GPIO configuration, as there is no pin number available in
such case, but due to an incorrect check, it actually did not skip it
and used an incorrect pin number for that. In nrfx prior to 3.0.0, this
caused an assertion failure, but because of a fallback routine, things
could still work in most cases (when assertions were disabled) as that
GPIO configuration was just applied to P0.31. Hence the bug was not
discovered until now. In the recent nrfx, this causes a null pointer
dereference, so always a crash.
This commit corrects the mentioned check and also uses the term "psel"
instead of "pin" where it is possible that the value is not a correct
pin number, in the hope of preventing a similar problem in the future.
Signed-off-by: Andrzej Głąbek <andrzej.glabek@nordicsemi.no>
2023-05-08 15:51:31 +02:00
|
|
|
NRF_PSEL_I2S(reg, SDOUT) = psel;
|
2022-08-11 15:16:27 +02:00
|
|
|
write = 0U;
|
|
|
|
|
dir = NRF_GPIO_PIN_DIR_OUTPUT;
|
|
|
|
|
input = NRF_GPIO_PIN_INPUT_DISCONNECT;
|
2022-03-01 17:01:44 +01:00
|
|
|
break;
|
|
|
|
|
case NRF_FUN_I2S_MCK:
|
drivers: pinctrl_nrf: Fix disconnecting of pins
This is a follow-up to commit 223cc3c6bd95821f19c4f2e473f786076667e399.
When a peripheral pin is disconnected, the pinctrl driver should skip
applying of GPIO configuration, as there is no pin number available in
such case, but due to an incorrect check, it actually did not skip it
and used an incorrect pin number for that. In nrfx prior to 3.0.0, this
caused an assertion failure, but because of a fallback routine, things
could still work in most cases (when assertions were disabled) as that
GPIO configuration was just applied to P0.31. Hence the bug was not
discovered until now. In the recent nrfx, this causes a null pointer
dereference, so always a crash.
This commit corrects the mentioned check and also uses the term "psel"
instead of "pin" where it is possible that the value is not a correct
pin number, in the hope of preventing a similar problem in the future.
Signed-off-by: Andrzej Głąbek <andrzej.glabek@nordicsemi.no>
2023-05-08 15:51:31 +02:00
|
|
|
NRF_PSEL_I2S(reg, MCK) = psel;
|
2022-08-11 15:16:27 +02:00
|
|
|
write = 0U;
|
|
|
|
|
dir = NRF_GPIO_PIN_DIR_OUTPUT;
|
|
|
|
|
input = NRF_GPIO_PIN_INPUT_DISCONNECT;
|
2022-03-01 17:01:44 +01:00
|
|
|
break;
|
|
|
|
|
#endif /* defined(NRF_PSEL_I2S) */
|
|
|
|
|
#if defined(NRF_PSEL_PDM)
|
|
|
|
|
case NRF_FUN_PDM_CLK:
|
drivers: pinctrl_nrf: Fix disconnecting of pins
This is a follow-up to commit 223cc3c6bd95821f19c4f2e473f786076667e399.
When a peripheral pin is disconnected, the pinctrl driver should skip
applying of GPIO configuration, as there is no pin number available in
such case, but due to an incorrect check, it actually did not skip it
and used an incorrect pin number for that. In nrfx prior to 3.0.0, this
caused an assertion failure, but because of a fallback routine, things
could still work in most cases (when assertions were disabled) as that
GPIO configuration was just applied to P0.31. Hence the bug was not
discovered until now. In the recent nrfx, this causes a null pointer
dereference, so always a crash.
This commit corrects the mentioned check and also uses the term "psel"
instead of "pin" where it is possible that the value is not a correct
pin number, in the hope of preventing a similar problem in the future.
Signed-off-by: Andrzej Głąbek <andrzej.glabek@nordicsemi.no>
2023-05-08 15:51:31 +02:00
|
|
|
NRF_PSEL_PDM(reg, CLK) = psel;
|
2022-08-11 15:16:27 +02:00
|
|
|
write = 0U;
|
|
|
|
|
dir = NRF_GPIO_PIN_DIR_OUTPUT;
|
|
|
|
|
input = NRF_GPIO_PIN_INPUT_DISCONNECT;
|
2022-03-01 17:01:44 +01:00
|
|
|
break;
|
|
|
|
|
case NRF_FUN_PDM_DIN:
|
drivers: pinctrl_nrf: Fix disconnecting of pins
This is a follow-up to commit 223cc3c6bd95821f19c4f2e473f786076667e399.
When a peripheral pin is disconnected, the pinctrl driver should skip
applying of GPIO configuration, as there is no pin number available in
such case, but due to an incorrect check, it actually did not skip it
and used an incorrect pin number for that. In nrfx prior to 3.0.0, this
caused an assertion failure, but because of a fallback routine, things
could still work in most cases (when assertions were disabled) as that
GPIO configuration was just applied to P0.31. Hence the bug was not
discovered until now. In the recent nrfx, this causes a null pointer
dereference, so always a crash.
This commit corrects the mentioned check and also uses the term "psel"
instead of "pin" where it is possible that the value is not a correct
pin number, in the hope of preventing a similar problem in the future.
Signed-off-by: Andrzej Głąbek <andrzej.glabek@nordicsemi.no>
2023-05-08 15:51:31 +02:00
|
|
|
NRF_PSEL_PDM(reg, DIN) = psel;
|
2022-08-11 15:16:27 +02:00
|
|
|
dir = NRF_GPIO_PIN_DIR_INPUT;
|
|
|
|
|
input = NRF_GPIO_PIN_INPUT_CONNECT;
|
2022-03-01 17:01:44 +01:00
|
|
|
break;
|
|
|
|
|
#endif /* defined(NRF_PSEL_PDM) */
|
2022-03-04 17:11:37 +01:00
|
|
|
#if defined(NRF_PSEL_PWM)
|
|
|
|
|
case NRF_FUN_PWM_OUT0:
|
drivers: pinctrl_nrf: Fix disconnecting of pins
This is a follow-up to commit 223cc3c6bd95821f19c4f2e473f786076667e399.
When a peripheral pin is disconnected, the pinctrl driver should skip
applying of GPIO configuration, as there is no pin number available in
such case, but due to an incorrect check, it actually did not skip it
and used an incorrect pin number for that. In nrfx prior to 3.0.0, this
caused an assertion failure, but because of a fallback routine, things
could still work in most cases (when assertions were disabled) as that
GPIO configuration was just applied to P0.31. Hence the bug was not
discovered until now. In the recent nrfx, this causes a null pointer
dereference, so always a crash.
This commit corrects the mentioned check and also uses the term "psel"
instead of "pin" where it is possible that the value is not a correct
pin number, in the hope of preventing a similar problem in the future.
Signed-off-by: Andrzej Głąbek <andrzej.glabek@nordicsemi.no>
2023-05-08 15:51:31 +02:00
|
|
|
NRF_PSEL_PWM(reg, OUT[0]) = psel;
|
2022-08-11 15:16:27 +02:00
|
|
|
write = NRF_GET_INVERT(pins[i]);
|
|
|
|
|
dir = NRF_GPIO_PIN_DIR_OUTPUT;
|
|
|
|
|
input = NRF_GPIO_PIN_INPUT_DISCONNECT;
|
2022-03-04 17:11:37 +01:00
|
|
|
break;
|
|
|
|
|
case NRF_FUN_PWM_OUT1:
|
drivers: pinctrl_nrf: Fix disconnecting of pins
This is a follow-up to commit 223cc3c6bd95821f19c4f2e473f786076667e399.
When a peripheral pin is disconnected, the pinctrl driver should skip
applying of GPIO configuration, as there is no pin number available in
such case, but due to an incorrect check, it actually did not skip it
and used an incorrect pin number for that. In nrfx prior to 3.0.0, this
caused an assertion failure, but because of a fallback routine, things
could still work in most cases (when assertions were disabled) as that
GPIO configuration was just applied to P0.31. Hence the bug was not
discovered until now. In the recent nrfx, this causes a null pointer
dereference, so always a crash.
This commit corrects the mentioned check and also uses the term "psel"
instead of "pin" where it is possible that the value is not a correct
pin number, in the hope of preventing a similar problem in the future.
Signed-off-by: Andrzej Głąbek <andrzej.glabek@nordicsemi.no>
2023-05-08 15:51:31 +02:00
|
|
|
NRF_PSEL_PWM(reg, OUT[1]) = psel;
|
2022-08-11 15:16:27 +02:00
|
|
|
write = NRF_GET_INVERT(pins[i]);
|
|
|
|
|
dir = NRF_GPIO_PIN_DIR_OUTPUT;
|
|
|
|
|
input = NRF_GPIO_PIN_INPUT_DISCONNECT;
|
2022-03-04 17:11:37 +01:00
|
|
|
break;
|
|
|
|
|
case NRF_FUN_PWM_OUT2:
|
drivers: pinctrl_nrf: Fix disconnecting of pins
This is a follow-up to commit 223cc3c6bd95821f19c4f2e473f786076667e399.
When a peripheral pin is disconnected, the pinctrl driver should skip
applying of GPIO configuration, as there is no pin number available in
such case, but due to an incorrect check, it actually did not skip it
and used an incorrect pin number for that. In nrfx prior to 3.0.0, this
caused an assertion failure, but because of a fallback routine, things
could still work in most cases (when assertions were disabled) as that
GPIO configuration was just applied to P0.31. Hence the bug was not
discovered until now. In the recent nrfx, this causes a null pointer
dereference, so always a crash.
This commit corrects the mentioned check and also uses the term "psel"
instead of "pin" where it is possible that the value is not a correct
pin number, in the hope of preventing a similar problem in the future.
Signed-off-by: Andrzej Głąbek <andrzej.glabek@nordicsemi.no>
2023-05-08 15:51:31 +02:00
|
|
|
NRF_PSEL_PWM(reg, OUT[2]) = psel;
|
2022-08-11 15:16:27 +02:00
|
|
|
write = NRF_GET_INVERT(pins[i]);
|
|
|
|
|
dir = NRF_GPIO_PIN_DIR_OUTPUT;
|
|
|
|
|
input = NRF_GPIO_PIN_INPUT_DISCONNECT;
|
2022-03-04 17:11:37 +01:00
|
|
|
break;
|
|
|
|
|
case NRF_FUN_PWM_OUT3:
|
drivers: pinctrl_nrf: Fix disconnecting of pins
This is a follow-up to commit 223cc3c6bd95821f19c4f2e473f786076667e399.
When a peripheral pin is disconnected, the pinctrl driver should skip
applying of GPIO configuration, as there is no pin number available in
such case, but due to an incorrect check, it actually did not skip it
and used an incorrect pin number for that. In nrfx prior to 3.0.0, this
caused an assertion failure, but because of a fallback routine, things
could still work in most cases (when assertions were disabled) as that
GPIO configuration was just applied to P0.31. Hence the bug was not
discovered until now. In the recent nrfx, this causes a null pointer
dereference, so always a crash.
This commit corrects the mentioned check and also uses the term "psel"
instead of "pin" where it is possible that the value is not a correct
pin number, in the hope of preventing a similar problem in the future.
Signed-off-by: Andrzej Głąbek <andrzej.glabek@nordicsemi.no>
2023-05-08 15:51:31 +02:00
|
|
|
NRF_PSEL_PWM(reg, OUT[3]) = psel;
|
2022-08-11 15:16:27 +02:00
|
|
|
write = NRF_GET_INVERT(pins[i]);
|
|
|
|
|
dir = NRF_GPIO_PIN_DIR_OUTPUT;
|
|
|
|
|
input = NRF_GPIO_PIN_INPUT_DISCONNECT;
|
2022-03-04 17:11:37 +01:00
|
|
|
break;
|
|
|
|
|
#endif /* defined(NRF_PSEL_PWM) */
|
|
|
|
|
#if defined(NRF_PSEL_QDEC)
|
|
|
|
|
case NRF_FUN_QDEC_A:
|
drivers: pinctrl_nrf: Fix disconnecting of pins
This is a follow-up to commit 223cc3c6bd95821f19c4f2e473f786076667e399.
When a peripheral pin is disconnected, the pinctrl driver should skip
applying of GPIO configuration, as there is no pin number available in
such case, but due to an incorrect check, it actually did not skip it
and used an incorrect pin number for that. In nrfx prior to 3.0.0, this
caused an assertion failure, but because of a fallback routine, things
could still work in most cases (when assertions were disabled) as that
GPIO configuration was just applied to P0.31. Hence the bug was not
discovered until now. In the recent nrfx, this causes a null pointer
dereference, so always a crash.
This commit corrects the mentioned check and also uses the term "psel"
instead of "pin" where it is possible that the value is not a correct
pin number, in the hope of preventing a similar problem in the future.
Signed-off-by: Andrzej Głąbek <andrzej.glabek@nordicsemi.no>
2023-05-08 15:51:31 +02:00
|
|
|
NRF_PSEL_QDEC(reg, A) = psel;
|
2022-08-11 15:16:27 +02:00
|
|
|
dir = NRF_GPIO_PIN_DIR_INPUT;
|
|
|
|
|
input = NRF_GPIO_PIN_INPUT_CONNECT;
|
2022-03-04 17:11:37 +01:00
|
|
|
break;
|
|
|
|
|
case NRF_FUN_QDEC_B:
|
drivers: pinctrl_nrf: Fix disconnecting of pins
This is a follow-up to commit 223cc3c6bd95821f19c4f2e473f786076667e399.
When a peripheral pin is disconnected, the pinctrl driver should skip
applying of GPIO configuration, as there is no pin number available in
such case, but due to an incorrect check, it actually did not skip it
and used an incorrect pin number for that. In nrfx prior to 3.0.0, this
caused an assertion failure, but because of a fallback routine, things
could still work in most cases (when assertions were disabled) as that
GPIO configuration was just applied to P0.31. Hence the bug was not
discovered until now. In the recent nrfx, this causes a null pointer
dereference, so always a crash.
This commit corrects the mentioned check and also uses the term "psel"
instead of "pin" where it is possible that the value is not a correct
pin number, in the hope of preventing a similar problem in the future.
Signed-off-by: Andrzej Głąbek <andrzej.glabek@nordicsemi.no>
2023-05-08 15:51:31 +02:00
|
|
|
NRF_PSEL_QDEC(reg, B) = psel;
|
2022-08-11 15:16:27 +02:00
|
|
|
dir = NRF_GPIO_PIN_DIR_INPUT;
|
|
|
|
|
input = NRF_GPIO_PIN_INPUT_CONNECT;
|
2022-05-06 19:51:41 +02:00
|
|
|
break;
|
2022-03-04 17:11:37 +01:00
|
|
|
case NRF_FUN_QDEC_LED:
|
drivers: pinctrl_nrf: Fix disconnecting of pins
This is a follow-up to commit 223cc3c6bd95821f19c4f2e473f786076667e399.
When a peripheral pin is disconnected, the pinctrl driver should skip
applying of GPIO configuration, as there is no pin number available in
such case, but due to an incorrect check, it actually did not skip it
and used an incorrect pin number for that. In nrfx prior to 3.0.0, this
caused an assertion failure, but because of a fallback routine, things
could still work in most cases (when assertions were disabled) as that
GPIO configuration was just applied to P0.31. Hence the bug was not
discovered until now. In the recent nrfx, this causes a null pointer
dereference, so always a crash.
This commit corrects the mentioned check and also uses the term "psel"
instead of "pin" where it is possible that the value is not a correct
pin number, in the hope of preventing a similar problem in the future.
Signed-off-by: Andrzej Głąbek <andrzej.glabek@nordicsemi.no>
2023-05-08 15:51:31 +02:00
|
|
|
NRF_PSEL_QDEC(reg, LED) = psel;
|
2022-08-11 15:16:27 +02:00
|
|
|
dir = NRF_GPIO_PIN_DIR_INPUT;
|
|
|
|
|
input = NRF_GPIO_PIN_INPUT_CONNECT;
|
2022-03-04 17:11:37 +01:00
|
|
|
break;
|
|
|
|
|
#endif /* defined(NRF_PSEL_QDEC) */
|
|
|
|
|
#if defined(NRF_PSEL_QSPI)
|
|
|
|
|
case NRF_FUN_QSPI_SCK:
|
drivers: pinctrl_nrf: Fix disconnecting of pins
This is a follow-up to commit 223cc3c6bd95821f19c4f2e473f786076667e399.
When a peripheral pin is disconnected, the pinctrl driver should skip
applying of GPIO configuration, as there is no pin number available in
such case, but due to an incorrect check, it actually did not skip it
and used an incorrect pin number for that. In nrfx prior to 3.0.0, this
caused an assertion failure, but because of a fallback routine, things
could still work in most cases (when assertions were disabled) as that
GPIO configuration was just applied to P0.31. Hence the bug was not
discovered until now. In the recent nrfx, this causes a null pointer
dereference, so always a crash.
This commit corrects the mentioned check and also uses the term "psel"
instead of "pin" where it is possible that the value is not a correct
pin number, in the hope of preventing a similar problem in the future.
Signed-off-by: Andrzej Głąbek <andrzej.glabek@nordicsemi.no>
2023-05-08 15:51:31 +02:00
|
|
|
NRF_PSEL_QSPI(reg, SCK) = psel;
|
2022-08-11 15:16:27 +02:00
|
|
|
dir = NRF_GPIO_PIN_DIR_INPUT;
|
|
|
|
|
input = NRF_GPIO_PIN_INPUT_DISCONNECT;
|
2022-03-04 17:11:37 +01:00
|
|
|
break;
|
|
|
|
|
case NRF_FUN_QSPI_CSN:
|
drivers: pinctrl_nrf: Fix disconnecting of pins
This is a follow-up to commit 223cc3c6bd95821f19c4f2e473f786076667e399.
When a peripheral pin is disconnected, the pinctrl driver should skip
applying of GPIO configuration, as there is no pin number available in
such case, but due to an incorrect check, it actually did not skip it
and used an incorrect pin number for that. In nrfx prior to 3.0.0, this
caused an assertion failure, but because of a fallback routine, things
could still work in most cases (when assertions were disabled) as that
GPIO configuration was just applied to P0.31. Hence the bug was not
discovered until now. In the recent nrfx, this causes a null pointer
dereference, so always a crash.
This commit corrects the mentioned check and also uses the term "psel"
instead of "pin" where it is possible that the value is not a correct
pin number, in the hope of preventing a similar problem in the future.
Signed-off-by: Andrzej Głąbek <andrzej.glabek@nordicsemi.no>
2023-05-08 15:51:31 +02:00
|
|
|
NRF_PSEL_QSPI(reg, CSN) = psel;
|
2022-09-19 13:34:46 +02:00
|
|
|
write = 1U;
|
|
|
|
|
dir = NRF_GPIO_PIN_DIR_OUTPUT;
|
2022-08-11 15:16:27 +02:00
|
|
|
input = NRF_GPIO_PIN_INPUT_DISCONNECT;
|
2022-03-04 17:11:37 +01:00
|
|
|
break;
|
|
|
|
|
case NRF_FUN_QSPI_IO0:
|
drivers: pinctrl_nrf: Fix disconnecting of pins
This is a follow-up to commit 223cc3c6bd95821f19c4f2e473f786076667e399.
When a peripheral pin is disconnected, the pinctrl driver should skip
applying of GPIO configuration, as there is no pin number available in
such case, but due to an incorrect check, it actually did not skip it
and used an incorrect pin number for that. In nrfx prior to 3.0.0, this
caused an assertion failure, but because of a fallback routine, things
could still work in most cases (when assertions were disabled) as that
GPIO configuration was just applied to P0.31. Hence the bug was not
discovered until now. In the recent nrfx, this causes a null pointer
dereference, so always a crash.
This commit corrects the mentioned check and also uses the term "psel"
instead of "pin" where it is possible that the value is not a correct
pin number, in the hope of preventing a similar problem in the future.
Signed-off-by: Andrzej Głąbek <andrzej.glabek@nordicsemi.no>
2023-05-08 15:51:31 +02:00
|
|
|
NRF_PSEL_QSPI(reg, IO0) = psel;
|
2022-08-11 15:16:27 +02:00
|
|
|
dir = NRF_GPIO_PIN_DIR_INPUT;
|
|
|
|
|
input = NRF_GPIO_PIN_INPUT_DISCONNECT;
|
2022-05-06 19:51:41 +02:00
|
|
|
break;
|
2022-03-04 17:11:37 +01:00
|
|
|
case NRF_FUN_QSPI_IO1:
|
drivers: pinctrl_nrf: Fix disconnecting of pins
This is a follow-up to commit 223cc3c6bd95821f19c4f2e473f786076667e399.
When a peripheral pin is disconnected, the pinctrl driver should skip
applying of GPIO configuration, as there is no pin number available in
such case, but due to an incorrect check, it actually did not skip it
and used an incorrect pin number for that. In nrfx prior to 3.0.0, this
caused an assertion failure, but because of a fallback routine, things
could still work in most cases (when assertions were disabled) as that
GPIO configuration was just applied to P0.31. Hence the bug was not
discovered until now. In the recent nrfx, this causes a null pointer
dereference, so always a crash.
This commit corrects the mentioned check and also uses the term "psel"
instead of "pin" where it is possible that the value is not a correct
pin number, in the hope of preventing a similar problem in the future.
Signed-off-by: Andrzej Głąbek <andrzej.glabek@nordicsemi.no>
2023-05-08 15:51:31 +02:00
|
|
|
NRF_PSEL_QSPI(reg, IO1) = psel;
|
2022-08-11 15:16:27 +02:00
|
|
|
dir = NRF_GPIO_PIN_DIR_INPUT;
|
|
|
|
|
input = NRF_GPIO_PIN_INPUT_DISCONNECT;
|
2022-05-06 19:51:41 +02:00
|
|
|
break;
|
2022-03-04 17:11:37 +01:00
|
|
|
case NRF_FUN_QSPI_IO2:
|
drivers: pinctrl_nrf: Fix disconnecting of pins
This is a follow-up to commit 223cc3c6bd95821f19c4f2e473f786076667e399.
When a peripheral pin is disconnected, the pinctrl driver should skip
applying of GPIO configuration, as there is no pin number available in
such case, but due to an incorrect check, it actually did not skip it
and used an incorrect pin number for that. In nrfx prior to 3.0.0, this
caused an assertion failure, but because of a fallback routine, things
could still work in most cases (when assertions were disabled) as that
GPIO configuration was just applied to P0.31. Hence the bug was not
discovered until now. In the recent nrfx, this causes a null pointer
dereference, so always a crash.
This commit corrects the mentioned check and also uses the term "psel"
instead of "pin" where it is possible that the value is not a correct
pin number, in the hope of preventing a similar problem in the future.
Signed-off-by: Andrzej Głąbek <andrzej.glabek@nordicsemi.no>
2023-05-08 15:51:31 +02:00
|
|
|
NRF_PSEL_QSPI(reg, IO2) = psel;
|
2022-08-11 15:16:27 +02:00
|
|
|
dir = NRF_GPIO_PIN_DIR_INPUT;
|
|
|
|
|
input = NRF_GPIO_PIN_INPUT_DISCONNECT;
|
2022-05-06 19:51:41 +02:00
|
|
|
break;
|
2022-03-04 17:11:37 +01:00
|
|
|
case NRF_FUN_QSPI_IO3:
|
drivers: pinctrl_nrf: Fix disconnecting of pins
This is a follow-up to commit 223cc3c6bd95821f19c4f2e473f786076667e399.
When a peripheral pin is disconnected, the pinctrl driver should skip
applying of GPIO configuration, as there is no pin number available in
such case, but due to an incorrect check, it actually did not skip it
and used an incorrect pin number for that. In nrfx prior to 3.0.0, this
caused an assertion failure, but because of a fallback routine, things
could still work in most cases (when assertions were disabled) as that
GPIO configuration was just applied to P0.31. Hence the bug was not
discovered until now. In the recent nrfx, this causes a null pointer
dereference, so always a crash.
This commit corrects the mentioned check and also uses the term "psel"
instead of "pin" where it is possible that the value is not a correct
pin number, in the hope of preventing a similar problem in the future.
Signed-off-by: Andrzej Głąbek <andrzej.glabek@nordicsemi.no>
2023-05-08 15:51:31 +02:00
|
|
|
NRF_PSEL_QSPI(reg, IO3) = psel;
|
2022-08-11 15:16:27 +02:00
|
|
|
dir = NRF_GPIO_PIN_DIR_INPUT;
|
|
|
|
|
input = NRF_GPIO_PIN_INPUT_DISCONNECT;
|
2022-03-04 17:11:37 +01:00
|
|
|
break;
|
|
|
|
|
#endif /* defined(NRF_PSEL_QSPI) */
|
2021-08-10 11:22:31 +02:00
|
|
|
default:
|
|
|
|
|
return -ENOTSUP;
|
|
|
|
|
}
|
2022-08-11 15:16:27 +02:00
|
|
|
|
|
|
|
|
/* configure GPIO properties */
|
drivers: pinctrl_nrf: Fix disconnecting of pins
This is a follow-up to commit 223cc3c6bd95821f19c4f2e473f786076667e399.
When a peripheral pin is disconnected, the pinctrl driver should skip
applying of GPIO configuration, as there is no pin number available in
such case, but due to an incorrect check, it actually did not skip it
and used an incorrect pin number for that. In nrfx prior to 3.0.0, this
caused an assertion failure, but because of a fallback routine, things
could still work in most cases (when assertions were disabled) as that
GPIO configuration was just applied to P0.31. Hence the bug was not
discovered until now. In the recent nrfx, this causes a null pointer
dereference, so always a crash.
This commit corrects the mentioned check and also uses the term "psel"
instead of "pin" where it is possible that the value is not a correct
pin number, in the hope of preventing a similar problem in the future.
Signed-off-by: Andrzej Głąbek <andrzej.glabek@nordicsemi.no>
2023-05-08 15:51:31 +02:00
|
|
|
if (psel != PSEL_DISCONNECTED) {
|
|
|
|
|
uint32_t pin = psel;
|
|
|
|
|
|
2022-08-11 15:16:27 +02:00
|
|
|
if (write != NO_WRITE) {
|
|
|
|
|
nrf_gpio_pin_write(pin, write);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* force input and disconnected buffer for low power */
|
|
|
|
|
if (NRF_GET_LP(pins[i]) == NRF_LP_ENABLE) {
|
|
|
|
|
dir = NRF_GPIO_PIN_DIR_INPUT;
|
|
|
|
|
input = NRF_GPIO_PIN_INPUT_DISCONNECT;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
nrf_gpio_cfg(pin, dir, input, NRF_GET_PULL(pins[i]),
|
|
|
|
|
drive, NRF_GPIO_PIN_NOSENSE);
|
2024-03-12 16:19:55 +01:00
|
|
|
#if NRF_GPIO_HAS_CLOCKPIN
|
|
|
|
|
nrf_gpio_pin_clock_set(pin, clockpin);
|
|
|
|
|
#endif
|
2022-08-11 15:16:27 +02:00
|
|
|
}
|
2021-08-10 11:22:31 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
