* [PATCH v4 3/7] pinctrl: extract pinctrl_generic_to_map() from pinctrl_generic_pins_function_dt_node_to_map()
From: Frank Li @ 2026-03-25 23:04 UTC (permalink / raw)
To: Peter Rosin, Linus Walleij, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Rafał Miłecki, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam
Cc: linux-kernel, linux-gpio, devicetree, imx, linux-arm-kernel,
Haibo Chen, Frank Li
In-Reply-To: <20260325-pinctrl-mux-v4-0-043c2c82e623@nxp.com>
Refactor pinctrl_generic_pins_function_dt_subnode_to_map() by separating DT
parsing logic from map creation. Introduce a new helper
pinctrl_generic_to_map() to handle mapping to kernel data structures, while
keeping DT property parsing in the subnode function.
Improve code structure and enables easier reuse for platforms using
different DT properties (e.g. pinmux) without modifying the
dt_node_to_map-style callback API. Avoid unnecessary coupling to
pinctrl_generic_pins_function_dt_node_to_map(), which provides
functionality not needed when the phandle target is unambiguous.
Maximize code reuse and provide a cleaner extension point for future
pinctrl drivers.
Signed-off-by: Frank Li <Frank.Li@nxp.com>
---
change in v4
- new patch
---
drivers/pinctrl/pinconf.h | 18 ++++++++
drivers/pinctrl/pinctrl-generic.c | 91 ++++++++++++++++++++++++---------------
2 files changed, 74 insertions(+), 35 deletions(-)
diff --git a/drivers/pinctrl/pinconf.h b/drivers/pinctrl/pinconf.h
index 2880adef476e68950ffdd540ea42cdee6a16ec27..ffdabddb9660324ed8886a2e8dcacff7e1c6c529 100644
--- a/drivers/pinctrl/pinconf.h
+++ b/drivers/pinctrl/pinconf.h
@@ -166,6 +166,13 @@ int pinctrl_generic_pins_function_dt_node_to_map(struct pinctrl_dev *pctldev,
struct device_node *np,
struct pinctrl_map **maps,
unsigned int *num_maps);
+
+int
+pinctrl_generic_to_map(struct pinctrl_dev *pctldev, struct device_node *parent,
+ struct device_node *np, struct pinctrl_map **maps,
+ unsigned int *num_maps, unsigned int *num_reserved_maps,
+ const char **group_name, unsigned int ngroups,
+ const char **functions, unsigned int *pins);
#else
static inline int
pinctrl_generic_pins_function_dt_node_to_map(struct pinctrl_dev *pctldev,
@@ -175,4 +182,15 @@ pinctrl_generic_pins_function_dt_node_to_map(struct pinctrl_dev *pctldev,
{
return -ENOTSUPP;
}
+
+static inline int
+pinctrl_generic_to_map(struct pinctrl_dev *pctldev, struct device_node *parent,
+ struct device_node *np, struct pinctrl_map **maps,
+ unsigned int *num_maps, unsigned int *num_reserved_maps,
+ const char **group_name, unsigned int ngroups,
+ const char **functions, unsigned int *pins,
+ void *function_data)
+{
+ return -ENOTSUPP;
+}
#endif
diff --git a/drivers/pinctrl/pinctrl-generic.c b/drivers/pinctrl/pinctrl-generic.c
index efb39c6a670331775855efdc8566102b5c6202ef..20a216ae63e91b69985ea4cfcd0b57103c6ca950 100644
--- a/drivers/pinctrl/pinctrl-generic.c
+++ b/drivers/pinctrl/pinctrl-generic.c
@@ -17,29 +17,18 @@
#include "pinctrl-utils.h"
#include "pinmux.h"
-static int pinctrl_generic_pins_function_dt_subnode_to_map(struct pinctrl_dev *pctldev,
- struct device_node *parent,
- struct device_node *np,
- struct pinctrl_map **maps,
- unsigned int *num_maps,
- unsigned int *num_reserved_maps,
- const char **group_names,
- unsigned int ngroups)
+int
+pinctrl_generic_to_map(struct pinctrl_dev *pctldev, struct device_node *parent,
+ struct device_node *np, struct pinctrl_map **maps,
+ unsigned int *num_maps, unsigned int *num_reserved_maps,
+ const char **group_names, unsigned int ngroups,
+ const char **functions, unsigned int *pins)
{
struct device *dev = pctldev->dev;
- const char **functions;
+ int npins, ret, reserve = 1;
+ unsigned int num_configs;
const char *group_name;
unsigned long *configs;
- unsigned int num_configs, pin, *pins;
- int npins, ret, reserve = 1;
-
- npins = of_property_count_u32_elems(np, "pins");
-
- if (npins < 1) {
- dev_err(dev, "invalid pinctrl group %pOFn.%pOFn %d\n",
- parent, np, npins);
- return npins;
- }
group_name = devm_kasprintf(dev, GFP_KERNEL, "%pOFn.%pOFn", parent, np);
if (!group_name)
@@ -51,22 +40,6 @@ static int pinctrl_generic_pins_function_dt_subnode_to_map(struct pinctrl_dev *p
if (!pins)
return -ENOMEM;
- functions = devm_kcalloc(dev, npins, sizeof(*functions), GFP_KERNEL);
- if (!functions)
- return -ENOMEM;
-
- for (int i = 0; i < npins; i++) {
- ret = of_property_read_u32_index(np, "pins", i, &pin);
- if (ret)
- return ret;
-
- pins[i] = pin;
-
- ret = of_property_read_string(np, "function", &functions[i]);
- if (ret)
- return ret;
- }
-
ret = pinctrl_utils_reserve_map(pctldev, maps, num_reserved_maps, num_maps, reserve);
if (ret)
return ret;
@@ -103,6 +76,54 @@ static int pinctrl_generic_pins_function_dt_subnode_to_map(struct pinctrl_dev *p
return 0;
};
+static int
+pinctrl_generic_pins_function_dt_subnode_to_map(struct pinctrl_dev *pctldev,
+ struct device_node *parent,
+ struct device_node *np,
+ struct pinctrl_map **maps,
+ unsigned int *num_maps,
+ unsigned int *num_reserved_maps,
+ const char **group_names,
+ unsigned int ngroups)
+{
+ struct device *dev = pctldev->dev;
+ unsigned int pin, *pins;
+ const char **functions;
+ int npins, ret;
+
+ npins = of_property_count_u32_elems(np, "pins");
+
+ if (npins < 1) {
+ dev_err(dev, "invalid pinctrl group %pOFn.%pOFn %d\n",
+ parent, np, npins);
+ return npins;
+ }
+
+ pins = devm_kcalloc(dev, npins, sizeof(*pins), GFP_KERNEL);
+ if (!pins)
+ return -ENOMEM;
+
+ functions = devm_kcalloc(dev, npins, sizeof(*functions), GFP_KERNEL);
+ if (!functions)
+ return -ENOMEM;
+
+ for (int i = 0; i < npins; i++) {
+ ret = of_property_read_u32_index(np, "pins", i, &pin);
+ if (ret)
+ return ret;
+
+ pins[i] = pin;
+
+ ret = of_property_read_string(np, "function", &functions[i]);
+ if (ret)
+ return ret;
+ }
+
+ return pinctrl_generic_to_map(pctldev, parent, np, maps, num_maps,
+ num_reserved_maps, group_names, ngroups,
+ functions, pins);
+}
+
/*
* For platforms that do not define groups or functions in the driver, but
* instead use the devicetree to describe them. This function will, unlike
--
2.43.0
^ permalink raw reply related
* [PATCH v4 5/7] pinctrl: add generic board-level pinctrl driver using mux framework
From: Frank Li @ 2026-03-25 23:04 UTC (permalink / raw)
To: Peter Rosin, Linus Walleij, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Rafał Miłecki, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam
Cc: linux-kernel, linux-gpio, devicetree, imx, linux-arm-kernel,
Haibo Chen, Frank Li
In-Reply-To: <20260325-pinctrl-mux-v4-0-043c2c82e623@nxp.com>
Many boards use on-board mux chips (often controlled by GPIOs from an I2C
expander) to switch shared signals between peripherals.
Add a generic pinctrl driver built on top of the mux framework to
centralize mux handling and avoid probe ordering issues. Keep board-level
routing out of individual drivers and supports boot-time only mux
selection.
Ensure correct probe ordering, especially when the GPIO expander is probed
later.
Signed-off-by: Frank Li <Frank.Li@nxp.com>
---
chagne in v4:
- use new pinctrl_generic_pins_to_map()
change in v3:
- use pinctrl_generic_pins_function_dt_node_to_map() and
pinctrl_utils_free_map().
change in v2:
- fix copywrite by add nxp
- fix if (!*map) check
- add release_mux to call mux_state_deselect()
---
drivers/pinctrl/Kconfig | 9 ++
drivers/pinctrl/Makefile | 1 +
drivers/pinctrl/pinctrl-generic-mux.c | 197 ++++++++++++++++++++++++++++++++++
3 files changed, 207 insertions(+)
diff --git a/drivers/pinctrl/Kconfig b/drivers/pinctrl/Kconfig
index afecd9407f5354f5b92223f8cd80d2f7a08f8e7d..b6d4755e67510786c34f890c5e7a3fcf0adf45e4 100644
--- a/drivers/pinctrl/Kconfig
+++ b/drivers/pinctrl/Kconfig
@@ -274,6 +274,15 @@ config PINCTRL_GEMINI
select GENERIC_PINCONF
select MFD_SYSCON
+config PINCTRL_GENERIC_MUX
+ tristate "Generic Pinctrl driver by using multiplexer"
+ depends on MULTIPLEXER
+ select PINMUX
+ select GENERIC_PINCTRL
+ help
+ Generic pinctrl driver by MULTIPLEXER framework to control on
+ board pin selection.
+
config PINCTRL_INGENIC
bool "Pinctrl driver for the Ingenic JZ47xx SoCs"
default MACH_INGENIC
diff --git a/drivers/pinctrl/Makefile b/drivers/pinctrl/Makefile
index f7d5d5f76d0c8becc0aa1d77c68b6ced924ea264..fcd1703440d24579636e8ddb6cbd83a0a982dfb7 100644
--- a/drivers/pinctrl/Makefile
+++ b/drivers/pinctrl/Makefile
@@ -29,6 +29,7 @@ obj-$(CONFIG_PINCTRL_EQUILIBRIUM) += pinctrl-equilibrium.o
obj-$(CONFIG_PINCTRL_EP93XX) += pinctrl-ep93xx.o
obj-$(CONFIG_PINCTRL_EYEQ5) += pinctrl-eyeq5.o
obj-$(CONFIG_PINCTRL_GEMINI) += pinctrl-gemini.o
+obj-$(CONFIG_PINCTRL_GENERIC_MUX) += pinctrl-generic-mux.o
obj-$(CONFIG_PINCTRL_INGENIC) += pinctrl-ingenic.o
obj-$(CONFIG_PINCTRL_K210) += pinctrl-k210.o
obj-$(CONFIG_PINCTRL_K230) += pinctrl-k230.o
diff --git a/drivers/pinctrl/pinctrl-generic-mux.c b/drivers/pinctrl/pinctrl-generic-mux.c
new file mode 100644
index 0000000000000000000000000000000000000000..d1c1ff16a78dfd9ea66c51e9f70af1839844bcec
--- /dev/null
+++ b/drivers/pinctrl/pinctrl-generic-mux.c
@@ -0,0 +1,197 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Generic Pin Control Driver for Board-Level Mux Chips
+ * Copyright 2026 NXP
+ */
+
+#include <linux/cleanup.h>
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/mutex.h>
+#include <linux/mux/consumer.h>
+#include <linux/platform_device.h>
+#include <linux/pinctrl/pinconf-generic.h>
+#include <linux/pinctrl/pinctrl.h>
+#include <linux/pinctrl/pinmux.h>
+#include <linux/slab.h>
+
+#include "core.h"
+#include "pinconf.h"
+#include "pinmux.h"
+#include "pinctrl-utils.h"
+
+struct mux_pin_function {
+ struct mux_state *mux_state;
+};
+
+struct mux_pinctrl {
+ struct device *dev;
+ struct pinctrl_dev *pctl;
+
+ /* mutex protect [pinctrl|pinmux]_generic functions */
+ struct mutex lock;
+ int cur_select;
+};
+
+static int
+mux_pinmux_dt_node_to_map(struct pinctrl_dev *pctldev,
+ struct device_node *np_config,
+ struct pinctrl_map **maps, unsigned int *num_maps)
+{
+ unsigned int num_reserved_maps = 0;
+ struct mux_pin_function *function;
+ const char **group_names;
+ int ret;
+
+ function = devm_kzalloc(pctldev->dev, sizeof(*function), GFP_KERNEL);
+ if (!function)
+ return -ENOMEM;
+
+ group_names = devm_kcalloc(pctldev->dev, 1, sizeof(*group_names), GFP_KERNEL);
+ if (!group_names)
+ return -ENOMEM;
+
+ function->mux_state = devm_mux_state_get_from_np(pctldev->dev, NULL, np_config);
+ if (IS_ERR(function->mux_state))
+ return PTR_ERR(function->mux_state);
+
+ ret = pinctrl_generic_to_map(pctldev, np_config, np_config, maps,
+ num_maps, &num_reserved_maps, group_names,
+ 0, &np_config->name, NULL);
+
+ if (ret)
+ return ret;
+
+ ret = pinmux_generic_add_function(pctldev, np_config->name, group_names,
+ 1, function);
+ if (ret < 0) {
+ pinctrl_utils_free_map(pctldev, *maps, *num_maps);
+ return ret;
+ }
+
+ return 0;
+}
+
+static const struct pinctrl_ops mux_pinctrl_ops = {
+ .get_groups_count = pinctrl_generic_get_group_count,
+ .get_group_name = pinctrl_generic_get_group_name,
+ .get_group_pins = pinctrl_generic_get_group_pins,
+ .dt_node_to_map = mux_pinmux_dt_node_to_map,
+ .dt_free_map = pinctrl_utils_free_map,
+};
+
+static int mux_pinmux_set_mux(struct pinctrl_dev *pctldev,
+ unsigned int func_selector,
+ unsigned int group_selector)
+{
+ struct mux_pinctrl *mpctl = pinctrl_dev_get_drvdata(pctldev);
+ const struct function_desc *function;
+ struct mux_pin_function *func;
+ int ret;
+
+ guard(mutex)(&mpctl->lock);
+
+ function = pinmux_generic_get_function(pctldev, func_selector);
+ func = function->data;
+
+ if (mpctl->cur_select == func_selector)
+ return 0;
+
+ if (mpctl->cur_select >= 0 && mpctl->cur_select != func_selector)
+ return -EINVAL;
+
+ ret = mux_state_select(func->mux_state);
+ if (ret)
+ return ret;
+
+ mpctl->cur_select = func_selector;
+
+ return 0;
+}
+
+static void mux_pinmux_release_mux(struct pinctrl_dev *pctldev,
+ unsigned int func_selector,
+ unsigned int group_selector)
+{
+ struct mux_pinctrl *mpctl = pinctrl_dev_get_drvdata(pctldev);
+ const struct function_desc *function;
+ struct mux_pin_function *func;
+
+ guard(mutex)(&mpctl->lock);
+
+ function = pinmux_generic_get_function(pctldev, func_selector);
+ func = function->data;
+
+ mux_state_deselect(func->mux_state);
+
+ mpctl->cur_select = -1;
+}
+
+static const struct pinmux_ops mux_pinmux_ops = {
+ .get_functions_count = pinmux_generic_get_function_count,
+ .get_function_name = pinmux_generic_get_function_name,
+ .get_function_groups = pinmux_generic_get_function_groups,
+ .set_mux = mux_pinmux_set_mux,
+ .release_mux = mux_pinmux_release_mux,
+};
+
+static int mux_pinctrl_probe(struct platform_device *pdev)
+{
+ struct device *dev = &pdev->dev;
+ struct mux_pinctrl *mpctl;
+ struct pinctrl_desc *pctl_desc;
+ int ret;
+
+ mpctl = devm_kzalloc(dev, sizeof(*mpctl), GFP_KERNEL);
+ if (!mpctl)
+ return -ENOMEM;
+
+ mpctl->dev = dev;
+ mpctl->cur_select = -1;
+
+ platform_set_drvdata(pdev, mpctl);
+
+ pctl_desc = devm_kzalloc(dev, sizeof(*pctl_desc), GFP_KERNEL);
+ if (!pctl_desc)
+ return -ENOMEM;
+
+ ret = devm_mutex_init(dev, &mpctl->lock);
+ if (ret)
+ return ret;
+
+ pctl_desc->name = dev_name(dev);
+ pctl_desc->owner = THIS_MODULE;
+ pctl_desc->pctlops = &mux_pinctrl_ops;
+ pctl_desc->pmxops = &mux_pinmux_ops;
+
+ ret = devm_pinctrl_register_and_init(dev, pctl_desc, mpctl,
+ &mpctl->pctl);
+ if (ret)
+ return dev_err_probe(dev, ret, "Failed to register pinctrl.\n");
+
+ ret = pinctrl_enable(mpctl->pctl);
+ if (ret)
+ return dev_err_probe(dev, ret, "Failed to enable pinctrl.\n");
+
+ return 0;
+}
+
+static const struct of_device_id mux_pinctrl_of_match[] = {
+ { .compatible = "pinctrl-multiplexer" },
+ { }
+};
+MODULE_DEVICE_TABLE(of, mux_pinctrl_of_match);
+
+static struct platform_driver mux_pinctrl_driver = {
+ .driver = {
+ .name = "generic-pinctrl-mux",
+ .of_match_table = mux_pinctrl_of_match,
+ },
+ .probe = mux_pinctrl_probe,
+};
+module_platform_driver(mux_pinctrl_driver);
+
+MODULE_AUTHOR("Frank Li <Frank.Li@nxp.com>");
+MODULE_DESCRIPTION("Generic Pin Control Driver for Board-Level Mux Chips");
+MODULE_LICENSE("GPL");
+
--
2.43.0
^ permalink raw reply related
* [PATCH v4 4/7] pinctrl: add optional .release_mux() callback
From: Frank Li @ 2026-03-25 23:04 UTC (permalink / raw)
To: Peter Rosin, Linus Walleij, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Rafał Miłecki, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam
Cc: linux-kernel, linux-gpio, devicetree, imx, linux-arm-kernel,
Haibo Chen, Frank Li
In-Reply-To: <20260325-pinctrl-mux-v4-0-043c2c82e623@nxp.com>
Add an optional .release_mux() callback to struct pinmux_ops.
Some drivers acquire additional resources in .set_mux(), such as software
locks. These resources may need to be released when the mux function is no
longer active. Introducing a dedicated .release_mux() callback allows
drivers to clean up such resources.
The callback is optional and does not affect existing drivers.
Commit 2243a87d90b42 ("pinctrl: avoid duplicated calling
enable_pinmux_setting for a pin") removed the .disable() callback
to resolve two issues:
1. desc->mux_usecount increasing monotonically
2. Hardware glitches caused by repeated .disable()/.enable() calls
Adding .release_mux() does not reintroduce those problems. The callback is
intended only for releasing driver-side resources (e.g. locks) and must not
modify hardware registers.
Signed-off-by: Frank Li <Frank.Li@nxp.com>
---
change in v4
- none
change in v3
- Add judgement about 2243a87d90b42 ("pinctrl: avoid duplicated calling
enable_pinmux_setting for a pin") in commit message.
---
drivers/pinctrl/pinmux.c | 5 +++++
include/linux/pinctrl/pinmux.h | 5 +++++
2 files changed, 10 insertions(+)
diff --git a/drivers/pinctrl/pinmux.c b/drivers/pinctrl/pinmux.c
index 3a8dd184ba3d670e01a890427e19af59b65eb813..c705bc182266c596c4e6c820f5e3ffcadbbb2838 100644
--- a/drivers/pinctrl/pinmux.c
+++ b/drivers/pinctrl/pinmux.c
@@ -517,6 +517,7 @@ void pinmux_disable_setting(const struct pinctrl_setting *setting)
{
struct pinctrl_dev *pctldev = setting->pctldev;
const struct pinctrl_ops *pctlops = pctldev->desc->pctlops;
+ const struct pinmux_ops *ops = pctldev->desc->pmxops;
int ret = 0;
const unsigned int *pins = NULL;
unsigned int num_pins = 0;
@@ -563,6 +564,10 @@ void pinmux_disable_setting(const struct pinctrl_setting *setting)
pins[i], desc->name, gname);
}
}
+
+ if (ops->release_mux)
+ ops->release_mux(pctldev, setting->data.mux.func,
+ setting->data.mux.group);
}
#ifdef CONFIG_DEBUG_FS
diff --git a/include/linux/pinctrl/pinmux.h b/include/linux/pinctrl/pinmux.h
index 094bbe2fd6fd5ea3c5fdf5b6d6d9a7639700b50b..77664937eeb273eef440988c4cf833dbc6f10758 100644
--- a/include/linux/pinctrl/pinmux.h
+++ b/include/linux/pinctrl/pinmux.h
@@ -51,6 +51,8 @@ struct pinctrl_gpio_range;
* are handled by the pinmux subsystem. The @func_selector selects a
* certain function whereas @group_selector selects a certain set of pins
* to be used. On simple controllers the latter argument may be ignored
+ * @release_mux: Release software resources acquired by @set_mux. This callback
+ * must not change hardware state to avoid glitches when switching mux.
* @gpio_request_enable: requests and enables GPIO on a certain pin.
* Implement this only if you can mux every pin individually as GPIO. The
* affected GPIO range is passed along with an offset(pin number) into that
@@ -80,6 +82,9 @@ struct pinmux_ops {
unsigned int selector);
int (*set_mux) (struct pinctrl_dev *pctldev, unsigned int func_selector,
unsigned int group_selector);
+ void (*release_mux) (struct pinctrl_dev *pctldev,
+ unsigned int func_selector,
+ unsigned int group_selector);
int (*gpio_request_enable) (struct pinctrl_dev *pctldev,
struct pinctrl_gpio_range *range,
unsigned int offset);
--
2.43.0
^ permalink raw reply related
* [PATCH v4 6/7] arm64: dts: imx8mp-evk: add board-level mux for CAN2 and MICFIL
From: Frank Li @ 2026-03-25 23:04 UTC (permalink / raw)
To: Peter Rosin, Linus Walleij, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Rafał Miłecki, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam
Cc: linux-kernel, linux-gpio, devicetree, imx, linux-arm-kernel,
Haibo Chen, Frank Li, Ahmad Fatoum
In-Reply-To: <20260325-pinctrl-mux-v4-0-043c2c82e623@nxp.com>
The board integrates an on-board mux to route shared signals to either
CAN2 or PDM (MICFIL). The mux is controlled by a GPIO.
Add a pinctrl-based multiplexer node to describe this routing and ensure
proper probe ordering of the dependent devices.
Previously, MICFIL operation implicitly depended on the default level of
PCA6416 GPIO3. After adding the pinctrl-multiplexer, make the dependency
explicit.
Reviewed-by: Ahmad Fatoum <a.fatoum@pengutronix.de>
Signed-off-by: Frank Li <Frank.Li@nxp.com>
---
change in v3 - v4
- none
change in v2
- update commit message to show why need update PDM MICIFL.
---
arch/arm64/boot/dts/freescale/imx8mp-evk.dts | 23 +++++++++++++++++++++--
1 file changed, 21 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/boot/dts/freescale/imx8mp-evk.dts b/arch/arm64/boot/dts/freescale/imx8mp-evk.dts
index b256be710ea1281465f5cecc7a3b979f2c068e43..1341ee27239fd41a26117adc9023524ce50420a7 100644
--- a/arch/arm64/boot/dts/freescale/imx8mp-evk.dts
+++ b/arch/arm64/boot/dts/freescale/imx8mp-evk.dts
@@ -50,6 +50,25 @@ status {
};
};
+ can_mux: mux-controller-0 {
+ compatible = "gpio-mux";
+ #mux-control-cells = <0>;
+ #mux-state-cells = <1>;
+ mux-gpios = <&pca6416 3 GPIO_ACTIVE_HIGH>;
+ };
+
+ can_mux_pinctrl: pinctrl-gpiomux {
+ compatible = "pinctrl-multiplexer";
+
+ can_fun: can-grp {
+ mux-states = <&can_mux 1>;
+ };
+
+ pdm_fun: pdm-grp {
+ mux-states = <&can_mux 0>;
+ };
+ };
+
memory@40000000 {
device_type = "memory";
reg = <0x0 0x40000000 0 0xc0000000>,
@@ -446,7 +465,7 @@ &flexcan1 {
&flexcan2 {
pinctrl-names = "default";
- pinctrl-0 = <&pinctrl_flexcan2>;
+ pinctrl-0 = <&pinctrl_flexcan2>, <&can_fun>;
phys = <&flexcan_phy 1>;
status = "disabled";/* can2 pin conflict with pdm */
};
@@ -712,7 +731,7 @@ &lcdif3 {
&micfil {
#sound-dai-cells = <0>;
pinctrl-names = "default";
- pinctrl-0 = <&pinctrl_pdm>;
+ pinctrl-0 = <&pinctrl_pdm>, <&pdm_fun>;
assigned-clocks = <&clk IMX8MP_CLK_PDM>;
assigned-clock-parents = <&clk IMX8MP_AUDIO_PLL1_OUT>;
assigned-clock-rates = <196608000>;
--
2.43.0
^ permalink raw reply related
* [PATCH v4 7/7] arm64: dts: imx8mp-evk: add flexcan2 overlay file
From: Frank Li @ 2026-03-25 23:04 UTC (permalink / raw)
To: Peter Rosin, Linus Walleij, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Rafał Miłecki, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam
Cc: linux-kernel, linux-gpio, devicetree, imx, linux-arm-kernel,
Haibo Chen, Frank Li
In-Reply-To: <20260325-pinctrl-mux-v4-0-043c2c82e623@nxp.com>
Add flexcan2 overlay file, which enable flexcan2 node and disable micfil
node.
Signed-off-by: Frank Li <Frank.Li@nxp.com>
---
change in v3-v4
- none
---
arch/arm64/boot/dts/freescale/Makefile | 4 ++++
arch/arm64/boot/dts/freescale/imx8mp-evk-flexcan2.dtso | 15 +++++++++++++++
2 files changed, 19 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/Makefile b/arch/arm64/boot/dts/freescale/Makefile
index 700bab4d3e6001fe6cf460fcb09cfe57acc77e36..bd377191a68a6167d5f9a65184d19c789a4223ee 100644
--- a/arch/arm64/boot/dts/freescale/Makefile
+++ b/arch/arm64/boot/dts/freescale/Makefile
@@ -233,6 +233,10 @@ dtb-$(CONFIG_ARCH_MXC) += imx8mp-dhcom-pdk3.dtb
dtb-$(CONFIG_ARCH_MXC) += imx8mp-dhcom-picoitx.dtb
dtb-$(CONFIG_ARCH_MXC) += imx8mp-edm-g-wb.dtb
dtb-$(CONFIG_ARCH_MXC) += imx8mp-evk.dtb
+
+imx8mp-evk-flexcan2-dtbs += imx8mp-evk.dtb imx8mp-evk-flexcan2.dtbo
+dtb-$(CONFIG_ARCH_MXC) += imx8mp-evk-flexcan2.dtb
+
dtb-$(CONFIG_ARCH_MXC) += imx8mp-frdm.dtb
dtb-$(CONFIG_ARCH_MXC) += imx8mp-hummingboard-mate.dtb
dtb-$(CONFIG_ARCH_MXC) += imx8mp-hummingboard-pro.dtb
diff --git a/arch/arm64/boot/dts/freescale/imx8mp-evk-flexcan2.dtso b/arch/arm64/boot/dts/freescale/imx8mp-evk-flexcan2.dtso
new file mode 100644
index 0000000000000000000000000000000000000000..f7d2674c45f72353a20300300e98c8a1eba4a2a6
--- /dev/null
+++ b/arch/arm64/boot/dts/freescale/imx8mp-evk-flexcan2.dtso
@@ -0,0 +1,15 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright 2026 NXP
+ */
+
+/dts-v1/;
+/plugin/;
+
+&flexcan2 {
+ status = "okay"; /* can2 pin conflict with pdm */
+};
+
+&micfil {
+ status = "disabled";
+};
--
2.43.0
^ permalink raw reply related
* [PATCH v2] ARM: tegra: paz00: configure WiFi rfkill switch through device tree
From: Dmitry Torokhov @ 2026-03-25 23:29 UTC (permalink / raw)
To: Thierry Reding
Cc: Marc Dietrich, Krzysztof Kozlowski, Rob Herring, Conor Dooley,
Jonathan Hunter, Bartosz Golaszewski, devicetree, linux-tegra,
linux-kernel, linux-arm-kernel
As of d64c732dfc9e ("net: rfkill: gpio: add DT support") rfkill-gpio
device can be instantiated via device tree.
Add the declaration there and drop board-paz00.c file and relevant
Makefile fragments.
Tested-by: Marc Dietrich <marvin24@gmx.de>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
---
V2:
- added Marc's Tested-by
V1:
- https://lore.kernel.org/r/aY_BpRQmLdqOOW2K@google.com
arch/arm/boot/dts/nvidia/tegra20-paz00.dts | 8 ++++
arch/arm/mach-tegra/Makefile | 2 -
arch/arm/mach-tegra/board-paz00.c | 56 ----------------------
arch/arm/mach-tegra/board.h | 2 -
arch/arm/mach-tegra/tegra.c | 4 --
5 files changed, 8 insertions(+), 64 deletions(-)
diff --git a/arch/arm/boot/dts/nvidia/tegra20-paz00.dts b/arch/arm/boot/dts/nvidia/tegra20-paz00.dts
index 1408e1e00759..d1093ad569e6 100644
--- a/arch/arm/boot/dts/nvidia/tegra20-paz00.dts
+++ b/arch/arm/boot/dts/nvidia/tegra20-paz00.dts
@@ -706,6 +706,14 @@ vdd_pnl_reg: regulator-3v0 {
enable-active-high;
};
+ rfkill {
+ compatible = "rfkill-gpio";
+ label = "wifi_rfkill";
+ radio-type = "wlan";
+ reset-gpios = <&gpio TEGRA_GPIO(D, 1) GPIO_ACTIVE_HIGH>;
+ shutdown-gpios = <&gpio TEGRA_GPIO(K, 5) GPIO_ACTIVE_HIGH>;
+ };
+
sound {
compatible = "nvidia,tegra-audio-alc5632-paz00",
"nvidia,tegra-audio-alc5632";
diff --git a/arch/arm/mach-tegra/Makefile b/arch/arm/mach-tegra/Makefile
index a2bb55bc0081..9e3abb14fbc1 100644
--- a/arch/arm/mach-tegra/Makefile
+++ b/arch/arm/mach-tegra/Makefile
@@ -15,5 +15,3 @@ obj-$(CONFIG_HOTPLUG_CPU) += hotplug.o
obj-$(CONFIG_ARCH_TEGRA_114_SOC) += pm-tegra30.o
obj-$(CONFIG_ARCH_TEGRA_124_SOC) += pm-tegra30.o
-
-obj-$(CONFIG_ARCH_TEGRA_2x_SOC) += board-paz00.o
diff --git a/arch/arm/mach-tegra/board-paz00.c b/arch/arm/mach-tegra/board-paz00.c
deleted file mode 100644
index 3ec810b6f1a7..000000000000
--- a/arch/arm/mach-tegra/board-paz00.c
+++ /dev/null
@@ -1,56 +0,0 @@
-// SPDX-License-Identifier: GPL-2.0-only
-/*
- * arch/arm/mach-tegra/board-paz00.c
- *
- * Copyright (C) 2011 Marc Dietrich <marvin24@gmx.de>
- *
- * Based on board-harmony.c
- * Copyright (C) 2010 Google, Inc.
- */
-
-#include <linux/err.h>
-#include <linux/gpio/machine.h>
-#include <linux/gpio/property.h>
-#include <linux/platform_device.h>
-#include <linux/printk.h>
-#include <linux/property.h>
-
-#include "board.h"
-
-static const struct software_node tegra_gpiochip_node = {
- .name = "tegra-gpio",
-};
-
-static const struct property_entry wifi_rfkill_prop[] __initconst = {
- PROPERTY_ENTRY_STRING("name", "wifi_rfkill"),
- PROPERTY_ENTRY_STRING("type", "wlan"),
- PROPERTY_ENTRY_GPIO("reset-gpios",
- &tegra_gpiochip_node, 25, GPIO_ACTIVE_HIGH),
- PROPERTY_ENTRY_GPIO("shutdown-gpios",
- &tegra_gpiochip_node, 85, GPIO_ACTIVE_HIGH),
- { }
-};
-
-static const struct platform_device_info wifi_rfkill_info __initconst = {
- .name = "rfkill_gpio",
- .id = PLATFORM_DEVID_NONE,
- .properties = wifi_rfkill_prop,
-};
-
-void __init tegra_paz00_wifikill_init(void)
-{
- struct platform_device *pd;
- int err;
-
- err = software_node_register(&tegra_gpiochip_node);
- if (err) {
- pr_err("failed to register %s node: %d\n",
- tegra_gpiochip_node.name, err);
- return;
- }
-
- pd = platform_device_register_full(&wifi_rfkill_info);
- err = PTR_ERR_OR_ZERO(pd);
- if (err)
- pr_err("failed to register WiFi rfkill device: %d\n", err);
-}
diff --git a/arch/arm/mach-tegra/board.h b/arch/arm/mach-tegra/board.h
index 7b3ef0dc9be1..86c3ea0d6b30 100644
--- a/arch/arm/mach-tegra/board.h
+++ b/arch/arm/mach-tegra/board.h
@@ -19,6 +19,4 @@
void __init tegra_map_common_io(void);
void __init tegra_init_irq(void);
-void __init tegra_paz00_wifikill_init(void);
-
#endif
diff --git a/arch/arm/mach-tegra/tegra.c b/arch/arm/mach-tegra/tegra.c
index 9ef1dfa7b926..f324a7e491d8 100644
--- a/arch/arm/mach-tegra/tegra.c
+++ b/arch/arm/mach-tegra/tegra.c
@@ -83,10 +83,6 @@ static void __init tegra_dt_init(void)
static void __init tegra_dt_init_late(void)
{
- if (IS_ENABLED(CONFIG_ARCH_TEGRA_2x_SOC) &&
- of_machine_is_compatible("compal,paz00"))
- tegra_paz00_wifikill_init();
-
if (IS_ENABLED(CONFIG_ARCH_TEGRA_2x_SOC) &&
of_machine_is_compatible("nvidia,tegra20"))
platform_device_register_simple("tegra20-cpufreq", -1, NULL, 0);
--
2.53.0.1018.g2bb0e51243-goog
--
Dmitry
^ permalink raw reply related
* [PATCH v2 0/8] Bluetooth: Add MediaTek MT7927 (MT6639) support
From: Javier Tia @ 2026-03-25 23:30 UTC (permalink / raw)
To: Marcel Holtmann, Luiz Augusto von Dentz, Matthias Brugger,
AngeloGioacchino Del Regno
Cc: linux-bluetooth, linux-kernel, linux-arm-kernel, linux-mediatek,
Ryan Gilbert, Jose Tiburcio Ribeiro Netto, Llewellyn Curran,
Chapuis Dario, Evgeny Kapusta, Thibaut FRANCOIS, Ivan Lubnin
This series adds Bluetooth support for the MediaTek MT7927 (Filogic 380)
combo WiFi 7 + BT 5.4 module. The BT subsystem uses hardware variant
0x6639 and connects via USB.
The MT7927 is shipping in motherboards and PCIe add-in cards from ASUS,
Gigabyte, Lenovo, MSI, and TP-Link since mid-2024. Without these patches,
users see "Unsupported hardware variant (00006639)" or the BT subsystem
hangs during firmware download.
Jean-Francois Marliere independently identified the same three root
causes and posted an analysis to the list in February [1], though the
patch diff was not included in that message. This series provides the
complete, split patches addressing the same issues.
The series consists of nine patches:
[1/9] Bluetooth: btmtk: Add MT6639 (MT7927) Bluetooth support
[2/9] Bluetooth: btmtk: fix ISO interface setup for single alt setting
[3/9] Bluetooth: btusb: Add MT7927 ID for ASUS ROG Crosshair X870E Hero
[4/9] Bluetooth: btusb: Add MT7927 ID for Lenovo Legion Pro 7 16ARX9
[5/9] Bluetooth: btusb: Add MT7927 ID for Gigabyte Z790 AORUS MASTER X
[6/9] Bluetooth: btusb: Add MT7927 ID for MSI X870E Ace Max
[7/9] Bluetooth: btusb: Add MT7927 ID for TP-Link Archer TBE550E
[8/9] Bluetooth: btusb: Add MT7927 ID for ASUS X870E / ProArt X870E-Creator
Three driver changes are needed for MT6639:
1. CHIPID workaround: On some boards the BT USB MMIO register reads
0x0000 for dev_id, causing the driver to skip the 0x6639 init path.
Force dev_id to 0x6639 when it reads zero, matching the equivalent
WiFi-side workaround that forces chip=0x7927.
2. Firmware naming: MT6639 uses firmware version prefix "2_1" instead of
"1_1" used by MT7925 and other variants. The firmware path is
mediatek/mt6639/BT_RAM_CODE_MT6639_2_1_hdr.bin.
3. Section filtering: The firmware binary contains 9 sections, but only
sections with (dlmodecrctype & 0xff) == 0x01 are Bluetooth-related.
Sending WiFi/other sections causes an irreversible BT subsystem hang.
The filter is gated on dev_id == 0x6639 to avoid affecting other chips.
Additionally, patch 2 fixes the ISO interface setup for devices that
expose only a single alternate setting (alt 0) on the ISO endpoint.
Without this fix, btmtk_usb_claim_iso_intf() fails with EINVAL,
causing ~20 second initialization delays.
Changes in v2:
- Split USB device IDs into per-device commits as requested (Luiz)
- Added 0489:e110 (MSI X870E Ace Max, new hardware report)
- Added ISO interface fix for single alt setting (13d3:3588 devices)
- Added Tested-by trailers for all USB IDs except 0489:e110
- Added USB descriptor output to all per-device commits
- Removed BTMTK_FIRMWARE_LOADED skip logic; firmware persistence is
handled by the existing framework (Sean Wang)
The firmware blob (BT_RAM_CODE_MT6639_2_1_hdr.bin) is being submitted
separately to linux-firmware via GitLab MR. The firmware path and
filename have not been finalized yet; the driver currently requests
mediatek/mt6639/, but this may change based on the linux-firmware
review.
Tested hardware:
- ASUS ROG Crosshair X870E Hero (BT 0489:e13a)
- ASUS ROG STRIX X870-I (BT 0489:e13a)
- ASUS ROG STRIX X870E-E (BT 13d3:3588)
- ASUS ProArt X870E-Creator WiFi (BT 13d3:3588)
- Gigabyte Z790 AORUS MASTER X (BT 0489:e10f)
- Gigabyte Z790 AORUS ELITE X WiFi7 (BT 0489:e10f)
- MSI MEG X870E ACE MAX (BT 0489:e110)
- Lenovo Legion Pro 7 16ARX9 (BT 0489:e0fa)
- Lenovo Legion Pro 7 16AFR10H (BT 0489:e0fa)
- TP-Link Archer TBE550E PCIe (BT 0489:e116)
Tested on Arch Linux, CachyOS, Fedora (Bazzite), and Ubuntu
across kernels 6.13-6.19.
The companion WiFi support for MT7927 (mt76/mt7925e driver) has been
submitted separately to linux-wireless.
[1] https://lore.kernel.org/linux-bluetooth/496b0f8505eb6ffb19fdbee6f963c62aa6790fba.camel@marliere.fr/
Link: https://bugzilla.kernel.org/show_bug.cgi?id=221096
Link: https://github.com/openwrt/mt76/issues/927
Assisted-by: Claude (Anthropic)
Signed-off-by: Javier Tia <floss@jetm.me>
---
Javier Tia (8):
Bluetooth: btmtk: Add MT6639 (MT7927) Bluetooth support
Bluetooth: btmtk: fix ISO interface setup for single alt setting
Bluetooth: btusb: Add MT7927 ID for ASUS ROG Crosshair X870E Hero
Bluetooth: btusb: Add MT7927 ID for Lenovo Legion Pro 7 16ARX9
Bluetooth: btusb: Add MT7927 ID for Gigabyte Z790 AORUS MASTER X
Bluetooth: btusb: Add MT7927 ID for MSI X870E Ace Max
Bluetooth: btusb: Add MT7927 ID for TP-Link Archer TBE550E
Bluetooth: btusb: Add MT7927 ID for ASUS X870E / ProArt X870E-Creator
drivers/bluetooth/btmtk.c | 26 +++++++++++++++++++++++---
drivers/bluetooth/btmtk.h | 1 +
drivers/bluetooth/btusb.c | 12 ++++++++++++
3 files changed, 36 insertions(+), 3 deletions(-)
---
base-commit: 50003ce2085a7f7dacf2426065d1a69c84b5b963
change-id: 20260305-mt7927-bt-support-6589a50c961f
Best regards,
--
Javier Tia <floss@jetm.me>
^ permalink raw reply
* [PATCH v2 1/8] Bluetooth: btmtk: Add MT6639 (MT7927) Bluetooth support
From: Javier Tia @ 2026-03-25 23:30 UTC (permalink / raw)
To: Marcel Holtmann, Luiz Augusto von Dentz, Matthias Brugger,
AngeloGioacchino Del Regno
Cc: linux-bluetooth, linux-kernel, linux-arm-kernel, linux-mediatek,
Ryan Gilbert
In-Reply-To: <20260325-mt7927-bt-support-v2-0-b892a3252880@jetm.me>
The MediaTek MT7927 (Filogic 380) combo WiFi 7 + BT 5.4 module uses
hardware variant 0x6639 for its Bluetooth subsystem. Without this patch,
the chip fails with "Unsupported hardware variant (00006639)" or hangs
during firmware download.
Three changes are needed to support MT6639:
1. CHIPID workaround: On some boards the BT USB MMIO register reads
0x0000 for dev_id, causing the driver to skip the 0x6639 init path.
Force dev_id to 0x6639 when it reads zero, matching the equivalent
WiFi-side workaround that forces chip=0x7927.
2. Firmware naming: MT6639 uses firmware version prefix "2_1" instead of
"1_1" used by MT7925 and other variants. The firmware path is
mediatek/mt6639/BT_RAM_CODE_MT6639_2_1_hdr.bin.
3. Section filtering: The MT6639 firmware binary contains 9 sections, but
only sections with (dlmodecrctype & 0xff) == 0x01 are Bluetooth-related.
Sending the remaining WiFi/other sections causes an irreversible BT
subsystem hang requiring a full power cycle. This matches the Windows
driver behavior observed via USB captures.
Also add 0x6639 to the reset register (CONNV3) and firmware setup switch
cases alongside the existing 0x7925 handling.
Link: https://bugzilla.kernel.org/show_bug.cgi?id=221096
Link: https://github.com/openwrt/mt76/issues/927
Reported-by: Ryan Gilbert <xelnaga@gmail.com>
Signed-off-by: Javier Tia <floss@jetm.me>
---
drivers/bluetooth/btmtk.c | 23 +++++++++++++++++++++--
drivers/bluetooth/btmtk.h | 1 +
2 files changed, 22 insertions(+), 2 deletions(-)
diff --git a/drivers/bluetooth/btmtk.c b/drivers/bluetooth/btmtk.c
index 2507d587f28a..13c6e45deede 100644
--- a/drivers/bluetooth/btmtk.c
+++ b/drivers/bluetooth/btmtk.c
@@ -112,7 +112,11 @@ static void btmtk_coredump_notify(struct hci_dev *hdev, int state)
void btmtk_fw_get_filename(char *buf, size_t size, u32 dev_id, u32 fw_ver,
u32 fw_flavor)
{
- if (dev_id == 0x7925)
+ if (dev_id == 0x6639)
+ snprintf(buf, size,
+ "mediatek/mt%04x/BT_RAM_CODE_MT%04x_2_%x_hdr.bin",
+ dev_id & 0xffff, dev_id & 0xffff, (fw_ver & 0xff) + 1);
+ else if (dev_id == 0x7925)
snprintf(buf, size,
"mediatek/mt%04x/BT_RAM_CODE_MT%04x_1_%x_hdr.bin",
dev_id & 0xffff, dev_id & 0xffff, (fw_ver & 0xff) + 1);
@@ -130,6 +134,7 @@ EXPORT_SYMBOL_GPL(btmtk_fw_get_filename);
int btmtk_setup_firmware_79xx(struct hci_dev *hdev, const char *fwname,
wmt_cmd_sync_func_t wmt_cmd_sync)
{
+ struct btmtk_data *data = hci_get_priv(hdev);
struct btmtk_hci_wmt_params wmt_params;
struct btmtk_patch_header *hdr;
struct btmtk_global_desc *globaldesc = NULL;
@@ -166,6 +171,14 @@ int btmtk_setup_firmware_79xx(struct hci_dev *hdev, const char *fwname,
section_offset = le32_to_cpu(sectionmap->secoffset);
dl_size = le32_to_cpu(sectionmap->bin_info_spec.dlsize);
+ /* MT6639: only download sections where dlmode byte0 == 0x01,
+ * matching the Windows driver behavior which skips WiFi/other
+ * sections that would cause the chip to hang.
+ */
+ if (data->dev_id == 0x6639 && dl_size > 0 &&
+ (le32_to_cpu(sectionmap->bin_info_spec.dlmodecrctype) & 0xff) != 0x01)
+ continue;
+
if (dl_size > 0) {
retry = 20;
while (retry > 0) {
@@ -852,7 +865,7 @@ int btmtk_usb_subsys_reset(struct hci_dev *hdev, u32 dev_id)
if (err < 0)
return err;
msleep(100);
- } else if (dev_id == 0x7925) {
+ } else if (dev_id == 0x7925 || dev_id == 0x6639) {
err = btmtk_usb_uhw_reg_read(hdev, MTK_BT_RESET_REG_CONNV3, &val);
if (err < 0)
return err;
@@ -1322,6 +1335,11 @@ int btmtk_usb_setup(struct hci_dev *hdev)
fw_flavor = (fw_flavor & 0x00000080) >> 7;
}
+ if (!dev_id) {
+ bt_dev_info(hdev, "MT6639: raw CHIPID=0x0000, forcing chip=0x6639");
+ dev_id = 0x6639;
+ }
+
btmtk_data->dev_id = dev_id;
err = btmtk_register_coredump(hdev, btmtk_data->drv_name, fw_version);
@@ -1339,6 +1357,7 @@ int btmtk_usb_setup(struct hci_dev *hdev)
case 0x7925:
case 0x7961:
case 0x7902:
+ case 0x6639:
btmtk_fw_get_filename(fw_bin_name, sizeof(fw_bin_name), dev_id,
fw_version, fw_flavor);
diff --git a/drivers/bluetooth/btmtk.h b/drivers/bluetooth/btmtk.h
index adaf385626ee..6645bcadb523 100644
--- a/drivers/bluetooth/btmtk.h
+++ b/drivers/bluetooth/btmtk.h
@@ -8,6 +8,7 @@
#define FIRMWARE_MT7902 "mediatek/BT_RAM_CODE_MT7902_1_1_hdr.bin"
#define FIRMWARE_MT7961 "mediatek/BT_RAM_CODE_MT7961_1_2_hdr.bin"
#define FIRMWARE_MT7925 "mediatek/mt7925/BT_RAM_CODE_MT7925_1_1_hdr.bin"
+#define FIRMWARE_MT7927 "mediatek/mt6639/BT_RAM_CODE_MT6639_2_1_hdr.bin"
#define HCI_EV_WMT 0xe4
#define HCI_WMT_MAX_EVENT_SIZE 64
--
2.53.0
^ permalink raw reply related
* [PATCH v2 2/8] Bluetooth: btmtk: fix ISO interface setup for single alt setting
From: Javier Tia @ 2026-03-25 23:30 UTC (permalink / raw)
To: Marcel Holtmann, Luiz Augusto von Dentz, Matthias Brugger,
AngeloGioacchino Del Regno
Cc: linux-bluetooth, linux-kernel, linux-arm-kernel, linux-mediatek,
Ryan Gilbert
In-Reply-To: <20260325-mt7927-bt-support-v2-0-b892a3252880@jetm.me>
Some MT6639 Bluetooth USB interfaces (e.g. IMC Networks 13d3:3588 on
ASUS ROG STRIX X870E-E and ProArt X870E-Creator boards) expose only a
single alternate setting (alt 0) on the ISO interface. The driver
unconditionally requests alt setting 1, which fails with EINVAL on
these devices, causing a ~20 second initialization delay and no LE
audio support.
Check the number of available alternate settings before selecting one.
If only alt 0 exists, use it; otherwise request alt 1 as before.
Link: https://github.com/jetm/mediatek-mt7927-dkms/pull/39
Signed-off-by: Javier Tia <floss@jetm.me>
Reported-by: Ryan Gilbert <xelnaga@gmail.com>
Tested-by: Ryan Gilbert <xelnaga@gmail.com>
---
drivers/bluetooth/btmtk.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/bluetooth/btmtk.c b/drivers/bluetooth/btmtk.c
index 13c6e45deede..06ba0dcd6527 100644
--- a/drivers/bluetooth/btmtk.c
+++ b/drivers/bluetooth/btmtk.c
@@ -1013,7 +1013,8 @@ static int __set_mtk_intr_interface(struct hci_dev *hdev)
if (!btmtk_data->isopkt_intf)
return -ENODEV;
- err = usb_set_interface(btmtk_data->udev, MTK_ISO_IFNUM, 1);
+ err = usb_set_interface(btmtk_data->udev, MTK_ISO_IFNUM,
+ (intf->num_altsetting > 1) ? 1 : 0);
if (err < 0) {
bt_dev_err(hdev, "setting interface failed (%d)", -err);
return err;
--
2.53.0
^ permalink raw reply related
* [PATCH v2 3/8] Bluetooth: btusb: Add MT7927 ID for ASUS ROG Crosshair X870E Hero
From: Javier Tia @ 2026-03-25 23:30 UTC (permalink / raw)
To: Marcel Holtmann, Luiz Augusto von Dentz, Matthias Brugger,
AngeloGioacchino Del Regno
Cc: linux-bluetooth, linux-kernel, linux-arm-kernel, linux-mediatek,
Jose Tiburcio Ribeiro Netto
In-Reply-To: <20260325-mt7927-bt-support-v2-0-b892a3252880@jetm.me>
Add USB device ID 0489:e13a (Foxconn/Hon Hai) for the MediaTek MT7927
(Filogic 380) Bluetooth interface found on the ASUS ROG Crosshair X870E
Hero WiFi motherboard.
The information in /sys/kernel/debug/usb/devices about the Bluetooth
device is listed as the below.
T: Bus=01 Lev=01 Prnt=01 Port=05 Cnt=04 Dev#= 5 Spd=480 MxCh= 0
D: Ver= 2.10 Cls=ef(misc ) Sub=02 Prot=01 MxPS=64 #Cfgs= 1
P: Vendor=0489 ProdID=e13a Rev= 1.00
S: Manufacturer=MediaTek Inc.
S: Product=Wireless_Device
S: SerialNumber=000000000
C:* #Ifs= 3 Cfg#= 1 Atr=e0 MxPwr=100mA
A: FirstIf#= 0 IfCount= 3 Cls=e0(wlcon) Sub=01 Prot=01
I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=81(I) Atr=03(Int.) MxPS= 16 Ivl=125us
E: Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E: Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=83(I) Atr=01(Isoc) MxPS= 0 Ivl=1ms
E: Ad=03(O) Atr=01(Isoc) MxPS= 0 Ivl=1ms
I: If#= 1 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
...
I:* If#= 2 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=8a(I) Atr=03(Int.) MxPS= 512 Ivl=125us
E: Ad=0a(O) Atr=03(Int.) MxPS= 512 Ivl=125us
Link: https://bugzilla.kernel.org/show_bug.cgi?id=221096
Link: https://github.com/openwrt/mt76/issues/927
Signed-off-by: Javier Tia <floss@jetm.me>
Tested-by: Jose Tiburcio Ribeiro Netto <jnetto@mineiro.io>
---
drivers/bluetooth/btusb.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c
index a5e44887a5b5..58309af0f7a2 100644
--- a/drivers/bluetooth/btusb.c
+++ b/drivers/bluetooth/btusb.c
@@ -751,6 +751,8 @@ static const struct usb_device_id quirks_table[] = {
BTUSB_WIDEBAND_SPEECH },
{ USB_DEVICE(0x0489, 0xe139), .driver_info = BTUSB_MEDIATEK |
BTUSB_WIDEBAND_SPEECH },
+ { USB_DEVICE(0x0489, 0xe13a), .driver_info = BTUSB_MEDIATEK |
+ BTUSB_WIDEBAND_SPEECH },
{ USB_DEVICE(0x0489, 0xe14e), .driver_info = BTUSB_MEDIATEK |
BTUSB_WIDEBAND_SPEECH },
{ USB_DEVICE(0x0489, 0xe14f), .driver_info = BTUSB_MEDIATEK |
--
2.53.0
^ permalink raw reply related
* [PATCH v2 4/8] Bluetooth: btusb: Add MT7927 ID for Lenovo Legion Pro 7 16ARX9
From: Javier Tia @ 2026-03-25 23:30 UTC (permalink / raw)
To: Marcel Holtmann, Luiz Augusto von Dentz, Matthias Brugger,
AngeloGioacchino Del Regno
Cc: linux-bluetooth, linux-kernel, linux-arm-kernel, linux-mediatek,
Llewellyn Curran
In-Reply-To: <20260325-mt7927-bt-support-v2-0-b892a3252880@jetm.me>
Add USB device ID 0489:e0fa (Foxconn/Hon Hai) for the MediaTek MT7927
(Filogic 380) Bluetooth interface found on the Lenovo Legion Pro 7
16ARX9 laptop.
The information in /sys/kernel/debug/usb/devices about the Bluetooth
device is listed as the below.
T: Bus=01 Lev=01 Prnt=01 Port=05 Cnt=04 Dev#= 5 Spd=480 MxCh= 0
D: Ver= 2.10 Cls=ef(misc ) Sub=02 Prot=01 MxPS=64 #Cfgs= 1
P: Vendor=0489 ProdID=e0fa Rev= 1.00
S: Manufacturer=MediaTek Inc.
S: Product=Wireless_Device
S: SerialNumber=000000000
C:* #Ifs= 3 Cfg#= 1 Atr=e0 MxPwr=100mA
A: FirstIf#= 0 IfCount= 3 Cls=e0(wlcon) Sub=01 Prot=01
I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=81(I) Atr=03(Int.) MxPS= 16 Ivl=125us
E: Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E: Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=83(I) Atr=01(Isoc) MxPS= 0 Ivl=1ms
E: Ad=03(O) Atr=01(Isoc) MxPS= 0 Ivl=1ms
I: If#= 1 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
...
I:* If#= 2 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=8a(I) Atr=03(Int.) MxPS= 512 Ivl=125us
E: Ad=0a(O) Atr=03(Int.) MxPS= 512 Ivl=125us
Link: https://bugzilla.kernel.org/show_bug.cgi?id=221096
Link: https://github.com/openwrt/mt76/issues/927
Signed-off-by: Javier Tia <floss@jetm.me>
Tested-by: Llewellyn Curran <melinko2003@gmail.com>
---
drivers/bluetooth/btusb.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c
index 58309af0f7a2..2c9ca3d6016b 100644
--- a/drivers/bluetooth/btusb.c
+++ b/drivers/bluetooth/btusb.c
@@ -753,6 +753,8 @@ static const struct usb_device_id quirks_table[] = {
BTUSB_WIDEBAND_SPEECH },
{ USB_DEVICE(0x0489, 0xe13a), .driver_info = BTUSB_MEDIATEK |
BTUSB_WIDEBAND_SPEECH },
+ { USB_DEVICE(0x0489, 0xe0fa), .driver_info = BTUSB_MEDIATEK |
+ BTUSB_WIDEBAND_SPEECH },
{ USB_DEVICE(0x0489, 0xe14e), .driver_info = BTUSB_MEDIATEK |
BTUSB_WIDEBAND_SPEECH },
{ USB_DEVICE(0x0489, 0xe14f), .driver_info = BTUSB_MEDIATEK |
--
2.53.0
^ permalink raw reply related
* [PATCH v2 5/8] Bluetooth: btusb: Add MT7927 ID for Gigabyte Z790 AORUS MASTER X
From: Javier Tia @ 2026-03-25 23:30 UTC (permalink / raw)
To: Marcel Holtmann, Luiz Augusto von Dentz, Matthias Brugger,
AngeloGioacchino Del Regno
Cc: linux-bluetooth, linux-kernel, linux-arm-kernel, linux-mediatek,
Chapuis Dario, Evgeny Kapusta
In-Reply-To: <20260325-mt7927-bt-support-v2-0-b892a3252880@jetm.me>
Add USB device ID 0489:e10f (Foxconn/Hon Hai) for the MediaTek MT7927
(Filogic 380) Bluetooth interface found on the Gigabyte Z790 AORUS
MASTER X motherboard.
The information in /sys/kernel/debug/usb/devices about the Bluetooth
device is listed as the below.
T: Bus=01 Lev=01 Prnt=01 Port=05 Cnt=04 Dev#= 5 Spd=480 MxCh= 0
D: Ver= 2.10 Cls=ef(misc ) Sub=02 Prot=01 MxPS=64 #Cfgs= 1
P: Vendor=0489 ProdID=e10f Rev= 1.00
S: Manufacturer=MediaTek Inc.
S: Product=Wireless_Device
S: SerialNumber=000000000
C:* #Ifs= 3 Cfg#= 1 Atr=e0 MxPwr=100mA
A: FirstIf#= 0 IfCount= 3 Cls=e0(wlcon) Sub=01 Prot=01
I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=81(I) Atr=03(Int.) MxPS= 16 Ivl=125us
E: Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E: Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=83(I) Atr=01(Isoc) MxPS= 0 Ivl=1ms
E: Ad=03(O) Atr=01(Isoc) MxPS= 0 Ivl=1ms
I: If#= 1 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
...
I:* If#= 2 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=8a(I) Atr=03(Int.) MxPS= 512 Ivl=125us
E: Ad=0a(O) Atr=03(Int.) MxPS= 512 Ivl=125us
Link: https://bugzilla.kernel.org/show_bug.cgi?id=221096
Link: https://github.com/openwrt/mt76/issues/927
Signed-off-by: Javier Tia <floss@jetm.me>
Tested-by: Chapuis Dario <chapuisdario4@gmail.com>
Tested-by: Evgeny Kapusta <3193631@gmail.com>
---
drivers/bluetooth/btusb.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c
index 2c9ca3d6016b..d60798331bb3 100644
--- a/drivers/bluetooth/btusb.c
+++ b/drivers/bluetooth/btusb.c
@@ -755,6 +755,8 @@ static const struct usb_device_id quirks_table[] = {
BTUSB_WIDEBAND_SPEECH },
{ USB_DEVICE(0x0489, 0xe0fa), .driver_info = BTUSB_MEDIATEK |
BTUSB_WIDEBAND_SPEECH },
+ { USB_DEVICE(0x0489, 0xe10f), .driver_info = BTUSB_MEDIATEK |
+ BTUSB_WIDEBAND_SPEECH },
{ USB_DEVICE(0x0489, 0xe14e), .driver_info = BTUSB_MEDIATEK |
BTUSB_WIDEBAND_SPEECH },
{ USB_DEVICE(0x0489, 0xe14f), .driver_info = BTUSB_MEDIATEK |
--
2.53.0
^ permalink raw reply related
* [PATCH v2 6/8] Bluetooth: btusb: Add MT7927 ID for MSI X870E Ace Max
From: Javier Tia @ 2026-03-25 23:30 UTC (permalink / raw)
To: Marcel Holtmann, Luiz Augusto von Dentz, Matthias Brugger,
AngeloGioacchino Del Regno
Cc: linux-bluetooth, linux-kernel, linux-arm-kernel, linux-mediatek
In-Reply-To: <20260325-mt7927-bt-support-v2-0-b892a3252880@jetm.me>
Add USB device ID 0489:e110 (Foxconn/Hon Hai) for the MediaTek MT7927
(Filogic 380) Bluetooth interface found on the MSI X870E Ace Max
motherboard.
The information in /sys/kernel/debug/usb/devices about the Bluetooth
device is listed as the below.
T: Bus=01 Lev=01 Prnt=01 Port=05 Cnt=04 Dev#= 5 Spd=480 MxCh= 0
D: Ver= 2.10 Cls=ef(misc ) Sub=02 Prot=01 MxPS=64 #Cfgs= 1
P: Vendor=0489 ProdID=e110 Rev= 1.00
S: Manufacturer=MediaTek Inc.
S: Product=Wireless_Device
S: SerialNumber=000000000
C:* #Ifs= 3 Cfg#= 1 Atr=e0 MxPwr=100mA
A: FirstIf#= 0 IfCount= 3 Cls=e0(wlcon) Sub=01 Prot=01
I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=81(I) Atr=03(Int.) MxPS= 16 Ivl=125us
E: Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E: Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=83(I) Atr=01(Isoc) MxPS= 0 Ivl=1ms
E: Ad=03(O) Atr=01(Isoc) MxPS= 0 Ivl=1ms
I: If#= 1 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
...
I:* If#= 2 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=8a(I) Atr=03(Int.) MxPS= 512 Ivl=125us
E: Ad=0a(O) Atr=03(Int.) MxPS= 512 Ivl=125us
Link: https://bugzilla.kernel.org/show_bug.cgi?id=221096
Link: https://github.com/openwrt/mt76/issues/927
Signed-off-by: Javier Tia <floss@jetm.me>
---
drivers/bluetooth/btusb.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c
index d60798331bb3..96882e9b831c 100644
--- a/drivers/bluetooth/btusb.c
+++ b/drivers/bluetooth/btusb.c
@@ -757,6 +757,8 @@ static const struct usb_device_id quirks_table[] = {
BTUSB_WIDEBAND_SPEECH },
{ USB_DEVICE(0x0489, 0xe10f), .driver_info = BTUSB_MEDIATEK |
BTUSB_WIDEBAND_SPEECH },
+ { USB_DEVICE(0x0489, 0xe110), .driver_info = BTUSB_MEDIATEK |
+ BTUSB_WIDEBAND_SPEECH },
{ USB_DEVICE(0x0489, 0xe14e), .driver_info = BTUSB_MEDIATEK |
BTUSB_WIDEBAND_SPEECH },
{ USB_DEVICE(0x0489, 0xe14f), .driver_info = BTUSB_MEDIATEK |
--
2.53.0
^ permalink raw reply related
* [PATCH v2 7/8] Bluetooth: btusb: Add MT7927 ID for TP-Link Archer TBE550E
From: Javier Tia @ 2026-03-25 23:30 UTC (permalink / raw)
To: Marcel Holtmann, Luiz Augusto von Dentz, Matthias Brugger,
AngeloGioacchino Del Regno
Cc: linux-bluetooth, linux-kernel, linux-arm-kernel, linux-mediatek,
Thibaut FRANCOIS
In-Reply-To: <20260325-mt7927-bt-support-v2-0-b892a3252880@jetm.me>
Add USB device ID 0489:e116 (Foxconn/Hon Hai) for the MediaTek MT7927
(Filogic 380) Bluetooth interface found on the TP-Link Archer TBE550E
PCIe adapter.
The information in /sys/kernel/debug/usb/devices about the Bluetooth
device is listed as the below.
T: Bus=01 Lev=01 Prnt=01 Port=05 Cnt=04 Dev#= 5 Spd=480 MxCh= 0
D: Ver= 2.10 Cls=ef(misc ) Sub=02 Prot=01 MxPS=64 #Cfgs= 1
P: Vendor=0489 ProdID=e116 Rev= 1.00
S: Manufacturer=MediaTek Inc.
S: Product=Wireless_Device
S: SerialNumber=000000000
C:* #Ifs= 3 Cfg#= 1 Atr=e0 MxPwr=100mA
A: FirstIf#= 0 IfCount= 3 Cls=e0(wlcon) Sub=01 Prot=01
I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=81(I) Atr=03(Int.) MxPS= 16 Ivl=125us
E: Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E: Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=83(I) Atr=01(Isoc) MxPS= 0 Ivl=1ms
E: Ad=03(O) Atr=01(Isoc) MxPS= 0 Ivl=1ms
I: If#= 1 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
...
I:* If#= 2 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=8a(I) Atr=03(Int.) MxPS= 512 Ivl=125us
E: Ad=0a(O) Atr=03(Int.) MxPS= 512 Ivl=125us
Link: https://bugzilla.kernel.org/show_bug.cgi?id=221096
Link: https://github.com/openwrt/mt76/issues/927
Signed-off-by: Javier Tia <floss@jetm.me>
Tested-by: Thibaut FRANCOIS <tibo@humeurlibre.fr>
---
drivers/bluetooth/btusb.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c
index 96882e9b831c..55a000540439 100644
--- a/drivers/bluetooth/btusb.c
+++ b/drivers/bluetooth/btusb.c
@@ -759,6 +759,8 @@ static const struct usb_device_id quirks_table[] = {
BTUSB_WIDEBAND_SPEECH },
{ USB_DEVICE(0x0489, 0xe110), .driver_info = BTUSB_MEDIATEK |
BTUSB_WIDEBAND_SPEECH },
+ { USB_DEVICE(0x0489, 0xe116), .driver_info = BTUSB_MEDIATEK |
+ BTUSB_WIDEBAND_SPEECH },
{ USB_DEVICE(0x0489, 0xe14e), .driver_info = BTUSB_MEDIATEK |
BTUSB_WIDEBAND_SPEECH },
{ USB_DEVICE(0x0489, 0xe14f), .driver_info = BTUSB_MEDIATEK |
--
2.53.0
^ permalink raw reply related
* [PATCH v2 8/8] Bluetooth: btusb: Add MT7927 ID for ASUS X870E / ProArt X870E-Creator
From: Javier Tia @ 2026-03-25 23:30 UTC (permalink / raw)
To: Marcel Holtmann, Luiz Augusto von Dentz, Matthias Brugger,
AngeloGioacchino Del Regno
Cc: linux-bluetooth, linux-kernel, linux-arm-kernel, linux-mediatek,
Jose Tiburcio Ribeiro Netto, Ivan Lubnin
In-Reply-To: <20260325-mt7927-bt-support-v2-0-b892a3252880@jetm.me>
Add USB device ID 13d3:3588 (IMC Networks/Azurewave) for the MediaTek
MT7927 (Filogic 380) Bluetooth interface found on the ASUS ROG STRIX
X870E-E GAMING WIFI and ASUS ProArt X870E-Creator WiFi motherboards.
Note: boards with this USB ID report only one ISO alternate setting
(alt 0), causing a non-fatal "setting interface failed (22)" during
setup. Bluetooth still functions but initialization takes ~19 seconds
instead of ~2.6 seconds.
The information in /sys/kernel/debug/usb/devices about the Bluetooth
device is listed as the below.
T: Bus=01 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 5 Spd=480 MxCh= 0
D: Ver= 2.10 Cls=ef(misc ) Sub=02 Prot=01 MxPS=64 #Cfgs= 1
P: Vendor=13d3 ProdID=3588 Rev= 1.00
S: Manufacturer=MediaTek Inc.
S: Product=Wireless_Device
S: SerialNumber=000000000
C:* #Ifs= 3 Cfg#= 1 Atr=e0 MxPwr=100mA
A: FirstIf#= 0 IfCount= 3 Cls=e0(wlcon) Sub=01 Prot=01
I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=81(I) Atr=03(Int.) MxPS= 16 Ivl=125us
E: Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E: Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=83(I) Atr=01(Isoc) MxPS= 0 Ivl=1ms
E: Ad=03(O) Atr=01(Isoc) MxPS= 0 Ivl=1ms
I:* If#= 2 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=8a(I) Atr=03(Int.) MxPS= 512 Ivl=125us
E: Ad=0a(O) Atr=03(Int.) MxPS= 512 Ivl=125us
Link: https://bugzilla.kernel.org/show_bug.cgi?id=221096
Link: https://github.com/openwrt/mt76/issues/927
Signed-off-by: Javier Tia <floss@jetm.me>
Tested-by: Jose Tiburcio Ribeiro Netto <jnetto@mineiro.io>
Tested-by: Ivan Lubnin <lubnin.ivan@gmail.com>
---
drivers/bluetooth/btusb.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c
index 55a000540439..45ef0d008bce 100644
--- a/drivers/bluetooth/btusb.c
+++ b/drivers/bluetooth/btusb.c
@@ -761,6 +761,8 @@ static const struct usb_device_id quirks_table[] = {
BTUSB_WIDEBAND_SPEECH },
{ USB_DEVICE(0x0489, 0xe116), .driver_info = BTUSB_MEDIATEK |
BTUSB_WIDEBAND_SPEECH },
+ { USB_DEVICE(0x13d3, 0x3588), .driver_info = BTUSB_MEDIATEK |
+ BTUSB_WIDEBAND_SPEECH },
{ USB_DEVICE(0x0489, 0xe14e), .driver_info = BTUSB_MEDIATEK |
BTUSB_WIDEBAND_SPEECH },
{ USB_DEVICE(0x0489, 0xe14f), .driver_info = BTUSB_MEDIATEK |
--
2.53.0
^ permalink raw reply related
* Re: [PATCH RESEND v2] arm64: dts: rockchip: configure hdmirx in Rock 5 ITX
From: Heiko Stuebner @ 2026-03-25 23:38 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Pedro Alves
Cc: Heiko Stuebner, devicetree, linux-arm-kernel, linux-rockchip,
linux-kernel
In-Reply-To: <20260323-radxa-r5-itx-hdmirx-v2-1-c52501909577@pta2002.com>
On Mon, 23 Mar 2026 09:25:33 +0000, Pedro Alves wrote:
> The Radxa Rock 5 ITX board exposes an HDMI input exactly the same way as
> the Rock 5B, but this was not reflected in its DTS.
>
> Change the rk3588-rock-5-itx to configure and enable the hdmi_receiver
> and hdmi_receiver_cma nodes.
>
> The hot-plug detection (HPD) pin keeps the hdmirx_det name rather than
> the hdmirx_hpd name used in other boards since that is what matches the
> official schematics (HDMIIRX_DET_L).
>
> [...]
Applied, thanks!
[1/1] arm64: dts: rockchip: configure hdmirx in Rock 5 ITX
commit: 6cb4ec63ba9a5831621cf951b7af55c67beeb97b
Best regards,
--
Heiko Stuebner <heiko@sntech.de>
^ permalink raw reply
* Re: [PATCH RESEND v2] arm64: dts: rockchip: configure hdmirx in Rock 5 ITX
From: Heiko Stuebner @ 2026-03-25 23:41 UTC (permalink / raw)
To: Pedro Alves
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, devicetree,
linux-arm-kernel, linux-rockchip, linux-kernel
In-Reply-To: <1331010f-1446-4892-9d81-2f18b60f6977@pta2002.com>
Hi Pedro,
Am Mittwoch, 25. März 2026, 15:24:45 Mitteleuropäische Normalzeit schrieb Pedro Alves:
> Hi,
>
> On 24/03/2026 14:18, Heiko Stuebner wrote:
> > Am Montag, 23. März 2026, 10:25:33 Mitteleuropäische Normalzeit schrieb Pedro Alves:
> >> +&hdmi_receiver {
> >> + pinctrl-0 = <&hdmim1_rx_cec &hdmim1_rx_hpdin &hdmim1_rx_scl &hdmim1_rx_sda &hdmirx_det>;
> >> + pinctrl-names = "default";
> >> + hpd-gpios = <&gpio1 RK_PC6 GPIO_ACTIVE_LOW>;
> >
> > as said before, please also add a pinctrl setting for this pin.
> >
> > gpio1_c6 is not part of the main hdmirx set of pins, hence needs an
> > additional pinctrl entry to configure it as gpio and possibly set any
> > additional pull settings.
> >
> > And yes the pinctrl-driver does "implcitly" set the gpio-mode when
> > a gpio is requested, but our more modern approach is to always have
> > a real pinctrl entry even for gpios.
>
> I am probably getting confused by what you are asking here, but I don't
> understand what exactly I should add. There was already a pinctrl for
> hdmirx_det (which is what the gpio1_c6 pin is) present in the file,
> hence why I did not add it in this patch:
>
> &pinctrl {
> /* ... */
> hdmirx {
> hdmirx_det: hdmirx-det {
> rockchip,pins = <1 RK_PC6 RK_FUNC_GPIO &pcfg_pull_none>;
> };
> };
> /* ... */
> };
>
> Looking at the other boards, they do the same thing, but they call it
> hdmirx-5v-detection instead, but as discussed in v1 of this patch I
> ended up keeping the det naming to match the schematics.
>
> Sorry if I am missing something, I don't have much experience with this,
> so I would really appreciate some extra information.
You didn't miss anything - I did :-) .
Not finding an addition to the pinctrl definitions in the patch
I misread the &hdmirx-det reference as the one defined in the core
rk3588-base-pinctrl, not realizing that the rock5-itx one was
already existing in the rock5-itx dts already.
Sorry about confusing you
Heiko
^ permalink raw reply
* Re: [PATCH v2 05/13] wifi: mt76: mt7925: advertise EHT 320MHz capabilities for 6GHz band
From: Javier Tia @ 2026-03-26 0:18 UTC (permalink / raw)
To: Sean Wang
Cc: Felix Fietkau, Lorenzo Bianconi, Ryder Lee, Shayne Chen,
Sean Wang, Matthias Brugger, AngeloGioacchino Del Regno, Deren Wu,
Ming Yen Hsieh, linux-wireless, linux-kernel, linux-arm-kernel,
linux-mediatek, Marcin FM, Cristian-Florin Radoi,
George Salukvadze, Evgeny Kapusta, Samu Toljamo, Ariel Rosenfeld,
Chapuis Dario, Thibaut François, 张旭涵
Hi Sean,
On Mon, Mar 24, 2026 Sean Wang wrote:
> I don't think this is correct for mt7925, and it will cause a
> regression there. Was this tested on actual mt7925 hardware?
You are right. I do not have mt7925 hardware to verify against.
In v3, is_320mhz_supported() now checks is_mt7927() only, so
mt7925 behavior is unchanged.
> I don't think this should be copied from mt7996 as-is for mt7927. I'd
> suggest dropping the eht_cap_elem->phy_cap_info[7] change and keeping
> it conservative for now.
Agreed. The phy_cap_info[7] additions (NON_OFDMA_UL_MU_MIMO_320MHZ
and MU_BEAMFORMER_320MHZ) are dropped in v3. Only the MCS/NSS maps
and per-BW beamformee SS/sounding dimensions for 320MHz remain.
Both changes are in v3, sent today.
Best,
Javier
^ permalink raw reply
* Re: [PATCH v13 00/48] arm64: Support for Arm CCA in KVM
From: Gavin Shan @ 2026-03-26 0:48 UTC (permalink / raw)
To: Suzuki K Poulose, Steven Price, Mathieu Poirier
Cc: kvm, kvmarm, Catalin Marinas, Marc Zyngier, Will Deacon,
James Morse, Oliver Upton, Zenghui Yu, linux-arm-kernel,
linux-kernel, Joey Gouly, Alexandru Elisei, Christoffer Dall,
Fuad Tabba, linux-coco, Ganapatrao Kulkarni, Shanker Donthineni,
Alper Gun, Aneesh Kumar K . V, Emi Kisanuki, Vishal Annapurve
In-Reply-To: <9247d9ea-64b4-4e8e-81f8-3c8e00750acf@arm.com>
Hi Suzuki,
On 3/25/26 8:16 PM, Suzuki K Poulose wrote:
> On 25/03/2026 06:37, Gavin Shan wrote:
>> On 3/21/26 2:45 AM, Steven Price wrote:
[...]
>>
>> In upstream TF-A repository [1], I don't see the config option 'RMM_V1_COMPAT'.
>> would it be something else?
>>
>> [1] git@github.com:ARM-software/arm-trusted-firmware.git (branch: master)
>>
>
> suzuki@ewhatever:trusted-firmware-a$ git grep RMM_V1_COMPAT
> Makefile: RMM_V1_COMPAT \
> Makefile: RMM_V1_COMPAT \
> docs/getting_started/build-options.rst:- ``RMM_V1_COMPAT``: Boolean flag to enable support for RMM v1.x compatibility
> include/services/rmmd_svc.h:#if RMM_V1_COMPAT
> include/services/rmmd_svc.h:#endif /* RMM_V1_COMPAT */
> make_helpers/defaults.mk:RMM_V1_COMPAT := 1
> services/std_svc/rmmd/rmmd_main.c:#if RMM_V1_COMPAT
> services/std_svc/rmmd/rmmd_main.c:#if RMM_V1_COMPAT
> services/std_svc/rmmd/rmmd_main.c:#if !RMM_V1_COMPAT
> services/std_svc/rmmd/rmmd_main.c:#if RMM_V1_COMPAT
> services/std_svc/rmmd/rmmd_main.c:#if RMM_V1_COMPAT
> services/std_svc/rmmd/rmmd_main.c:#if RMM_V1_COMPAT
> services/std_svc/rmmd/rmmd_rmm_lfa.c:#if RMM_V1_COMPAT
> services/std_svc/rmmd/rmmd_rmm_lfa.c:#if RMM_V1_COMPAT
> services/std_svc/rmmd/rmmd_rmm_lfa.c:#if RMM_V1_COMPAT
> services/std_svc/rmmd/rmmd_rmm_lfa.c:#if RMM_V1_COMPAT
> suzuki@ewhatever:trusted-firmware-a$ git log --oneline -1
> 8dae0862c (HEAD, origin/master, origin/integration, origin/HEAD) Merge changes from topic "qti_lemans_evk" into integration
> suzuki@ewhatever:trusted-firmware-a$ git remote get-url origin
> https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git
>
Thanks for the details. It turned out that I used the wrong TF-A repository. In
the proposed repository, I'm able to see the option 'RMM_V1_COMPAT' and the EL3-RMM
interface compatible issue disappears. However, there are more issues popped up.
I build everything manually where the host is emulated by QEMU instead of shrinkwrap
and FVP model. It's used to work well before. Maybe it's time to switch to shinkwrap
and FVP model since device assignment (DA) isn't supported by an emulated host
by QEMU and shrinkwrap and FVP model seems the only option. I need to learn how
to do that later.
There are two issues I can see with the following combinations. Details are provided
like below.
QEMU: https://git.qemu.org/git/qemu.git (branch: stable-9.2)
TF-RMM: https://git.trustedfirmware.org/TF-RMM/tf-rmm.git (branch: topics/rmm-v2.0-poc)
EDK2: git@github.com:tianocore/edk2.git (tag: edk2-stable202411)
TF-A: https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git (branch: master)
HOST: https://git.gitlab.arm.com/linux-arm/linux-cca.git (branch: cca-host/v13)
BUILDROOT: https://github.com/buildroot/buildroot (branch: master)
KVMTOOL: https://gitlab.arm.com/linux-arm/kvmtool-cca (branch: cca/v11)
GUEST: https://github.com/torvalds/linux.git (branch: master)
(1) The emulated host is started by the following command lines.
sudo /home/gshan/sandbox/cca/host/qemu/build/qemu-system-aarch64 \
-M virt,virtualization=on,secure=on,gic-version=3,acpi=off \
-cpu max,x-rme=on -m 8G -smp 8 \
-serial mon:stdio -monitor none -nographic -nodefaults \
-bios /home/gshan/sandbox/cca/host/tf-a/flash.bin \
-kernel /home/gshan/sandbox/cca/host/linux/arch/arm64/boot/Image \
-initrd /home/gshan/sandbox/cca/host/buildroot/output/images/rootfs.cpio.xz \
-device pcie-root-port,bus=pcie.0,chassis=1,id=pcie.1 \
-device pcie-root-port,bus=pcie.0,chassis=2,id=pcie.2 \
-device pcie-root-port,bus=pcie.0,chassis=3,id=pcie.3 \
-device pcie-root-port,bus=pcie.0,chassis=4,id=pcie.4 \
-device virtio-9p-device,fsdev=shr0,mount_tag=shr0 \
-fsdev local,security_model=none,path=/home/gshan/sandbox/cca/guest,id=shr0 \
-netdev tap,id=tap1,script=/etc/qemu-ifup-gshan,downscript=/etc/qemu-ifdown-gshan \
-device virtio-net-pci,bus=pcie.2,netdev=tap1,mac=b8:3f:d2:1d:3e:f1
(2) Issue-1: TF-RMM complains about the root complex list is invalid. This error is
raised in TF-RMM::setup_root_complex_list() where the error code is still set to
0 (SUCCESS) in this failing case. The TF-RMM initialization is terminated early,
but TF-A still thinks the initialization has been completely done.
INFO: BL31: Initializing RMM
INFO: RMM init start.
RMM EL3 compat memory reservation enabled.
Dynamic VA pool base address: 0xc0000000
Reserved 20 pages. Remaining: 3615 pages
Reserve mem: 20 pages at PA: 0x401f2000 (alignment 0x1000)
Static Low VA initialized. xlat tables allocated: 20 used: 7
Reserved 514 pages. Remaining: 3101 pages
Reserve mem: 514 pages at PA: 0x40206000 (alignment 0x1000)
Dynamic Low VA initialized. xlat tables allocated: 514 used: 514
Invalid: Root Complex list <<<<< ERROR
INFO: RMM init end.
(3) Issue-2: The host kernel gets stuck in rmi_check_version() where SMC_RMI_VERSION
is issued to TF-A, but it can't be forwarded to TF-RMM because its initialization
isn't completely done (issue-1).
[ 37.438253] Unpacking initramfs...
[ 37.563460] kvm [1]: nv: 570 coarse grained trap handlers
[ 37.581139] kvm [1]: nv: 664 fine grained trap handlers
<... system becomes stuck here ...>
So my workaround is to skip fetching root complex list from the EL3-RMM manifest data
in TF-RMM::setup_root_complex_list() since it's not provided for the qemu platform by
TF-A. With this workaround, the host can boot up into shell prompt and the guest can
be started by kvmtool.
host$ uname -r
7.0.0-rc1-gavin-gd62aa44b2590
host$ lkvm run --realm -c 2 -m 256 \
-k /mnt/linux/arch/arm64/boot/Image \
-i /mnt/buildroot/output/images/rootfs.cpio.xz
-p earlycon=uart,mmio,0x101000000
Info: # lkvm run -k /mnt/linux/arch/arm64/boot/Image -m 256 -c 2 --name guest-163
Info: Enabling Guest memfd for confidential guest
Warning: The maximum recommended amount of VCPUs is 1
[ 0.000000] Booting Linux on physical CPU 0x0000000000 [0x000f0510]
[ 0.000000] Linux version 7.0.0-rc2-gavin-g0031c06807cf (gshan@nvidia-grace-hopper-01.khw.eng.bos2.dc.redhat.com) (gcc (GCC) 14.3.1 20251022 (Red Hat 14.3.1-4), GNU ld version 2.41-64.el10) #2 SMP PREEMPT Wed Mar 25 20:28:05 EDT 2026
[ 0.000000] KASLR enabled
:
[ 267.578060] Freeing initrd memory: 4728K
[ 267.921865] Warning: unable to open an initial console.
[ 270.327960] Freeing unused kernel memory: 1792K
[ 270.669368] Run /init as init process
Thanks,
Gavin
^ permalink raw reply
* [PATCH] clocksource/drivers/timer-mediatek: initialize GPT6 as system counter
From: Roman Vivchar via B4 Relay @ 2026-03-26 1:00 UTC (permalink / raw)
To: Daniel Lezcano, Thomas Gleixner, Matthias Brugger,
AngeloGioacchino Del Regno
Cc: linux-kernel, linux-arm-kernel, linux-mediatek, Akari Tsuyukusa,
Roman Vivchar
From: Roman Vivchar <rva333@protonmail.com>
On certain MediaTek SoCs like mt6572 (likely before the CPUXGPT was
introduced), the generic arch timer is fed by the GPT6. Some bootloaders
don't initialize it properly, leading to dead arch timer.
Fix this by configuring GPT6 when the MediaTek timer is probed. This
makes arch timer work properly and removes IPI overhead from MediaTek
timer broadcast when arch timer is used.
If the timer was configured by the bootloader, this change is no-op.
Tested-by: Akari Tsuyukusa <akkun11.open@gmail.com> # MT6589
Signed-off-by: Roman Vivchar <rva333@protonmail.com>
---
On certain MediaTek SoCs like mt6572 (likely before the CPUXGPT was
introduced), the generic arch timer is fed by the GPT6. Some bootloaders
don't initialize it properly, leading to dead arch timer.
Fix this by configuring GPT6 when the MediaTek timer is probed. This
makes arch timer work properly and removes IPI overhead from MediaTek
timer broadcast when arch timer is used.
If the timer was configured by the bootloader, this change is no-op.
---
drivers/clocksource/timer-mediatek.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/drivers/clocksource/timer-mediatek.c b/drivers/clocksource/timer-mediatek.c
index 7bcb4a3f26fb..7de34cace572 100644
--- a/drivers/clocksource/timer-mediatek.c
+++ b/drivers/clocksource/timer-mediatek.c
@@ -22,6 +22,8 @@
#define TIMER_SYNC_TICKS (3)
+#define TIMER_SYSCNT (6)
+
/* gpt */
#define GPT_IRQ_EN_REG 0x00
#define GPT_IRQ_ENABLE(val) BIT((val) - 1)
@@ -335,6 +337,9 @@ static int __init mtk_gpt_init(struct device_node *node)
mtk_gpt_enable_irq(&to, TIMER_CLK_EVT);
+ /* Configure GPT6 to feed arch timer */
+ mtk_gpt_setup(&to, TIMER_SYSCNT, GPT_CTRL_OP_FREERUN);
+
return 0;
}
TIMER_OF_DECLARE(mtk_mt6577, "mediatek,mt6577-timer", mtk_gpt_init);
---
base-commit: 05f7e89ab9731565d8a62e3b5d1ec206485eeb0b
change-id: 20260325-archtimer-357b02f74058
Best regards,
--
Roman Vivchar <rva333@protonmail.com>
^ permalink raw reply related
* Re: [PATCH net-next v9 2/6] net: stmmac: qcom-ethqos: use generic device properties
From: Andrew Lunn @ 2026-03-26 1:08 UTC (permalink / raw)
To: Bartosz Golaszewski
Cc: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Maxime Coquelin, Alexandre Torgue,
Vinod Koul, Giuseppe Cavallaro, Chen-Yu Tsai, Jernej Skrabec,
Neil Armstrong, Kevin Hilman, Jerome Brunet, Shawn Guo,
Fabio Estevam, Jan Petrous, s32, Mohd Ayaan Anwar, Romain Gantois,
Geert Uytterhoeven, Magnus Damm, Maxime Ripard,
Christophe Roullier, Bartosz Golaszewski, Radu Rendec,
linux-arm-msm, devicetree, linux-kernel, netdev, linux-stm32,
linux-arm-kernel, Drew Fustini, linux-sunxi, linux-amlogic,
linux-mips, imx, linux-renesas-soc, linux-rockchip, sophgo,
linux-riscv, Bartosz Golaszewski
In-Reply-To: <20260316-qcom-sa8255p-emac-v9-2-c58934e76ff2@oss.qualcomm.com>
On Mon, Mar 16, 2026 at 01:05:07PM +0100, Bartosz Golaszewski wrote:
> From: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
>
> In order to drop the dependency on CONFIG_OF, convert all device property
> getters from OF-specific to generic device properties and stop pulling
> in any linux/of.h symbols.
>
> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
> ---
> drivers/net/ethernet/stmicro/stmmac/Kconfig | 2 +-
> drivers/net/ethernet/stmicro/stmmac/dwmac-qcom-ethqos.c | 9 ++++-----
> 2 files changed, 5 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/net/ethernet/stmicro/stmmac/Kconfig b/drivers/net/ethernet/stmicro/stmmac/Kconfig
> index 07088d03dbab5bd1abf66e9460613b839c1d565e..e2af4fdd654340d618477ed87d3889dbb9aab456 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/Kconfig
> +++ b/drivers/net/ethernet/stmicro/stmmac/Kconfig
> @@ -135,7 +135,7 @@ config DWMAC_MESON
> config DWMAC_QCOM_ETHQOS
> tristate "Qualcomm ETHQOS support"
> default ARCH_QCOM
> - depends on OF && (ARCH_QCOM || COMPILE_TEST)
> + depends on ARCH_QCOM || COMPILE_TEST
> help
> Support for the Qualcomm ETHQOS core.
Are you sure you want to do that?
static int qcom_ethqos_probe(struct platform_device *pdev)
{
struct device_node *np = pdev->dev.of_node;
const struct ethqos_emac_driver_data *data;
struct plat_stmmacenet_data *plat_dat;
struct stmmac_resources stmmac_res;
struct device *dev = &pdev->dev;
struct qcom_ethqos *ethqos;
int ret, i;
ret = stmmac_get_platform_resources(pdev, &stmmac_res);
if (ret)
return dev_err_probe(dev, ret,
"Failed to get platform resources\n");
plat_dat = devm_stmmac_probe_config_dt(pdev, stmmac_res.mac);
if (IS_ERR(plat_dat)) {
return dev_err_probe(dev, PTR_ERR(plat_dat),
"dt configuration failed\n");
}
https://elixir.bootlin.com/linux/v6.19.9/source/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c#L684
#else
struct plat_stmmacenet_data *
devm_stmmac_probe_config_dt(struct platform_device *pdev, u8 *mac)
{
return ERR_PTR(-EINVAL);
}
#endif /* CONFIG_OF */
It seems like this is just going to result in the probe failing with
-EINVAL.
Andrew
^ permalink raw reply
* RE: [PATCH v1] PCI: imx6: Fix reference clock source selection
From: Hongxing Zhu @ 2026-03-26 1:20 UTC (permalink / raw)
To: Franz Schnyder, Lucas Stach, Lorenzo Pieralisi,
Krzysztof Wilczy��ski, Manivannan Sadhasivam,
Rob Herring, Bjorn Helgaas, Frank Li, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam
Cc: Franz Schnyder, linux-pci@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, imx@lists.linux.dev,
linux-kernel@vger.kernel.org, Francesco Dolcini,
stable@vger.kernel.org
In-Reply-To: <20260325093118.684142-1-fra.schnyder@gmail.com>
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="gb2312", Size: 2564 bytes --]
> -----Original Message-----
> From: Franz Schnyder <fra.schnyder@gmail.com>
> Sent: 2026Äê3ÔÂ25ÈÕ 17:31
> To: Hongxing Zhu <hongxing.zhu@nxp.com>; Lucas Stach
> <l.stach@pengutronix.de>; Lorenzo Pieralisi <lpieralisi@kernel.org>;
> Krzysztof Wilczy¨½ski <kwilczynski@kernel.org>; Manivannan Sadhasivam
> <mani@kernel.org>; Rob Herring <robh@kernel.org>; Bjorn Helgaas
> <bhelgaas@google.com>; Frank Li <frank.li@nxp.com>; Sascha Hauer
> <s.hauer@pengutronix.de>; Pengutronix Kernel Team
> <kernel@pengutronix.de>; Fabio Estevam <festevam@gmail.com>
> Cc: Franz Schnyder <franz.schnyder@toradex.com>;
> linux-pci@vger.kernel.org; linux-arm-kernel@lists.infradead.org;
> imx@lists.linux.dev; linux-kernel@vger.kernel.org; Francesco Dolcini
> <francesco.dolcini@toradex.com>; stable@vger.kernel.org
> Subject: [PATCH v1] PCI: imx6: Fix reference clock source selection
>
> From: Franz Schnyder <franz.schnyder@toradex.com>
>
> In the PCIe PHY init for the iMX95, the reference clock source selection uses
> a conditional instead of always passing the mask. This currently breaks
> functionality if the internal refclk is used.
>
> Pass always IMX95_PCIE_REF_USE_PAD as the mask and clear the bit if
> external refclk is not used.
>
> Fixes: d8574ce57d76 ("PCI: imx6: Add external reference clock input mode
> support")
> Cc: stable@vger.kernel.org
> Signed-off-by: Franz Schnyder <franz.schnyder@toradex.com>
Apologies, I made an error when organizing the code.
This bug was not caught during local testing because the external OSC clock
input is permanently enabled on the EVK board.
Acked-by: Richard Zhu <hongxing.zhu@nxp.com>
Best Regards
Richard Zhu
> ---
> drivers/pci/controller/dwc/pci-imx6.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/pci/controller/dwc/pci-imx6.c
> b/drivers/pci/controller/dwc/pci-imx6.c
> index 81a7093494c8..e0580d6efa57 100644
> --- a/drivers/pci/controller/dwc/pci-imx6.c
> +++ b/drivers/pci/controller/dwc/pci-imx6.c
> @@ -268,8 +268,8 @@ static int imx95_pcie_init_phy(struct imx_pcie
> *imx_pcie)
> IMX95_PCIE_PHY_CR_PARA_SEL);
>
> regmap_update_bits(imx_pcie->iomuxc_gpr,
> IMX95_PCIE_PHY_GEN_CTRL,
> - ext ? IMX95_PCIE_REF_USE_PAD : 0,
> - IMX95_PCIE_REF_USE_PAD);
> + IMX95_PCIE_REF_USE_PAD,
> + ext ? IMX95_PCIE_REF_USE_PAD : 0);
> regmap_update_bits(imx_pcie->iomuxc_gpr, IMX95_PCIE_SS_RW_REG_0,
> IMX95_PCIE_REF_CLKEN,
> ext ? 0 : IMX95_PCIE_REF_CLKEN);
> --
> 2.43.0
^ permalink raw reply
* Re: [PATCH v2 2/5] clk: mediatek: Add mt8173-mfgtop driver
From: kernel test robot @ 2026-03-26 1:24 UTC (permalink / raw)
To: Chen-Yu Tsai, Stephen Boyd, Matthias Brugger,
AngeloGioacchino Del Regno, Frank Binns, Matt Coster,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann
Cc: oe-kbuild-all, Icenowy Zheng, Chen-Yu Tsai, David Airlie,
Simona Vetter, linux-clk, devicetree, linux-mediatek, dri-devel,
linux-arm-kernel, linux-kernel
In-Reply-To: <20260325071951.544031-3-wenst@chromium.org>
Hi Chen-Yu,
kernel test robot noticed the following build errors:
[auto build test ERROR on clk/clk-next]
[also build test ERROR on robh/for-next drm-misc/drm-misc-next linus/master v7.0-rc5 next-20260325]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]
url: https://github.com/intel-lab-lkp/linux/commits/Chen-Yu-Tsai/dt-bindings-clock-mediatek-Add-mt8173-mfgtop/20260325-202618
base: https://git.kernel.org/pub/scm/linux/kernel/git/clk/linux.git clk-next
patch link: https://lore.kernel.org/r/20260325071951.544031-3-wenst%40chromium.org
patch subject: [PATCH v2 2/5] clk: mediatek: Add mt8173-mfgtop driver
config: loongarch-randconfig-002-20260326 (https://download.01.org/0day-ci/archive/20260326/202603260926.gAEaAK0A-lkp@intel.com/config)
compiler: loongarch64-linux-gcc (GCC) 14.3.0
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20260326/202603260926.gAEaAK0A-lkp@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202603260926.gAEaAK0A-lkp@intel.com/
All errors (new ones prefixed by >>):
drivers/pmdomain/governor.c: In function 'default_suspend_ok':
>> drivers/pmdomain/governor.c:88:24: error: 'struct dev_pm_info' has no member named 'ignore_children'
88 | if (!dev->power.ignore_children)
| ^
--
drivers/pmdomain/core.c: In function 'genpd_queue_power_off_work':
>> drivers/pmdomain/core.c:941:20: error: 'pm_wq' undeclared (first use in this function)
941 | queue_work(pm_wq, &genpd->power_off_work);
| ^~~~~
drivers/pmdomain/core.c:941:20: note: each undeclared identifier is reported only once for each function it appears in
drivers/pmdomain/core.c: In function 'genpd_dev_pm_qos_notifier':
>> drivers/pmdomain/core.c:1138:39: error: 'struct dev_pm_info' has no member named 'ignore_children'
1138 | if (!dev || dev->power.ignore_children)
| ^
drivers/pmdomain/core.c: In function 'rtpm_status_str':
>> drivers/pmdomain/core.c:3614:23: error: 'struct dev_pm_info' has no member named 'runtime_error'
3614 | if (dev->power.runtime_error)
| ^
>> drivers/pmdomain/core.c:3616:28: error: 'struct dev_pm_info' has no member named 'disable_depth'
3616 | else if (dev->power.disable_depth)
| ^
>> drivers/pmdomain/core.c:3618:28: error: 'struct dev_pm_info' has no member named 'runtime_status'
3618 | else if (dev->power.runtime_status < ARRAY_SIZE(status_lookup))
| ^
drivers/pmdomain/core.c:3619:45: error: 'struct dev_pm_info' has no member named 'runtime_status'
3619 | p = status_lookup[dev->power.runtime_status];
| ^
Kconfig warnings: (for reference only)
WARNING: unmet direct dependencies detected for PM_GENERIC_DOMAINS
Depends on [n]: PM [=n]
Selected by [m]:
- COMMON_CLK_MT8173_MFGTOP [=m] && COMMON_CLK [=y] && (ARCH_MEDIATEK || COMPILE_TEST [=y]) && COMMON_CLK_MT8173 [=m]
vim +88 drivers/pmdomain/governor.c
a5bef810ad9816 drivers/base/power/domain_governor.c Rafael J. Wysocki 2012-04-29 49
b02c999ac325e9 drivers/base/power/domain_governor.c Rafael J. Wysocki 2011-12-01 50 /**
9df3921e026532 drivers/base/power/domain_governor.c Ulf Hansson 2016-03-31 51 * default_suspend_ok - Default PM domain governor routine to suspend devices.
b02c999ac325e9 drivers/base/power/domain_governor.c Rafael J. Wysocki 2011-12-01 52 * @dev: Device to check.
3b2714c5d2d26d drivers/base/power/domain_governor.c Randy Dunlap 2023-12-05 53 *
3b2714c5d2d26d drivers/base/power/domain_governor.c Randy Dunlap 2023-12-05 54 * Returns: true if OK to suspend, false if not OK to suspend
b02c999ac325e9 drivers/base/power/domain_governor.c Rafael J. Wysocki 2011-12-01 55 */
9df3921e026532 drivers/base/power/domain_governor.c Ulf Hansson 2016-03-31 56 static bool default_suspend_ok(struct device *dev)
b02c999ac325e9 drivers/base/power/domain_governor.c Rafael J. Wysocki 2011-12-01 57 {
66d29d802ef3bf drivers/base/power/domain_governor.c Ulf Hansson 2022-05-11 58 struct gpd_timing_data *td = dev_gpd_data(dev)->td;
6ff7bb0d02f829 drivers/base/power/domain_governor.c Rafael J. Wysocki 2012-05-01 59 unsigned long flags;
a5bef810ad9816 drivers/base/power/domain_governor.c Rafael J. Wysocki 2012-04-29 60 s64 constraint_ns;
b02c999ac325e9 drivers/base/power/domain_governor.c Rafael J. Wysocki 2011-12-01 61
b02c999ac325e9 drivers/base/power/domain_governor.c Rafael J. Wysocki 2011-12-01 62 dev_dbg(dev, "%s()\n", __func__);
b02c999ac325e9 drivers/base/power/domain_governor.c Rafael J. Wysocki 2011-12-01 63
6ff7bb0d02f829 drivers/base/power/domain_governor.c Rafael J. Wysocki 2012-05-01 64 spin_lock_irqsave(&dev->power.lock, flags);
6ff7bb0d02f829 drivers/base/power/domain_governor.c Rafael J. Wysocki 2012-05-01 65
6ff7bb0d02f829 drivers/base/power/domain_governor.c Rafael J. Wysocki 2012-05-01 66 if (!td->constraint_changed) {
9df3921e026532 drivers/base/power/domain_governor.c Ulf Hansson 2016-03-31 67 bool ret = td->cached_suspend_ok;
6ff7bb0d02f829 drivers/base/power/domain_governor.c Rafael J. Wysocki 2012-05-01 68
6ff7bb0d02f829 drivers/base/power/domain_governor.c Rafael J. Wysocki 2012-05-01 69 spin_unlock_irqrestore(&dev->power.lock, flags);
6ff7bb0d02f829 drivers/base/power/domain_governor.c Rafael J. Wysocki 2012-05-01 70 return ret;
6ff7bb0d02f829 drivers/base/power/domain_governor.c Rafael J. Wysocki 2012-05-01 71 }
6ff7bb0d02f829 drivers/base/power/domain_governor.c Rafael J. Wysocki 2012-05-01 72 td->constraint_changed = false;
9df3921e026532 drivers/base/power/domain_governor.c Ulf Hansson 2016-03-31 73 td->cached_suspend_ok = false;
0759e80b84e34a drivers/base/power/domain_governor.c Rafael J. Wysocki 2017-11-07 74 td->effective_constraint_ns = 0;
8262331eaaf751 drivers/base/power/domain_governor.c Viresh Kumar 2019-07-04 75 constraint_ns = __dev_pm_qos_resume_latency(dev);
6ff7bb0d02f829 drivers/base/power/domain_governor.c Rafael J. Wysocki 2012-05-01 76
6ff7bb0d02f829 drivers/base/power/domain_governor.c Rafael J. Wysocki 2012-05-01 77 spin_unlock_irqrestore(&dev->power.lock, flags);
6ff7bb0d02f829 drivers/base/power/domain_governor.c Rafael J. Wysocki 2012-05-01 78
0759e80b84e34a drivers/base/power/domain_governor.c Rafael J. Wysocki 2017-11-07 79 if (constraint_ns == 0)
a5bef810ad9816 drivers/base/power/domain_governor.c Rafael J. Wysocki 2012-04-29 80 return false;
a5bef810ad9816 drivers/base/power/domain_governor.c Rafael J. Wysocki 2012-04-29 81
a5bef810ad9816 drivers/base/power/domain_governor.c Rafael J. Wysocki 2012-04-29 82 constraint_ns *= NSEC_PER_USEC;
a5bef810ad9816 drivers/base/power/domain_governor.c Rafael J. Wysocki 2012-04-29 83 /*
a5bef810ad9816 drivers/base/power/domain_governor.c Rafael J. Wysocki 2012-04-29 84 * We can walk the children without any additional locking, because
6ff7bb0d02f829 drivers/base/power/domain_governor.c Rafael J. Wysocki 2012-05-01 85 * they all have been suspended at this point and their
6ff7bb0d02f829 drivers/base/power/domain_governor.c Rafael J. Wysocki 2012-05-01 86 * effective_constraint_ns fields won't be modified in parallel with us.
a5bef810ad9816 drivers/base/power/domain_governor.c Rafael J. Wysocki 2012-04-29 87 */
a5bef810ad9816 drivers/base/power/domain_governor.c Rafael J. Wysocki 2012-04-29 @88 if (!dev->power.ignore_children)
a5bef810ad9816 drivers/base/power/domain_governor.c Rafael J. Wysocki 2012-04-29 89 device_for_each_child(dev, &constraint_ns,
a5bef810ad9816 drivers/base/power/domain_governor.c Rafael J. Wysocki 2012-04-29 90 dev_update_qos_constraint);
b02c999ac325e9 drivers/base/power/domain_governor.c Rafael J. Wysocki 2011-12-01 91
0759e80b84e34a drivers/base/power/domain_governor.c Rafael J. Wysocki 2017-11-07 92 if (constraint_ns == PM_QOS_RESUME_LATENCY_NO_CONSTRAINT_NS) {
704d2ce6603f7e drivers/base/power/domain_governor.c Rafael J. Wysocki 2017-11-07 93 /* "No restriction", so the device is allowed to suspend. */
0759e80b84e34a drivers/base/power/domain_governor.c Rafael J. Wysocki 2017-11-07 94 td->effective_constraint_ns = PM_QOS_RESUME_LATENCY_NO_CONSTRAINT_NS;
704d2ce6603f7e drivers/base/power/domain_governor.c Rafael J. Wysocki 2017-11-07 95 td->cached_suspend_ok = true;
0759e80b84e34a drivers/base/power/domain_governor.c Rafael J. Wysocki 2017-11-07 96 } else if (constraint_ns == 0) {
704d2ce6603f7e drivers/base/power/domain_governor.c Rafael J. Wysocki 2017-11-07 97 /*
704d2ce6603f7e drivers/base/power/domain_governor.c Rafael J. Wysocki 2017-11-07 98 * This triggers if one of the children that don't belong to a
0759e80b84e34a drivers/base/power/domain_governor.c Rafael J. Wysocki 2017-11-07 99 * domain has a zero PM QoS constraint and it's better not to
0759e80b84e34a drivers/base/power/domain_governor.c Rafael J. Wysocki 2017-11-07 100 * suspend then. effective_constraint_ns is zero already and
0759e80b84e34a drivers/base/power/domain_governor.c Rafael J. Wysocki 2017-11-07 101 * cached_suspend_ok is false, so bail out.
704d2ce6603f7e drivers/base/power/domain_governor.c Rafael J. Wysocki 2017-11-07 102 */
704d2ce6603f7e drivers/base/power/domain_governor.c Rafael J. Wysocki 2017-11-07 103 return false;
704d2ce6603f7e drivers/base/power/domain_governor.c Rafael J. Wysocki 2017-11-07 104 } else {
2b1d88cda32f81 drivers/base/power/domain_governor.c Ulf Hansson 2015-10-15 105 constraint_ns -= td->suspend_latency_ns +
2b1d88cda32f81 drivers/base/power/domain_governor.c Ulf Hansson 2015-10-15 106 td->resume_latency_ns;
704d2ce6603f7e drivers/base/power/domain_governor.c Rafael J. Wysocki 2017-11-07 107 /*
0759e80b84e34a drivers/base/power/domain_governor.c Rafael J. Wysocki 2017-11-07 108 * effective_constraint_ns is zero already and cached_suspend_ok
0759e80b84e34a drivers/base/power/domain_governor.c Rafael J. Wysocki 2017-11-07 109 * is false, so if the computed value is not positive, return
0759e80b84e34a drivers/base/power/domain_governor.c Rafael J. Wysocki 2017-11-07 110 * right away.
704d2ce6603f7e drivers/base/power/domain_governor.c Rafael J. Wysocki 2017-11-07 111 */
704d2ce6603f7e drivers/base/power/domain_governor.c Rafael J. Wysocki 2017-11-07 112 if (constraint_ns <= 0)
a5bef810ad9816 drivers/base/power/domain_governor.c Rafael J. Wysocki 2012-04-29 113 return false;
704d2ce6603f7e drivers/base/power/domain_governor.c Rafael J. Wysocki 2017-11-07 114
a5bef810ad9816 drivers/base/power/domain_governor.c Rafael J. Wysocki 2012-04-29 115 td->effective_constraint_ns = constraint_ns;
704d2ce6603f7e drivers/base/power/domain_governor.c Rafael J. Wysocki 2017-11-07 116 td->cached_suspend_ok = true;
704d2ce6603f7e drivers/base/power/domain_governor.c Rafael J. Wysocki 2017-11-07 117 }
a98f1b78ecf325 drivers/base/power/domain_governor.c Ulf Hansson 2015-10-13 118
a5bef810ad9816 drivers/base/power/domain_governor.c Rafael J. Wysocki 2012-04-29 119 /*
a5bef810ad9816 drivers/base/power/domain_governor.c Rafael J. Wysocki 2012-04-29 120 * The children have been suspended already, so we don't need to take
9df3921e026532 drivers/base/power/domain_governor.c Ulf Hansson 2016-03-31 121 * their suspend latencies into account here.
a5bef810ad9816 drivers/base/power/domain_governor.c Rafael J. Wysocki 2012-04-29 122 */
9df3921e026532 drivers/base/power/domain_governor.c Ulf Hansson 2016-03-31 123 return td->cached_suspend_ok;
b02c999ac325e9 drivers/base/power/domain_governor.c Rafael J. Wysocki 2011-12-01 124 }
b02c999ac325e9 drivers/base/power/domain_governor.c Rafael J. Wysocki 2011-12-01 125
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* [PATCH v4] nvme: Skip trace complete_rq on host path error
From: 전민식 @ 2026-03-26 1:44 UTC (permalink / raw)
To: Keith Busch, Justin Tee
Cc: axboe@kernel.dk, sven@kernel.org, j@jannau.net, neal@gompa.dev,
hch@lst.de, sagi@grimberg.me, justin.tee@broadcom.com,
nareshgottumukkala83@gmail.com, paul.ely@broadcom.com,
James Smart, kch@nvidia.com, linux-arm-kernel@lists.infradead.org,
linux-nvme@lists.infradead.org, asahi@lists.linux.dev,
linux-kernel@vger.kernel.org, 이은수,
전민식, 칸찬
In-Reply-To: <acQxjZMOqj74yIJf@kbusch-mbp>
Hi Keith Busch,
If it's host pathing error, Do you mean to skip `trace_nvme_complete_rq()`?
If so, I agree with this approach.
Thank you
Regards,
Minsik Jeon
From c1f3c209c35233154bf5918092bdbb085828db23 Mon Sep 17 00:00:00 2001
From: Minsik Jeon <hmi.jeon@samsung.com>
Date: Thu, 26 Mar 2026 11:09:57 +0900
Subject: [PATCH v4] nvme: Skip trace complete_rq on host path error
we were checking host_pathing_error before calling nvme_setup_cmd().
This is caused the command setup to be skipped entirely when a pathing
error occurred, making it impossible to trace the nvme command via
trace_cmd nvme_complete_rq().
As a result, when nvme_complete_rq() logged a completion with cmdid=0,
it was impossible to correlate the completion with the nvme command
request.
This patch Skip trace_nvme_complete_rq() on NVMe host path error.
Co-authored-by: Beomsoo Kim <beomsooo.kim@samsung.com>
Co-authored-by: Eunsoo Lee <euns212.lee@samsung.com>
Co-authored-by: Steven Seungcheol Lee <sc108.lee@samsung.com>
Signed-off-by: Minsik Jeon <hmi.jeon@samsung.com>
---
drivers/nvme/host/core.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/nvme/host/core.c b/drivers/nvme/host/core.c
index 766e9cc4ffca..8f98d5220206 100644
--- a/drivers/nvme/host/core.c
+++ b/drivers/nvme/host/core.c
@@ -458,7 +458,9 @@ void nvme_complete_rq(struct request *req)
{
struct nvme_ctrl *ctrl = nvme_req(req)->ctrl;
- trace_nvme_complete_rq(req);
+ if (nvme_req(req)->status != NVME_SC_HOST_PATH_ERROR)
+ trace_nvme_complete_rq(req);
+
nvme_cleanup_cmd(req);
/*
--
2.52.0
^ permalink raw reply related
* Re: [PATCH v6 1/5] mm: rmap: support batched checks of the references for large folios
From: Baolin Wang @ 2026-03-26 1:47 UTC (permalink / raw)
To: Lorenzo Stoakes (Oracle), David Hildenbrand (Arm)
Cc: Barry Song, akpm, catalin.marinas, will, lorenzo.stoakes,
ryan.roberts, Liam.Howlett, vbabka, rppt, surenb, mhocko, riel,
harry.yoo, jannh, willy, dev.jain, linux-mm, linux-arm-kernel,
linux-kernel
In-Reply-To: <e227a7f7-0186-4d10-b7b4-c84ca8424bdd@lucifer.local>
On 3/25/26 11:06 PM, Lorenzo Stoakes (Oracle) wrote:
> On Wed, Mar 25, 2026 at 03:58:36PM +0100, David Hildenbrand (Arm) wrote:
>> On 3/25/26 15:36, Lorenzo Stoakes (Oracle) wrote:
>>> On Mon, Mar 16, 2026 at 03:15:18PM +0100, David Hildenbrand (Arm) wrote:
>>>> On 3/16/26 07:25, Baolin Wang wrote:
>>>>>
>>>>>
>>>>>
>>>>> Sure. However, after investigating RISC‑V and x86, I found that
>>>>> ptep_clear_flush_young() does not flush the TLB on these architectures:
>>>>>
>>>>> int ptep_clear_flush_young(struct vm_area_struct *vma,
>>>>> unsigned long address, pte_t *ptep)
>>>>> {
>>>>> /*
>>>>> * On x86 CPUs, clearing the accessed bit without a TLB flush
>>>>> * doesn't cause data corruption. [ It could cause incorrect
>>>>> * page aging and the (mistaken) reclaim of hot pages, but the
>>>>> * chance of that should be relatively low. ]
>>>>> *
>>>>> * So as a performance optimization don't flush the TLB when
>>>>> * clearing the accessed bit, it will eventually be flushed by
>>>>> * a context switch or a VM operation anyway. [ In the rare
>>>>> * event of it not getting flushed for a long time the delay
>>>>> * shouldn't really matter because there's no real memory
>>>>> * pressure for swapout to react to. ]
>>>>> */
>>>>> return ptep_test_and_clear_young(vma, address, ptep);
>>>>> }
>>>>
>>>> You'd probably want an arch helper then, that tells you whether
>>>> a flush_tlb_range() after ptep_test_and_clear_young() is required.
>>>>
>>>> Or some special flush_tlb_range() helper.
>>>>
>>>> I agree that it requires more work.
(Sorry, David. I forgot to reply to your email because I've had a lot to
sort out recently.)
Rather than adding more arch helpers (we already have plenty for the
young flag check), I think we should try removing the TLB flush, as I
mentioned to Barry[1]. MGLRU reclaim already skips the TLB flush, and it
seems to work fine. What do you think?
Here are our previous attempts to remove the TLB flush:
My patch: https://lkml.org/lkml/2023/10/24/533
Barry's patch:
https://lore.kernel.org/lkml/20220617070555.344368-1-21cnbao@gmail.com/
[1]
https://lore.kernel.org/all/6bdc4b03-9631-4717-a3fa-2785a7930aba@linux.alibaba.com/
>>> Sorry unclear here - does the series need more work or does a follow up patch
>>> need more work?
>>
>> Follow up!
>
> Ok good as in mm-stable now. Sadly means I don't get to review it but there we
> go.
Actually this patchset has already been merged upstream:)
^ 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