* [PATCH V3 8/8] arm64: dts: imx8qxp-mek: Describe the PCIe M.2 Key E connector
From: Sherry Sun (OSS) @ 2026-06-26 2:31 UTC (permalink / raw)
To: robh, krzk+dt, conor+dt, Frank.Li, s.hauer, kernel, festevam,
amitkumar.karwar, neeraj.sanjaykale, marcel, luiz.dentz,
hongxing.zhu, l.stach, lpieralisi, kwilczynski, mani, bhelgaas,
brgl
Cc: imx, linux-pci, linux-arm-kernel, devicetree, linux-kernel,
linux-bluetooth, linux-pm, sherry.sun
In-Reply-To: <20260626023126.2189931-1-sherry.sun@oss.nxp.com>
From: Sherry Sun <sherry.sun@nxp.com>
The i.MX8QXP-MEK has the PCIe M.2 Mechanical Key E connector to connect
wireless connectivity cards over PCIe and UART interfaces. Hence,
describe the connector node and link it with the PCIe b Root Port and
LPUART1 nodes through graph port/endpoint.
The M.2 Key E connector is powered by a 3.3V fixed regulator
(reg_3v3) on board.
Signed-off-by: Sherry Sun <sherry.sun@nxp.com>
---
arch/arm64/boot/dts/freescale/imx8qxp-mek.dts | 54 ++++++++++++++-----
1 file changed, 41 insertions(+), 13 deletions(-)
diff --git a/arch/arm64/boot/dts/freescale/imx8qxp-mek.dts b/arch/arm64/boot/dts/freescale/imx8qxp-mek.dts
index a9b967d0a9be..c9fe4034cc2d 100644
--- a/arch/arm64/boot/dts/freescale/imx8qxp-mek.dts
+++ b/arch/arm64/boot/dts/freescale/imx8qxp-mek.dts
@@ -40,6 +40,37 @@ memory@80000000 {
reg = <0x00000000 0x80000000 0 0x40000000>;
};
+ m2-connector {
+ compatible = "pcie-m2-e-connector";
+ vpcie3v3-supply = <®_3v3>;
+ w-disable1-gpios = <&pca9557_a 2 GPIO_ACTIVE_LOW>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0>;
+ m2_e_pcie_ep: endpoint@0 {
+ reg = <0>;
+ remote-endpoint = <&pcieb_port0_ep>;
+ };
+ };
+
+ port@3 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <3>;
+ m2_e_uart_ep: endpoint@0 {
+ reg = <0>;
+ remote-endpoint = <&lpuart1_ep>;
+ };
+ };
+ };
+ };
+
reg_usdhc2_vmmc: usdhc2-vmmc {
compatible = "regulator-fixed";
regulator-name = "SD1_SPWR";
@@ -157,15 +188,6 @@ reg_3v3: regulator-3v3 {
regulator-max-microvolt = <3300000>;
};
- reg_pcieb: regulator-pcie {
- compatible = "regulator-fixed";
- regulator-max-microvolt = <3300000>;
- regulator-min-microvolt = <3300000>;
- regulator-name = "mpcie_3v3";
- gpio = <&pca9557_a 2 GPIO_ACTIVE_HIGH>;
- enable-active-high;
- };
-
reg_audio: regulator-audio {
compatible = "regulator-fixed";
regulator-max-microvolt = <3300000>;
@@ -696,8 +718,10 @@ &lpuart1 {
pinctrl-0 = <&pinctrl_lpuart1>;
status = "okay";
- bluetooth {
- compatible = "nxp,88w8987-bt";
+ port {
+ lpuart1_ep: endpoint {
+ remote-endpoint = <&m2_e_uart_ep>;
+ };
};
};
@@ -746,8 +770,12 @@ &pcie0_ep {
&pcieb_port0 {
reset-gpios = <&lsio_gpio4 0 GPIO_ACTIVE_LOW>;
- vpcie-supply = <®_pcieb>;
- vpcie3v3aux-supply = <®_pcieb>;
+
+ port {
+ pcieb_port0_ep: endpoint {
+ remote-endpoint = <&m2_e_pcie_ep>;
+ };
+ };
};
&scu_key {
--
2.50.1
^ permalink raw reply related
* Re: [PATCH v1] irqchip/gic-v3-its: Fix OF node reference leak
From: 최유호 @ 2026-06-26 2:40 UTC (permalink / raw)
To: Zenghui Yu; +Cc: Marc Zyngier, Thomas Gleixner, linux-arm-kernel, linux-kernel
In-Reply-To: <24e2da5b-82a4-4889-8b62-5f445cec9657@linux.dev>
Thanks for the review!
> It looks to me that this issue was introduced in fbf8f40e1658
> ("irqchip/gicv3-its: numa: Enable workaround for Cavium thunderx erratum
> 23144"). What am I missing?
>
You are right; I used the wrong Fixes tag. I will update the fix commit in v2.
> > Please consider using the cleanup infrastructure instead, something
> > like the untested hack below.
Sure, I'll update this in v2 and resend it.
Thanks,
Yuho
^ permalink raw reply
* Re: chipidea: usbmisc_imx: i.MX93 support
From: Xu Yang @ 2026-06-26 2:39 UTC (permalink / raw)
To: Stefan Wahren
Cc: Xu Yang, Frank Li, Jun Li, Alexander Stein, Greg Kroah-Hartman,
Linux ARM, linux-usb@vger.kernel.org
In-Reply-To: <f1cb93cc-40ac-4b88-bc0e-94390d1f6a99@gmx.net>
On Thu, Jun 25, 2026 at 05:22:20PM +0200, Stefan Wahren wrote:
> Am 25.06.26 um 05:07 schrieb Xu Yang:
> > On Wed, Jun 24, 2026 at 12:05:00PM +0200, Stefan Wahren wrote:
> > > Hi Xu,
> > >
> > > Am 24.06.26 um 11:11 schrieb Xu Yang:
> > > > On Wed, Jun 24, 2026 at 08:30:00AM +0200, Stefan Wahren wrote:
> > > > What's your issue on i.MX93?
> > > we have an i.MX93 board using both USB interfaces:
> > >
> > > USB1:
> > > - external available via USB-C connector
> > > - OTG interface should be able to switch between host and peripheral
> > > - as USB-C interface control we use the TI TUSB321AI [1] (while its DIR,
> > > OUT1, OUT2, CURRENT_MODE, PORT is unconnected or tied to GND)
> > >
> > > USB2:
> > > - used as internal host interface
> > >
> > > We have the problem that 5 seconds after disconnecting a USB device from
> > > USB-C (USB1) interface, the USB driver complains that the VBUS is still to
> > > high:
> > >
> > > [ 144.078347] usb 2-1: USB disconnect, device number 2
> > > [ 144.083425] ci_hdrc ci_hdrc.0: remove, state 1
> > > [ 144.083521] usb 2-1.1: USB disconnect, device number 3
> > > [ 144.090310] usb usb2: USB disconnect, device number 1
> > > [ 144.139325] usb 2-1.5: USB disconnect, device number 4
> > > [ 144.158700] ci_hdrc ci_hdrc.0: USB bus 2 deregistered
> > > [ 149.190274] ci_hdrc ci_hdrc.0: timeout waiting for 00000800 in OTGSC
> > > [ 149.196741] usbmisc_imx 4c100200.usbmisc: vbus is error
> > > [ 149.202078] usbmisc_imx 4c100200.usbmisc: Error occurs during detection:
> > > -22
> > Does the VBUS be turned off after switching to device mode? If yes, how long
> > will the voltage of VBUS drop to 0.8V?
> The regulator turns off the VBUS indirectly, but the voltage is above 2 V.
> AFAIU the discharge resistor is missing.
Yes, then the 2V voltage is the issue.
> >
> > > But except of this, both roles works as expected.
> > >
> > > Here are the relevant device tree parts:
> > >
> > > reg_usb_otg1_vbus: regulator-usb-otg1-vbus {
> > > pinctrl-names = "default";
> > > pinctrl-0 = <&pinctrl_usbotg1grp>;
> > > compatible = "regulator-fixed";
> > > regulator-name = "usb_otg1_vbus";
> > > regulator-min-microvolt = <5000000>;
> > > regulator-max-microvolt = <5000000>;
> > > gpio = <&gpio4 13 GPIO_ACTIVE_HIGH>;
> > > enable-active-high;
> > > regulator-boot-on;
> > > };
> > >
> > > &usbotg1 {
> > > vbus-supply = <®_usb_otg1_vbus>;
> > > over-current-active-low;
> > > status = "okay";
> > > };
> > Does USB2 use the same VBUS regulator?
> No, USB2 has its own VBUS regulator. So the usbotg1 node looks good?
Yes, it's fine here.
Thanks,
Xu Yang
^ permalink raw reply
* Re: [PATCH] Bluetooth: btmtk: Disable remote wakeup for MT7922/MT7925
From: Chris Lu (陸稚泓) @ 2026-06-26 2:40 UTC (permalink / raw)
To: patchwork-bot+bluetooth@kernel.org, luiz.dentz@gmail.com,
i@rong.moe
Cc: Chris Lu (陸稚泓), marcel@holtmann.org,
AngeloGioacchino Del Regno, SS Wu (巫憲欣),
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-bluetooth@vger.kernel.org,
linux-mediatek@lists.infradead.org, matthias.bgg@gmail.com
In-Reply-To: <178050901239.1520440.2026593395539384648.git-patchwork-notify@kernel.org>
Hi Luiz,
Could we revert this change?
Sorry, MediaTek wasn't aware someone submitted this change and it had
already been merged.
MTK believes this issue is strongly related to the platform's USB hub
behavior, The product lines MTK directly support haven't reported such
issue.
Disable wake capability would severely impact wake on Bluetooth on
MTK's official product lines. Furthermore, this patch looks like a
workaround. There should be a better way to handle this issue. We hope
this change can be reverted.
On Wed, 2026-06-03 at 17:50 +0000, patchwork-bot+bluetooth@kernel.org
wrote:
> Hello:
>
> This patch was applied to bluetooth/bluetooth-next.git (master)
> by Luiz Augusto von Dentz <luiz.von.dentz@intel.com>:
>
> On Wed, 03 Jun 2026 02:38:10 +0800 you wrote:
> > These NICs are often reported to lose their Bluetooth interfaces,
> > i.e,
> > their USB interfaces suddenly become completely unresponsive,
> > causing
> > the USB core to reset them, only to find that they are no longer
> > accessible. A power cycle is required to make the Bluetooth
> > interfaces
> > recover.
> >
> > After some investigations, I found that their USB autosuspend
> > remote
> > wakeup capabilities are so broken that they are precisely the
> > culprit
> > behind the issue:
> >
> > [...]
>
> Here is the summary with links:
> - Bluetooth: btmtk: Disable remote wakeup for MT7922/MT7925
> https://git.kernel.org/bluetooth/bluetooth-next/c/247570151789
>
> You are awesome, thank you!
Best Regards,
Chris Lu
^ permalink raw reply
* [PATCH v2 21/32] pinctrl: mediatek: mt8135: Enable module build support
From: Justin Yeh @ 2026-06-26 1:31 UTC (permalink / raw)
To: Sean Wang, Linus Walleij, Matthias Brugger,
AngeloGioacchino Del Regno
Cc: Project_Global_Chrome_Upstream_Group, linux-mediatek, linux-gpio,
linux-kernel, linux-arm-kernel, Justin Yeh
In-Reply-To: <20260626013217.2373808-1-justin.yeh@mediatek.com>
Add MODULE_LICENSE("GPL") macro and change Kconfig option from
bool to tristate to allow building as a loadable kernel module.
This is required for Android GKI + vendor_dlkm deployments where
vendor-specific drivers must be kept separate from the GKI vmlinux.
Fixes: a6df410d420a ("pinctrl: mediatek: Add Pinctrl/GPIO driver for mt8135.")
Signed-off-by: Justin Yeh <justin.yeh@mediatek.com>
---
drivers/pinctrl/mediatek/Kconfig | 2 +-
drivers/pinctrl/mediatek/pinctrl-mt8135.c | 3 +++
2 files changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/pinctrl/mediatek/Kconfig b/drivers/pinctrl/mediatek/Kconfig
index 2d29968e4cf2..9efbff94e074 100644
--- a/drivers/pinctrl/mediatek/Kconfig
+++ b/drivers/pinctrl/mediatek/Kconfig
@@ -112,7 +112,7 @@ config PINCTRL_MT7629
select PINCTRL_MTK_MOORE
config PINCTRL_MT8135
- bool "MediaTek MT8135 pin control"
+ tristate "MediaTek MT8135 pin control"
depends on MACH_MT8135 || COMPILE_TEST
depends on OF
default MACH_MT8135
diff --git a/drivers/pinctrl/mediatek/pinctrl-mt8135.c b/drivers/pinctrl/mediatek/pinctrl-mt8135.c
index 77c6ac464e86..63da47010b53 100644
--- a/drivers/pinctrl/mediatek/pinctrl-mt8135.c
+++ b/drivers/pinctrl/mediatek/pinctrl-mt8135.c
@@ -336,3 +336,6 @@ static int __init mtk_pinctrl_init(void)
return platform_driver_register(&mtk_pinctrl_driver);
}
arch_initcall(mtk_pinctrl_init);
+
+MODULE_DESCRIPTION("MediaTek MT8135 Pinctrl Driver");
+MODULE_LICENSE("GPL");
--
2.45.2
^ permalink raw reply related
* [PATCH v3 01/32] pinctrl: mediatek: mt8189: Enable module build support
From: Justin Yeh @ 2026-06-26 1:44 UTC (permalink / raw)
To: Sean Wang, Linus Walleij, Matthias Brugger,
AngeloGioacchino Del Regno
Cc: Project_Global_Chrome_Upstream_Group, linux-mediatek, linux-gpio,
linux-kernel, linux-arm-kernel, Justin Yeh
In-Reply-To: <20260626014442.2378513-1-justin.yeh@mediatek.com>
Add MODULE_LICENSE("GPL") macro and change Kconfig option from
bool to tristate to allow building as a loadable kernel module.
This is required for Android GKI + vendor_dlkm deployments where
vendor-specific drivers must be kept separate from the GKI vmlinux.
Fixes: a3fe1324c3c5 ("pinctrl: mediatek: Add pinctrl driver for mt8189")
Signed-off-by: Justin Yeh <justin.yeh@mediatek.com>
---
drivers/pinctrl/mediatek/Kconfig | 2 +-
drivers/pinctrl/mediatek/pinctrl-mt8189.c | 1 +
2 files changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/pinctrl/mediatek/Kconfig b/drivers/pinctrl/mediatek/Kconfig
index 97980cc28b9c..e79139700d72 100644
--- a/drivers/pinctrl/mediatek/Kconfig
+++ b/drivers/pinctrl/mediatek/Kconfig
@@ -255,7 +255,7 @@ config PINCTRL_MT8188
map specific eint which doesn't have real gpio pin.
config PINCTRL_MT8189
- bool "MediaTek MT8189 pin control"
+ tristate "MediaTek MT8189 pin control"
depends on OF
depends on ARM64 || COMPILE_TEST
default ARM64 && ARCH_MEDIATEK
diff --git a/drivers/pinctrl/mediatek/pinctrl-mt8189.c b/drivers/pinctrl/mediatek/pinctrl-mt8189.c
index cd4cdff309a1..a9c128c514a4 100644
--- a/drivers/pinctrl/mediatek/pinctrl-mt8189.c
+++ b/drivers/pinctrl/mediatek/pinctrl-mt8189.c
@@ -1696,3 +1696,4 @@ static int __init mt8189_pinctrl_init(void)
arch_initcall(mt8189_pinctrl_init);
MODULE_DESCRIPTION("MediaTek MT8189 Pinctrl Driver");
+MODULE_LICENSE("GPL v2");
--
2.45.2
^ permalink raw reply related
* [PATCH v2 07/32] pinctrl: mediatek: mt7988: Enable module build support
From: Justin Yeh @ 2026-06-26 1:31 UTC (permalink / raw)
To: Sean Wang, Linus Walleij, Matthias Brugger,
AngeloGioacchino Del Regno
Cc: Project_Global_Chrome_Upstream_Group, linux-mediatek, linux-gpio,
linux-kernel, linux-arm-kernel, Justin Yeh
In-Reply-To: <20260626013217.2373808-1-justin.yeh@mediatek.com>
Add MODULE_LICENSE("GPL") macro and change Kconfig option from
bool to tristate to allow building as a loadable kernel module.
This is required for Android GKI + vendor_dlkm deployments where
vendor-specific drivers must be kept separate from the GKI vmlinux.
Fixes: 08bec8511182 ("pinctrl: mediatek: add MT7988 pinctrl driver")
Signed-off-by: Justin Yeh <justin.yeh@mediatek.com>
---
drivers/pinctrl/mediatek/Kconfig | 2 +-
drivers/pinctrl/mediatek/pinctrl-mt7988.c | 3 +++
2 files changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/pinctrl/mediatek/Kconfig b/drivers/pinctrl/mediatek/Kconfig
index f0bc125cfb2a..d21c4cd0708a 100644
--- a/drivers/pinctrl/mediatek/Kconfig
+++ b/drivers/pinctrl/mediatek/Kconfig
@@ -223,7 +223,7 @@ config PINCTRL_MT7986
select PINCTRL_MTK_MOORE
config PINCTRL_MT7988
- bool "Mediatek MT7988 pin control"
+ tristate "Mediatek MT7988 pin control"
depends on OF
depends on ARM64 || COMPILE_TEST
default ARM64 && ARCH_MEDIATEK
diff --git a/drivers/pinctrl/mediatek/pinctrl-mt7988.c b/drivers/pinctrl/mediatek/pinctrl-mt7988.c
index fd3a7ff0a04d..99b445f1e771 100644
--- a/drivers/pinctrl/mediatek/pinctrl-mt7988.c
+++ b/drivers/pinctrl/mediatek/pinctrl-mt7988.c
@@ -1544,3 +1544,6 @@ static int __init mt7988_pinctrl_init(void)
return platform_driver_register(&mt7988_pinctrl_driver);
}
arch_initcall(mt7988_pinctrl_init);
+
+MODULE_DESCRIPTION("MediaTek MT7988 Pinctrl Driver");
+MODULE_LICENSE("GPL");
--
2.45.2
^ permalink raw reply related
* [PATCH v3 1/2] i2c: imx: Clear slave pointer on registration error
From: Liem @ 2026-06-26 2:58 UTC (permalink / raw)
To: frank.li
Cc: Frank.Li, andi.shyti, biwen.li, festevam, imx, kernel, liem16213,
linux-arm-kernel, linux-i2c, linux-kernel, o.rempel, s.hauer,
stable, wsa
In-Reply-To: <20260626025846.106157-1-liem16213@gmail.com>
In i2c_imx_reg_slave(), i2c_imx->slave is checked at the beginning
and the function returns -EBUSY if it is non-NULL. If
pm_runtime_resume_and_get() fails later, the error path returns
without clearing i2c_imx->slave, leaving it non-NULL. Subsequent
attempts to register a slave will then immediately fail with
-EBUSY, making it impossible to register the slave again.
Fix by setting i2c_imx->slave = NULL on the error path.
Fixes: f7414cd6923f ("i2c: imx: support slave mode for imx I2C driver")
Cc: stable@vger.kernel.org
Signed-off-by: Liem <liem16213@gmail.com>
---
drivers/i2c/busses/i2c-imx.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/i2c/busses/i2c-imx.c b/drivers/i2c/busses/i2c-imx.c
index 28313d0fad37..17defb470776 100644
--- a/drivers/i2c/busses/i2c-imx.c
+++ b/drivers/i2c/busses/i2c-imx.c
@@ -936,6 +936,7 @@ static int i2c_imx_reg_slave(struct i2c_client *client)
/* Resume */
ret = pm_runtime_resume_and_get(i2c_imx->adapter.dev.parent);
if (ret < 0) {
+ i2c_imx->slave = NULL;
dev_err(&i2c_imx->adapter.dev, "failed to resume i2c controller");
return ret;
}
--
2.34.1
^ permalink raw reply related
* [PATCH v3 2/2] i2c: imx: Cancel hrtimer before clearing slave pointer
From: Liem @ 2026-06-26 2:58 UTC (permalink / raw)
To: frank.li
Cc: Frank.Li, andi.shyti, biwen.li, festevam, imx, kernel, liem16213,
linux-arm-kernel, linux-i2c, linux-kernel, o.rempel, s.hauer,
stable, wsa
In-Reply-To: <20260626025846.106157-1-liem16213@gmail.com>
In i2c_imx_unreg_slave(), the slave pointer is set to NULL after
disabling interrupts. However, a pending interrupt might already
have started the hrtimer (i2c_imx_slave_timeout) before the pointer
was cleared. If the hrtimer fires after i2c_imx->slave is set to
NULL, the timer callback i2c_imx_slave_finish_op() will call
i2c_imx_slave_event() with a NULL slave pointer,which results in a
use-after-free / NULL pointer dereference.
Fix by canceling the hrtimer and waiting for it to complete after
disabling interrupts, before clearing the slave pointer.
Fixes: f7414cd6923f ("i2c: imx: support slave mode for imx I2C driver")
Cc: stable@vger.kernel.org
Signed-off-by: Liem <liem16213@gmail.com>
---
drivers/i2c/busses/i2c-imx.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/i2c/busses/i2c-imx.c b/drivers/i2c/busses/i2c-imx.c
index 17defb470776..f02c216ba299 100644
--- a/drivers/i2c/busses/i2c-imx.c
+++ b/drivers/i2c/busses/i2c-imx.c
@@ -959,6 +959,7 @@ static int i2c_imx_unreg_slave(struct i2c_client *client)
i2c_imx_reset_regs(i2c_imx);
+ hrtimer_cancel(&i2c_imx->slave_timer);
i2c_imx->slave = NULL;
/* Suspend */
--
2.34.1
^ permalink raw reply related
* [PATCH v3 0/2] Fix slave mode corner issues
From: Liem @ 2026-06-26 2:58 UTC (permalink / raw)
To: frank.li
Cc: Frank.Li, andi.shyti, biwen.li, festevam, imx, kernel, liem16213,
linux-arm-kernel, linux-i2c, linux-kernel, o.rempel, s.hauer,
stable, wsa
In-Reply-To: <aj1UR5ddawsdMbZC@SMW015318>
This series fixes two issues in the i2c-imx slave mode.
Patch 1 clears the slave pointer on registration failure to allow
subsequent re-registration.
Patch 2 cancels the hrtimer before clearing the slave pointer during
unregistration, preventing a potential use-after-free / NULL pointer
dereference.
Changes in v3:
- Split the original patch into two separate patches as suggested by
Frank Li.
- v2: https://lore.kernel.org/imx/
20260625160219.55116-1-liem16213@gmail.com/
Liem (2):
i2c: imx: Clear slave pointer on registration error
i2c: imx: Cancel hrtimer before clearing slave pointer
drivers/i2c/busses/i2c-imx.c | 2 ++
1 file changed, 2 insertions(+)
--
2.34.1
^ permalink raw reply
* [PATCH v2] irqchip/gic-v3-its: Fix OF node reference leak
From: Yuho Choi @ 2026-06-26 3:37 UTC (permalink / raw)
To: Marc Zyngier, Thomas Gleixner; +Cc: linux-arm-kernel, linux-kernel, Yuho Choi
of_get_cpu_node() returns a referenced device node. In
its_cpu_init_collection(), the Cavium 23144 workaround only uses the
node to compare the CPU NUMA node, but the reference is never dropped.
Use the device_node cleanup helper for the CPU node reference so it is
released when leaving the workaround block, including the NUMA mismatch
return path.
Fixes: fbf8f40e1658 ("irqchip/gicv3-its: numa: Enable workaround for Cavium thunderx erratum 23144")
Signed-off-by: Yuho Choi <dbgh9129@gmail.com>
---
- Use __free(device_node) for the CPU node reference.
- Correct the Fixes tag to fbf8f40e1658.
drivers/irqchip/irq-gic-v3-its.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/irqchip/irq-gic-v3-its.c b/drivers/irqchip/irq-gic-v3-its.c
index b57d81ad33a0..63942cf1dbe3 100644
--- a/drivers/irqchip/irq-gic-v3-its.c
+++ b/drivers/irqchip/irq-gic-v3-its.c
@@ -3290,9 +3290,9 @@ static void its_cpu_init_collection(struct its_node *its)
/* avoid cross node collections and its mapping */
if (its->flags & ITS_FLAGS_WORKAROUND_CAVIUM_23144) {
- struct device_node *cpu_node;
+ struct device_node *cpu_node __free(device_node) =
+ of_get_cpu_node(cpu, NULL);
- cpu_node = of_get_cpu_node(cpu, NULL);
if (its->numa_node != NUMA_NO_NODE &&
its->numa_node != of_node_to_nid(cpu_node))
return;
--
2.43.0
^ permalink raw reply related
page: | 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