* [PATCH v5 3/8] Bluetooth: btusb: Add MT7927 ID for ASUS ROG Crosshair X870E Hero
From: Javier Tia @ 2026-03-31 17:09 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: <20260331-mt7927-bt-support-v5-0-6f31b4342daa@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 v5 4/8] Bluetooth: btusb: Add MT7927 ID for Lenovo Legion Pro 7 16ARX9
From: Javier Tia @ 2026-03-31 17:09 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: <20260331-mt7927-bt-support-v5-0-6f31b4342daa@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 v5 5/8] Bluetooth: btusb: Add MT7927 ID for Gigabyte Z790 AORUS MASTER X
From: Javier Tia @ 2026-03-31 17:09 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: <20260331-mt7927-bt-support-v5-0-6f31b4342daa@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 v5 6/8] Bluetooth: btusb: Add MT7927 ID for MSI X870E Ace Max
From: Javier Tia @ 2026-03-31 17:09 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,
Nitin Gurram
In-Reply-To: <20260331-mt7927-bt-support-v5-0-6f31b4342daa@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>
Tested-by: Nitin Gurram <nitin.reddy88@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 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 v5 7/8] Bluetooth: btusb: Add MT7927 ID for TP-Link Archer TBE550E
From: Javier Tia @ 2026-03-31 17:09 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: <20260331-mt7927-bt-support-v5-0-6f31b4342daa@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 v5 8/8] Bluetooth: btusb: Add MT7927 ID for ASUS X870E / ProArt X870E-Creator
From: Javier Tia @ 2026-03-31 17:09 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: <20260331-mt7927-bt-support-v5-0-6f31b4342daa@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 expose only one ISO alternate setting
(alt 0). Without the fix in patch 2/8 ("btmtk: fix ISO interface
setup for single alt setting"), this caused ~19 second initialization
delays. With the fix applied, initialization completes in ~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 v4 0/8] Bluetooth: Add MediaTek MT7927 (MT6639) support
From: Javier Tia @ 2026-03-31 17:10 UTC (permalink / raw)
To: Luiz Augusto von Dentz
Cc: Marcel Holtmann, Matthias Brugger, AngeloGioacchino Del Regno,
linux-bluetooth, linux-kernel, linux-arm-kernel, linux-mediatek,
Ryan Gilbert, Jose Tiburcio Ribeiro Netto, Llewellyn Curran,
Chapuis Dario, Evgeny Kapusta, Nitin Gurram, Thibaut FRANCOIS,
Ivan Lubnin
Hi Luiz,
On Tue, 31 Mar 2026 Luiz Augusto von Dentz wrote:
> Ok, but on 8/8 it seem to suggest the problem still exists which
> trigger the following review:
>
> https://sashiko.dev/#/patchset/20260330-mt7927-bt-support-v4-0-cecc025e7062%40jetm.me
>
> Perhaps we should ajust the commit description if the 19 seconds
> doesn't really occurs when 2/8 is applied.
Good catch. The ~19 second delay is indeed fixed by patch 2/8, so the
note in 8/8 was misleading as written.
I've updated the commit message in 8/8 to clarify:
Note: boards with this USB ID expose only one ISO alternate setting
(alt 0). Without the fix in patch 2/8 ("btmtk: fix ISO interface
setup for single alt setting"), this caused ~19 second initialization
delays. With the fix applied, initialization completes in ~2.6
seconds.
This is addressed in v5:
https://lore.kernel.org/linux-bluetooth/20260331-mt7927-bt-support-v5-0-6f31b4342daa@jetm.me/
Best,
Javier
^ permalink raw reply
* Re: [PATCH 09/15] KVM: arm64: vgic-v5: align priority comparison with other GICs
From: Marc Zyngier @ 2026-03-31 17:18 UTC (permalink / raw)
To: Sascha Bischoff
Cc: kvmarm@lists.linux.dev, kvm@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, Joey Gouly,
yuzenghui@huawei.com, Suzuki Poulose, oupton@kernel.org,
broonie@kernel.org, nd
In-Reply-To: <729851f0e7d277d308adf04d0008156a01f482bb.camel@arm.com>
On Tue, 31 Mar 2026 16:09:10 +0100,
Sascha Bischoff <Sascha.Bischoff@arm.com> wrote:
>
> On Thu, 2026-03-26 at 15:35 +0000, Marc Zyngier wrote:
> > The way the effective priority mask is computed, and then compared
> > to the priority of an interrupt to decide whether to wake-up or not,
> > is slightly odd, and breaks at the limits.
> >
> > This could result in spurious wake-ups that are undesirable.
> >
> > Adopt the GICv[23] logic instead, which checks that the priority
> > value
> > is strictly lower than the mask.
> >
> > Fixes: 933e5288fa971 ("KVM: arm64: gic-v5: Check for pending PPIs")
> > Link:
> > https://sashiko.dev/#/patchset/20260319154937.3619520-1-sascha.bischoff%40arm.com
> > Signed-off-by: Marc Zyngier <maz@kernel.org>
> > ---
> > arch/arm64/kvm/vgic/vgic-v5.c | 4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/arch/arm64/kvm/vgic/vgic-v5.c
> > b/arch/arm64/kvm/vgic/vgic-v5.c
> > index 0f269321ece4b..75372bbfb6a6a 100644
> > --- a/arch/arm64/kvm/vgic/vgic-v5.c
> > +++ b/arch/arm64/kvm/vgic/vgic-v5.c
> > @@ -238,7 +238,7 @@ static u32
> > vgic_v5_get_effective_priority_mask(struct kvm_vcpu *vcpu)
> > */
> > priority_mask = FIELD_GET(FEAT_GCIE_ICH_VMCR_EL2_VPMR,
> > cpu_if->vgic_vmcr);
> >
> > - return min(highest_ap, priority_mask + 1);
> > + return min(highest_ap, priority_mask);
>
> Hi Marc,
>
> This part of your change (dropping the `- 1`) is not correct for GICv5.
> The GICv[23] PMR works differently to the GICv5 PCR.
>
> For GICv[23] the mask is exclusive, i.e., only higher priority (lower
> numerical value) interrupts are of sufficient priority to be signalled.
>
> For GICv5, the priority of an interrupt can be equal to or higher than
> (numerically lower than) the mask. See DMSQKF in the GICv5 spec:
>
> A physical interrupt has Sufficient priority to be signaled when all of
> the following are true:
> * The priority of the interrupt is higher than the physical running
> priority for the Physical Interrupt Domain.
> * The priority of the interrupt is equal to or higher than the
> Physical Priority Mask for the Physical Interrupt Domain.
>
> Therefore, we require this `+ 1` for the priority_mask in order to allow
> us to combine the active priority and priority mask. Else, they operate on
> different scales.
>
> I'd tried to explain this in a comment that lies just outside the diff,
> but hadn't explicitly called out that GICv5 operates differently to
> GICv[23] in this regard. Apologies.
Nothing to apologise about, this is me not being able to read.
>
> > }
> >
> > /*
> > @@ -367,7 +367,7 @@ bool vgic_v5_has_pending_ppi(struct kvm_vcpu
> > *vcpu)
> >
> > scoped_guard(raw_spinlock_irqsave, &irq->irq_lock)
> > has_pending = (irq->enabled &&
> > irq_is_pending(irq) &&
> > - irq->priority <=
> > priority_mask);
> > + irq->priority <
> > priority_mask);
>
> I agree that this was wrong and should never have included the
> equality. This was definitely a bug!
Cool. I'll revert the revert of the first hunk and keep the second
one.
Thanks!
M.
--
Without deviation from the norm, progress is not possible.
^ permalink raw reply
* [PATCH] dt-bindings: arm: arm,vexpress-scc: convert to DT schema
From: Khushal Chitturi @ 2026-03-31 17:29 UTC (permalink / raw)
To: robh, krzk+dt, conor+dt, liviu.dudau, sudeep.holla, lpieralisi,
pawel.moll
Cc: devicetree, linux-arm-kernel, linux-kernel, Khushal Chitturi
Convert the ARM Versatile Express Serial Configuration Controller
bindings to DT schema.
Signed-off-by: Khushal Chitturi <khushalchitturi@gmail.com>
---
Note:
* This patch is part of the GSoC2026 application process for device tree bindings conversions
* https://github.com/LinuxFoundationGSoC/ProjectIdeas/wiki/GSoC-2026-Device-Tree-Bindings
.../bindings/arm/arm,vexpress-scc.yaml | 51 +++++++++++++++++++
.../devicetree/bindings/arm/vexpress-scc.txt | 33 ------------
2 files changed, 51 insertions(+), 33 deletions(-)
create mode 100644 Documentation/devicetree/bindings/arm/arm,vexpress-scc.yaml
delete mode 100644 Documentation/devicetree/bindings/arm/vexpress-scc.txt
diff --git a/Documentation/devicetree/bindings/arm/arm,vexpress-scc.yaml b/Documentation/devicetree/bindings/arm/arm,vexpress-scc.yaml
new file mode 100644
index 000000000000..7870410211a0
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/arm,vexpress-scc.yaml
@@ -0,0 +1,51 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/arm/arm,vexpress-scc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: ARM Versatile Express Serial Configuration Controller
+
+maintainers:
+ - Pawel Moll <pawel.moll@arm.com>
+
+description: |
+ Test chips for ARM Versatile Express platform implement SCC (Serial
+ Configuration Controller) interface, used to set initial conditions
+ for the test chip.
+
+ In some cases its registers are also mapped in normal address space
+ and can be used to obtain runtime information about the chip internals
+ (like silicon temperature sensors) and as interface to other subsystems
+ like platform configuration control and power management.
+
+properties:
+ compatible:
+ items:
+ - pattern: "^arm,vexpress-scc,[a-z0-9_-]+$"
+ - const: arm,vexpress-scc
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+required:
+ - compatible
+
+additionalProperties: false
+
+examples:
+ - |
+ bus {
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ scc@7fff0000 {
+ compatible = "arm,vexpress-scc,v2p-ca15_a7", "arm,vexpress-scc";
+ reg = <0 0x7fff0000 0 0x1000>;
+ interrupts = <0 95 4>;
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/arm/vexpress-scc.txt b/Documentation/devicetree/bindings/arm/vexpress-scc.txt
deleted file mode 100644
index ae5043e42e5d..000000000000
--- a/Documentation/devicetree/bindings/arm/vexpress-scc.txt
+++ /dev/null
@@ -1,33 +0,0 @@
-ARM Versatile Express Serial Configuration Controller
------------------------------------------------------
-
-Test chips for ARM Versatile Express platform implement SCC (Serial
-Configuration Controller) interface, used to set initial conditions
-for the test chip.
-
-In some cases its registers are also mapped in normal address space
-and can be used to obtain runtime information about the chip internals
-(like silicon temperature sensors) and as interface to other subsystems
-like platform configuration control and power management.
-
-Required properties:
-
-- compatible value: "arm,vexpress-scc,<model>", "arm,vexpress-scc";
- where <model> is the full tile model name (as used
- in the tile's Technical Reference Manual),
- eg. for Coretile Express A15x2 A7x3 (V2P-CA15_A7):
- compatible = "arm,vexpress-scc,v2p-ca15_a7", "arm,vexpress-scc";
-
-Optional properties:
-
-- reg: when the SCC is memory mapped, physical address and size of the
- registers window
-- interrupts: when the SCC can generate a system-level interrupt
-
-Example:
-
- scc@7fff0000 {
- compatible = "arm,vexpress-scc,v2p-ca15_a7", "arm,vexpress-scc";
- reg = <0 0x7fff0000 0 0x1000>;
- interrupts = <0 95 4>;
- };
--
2.53.0
^ permalink raw reply related
* Re: [PATCH v4 0/8] Bluetooth: Add MediaTek MT7927 (MT6639) support
From: Luiz Augusto von Dentz @ 2026-03-31 17:31 UTC (permalink / raw)
To: Javier Tia
Cc: Marcel Holtmann, Matthias Brugger, AngeloGioacchino Del Regno,
linux-bluetooth, linux-kernel, linux-arm-kernel, linux-mediatek,
Ryan Gilbert, Jose Tiburcio Ribeiro Netto, Llewellyn Curran,
Chapuis Dario, Evgeny Kapusta, Nitin Gurram, Thibaut FRANCOIS,
Ivan Lubnin
In-Reply-To: <20260331171043.F1C481EA006B@mailuser.phl.internal>
Hi Javier,
On Tue, Mar 31, 2026 at 1:10 PM Javier Tia <floss@jetm.me> wrote:
>
> Hi Luiz,
>
> On Tue, 31 Mar 2026 Luiz Augusto von Dentz wrote:
> > Ok, but on 8/8 it seem to suggest the problem still exists which
> > trigger the following review:
> >
> > https://sashiko.dev/#/patchset/20260330-mt7927-bt-support-v4-0-cecc025e7062%40jetm.me
> >
> > Perhaps we should ajust the commit description if the 19 seconds
> > doesn't really occurs when 2/8 is applied.
>
> Good catch. The ~19 second delay is indeed fixed by patch 2/8, so the
> note in 8/8 was misleading as written.
>
> I've updated the commit message in 8/8 to clarify:
>
> Note: boards with this USB ID expose only one ISO alternate setting
> (alt 0). Without the fix in patch 2/8 ("btmtk: fix ISO interface
> setup for single alt setting"), this caused ~19 second initialization
> delays. With the fix applied, initialization completes in ~2.6
> seconds.
>
> This is addressed in v5:
> https://lore.kernel.org/linux-bluetooth/20260331-mt7927-bt-support-v5-0-6f31b4342daa@jetm.me/
I've already pushed v4 with the 19 seconds comments removed.
> Best,
> Javier
--
Luiz Augusto von Dentz
^ permalink raw reply
* Re: [PATCH v20 04/10] firmware: psci: Introduce command-based reset in psci_sys_reset
From: Shivendra Pratap @ 2026-03-31 17:38 UTC (permalink / raw)
To: Lorenzo Pieralisi
Cc: Arnd Bergmann, Bjorn Andersson, Sebastian Reichel, Rob Herring,
Souvik Chakravarty, Krzysztof Kozlowski, Andy Yan,
Matthias Brugger, Mark Rutland, Conor Dooley, Konrad Dybcio,
John Stultz, Moritz Fischer, Bartosz Golaszewski, Sudeep Holla,
Florian Fainelli, Krzysztof Kozlowski, Dmitry Baryshkov,
Mukesh Ojha, Andre Draszik, Kathiravan Thirumoorthy, linux-pm,
linux-kernel, linux-arm-kernel, linux-arm-msm, devicetree,
Srinivas Kandagatla
In-Reply-To: <acaPCJnX6lb9lxPy@lpieralisi>
On 27-03-2026 19:37, Lorenzo Pieralisi wrote:
> On Wed, Mar 04, 2026 at 11:33:04PM +0530, Shivendra Pratap wrote:
>> PSCI currently supports only COLD reset and ARCH WARM reset based on the
>> Linux reboot_mode variable. The PSCI specification now includes
>> SYSTEM_RESET2 for vendor-specific resets, but there's no mechanism to
>> issue these through psci_sys_reset.
>>
>> Add a command-based reset mechanism that allows external drivers to set
>> the psci reset command via a new psci_set_reset_cmd() function.
>>
>> The psci command-based reset is disabled by default and the
>> psci_sys_reset follows its original flow until a psci_reset command is
>> set. In kernel panic path, psci_reset command is ignored.
>
> If it is function calls you should add parenthesis (eg psci_sys_reset ->
> psci_sys_reset()).
>
> You must explain why the kernel panic path requires separate handling
> here AND in the code - think about looking at this years down the line
> and figure out why kernel panics are special here.
Ack.
>
>> Signed-off-by: Shivendra Pratap <shivendra.pratap@oss.qualcomm.com>
>> ---
>> drivers/firmware/psci/psci.c | 45 ++++++++++++++++++++++++++++++++++++++++++--
>> include/linux/psci.h | 2 ++
>> 2 files changed, 45 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/firmware/psci/psci.c b/drivers/firmware/psci/psci.c
>> index 38ca190d4a22d6e7e0f06420e8478a2b0ec2fe6f..ae6f7a0aead913d740070080d4b2a3da15b29485 100644
>> --- a/drivers/firmware/psci/psci.c
>> +++ b/drivers/firmware/psci/psci.c
>> @@ -51,6 +51,15 @@ static int resident_cpu = -1;
>> struct psci_operations psci_ops;
>> static enum arm_smccc_conduit psci_conduit = SMCCC_CONDUIT_NONE;
>>
>> +struct psci_sys_reset_params {
>> + u32 system_reset;
>> + u32 reset_type;
>> + u32 cookie;
>> + bool cmd;
>> +};
>> +
>> +static struct psci_sys_reset_params psci_reset;
>> +
>> bool psci_tos_resident_on(int cpu)
>> {
>> return cpu == resident_cpu;
>> @@ -80,6 +89,28 @@ static u32 psci_cpu_suspend_feature;
>> static bool psci_system_reset2_supported;
>> static bool psci_system_off2_hibernate_supported;
>>
>> +/**
>> + * psci_set_reset_cmd - Sets the psci_reset_cmd for command-based
>> + * reset which will be used in psci_sys_reset call.
>> + *
>> + * @cmd_sys_rst2: Set to true for SYSTEM_RESET2 based resets.
>> + * @cmd_reset_type: Set the reset_type argument for psci_sys_reset.
>> + * @cmd_cookie: Set the cookie argument for psci_sys_reset.
>> + */
>> +void psci_set_reset_cmd(bool cmd_sys_rst2, u32 cmd_reset_type, u32 cmd_cookie)
>> +{
>
> I don't think cmd_sys_rst2 is needed, as a replied in a different thread.
Need bit more clarification. The issue is that at some point we need to
decide - sys_rst2 or the reboot_mode based reset. Are you suggesting
that this check should be in psci driver instead of a pre-check in
psci_reboot_mode driver?
>
>> + if (cmd_sys_rst2 && psci_system_reset2_supported) {
>> + psci_reset.system_reset = PSCI_FN_NATIVE(1_1, SYSTEM_RESET2);
>> + psci_reset.reset_type = cmd_reset_type;
>> + psci_reset.cookie = cmd_cookie;
>> + } else {
>> + psci_reset.system_reset = PSCI_0_2_FN_SYSTEM_RESET;
>> + psci_reset.reset_type = 0;
>> + psci_reset.cookie = 0;
>> + }
>> + psci_reset.cmd = true;
>> +}
>> +
>> static inline bool psci_has_ext_power_state(void)
>> {
>> return psci_cpu_suspend_feature &
>> @@ -309,14 +340,24 @@ static int get_set_conduit_method(const struct device_node *np)
>> static int psci_sys_reset(struct notifier_block *nb, unsigned long action,
>> void *data)
>> {
>> - if ((reboot_mode == REBOOT_WARM || reboot_mode == REBOOT_SOFT) &&
>> - psci_system_reset2_supported) {
>> + if (((reboot_mode == REBOOT_WARM || reboot_mode == REBOOT_SOFT) &&
>> + psci_system_reset2_supported) && (panic_in_progress() || !psci_reset.cmd)) {
>> /*
>> * reset_type[31] = 0 (architectural)
>> * reset_type[30:0] = 0 (SYSTEM_WARM_RESET)
>> * cookie = 0 (ignored by the implementation)
>> */
>> invoke_psci_fn(PSCI_FN_NATIVE(1_1, SYSTEM_RESET2), 0, 0, 0);
>> + } else if (!panic_in_progress() && psci_reset.cmd) {
>> + /*
>> + * Commands are being set in psci_set_reset_cmd
>> + * This issues, SYSTEM_RESET2 arch warm reset or
>> + * SYSTEM_RESET2 vendor-specific reset or
>> + * a SYSTEM_RESET cold reset in accordance with
>> + * the reboot-mode command.
>> + */
>> + invoke_psci_fn(psci_reset.system_reset, psci_reset.reset_type,
>> + psci_reset.cookie, 0);
>> } else {
>> invoke_psci_fn(PSCI_0_2_FN_SYSTEM_RESET, 0, 0, 0);
>
> This is very hard to parse. IMO, what you should do is:
>
> - Split this into two different paths: reboot_mode vs psci_reset.cmd == true.
> - Document very clearly why a panic needs separate handling.
>
> Something like:
>
> if (psci_reset.cmd)
> handle_reset_cmd();
> else
> handle_reboot_mode();
>
> I don't think we are far from converging but I want to be able to maintain
> this code going forward.
Ack. Will restructure it as suggested.
thanks,
Shivendra
^ permalink raw reply
* Re: [PATCH v20 06/10] power: reset: Add psci-reboot-mode driver
From: Shivendra Pratap @ 2026-03-31 17:40 UTC (permalink / raw)
To: Lorenzo Pieralisi
Cc: Arnd Bergmann, Bjorn Andersson, Sebastian Reichel, Rob Herring,
Souvik Chakravarty, Krzysztof Kozlowski, Andy Yan,
Matthias Brugger, Mark Rutland, Conor Dooley, Konrad Dybcio,
John Stultz, Moritz Fischer, Bartosz Golaszewski, Sudeep Holla,
Florian Fainelli, Krzysztof Kozlowski, Dmitry Baryshkov,
Mukesh Ojha, Andre Draszik, Kathiravan Thirumoorthy, linux-pm,
linux-kernel, linux-arm-kernel, linux-arm-msm, devicetree,
Srinivas Kandagatla
In-Reply-To: <acaQzmVhO50oAbbE@lpieralisi>
On 27-03-2026 19:44, Lorenzo Pieralisi wrote:
> On Wed, Mar 04, 2026 at 11:33:06PM +0530, Shivendra Pratap wrote:
>> PSCI supports different types of resets like COLD reset, ARCH WARM
>> reset, vendor-specific resets. Currently there is no common driver that
>> handles all supported psci resets at one place. Additionally, there is
>> no common mechanism to issue the supported psci resets from userspace.
>>
>> Add a PSCI reboot mode driver and define two types of PSCI resets in the
>> driver as reboot-modes: predefined resets controlled by Linux
>> reboot_mode and customizable resets defined by SoC vendors in their
>> device tree under the psci:reboot-mode node.
>>
>> Register the driver with the reboot-mode framework to interface these
>> resets to userspace. When userspace initiates a supported command, pass
>> the reset arguments to the PSCI driver to enable command-based reset.
>>
>> This change allows userspace to issue supported PSCI reset commands
>> using the standard reboot system calls while enabling SoC vendors to
>> define their specific resets for PSCI.
>>
>> Signed-off-by: Shivendra Pratap <shivendra.pratap@oss.qualcomm.com>
>> ---
>> drivers/power/reset/Kconfig | 10 +++
>> drivers/power/reset/Makefile | 1 +
>> drivers/power/reset/psci-reboot-mode.c | 119 +++++++++++++++++++++++++++++++++
>
> Add an entry into MAINTAINERS.POWER STATE COORDINATION INTERFACE for this
> specific file because I'd like to keep an eye on it, if you don't mind.
>
> Creating a MAINTAINER entry just for this seems overkill to me, it
> does not look like it is done for other reboot mode drivers.
Ack.
thanks,
Shivendra
^ permalink raw reply
* Re: [PATCH v13 10/48] arm64: RMI: Ensure that the RMM has GPT entries for memory
From: Mathieu Poirier @ 2026-03-31 17:43 UTC (permalink / raw)
To: Suzuki K Poulose
Cc: Steven Price, 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,
Gavin Shan, Shanker Donthineni, Alper Gun, Aneesh Kumar K . V,
Emi Kisanuki, Vishal Annapurve
In-Reply-To: <152f5070-fda6-4381-bc40-4a70908c27c1@arm.com>
On Tue, Mar 31, 2026 at 12:05:47PM +0100, Suzuki K Poulose wrote:
> Hi Mathieu,
>
> On 30/03/2026 21:58, Mathieu Poirier wrote:
> > Hi,
> >
> > On Wed, Mar 18, 2026 at 03:53:34PM +0000, Steven Price wrote:
> > > The RMM may not be tracking all the memory of the system at boot. Create
> > > the necessary tracking state and GPTs within the RMM so that all boot
> > > memory can be delegated to the RMM as needed during runtime.
> > >
> > > Note: support is currently missing for SROs which means that if the RMM
> > > needs memory donating this will fail (and render CCA unusable in Linux).
> > >
> > > Signed-off-by: Steven Price <steven.price@arm.com>
> > > ---
> > > New patch for v13
> > > ---
> > > arch/arm64/kvm/rmi.c | 89 ++++++++++++++++++++++++++++++++++++++++++++
> > > 1 file changed, 89 insertions(+)
> > >
> > > diff --git a/arch/arm64/kvm/rmi.c b/arch/arm64/kvm/rmi.c
> > > index 9590dff9a2c1..80aedc85e94a 100644
> > > --- a/arch/arm64/kvm/rmi.c
> > > +++ b/arch/arm64/kvm/rmi.c
> > > @@ -4,6 +4,7 @@
> > > */
> > > #include <linux/kvm_host.h>
> > > +#include <linux/memblock.h>
> > > #include <asm/kvm_pgtable.h>
> > > #include <asm/rmi_cmds.h>
> > > @@ -56,6 +57,18 @@ static int rmi_check_version(void)
> > > return 0;
> > > }
> > > +/*
> > > + * These are the 'default' sizes when passing 0 as the tracking_region_size.
> > > + * TODO: Support other granule sizes
> > > + */
> > > +#ifdef CONFIG_PAGE_SIZE_4KB
> > > +#define RMM_GRANULE_TRACKING_SIZE SZ_1G
> > > +#elif defined(CONFIG_PAGE_SIZE_16KB)
> > > +#define RMM_GRANULE_TRACKING_SIZE SZ_32M
> > > +#elif defined(CONFIG_PAGE_SIZE_64KB)
> > > +#define RMM_GRANULE_TRACKING_SIZE SZ_512M
> > > +#endif
> > > +
> > > static int rmi_configure(void)
> > > {
> > > struct rmm_config *config __free(free_page) = NULL;
> > > @@ -95,6 +108,80 @@ static int rmi_configure(void)
> > > return 0;
> > > }
> > > +static int rmi_verify_memory_tracking(phys_addr_t start, phys_addr_t end)
> > > +{
> > > + start = ALIGN_DOWN(start, RMM_GRANULE_TRACKING_SIZE);
> >
> > This will produce an error on systems where the start of system memory is not
> > aligned to RMM_GRANULE_TRACKING_SIZE. For instance, on QEMU-SBSA the system
> > memory starts at 0x100_4300_0000. With the above and RMM_GRANULE_TRACKING_SIZE
> > set to SZ_1G, @start becomes 0x100_4000_0000, which falls outside the memory map
> > known to the TF-A. I fixed it with these modifications:
>
> Thanks for raising this. This would need to be addressed in the RMM
> spec, I have raised it with the team and will be addressed soon.
>
> >
> > LINUX:
> >
> > diff --git a/arch/arm64/kvm/rmi.c b/arch/arm64/kvm/rmi.c
> > index 10ff1c3bddaf..21bfbbe2f047 100644
> > --- a/arch/arm64/kvm/rmi.c
> > +++ b/arch/arm64/kvm/rmi.c
> > @@ -424,7 +424,9 @@ static int rmi_configure(void)
> > static int rmi_verify_memory_tracking(phys_addr_t start, phys_addr_t end)
> > {
> > - start = ALIGN_DOWN(start, RMM_GRANULE_TRACKING_SIZE);
> > + phys_addr_t offset;
> > +
> > + offset = start - ALIGN_DOWN(start, RMM_GRANULE_TRACKING_SIZE);
> > end = ALIGN(end, RMM_GRANULE_TRACKING_SIZE);
> > while (start < end) {
> > @@ -439,7 +441,13 @@ static int rmi_verify_memory_tracking(phys_addr_t start, phys_addr_t end)
> > start);
> > return -ENODEV;
> > }
> > - start += RMM_GRANULE_TRACKING_SIZE;
> > +
> > + if (offset) {
> > + start += (RMM_GRANULE_TRACKING_SIZE - offset);
> > + offset = 0;
> > + } else {
> > + start += RMM_GRANULE_TRACKING_SIZE;
> > + }
> > }
> > return 0;
> >
> > RMM:
> >
> > diff --git a/runtime/rmi/granule.c b/runtime/rmi/granule.c
> > index cef521fc0869..60358d9ee81e 100644
> > --- a/runtime/rmi/granule.c
> > +++ b/runtime/rmi/granule.c
> > @@ -209,9 +209,11 @@ void smc_granule_tracking_get(unsigned long addr,
> > return;
> > }
> > +#if 0
> > if (!ALIGNED(addr, RMM_INTERNAL_TRACKING_REGION_SIZE)) {
> > return;
> > }
> > +#endif
> > g = find_granule(addr);
> > if (g != NULL) {
> >
> > This is likely not the right fix but hopefully provides some guidance. Send me
> > your patches when you have an idea and I'll test them.
>
> We will send you the update once it is fixed in the RMM spec. The rough idea
> is to remove the ALIGNMENT restrictions and return a Range that
> the host can iterate over to find "regions" with the same type of
> memory.
>
Ok, thanks for looking into this.
>
> Cheers
> Suzuki
>
>
> >
> > Thanks,
> > Mathieu
> >
> >
> > > + end = ALIGN(end, RMM_GRANULE_TRACKING_SIZE);
> > > +
> > > + while (start < end) {
> > > + unsigned long ret, category, state;
> > > +
> > > + ret = rmi_granule_tracking_get(start, &category, &state);
> > > + if (ret != RMI_SUCCESS ||
> > > + state != RMI_TRACKING_FINE ||
> > > + category != RMI_MEM_CATEGORY_CONVENTIONAL) {
> > > + /* TODO: Set granule tracking in this case */
> > > + kvm_err("Granule tracking for region isn't fine/conventional: %llx",
> > > + start);
> > > + return -ENODEV;
> > > + }
> > > + start += RMM_GRANULE_TRACKING_SIZE;
> > > + }
> > > +
> > > + return 0;
> > > +}
> > > +
> > > +static unsigned long rmi_l0gpt_size(void)
> > > +{
> > > + return 1UL << (30 + FIELD_GET(RMI_FEATURE_REGISTER_1_L0GPTSZ,
> > > + rmm_feat_reg1));
> > > +}
> > > +
> > > +static int rmi_create_gpts(phys_addr_t start, phys_addr_t end)
> > > +{
> > > + unsigned long l0gpt_sz = rmi_l0gpt_size();
> > > +
> > > + start = ALIGN_DOWN(start, l0gpt_sz);
> > > + end = ALIGN(end, l0gpt_sz);
> > > +
> > > + while (start < end) {
> > > + int ret = rmi_gpt_l1_create(start);
> > > +
> > > + if (ret && ret != RMI_ERROR_GPT) {
> > > + /*
> > > + * FIXME: Handle SRO so that memory can be donated for
> > > + * the tables.
> > > + */
> > > + kvm_err("GPT Level1 table missing for %llx\n", start);
> > > + return -ENOMEM;
> > > + }
> > > + start += l0gpt_sz;
> > > + }
> > > +
> > > + return 0;
> > > +}
> > > +
> > > +static int rmi_init_metadata(void)
> > > +{
> > > + phys_addr_t start, end;
> > > + const struct memblock_region *r;
> > > +
> > > + for_each_mem_region(r) {
> > > + int ret;
> > > +
> > > + start = memblock_region_memory_base_pfn(r) << PAGE_SHIFT;
> > > + end = memblock_region_memory_end_pfn(r) << PAGE_SHIFT;
> > > + ret = rmi_verify_memory_tracking(start, end);
> > > + if (ret)
> > > + return ret;
> > > + ret = rmi_create_gpts(start, end);
> > > + if (ret)
> > > + return ret;
> > > + }
> > > +
> > > + return 0;
> > > +}
> > > +
> > > static int rmm_check_features(void)
> > > {
> > > if (kvm_lpa2_is_enabled() && !rmi_has_feature(RMI_FEATURE_REGISTER_0_LPA2)) {
> > > @@ -120,6 +207,8 @@ void kvm_init_rmi(void)
> > > return;
> > > if (rmi_configure())
> > > return;
> > > + if (rmi_init_metadata())
> > > + return;
> > > /* Future patch will enable static branch kvm_rmi_is_available */
> > > }
> > > --
> > > 2.43.0
> > >
> > >
>
^ permalink raw reply
* Re: [PATCH v4 7/9] regulator: Add MediaTek MT6392 regulator
From: kernel test robot @ 2026-03-31 17:55 UTC (permalink / raw)
To: Luca Leonardo Scorcia, linux-mediatek
Cc: oe-kbuild-all, Fabien Parent, Val Packett, Luca Leonardo Scorcia,
AngeloGioacchino Del Regno, Dmitry Torokhov, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Sen Chu, Sean Wang,
Macpaul Lin, Lee Jones, Matthias Brugger, Linus Walleij,
Liam Girdwood, Mark Brown, Julien Massot, Louis-Alexis Eyraud,
Gary Bisson, Chen Zhong, linux-input, devicetree, linux-kernel,
linux-pm, linux-arm-kernel, linux-gpio
In-Reply-To: <20260330083429.359819-8-l.scorcia@gmail.com>
Hi Luca,
kernel test robot noticed the following build warnings:
[auto build test WARNING on lee-mfd/for-mfd-next]
[also build test WARNING on broonie-regulator/for-next linusw-pinctrl/devel linusw-pinctrl/for-next lee-mfd/for-mfd-fixes linus/master v7.0-rc6 next-20260330]
[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/Luca-Leonardo-Scorcia/dt-bindings-mfd-mt6397-Add-MT6392-PMIC/20260331-081127
base: https://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd.git for-mfd-next
patch link: https://lore.kernel.org/r/20260330083429.359819-8-l.scorcia%40gmail.com
patch subject: [PATCH v4 7/9] regulator: Add MediaTek MT6392 regulator
config: sh-allmodconfig (https://download.01.org/0day-ci/archive/20260401/202604010103.FzAGRPye-lkp@intel.com/config)
compiler: sh4-linux-gcc (GCC) 15.2.0
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20260401/202604010103.FzAGRPye-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/202604010103.FzAGRPye-lkp@intel.com/
All warnings (new ones prefixed by >>):
>> drivers/regulator/mt6392-regulator.c:181:18: warning: 'ldo_volt_table1b' defined but not used [-Wunused-const-variable=]
181 | static const u32 ldo_volt_table1b[] = {
| ^~~~~~~~~~~~~~~~
vim +/ldo_volt_table1b +181 drivers/regulator/mt6392-regulator.c
180
> 181 static const u32 ldo_volt_table1b[] = {
182 1500000, 1800000, 2500000, 2800000,
183 };
184
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* Re: [PATCH v15 1/5] ring-buffer: Flush and stop persistent ring buffer on panic
From: Catalin Marinas @ 2026-03-31 17:57 UTC (permalink / raw)
To: Masami Hiramatsu (Google)
Cc: Steven Rostedt, Will Deacon, Mathieu Desnoyers, linux-kernel,
linux-trace-kernel, Ian Rogers, linux-arm-kernel, Robin Murphy
In-Reply-To: <177494616630.71933.2941681397188791689.stgit@mhiramat.tok.corp.google.com>
On Tue, Mar 31, 2026 at 05:36:06PM +0900, Masami Hiramatsu (Google) wrote:
> From: Masami Hiramatsu (Google) <mhiramat@kernel.org>
>
> On real hardware, panic and machine reboot may not flush hardware cache
> to memory. This means the persistent ring buffer, which relies on a
> coherent state of memory, may not have its events written to the buffer
> and they may be lost. Moreover, there may be inconsistency with the
> counters which are used for validation of the integrity of the
> persistent ring buffer which may cause all data to be discarded.
>
> To avoid this issue, stop recording of the ring buffer on panic and
> flush the cache of the ring buffer's memory.
>
> Fixes: e645535a954a ("tracing: Add option to use memmapped memory for trace boot instance")
> Cc: stable@vger.kernel.org
> Signed-off-by: Masami Hiramatsu (Google) <mhiramat@kernel.org>
[...]
> diff --git a/arch/arm64/include/asm/ring_buffer.h b/arch/arm64/include/asm/ring_buffer.h
> new file mode 100644
> index 000000000000..62316c406888
> --- /dev/null
> +++ b/arch/arm64/include/asm/ring_buffer.h
> @@ -0,0 +1,10 @@
> +/* SPDX-License-Identifier: GPL-2.0-only */
> +#ifndef _ASM_ARM64_RING_BUFFER_H
> +#define _ASM_ARM64_RING_BUFFER_H
> +
> +#include <asm/cacheflush.h>
> +
> +/* Flush D-cache on persistent ring buffer */
> +#define arch_ring_buffer_flush_range(start, end) dcache_clean_pop(start, end)
> +
> +#endif /* _ASM_ARM64_RING_BUFFER_H */
Adding Robin as he wrote the pmem support for arm64.
I assume the ring buffer here is cacheable memory, otherwise we'd also
need a dmb(osh) as in arch_wb_cache_pmem(). If that's correct:
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
^ permalink raw reply
* Re: [PATCH v20 06/10] power: reset: Add psci-reboot-mode driver
From: Shivendra Pratap @ 2026-03-31 18:00 UTC (permalink / raw)
To: Lorenzo Pieralisi
Cc: Arnd Bergmann, Bjorn Andersson, Sebastian Reichel, Rob Herring,
Souvik Chakravarty, Krzysztof Kozlowski, Andy Yan,
Matthias Brugger, Mark Rutland, Conor Dooley, Konrad Dybcio,
John Stultz, Moritz Fischer, Bartosz Golaszewski, Sudeep Holla,
Florian Fainelli, Krzysztof Kozlowski, Dmitry Baryshkov,
Mukesh Ojha, Andre Draszik, Kathiravan Thirumoorthy, linux-pm,
linux-kernel, linux-arm-kernel, linux-arm-msm, devicetree,
Srinivas Kandagatla
In-Reply-To: <acaMPgRALnoUIHMC@lpieralisi>
On 27-03-2026 19:25, Lorenzo Pieralisi wrote:
> On Wed, Mar 04, 2026 at 11:33:06PM +0530, Shivendra Pratap wrote:
>> PSCI supports different types of resets like COLD reset, ARCH WARM
>> reset, vendor-specific resets. Currently there is no common driver that
>> handles all supported psci resets at one place. Additionally, there is
>> no common mechanism to issue the supported psci resets from userspace.
>>
>> Add a PSCI reboot mode driver and define two types of PSCI resets in the
>> driver as reboot-modes: predefined resets controlled by Linux
>> reboot_mode and customizable resets defined by SoC vendors in their
>> device tree under the psci:reboot-mode node.
>>
>> Register the driver with the reboot-mode framework to interface these
>> resets to userspace. When userspace initiates a supported command, pass
>> the reset arguments to the PSCI driver to enable command-based reset.
>>
>> This change allows userspace to issue supported PSCI reset commands
>> using the standard reboot system calls while enabling SoC vendors to
>> define their specific resets for PSCI.
>>
>> Signed-off-by: Shivendra Pratap <shivendra.pratap@oss.qualcomm.com>
>> ---
>> drivers/power/reset/Kconfig | 10 +++
>> drivers/power/reset/Makefile | 1 +
>> drivers/power/reset/psci-reboot-mode.c | 119 +++++++++++++++++++++++++++++++++
>> 3 files changed, 130 insertions(+)
>>
>> diff --git a/drivers/power/reset/Kconfig b/drivers/power/reset/Kconfig
>> index f6c1bcbb57deff3568d6b1b326454add3b3bbf06..529d6c7d3555601f7b7e6199acd29838030fcef2 100644
>> --- a/drivers/power/reset/Kconfig
>> +++ b/drivers/power/reset/Kconfig
>> @@ -348,6 +348,16 @@ config NVMEM_REBOOT_MODE
>> then the bootloader can read it and take different
>> action according to the mode.
>>
>> +config PSCI_REBOOT_MODE
>> + bool "PSCI reboot mode driver"
>> + depends on OF && ARM_PSCI_FW
>> + select REBOOT_MODE
>> + help
>> + Say y here will enable PSCI reboot mode driver. This gets
>> + the PSCI reboot mode arguments and passes them to psci
>> + driver. psci driver uses these arguments for issuing
>> + device reset into different boot states.
>> +
>> config POWER_MLXBF
>> tristate "Mellanox BlueField power handling driver"
>> depends on (GPIO_MLXBF2 || GPIO_MLXBF3) && ACPI
>> diff --git a/drivers/power/reset/Makefile b/drivers/power/reset/Makefile
>> index 0e4ae6f6b5c55729cf60846d47e6fe0fec24f3cc..49774b42cdf61fd57a5b70f286c65c9d66bbc0cb 100644
>> --- a/drivers/power/reset/Makefile
>> +++ b/drivers/power/reset/Makefile
>> @@ -40,4 +40,5 @@ obj-$(CONFIG_REBOOT_MODE) += reboot-mode.o
>> obj-$(CONFIG_SYSCON_REBOOT_MODE) += syscon-reboot-mode.o
>> obj-$(CONFIG_POWER_RESET_SC27XX) += sc27xx-poweroff.o
>> obj-$(CONFIG_NVMEM_REBOOT_MODE) += nvmem-reboot-mode.o
>> +obj-$(CONFIG_PSCI_REBOOT_MODE) += psci-reboot-mode.o
>> obj-$(CONFIG_POWER_MLXBF) += pwr-mlxbf.o
>> diff --git a/drivers/power/reset/psci-reboot-mode.c b/drivers/power/reset/psci-reboot-mode.c
>> new file mode 100644
>> index 0000000000000000000000000000000000000000..86bef195228b0924704c2936b99f6801c14ff1b1
>> --- /dev/null
>> +++ b/drivers/power/reset/psci-reboot-mode.c
>> @@ -0,0 +1,119 @@
>> +// SPDX-License-Identifier: GPL-2.0-only
>> +/*
>> + * Copyright (c) Qualcomm Technologies, Inc. and/or its subsidiaries.
>> + */
>> +
>> +#include <linux/device/faux.h>
>> +#include <linux/device.h>
>
> Nit: swap the two.
Ack. thanks.
>> +#include <linux/err.h>
>> +#include <linux/of.h>
>> +#include <linux/psci.h>
>> +#include <linux/reboot.h>
>> +#include <linux/reboot-mode.h>
>> +#include <linux/types.h>
>> +
>> +/*
>> + * Predefined reboot-modes are defined as per the values
>> + * of enum reboot_mode defined in the kernel: reboot.c.
>> + */
>> +static struct mode_info psci_resets[] = {
>> + { .mode = "warm", .magic = REBOOT_WARM},
>> + { .mode = "soft", .magic = REBOOT_SOFT},
>> + { .mode = "cold", .magic = REBOOT_COLD},
>> +};
>> +
>> +static void psci_reboot_mode_set_predefined_modes(struct reboot_mode_driver *reboot)
>> +{
>> + INIT_LIST_HEAD(&reboot->predefined_modes);
>> + for (u32 i = 0; i < ARRAY_SIZE(psci_resets); i++) {
>> + /* Prepare the magic with arg1 as 0 and arg2 as per pre-defined mode */
>> + psci_resets[i].magic = REBOOT_MODE_MAGIC(0, psci_resets[i].magic);
>
> This looks weird to me, why can't we just initialize the array with the values
> directly ?
Ack. The idea was to avoid Typecasting. Will check on this.
>> + INIT_LIST_HEAD(&psci_resets[i].list);
>> + list_add_tail(&psci_resets[i].list, &reboot->predefined_modes);
>> + }
>> +}
>> +
>> +/*
>> + * arg1 is reset_type(Low 32 bit of magic).
>> + * arg2 is cookie(High 32 bit of magic).
>> + * If reset_type is 0, cookie will be used to decide the reset command.
>> + */
>> +static int psci_reboot_mode_write(struct reboot_mode_driver *reboot, u64 magic)
>> +{
>> + u32 reset_type = REBOOT_MODE_ARG1(magic);
>> + u32 cookie = REBOOT_MODE_ARG2(magic);
>> +
>> + if (reset_type == 0) {
>> + if (cookie == REBOOT_WARM || cookie == REBOOT_SOFT)
>> + psci_set_reset_cmd(true, 0, 0);
>> + else
>> + psci_set_reset_cmd(false, 0, 0);
>> + } else {
>> + psci_set_reset_cmd(true, reset_type, cookie);
>> + }
>
> I don't think that psci_set_reset_cmd() has the right interface (and this
> nested if is too complicated for my taste). All we need to pass is reset-type
> and cookie (and if the reset is one of the predefined ones, reset-type is 0
> and cookie is the REBOOT_* cookie).
>
> Then the PSCI firmware driver will take the action according to what
> resets are available.
>
> How does it sound ?
So we mean these checks will move to the psci driver? Sorry for
re-iterating the question.
>> +
>> + return NOTIFY_DONE;
>> +}
>> +
>> +static int psci_reboot_mode_register_device(struct faux_device *fdev)
>> +{
>> + struct reboot_mode_driver *reboot;
>> + int ret;
>> +
>> + reboot = devm_kzalloc(&fdev->dev, sizeof(*reboot), GFP_KERNEL);
>> + if (!reboot)
>> + return -ENOMEM;
>> +
>> + psci_reboot_mode_set_predefined_modes(reboot);
>> + reboot->write = psci_reboot_mode_write;
>> + reboot->dev = &fdev->dev;
>> +
>> + ret = devm_reboot_mode_register(&fdev->dev, reboot);
>> + if (ret) {
>> + dev_err_probe(&fdev->dev, ret, "devm_reboot_mode_register failed %d\n", ret);
>> + return ret;
>> + }
>> +
>> + return 0;
>> +}
>> +
>> +static int __init psci_reboot_mode_init(void)
>> +{
>> + struct device_node *psci_np;
>> + struct faux_device *fdev;
>> + struct device_node *np;
>> + int ret;
>> +
>> + psci_np = of_find_compatible_node(NULL, NULL, "arm,psci-1.0");
>> + if (!psci_np)
>> + return -ENODEV;
>> + /*
>> + * Look for reboot-mode in the psci node. Even if the reboot-mode
>> + * node is not defined in psci, continue to register with the
>> + * reboot-mode driver and let the dev.ofnode be set as NULL.
>> + */
>> + np = of_find_node_by_name(psci_np, "reboot-mode");
>> +
>> + fdev = faux_device_create("psci-reboot-mode", NULL, NULL);
>
> Same comment as Bartosz (have you picked up his work and working towards
> a solution) ?
Working on this via MFD. Some issue as again MFD framework does not
allows a fwnode based driver registration. Will update.
thanks,
Shivendra
^ permalink raw reply
* [PATCH 1/2] pmdomain/rockchip: skip QoS operations for idle-only domains
From: Daniel Bozeman @ 2026-03-31 18:02 UTC (permalink / raw)
To: ulf.hansson, heiko
Cc: linux-pm, linux-arm-kernel, linux-rockchip, linux-kernel,
Daniel Bozeman
Idle-only power domains (pwr_mask == 0) cannot actually be powered
on or off. rockchip_do_pmu_set_power_domain() already returns early
for these domains, but rockchip_pd_power() still attempts QoS save
and idle requests before reaching that check.
On RK3528, the idle-only domains (PD_RKVENC, PD_VO, PD_VPU) have
QoS registers that may be inaccessible when the generic power domain
framework attempts to power them off, leading to synchronous external
aborts.
Return early from rockchip_pd_power() when pwr_mask is zero, matching
the existing guard in rockchip_do_pmu_set_power_domain().
Fixes: 1fe767a56c32 ("soc: rockchip: power-domain: allow domains only handling idle requests")
Signed-off-by: Daniel Bozeman <daniel@orb.net>
---
drivers/pmdomain/rockchip/pm-domains.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/pmdomain/rockchip/pm-domains.c b/drivers/pmdomain/rockchip/pm-domains.c
index 490bbb1d1d..2eecae092a 100644
--- a/drivers/pmdomain/rockchip/pm-domains.c
+++ b/drivers/pmdomain/rockchip/pm-domains.c
@@ -640,6 +640,9 @@ static int rockchip_pd_power(struct rockchip_pm_domain *pd, bool power_on)
if (rockchip_pmu_domain_is_on(pd) == power_on)
return 0;
+ if (pd->info->pwr_mask == 0)
+ return 0;
+
ret = clk_bulk_enable(pd->num_clks, pd->clks);
if (ret < 0) {
dev_err(pmu->dev, "failed to enable clocks\n");
base-commit: bc330699801d3b4f99110365512caed5adcfaca3
--
2.43.0
^ permalink raw reply related
* [PATCH 2/2] pmdomain/rockchip: skip domains returning -EPROBE_DEFER
From: Daniel Bozeman @ 2026-03-31 18:02 UTC (permalink / raw)
To: ulf.hansson, heiko
Cc: linux-pm, linux-arm-kernel, linux-rockchip, linux-kernel,
Daniel Bozeman
In-Reply-To: <20260331180223.1682283-1-daniel@orb.net>
When iterating child nodes during probe, a single domain returning
-EPROBE_DEFER (e.g. due to clock dependencies not yet available)
causes the entire power domain controller to fail and tear down all
successfully registered domains.
This creates a window where devices in unrelated power domains that
would have registered successfully cannot access their hardware. On
RK3528, PD_GPU requires CRU clocks that may not be available yet,
but the idle-only domains (PD_RKVENC, PD_VO, PD_VPU) have no clock
requirements. When the controller fails due to PD_GPU, GPIO
controllers in PD_RKVENC become inaccessible, leading to synchronous
external aborts when GPIO-controlled regulators probe.
Skip domains that return -EPROBE_DEFER and continue registering the
rest. Skipped domains have NULL entries in the provider, causing
their consumers to receive -ENOENT and defer until available.
Fixes: 7c696693a4f5 ("soc: rockchip: power-domain: Add power domain driver")
Signed-off-by: Daniel Bozeman <daniel@orb.net>
---
drivers/pmdomain/rockchip/pm-domains.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/drivers/pmdomain/rockchip/pm-domains.c b/drivers/pmdomain/rockchip/pm-domains.c
index 2eecae092a..f42880c94f 100644
--- a/drivers/pmdomain/rockchip/pm-domains.c
+++ b/drivers/pmdomain/rockchip/pm-domains.c
@@ -1077,6 +1077,11 @@ static int rockchip_pm_domain_probe(struct platform_device *pdev)
for_each_available_child_of_node_scoped(np, node) {
error = rockchip_pm_add_one_domain(pmu, node);
if (error) {
+ if (error == -EPROBE_DEFER) {
+ dev_dbg(dev, "skipped node %pOFn, dependencies not yet available\n",
+ node);
+ continue;
+ }
dev_err(dev, "failed to handle node %pOFn: %d\n",
node, error);
goto err_out;
--
2.43.0
^ permalink raw reply related
* Re: [PATCH v15 1/5] ring-buffer: Flush and stop persistent ring buffer on panic
From: Steven Rostedt @ 2026-03-31 18:03 UTC (permalink / raw)
To: Catalin Marinas
Cc: Masami Hiramatsu (Google), Will Deacon, Mathieu Desnoyers,
linux-kernel, linux-trace-kernel, Ian Rogers, linux-arm-kernel,
Robin Murphy
In-Reply-To: <acwK-Xu-Mon2_6bT@arm.com>
On Tue, 31 Mar 2026 18:57:13 +0100
Catalin Marinas <catalin.marinas@arm.com> wrote:
> I assume the ring buffer here is cacheable memory, otherwise we'd also
> need a dmb(osh) as in arch_wb_cache_pmem(). If that's correct:
Yes, it's cacheable (I couldn't imagine the performance overhead if it
wasn't! ;-)
>
> Acked-by: Catalin Marinas <catalin.marinas@arm.com>
Thanks!
-- Steve
^ permalink raw reply
* Re: [PATCH] iommu/rockchip: fix page table allocation flags for v2 IOMMU
From: Jonas Karlman @ 2026-03-31 18:13 UTC (permalink / raw)
To: Midgy BALON
Cc: Shawn Lin, Simon Xue, iommu, joro, will, robin.murphy, heiko,
linux-arm-kernel, linux-rockchip, linux-kernel, stable
In-Reply-To: <20260331075010.1463-1-midgy971@gmail.com>
Hi Midgy,
On 3/31/2026 9:50 AM, Midgy BALON wrote:
> commit 2a7e6400f72b ("iommu: rockchip: Allocate tables from all
> available memory for IOMMU v2") removed GFP_DMA32 from
> iommu_data_ops_v2, reasoning that RK356x and RK3588 IOMMU v2 hardware
> supports up to 40-bit physical addresses for page tables. However, the
> RK3568 IOMMU page-table walker uses a 32-bit AXI bus: it cannot access
> physical addresses above 4 GB regardless of the address encoding range.
>
> On boards with more than 4 GB of RAM (e.g. 8 GB LPDDR4X), removing
> GFP_DMA32 causes two distinct failure modes:
>
> 1. Direct allocation above 4 GB: iommu_alloc_pages_sz() may return
> memory above 0x100000000. The hardware page-table walker issues a
> bus error trying to dereference those addresses, causing an IOMMU
> fault on the first DMA transaction.
>
> 2. SWIOTLB bounce-buffer poisoning: without GFP_DMA32, page tables land
> above the SWIOTLB window. dma_map_single() with DMA_BIT_MASK(32)
> then bounces them into a buffer below 4 GB. rk_dte_get_page_table()
> returns phys_to_virt() of the bounce buffer address; PTEs are written
> there; the next dma_sync_single_for_device(DMA_TO_DEVICE) copies the
> original (zero) data back over the bounce buffer, silently erasing the
> freshly written PTEs. The IOMMU faults because every PTE reads as zero.
>
> Restore GFP_DMA32 (and DMA_BIT_MASK(32)) for iommu_data_ops_v2, which
> currently only serves "rockchip,rk3568-iommu" in mainline.
>
> Tested on Radxa ROCK 3B (RK3568, 8 GB LPDDR4X):
> - MobileNetV1 via RKNN: 5.8 ms/inference (IOMMU mode)
> - YOLOv5s 640x640 via RKNN: ~57 ms/inference (IOMMU mode)
> - No IOMMU faults, correct inference results
>
> Fixes: 2a7e6400f72b ("iommu: rockchip: Allocate tables from all available memory for IOMMU v2")
> Cc: stable@vger.kernel.org
> Cc: Jonas Karlman <jonas@kwiboo.se>
> Signed-off-by: Midgy BALON <midgy971@gmail.com>
> ---
> drivers/iommu/rockchip-iommu.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/iommu/rockchip-iommu.c b/drivers/iommu/rockchip-iommu.c
> index 85f3667e797..8b45db29471 100644
> --- a/drivers/iommu/rockchip-iommu.c
> +++ b/drivers/iommu/rockchip-iommu.c
> @@ -1358,8 +1358,8 @@ static struct rk_iommu_ops iommu_data_ops_v2 = {
> .pt_address = &rk_dte_pt_address_v2,
> .mk_dtentries = &rk_mk_dte_v2,
> .mk_ptentries = &rk_mk_pte_v2,
> - .dma_bit_mask = DMA_BIT_MASK(40),
> - .gfp_flags = 0,
> + .dma_bit_mask = DMA_BIT_MASK(32),
> + .gfp_flags = GFP_DMA32,
This change is wrong because this struct describe the RK IOMMU v2 that
is capable of 40-bit addressing, used with e.g. RK3568 VOP2 MMU and MMUs
in other RK35xx SoCs.
What you have discovered is most likely that some IP blocks, e.g. NPU on
RK3568, is not capable of >32-bit addressing, and/or that such IP blocks
are still using IOMMU v1 blocks, or some variant with 32-bit limitation.
However, the RK IOMMU driver is currently not capable of supporting
different IOMMU revisions, if I recall correctly there may have been a
patch trying to address that already on ML.
Have you seen this issue with a variant of the rockit driver that add
support for RK3568 or a variant of the downstream rknpu driver forward
ported to mainline?
If your findings are correct it is likely that the NPU MMU needs to use
a different compatible, since rockchip,rk3568-iommu describe the IOMMUv2
that is capable of 40-bit addressing and is also used by other RK35xx
SoCs.
Regards,
Jonas
> };
>
> static const struct of_device_id rk_iommu_dt_ids[] = {
^ permalink raw reply
* Re: [PATCH v5 8/8] Bluetooth: btusb: Add MT7927 ID for ASUS X870E / ProArt X870E-Creator
From: Paul Menzel @ 2026-03-31 18:13 UTC (permalink / raw)
To: Javier Tia
Cc: Marcel Holtmann, Luiz Augusto von Dentz, Matthias Brugger,
AngeloGioacchino Del Regno, linux-bluetooth, linux-kernel,
linux-arm-kernel, linux-mediatek, Jose Tiburcio Ribeiro Netto,
Ivan Lubnin
In-Reply-To: <20260331-mt7927-bt-support-v5-8-6f31b4342daa@jetm.me>
Dear Javier,
Thank you for the patches and your persistence on improving them. I
noticed one more thing, just in this one:
Am 31.03.26 um 19:09 schrieb Javier Tia:
> 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 expose only one ISO alternate setting
> (alt 0). Without the fix in patch 2/8 ("btmtk: fix ISO interface
> setup for single alt setting"), this caused ~19 second initialization
> delays. With the fix applied, initialization completes in ~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 },
This is not sorted. Is there a reason to place it here?
> { USB_DEVICE(0x0489, 0xe14e), .driver_info = BTUSB_MEDIATEK |
> BTUSB_WIDEBAND_SPEECH },
> { USB_DEVICE(0x0489, 0xe14f), .driver_info = BTUSB_MEDIATEK |
>
Kind regards,
Paul
^ permalink raw reply
* Re: [PATCH v2 12/30] KVM: arm64: Hoist MTE validation check out of MMU lock path
From: Marc Zyngier @ 2026-03-31 18:28 UTC (permalink / raw)
To: Anshuman Khandual
Cc: kvmarm, linux-arm-kernel, kvm, Joey Gouly, Suzuki K Poulose,
Oliver Upton, Zenghui Yu, Fuad Tabba, Will Deacon, Quentin Perret
In-Reply-To: <8bd2b649-01b5-44f4-a034-c202e226e97c@arm.com>
On Tue, 31 Mar 2026 07:57:48 +0100,
Anshuman Khandual <anshuman.khandual@arm.com> wrote:
>
> On 27/03/26 5:06 PM, Marc Zyngier wrote:
> > From: Fuad Tabba <tabba@google.com>
> >
> > Simplify the non-cacheable attributes assignment by using a ternary
> > operator. Additionally, hoist the MTE validation check (mte_allowed) out
> > of kvm_s2_fault_map() and into kvm_s2_fault_compute_prot(). This allows
> > us to fail faster and avoid acquiring the KVM MMU lock unnecessarily
> > when the VMM introduces a disallowed VMA for an MTE-enabled guest.
> >
> > Signed-off-by: Fuad Tabba <tabba@google.com>
> > Signed-off-by: Marc Zyngier <maz@kernel.org>
> > ---
> > arch/arm64/kvm/mmu.c | 28 ++++++++++++----------------
> > 1 file changed, 12 insertions(+), 16 deletions(-)
> >
> > diff --git a/arch/arm64/kvm/mmu.c b/arch/arm64/kvm/mmu.c
> > index 0c71e3a9af8b0..ee2a548999b1b 100644
> > --- a/arch/arm64/kvm/mmu.c
> > +++ b/arch/arm64/kvm/mmu.c
> > @@ -1870,18 +1870,21 @@ static int kvm_s2_fault_compute_prot(struct kvm_s2_fault *fault)
> > if (fault->exec_fault)
> > fault->prot |= KVM_PGTABLE_PROT_X;
> >
> > - if (fault->s2_force_noncacheable) {
> > - if (fault->vm_flags & VM_ALLOW_ANY_UNCACHED)
> > - fault->prot |= KVM_PGTABLE_PROT_NORMAL_NC;
> > - else
> > - fault->prot |= KVM_PGTABLE_PROT_DEVICE;
> > - } else if (cpus_have_final_cap(ARM64_HAS_CACHE_DIC)) {
> > + if (fault->s2_force_noncacheable)
> > + fault->prot |= (fault->vm_flags & VM_ALLOW_ANY_UNCACHED) ?
> > + KVM_PGTABLE_PROT_NORMAL_NC : KVM_PGTABLE_PROT_DEVICE;
> > + else if (cpus_have_final_cap(ARM64_HAS_CACHE_DIC))
> > fault->prot |= KVM_PGTABLE_PROT_X;
> > - }
>
> Is not the existing code block bit more cleaner though ?
What is wrong with this? Are you stating a matter of personal taste ?
Ternary operators are great at making things more readable by reducing
the amount of nesting, and I'm all in favour of anything that makes
this $%^&*( code easier to parse.
Or are you pointing out a technical issue?
M.
--
Without deviation from the norm, progress is not possible.
^ permalink raw reply
* arm `rustdoc` Rust 1.85.0-only build error
From: Miguel Ojeda @ 2026-03-31 19:00 UTC (permalink / raw)
To: Christian Schrrefl, Russell King, Fabian Grünbichler
Cc: Rudraksha Gupta, Ard Biesheuvel, linux-arm-kernel, Miguel Ojeda,
rust-for-linux, linux-kernel
Hi Christian, Russell, arm, Fabian,
For Rust 1.85.0, for arm32, for the `rustdoc` target (i.e. all those
combined), I am seeing:
RUSTDOC .../1.85.0-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/lib.rs
error: target feature `fp-armv8` cannot be toggled with `#[target_feature]`: Rust ties `fp-armv8` to `neon`
--> .../1.85.0-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/../../stdarch/crates/core_arch/src/arm_shared/neon/generated.rs:7538:48
|
7538 | #[cfg_attr(target_arch = "arm", target_feature(enable = "fp-armv8,v8"))]
| ^^^^^^^^^^^^^^^^^^^^^
The issue is [1], was introduced in Rust 1.85.0 and was fixed already in
Rust 1.85.1 [2]:
Link: https://github.com/rust-lang/rust/issues/137366 [1]
Link: https://github.com/rust-lang/rust/pull/137632 [2]
It is unfortunate since our minimum is going to be 1.85.0 since that is
what Debian Stable has (even if patches may be on top) -- I generally
test the latest patch versions for each minor, but I noticed this since
I also test the actual minimum, and I am bumping it to 1.85.0.
To be clear, it is likely almost no one actually cares about this, since
nobody complained yet, and this can easily be fixed using the already
released Rust 1.85.1.
By the way, what is Debian's policy on upstream Rust patch versions?
Thanks!
Cheers,
Miguel
^ permalink raw reply
* Re: [PATCH v5 11/38] KVM: arm64: Split teardown hypercall into two phases
From: Mark Brown @ 2026-03-31 19:15 UTC (permalink / raw)
To: Will Deacon
Cc: kvmarm, linux-arm-kernel, Marc Zyngier, Oliver Upton, Joey Gouly,
Suzuki K Poulose, Zenghui Yu, Catalin Marinas, Quentin Perret,
Fuad Tabba, Vincent Donnefort, Mostafa Saleh, Alexandru Elisei,
Aishwarya.TCV
In-Reply-To: <20260330144841.26181-12-will@kernel.org>
[-- Attachment #1: Type: text/plain, Size: 4853 bytes --]
On Mon, Mar 30, 2026 at 03:48:12PM +0100, Will Deacon wrote:
> In preparation for reclaiming protected guest VM pages from the host
> during teardown, split the current 'pkvm_teardown_vm' hypercall into
> separate 'start' and 'finalise' calls.
>
> The 'pkvm_start_teardown_vm' hypercall puts the VM into a new 'is_dying'
> state, which is a point of no return past which no vCPU of the pVM is
> allowed to run any more. Once in this new state,
> 'pkvm_finalize_teardown_vm' can be used to reclaim meta-data and
> page-table pages from the VM. A subsequent patch will add support for
> reclaiming the individual guest memory pages.
We've started seeing WARN_ON()s generated in -next on N1DSP when running
kvm-unit-tests under pKVM:
1821 23:03:59.721620 <4>[ 17.558270] ------------[ cut here ]------------
1822 23:03:59.725053 <4>[ 17.558274] WARNING: arch/arm64/kvm/pkvm.c:373 at __pkvm_pgtable_stage2_unshare+0xbc/0xfc, CPU#3: qemu-system-aar/390
...
1839 23:03:59.850178 <4>[ 17.697247] Call trace:
1840 23:03:59.853079 <4>[ 17.699940] __pkvm_pgtable_stage2_unshare+0xbc/0xfc (P)
1841 23:03:59.865729 <4>[ 17.705500] pkvm_pgtable_stage2_destroy_range+0x90/0x214
1842 23:03:59.866226 <4>[ 17.711145] kvm_stage2_destroy+0x74/0xd0
1843 23:03:59.869119 <4>[ 17.715403] kvm_free_stage2_pgd+0x5c/0xc0
1844 23:03:59.881700 <4>[ 17.719746] kvm_uninit_stage2_mmu+0x1c/0x34
1845 23:03:59.882197 <4>[ 17.724262] kvm_arch_flush_shadow_all+0x6c/0x84
1846 23:03:59.885123 <4>[ 17.729127] kvm_mmu_notifier_release+0x30/0x84
1847 23:03:59.897681 <4>[ 17.733905] __mmu_notifier_release+0x74/0x264
1848 23:03:59.898181 <4>[ 17.738596] exit_mmap+0x260/0x268
1849 23:03:59.898513 <4>[ 17.742247] __mmput+0x38/0x120
1850 23:03:59.898817 <4>[ 17.745637] mmput+0x50/0x5c
1851 23:03:59.901098 <4>[ 17.748766] do_exit+0x220/0x8f4
A bisect points at this patch:
git bisect start
# status: waiting for both good and bad commits
# bad: [cf7c3c02fdd0dfccf4d6611714273dcb538af2cb] Add linux-next specific files for 20260330
git bisect bad cf7c3c02fdd0dfccf4d6611714273dcb538af2cb
# status: waiting for good commit(s), bad commit known
# good: [a010730e610019b6d010ec43ce737cb59a37809d] Merge branch 'for-linux-next-fixes' of https://gitlab.freedesktop.org/drm/misc/kernel.git
git bisect good a010730e610019b6d010ec43ce737cb59a37809d
# good: [5c552968883f4b10da9a1baeefd38a28afe993cd] Merge branch 'for-next' of https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next.git
git bisect good 5c552968883f4b10da9a1baeefd38a28afe993cd
# good: [de8f4e3b3d9aec5d4fdd5113ff09a6904b8a9f91] Merge branch 'for-next' of https://git.kernel.org/pub/scm/linux/kernel/git/axboe/linux.git
git bisect good de8f4e3b3d9aec5d4fdd5113ff09a6904b8a9f91
# bad: [7b3de9ac54f51bf09357802f02f0672de8bd49c0] Merge branch 'for-next' of https://git.kernel.org/pub/scm/linux/kernel/git/pdx86/platform-drivers-x86.git
git bisect bad 7b3de9ac54f51bf09357802f02f0672de8bd49c0
# good: [6778bd8a07f6f11414325ba6fe6d263f6b6994c9] Merge branch 'for-next' of https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git
git bisect good 6778bd8a07f6f11414325ba6fe6d263f6b6994c9
# good: [1cb1ca5899ab60d85e21ccf38da645a875fcf242] Merge branch 'edac-for-next' of https://git.kernel.org/pub/scm/linux/kernel/git/ras/ras.git
git bisect good 1cb1ca5899ab60d85e21ccf38da645a875fcf242
# bad: [4476dfd35bb0428c406fa68ce0d2125960535150] Merge branch 'next' of https://github.com/kvm-x86/linux.git
git bisect bad 4476dfd35bb0428c406fa68ce0d2125960535150
# good: [8f3483cd04d6ee6579594417d4a19394de63463a] Merge branch 'selftests'
git bisect good 8f3483cd04d6ee6579594417d4a19394de63463a
# bad: [5ad2ff071b5980f072a85c8114649218971c586e] Merge branch kvm-arm64/pkvm-protected-guest into kvmarm-master/next
git bisect bad 5ad2ff071b5980f072a85c8114649218971c586e
# bad: [9ff714a09222128da16900fc7c15dea65692fc26] KVM: arm64: Inject SIGSEGV on illegal accesses
git bisect bad 9ff714a09222128da16900fc7c15dea65692fc26
# good: [f0877a1455cc6a93be14e4da741ce26ac0d6ca6d] KVM: arm64: Prevent unsupported memslot operations on protected VMs
git bisect good f0877a1455cc6a93be14e4da741ce26ac0d6ca6d
# bad: [ea03466e806fea942841a41cfaab8db8c851aa71] KVM: arm64: Handle aborts from protected VMs
git bisect bad ea03466e806fea942841a41cfaab8db8c851aa71
# bad: [6c58f914eb9c4ce5225d03183ae1290d72b5f639] KVM: arm64: Split teardown hypercall into two phases
git bisect bad 6c58f914eb9c4ce5225d03183ae1290d72b5f639
# good: [73c55be08932a348f8b0a44f561c33eaa2cf1ad2] KVM: arm64: Ignore -EAGAIN when mapping in pages for the pKVM host
git bisect good 73c55be08932a348f8b0a44f561c33eaa2cf1ad2
# first bad commit: [6c58f914eb9c4ce5225d03183ae1290d72b5f639] KVM: arm64: Split teardown hypercall into two phases
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH v5 11/38] KVM: arm64: Split teardown hypercall into two phases
From: Will Deacon @ 2026-03-31 19:24 UTC (permalink / raw)
To: Mark Brown
Cc: kvmarm, linux-arm-kernel, Marc Zyngier, Oliver Upton, Joey Gouly,
Suzuki K Poulose, Zenghui Yu, Catalin Marinas, Quentin Perret,
Fuad Tabba, Vincent Donnefort, Mostafa Saleh, Alexandru Elisei,
Aishwarya.TCV
In-Reply-To: <0cf948e9-be64-4c75-97f8-a560442eb5d2@sirena.org.uk>
On Tue, Mar 31, 2026 at 08:15:40PM +0100, Mark Brown wrote:
> On Mon, Mar 30, 2026 at 03:48:12PM +0100, Will Deacon wrote:
> > In preparation for reclaiming protected guest VM pages from the host
> > during teardown, split the current 'pkvm_teardown_vm' hypercall into
> > separate 'start' and 'finalise' calls.
> >
> > The 'pkvm_start_teardown_vm' hypercall puts the VM into a new 'is_dying'
> > state, which is a point of no return past which no vCPU of the pVM is
> > allowed to run any more. Once in this new state,
> > 'pkvm_finalize_teardown_vm' can be used to reclaim meta-data and
> > page-table pages from the VM. A subsequent patch will add support for
> > reclaiming the individual guest memory pages.
>
> We've started seeing WARN_ON()s generated in -next on N1DSP when running
> kvm-unit-tests under pKVM:
>
> 1821 23:03:59.721620 <4>[ 17.558270] ------------[ cut here ]------------
> 1822 23:03:59.725053 <4>[ 17.558274] WARNING: arch/arm64/kvm/pkvm.c:373 at __pkvm_pgtable_stage2_unshare+0xbc/0xfc, CPU#3: qemu-system-aar/390
Aha! That's probably the thing I tried to fix today. Please can you try
these patches on top?
https://lore.kernel.org/r/20260331155056.28220-1-will@kernel.org
Thanks,
Will
^ 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