* [PATCH 01/11] pinctrl: airoha: an7581: add missed gpio32 pin group
From: Mikhail Kshevetskiy @ 2026-06-06 2:03 UTC (permalink / raw)
To: Lorenzo Bianconi, Sean Wang, Linus Walleij, Matthias Brugger,
AngeloGioacchino Del Regno, Benjamin Larsson, Christian Marangi,
linux-mediatek, linux-gpio, linux-kernel, linux-arm-kernel,
Markus Gothe, Matheus Sampaio Queiroga
Cc: Mikhail Kshevetskiy
In-Reply-To: <20260606020342.1256509-1-mikhail.kshevetskiy@iopsys.eu>
gpio32 pin group is missed for an7581 SoC. This patch add it.
Fixes: 1c8ace2d0725 ("pinctrl: airoha: Add support for EN7581 SoC")
Signed-off-by: Mikhail Kshevetskiy <mikhail.kshevetskiy@iopsys.eu>
---
drivers/pinctrl/mediatek/pinctrl-airoha.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/pinctrl/mediatek/pinctrl-airoha.c b/drivers/pinctrl/mediatek/pinctrl-airoha.c
index 995ba6175c95..805166223228 100644
--- a/drivers/pinctrl/mediatek/pinctrl-airoha.c
+++ b/drivers/pinctrl/mediatek/pinctrl-airoha.c
@@ -539,6 +539,7 @@ static const int en7581_gpio28_pins[] = { 41 };
static const int en7581_gpio29_pins[] = { 42 };
static const int en7581_gpio30_pins[] = { 43 };
static const int en7581_gpio31_pins[] = { 44 };
+static const int en7581_gpio32_pins[] = { 45 };
static const int en7581_gpio33_pins[] = { 46 };
static const int en7581_gpio34_pins[] = { 47 };
static const int en7581_gpio35_pins[] = { 48 };
@@ -623,6 +624,7 @@ static const struct pingroup en7581_pinctrl_groups[] = {
PINCTRL_PIN_GROUP("gpio29", en7581_gpio29),
PINCTRL_PIN_GROUP("gpio30", en7581_gpio30),
PINCTRL_PIN_GROUP("gpio31", en7581_gpio31),
+ PINCTRL_PIN_GROUP("gpio32", en7581_gpio32),
PINCTRL_PIN_GROUP("gpio33", en7581_gpio33),
PINCTRL_PIN_GROUP("gpio34", en7581_gpio34),
PINCTRL_PIN_GROUP("gpio35", en7581_gpio35),
--
2.53.0
^ permalink raw reply related
* [PATCH 00/11] pinctrl: airoha: small fixes
From: Mikhail Kshevetskiy @ 2026-06-06 2:03 UTC (permalink / raw)
To: Lorenzo Bianconi, Sean Wang, Linus Walleij, Matthias Brugger,
AngeloGioacchino Del Regno, Benjamin Larsson, Christian Marangi,
linux-mediatek, linux-gpio, linux-kernel, linux-arm-kernel,
Markus Gothe, Matheus Sampaio Queiroga
Cc: Mikhail Kshevetskiy
This is a set of small fixes for Airoha pinctrl driver.
Mikhail Kshevetskiy (11):
pinctrl: airoha: an7581: add missed gpio32 pin group
pinctrl: airoha: an7583: add missed gpio32 pin group
pinctrl: airoha: an7581: fix misprint in gpio19 pinconf
pinctrl: airoha: an7583: fix misprint in gpio19 pinconf
pinctrl: airoha: an7581: fix incorrect led mapping in phy4_led1 pin
function
pinctrl: airoha: an7583: fix incorrect led mapping in phy4_led1 pin
function
pinctrl: airoha: fix pwm pin function for an7581 and an7583
pinctrl: airoha: an7583: fix gpio21 pin group
pinctrl: airoha: an7583: add missed gpio22 pin group
pinctrl: airoha: an7583: fix phy1_led1 pin function
pinctrl: airoha: an7583: remove undefined groups from pcm_spi pin
function
drivers/pinctrl/mediatek/pinctrl-airoha.c | 122 +++++++++++++++++-----
1 file changed, 98 insertions(+), 24 deletions(-)
--
2.53.0
^ permalink raw reply
* [PATCH 02/11] pinctrl: airoha: an7583: add missed gpio32 pin group
From: Mikhail Kshevetskiy @ 2026-06-06 2:03 UTC (permalink / raw)
To: Lorenzo Bianconi, Sean Wang, Linus Walleij, Matthias Brugger,
AngeloGioacchino Del Regno, Benjamin Larsson, Christian Marangi,
linux-mediatek, linux-gpio, linux-kernel, linux-arm-kernel,
Markus Gothe, Matheus Sampaio Queiroga
Cc: Mikhail Kshevetskiy
In-Reply-To: <20260606020342.1256509-1-mikhail.kshevetskiy@iopsys.eu>
gpio32 pin group is missed for an7583 SoC. This patch add it.
Fixes: 3ffeb17a9a27 ("pinctrl: airoha: add support for Airoha AN7583 PINs")
Signed-off-by: Mikhail Kshevetskiy <mikhail.kshevetskiy@iopsys.eu>
---
drivers/pinctrl/mediatek/pinctrl-airoha.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/pinctrl/mediatek/pinctrl-airoha.c b/drivers/pinctrl/mediatek/pinctrl-airoha.c
index 805166223228..c0aed1b60792 100644
--- a/drivers/pinctrl/mediatek/pinctrl-airoha.c
+++ b/drivers/pinctrl/mediatek/pinctrl-airoha.c
@@ -758,6 +758,7 @@ static const int an7583_gpio28_pins[] = { 30 };
static const int an7583_gpio29_pins[] = { 31 };
static const int an7583_gpio30_pins[] = { 32 };
static const int an7583_gpio31_pins[] = { 33 };
+static const int an7583_gpio32_pins[] = { 34 };
static const int an7583_gpio33_pins[] = { 35 };
static const int an7583_gpio34_pins[] = { 36 };
static const int an7583_gpio35_pins[] = { 37 };
@@ -836,6 +837,7 @@ static const struct pingroup an7583_pinctrl_groups[] = {
PINCTRL_PIN_GROUP("gpio29", an7583_gpio29),
PINCTRL_PIN_GROUP("gpio30", an7583_gpio30),
PINCTRL_PIN_GROUP("gpio31", an7583_gpio31),
+ PINCTRL_PIN_GROUP("gpio32", an7583_gpio32),
PINCTRL_PIN_GROUP("gpio33", an7583_gpio33),
PINCTRL_PIN_GROUP("gpio34", an7583_gpio34),
PINCTRL_PIN_GROUP("gpio35", an7583_gpio35),
--
2.53.0
^ permalink raw reply related
* [PATCH 03/11] pinctrl: airoha: an7581: fix misprint in gpio19 pinconf
From: Mikhail Kshevetskiy @ 2026-06-06 2:03 UTC (permalink / raw)
To: Lorenzo Bianconi, Sean Wang, Linus Walleij, Matthias Brugger,
AngeloGioacchino Del Regno, Benjamin Larsson, Christian Marangi,
linux-mediatek, linux-gpio, linux-kernel, linux-arm-kernel,
Markus Gothe, Matheus Sampaio Queiroga
Cc: Mikhail Kshevetskiy
In-Reply-To: <20260606020342.1256509-1-mikhail.kshevetskiy@iopsys.eu>
Pin 32 (gpio19) duplicate pinconf settings of pin 31. Fix it using
a proper bit number in the configuration register.
Fixes: 1c8ace2d0725 ("pinctrl: airoha: Add support for EN7581 SoC")
Signed-off-by: Mikhail Kshevetskiy <mikhail.kshevetskiy@iopsys.eu>
---
drivers/pinctrl/mediatek/pinctrl-airoha.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/pinctrl/mediatek/pinctrl-airoha.c b/drivers/pinctrl/mediatek/pinctrl-airoha.c
index c0aed1b60792..14b235727736 100644
--- a/drivers/pinctrl/mediatek/pinctrl-airoha.c
+++ b/drivers/pinctrl/mediatek/pinctrl-airoha.c
@@ -1798,7 +1798,7 @@ static const struct airoha_pinctrl_conf en7581_pinctrl_pullup_conf[] = {
PINCTRL_CONF_DESC(29, REG_GPIO_L_PU, BIT(16)),
PINCTRL_CONF_DESC(30, REG_GPIO_L_PU, BIT(17)),
PINCTRL_CONF_DESC(31, REG_GPIO_L_PU, BIT(18)),
- PINCTRL_CONF_DESC(32, REG_GPIO_L_PU, BIT(18)),
+ PINCTRL_CONF_DESC(32, REG_GPIO_L_PU, BIT(19)),
PINCTRL_CONF_DESC(33, REG_GPIO_L_PU, BIT(20)),
PINCTRL_CONF_DESC(34, REG_GPIO_L_PU, BIT(21)),
PINCTRL_CONF_DESC(35, REG_GPIO_L_PU, BIT(22)),
@@ -1915,7 +1915,7 @@ static const struct airoha_pinctrl_conf en7581_pinctrl_pulldown_conf[] = {
PINCTRL_CONF_DESC(29, REG_GPIO_L_PD, BIT(16)),
PINCTRL_CONF_DESC(30, REG_GPIO_L_PD, BIT(17)),
PINCTRL_CONF_DESC(31, REG_GPIO_L_PD, BIT(18)),
- PINCTRL_CONF_DESC(32, REG_GPIO_L_PD, BIT(18)),
+ PINCTRL_CONF_DESC(32, REG_GPIO_L_PD, BIT(19)),
PINCTRL_CONF_DESC(33, REG_GPIO_L_PD, BIT(20)),
PINCTRL_CONF_DESC(34, REG_GPIO_L_PD, BIT(21)),
PINCTRL_CONF_DESC(35, REG_GPIO_L_PD, BIT(22)),
@@ -2032,7 +2032,7 @@ static const struct airoha_pinctrl_conf en7581_pinctrl_drive_e2_conf[] = {
PINCTRL_CONF_DESC(29, REG_GPIO_L_E2, BIT(16)),
PINCTRL_CONF_DESC(30, REG_GPIO_L_E2, BIT(17)),
PINCTRL_CONF_DESC(31, REG_GPIO_L_E2, BIT(18)),
- PINCTRL_CONF_DESC(32, REG_GPIO_L_E2, BIT(18)),
+ PINCTRL_CONF_DESC(32, REG_GPIO_L_E2, BIT(19)),
PINCTRL_CONF_DESC(33, REG_GPIO_L_E2, BIT(20)),
PINCTRL_CONF_DESC(34, REG_GPIO_L_E2, BIT(21)),
PINCTRL_CONF_DESC(35, REG_GPIO_L_E2, BIT(22)),
@@ -2149,7 +2149,7 @@ static const struct airoha_pinctrl_conf en7581_pinctrl_drive_e4_conf[] = {
PINCTRL_CONF_DESC(29, REG_GPIO_L_E4, BIT(16)),
PINCTRL_CONF_DESC(30, REG_GPIO_L_E4, BIT(17)),
PINCTRL_CONF_DESC(31, REG_GPIO_L_E4, BIT(18)),
- PINCTRL_CONF_DESC(32, REG_GPIO_L_E4, BIT(18)),
+ PINCTRL_CONF_DESC(32, REG_GPIO_L_E4, BIT(19)),
PINCTRL_CONF_DESC(33, REG_GPIO_L_E4, BIT(20)),
PINCTRL_CONF_DESC(34, REG_GPIO_L_E4, BIT(21)),
PINCTRL_CONF_DESC(35, REG_GPIO_L_E4, BIT(22)),
--
2.53.0
^ permalink raw reply related
* [PATCH 04/11] pinctrl: airoha: an7583: fix misprint in gpio19 pinconf
From: Mikhail Kshevetskiy @ 2026-06-06 2:03 UTC (permalink / raw)
To: Lorenzo Bianconi, Sean Wang, Linus Walleij, Matthias Brugger,
AngeloGioacchino Del Regno, Benjamin Larsson, Christian Marangi,
linux-mediatek, linux-gpio, linux-kernel, linux-arm-kernel,
Markus Gothe, Matheus Sampaio Queiroga
Cc: Mikhail Kshevetskiy
In-Reply-To: <20260606020342.1256509-1-mikhail.kshevetskiy@iopsys.eu>
Pin 21 (gpio19) duplicate pinconf settings of pin 20. Fix it using
a proper bit number in the configuration register.
Fixes: 3ffeb17a9a27 ("pinctrl: airoha: add support for Airoha AN7583 PINs")
Signed-off-by: Mikhail Kshevetskiy <mikhail.kshevetskiy@iopsys.eu>
---
drivers/pinctrl/mediatek/pinctrl-airoha.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/pinctrl/mediatek/pinctrl-airoha.c b/drivers/pinctrl/mediatek/pinctrl-airoha.c
index 14b235727736..34eef79d058f 100644
--- a/drivers/pinctrl/mediatek/pinctrl-airoha.c
+++ b/drivers/pinctrl/mediatek/pinctrl-airoha.c
@@ -1851,7 +1851,7 @@ static const struct airoha_pinctrl_conf an7583_pinctrl_pullup_conf[] = {
PINCTRL_CONF_DESC(18, REG_GPIO_L_PU, BIT(16)),
PINCTRL_CONF_DESC(19, REG_GPIO_L_PU, BIT(17)),
PINCTRL_CONF_DESC(20, REG_GPIO_L_PU, BIT(18)),
- PINCTRL_CONF_DESC(21, REG_GPIO_L_PU, BIT(18)),
+ PINCTRL_CONF_DESC(21, REG_GPIO_L_PU, BIT(19)),
PINCTRL_CONF_DESC(22, REG_GPIO_L_PU, BIT(20)),
PINCTRL_CONF_DESC(23, REG_GPIO_L_PU, BIT(21)),
PINCTRL_CONF_DESC(24, REG_GPIO_L_PU, BIT(22)),
@@ -1968,7 +1968,7 @@ static const struct airoha_pinctrl_conf an7583_pinctrl_pulldown_conf[] = {
PINCTRL_CONF_DESC(18, REG_GPIO_L_PD, BIT(16)),
PINCTRL_CONF_DESC(19, REG_GPIO_L_PD, BIT(17)),
PINCTRL_CONF_DESC(20, REG_GPIO_L_PD, BIT(18)),
- PINCTRL_CONF_DESC(21, REG_GPIO_L_PD, BIT(18)),
+ PINCTRL_CONF_DESC(21, REG_GPIO_L_PD, BIT(19)),
PINCTRL_CONF_DESC(22, REG_GPIO_L_PD, BIT(20)),
PINCTRL_CONF_DESC(23, REG_GPIO_L_PD, BIT(21)),
PINCTRL_CONF_DESC(24, REG_GPIO_L_PD, BIT(22)),
@@ -2085,7 +2085,7 @@ static const struct airoha_pinctrl_conf an7583_pinctrl_drive_e2_conf[] = {
PINCTRL_CONF_DESC(18, REG_GPIO_L_E2, BIT(16)),
PINCTRL_CONF_DESC(19, REG_GPIO_L_E2, BIT(17)),
PINCTRL_CONF_DESC(20, REG_GPIO_L_E2, BIT(18)),
- PINCTRL_CONF_DESC(21, REG_GPIO_L_E2, BIT(18)),
+ PINCTRL_CONF_DESC(21, REG_GPIO_L_E2, BIT(19)),
PINCTRL_CONF_DESC(22, REG_GPIO_L_E2, BIT(20)),
PINCTRL_CONF_DESC(23, REG_GPIO_L_E2, BIT(21)),
PINCTRL_CONF_DESC(24, REG_GPIO_L_E2, BIT(22)),
@@ -2202,7 +2202,7 @@ static const struct airoha_pinctrl_conf an7583_pinctrl_drive_e4_conf[] = {
PINCTRL_CONF_DESC(18, REG_GPIO_L_E4, BIT(16)),
PINCTRL_CONF_DESC(19, REG_GPIO_L_E4, BIT(17)),
PINCTRL_CONF_DESC(20, REG_GPIO_L_E4, BIT(18)),
- PINCTRL_CONF_DESC(21, REG_GPIO_L_E4, BIT(18)),
+ PINCTRL_CONF_DESC(21, REG_GPIO_L_E4, BIT(19)),
PINCTRL_CONF_DESC(22, REG_GPIO_L_E4, BIT(20)),
PINCTRL_CONF_DESC(23, REG_GPIO_L_E4, BIT(21)),
PINCTRL_CONF_DESC(24, REG_GPIO_L_E4, BIT(22)),
--
2.53.0
^ permalink raw reply related
* [PATCH 05/11] pinctrl: airoha: an7581: fix incorrect led mapping in phy4_led1 pin function
From: Mikhail Kshevetskiy @ 2026-06-06 2:03 UTC (permalink / raw)
To: Lorenzo Bianconi, Sean Wang, Linus Walleij, Matthias Brugger,
AngeloGioacchino Del Regno, Benjamin Larsson, Christian Marangi,
linux-mediatek, linux-gpio, linux-kernel, linux-arm-kernel,
Markus Gothe, Matheus Sampaio Queiroga
Cc: Mikhail Kshevetskiy
In-Reply-To: <20260606020342.1256509-1-mikhail.kshevetskiy@iopsys.eu>
phy4_led1 pin function maps led incorrectly. It uses the same map as
phy3_led1. PHY{X} should map to LAN{N}_PHY_LED_MAP(X-1).
Fixes: 579839c9548c ("pinctrl: airoha: convert PHY LED GPIO to macro")
Signed-off-by: Mikhail Kshevetskiy <mikhail.kshevetskiy@iopsys.eu>
---
drivers/pinctrl/mediatek/pinctrl-airoha.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/pinctrl/mediatek/pinctrl-airoha.c b/drivers/pinctrl/mediatek/pinctrl-airoha.c
index 34eef79d058f..9497f5110f61 100644
--- a/drivers/pinctrl/mediatek/pinctrl-airoha.c
+++ b/drivers/pinctrl/mediatek/pinctrl-airoha.c
@@ -1622,13 +1622,13 @@ static const struct airoha_pinctrl_func_group phy3_led1_func_group[] = {
static const struct airoha_pinctrl_func_group phy4_led1_func_group[] = {
AIROHA_PINCTRL_PHY_LED1("gpio43", GPIO_LAN0_LED1_MODE_MASK,
- LAN0_LED_MAPPING_MASK, LAN0_PHY_LED_MAP(2)),
+ LAN0_LED_MAPPING_MASK, LAN0_PHY_LED_MAP(3)),
AIROHA_PINCTRL_PHY_LED1("gpio44", GPIO_LAN1_LED1_MODE_MASK,
- LAN1_LED_MAPPING_MASK, LAN1_PHY_LED_MAP(2)),
+ LAN1_LED_MAPPING_MASK, LAN1_PHY_LED_MAP(3)),
AIROHA_PINCTRL_PHY_LED1("gpio45", GPIO_LAN2_LED1_MODE_MASK,
- LAN2_LED_MAPPING_MASK, LAN2_PHY_LED_MAP(2)),
+ LAN2_LED_MAPPING_MASK, LAN2_PHY_LED_MAP(3)),
AIROHA_PINCTRL_PHY_LED1("gpio46", GPIO_LAN3_LED1_MODE_MASK,
- LAN3_LED_MAPPING_MASK, LAN3_PHY_LED_MAP(2)),
+ LAN3_LED_MAPPING_MASK, LAN3_PHY_LED_MAP(3)),
};
static const struct airoha_pinctrl_func_group an7583_phy1_led0_func_group[] = {
--
2.53.0
^ permalink raw reply related
* [PATCH 07/11] pinctrl: airoha: fix pwm pin function for an7581 and an7583
From: Mikhail Kshevetskiy @ 2026-06-06 2:03 UTC (permalink / raw)
To: Lorenzo Bianconi, Sean Wang, Linus Walleij, Matthias Brugger,
AngeloGioacchino Del Regno, Benjamin Larsson, Christian Marangi,
linux-mediatek, linux-gpio, linux-kernel, linux-arm-kernel,
Markus Gothe, Matheus Sampaio Queiroga
Cc: Mikhail Kshevetskiy
In-Reply-To: <20260606020342.1256509-1-mikhail.kshevetskiy@iopsys.eu>
AN7581 have 47 valid GPIOs only (gpio0-gpio46), so gpio47 is a fiction.
AN7583 have 49 valid GPIOs (gpio0-gpio48), so gpio48 is missed
To fix an issue
* create AN7583 specific pwm pin function,
* remove gpio47 from AN7581 pwm pin function.
Fixes: 3ffeb17a9a27 ("pinctrl: airoha: add support for Airoha AN7583 PINs")
Signed-off-by: Mikhail Kshevetskiy <mikhail.kshevetskiy@iopsys.eu>
---
drivers/pinctrl/mediatek/pinctrl-airoha.c | 74 ++++++++++++++++++++++-
1 file changed, 72 insertions(+), 2 deletions(-)
diff --git a/drivers/pinctrl/mediatek/pinctrl-airoha.c b/drivers/pinctrl/mediatek/pinctrl-airoha.c
index 9be759f08b18..15a541724349 100644
--- a/drivers/pinctrl/mediatek/pinctrl-airoha.c
+++ b/drivers/pinctrl/mediatek/pinctrl-airoha.c
@@ -906,7 +906,30 @@ static const char *const pwm_groups[] = { "gpio0", "gpio1",
"gpio40", "gpio41",
"gpio42", "gpio43",
"gpio44", "gpio45",
- "gpio46", "gpio47" };
+ "gpio46" };
+static const char *const an7583_pwm_groups[] = { "gpio0", "gpio1",
+ "gpio2", "gpio3",
+ "gpio4", "gpio5",
+ "gpio6", "gpio7",
+ "gpio8", "gpio9",
+ "gpio10", "gpio11",
+ "gpio12", "gpio13",
+ "gpio14", "gpio15",
+ "gpio16", "gpio17",
+ "gpio18", "gpio19",
+ "gpio20", "gpio21",
+ "gpio22", "gpio23",
+ "gpio24", "gpio25",
+ "gpio26", "gpio27",
+ "gpio28", "gpio29",
+ "gpio30", "gpio31",
+ "gpio36", "gpio37",
+ "gpio38", "gpio39",
+ "gpio40", "gpio41",
+ "gpio42", "gpio43",
+ "gpio44", "gpio45",
+ "gpio46", "gpio47",
+ "gpio48" };
static const char *const phy1_led0_groups[] = { "gpio33", "gpio34",
"gpio35", "gpio42" };
static const char *const phy2_led0_groups[] = { "gpio33", "gpio34",
@@ -1504,7 +1527,54 @@ static const struct airoha_pinctrl_func_group pwm_func_group[] = {
AIROHA_PINCTRL_PWM_EXT("gpio44", GPIO44_FLASH_MODE_CFG),
AIROHA_PINCTRL_PWM_EXT("gpio45", GPIO45_FLASH_MODE_CFG),
AIROHA_PINCTRL_PWM_EXT("gpio46", GPIO46_FLASH_MODE_CFG),
+};
+
+static const struct airoha_pinctrl_func_group an7583_pwm_func_group[] = {
+ AIROHA_PINCTRL_PWM("gpio0", GPIO0_FLASH_MODE_CFG),
+ AIROHA_PINCTRL_PWM("gpio1", GPIO1_FLASH_MODE_CFG),
+ AIROHA_PINCTRL_PWM("gpio2", GPIO2_FLASH_MODE_CFG),
+ AIROHA_PINCTRL_PWM("gpio3", GPIO3_FLASH_MODE_CFG),
+ AIROHA_PINCTRL_PWM("gpio4", GPIO4_FLASH_MODE_CFG),
+ AIROHA_PINCTRL_PWM("gpio5", GPIO5_FLASH_MODE_CFG),
+ AIROHA_PINCTRL_PWM("gpio6", GPIO6_FLASH_MODE_CFG),
+ AIROHA_PINCTRL_PWM("gpio7", GPIO7_FLASH_MODE_CFG),
+ AIROHA_PINCTRL_PWM("gpio8", GPIO8_FLASH_MODE_CFG),
+ AIROHA_PINCTRL_PWM("gpio9", GPIO9_FLASH_MODE_CFG),
+ AIROHA_PINCTRL_PWM("gpio10", GPIO10_FLASH_MODE_CFG),
+ AIROHA_PINCTRL_PWM("gpio11", GPIO11_FLASH_MODE_CFG),
+ AIROHA_PINCTRL_PWM("gpio12", GPIO12_FLASH_MODE_CFG),
+ AIROHA_PINCTRL_PWM("gpio13", GPIO13_FLASH_MODE_CFG),
+ AIROHA_PINCTRL_PWM("gpio14", GPIO14_FLASH_MODE_CFG),
+ AIROHA_PINCTRL_PWM("gpio15", GPIO15_FLASH_MODE_CFG),
+ AIROHA_PINCTRL_PWM_EXT("gpio16", GPIO16_FLASH_MODE_CFG),
+ AIROHA_PINCTRL_PWM_EXT("gpio17", GPIO17_FLASH_MODE_CFG),
+ AIROHA_PINCTRL_PWM_EXT("gpio18", GPIO18_FLASH_MODE_CFG),
+ AIROHA_PINCTRL_PWM_EXT("gpio19", GPIO19_FLASH_MODE_CFG),
+ AIROHA_PINCTRL_PWM_EXT("gpio20", GPIO20_FLASH_MODE_CFG),
+ AIROHA_PINCTRL_PWM_EXT("gpio21", GPIO21_FLASH_MODE_CFG),
+ AIROHA_PINCTRL_PWM_EXT("gpio22", GPIO22_FLASH_MODE_CFG),
+ AIROHA_PINCTRL_PWM_EXT("gpio23", GPIO23_FLASH_MODE_CFG),
+ AIROHA_PINCTRL_PWM_EXT("gpio24", GPIO24_FLASH_MODE_CFG),
+ AIROHA_PINCTRL_PWM_EXT("gpio25", GPIO25_FLASH_MODE_CFG),
+ AIROHA_PINCTRL_PWM_EXT("gpio26", GPIO26_FLASH_MODE_CFG),
+ AIROHA_PINCTRL_PWM_EXT("gpio27", GPIO27_FLASH_MODE_CFG),
+ AIROHA_PINCTRL_PWM_EXT("gpio28", GPIO28_FLASH_MODE_CFG),
+ AIROHA_PINCTRL_PWM_EXT("gpio29", GPIO29_FLASH_MODE_CFG),
+ AIROHA_PINCTRL_PWM_EXT("gpio30", GPIO30_FLASH_MODE_CFG),
+ AIROHA_PINCTRL_PWM_EXT("gpio31", GPIO31_FLASH_MODE_CFG),
+ AIROHA_PINCTRL_PWM_EXT("gpio36", GPIO36_FLASH_MODE_CFG),
+ AIROHA_PINCTRL_PWM_EXT("gpio37", GPIO37_FLASH_MODE_CFG),
+ AIROHA_PINCTRL_PWM_EXT("gpio38", GPIO38_FLASH_MODE_CFG),
+ AIROHA_PINCTRL_PWM_EXT("gpio39", GPIO39_FLASH_MODE_CFG),
+ AIROHA_PINCTRL_PWM_EXT("gpio40", GPIO40_FLASH_MODE_CFG),
+ AIROHA_PINCTRL_PWM_EXT("gpio41", GPIO41_FLASH_MODE_CFG),
+ AIROHA_PINCTRL_PWM_EXT("gpio42", GPIO42_FLASH_MODE_CFG),
+ AIROHA_PINCTRL_PWM_EXT("gpio43", GPIO43_FLASH_MODE_CFG),
+ AIROHA_PINCTRL_PWM_EXT("gpio44", GPIO44_FLASH_MODE_CFG),
+ AIROHA_PINCTRL_PWM_EXT("gpio45", GPIO45_FLASH_MODE_CFG),
+ AIROHA_PINCTRL_PWM_EXT("gpio46", GPIO46_FLASH_MODE_CFG),
AIROHA_PINCTRL_PWM_EXT("gpio47", GPIO47_FLASH_MODE_CFG),
+ AIROHA_PINCTRL_PWM_EXT("gpio48", GPIO48_FLASH_MODE_CFG),
};
#define AIROHA_PINCTRL_PHY_LED0(gpio, mux_val, map_mask, map_val) \
@@ -1759,7 +1829,7 @@ static const struct airoha_pinctrl_func an7583_pinctrl_funcs[] = {
PINCTRL_FUNC_DESC("emmc", emmc),
PINCTRL_FUNC_DESC("pnand", pnand),
PINCTRL_FUNC_DESC("pcie_reset", an7583_pcie_reset),
- PINCTRL_FUNC_DESC("pwm", pwm),
+ PINCTRL_FUNC_DESC("pwm", an7583_pwm),
PINCTRL_FUNC_DESC("phy1_led0", an7583_phy1_led0),
PINCTRL_FUNC_DESC("phy2_led0", an7583_phy2_led0),
PINCTRL_FUNC_DESC("phy3_led0", an7583_phy3_led0),
--
2.53.0
^ permalink raw reply related
* [PATCH 08/11] pinctrl: airoha: an7583: fix gpio21 pin group
From: Mikhail Kshevetskiy @ 2026-06-06 2:03 UTC (permalink / raw)
To: Lorenzo Bianconi, Sean Wang, Linus Walleij, Matthias Brugger,
AngeloGioacchino Del Regno, Benjamin Larsson, Christian Marangi,
linux-mediatek, linux-gpio, linux-kernel, linux-arm-kernel,
Markus Gothe, Matheus Sampaio Queiroga
Cc: Mikhail Kshevetskiy
In-Reply-To: <20260606020342.1256509-1-mikhail.kshevetskiy@iopsys.eu>
gpio21 pin group refers to gpio22 pin, this is wrong.
Fixes: 3ffeb17a9a27 ("pinctrl: airoha: add support for Airoha AN7583 PINs")
Signed-off-by: Mikhail Kshevetskiy <mikhail.kshevetskiy@iopsys.eu>
---
drivers/pinctrl/mediatek/pinctrl-airoha.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/pinctrl/mediatek/pinctrl-airoha.c b/drivers/pinctrl/mediatek/pinctrl-airoha.c
index 15a541724349..9dce3ed6de17 100644
--- a/drivers/pinctrl/mediatek/pinctrl-airoha.c
+++ b/drivers/pinctrl/mediatek/pinctrl-airoha.c
@@ -748,7 +748,7 @@ static const int an7583_gpio17_pins[] = { 19 };
static const int an7583_gpio18_pins[] = { 20 };
static const int an7583_gpio19_pins[] = { 21 };
static const int an7583_gpio20_pins[] = { 22 };
-static const int an7583_gpio21_pins[] = { 24 };
+static const int an7583_gpio21_pins[] = { 23 };
static const int an7583_gpio23_pins[] = { 25 };
static const int an7583_gpio24_pins[] = { 26 };
static const int an7583_gpio25_pins[] = { 27 };
--
2.53.0
^ permalink raw reply related
* [PATCH 06/11] pinctrl: airoha: an7583: fix incorrect led mapping in phy4_led1 pin function
From: Mikhail Kshevetskiy @ 2026-06-06 2:03 UTC (permalink / raw)
To: Lorenzo Bianconi, Sean Wang, Linus Walleij, Matthias Brugger,
AngeloGioacchino Del Regno, Benjamin Larsson, Christian Marangi,
linux-mediatek, linux-gpio, linux-kernel, linux-arm-kernel,
Markus Gothe, Matheus Sampaio Queiroga
Cc: Mikhail Kshevetskiy
In-Reply-To: <20260606020342.1256509-1-mikhail.kshevetskiy@iopsys.eu>
phy4_led1 pin function maps led incorrectly. It uses the same map as
phy3_led1. PHY{X} should map to LAN{N}_PHY_LED_MAP(X-1).
Fixes: 3ffeb17a9a27 ("pinctrl: airoha: add support for Airoha AN7583 PINs")
Signed-off-by: Mikhail Kshevetskiy <mikhail.kshevetskiy@iopsys.eu>
---
drivers/pinctrl/mediatek/pinctrl-airoha.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/pinctrl/mediatek/pinctrl-airoha.c b/drivers/pinctrl/mediatek/pinctrl-airoha.c
index 9497f5110f61..9be759f08b18 100644
--- a/drivers/pinctrl/mediatek/pinctrl-airoha.c
+++ b/drivers/pinctrl/mediatek/pinctrl-airoha.c
@@ -1710,13 +1710,13 @@ static const struct airoha_pinctrl_func_group an7583_phy3_led1_func_group[] = {
static const struct airoha_pinctrl_func_group an7583_phy4_led1_func_group[] = {
AIROHA_PINCTRL_PHY_LED1("gpio8", GPIO_LAN0_LED1_MODE_MASK,
- LAN0_LED_MAPPING_MASK, LAN0_PHY_LED_MAP(2)),
+ LAN0_LED_MAPPING_MASK, LAN0_PHY_LED_MAP(3)),
AIROHA_PINCTRL_PHY_LED1("gpio9", GPIO_LAN1_LED1_MODE_MASK,
- LAN1_LED_MAPPING_MASK, LAN1_PHY_LED_MAP(2)),
+ LAN1_LED_MAPPING_MASK, LAN1_PHY_LED_MAP(3)),
AIROHA_PINCTRL_PHY_LED1("gpio10", GPIO_LAN2_LED1_MODE_MASK,
- LAN2_LED_MAPPING_MASK, LAN2_PHY_LED_MAP(2)),
+ LAN2_LED_MAPPING_MASK, LAN2_PHY_LED_MAP(3)),
AIROHA_PINCTRL_PHY_LED1("gpio11", GPIO_LAN3_LED1_MODE_MASK,
- LAN3_LED_MAPPING_MASK, LAN3_PHY_LED_MAP(2)),
+ LAN3_LED_MAPPING_MASK, LAN3_PHY_LED_MAP(3)),
};
static const struct airoha_pinctrl_func en7581_pinctrl_funcs[] = {
--
2.53.0
^ permalink raw reply related
* [PATCH 09/11] pinctrl: airoha: an7583: add missed gpio22 pin group
From: Mikhail Kshevetskiy @ 2026-06-06 2:03 UTC (permalink / raw)
To: Lorenzo Bianconi, Sean Wang, Linus Walleij, Matthias Brugger,
AngeloGioacchino Del Regno, Benjamin Larsson, Christian Marangi,
linux-mediatek, linux-gpio, linux-kernel, linux-arm-kernel,
Markus Gothe, Matheus Sampaio Queiroga
Cc: Mikhail Kshevetskiy
In-Reply-To: <20260606020342.1256509-1-mikhail.kshevetskiy@iopsys.eu>
gpio22 pin group is missed, fix it.
Fixes: 3ffeb17a9a27 ("pinctrl: airoha: add support for Airoha AN7583 PINs")
Signed-off-by: Mikhail Kshevetskiy <mikhail.kshevetskiy@iopsys.eu>
---
drivers/pinctrl/mediatek/pinctrl-airoha.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/pinctrl/mediatek/pinctrl-airoha.c b/drivers/pinctrl/mediatek/pinctrl-airoha.c
index 9dce3ed6de17..e66b608c4803 100644
--- a/drivers/pinctrl/mediatek/pinctrl-airoha.c
+++ b/drivers/pinctrl/mediatek/pinctrl-airoha.c
@@ -749,6 +749,7 @@ static const int an7583_gpio18_pins[] = { 20 };
static const int an7583_gpio19_pins[] = { 21 };
static const int an7583_gpio20_pins[] = { 22 };
static const int an7583_gpio21_pins[] = { 23 };
+static const int an7583_gpio22_pins[] = { 24 };
static const int an7583_gpio23_pins[] = { 25 };
static const int an7583_gpio24_pins[] = { 26 };
static const int an7583_gpio25_pins[] = { 27 };
@@ -828,6 +829,7 @@ static const struct pingroup an7583_pinctrl_groups[] = {
PINCTRL_PIN_GROUP("gpio19", an7583_gpio19),
PINCTRL_PIN_GROUP("gpio20", an7583_gpio20),
PINCTRL_PIN_GROUP("gpio21", an7583_gpio21),
+ PINCTRL_PIN_GROUP("gpio22", an7583_gpio22),
PINCTRL_PIN_GROUP("gpio23", an7583_gpio23),
PINCTRL_PIN_GROUP("gpio24", an7583_gpio24),
PINCTRL_PIN_GROUP("gpio25", an7583_gpio25),
--
2.53.0
^ permalink raw reply related
* [PATCH 10/11] pinctrl: airoha: an7583: fix phy1_led1 pin function
From: Mikhail Kshevetskiy @ 2026-06-06 2:03 UTC (permalink / raw)
To: Lorenzo Bianconi, Sean Wang, Linus Walleij, Matthias Brugger,
AngeloGioacchino Del Regno, Benjamin Larsson, Christian Marangi,
linux-mediatek, linux-gpio, linux-kernel, linux-arm-kernel,
Markus Gothe, Matheus Sampaio Queiroga
Cc: Mikhail Kshevetskiy
In-Reply-To: <20260606020342.1256509-1-mikhail.kshevetskiy@iopsys.eu>
phy1_led1 pin function wrongly refers to gpio1 instead of gpio11.
Fix it.
Fixes: 3ffeb17a9a27 ("pinctrl: airoha: add support for Airoha AN7583 PINs")
Signed-off-by: Mikhail Kshevetskiy <mikhail.kshevetskiy@iopsys.eu>
---
drivers/pinctrl/mediatek/pinctrl-airoha.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/pinctrl/mediatek/pinctrl-airoha.c b/drivers/pinctrl/mediatek/pinctrl-airoha.c
index e66b608c4803..b73ab60d0065 100644
--- a/drivers/pinctrl/mediatek/pinctrl-airoha.c
+++ b/drivers/pinctrl/mediatek/pinctrl-airoha.c
@@ -1754,7 +1754,7 @@ static const struct airoha_pinctrl_func_group an7583_phy1_led1_func_group[] = {
LAN1_LED_MAPPING_MASK, LAN1_PHY_LED_MAP(0)),
AIROHA_PINCTRL_PHY_LED1("gpio10", GPIO_LAN2_LED1_MODE_MASK,
LAN2_LED_MAPPING_MASK, LAN2_PHY_LED_MAP(0)),
- AIROHA_PINCTRL_PHY_LED1("gpio1", GPIO_LAN3_LED1_MODE_MASK,
+ AIROHA_PINCTRL_PHY_LED1("gpio11", GPIO_LAN3_LED1_MODE_MASK,
LAN3_LED_MAPPING_MASK, LAN3_PHY_LED_MAP(0)),
};
--
2.53.0
^ permalink raw reply related
* [PATCH 11/11] pinctrl: airoha: an7583: remove undefined groups from pcm_spi pin function
From: Mikhail Kshevetskiy @ 2026-06-06 2:03 UTC (permalink / raw)
To: Lorenzo Bianconi, Sean Wang, Linus Walleij, Matthias Brugger,
AngeloGioacchino Del Regno, Benjamin Larsson, Christian Marangi,
linux-mediatek, linux-gpio, linux-kernel, linux-arm-kernel,
Markus Gothe, Matheus Sampaio Queiroga
Cc: Mikhail Kshevetskiy
In-Reply-To: <20260606020342.1256509-1-mikhail.kshevetskiy@iopsys.eu>
pcm_spi_int, pcm_spi_cs2, pcm_spi_cs3, pcm_spi_cs4 pin groups are not
defined, so pcm_spi function can't be applied to these groups.
Fixes: 3ffeb17a9a27 ("pinctrl: airoha: add support for Airoha AN7583 PINs")
Signed-off-by: Mikhail Kshevetskiy <mikhail.kshevetskiy@iopsys.eu>
---
drivers/pinctrl/mediatek/pinctrl-airoha.c | 6 ++----
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/pinctrl/mediatek/pinctrl-airoha.c b/drivers/pinctrl/mediatek/pinctrl-airoha.c
index b73ab60d0065..bf5ebb31e635 100644
--- a/drivers/pinctrl/mediatek/pinctrl-airoha.c
+++ b/drivers/pinctrl/mediatek/pinctrl-airoha.c
@@ -877,10 +877,8 @@ static const char *const pcm_spi_groups[] = { "pcm_spi", "pcm_spi_int",
"pcm_spi_cs2_p156",
"pcm_spi_cs2_p128",
"pcm_spi_cs3", "pcm_spi_cs4" };
-static const char *const an7583_pcm_spi_groups[] = { "pcm_spi", "pcm_spi_int",
- "pcm_spi_rst", "pcm_spi_cs1",
- "pcm_spi_cs2", "pcm_spi_cs3",
- "pcm_spi_cs4" };
+static const char *const an7583_pcm_spi_groups[] = { "pcm_spi",
+ "pcm_spi_rst", "pcm_spi_cs1" };
static const char *const i2s_groups[] = { "i2s" };
static const char *const emmc_groups[] = { "emmc" };
static const char *const pnand_groups[] = { "pnand" };
--
2.53.0
^ permalink raw reply related
* Re: [PATCH net-next v9 0/6] net: airoha: Support multiple net_devices connected to the same GDM port
From: patchwork-bot+netdevbpf @ 2026-06-06 2:10 UTC (permalink / raw)
To: Lorenzo Bianconi
Cc: andrew+netdev, davem, edumazet, kuba, pabeni, robh, krzk+dt,
conor+dt, ansuelsmth, benjamin.larsson, linux-arm-kernel,
linux-mediatek, netdev, devicetree, xuegang.lu, madhur.agrawal
In-Reply-To: <20260603-airoha-eth-multi-serdes-v9-0-5d476bc2f426@kernel.org>
Hello:
This series was applied to netdev/net-next.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Wed, 03 Jun 2026 08:00:14 +0200 you wrote:
> EN7581 or AN7583 SoCs support connecting multiple external SerDes (e.g.
> Ethernet or USB SerDes) to GDM3 or GDM4 ports via a hw arbiter that
> manages the traffic in a TDM manner. As a result multiple net_devices can
> connect to the same GDM{3,4} port and there is a theoretical "1:n"
> relation between GDM ports and net_devices.
>
> ┌─────────────────────────────────┐
> │ │ ┌──────┐
> │ P1 GDM1 ├────►MT7530│
> │ │ └──────┘
> │ │ ETH0 (DSA conduit)
> │ │
> │ PSE/FE │
> │ │
> │ │
> │ │ ┌─────┐
> │ P0 CDM1 ├────►QDMA0│
> │ P4 P9 GDM4 │ └─────┘
> └──┬─────────────────────────┬────┘
> │ │
> ┌──▼──┐ ┌────▼────┐
> │ PPE │ │ ARB │
> └─────┘ └─┬─────┬─┘
> │ │
> ┌──▼──┐┌─▼───┐
> │ ETH ││ USB │
> └─────┘└─────┘
> ETH1 ETH2
>
> [...]
Here is the summary with links:
- [net-next,v9,1/6] dt-bindings: net: airoha: Add GDM port ethernet child node
https://git.kernel.org/netdev/net-next/c/a4597204b681
- [net-next,v9,2/6] net: airoha: Remove private net_device pointer in airoha_gdm_dev struct
https://git.kernel.org/netdev/net-next/c/4408f5206809
- [net-next,v9,3/6] net: airoha: Support multiple net_devices for a single FE GDM port
https://git.kernel.org/netdev/net-next/c/a9c2ca61fec7
- [net-next,v9,4/6] net: airoha: Do not stop GDM port if it is shared
https://git.kernel.org/netdev/net-next/c/99b9d095d71e
- [net-next,v9,5/6] net: airoha: Introduce WAN device flag
https://git.kernel.org/netdev/net-next/c/7758cb462ff7
- [net-next,v9,6/6] net: airoha: Support multiple LAN/WAN interfaces for hw MAC address configuration
https://git.kernel.org/netdev/net-next/c/ef2aee987174
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [PATCH net-next v3] net: microchip: sparx5: clean up PSFP resources on flower setup failure
From: patchwork-bot+netdevbpf @ 2026-06-06 2:10 UTC (permalink / raw)
To: Haoxiang Li
Cc: andrew+netdev, davem, kuba, pabeni, Steen.Hegelund, daniel.machon,
UNGLinuxDriver, kees, netdev, linux-arm-kernel, linux-kernel
In-Reply-To: <20260603061716.747282-1-lihaoxiang@isrc.iscas.ac.cn>
Hello:
This patch was applied to netdev/net-next.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Wed, 3 Jun 2026 14:17:16 +0800 you wrote:
> sparx5_tc_flower_psfp_setup() allocates PSFP stream gate, flow meter and
> stream filter resources before adding VCAP actions. If a later step
> fails, the resources allocated earlier in the function are not unwound.
>
> Add error paths to release the stream filter, flow meter and stream gate
> when setup fails after they have been acquired.
>
> [...]
Here is the summary with links:
- [net-next,v3] net: microchip: sparx5: clean up PSFP resources on flower setup failure
https://git.kernel.org/netdev/net-next/c/46e503673387
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [PATCH] net: stmmac: xgmac: report L3/L4 filter match count in ethtool stats
From: patchwork-bot+netdevbpf @ 2026-06-06 2:20 UTC (permalink / raw)
To: Nazle, Asmade, Muhammad Nazim Amirul
Cc: netdev, andrew+netdev, davem, edumazet, kuba, pabeni,
mcoquelin.stm32, alexandre.torgue, rmk+kernel, maxime.chevallier,
linux-stm32, linux-arm-kernel, linux-kernel
In-Reply-To: <20260604083037.24407-1-muhammad.nazim.amirul.nazle.asmade@altera.com>
Hello:
This patch was applied to netdev/net-next.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Thu, 4 Jun 2026 01:30:37 -0700 you wrote:
> From: Nazim Amirul <muhammad.nazim.amirul.nazle.asmade@altera.com>
>
> Read the L3FM and L4FM bits from the RX descriptor status word (RDES2)
> and increment the corresponding ethtool statistics counters. This allows
> users to observe L3/L4 filter hit rates via ethtool -S.
>
> Signed-off-by: Rohan G Thomas <rohan.g.thomas@altera.com>
> Signed-off-by: Nazim Amirul <muhammad.nazim.amirul.nazle.asmade@altera.com>
>
> [...]
Here is the summary with links:
- net: stmmac: xgmac: report L3/L4 filter match count in ethtool stats
https://git.kernel.org/netdev/net-next/c/903db046d557
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* [STATUS] arm64/for-kernelci - ffe7bef3786c1c2a725f80c2025010644452fd1c
From: KernelCI bot @ 2026-06-06 2:30 UTC (permalink / raw)
To: kernelci-results; +Cc: will, linux-arm-kernel
Hello,
Status summary for arm64/for-kernelci
Dashboard:
https://d.kernelci.org/c/arm64/for-kernelci/ffe7bef3786c1c2a725f80c2025010644452fd1c/
giturl: https://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git
branch: for-kernelci
commit hash: ffe7bef3786c1c2a725f80c2025010644452fd1c
origin: maestro
test start time: 2026-06-05 17:03:21.134000+00:00
Builds: 8 ✅ 0 ❌ 0 ⚠️
Boots: 12 ✅ 0 ❌ 1 ⚠️
Tests: 10548 ✅ 84 ❌ 93 ⚠️
### POSSIBLE REGRESSIONS
No possible regressions observed.
### FIXED REGRESSIONS
No fixed regressions observed.
### UNSTABLE TESTS
Hardware: bcm2711-rpi-4-b
> Config: defconfig+lab-setup+kselftest
- Architecture/compiler: arm64/gcc-14
- boot
last run: https://d.kernelci.org/test/maestro:6a230ad146e71b76f9f6eb2e
history: > ⚠️ > ✅ > ✅ > ✅ > ⚠️
Sent every day if there were changes in the past 24 hours.
Legend: ✅ PASS ❌ FAIL ⚠️ INCONCLUSIVE
--
This is an experimental report format. Please send feedback in!
Talk to us at kernelci@lists.linux.dev
Made with love by the KernelCI team - https://kernelci.org
^ permalink raw reply
* Re: [PATCH v3 0/5] remoteproc: cleanup shared carveout and resource-table helpers
From: Peng Fan @ 2026-06-06 3:43 UTC (permalink / raw)
To: Mathieu Poirier
Cc: Ben Levinsky, arnaud.pouliquen, daniel.baluta, Bjorn Andersson,
linux-remoteproc, Frank Li, Sascha Hauer, Pengutronix Kernel Team,
Fabio Estevam, Geert Uytterhoeven, Magnus Damm, Patrice Chotard,
Maxime Coquelin, Alexandre Torgue, Tanmay Shah, imx,
linux-arm-kernel, linux-kernel, linux-renesas-soc, linux-stm32
In-Reply-To: <ah2aVdlsLqy9aeHP@p14s>
On Mon, Jun 01, 2026 at 08:42:29AM -0600, Mathieu Poirier wrote:
>Good morning,
>
>On Thu, May 28, 2026 at 07:16:32PM -0700, Ben Levinsky wrote:
>> This series is a preparatory remoteproc cleanup split out from review of
>> the AMD BRAM-based remoteproc series.
>>
>> During review, there was a request to move the duplicated plain
>> ioremap_wc()/iounmap() carveout callbacks into common code and to
>> factor the "missing resource table is OK" ELF parsing path into a
>> common helper as well. There was also a request to send that cleanup as
>> its own patchset first, with the AMD BRAM series respun afterwards on
>> top once this cleanup is merged.
>>
>> This version keeps the same overall cleanup goals as v2, but reworks
>> the optional resource-table pieces based on follow-up review:
>>
>> - reshape the optional resource-table helper in patch 4 into the thin
>> parse_fw() wrapper form suggested on the thread
>> - switch the patch 5 clients over to that helper shape directly,
>> without post-helper rproc->table_ptr checks
>> - keep the driver-local parse_fw() wrappers and their existing log
>> messages and severity choices
>> - retain as much of the existing per-driver parse_fw() logic and code
>> placement as possible while moving the missing-table handling
>> through the shared helper
>>
>> This series now does that in five patches:
>>
>> 1. add common subsystem-private callbacks for the exact-match
>> wc-ioremap carveout case
>> 2. switch the in-tree exact-match users over to those callbacks
>> 3. mark carveouts mapped through the shared wc-ioremap helper as
>> iomem so the framework uses the proper I/O accessors
>> 4. add a common helper for drivers that treat a missing ELF resource
>> table as optional while keeping per-driver logging decisions local
>> 5. switch the matching in-tree drivers over to that helper while
>> keeping thin local parse_fw() wrappers
>>
>> For the carveout map/unmap cleanup, this series covers the exact-match
>> users called out in review: xlnx_r5_remoteproc, rcar_rproc,
>> st_remoteproc, stm32_rproc, imx_rproc, and imx_dsp_rproc. The zynqmp R5
>> TCM mapping path is left alone because it also clears the mapped memory
>> and is not an exact match.
>>
>> For the optional resource-table handling, this series converts
>> xlnx_r5_remoteproc, rcar_rproc, stm32_rproc, imx_rproc, and
>> imx_dsp_rproc. st_remoteproc is intentionally left unchanged because its
>> parse_fw() callback also builds carveouts and is therefore not a direct
>> match for the helper introduced here.
>>
>> Changes in v3:
>> - rework patch 4 so the optional resource-table helper matches the
>> thin-wrapper form suggested in review
>> - note that patch 4 still triggers a checkpatch --strict warning for
>> the flow-control macro form, but that implementation follows the
>> maintainer's review suggestion for the thin parse_fw() wrapper shape
>> - update patch 5 to use that helper shape directly in the client
>> parse_fw() callbacks
>> - drop the post-helper rproc->table_ptr checks from the converted
>> drivers
>> - keep the converted parse_fw() wrappers otherwise close to their
>> existing structure and placement
>> - test xlnx_r5_remoteproc on the latest tree with firmware images
>> both with and without an ELF resource table
>>
>> Changes in v2:
>> - split the mem->is_iomem change out into a separate patch
>> - add a common error message on ioremap_wc() failure
>> - drop logging from the optional resource-table helper
>> - keep driver-local parse_fw() wrappers to preserve per-platform
>> missing-resource-table logging policy
>>
>> Ben Levinsky (5):
>> remoteproc: add common wc-ioremap carveout callbacks
>> remoteproc: switch exact-match drivers to wc-ioremap callbacks
>> remoteproc: mark wc-ioremap carveouts as iomem
>> remoteproc: add helper for optional ELF resource tables
>> remoteproc: switch drivers to optional resource-table helper
>>
>> drivers/remoteproc/imx_dsp_rproc.c | 41 +++-----------
>> drivers/remoteproc/imx_rproc.c | 40 ++------------
>> drivers/remoteproc/rcar_rproc.c | 41 ++------------
>> drivers/remoteproc/remoteproc_internal.h | 38 +++++++++++++
>> drivers/remoteproc/st_remoteproc.c | 31 +----------
>> drivers/remoteproc/stm32_rproc.c | 39 ++-----------
>> drivers/remoteproc/xlnx_r5_remoteproc.c | 70 +++++-------------------
>
>This set looks good to me. I am fine with the checkpatch warning on the macro -
>given the redundancy it avoids, I think it can be tolerated.
>
>Wolfram has already indicated he wanted to test these changes - Arnaud, Daniel
>and Peng, please do the same for your platforms.
Tested-by: Peng Fan <peng.fan@nxp.com> #i.MX8MP-EVK
>
>Thanks,
>Mathieu
>
>> 7 files changed, 73 insertions(+), 227 deletions(-)
>>
>> --
>> 2.34.1
^ permalink raw reply
* Re: [PATCH v4 18/24] iommu/arm-smmu-v3: Introduce master->ats_broken flag
From: Nicolin Chen @ 2026-06-06 4:04 UTC (permalink / raw)
To: Jason Gunthorpe
Cc: Will Deacon, Robin Murphy, Joerg Roedel, Bjorn Helgaas,
Rafael J . Wysocki, Len Brown, Pranjal Shrivastava, Mostafa Saleh,
Lu Baolu, Kevin Tian, linux-arm-kernel, iommu, linux-kernel,
linux-acpi, linux-pci, vsethi, Shuai Xue
In-Reply-To: <20260605230315.GF1962447@nvidia.com>
On Fri, Jun 05, 2026 at 08:03:15PM -0300, Jason Gunthorpe wrote:
> On Fri, Jun 05, 2026 at 02:56:06PM -0700, Nicolin Chen wrote:
> > On Fri, Jun 05, 2026 at 04:42:59PM -0300, Jason Gunthorpe wrote:
> > > I don't see any of these options as appealing. We have to maintain a
> > > few key invariants, and I think it cannot be done without a way to
> > > find all the domains that are using the STE.
> > >
> > > One way or another you have to be using the invs list rw locks to
> > > synchronize the EATS state changes.
> > >
> > > It is okayish to be sloppy when turning EATS off, but when turning it
> > > back on we do need to cycle through every invs list and toggle its
> > > lock to ensure that the invalidations are synchronized before
> > > EATS=enable happens.
> >
> > I think the core guarantees that "cycle through every invs list"
> > happens: a PCI reset calls reset_prepare() blocking all the RID
> > and PASID domains and removing ATS entries from every invs list,
> > and then calls reset_done() that re-attach RID/PASID domains so
> > freshly new ATS entries will be installed before EATS=enable.
>
> I think this whole thing is so async and racy this is not something we
> can truely rely on. The driver is going to have to make sure it
> doesn't get turned on accidentally while the CD is still populated.
You mean the driver needs to ensure that the ATS entires in the
invs list would not be skipped when STE.EATS is enabled, right?
Otherwise, INV_TYPE_ATS_BROKEN + per-master domain list cannot
prevent a concurrent attach() from turning on STE.EATS either.
> > > Given you must have a way to go from STE -> master -> all invs lists
> > > I'm not sure either option really makes such a large difference.
> > >
> > > If so then adjusting the invs to disable the ATS is pretty simple, run
> > > over the xarray and set them all off. Yes you could find the master
> > > through a SID lookup with some locking adjustment.
> > > >
> > > > (1) Per-invs marker: INV_TYPE_ATS_BROKEN + master_domains
> > > > disable_ats() in the timeout path walks master->master_domains
> > > > and flips matching ATS invs entries to the BROKEN type.
> > > >
> > > > + invs walker is free (one case label in the existing type switch).
> > > > + No lock or pointer deref in the invs walker.
> > > > + No master pointer stored in invs; no lifetime concern.
> > > >
> > > > - disable_ats() walks every (master, domain) and marks each invs
> > > > set; the list needs locking usable from atomic.
> > >
> > > This doesn't seem so bad
> >
> > Yea, the only thing is that the disable path has to deal with a
> > complexity from going through a per-device domain list. Maybe it
> > can reuse iommu_group->pasid_array by taking xa_lock?
>
> Maybe the locking seems tricky as the locks might end up nesting in
> weird ways.
Oh, that's thoughtful.
> The streams rb tree and existing master domains linked list seems
> appealing if the locking can nest acceptably.
Yea, limiting the locking at the driver-level is more manageable.
> > > > (3) Per-master flag + inv->master pointer (v4)
> > > > invs entry carries a master pointer; the invs walker reads
> > > > cur->master->ats_broken directly.
> > > >
> > > > + invs walker is one READ_ONCE through a cached pointer.
> > > > + disable_ats is one WRITE_ONCE.
> > > > + atc_inv_master early-skip via one READ_ONCE.
> > > > + attach gate + post-attach re-check, same as (2).
> > > >
> > > > - invs holds a master ptr, so release_device must synchronize_rcu()
> > > > before freeing the master to drain walkers under rcu_read_lock().
> > > > We dropped this from v4 for that reason.
> > >
> > > synchronize_rcu is not right because you have to have gone through the
> > > rwlock so there can be no readers.
> >
> > Ah, I think you are right! When release_device() is invoked, the
> > device must be already in the release (blocked) domain. So there
> > should be no domain->invs in the system holding its ATS entries.
> > And the enable part would work as (2).
> >
> > In this case, (3) seems the best? It's fast on every aspect.
>
> I don't like it mainly because of the sketch enable side, and if we
> tighten that then you can just do 1 which doesn't have a perf impact..
I agree that per-master flag alone would be racy. So, for it to
work, it would need an extra spinlock. This v4 actually added a
pairing ats_broken_lock to fence arm_smmu_write_entry() in the
attach path, while the quarantine path is disabling STE.EATS and
setting the per-master flag. With that, the driver can ensure:
- no race in STE.EATS update
- consistency between STE.EATS and ATS entries in every invs
> But still, I'm not sure how all the asyncess and races will resolve in
> any of these cases.
Maybe we can try "INV_TYPE_ATS_BROKEN + per-master domain list"
first and see if Sashiko might identify some corner case.
Thanks
Nicolin
^ permalink raw reply
* [PATCH] ASoC: mediatek: mt8365: check suspend backup allocation
From: Ruoyu Wang @ 2026-06-06 4:07 UTC (permalink / raw)
To: Liam Girdwood
Cc: Mark Brown, Jaroslav Kysela, Takashi Iwai, Matthias Brugger,
AngeloGioacchino Del Regno, linux-sound, linux-kernel,
linux-arm-kernel, linux-mediatek, Ruoyu Wang
mt8365_afe_suspend() lazily allocates the register backup array and then
stores register values into it. If devm_kcalloc() fails, the suspend path
dereferences afe->reg_back_up in the backup loop.
Check the allocation result before using the array. Disable the main
clock before returning so the error path balances the clock enable at the
start of suspend.
Signed-off-by: Ruoyu Wang <ruoyuw560@gmail.com>
---
sound/soc/mediatek/mt8365/mt8365-afe-pcm.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/sound/soc/mediatek/mt8365/mt8365-afe-pcm.c b/sound/soc/mediatek/mt8365/mt8365-afe-pcm.c
index d01793394f225..74e4f53b31605 100644
--- a/sound/soc/mediatek/mt8365/mt8365-afe-pcm.c
+++ b/sound/soc/mediatek/mt8365/mt8365-afe-pcm.c
@@ -1978,6 +1978,10 @@ static int mt8365_afe_suspend(struct device *dev)
afe->reg_back_up =
devm_kcalloc(dev, afe->reg_back_up_list_num,
sizeof(unsigned int), GFP_KERNEL);
+ if (!afe->reg_back_up) {
+ mt8365_afe_disable_main_clk(afe);
+ return -ENOMEM;
+ }
for (i = 0; i < afe->reg_back_up_list_num; i++)
regmap_read(regmap, afe->reg_back_up_list[i],
--
2.34.1
^ permalink raw reply related
* Re: [PATCH bpf-next v2 8/8] selftests/bpf: add tests to validate KASAN on JIT programs
From: Yonghong Song @ 2026-06-06 4:09 UTC (permalink / raw)
To: Alexis Lothoré, Alexei Starovoitov, Daniel Borkmann,
Andrii Nakryiko, Martin KaFai Lau, Eduard Zingerman,
Kumar Kartikeya Dwivedi, Song Liu, Jiri Olsa, John Fastabend,
Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen, x86,
H. Peter Anvin, Shuah Khan, Maxime Coquelin, Alexandre Torgue,
Ihor Solodrai
Cc: ebpf, Bastien Curutchet, Thomas Petazzoni, bpf, linux-kernel,
linux-kselftest, linux-stm32, linux-arm-kernel
In-Reply-To: <DJ1EYKOXV11H.25EJOUKFI81T4@bootlin.com>
On 6/5/26 1:55 PM, Alexis Lothoré wrote:
> On Fri Jun 5, 2026 at 7:20 PM CEST, Yonghong Song wrote:
>
> [...]
>
>>> Are you seeing any kasan report when you manually check your kernel
>>> logs, or not at all ? If not at all, are you using the "CI" defconfig ?
>> I do see one report:
>>
>> [ 79.503059] ==================================================================
>> [ 79.503715] BUG: KASAN: slab-use-after-free in bpf_prog_bb753b2ee1f69aa0_st_not_on_stack+0x115/0x160
>> [ 79.503715] Write of size 1 at addr ff11000117210a20 by task test_progs/2153
>>
>> [ 79.503715] CPU: 6 UID: 0 PID: 2153 Comm: test_progs Tainted: G OE 7.1.0-rc5-gd552a156c2fa #1926 PREEMPT(full)
>> [ 79.503715] Tainted: [O]=OOT_MODULE, [E]=UNSIGNED_MODULE
>> [ 79.503715] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014
>> [ 79.503715] Call Trace:
>> [ 79.503715] <TASK>
>> [ 79.503715] dump_stack_lvl+0x6d/0xa0
>> [ 79.503715] print_address_description+0x77/0x200
>> [ 79.503715] print_report+0x58/0x70
>> [ 79.503715] ? bpf_prog_bb753b2ee1f69aa0_st_not_on_stack+0x115/0x160
>> [ 79.503715] kasan_report+0xa2/0xe0
>> [ 79.503715] ? bpf_prog_bb753b2ee1f69aa0_st_not_on_stack+0x115/0x160
>> [ 79.503715] ? bpf_test_run+0x208/0x770
>> [ 79.503715] bpf_prog_bb753b2ee1f69aa0_st_not_on_stack+0x115/0x160
>> [ 79.503715] bpf_test_run+0x472/0x770
>> [ 79.503715] ? srso_alias_return_thunk+0x5/0xfbef5
>> [ 79.503715] ? __lock_acquire+0xe4a/0x2a10
>> [ 79.503715] ? __pfx___css_rstat_updated+0x10/0x10
>> [ 79.503715] ? __lock_acquire+0xe4a/0x2a10
>> [ 79.503715] ? __pfx_bpf_test_run+0x10/0x10
>> [ 79.503715] ? srso_alias_return_thunk+0x5/0xfbef5
>> [ 79.503715] ? lock_acquire+0xfd/0x2b0
>> [ 79.503715] ? srso_alias_return_thunk+0x5/0xfbef5
>> [ 79.503715] ? srso_alias_return_thunk+0x5/0xfbef5
>> [ 79.503715] ? rcu_is_watching+0x1f/0xa0
>> [ 79.503715] ? srso_alias_return_thunk+0x5/0xfbef5
>> [ 79.503715] ? __kasan_krealloc+0xe9/0x110
>> [ 79.503715] ? eth_type_trans+0x4b9/0x5f0
>> [ 79.503715] bpf_prog_test_run_skb+0xddf/0x22f0
>> [ 79.503715] ? __fget_files+0x29/0x350
>> [ 79.503715] ? srso_alias_return_thunk+0x5/0xfbef5
>> [ 79.503715] ? __fget_files+0x29/0x350
>> [ 79.503715] bpf_prog_test_run+0x1cc/0x2d0
>> [ 79.503715] __sys_bpf+0x740/0xa30
>> [ 79.503715] ? __pfx___sys_bpf+0x10/0x10
>> [ 79.503715] ? _prb_read_valid+0x334/0x770
>> [ 79.503715] ? handle_mm_fault+0x91b/0xc00
>> [ 79.503715] __x64_sys_bpf+0xba/0xd0
>> [ 79.503715] do_syscall_64+0xee/0x400
>> [ 79.503715] ? entry_SYSCALL_64_after_hwframe+0x76/0x7e
>> [ 79.503715] entry_SYSCALL_64_after_hwframe+0x76/0x7e
>> [ 79.503715] RIP: 0033:0x7f92d8cfe1ad
>> [ 79.503715] Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 8
>> [ 79.503715] RSP: 002b:00007ffe4237fee8 EFLAGS: 00000206 ORIG_RAX: 0000000000000141
>> [ 79.503715] RAX: ffffffffffffffda RBX: 00007ffe423807b8 RCX: 00007f92d8cfe1ad
>> [ 79.503715] RDX: 0000000000000050 RSI: 00007ffe4237ff70 RDI: 000000000000000a
>> [ 79.503715] RBP: 00007ffe4237ff10 R08: 0000000000000000 R09: 0000000000000050
>> [ 79.503715] R10: 0000000000000064 R11: 0000000000000206 R12: 0000000000000000
>> [ 79.503715] R13: 00007ffe423807d8 R14: 00007f92d8eb9000 R15: 00005585778dd150
>> [ 79.503715] </TASK>
>>
>> [ 79.503715] Allocated by task 2153:
>> [ 79.503715] kasan_save_track+0x2f/0x70
>> [ 79.503715] __kasan_kmalloc+0x72/0x90
>> [ 79.503715] __kmalloc_node_noprof+0x34c/0x730
>> [ 79.503715] bpf_map_area_alloc+0x4a/0x110
>> [ 79.503715] array_map_alloc+0x19e/0x580
>> [ 79.503715] map_create+0x8b2/0x1500
>> [ 79.503715] __sys_bpf+0x7ea/0xa30
>> [ 79.503715] __x64_sys_bpf+0xba/0xd0
>> [ 79.503715] do_syscall_64+0xee/0x400
>> [ 79.503715] entry_SYSCALL_64_after_hwframe+0x76/0x7e
>>
>> [ 79.503715] The buggy address belongs to the object at ff11000117210800
>> which belongs to the cache kmalloc-cg-1k of size 1024
>> [ 79.503715] The buggy address is located 0 bytes to the right of
>> freed 544-byte region [ff11000117210800, ff11000117210a20)
>>
>> [ 79.503715] The buggy address belongs to the physical page:
>> [ 79.503715] page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x117210
>> [ 79.503715] head: order:3 mapcount:0 entire_mapcount:0 nr_pages_mapped:0 pincount:0
>> [ 79.503715] memcg:ff11000117210411
>> [ 79.503715] flags: 0x200000000000040(head|node=0|zone=2)
>> [ 79.503715] page_type: f5(slab)
>> [ 79.503715] raw: 0200000000000040 ff11000100072000 dead000000000100 dead000000000122
>> [ 79.503715] raw: 0000000000000000 0000080000100010 00000000f5000000 ff11000117210411
>> [ 79.503715] head: 0200000000000040 ff11000100072000 dead000000000100 dead000000000122
>> [ 79.503715] head: 0000000000000000 0000080000100010 00000000f5000000 ff11000117210411
>> [ 79.503715] head: 0200000000000003 fffffffffffffe01 00000000ffffffff 00000000ffffffff
>> [ 79.503715] head: 0000000000000000 0000000000000000 00000000ffffffff 0000000000000008
>> [ 79.503715] page dumped because: kasan: bad access detected
>>
>> [ 79.503715] Memory state around the buggy address:
>> [ 79.503715] ff11000117210900: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>> [ 79.503715] ff11000117210980: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>> [ 79.503715] >ff11000117210a00: 00 00 00 00 fb fb fc fc fc fc fc fc fc fc fc fc
>> [ 79.503715] ^
>> [ 79.503715] ff11000117210a80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
>> [ 79.503715] ff11000117210b00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
>> [ 79.503715] ==================================================================
>>
>>
>> But when I am running another same test './test_progs -t kasan', there is no kasan reports.
> Ok, I guess you are missing kasan_multi_shot on your kernel command
> line: without this option, only the first report is generated, then
> KASAN does not emit additional report until you restart your kernel.
> Could you please try adding it and running the tests again ?
Thanks! Adding 'kasan_multi_shot' to the kernel command line indeed fixed the problem.
It would be great if you can mention 'kasan_multi_shot' is needed in kernel command
line in cover letter and in patch 8.
>
> Thanks,
>
> Alexis
>
>>> cat tools/testing/selftests/bpf/{config,config.vm,config.x86_64} > .config && make olddefconfig
>>>
>>> If not, would you mind sharing your defconfig ?
>> Attached.
>>
>>> Thanks,
>>>
>>> Alexis
>
>
>
^ permalink raw reply
* Re: [PATCH v3 1/3] dt-bindings: net: add Realtek r8169 family PCIe Ethernet
From: Ricardo Pardini @ 2026-06-06 5:03 UTC (permalink / raw)
To: Heiner Kallweit, nic_swsd, Andrew Lunn, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Heiko Stuebner
Cc: Sebastian Reichel, netdev, devicetree, linux-kernel,
linux-arm-kernel, linux-rockchip
In-Reply-To: <b7cc8eba-ff6e-417d-8e74-b3bb24e08a26@gmail.com>
On 05/06/2026 17:48, Heiner Kallweit wrote:
> On 05.06.2026 13:49, Ricardo Pardini via B4 Relay wrote:
>> From: Ricardo Pardini <ricardo@pardini.net>
>>
>> Add a binding for fixed/soldered Realtek PCIe Ethernet controllers
>> driven by the r8169 driver (RTL8125/8126/8127/8168 and variants).
>>
>> The "pciVVVV,DDDD" compatibles are the Open Firmware PCI Bus Binding
>> spelling, auto-derived from PCI-SIG vendor/device IDs, but they still
>> need a binding when used in a board DT - analogous to "usbVVVV,PPPP"
>> compatibles documented in their own bindings (e.g. microchip,lan95xx)
>> so board DTs attaching properties (fixed MAC, nvmem cell, ...) to
>> these PCI function nodes can be validated.
>>
>
> The of node seems to be created by of_pci_make_dev_node(). But this
> function is called for bridges only in pci_bus_add_device().
> So where is the node created in your case? Did you test node creation?
>
Hi Heiner,
Seems to me of_pci_make_dev_node() is not at play here - that's the
DT-synthesis path. For nodes already present in DT, the of_node is bound
earlier, during pci_setup_device() -> pci_set_of_node() ->
of_pci_find_child_device() via the 5-cell reg.
Ref testing: yes; with this series on a NanoPC-T6 I get, for example:
/sys/bus/pci/devices/0004:41:00.0/of_node ->
/sys/firmware/devicetree/base/pcie@fe190000/pcie@0,0/ethernet@0,0 and
u-boot correctly adds local-mac-address property there which is
correctly picked up kernel-side:
=> setenv eth1addr 8e:b4:90:66:66:66
=> boot
...
# readlink -f /sys/bus/pci/devices/0004:41:00.0/of_node
/sys/firmware/devicetree/base/pcie@fe190000/pcie@0,0/ethernet@0,0
# xxd /sys/bus/pci/devices/0004:41:00.0/of_node/local-mac-address
00000000: 8eb4 9066 6666 ...fff
# ip link show dev end1 | grep ether
link/ether 8e:b4:90:66:66:66 brd ff:ff:ff:ff:ff:ff
>> +properties:
>> + compatible:
>> + enum:
>> + - pci10ec,8125 # RTL8125 2.5GbE
>> + - pci10ec,8126 # RTL8126 5GbE
>> + - pci10ec,8127 # RTL8127
>> + - pci10ec,8161 # RTL8168 variant
>> + - pci10ec,8162 # RTL8168 variant
>> + - pci10ec,8168 # RTL8168/8111 GbE
>
> This list reflects just some of the PCI id's handled by r8169.
> Any specific reason for this exact selection?
I went for "chips likely to be soldered down on an SBC", but that was
indeed speculative.
I guess I should trim to pci10ec,8125, which is all this series
describes? (further IDs can be added by the patches that introduce
boards using them)
--
Regards,
Ricardo
^ permalink raw reply
* [PATCH net-next] net: airoha: Use int instead of atomic_t for qdma users counter
From: Lorenzo Bianconi @ 2026-06-06 5:49 UTC (permalink / raw)
To: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni
Cc: linux-arm-kernel, linux-mediatek, netdev, Lorenzo Bianconi
QDMA users counter is always accessed holding RTNL lock so we do not
require atomic_t for it.
Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
---
drivers/net/ethernet/airoha/airoha_eth.c | 4 ++--
drivers/net/ethernet/airoha/airoha_eth.h | 3 +--
2 files changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/airoha/airoha_eth.c b/drivers/net/ethernet/airoha/airoha_eth.c
index 5a8e84fa9918..a5fe08864fa3 100644
--- a/drivers/net/ethernet/airoha/airoha_eth.c
+++ b/drivers/net/ethernet/airoha/airoha_eth.c
@@ -1809,7 +1809,7 @@ static int airoha_dev_open(struct net_device *netdev)
airoha_qdma_set(qdma, REG_QDMA_GLOBAL_CFG,
GLOBAL_CFG_TX_DMA_EN_MASK |
GLOBAL_CFG_RX_DMA_EN_MASK);
- atomic_inc(&qdma->users);
+ qdma->users++;
if (!airoha_is_lan_gdm_dev(dev) &&
airoha_ppe_is_enabled(qdma->eth, 1))
@@ -1863,7 +1863,7 @@ static int airoha_dev_stop(struct net_device *netdev)
REG_GDM_FWD_CFG(port->id),
FE_PSE_PORT_DROP);
- if (atomic_dec_and_test(&qdma->users)) {
+ if (!--qdma->users) {
airoha_qdma_clear(qdma, REG_QDMA_GLOBAL_CFG,
GLOBAL_CFG_TX_DMA_EN_MASK |
GLOBAL_CFG_RX_DMA_EN_MASK);
diff --git a/drivers/net/ethernet/airoha/airoha_eth.h b/drivers/net/ethernet/airoha/airoha_eth.h
index 8f42973f9cf5..e89c2dff411f 100644
--- a/drivers/net/ethernet/airoha/airoha_eth.h
+++ b/drivers/net/ethernet/airoha/airoha_eth.h
@@ -525,8 +525,7 @@ struct airoha_irq_bank {
struct airoha_qdma {
struct airoha_eth *eth;
void __iomem *regs;
-
- atomic_t users;
+ int users;
struct airoha_irq_bank irq_banks[AIROHA_MAX_NUM_IRQ_BANKS];
---
base-commit: 903db046d5579bef0ea699eae4b279dd6455fc9f
change-id: 20260606-airoha_qdma_users-no-atomic-0750cc2b42f1
Best regards,
--
Lorenzo Bianconi <lorenzo@kernel.org>
^ permalink raw reply related
* [PATCH net-next] net: airoha: add ethtool priv_flags support for LAN/WAN and GDM2 loopback
From: Lorenzo Bianconi @ 2026-06-06 6:30 UTC (permalink / raw)
To: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni
Cc: linux-arm-kernel, linux-mediatek, netdev, Madhur Agrawal,
Lorenzo Bianconi
Introduce ethtool private flags infrastructure for the airoha ethernet
driver, allowing userspace to configure per-device behavior via ethtool.
Implement the "wan" private flag to let the user select whether a GDM
port is used as a hardware LAN or WAN interface. GDM2 is fixed as WAN
only, GDM1 is fixed as LAN only, while GDM3 and GDM4 can be switched
between LAN and WAN at runtime (when the interface is not running).
When a GDM3/GDM4 port is set to WAN mode, enable GDM2 loopback to
support hardware QoS. Conversely, when switching back to LAN mode,
disable the GDM2 loopback and restore the default forwarding
configuration.
Add airoha_disable_gdm2_loopback() as the counterpart of the existing
airoha_enable_gdm2_loopback(), and define FC_MAP6_DEF_VALUE for use
during loopback teardown.
Example usage to configure eth1 (GDM3/GDM4) as WAN:
$ ethtool --show-priv-flags eth1
Private flags for eth1:
wan: off
$ ethtool --set-priv-flags eth1 wan on
$ ethtool --show-priv-flags eth1
Private flags for eth1:
wan: on
To revert back to LAN mode:
$ ethtool --set-priv-flags eth1 wan off
Tested-by: Madhur Agrawal <madhur.agrawal@airoha.com>
Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
---
drivers/net/ethernet/airoha/airoha_eth.c | 175 ++++++++++++++++++++++++++++++
drivers/net/ethernet/airoha/airoha_regs.h | 1 +
2 files changed, 176 insertions(+)
diff --git a/drivers/net/ethernet/airoha/airoha_eth.c b/drivers/net/ethernet/airoha/airoha_eth.c
index 5a8e84fa9918..487c5470fb01 100644
--- a/drivers/net/ethernet/airoha/airoha_eth.c
+++ b/drivers/net/ethernet/airoha/airoha_eth.c
@@ -1960,6 +1960,45 @@ static int airoha_enable_gdm2_loopback(struct airoha_gdm_dev *dev)
return 0;
}
+static int airoha_disable_gdm2_loopback(struct airoha_gdm_dev *dev)
+{
+ struct airoha_eth *eth = dev->eth;
+ int i, src_port;
+ u32 pse_port;
+
+ src_port = eth->soc->ops.get_sport(dev->port, dev->nbq);
+ if (src_port < 0)
+ return src_port;
+
+ airoha_fe_clear(eth,
+ REG_SP_DFT_CPORT(src_port >> fls(SP_CPORT_DFT_MASK)),
+ SP_CPORT_MASK(src_port & SP_CPORT_DFT_MASK));
+
+ airoha_set_gdm_port_fwd_cfg(eth, REG_GDM_FWD_CFG(AIROHA_GDM2_IDX),
+ FE_PSE_PORT_DROP);
+ airoha_fe_clear(eth, REG_GDM_LPBK_CFG(AIROHA_GDM2_IDX),
+ LPBK_CHAN_MASK | LPBK_MODE_MASK | LPBK_EN_MASK);
+ pse_port = airoha_ppe_is_enabled(eth, 1) ? FE_PSE_PORT_PPE2
+ : FE_PSE_PORT_PPE1;
+ airoha_set_gdm_port_fwd_cfg(eth, REG_GDM_FWD_CFG(AIROHA_GDM2_IDX),
+ pse_port);
+
+ airoha_fe_rmw(eth, REG_FE_WAN_PORT, WAN0_MASK,
+ FIELD_PREP(WAN0_MASK, AIROHA_GDM2_IDX));
+
+ for (i = 0; i < eth->soc->num_ppe; i++)
+ airoha_fe_clear(eth, REG_PPE_DFT_CPORT(i, AIROHA_GDM2_IDX),
+ DFT_CPORT_MASK(AIROHA_GDM2_IDX));
+
+ /* Enable VIP and IFC for GDM2 */
+ airoha_fe_set(eth, REG_FE_VIP_PORT_EN, BIT(AIROHA_GDM2_IDX));
+ airoha_fe_set(eth, REG_FE_IFC_PORT_EN, BIT(AIROHA_GDM2_IDX));
+
+ airoha_fe_wr(eth, REG_SRC_PORT_FC_MAP6, FC_MAP6_DEF_VALUE);
+
+ return 0;
+}
+
static struct airoha_gdm_dev *
airoha_get_wan_gdm_dev(struct airoha_eth *eth)
{
@@ -2296,6 +2335,87 @@ static netdev_tx_t airoha_dev_xmit(struct sk_buff *skb,
return NETDEV_TX_OK;
}
+struct airoha_ethool_priv_flags {
+ char name[ETH_GSTRING_LEN];
+ int (*handler)(struct net_device *netdev, u32 flags);
+};
+
+static int airoha_dev_set_wan_flag(struct net_device *netdev, u32 flags)
+{
+ struct airoha_gdm_dev *dev = netdev_priv(netdev);
+ struct airoha_gdm_port *port = dev->port;
+ struct airoha_eth *eth = dev->eth;
+
+ if (!((dev->flags ^ flags) & AIROHA_PRIV_F_WAN))
+ return 0;
+
+ if (netif_running(netdev))
+ return -EBUSY;
+
+ if (flags & AIROHA_PRIV_F_WAN) {
+ struct airoha_gdm_dev *wan_dev;
+
+ /* Verify the WAN device is not already configured */
+ wan_dev = airoha_get_wan_gdm_dev(eth);
+ if (wan_dev && wan_dev != dev)
+ return -EBUSY;
+
+ switch (port->id) {
+ case AIROHA_GDM2_IDX:
+ /* GDM2 can be used just as WAN */
+ return 0;
+ case AIROHA_GDM3_IDX:
+ case AIROHA_GDM4_IDX: {
+ int err;
+
+ dev->flags |= AIROHA_PRIV_F_WAN;
+ airoha_dev_set_qdma(dev);
+
+ err = airoha_enable_gdm2_loopback(dev);
+ if (err) {
+ dev->flags &= ~AIROHA_PRIV_F_WAN;
+ airoha_dev_set_qdma(dev);
+
+ return err;
+ }
+ break;
+ }
+ default:
+ /* GDM1 can be used just as LAN */
+ return -EOPNOTSUPP;
+ }
+ } else {
+ switch (port->id) {
+ case AIROHA_GDM2_IDX:
+ /* GDM2 can be used just as WAN */
+ return -EOPNOTSUPP;
+ case AIROHA_GDM3_IDX:
+ case AIROHA_GDM4_IDX: {
+ int err;
+
+ err = airoha_disable_gdm2_loopback(dev);
+ if (err)
+ return err;
+
+ dev->flags &= ~AIROHA_PRIV_F_WAN;
+ airoha_dev_set_qdma(dev);
+ break;
+ }
+ default:
+ /* GDM1 can be used just as LAN */
+ return 0;
+ }
+ }
+
+ return airoha_set_macaddr(dev, netdev->dev_addr);
+}
+
+static const struct airoha_ethool_priv_flags airoha_eth_priv_flags[] = {
+ { "wan", airoha_dev_set_wan_flag },
+};
+
+#define AIROHA_PRIV_FLAGS_STR_LEN ARRAY_SIZE(airoha_eth_priv_flags)
+
static void airoha_ethtool_get_drvinfo(struct net_device *netdev,
struct ethtool_drvinfo *info)
{
@@ -2304,6 +2424,7 @@ static void airoha_ethtool_get_drvinfo(struct net_device *netdev,
strscpy(info->driver, eth->dev->driver->name, sizeof(info->driver));
strscpy(info->bus_info, dev_name(eth->dev), sizeof(info->bus_info));
+ info->n_priv_flags = AIROHA_PRIV_FLAGS_STR_LEN;
}
static void airoha_ethtool_get_mac_stats(struct net_device *netdev,
@@ -2368,6 +2489,56 @@ airoha_ethtool_get_rmon_stats(struct net_device *netdev,
} while (u64_stats_fetch_retry(&port->stats.syncp, start));
}
+static int airoha_ethtool_set_priv_flags(struct net_device *netdev, u32 flags)
+{
+ int i;
+
+ for (i = 0; i < AIROHA_PRIV_FLAGS_STR_LEN; i++) {
+ int err;
+
+ if (!airoha_eth_priv_flags[i].handler)
+ continue;
+
+ err = airoha_eth_priv_flags[i].handler(netdev, flags);
+ if (err)
+ return err;
+ }
+
+ return 0;
+}
+
+static u32 airoha_ethtool_get_priv_flags(struct net_device *netdev)
+{
+ struct airoha_gdm_dev *dev = netdev_priv(netdev);
+
+ return dev->flags;
+}
+
+static int airoha_ethtool_get_sset_count(struct net_device *netdev, int sset)
+{
+ switch (sset) {
+ case ETH_SS_PRIV_FLAGS:
+ return AIROHA_PRIV_FLAGS_STR_LEN;
+ default:
+ return -EOPNOTSUPP;
+ }
+}
+
+static void airoha_ethtool_get_strings(struct net_device *netdev,
+ u32 stringset, u8 *data)
+{
+ int i;
+
+ switch (stringset) {
+ case ETH_SS_PRIV_FLAGS:
+ for (i = 0; i < AIROHA_PRIV_FLAGS_STR_LEN; i++)
+ ethtool_puts(&data, airoha_eth_priv_flags[i].name);
+ break;
+ default:
+ break;
+ }
+}
+
static int airoha_qdma_set_chan_tx_sched(struct net_device *netdev,
int channel, enum tx_sched_mode mode,
const u16 *weights, u8 n_weights)
@@ -3094,6 +3265,10 @@ static const struct ethtool_ops airoha_ethtool_ops = {
.get_rmon_stats = airoha_ethtool_get_rmon_stats,
.get_link_ksettings = phy_ethtool_get_link_ksettings,
.get_link = ethtool_op_get_link,
+ .set_priv_flags = airoha_ethtool_set_priv_flags,
+ .get_priv_flags = airoha_ethtool_get_priv_flags,
+ .get_sset_count = airoha_ethtool_get_sset_count,
+ .get_strings = airoha_ethtool_get_strings,
};
static int airoha_metadata_dst_alloc(struct airoha_gdm_port *port)
diff --git a/drivers/net/ethernet/airoha/airoha_regs.h b/drivers/net/ethernet/airoha/airoha_regs.h
index 436f3c8779c1..4e17dfbcf2b8 100644
--- a/drivers/net/ethernet/airoha/airoha_regs.h
+++ b/drivers/net/ethernet/airoha/airoha_regs.h
@@ -376,6 +376,7 @@
#define REG_SRC_PORT_FC_MAP6 0x2298
#define FC_ID_OF_SRC_PORT_MASK(_n) GENMASK(4 + ((_n) << 3), ((_n) << 3))
+#define FC_MAP6_DEF_VALUE 0x1b1a1918
#define REG_CDM5_RX_OQ1_DROP_CNT 0x29d4
---
base-commit: 903db046d5579bef0ea699eae4b279dd6455fc9f
change-id: 20260606-airoha-ethtool-priv_flags-b6aa70caa780
Best regards,
--
Lorenzo Bianconi <lorenzo@kernel.org>
^ permalink raw reply related
* [PATCH net-next] net: airoha: simplify WAN device check in airoha_dev_init()
From: Lorenzo Bianconi @ 2026-06-06 7:05 UTC (permalink / raw)
To: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni
Cc: linux-arm-kernel, linux-mediatek, netdev, Lorenzo Bianconi
airoha_register_gdm_devices() iterates eth->ports[] in order, so GDM2's
netdev is always registered before GDM3/GDM4. This means the explicit
check for eth->ports[1] && eth->ports[1]->devs[0] is a redundant
special-case of what airoha_get_wan_gdm_dev() already covers, since
GDM2 is always marked as WAN during its own ndo_init.
Remove the redundant check and rely solely on airoha_get_wan_gdm_dev()
which handles both the GDM2-present and GDM2-absent cases.
Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
---
drivers/net/ethernet/airoha/airoha_eth.c | 12 ++----------
1 file changed, 2 insertions(+), 10 deletions(-)
diff --git a/drivers/net/ethernet/airoha/airoha_eth.c b/drivers/net/ethernet/airoha/airoha_eth.c
index 5a8e84fa9918..b333a7b309c2 100644
--- a/drivers/net/ethernet/airoha/airoha_eth.c
+++ b/drivers/net/ethernet/airoha/airoha_eth.c
@@ -2004,18 +2004,10 @@ static int airoha_dev_init(struct net_device *netdev)
switch (port->id) {
case AIROHA_GDM3_IDX:
- case AIROHA_GDM4_IDX: {
- struct airoha_eth *eth = dev->eth;
-
- /* GDM2 supports a single net_device */
- if (eth->ports[1] && eth->ports[1]->devs[0])
- break;
-
- if (airoha_get_wan_gdm_dev(eth))
+ case AIROHA_GDM4_IDX:
+ if (airoha_get_wan_gdm_dev(dev->eth))
break;
-
fallthrough;
- }
case AIROHA_GDM2_IDX:
/* GDM2 is always used as wan */
dev->flags |= AIROHA_PRIV_F_WAN;
---
base-commit: 903db046d5579bef0ea699eae4b279dd6455fc9f
change-id: 20260606-airoha-eth-simplify-dev-init-5d53c7cc004e
Best regards,
--
Lorenzo Bianconi <lorenzo@kernel.org>
^ permalink raw reply related
* Re: [RESEND,v2 1/2] dt-bindings: memory-controllers: mtk-smi: Add support for mt8189
From: Zhengnan Chen (陈征南) @ 2026-06-06 8:06 UTC (permalink / raw)
To: robh@kernel.org, matthias.bgg@gmail.com,
Yong Wu (吴勇), conor+dt@kernel.org, krzk@kernel.org,
AngeloGioacchino Del Regno
Cc: linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, linux-mediatek@lists.infradead.org,
Congcong Yao (姚聪聪),
devicetree@vger.kernel.org, Project_Global_Chrome_Upstream_Group
In-Reply-To: <50e53fd9-4cca-4cac-9f8d-868de3a8a7bc@kernel.org>
On Sun, 2026-05-24 at 21:08 +0200, Krzysztof Kozlowski wrote:
> On 27/04/2026 09:04, mtk20898 wrote:
> > From: Zhengnan Chen <zhengnan.chen@mediatek.com>
> >
> > Add binding description for mt8189.
> >
> > The clocks number of mt8189 smi-sub common has a bit difference.
> > Its clock count is 2, while mt8195 has 3. Therefore, the minimum
> > number of clocks is changed to 2, with the third one being
> > optional.
>
> Then why does the binding say that mt8195 has two clocks? You already
> received exactly this question.
>
The MT8195 SMI_sub_common has always been designed with three clocks.
We have reviewed the HW design of the MT8189 SMI_sub_common and
confirmed that the MT8189 should also follow the MT8195's settings and
maintain a three-clock DTS configuration.
We will send out the next version as soon as possible.
> >
> > About what smi-sub-common is, please check the below diagram,
> > we add it in mediatek,smi-common.yaml file.
> >
> > Signed-off-by: Zhengnan Chen <zhengnan.chen@mediatek.com>
> > Reviewed-by: AngeloGioacchino Del Regno <
> > angelogioacchino.delregno@collabora.com>
>
>
> No need to resend this. You received comments at v2 and you should
> have
> implemented them.
>
OK, we will remove this in next version.
> Best regards,
> Krzysztof
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox