* [PATCH v2] arm64: panic from init_IRQ if IRQ handler stacks cannot be allocated
From: Osama Abdelkader @ 2026-03-26 22:57 UTC (permalink / raw)
To: Catalin Marinas, Will Deacon, Ard Biesheuvel, Ryo Takakura,
Breno Leitao, Mark Rutland, Osama Abdelkader, linux-arm-kernel,
linux-kernel
init_irq_stacks() and init_irq_scs() may fail when arch_alloc_vmap_stack
or scs_alloc return NULL. Return -ENOMEM from both and call panic() once
from init_IRQ(), covering per-CPU IRQ stacks and shadow IRQ stacks
consistently.
Signed-off-by: Osama Abdelkader <osama.abdelkader@gmail.com>
---
v2:
- Add return -ENOMEM from both init_irq_stacks() and init_irq_scs()
- Call panic() once from init_IRQ() if either init_irq_stacks() or
init_irq_scs() returns -ENOMEM
---
arch/arm64/kernel/irq.c | 29 ++++++++++++++++++++---------
1 file changed, 20 insertions(+), 9 deletions(-)
diff --git a/arch/arm64/kernel/irq.c b/arch/arm64/kernel/irq.c
index 15dedb385b9e..9fafd826002b 100644
--- a/arch/arm64/kernel/irq.c
+++ b/arch/arm64/kernel/irq.c
@@ -10,6 +10,7 @@
* Copyright (C) 2012 ARM Ltd.
*/
+#include <linux/errno.h>
#include <linux/hardirq.h>
#include <linux/init.h>
#include <linux/irq.h>
@@ -32,34 +33,43 @@ DEFINE_PER_CPU(struct nmi_ctx, nmi_contexts);
DEFINE_PER_CPU(unsigned long *, irq_stack_ptr);
-
DECLARE_PER_CPU(unsigned long *, irq_shadow_call_stack_ptr);
#ifdef CONFIG_SHADOW_CALL_STACK
DEFINE_PER_CPU(unsigned long *, irq_shadow_call_stack_ptr);
#endif
-static void init_irq_scs(void)
+static int __init init_irq_scs(void)
{
int cpu;
+ void *s;
if (!scs_is_enabled())
- return;
+ return 0;
+
+ for_each_possible_cpu(cpu) {
+ s = scs_alloc(early_cpu_to_node(cpu));
+ if (!s)
+ return -ENOMEM;
+ per_cpu(irq_shadow_call_stack_ptr, cpu) = s;
+ }
- for_each_possible_cpu(cpu)
- per_cpu(irq_shadow_call_stack_ptr, cpu) =
- scs_alloc(early_cpu_to_node(cpu));
+ return 0;
}
-static void __init init_irq_stacks(void)
+static int __init init_irq_stacks(void)
{
int cpu;
unsigned long *p;
for_each_possible_cpu(cpu) {
p = arch_alloc_vmap_stack(IRQ_STACK_SIZE, early_cpu_to_node(cpu));
+ if (!p)
+ return -ENOMEM;
per_cpu(irq_stack_ptr, cpu) = p;
}
+
+ return 0;
}
#ifdef CONFIG_SOFTIRQ_ON_OWN_STACK
@@ -109,8 +119,9 @@ int __init set_handle_fiq(void (*handle_fiq)(struct pt_regs *))
void __init init_IRQ(void)
{
- init_irq_stacks();
- init_irq_scs();
+ if (init_irq_stacks() || init_irq_scs())
+ panic("Failed to allocate IRQ stack resources\n");
+
irqchip_init();
if (system_uses_irq_prio_masking()) {
--
2.43.0
^ permalink raw reply related
* Re: [PATCH v1 0/2] perf build: Remove libunwind support
From: Namhyung Kim @ 2026-03-26 22:51 UTC (permalink / raw)
To: Ian Rogers
Cc: 9erthalion6, acme, adrian.hunter, alex, alexander.shishkin,
andrew.jones, aou, atrajeev, blakejones, ctshao, dapeng1.mi,
howardchu95, james.clark, john.g.garry, jolsa, leo.yan,
libunwind-devel, linux-arm-kernel, linux-kernel, linux-perf-users,
linux-riscv, mingo, palmer, peterz, pjw, shimin.guo, tglozar,
tmricht, will, amadio, yuzhuo
In-Reply-To: <20260321234220.848859-1-irogers@google.com>
On Sat, Mar 21, 2026 at 04:42:18PM -0700, Ian Rogers wrote:
> libunwind support exists for "--call-graph dwarf", however, libunwind
> support has been opt-in rather than opt-out since Linux v6.13 as libdw
> is preferred - commit 13e17c9ff49119aa ("perf build: Make libunwind
> opt-in rather than opt-out"). A problem with the libdw support was
> that it was slow, an issue fixed in Linux v7.0 in commit 6b2658b3f36a
> ("perf unwind-libdw: Don't discard loaded ELF/DWARF after every
> unwind"). As such libunwind support is now unnecessary.
>
> The patch series:
> https://lore.kernel.org/lkml/20260305221927.3237145-1-irogers@google.com/
> looked to make the libunwind support in perf similar to the libdw
> support, allow cross-architecture unwinding, etc. This was motivated
> by the perf regs conventions being altered by the addition of x86 APX
> support:
> https://lore.kernel.org/lkml/20260209072047.2180332-1-dapeng1.mi@linux.intel.com/
> It is necessary to translate the library's notion of registers to the
> perf register convention so that the stack unwinding state can be
> initialized. On this series it was stated that removing libunwind
> support from perf should be an option, rather than updating support:
> https://lore.kernel.org/lkml/abxs-2rozL1tBEO1@google.com/
> This was also what motivated making libunwind opt-in rather than
> opt-out.
>
> Given that 7 minor releases have happened with libunwind "deprecated"
> by making it opt-in, let's remove the libunwind support. There doesn't
> appear to be any disagreement to this on the mailing list.
I'm not sure if we want to remove it now. I think we need more time to
verify libdw unwinding is stable and fast enough. Also maybe we can
add build- or run-time warning when people try to use libunwind.
Thanks,
Namhyung
>
> Ian Rogers (2):
> perf build: Remove libunwind support
> tools build: Remove libunwind feature tests
>
> tools/build/feature/Makefile | 31 -
> tools/build/feature/test-libunwind-aarch64.c | 27 -
> tools/build/feature/test-libunwind-arm.c | 28 -
> .../test-libunwind-debug-frame-aarch64.c | 17 -
> .../feature/test-libunwind-debug-frame-arm.c | 17 -
> .../feature/test-libunwind-debug-frame.c | 17 -
> tools/build/feature/test-libunwind-x86.c | 28 -
> tools/build/feature/test-libunwind-x86_64.c | 28 -
> tools/build/feature/test-libunwind.c | 28 -
> tools/perf/Documentation/perf-check.txt | 1 -
> tools/perf/Documentation/perf-config.txt | 4 +-
> tools/perf/Documentation/perf-record.txt | 2 +-
> tools/perf/Makefile.config | 163 +---
> tools/perf/Makefile.perf | 3 -
> tools/perf/arch/arm/util/Build | 1 -
> tools/perf/arch/arm/util/unwind-libunwind.c | 50 --
> tools/perf/arch/arm64/util/Build | 1 -
> tools/perf/arch/arm64/util/unwind-libunwind.c | 17 -
> tools/perf/arch/loongarch/util/Build | 1 -
> .../arch/loongarch/util/unwind-libunwind.c | 82 --
> tools/perf/arch/mips/util/Build | 1 -
> tools/perf/arch/mips/util/unwind-libunwind.c | 22 -
> tools/perf/arch/powerpc/util/Build | 1 -
> .../perf/arch/powerpc/util/unwind-libunwind.c | 92 --
> tools/perf/arch/x86/util/Build | 1 -
> tools/perf/arch/x86/util/unwind-libunwind.c | 115 ---
> tools/perf/builtin-check.c | 1 -
> tools/perf/builtin-report.c | 4 +-
> tools/perf/tests/make | 2 -
> tools/perf/util/Build | 5 -
> tools/perf/util/callchain.c | 2 +-
> tools/perf/util/dso.h | 6 -
> tools/perf/util/libunwind/arm64.c | 40 -
> tools/perf/util/libunwind/x86_32.c | 41 -
> tools/perf/util/maps.c | 47 +-
> tools/perf/util/maps.h | 6 -
> tools/perf/util/thread.c | 40 +-
> tools/perf/util/thread.h | 1 -
> tools/perf/util/unwind-libunwind-local.c | 832 ------------------
> tools/perf/util/unwind-libunwind.c | 92 --
> tools/perf/util/unwind.h | 41 +-
> 41 files changed, 19 insertions(+), 1919 deletions(-)
> delete mode 100644 tools/build/feature/test-libunwind-aarch64.c
> delete mode 100644 tools/build/feature/test-libunwind-arm.c
> delete mode 100644 tools/build/feature/test-libunwind-debug-frame-aarch64.c
> delete mode 100644 tools/build/feature/test-libunwind-debug-frame-arm.c
> delete mode 100644 tools/build/feature/test-libunwind-debug-frame.c
> delete mode 100644 tools/build/feature/test-libunwind-x86.c
> delete mode 100644 tools/build/feature/test-libunwind-x86_64.c
> delete mode 100644 tools/build/feature/test-libunwind.c
> delete mode 100644 tools/perf/arch/arm/util/unwind-libunwind.c
> delete mode 100644 tools/perf/arch/arm64/util/unwind-libunwind.c
> delete mode 100644 tools/perf/arch/loongarch/util/unwind-libunwind.c
> delete mode 100644 tools/perf/arch/mips/util/unwind-libunwind.c
> delete mode 100644 tools/perf/arch/powerpc/util/unwind-libunwind.c
> delete mode 100644 tools/perf/arch/x86/util/unwind-libunwind.c
> delete mode 100644 tools/perf/util/libunwind/arm64.c
> delete mode 100644 tools/perf/util/libunwind/x86_32.c
> delete mode 100644 tools/perf/util/unwind-libunwind-local.c
> delete mode 100644 tools/perf/util/unwind-libunwind.c
>
> --
> 2.53.0.959.g497ff81fa9-goog
>
^ permalink raw reply
* Re: [PATCH v3 1/2] media: dt-bindings: rockchip,rk3568-mipi-csi2: add rk3588 compatible
From: Michael Riesch @ 2026-03-26 22:49 UTC (permalink / raw)
To: Rob Herring
Cc: Mauro Carvalho Chehab, Sakari Ailus, Laurent Pinchart, Frank Li,
Krzysztof Kozlowski, Conor Dooley, Heiko Stuebner, Kever Yang,
Collabora Kernel Team, linux-media, devicetree, linux-arm-kernel,
linux-rockchip, linux-kernel
In-Reply-To: <CAL_JsqLy4=z24-RrJWLp3hPpTwYLJ8=ehRw8cRdhZiW-eAsYCA@mail.gmail.com>
Hi Rob,
On 3/26/26 20:42, Rob Herring wrote:
> On Wed, Mar 25, 2026 at 4:34 PM Michael Riesch
> <michael.riesch@collabora.com> wrote:
>>
>> Hi Rob,
>>
>> On 3/25/26 22:06, Rob Herring wrote:
>>> On Wed, Mar 25, 2026 at 11:25:34AM +0100, Michael Riesch wrote:
>>>> The RK3588 MIPI CSI-2 receivers are compatible to the ones found in
>>>> the RK3568.
>>>> Introduce a list of compatible variants and add the RK3588 variant to
>>>> it.
>>>>
>>>> Acked-by: Rob Herring (Arm) <robh@kernel.org>
>>
>> First of all, apologies for applying your Acked-by tag. I figured
>> resolving the merged conflict was trivial and impossible to screw up, but...
>
> No worries. I would have kept it too.
>
>>>> Signed-off-by: Michael Riesch <michael.riesch@collabora.com>
>>>> ---
>>>> .../devicetree/bindings/media/rockchip,rk3568-mipi-csi2.yaml | 10 +++++++---
>>>> 1 file changed, 7 insertions(+), 3 deletions(-)
>>>>
>>>> diff --git a/Documentation/devicetree/bindings/media/rockchip,rk3568-mipi-csi2.yaml b/Documentation/devicetree/bindings/media/rockchip,rk3568-mipi-csi2.yaml
>>>> index 4ac4a3b6f406..3d3b3cd78884 100644
>>>> --- a/Documentation/devicetree/bindings/media/rockchip,rk3568-mipi-csi2.yaml
>>>> +++ b/Documentation/devicetree/bindings/media/rockchip,rk3568-mipi-csi2.yaml
>>>> @@ -16,9 +16,13 @@ description:
>>>>
>>>> properties:
>>>> compatible:
>>>> - enum:
>>>> - - fsl,imx93-mipi-csi2
>>>> - - rockchip,rk3568-mipi-csi2
>>>> + oneOf:
>>>> + - const: fsl,imx93-mipi-csi2
>>>> + - const: rockchip,rk3568-mipi-csi2
>>>
>>> These 2 should be a single enum as they were before.
>>
>> ... hm. Well.
>>
>> First, do you mean
>>
>> properties:
>> compatible:
>> oneOf:
>> - enum:
>> - fsl,imx93-mipi-csi2
>> - rockchip,rk3568-mipi-csi2
>> - items:
>> - enum:
>> - rockchip,rk3588-mipi-csi2
>> - const: rockchip,rk3568-mipi-csi2
>> ?
>
> Yes.
Thanks for the clarification. v4 coming up.
>
>> If so, what is the practical difference?
>
> First, then you aren't changing what's already there. For validation,
> there is no difference other than failures with 'oneOf' give poor
> error messages. It wouldn't be much better, just one less oneOf entry.
I'll try to keep that one in mind!
Best regards,
Michael
^ permalink raw reply
* Re: [PATCH v2 1/8] Bluetooth: btmtk: Add MT6639 (MT7927) Bluetooth support
From: Javier Tia @ 2026-03-26 21:26 UTC (permalink / raw)
To: Sean Wang
Cc: Marcel Holtmann, Luiz Augusto von Dentz, Matthias Brugger,
AngeloGioacchino Del Regno, linux-bluetooth, linux-kernel,
linux-arm-kernel, linux-mediatek, Ryan Gilbert
Hi Sean,
Thank you for the review. Both items are addressed in v3.
On Wed, Mar 26, 2026 Sean Wang wrote:
> Using raw CHIPID=0x0000 to unconditionally force 0x6639 seems fragile.
> If another device later hits the same missing-ID condition, it would
> also be misdetected as MT6639. Normally this kind of quirk could be
> carried in .driver_data, but since btusb.c is shared, I'm not sure
> that is the right fit here either. This should probably be handled
> through a more device-specific fallback instead of mapping all zero
> CHIPID cases to 0x6639.
Agreed. In v3, the zero-CHIPID fallback is scoped to a static
VID/PID table of known MT6639 USB devices. Only those specific
devices get forced to 0x6639 - any other device reading zero will
fall through to the default "unsupported hardware" path. This
follows the WiFi-side pattern where is_mt7927_hw is derived from
the PCI device table, not the chip register.
> I would prefer using the mediatek/mt7927/ folder naming here. mt7927
> is more widely recognized, and using it would avoid unnecessary
> confusion.
Done. The firmware path is now mediatek/mt7927/ in both the
FIRMWARE_MT7927 define and btmtk_fw_get_filename(). This matches
the WiFi firmware convention (mediatek/mt7927/WIFI_RAM_CODE_...).
The linux-firmware MR !946 has also been updated to use the
mt7927 directory.
v3 sent with these changes:
https://lore.kernel.org/linux-bluetooth/20260326-mt7927-bt-support-v3-0-fa7ebd424323@jetm.me/T/#t
Best,
Javier
^ permalink raw reply
* [PATCH v3 8/8] Bluetooth: btusb: Add MT7927 ID for ASUS X870E / ProArt X870E-Creator
From: Javier Tia @ 2026-03-26 22:13 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: <20260326-mt7927-bt-support-v3-0-fa7ebd424323@jetm.me>
Add USB device ID 13d3:3588 (IMC Networks/Azurewave) for the MediaTek
MT7927 (Filogic 380) Bluetooth interface found on the ASUS ROG STRIX
X870E-E GAMING WIFI and ASUS ProArt X870E-Creator WiFi motherboards.
Note: boards with this USB ID report only one ISO alternate setting
(alt 0), causing a non-fatal "setting interface failed (22)" during
setup. Bluetooth still functions but initialization takes ~19 seconds
instead of ~2.6 seconds.
The information in /sys/kernel/debug/usb/devices about the Bluetooth
device is listed as the below.
T: Bus=01 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 5 Spd=480 MxCh= 0
D: Ver= 2.10 Cls=ef(misc ) Sub=02 Prot=01 MxPS=64 #Cfgs= 1
P: Vendor=13d3 ProdID=3588 Rev= 1.00
S: Manufacturer=MediaTek Inc.
S: Product=Wireless_Device
S: SerialNumber=000000000
C:* #Ifs= 3 Cfg#= 1 Atr=e0 MxPwr=100mA
A: FirstIf#= 0 IfCount= 3 Cls=e0(wlcon) Sub=01 Prot=01
I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=81(I) Atr=03(Int.) MxPS= 16 Ivl=125us
E: Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E: Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=83(I) Atr=01(Isoc) MxPS= 0 Ivl=1ms
E: Ad=03(O) Atr=01(Isoc) MxPS= 0 Ivl=1ms
I:* If#= 2 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=8a(I) Atr=03(Int.) MxPS= 512 Ivl=125us
E: Ad=0a(O) Atr=03(Int.) MxPS= 512 Ivl=125us
Link: https://bugzilla.kernel.org/show_bug.cgi?id=221096
Link: https://github.com/openwrt/mt76/issues/927
Signed-off-by: Javier Tia <floss@jetm.me>
Tested-by: Jose Tiburcio Ribeiro Netto <jnetto@mineiro.io>
Tested-by: Ivan Lubnin <lubnin.ivan@gmail.com>
---
drivers/bluetooth/btusb.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c
index 55a000540439..45ef0d008bce 100644
--- a/drivers/bluetooth/btusb.c
+++ b/drivers/bluetooth/btusb.c
@@ -761,6 +761,8 @@ static const struct usb_device_id quirks_table[] = {
BTUSB_WIDEBAND_SPEECH },
{ USB_DEVICE(0x0489, 0xe116), .driver_info = BTUSB_MEDIATEK |
BTUSB_WIDEBAND_SPEECH },
+ { USB_DEVICE(0x13d3, 0x3588), .driver_info = BTUSB_MEDIATEK |
+ BTUSB_WIDEBAND_SPEECH },
{ USB_DEVICE(0x0489, 0xe14e), .driver_info = BTUSB_MEDIATEK |
BTUSB_WIDEBAND_SPEECH },
{ USB_DEVICE(0x0489, 0xe14f), .driver_info = BTUSB_MEDIATEK |
--
2.53.0
^ permalink raw reply related
* [PATCH v3 6/8] Bluetooth: btusb: Add MT7927 ID for MSI X870E Ace Max
From: Javier Tia @ 2026-03-26 22:13 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: <20260326-mt7927-bt-support-v3-0-fa7ebd424323@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 v3 7/8] Bluetooth: btusb: Add MT7927 ID for TP-Link Archer TBE550E
From: Javier Tia @ 2026-03-26 22:13 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: <20260326-mt7927-bt-support-v3-0-fa7ebd424323@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 v3 5/8] Bluetooth: btusb: Add MT7927 ID for Gigabyte Z790 AORUS MASTER X
From: Javier Tia @ 2026-03-26 22:13 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: <20260326-mt7927-bt-support-v3-0-fa7ebd424323@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 v3 4/8] Bluetooth: btusb: Add MT7927 ID for Lenovo Legion Pro 7 16ARX9
From: Javier Tia @ 2026-03-26 22:13 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: <20260326-mt7927-bt-support-v3-0-fa7ebd424323@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 v3 3/8] Bluetooth: btusb: Add MT7927 ID for ASUS ROG Crosshair X870E Hero
From: Javier Tia @ 2026-03-26 22:13 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: <20260326-mt7927-bt-support-v3-0-fa7ebd424323@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 v3 0/8] Bluetooth: Add MediaTek MT7927 (MT6639) support
From: Javier Tia @ 2026-03-26 22:13 UTC (permalink / raw)
To: Marcel Holtmann, Luiz Augusto von Dentz, Matthias Brugger,
AngeloGioacchino Del Regno
Cc: linux-bluetooth, linux-kernel, linux-arm-kernel, linux-mediatek,
Ryan Gilbert, Jose Tiburcio Ribeiro Netto, Llewellyn Curran,
Chapuis Dario, Evgeny Kapusta, Nitin Gurram, Thibaut FRANCOIS,
Ivan Lubnin
In-Reply-To: <177272816248.352280.12453518046823439297@jetm.me>
This series adds Bluetooth support for the MediaTek MT7927 (Filogic 380)
combo WiFi 7 + BT 5.4 module. The BT subsystem uses hardware variant
0x6639 and connects via USB.
The MT7927 is shipping in motherboards and PCIe add-in cards from ASUS,
Gigabyte, Lenovo, MSI, and TP-Link since mid-2024. Without these patches,
users see "Unsupported hardware variant (00006639)" or the BT subsystem
hangs during firmware download.
The series consists of eight patches:
[1/8] Bluetooth: btmtk: Add MT6639 (MT7927) Bluetooth support
[2/8] Bluetooth: btmtk: fix ISO interface setup for single alt setting
[3/8] Bluetooth: btusb: Add MT7927 ID for ASUS ROG Crosshair X870E Hero
[4/8] Bluetooth: btusb: Add MT7927 ID for Lenovo Legion Pro 7 16ARX9
[5/8] Bluetooth: btusb: Add MT7927 ID for Gigabyte Z790 AORUS MASTER X
[6/8] Bluetooth: btusb: Add MT7927 ID for MSI X870E Ace Max
[7/8] Bluetooth: btusb: Add MT7927 ID for TP-Link Archer TBE550E
[8/8] Bluetooth: btusb: Add MT7927 ID for ASUS X870E / ProArt X870E-Creator
Three driver changes are needed for MT6639 (patch 1):
1. CHIPID workaround: On some boards the BT USB MMIO register reads
0x0000 for dev_id. Force dev_id to 0x6639 only when the USB VID/PID
matches a known MT6639 device, avoiding misdetection if a future
chip also reads zero. This follows the WiFi-side pattern.
2. Firmware naming: MT6639 uses firmware version prefix "2_1" instead of
"1_1" used by MT7925 and other variants. The firmware path is
mediatek/mt7927/BT_RAM_CODE_MT6639_2_1_hdr.bin, using the mt7927
directory to match the WiFi firmware convention. The filename will
likely change to use MT7927 once MediaTek submits a dedicated
Linux firmware binary.
3. Section filtering: The firmware binary contains 9 sections, but only
sections with (dlmodecrctype & 0xff) == 0x01 are Bluetooth-related.
Sending WiFi/other sections causes an irreversible BT subsystem hang.
Patch 2 fixes the ISO interface setup for devices that expose only a
single alternate setting (alt 0) on the ISO endpoint. Without this fix,
btmtk_usb_claim_iso_intf() fails with EINVAL, causing ~20 second
initialization delays on 13d3:3588 devices.
Tested on:
- ASUS ROG Crosshair X870E Hero (USB 0489:e13a)
- ASUS ROG STRIX X870E-E (USB 13d3:3588)
- ASUS ROG STRIX B850-E GAMING WIFI (USB 0489:e13a)
- Gigabyte Z790 AORUS MASTER X (USB 0489:e10f)
- Lenovo Legion Pro 7 16ARX9 (USB 0489:e0fa)
- MSI MEG X870E ACE MAX (USB 0489:e110)
- TP-Link Archer TBE550E PCIe (USB 0489:e116)
The firmware blob is being submitted separately to linux-firmware via
GitLab MR !946. The firmware path has been updated to mediatek/mt7927/
per maintainer feedback.
Changes in v3 (suggested by Sean Wang):
- Scoped CHIPID workaround to a static VID/PID table of known MT6639
USB devices instead of mapping all zero-CHIPID cases to 0x6639
- Changed firmware path from mediatek/mt6639/ to mediatek/mt7927/ to
match the WiFi firmware convention and avoid confusion
- Added MODULE_FIRMWARE(FIRMWARE_MT7927) for initramfs firmware discovery
- Added Tested-by for 0489:e110 (Nitin Gurram)
Changes in v2:
- Split USB device IDs into per-device commits as requested (Luiz)
- Added 0489:e110 (MSI X870E Ace Max, new hardware report)
- Added ISO interface fix for single alt setting (13d3:3588 devices)
- Added Tested-by trailers for all USB IDs
- Added USB descriptor output to all per-device commits
- Removed BTMTK_FIRMWARE_LOADED skip logic (Sean Wang)
Link to v2: https://lore.kernel.org/linux-bluetooth/20260325-mt7927-bt-support-v2-0-b892a3252880@jetm.me/T/#t
Link to v1: https://lore.kernel.org/linux-bluetooth/177272816248.352280.12453518046823439297@jetm.me/
Signed-off-by: Javier Tia <floss@jetm.me>
---
Javier Tia (8):
Bluetooth: btmtk: Add MT6639 (MT7927) Bluetooth support
Bluetooth: btmtk: fix ISO interface setup for single alt setting
Bluetooth: btusb: Add MT7927 ID for ASUS ROG Crosshair X870E Hero
Bluetooth: btusb: Add MT7927 ID for Lenovo Legion Pro 7 16ARX9
Bluetooth: btusb: Add MT7927 ID for Gigabyte Z790 AORUS MASTER X
Bluetooth: btusb: Add MT7927 ID for MSI X870E Ace Max
Bluetooth: btusb: Add MT7927 ID for TP-Link Archer TBE550E
Bluetooth: btusb: Add MT7927 ID for ASUS X870E / ProArt X870E-Creator
drivers/bluetooth/btmtk.c | 56 ++++++++++++++++++++++++++++++++++++++++++++---
drivers/bluetooth/btmtk.h | 1 +
drivers/bluetooth/btusb.c | 12 ++++++++++
3 files changed, 66 insertions(+), 3 deletions(-)
---
base-commit: 50003ce2085a7f7dacf2426065d1a69c84b5b963
change-id: 20260305-mt7927-bt-support-6589a50c961f
Best regards,
--
Javier Tia <floss@jetm.me>
^ permalink raw reply
* [PATCH v3 1/8] Bluetooth: btmtk: Add MT6639 (MT7927) Bluetooth support
From: Javier Tia @ 2026-03-26 22:13 UTC (permalink / raw)
To: Marcel Holtmann, Luiz Augusto von Dentz, Matthias Brugger,
AngeloGioacchino Del Regno
Cc: linux-bluetooth, linux-kernel, linux-arm-kernel, linux-mediatek,
Ryan Gilbert
In-Reply-To: <20260326-mt7927-bt-support-v3-0-fa7ebd424323@jetm.me>
The MediaTek MT7927 (Filogic 380) combo WiFi 7 + BT 5.4 module uses
hardware variant 0x6639 for its Bluetooth subsystem. Without this patch,
the chip fails with "Unsupported hardware variant (00006639)" or hangs
during firmware download.
Three changes are needed to support MT6639:
1. CHIPID workaround: On some boards the BT USB MMIO register reads
0x0000 for dev_id, causing the driver to skip the 0x6639 init path.
Force dev_id to 0x6639 only when the USB VID/PID matches a known
MT6639 device, avoiding misdetection if a future chip also reads
zero. This follows the WiFi-side pattern that uses PCI device IDs
to scope the same workaround.
2. Firmware naming: MT6639 uses firmware version prefix "2_1" instead of
"1_1" used by MT7925 and other variants. The firmware path is
mediatek/mt7927/BT_RAM_CODE_MT6639_2_1_hdr.bin, using the mt7927
directory to match the WiFi firmware convention. The filename will
likely change to use MT7927 once MediaTek submits a dedicated
Linux firmware binary.
3. Section filtering: The MT6639 firmware binary contains 9 sections, but
only sections with (dlmodecrctype & 0xff) == 0x01 are Bluetooth-related.
Sending the remaining WiFi/other sections causes an irreversible BT
subsystem hang requiring a full power cycle. This matches the Windows
driver behavior observed via USB captures.
Also add 0x6639 to the reset register (CONNV3) and firmware setup switch
cases alongside the existing 0x7925 handling.
Link: https://bugzilla.kernel.org/show_bug.cgi?id=221096
Link: https://github.com/openwrt/mt76/issues/927
Reported-by: Ryan Gilbert <xelnaga@gmail.com>
Signed-off-by: Javier Tia <floss@jetm.me>
---
drivers/bluetooth/btmtk.c | 53 +++++++++++++++++++++++++++++++++++++++++++++--
drivers/bluetooth/btmtk.h | 1 +
2 files changed, 52 insertions(+), 2 deletions(-)
diff --git a/drivers/bluetooth/btmtk.c b/drivers/bluetooth/btmtk.c
index 2507d587f28a..3f12f2ab6369 100644
--- a/drivers/bluetooth/btmtk.c
+++ b/drivers/bluetooth/btmtk.c
@@ -25,6 +25,22 @@
/* It is for mt79xx iso data transmission setting */
#define MTK_ISO_THRESHOLD 264
+/* Known MT6639 (MT7927) Bluetooth USB devices.
+ * Used to scope the zero-CHIPID workaround to real MT6639 hardware,
+ * since some boards return 0x0000 from the MMIO chip ID register.
+ */
+static const struct {
+ u16 vendor;
+ u16 product;
+} btmtk_mt6639_devs[] = {
+ { 0x0489, 0xe13a }, /* ASUS ROG Crosshair X870E Hero */
+ { 0x0489, 0xe0fa }, /* Lenovo Legion Pro 7 16ARX9 */
+ { 0x0489, 0xe10f }, /* Gigabyte Z790 AORUS MASTER X */
+ { 0x0489, 0xe110 }, /* MSI X870E Ace Max */
+ { 0x0489, 0xe116 }, /* TP-Link Archer TBE550E */
+ { 0x13d3, 0x3588 }, /* ASUS ROG STRIX X870E-E */
+};
+
struct btmtk_patch_header {
u8 datetime[16];
u8 platform[4];
@@ -112,7 +128,11 @@ static void btmtk_coredump_notify(struct hci_dev *hdev, int state)
void btmtk_fw_get_filename(char *buf, size_t size, u32 dev_id, u32 fw_ver,
u32 fw_flavor)
{
- if (dev_id == 0x7925)
+ if (dev_id == 0x6639)
+ snprintf(buf, size,
+ "mediatek/mt7927/BT_RAM_CODE_MT%04x_2_%x_hdr.bin",
+ dev_id & 0xffff, (fw_ver & 0xff) + 1);
+ else if (dev_id == 0x7925)
snprintf(buf, size,
"mediatek/mt%04x/BT_RAM_CODE_MT%04x_1_%x_hdr.bin",
dev_id & 0xffff, dev_id & 0xffff, (fw_ver & 0xff) + 1);
@@ -130,6 +150,7 @@ EXPORT_SYMBOL_GPL(btmtk_fw_get_filename);
int btmtk_setup_firmware_79xx(struct hci_dev *hdev, const char *fwname,
wmt_cmd_sync_func_t wmt_cmd_sync)
{
+ struct btmtk_data *data = hci_get_priv(hdev);
struct btmtk_hci_wmt_params wmt_params;
struct btmtk_patch_header *hdr;
struct btmtk_global_desc *globaldesc = NULL;
@@ -166,6 +187,14 @@ int btmtk_setup_firmware_79xx(struct hci_dev *hdev, const char *fwname,
section_offset = le32_to_cpu(sectionmap->secoffset);
dl_size = le32_to_cpu(sectionmap->bin_info_spec.dlsize);
+ /* MT6639: only download sections where dlmode byte0 == 0x01,
+ * matching the Windows driver behavior which skips WiFi/other
+ * sections that would cause the chip to hang.
+ */
+ if (data->dev_id == 0x6639 && dl_size > 0 &&
+ (le32_to_cpu(sectionmap->bin_info_spec.dlmodecrctype) & 0xff) != 0x01)
+ continue;
+
if (dl_size > 0) {
retry = 20;
while (retry > 0) {
@@ -852,7 +881,7 @@ int btmtk_usb_subsys_reset(struct hci_dev *hdev, u32 dev_id)
if (err < 0)
return err;
msleep(100);
- } else if (dev_id == 0x7925) {
+ } else if (dev_id == 0x7925 || dev_id == 0x6639) {
err = btmtk_usb_uhw_reg_read(hdev, MTK_BT_RESET_REG_CONNV3, &val);
if (err < 0)
return err;
@@ -1322,6 +1351,24 @@ int btmtk_usb_setup(struct hci_dev *hdev)
fw_flavor = (fw_flavor & 0x00000080) >> 7;
}
+ if (!dev_id) {
+ u16 vid = le16_to_cpu(btmtk_data->udev->descriptor.idVendor);
+ u16 pid = le16_to_cpu(btmtk_data->udev->descriptor.idProduct);
+ int i;
+
+ for (i = 0; i < ARRAY_SIZE(btmtk_mt6639_devs); i++) {
+ if (vid == btmtk_mt6639_devs[i].vendor &&
+ pid == btmtk_mt6639_devs[i].product) {
+ dev_id = 0x6639;
+ break;
+ }
+ }
+
+ if (dev_id)
+ bt_dev_info(hdev, "MT6639: CHIPID=0x0000 with VID=%04x PID=%04x, using 0x6639",
+ vid, pid);
+ }
+
btmtk_data->dev_id = dev_id;
err = btmtk_register_coredump(hdev, btmtk_data->drv_name, fw_version);
@@ -1339,6 +1386,7 @@ int btmtk_usb_setup(struct hci_dev *hdev)
case 0x7925:
case 0x7961:
case 0x7902:
+ case 0x6639:
btmtk_fw_get_filename(fw_bin_name, sizeof(fw_bin_name), dev_id,
fw_version, fw_flavor);
@@ -1516,3 +1564,4 @@ MODULE_FIRMWARE(FIRMWARE_MT7668);
MODULE_FIRMWARE(FIRMWARE_MT7922);
MODULE_FIRMWARE(FIRMWARE_MT7961);
MODULE_FIRMWARE(FIRMWARE_MT7925);
+MODULE_FIRMWARE(FIRMWARE_MT7927);
diff --git a/drivers/bluetooth/btmtk.h b/drivers/bluetooth/btmtk.h
index adaf385626ee..d95d023b6adc 100644
--- a/drivers/bluetooth/btmtk.h
+++ b/drivers/bluetooth/btmtk.h
@@ -8,6 +8,7 @@
#define FIRMWARE_MT7902 "mediatek/BT_RAM_CODE_MT7902_1_1_hdr.bin"
#define FIRMWARE_MT7961 "mediatek/BT_RAM_CODE_MT7961_1_2_hdr.bin"
#define FIRMWARE_MT7925 "mediatek/mt7925/BT_RAM_CODE_MT7925_1_1_hdr.bin"
+#define FIRMWARE_MT7927 "mediatek/mt7927/BT_RAM_CODE_MT6639_2_1_hdr.bin"
#define HCI_EV_WMT 0xe4
#define HCI_WMT_MAX_EVENT_SIZE 64
--
2.53.0
^ permalink raw reply related
* [PATCH v3 2/8] Bluetooth: btmtk: fix ISO interface setup for single alt setting
From: Javier Tia @ 2026-03-26 22:13 UTC (permalink / raw)
To: Marcel Holtmann, Luiz Augusto von Dentz, Matthias Brugger,
AngeloGioacchino Del Regno
Cc: linux-bluetooth, linux-kernel, linux-arm-kernel, linux-mediatek,
Ryan Gilbert
In-Reply-To: <20260326-mt7927-bt-support-v3-0-fa7ebd424323@jetm.me>
Some MT6639 Bluetooth USB interfaces (e.g. IMC Networks 13d3:3588 on
ASUS ROG STRIX X870E-E and ProArt X870E-Creator boards) expose only a
single alternate setting (alt 0) on the ISO interface. The driver
unconditionally requests alt setting 1, which fails with EINVAL on
these devices, causing a ~20 second initialization delay and no LE
audio support.
Check the number of available alternate settings before selecting one.
If only alt 0 exists, use it; otherwise request alt 1 as before.
Link: https://github.com/jetm/mediatek-mt7927-dkms/pull/39
Signed-off-by: Javier Tia <floss@jetm.me>
Reported-by: Ryan Gilbert <xelnaga@gmail.com>
Tested-by: Ryan Gilbert <xelnaga@gmail.com>
---
drivers/bluetooth/btmtk.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/bluetooth/btmtk.c b/drivers/bluetooth/btmtk.c
index 3f12f2ab6369..95b09b1ea78f 100644
--- a/drivers/bluetooth/btmtk.c
+++ b/drivers/bluetooth/btmtk.c
@@ -1029,7 +1029,8 @@ static int __set_mtk_intr_interface(struct hci_dev *hdev)
if (!btmtk_data->isopkt_intf)
return -ENODEV;
- err = usb_set_interface(btmtk_data->udev, MTK_ISO_IFNUM, 1);
+ err = usb_set_interface(btmtk_data->udev, MTK_ISO_IFNUM,
+ (intf->num_altsetting > 1) ? 1 : 0);
if (err < 0) {
bt_dev_err(hdev, "setting interface failed (%d)", -err);
return err;
--
2.53.0
^ permalink raw reply related
* Re: [PATCH v3 1/3] PCI: Allow ATS to be always on for CXL.cache capable devices
From: Jason Gunthorpe @ 2026-03-26 21:51 UTC (permalink / raw)
To: Bjorn Helgaas
Cc: Nicolin Chen, will, robin.murphy, bhelgaas, joro, praan, baolu.lu,
kevin.tian, miko.lenczewski, linux-arm-kernel, iommu,
linux-kernel, linux-pci, dan.j.williams, jonathan.cameron, vsethi,
linux-cxl
In-Reply-To: <20260326213854.GA1348488@bhelgaas>
On Thu, Mar 26, 2026 at 04:38:54PM -0500, Bjorn Helgaas wrote:
> It's only called from arm-smmu-v3.c. Is there something unique about
> SMMU, or will other IOMMUs need something similar?
Yeah, every iommu driver will eventually want to use this. IIRC the
motivation for using the pci core was to make use of pci quirks.
Right now ARM is the only one that turns ATS off for identity, but
IMHO those are bugs in the other drivers to not do that.
Jason
^ permalink raw reply
* Re: [PATCH v3 1/3] PCI: Allow ATS to be always on for CXL.cache capable devices
From: Bjorn Helgaas @ 2026-03-26 21:38 UTC (permalink / raw)
To: Nicolin Chen
Cc: jgg, will, robin.murphy, bhelgaas, joro, praan, baolu.lu,
kevin.tian, miko.lenczewski, linux-arm-kernel, iommu,
linux-kernel, linux-pci, dan.j.williams, jonathan.cameron, vsethi,
linux-cxl
In-Reply-To: <a0dd3e4cc5260f55bbec5b3ed6791def33028735.1772833963.git.nicolinc@nvidia.com>
On Fri, Mar 06, 2026 at 03:41:15PM -0800, Nicolin Chen wrote:
> Controlled by the IOMMU driver, ATS is usually enabled "on demand" when a
> device requests a translation service from its associated IOMMU HW running
> on the channel of a given PASID. This is working even when a device has no
> translation on its RID (i.e., the RID is IOMMU bypassed).
>
> However, certain PCIe devices require non-PASID ATS on their RID even when
> the RID is IOMMU bypassed. Call this "always on".
>
> For instance, the CXL spec notes in "3.2.5.13 Memory Type on CXL.cache":
> "To source requests on CXL.cache, devices need to get the Host Physical
> Address (HPA) from the Host by means of an ATS request on CXL.io."
Add CXL spec rev, e.g., "CXL r4.0, sec 3.2.5.13"
> In other words, the CXL.cache capability requires ATS; otherwise, it can't
> access host physical memory.
>
> Introduce a new pci_ats_always_on() helper for the IOMMU driver to scan a
> PCI device and shift ATS policies between "on demand" and "always on".
>
> Add the support for CXL.cache devices first. Pre-CXL devices will be added
> in quirks.c file.
>
> Note that pci_ats_always_on() validates against pci_ats_supported(), so we
> ensure that untrusted devices (e.g. external ports) will not be always on.
> This maintains the existing ATS security policy regarding potential side-
> channel attacks via ATS.
I don't think this really has anything to do with the PCI core.
pci_ats_always_on() doesn't *do* anything with a PCI device; it just
looks for PCI_DVSEC_CXL_CACHE_CAPABLE, and the caller figures out what
to do with the result. This doesn't make the PCI core turn on ATS
automatically by itself, and the PCI core doesn't care whether the
IOMMU driver always enables ATS.
It's only called from arm-smmu-v3.c. Is there something unique about
SMMU, or will other IOMMUs need something similar?
> +++ b/drivers/pci/ats.c
> @@ -205,6 +205,48 @@ int pci_ats_page_aligned(struct pci_dev *pdev)
> return 0;
> }
>
> +/*
> + * CXL r4.0, sec 3.2.5.13 Memory Type on CXL.cache notes: to source requests on
> + * CXL.cache, devices need to get the Host Physical Address (HPA) from the Host
> + * by means of an ATS request on CXL.io.
> + *
> + * In other world, CXL.cache devices cannot access host physical memory without
> + * ATS.
s/other world/other words/
^ permalink raw reply
* Re: [PATCH 3/3] KVM: arm64: selftests: Enable stage-2 in NV preparation functions
From: Wei-Lin Chang @ 2026-03-26 21:34 UTC (permalink / raw)
To: Itaru Kitayama
Cc: kvm, linux-kselftest, linux-arm-kernel, kvmarm, linux-kernel,
Paolo Bonzini, Shuah Khan, Marc Zyngier, Oliver Upton, Joey Gouly,
Suzuki K Poulose, Zenghui Yu, Catalin Marinas, Will Deacon
In-Reply-To: <acN_YIzr6JZmYhZ8@sm-arm-grace07>
On Wed, Mar 25, 2026 at 03:23:28PM +0900, Itaru Kitayama wrote:
> Hi Wei Lin,
Hi,
> On Wed, Mar 25, 2026 at 12:36:20AM +0000, Wei-Lin Chang wrote:
> > Introduce library functions for setting up guest stage-2 page tables,
> > then use that to give L2 an identity mapped stage-2 and enable it.
> >
> > The translation and stage-2 page table built is simple, start level 0,
> > 4 levels, 4KB granules, normal cachable, 48-bit IA, 40-bit OA.
> >
> > The nested page table code is adapted from lib/x86/vmx.c.
> >
> > Signed-off-by: Wei-Lin Chang <weilin.chang@arm.com>
> > ---
> > .../selftests/kvm/include/arm64/nested.h | 7 ++
> > .../selftests/kvm/include/arm64/processor.h | 9 ++
> > .../testing/selftests/kvm/lib/arm64/nested.c | 97 ++++++++++++++++++-
> > 3 files changed, 111 insertions(+), 2 deletions(-)
> >
> > diff --git a/tools/testing/selftests/kvm/include/arm64/nested.h b/tools/testing/selftests/kvm/include/arm64/nested.h
> > index 739ff2ee0161..0be10a775e48 100644
> > --- a/tools/testing/selftests/kvm/include/arm64/nested.h
> > +++ b/tools/testing/selftests/kvm/include/arm64/nested.h
> > @@ -6,6 +6,13 @@
> > #ifndef SELFTEST_KVM_NESTED_H
> > #define SELFTEST_KVM_NESTED_H
> >
> > +uint64_t get_l1_vtcr(void);
>
> Using a type u64 is simpler? And I think you configure guest
> hypervisor's stage 2 translation table, I felt this gives us
> an impression somewhere the configuration IA and OA sizes etc
> are stored.
Sure, u64 is okay.
In this version I basically just used hard-coded values whenever I not
needed IA, OA and other related values e.g. page shift, which is not
good and as Marc said would not even work on some platforms. I'll make
it more modular in the next iteration.
>
> > +
> > +void nested_map(struct kvm_vm *vm, vm_paddr_t guest_pgd,
> > + uint64_t nested_paddr, uint64_t paddr, uint64_t size);
> > +void nested_map_memslot(struct kvm_vm *vm, vm_paddr_t guest_pgd,
> > + uint32_t memslot);
> > +
> > void prepare_l2_stack(struct kvm_vm *vm, struct kvm_vcpu *vcpu);
> > void prepare_hyp_state(struct kvm_vm *vm, struct kvm_vcpu *vcpu);
> > void prepare_eret_destination(struct kvm_vm *vm, struct kvm_vcpu *vcpu, void *l2_pc);
> > diff --git a/tools/testing/selftests/kvm/include/arm64/processor.h b/tools/testing/selftests/kvm/include/arm64/processor.h
> > index ac97a1c436fc..5de2e932d95a 100644
> > --- a/tools/testing/selftests/kvm/include/arm64/processor.h
> > +++ b/tools/testing/selftests/kvm/include/arm64/processor.h
> > @@ -104,6 +104,15 @@
> > #define TCR_HA (UL(1) << 39)
> > #define TCR_DS (UL(1) << 59)
> >
> > +/* VTCR_EL2 specific flags */
> > +#define VTCR_EL2_T0SZ_BITS(x) ((UL(64) - (x)) << VTCR_EL2_T0SZ_SHIFT)
> > +
> > +#define VTCR_EL2_SL0_LV0_4K (UL(2) << VTCR_EL2_SL0_SHIFT)
> > +#define VTCR_EL2_SL0_LV1_4K (UL(1) << VTCR_EL2_SL0_SHIFT)
> > +#define VTCR_EL2_SL0_LV2_4K (UL(0) << VTCR_EL2_SL0_SHIFT)
> > +
> > +#define VTCR_EL2_PS_40_BITS (UL(2) << VTCR_EL2_PS_SHIFT)
> > +
> > /*
> > * AttrIndx[2:0] encoding (mapping attributes defined in the MAIR* registers).
> > */
> > diff --git a/tools/testing/selftests/kvm/lib/arm64/nested.c b/tools/testing/selftests/kvm/lib/arm64/nested.c
> > index 111d02f44cfe..910f8cd30f96 100644
> > --- a/tools/testing/selftests/kvm/lib/arm64/nested.c
> > +++ b/tools/testing/selftests/kvm/lib/arm64/nested.c
> > @@ -1,8 +1,11 @@
> > // SPDX-License-Identifier: GPL-2.0
> > /*
> > - * ARM64 Nested virtualization helpers
> > + * ARM64 Nested virtualization helpers, nested page table code adapted from
> > + * ../x86/vmx.c.
> > */
> >
> > +#include <linux/sizes.h>
> > +
> > #include "kvm_util.h"
> > #include "nested.h"
> > #include "processor.h"
> > @@ -18,6 +21,87 @@ static void hvc_handler(struct ex_regs *regs)
> > regs->pc = (u64)after_hvc;
> > }
> >
> > +uint64_t get_l1_vtcr(void)
> > +{
> > + return VTCR_EL2_PS_40_BITS | VTCR_EL2_TG0_4K | VTCR_EL2_ORGN0_WBWA |
> > + VTCR_EL2_IRGN0_WBWA | VTCR_EL2_SL0_LV0_4K | VTCR_EL2_T0SZ_BITS(48);
> > +}
> > +
> > +static void __nested_pg_map(struct kvm_vm *vm, uint64_t guest_pgd,
> > + uint64_t nested_paddr, uint64_t paddr, uint64_t flags)
> > +{
> > + uint8_t attr_idx = flags & (PTE_ATTRINDX_MASK >> PTE_ATTRINDX_SHIFT);
> > + uint64_t pg_attr;
> > + uint64_t *ptep;
> > +
> > + TEST_ASSERT((nested_paddr % vm->page_size) == 0,
> > + "L2 IPA not on page boundary,\n"
> > + " nested_paddr: 0x%lx vm->page_size: 0x%x", nested_paddr, vm->page_size);
> > + TEST_ASSERT((paddr % vm->page_size) == 0,
> > + "Guest physical address not on page boundary,\n"
> > + " paddr: 0x%lx vm->page_size: 0x%x", paddr, vm->page_size);
> > + TEST_ASSERT((paddr >> vm->page_shift) <= vm->max_gfn,
> > + "Physical address beyond maximum supported,\n"
> > + " paddr: 0x%lx vm->max_gfn: 0x%lx vm->page_size: 0x%x",
> > + paddr, vm->max_gfn, vm->page_size);
> > +
> > + ptep = addr_gpa2hva(vm, guest_pgd) + ((nested_paddr >> 39) & 0x1ffu) * 8;
> > + if (!*ptep)
> > + *ptep = (vm_alloc_page_table(vm) & GENMASK(47, 12)) | PGD_TYPE_TABLE | PTE_VALID;
>
> Same but given this is stage 2 translation tables, KVM_PTE_VALID?
I see your point, but KVM_PTE_VALID is only defined for KVM, not here in
kselftest userspace. However since I will redo the page table generator,
I can add this, let's see.
Thanks for the suggestions!
Thanks,
Wei-Lin Chang
>
> Thanks,
> Itaru.
> > + ptep = addr_gpa2hva(vm, *ptep & GENMASK(47, 12)) + ((nested_paddr >> 30) & 0x1ffu) * 8;
> > + if (!*ptep)
> > + *ptep = (vm_alloc_page_table(vm) & GENMASK(47, 12)) | PUD_TYPE_TABLE | PTE_VALID;
> > + ptep = addr_gpa2hva(vm, *ptep & GENMASK(47, 12)) + ((nested_paddr >> 21) & 0x1ffu) * 8;
> > + if (!*ptep)
> > + *ptep = (vm_alloc_page_table(vm) & GENMASK(47, 12)) | PMD_TYPE_TABLE | PTE_VALID;
> > + ptep = addr_gpa2hva(vm, *ptep & GENMASK(47, 12)) + ((nested_paddr >> 12) & 0x1ffu) * 8;
> > +
> > + pg_attr = PTE_AF | PTE_ATTRINDX(attr_idx) | PTE_TYPE_PAGE | PTE_VALID;
> > + pg_attr |= PTE_SHARED;
> > +
> > + *ptep = (paddr & GENMASK(47, 12)) | pg_attr;
> > +}
> > +
> > +void nested_map(struct kvm_vm *vm, vm_paddr_t guest_pgd,
> > + uint64_t nested_paddr, uint64_t paddr, uint64_t size)
> > +{
> > + size_t npages = size / SZ_4K;
> > +
> > + TEST_ASSERT(nested_paddr + size > nested_paddr, "Vaddr overflow");
> > + TEST_ASSERT(paddr + size > paddr, "Paddr overflow");
> > +
> > + while (npages--) {
> > + __nested_pg_map(vm, guest_pgd, nested_paddr, paddr, MT_NORMAL);
> > + nested_paddr += SZ_4K;
> > + paddr += SZ_4K;
> > + }
> > +}
> > +
> > +/*
> > + * Prepare an identity shadow page table that maps all the
> > + * physical pages in VM.
> > + */
> > +void nested_map_memslot(struct kvm_vm *vm, vm_paddr_t guest_pgd,
> > + uint32_t memslot)
> > +{
> > + sparsebit_idx_t i, last;
> > + struct userspace_mem_region *region =
> > + memslot2region(vm, memslot);
> > +
> > + i = (region->region.guest_phys_addr >> vm->page_shift) - 1;
> > + last = i + (region->region.memory_size >> vm->page_shift);
> > + for (;;) {
> > + i = sparsebit_next_clear(region->unused_phy_pages, i);
> > + if (i > last)
> > + break;
> > +
> > + nested_map(vm, guest_pgd,
> > + (uint64_t)i << vm->page_shift,
> > + (uint64_t)i << vm->page_shift,
> > + 1 << vm->page_shift);
> > + }
> > +}
> > +
> > void prepare_l2_stack(struct kvm_vm *vm, struct kvm_vcpu *vcpu)
> > {
> > size_t l2_stack_size;
> > @@ -32,7 +116,16 @@ void prepare_l2_stack(struct kvm_vm *vm, struct kvm_vcpu *vcpu)
> >
> > void prepare_hyp_state(struct kvm_vm *vm, struct kvm_vcpu *vcpu)
> > {
> > - vcpu_set_reg(vcpu, KVM_ARM64_SYS_REG(SYS_HCR_EL2), HCR_EL2_RW);
> > + vm_paddr_t guest_pgd;
> > +
> > + guest_pgd = vm_phy_pages_alloc(vm, 1,
> > + KVM_GUEST_PAGE_TABLE_MIN_PADDR,
> > + vm->memslots[MEM_REGION_PT]);
> > + nested_map_memslot(vm, guest_pgd, 0);
> > +
> > + vcpu_set_reg(vcpu, KVM_ARM64_SYS_REG(SYS_HCR_EL2), HCR_EL2_RW | HCR_EL2_VM);
> > + vcpu_set_reg(vcpu, KVM_ARM64_SYS_REG(SYS_VTTBR_EL2), guest_pgd);
> > + vcpu_set_reg(vcpu, KVM_ARM64_SYS_REG(SYS_VTCR_EL2), get_l1_vtcr());
> > }
> >
> > void prepare_eret_destination(struct kvm_vm *vm, struct kvm_vcpu *vcpu, void *l2_pc)
> > --
> > 2.43.0
> >
^ permalink raw reply
* Re: [PATCH v2 0/3] Inline helpers into Rust without full LTO
From: Arnd Bergmann @ 2026-03-26 21:33 UTC (permalink / raw)
To: Russell King, Christian Schrefl
Cc: Miguel Ojeda, Alice Ryhl, Ard Biesheuvel, Jamie Cunliffe,
Will Deacon, Catalin Marinas, Miguel Ojeda, Andreas Hindborg,
acourbot, Andrew Morton, Anton Ivanov, Björn Roy Baron,
Boqun Feng, Danilo Krummrich, David Gow, Gary Guo, Johannes Berg,
Justin Stitt, linux-arm-kernel, linux-kbuild, linux-kernel,
linux-mm, linux-um, llvm, Benno Lossin, Mark Rutland, mmaurer,
Bill Wendling, Nathan Chancellor, Nick Desaulniers,
Nicolas Schier, Nicolas Schier, Peter Zijlstra,
Richard Weinberger, rust-for-linux, Trevor Gross,
Uladzislau Rezki (Sony)
In-Reply-To: <acVOL5Psz6kHlhq2@shell.armlinux.org.uk>
On Thu, Mar 26, 2026, at 16:18, Russell King (Oracle) wrote:
> On Thu, Mar 26, 2026 at 03:31:26PM +0100, Christian Schrefl wrote:
>> On 3/26/26 2:47 PM, Miguel Ojeda wrote:
>> > On Thu, Mar 26, 2026 at 11:10 AM Alice Ryhl <aliceryhl@google.com> wrote:
>
> I'm not sure if this is still true, but I believe it used to be the case
> that the -linux-gnueabi target has one behaviour for enums (fixed size)
> whereas -none-eabi, the size of the type depends on the range of values
> included in the enum.
I checked Debian's arm-none-eabi-gcc, which indeed still has this behavior:
$ echo 'enum { A, B } x = sizeof(x);' | arm-none-eabi-gcc -xc - -O2 -o- -S | grep -A1 x:
x:
.byte 1
and I see the same thing for the hexagon target in clang, but none
of the other targets that Linux runs on. In particular, clang always
behaves like linux-gnueabi even when targeting plain eabi.
$ echo 'enum { A, B } x = sizeof(x);' | clang --target=arm-none-eabi -xc - -O2 -o- -S | grep -A1 x:
x:
.long 4
I noticed a similar issue with m68k-linux, which has a bitfield
alignment different from anything else on gcc, but uses the normal
behavior on clang.
Arnd
^ permalink raw reply
* [PATCH v2] arm64: defconfig: Enable Rockchip video decoder
From: Detlev Casanova @ 2026-03-26 21:33 UTC (permalink / raw)
To: linux-kernel, Heiko Stuebner, linux-arm-kernel, kernel,
linux-rockchip
Cc: Detlev Casanova
The rkvdec driver is now out of staging and can be built by default.
Signed-off-by: Detlev Casanova <detlev.casanova@collabora.com>
---
Changes in v2:
- Update commit message
- Add missing CCs
- Link to v1: https://patch.msgid.link/20260325-rkvdec-add-defconfig-v1-1-89a55d3bb5c4@collabora.com
---
arch/arm64/configs/defconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index b67d5b1fc45b..4b3f31cb4a94 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@ -931,6 +931,7 @@ CONFIG_VIDEO_RENESAS_VSP1=m
CONFIG_VIDEO_RCAR_DRIF=m
CONFIG_VIDEO_ROCKCHIP_CIF=m
CONFIG_VIDEO_ROCKCHIP_RGA=m
+CONFIG_VIDEO_ROCKCHIP_VDEC=m
CONFIG_VIDEO_SAMSUNG_EXYNOS_GSC=m
CONFIG_VIDEO_SAMSUNG_S5P_JPEG=m
CONFIG_VIDEO_SAMSUNG_S5P_MFC=m
---
base-commit: bbeb83d3182abe0d245318e274e8531e5dd7a948
change-id: 20260325-rkvdec-add-defconfig-eaa11ab14f1f
Best regards,
--
Detlev Casanova <detlev.casanova@collabora.com>
^ permalink raw reply related
* Re: [PATCH v3 00/13] This series adds support for the MediaTek MT7927 (Filogic 380) combo
From: Javier Tia @ 2026-03-26 21:09 UTC (permalink / raw)
To: Sean Wang
Cc: Felix Fietkau, Lorenzo Bianconi, Ryder Lee, Shayne Chen,
Sean Wang, Matthias Brugger, AngeloGioacchino Del Regno,
Ming Yen Hsieh, Deren Wu, linux-wireless, linux-kernel,
linux-arm-kernel, linux-mediatek, Marcin FM,
Cristian-Florin Radoi, George Salukvadze, Evgeny Kapusta,
Samu Toljamo, Ariel Rosenfeld, Chapuis Dario,
Thibaut François, 张旭涵
Hi Sean,
On Wed, Mar 26, 2026 Sean Wang wrote:
> This part patch 1-8 looks good overall. My only concern was a possible
> regression on mt7925, but now that the incorrect mt7925 320 MHz
> support has been fixed in the version, this should be fine.
Thank you. Patch 5 also had a build error (is_320mhz_supported()
called is_mt7927() before it was defined in patch 6). Fixed in v4
by using mt76_chip() directly.
> I am still thinking a bit more about patches 9-11. My current
> preference is to introduce the generic layer first, and then migrate
> the mt7925 and mt7927-specific parts on top of it.
> I will handle this part on my side, since I want to carefully compare
> the vendor driver with your changes first, and make sure the mt7925
> side is solid before moving the mt7927-related changes forward. For
> the mt7927-related work, I will make sure your contribution, as well
> as the work from the other volunteers, is properly preserved when I
> carry this forward.
Understood. v4 drops patches 9-13 so you have full control over
the DMA, HW init, band_idx, and PCI device ID enablement.
Regarding your feedback on v3 patch 13 (CNM quirk) - you suggested
folding the MT792x_FW_CAP_CNM force into mt792x_get_mac80211_ops()
instead of the post-hoc memcpy. Since the PCI IDs patch is now
part of your series, would you prefer to handle the CNM fix there
as well, or should I send a standalone patch for it ahead of your
DMA/init work?
> Similar to the BT side, I would prefer to have a dedicated Linux
> firmware for mt7927 WiFi.
Noted. The driver currently requests mediatek/mt7927/ paths. Once
a dedicated firmware is available we can adjust if needed.
v4 sent with patches 1-8 + ASPM/PM disable (9 patches):
https://lore.kernel.org/linux-wireless/20260326-mt7927-wifi-support-v4-v4-0-8ab465addcfe@jetm.me/T/#u
Best,
Javier
^ permalink raw reply
* Re: [PATCH 3/3] KVM: arm64: selftests: Enable stage-2 in NV preparation functions
From: Wei-Lin Chang @ 2026-03-26 21:16 UTC (permalink / raw)
To: Marc Zyngier
Cc: kvm, linux-kselftest, linux-arm-kernel, kvmarm, linux-kernel,
Paolo Bonzini, Shuah Khan, Oliver Upton, Joey Gouly,
Suzuki K Poulose, Zenghui Yu, Catalin Marinas, Will Deacon
In-Reply-To: <86mrzw468z.wl-maz@kernel.org>
On Wed, Mar 25, 2026 at 09:18:20AM +0000, Marc Zyngier wrote:
> On Wed, 25 Mar 2026 00:36:20 +0000,
> Wei-Lin Chang <weilin.chang@arm.com> wrote:
> >
> > Introduce library functions for setting up guest stage-2 page tables,
> > then use that to give L2 an identity mapped stage-2 and enable it.
> >
> > The translation and stage-2 page table built is simple, start level 0,
> > 4 levels, 4KB granules, normal cachable, 48-bit IA, 40-bit OA.
>
> That's a no go. The most common NV-capable out there can realistically
> only do 16kB at S2, and is limited to 36bit IPA. We can't really
> afford to say "too bad" and leave the main development platform behind.
Interesting, I didn't know that! I didn't consider the guest stage-2
granule size < host stage-2 granule size case either.
>
> >
> > The nested page table code is adapted from lib/x86/vmx.c.
>
> I guess this starting point is the main issue.
>
> >
> > Signed-off-by: Wei-Lin Chang <weilin.chang@arm.com>
> > ---
> > .../selftests/kvm/include/arm64/nested.h | 7 ++
> > .../selftests/kvm/include/arm64/processor.h | 9 ++
> > .../testing/selftests/kvm/lib/arm64/nested.c | 97 ++++++++++++++++++-
> > 3 files changed, 111 insertions(+), 2 deletions(-)
> >
> > diff --git a/tools/testing/selftests/kvm/include/arm64/nested.h b/tools/testing/selftests/kvm/include/arm64/nested.h
> > index 739ff2ee0161..0be10a775e48 100644
> > --- a/tools/testing/selftests/kvm/include/arm64/nested.h
> > +++ b/tools/testing/selftests/kvm/include/arm64/nested.h
> > @@ -6,6 +6,13 @@
> > #ifndef SELFTEST_KVM_NESTED_H
> > #define SELFTEST_KVM_NESTED_H
> >
> > +uint64_t get_l1_vtcr(void);
> > +
> > +void nested_map(struct kvm_vm *vm, vm_paddr_t guest_pgd,
> > + uint64_t nested_paddr, uint64_t paddr, uint64_t size);
> > +void nested_map_memslot(struct kvm_vm *vm, vm_paddr_t guest_pgd,
> > + uint32_t memslot);
> > +
> > void prepare_l2_stack(struct kvm_vm *vm, struct kvm_vcpu *vcpu);
> > void prepare_hyp_state(struct kvm_vm *vm, struct kvm_vcpu *vcpu);
> > void prepare_eret_destination(struct kvm_vm *vm, struct kvm_vcpu *vcpu, void *l2_pc);
> > diff --git a/tools/testing/selftests/kvm/include/arm64/processor.h b/tools/testing/selftests/kvm/include/arm64/processor.h
> > index ac97a1c436fc..5de2e932d95a 100644
> > --- a/tools/testing/selftests/kvm/include/arm64/processor.h
> > +++ b/tools/testing/selftests/kvm/include/arm64/processor.h
> > @@ -104,6 +104,15 @@
> > #define TCR_HA (UL(1) << 39)
> > #define TCR_DS (UL(1) << 59)
> >
> > +/* VTCR_EL2 specific flags */
> > +#define VTCR_EL2_T0SZ_BITS(x) ((UL(64) - (x)) << VTCR_EL2_T0SZ_SHIFT)
> > +
> > +#define VTCR_EL2_SL0_LV0_4K (UL(2) << VTCR_EL2_SL0_SHIFT)
> > +#define VTCR_EL2_SL0_LV1_4K (UL(1) << VTCR_EL2_SL0_SHIFT)
> > +#define VTCR_EL2_SL0_LV2_4K (UL(0) << VTCR_EL2_SL0_SHIFT)
> > +
> > +#define VTCR_EL2_PS_40_BITS (UL(2) << VTCR_EL2_PS_SHIFT)
> > +
> > /*
> > * AttrIndx[2:0] encoding (mapping attributes defined in the MAIR* registers).
> > */
> > diff --git a/tools/testing/selftests/kvm/lib/arm64/nested.c b/tools/testing/selftests/kvm/lib/arm64/nested.c
> > index 111d02f44cfe..910f8cd30f96 100644
> > --- a/tools/testing/selftests/kvm/lib/arm64/nested.c
> > +++ b/tools/testing/selftests/kvm/lib/arm64/nested.c
> > @@ -1,8 +1,11 @@
> > // SPDX-License-Identifier: GPL-2.0
> > /*
> > - * ARM64 Nested virtualization helpers
> > + * ARM64 Nested virtualization helpers, nested page table code adapted from
> > + * ../x86/vmx.c.
> > */
> >
> > +#include <linux/sizes.h>
> > +
> > #include "kvm_util.h"
> > #include "nested.h"
> > #include "processor.h"
> > @@ -18,6 +21,87 @@ static void hvc_handler(struct ex_regs *regs)
> > regs->pc = (u64)after_hvc;
> > }
> >
> > +uint64_t get_l1_vtcr(void)
> > +{
> > + return VTCR_EL2_PS_40_BITS | VTCR_EL2_TG0_4K | VTCR_EL2_ORGN0_WBWA |
> > + VTCR_EL2_IRGN0_WBWA | VTCR_EL2_SL0_LV0_4K | VTCR_EL2_T0SZ_BITS(48);
>
> Irk. See above.
>
> > +}
> > +
> > +static void __nested_pg_map(struct kvm_vm *vm, uint64_t guest_pgd,
> > + uint64_t nested_paddr, uint64_t paddr, uint64_t flags)
> > +{
> > + uint8_t attr_idx = flags & (PTE_ATTRINDX_MASK >> PTE_ATTRINDX_SHIFT);
> > + uint64_t pg_attr;
> > + uint64_t *ptep;
> > +
> > + TEST_ASSERT((nested_paddr % vm->page_size) == 0,
> > + "L2 IPA not on page boundary,\n"
> > + " nested_paddr: 0x%lx vm->page_size: 0x%x", nested_paddr, vm->page_size);
> > + TEST_ASSERT((paddr % vm->page_size) == 0,
> > + "Guest physical address not on page boundary,\n"
> > + " paddr: 0x%lx vm->page_size: 0x%x", paddr, vm->page_size);
> > + TEST_ASSERT((paddr >> vm->page_shift) <= vm->max_gfn,
> > + "Physical address beyond maximum supported,\n"
> > + " paddr: 0x%lx vm->max_gfn: 0x%lx vm->page_size: 0x%x",
> > + paddr, vm->max_gfn, vm->page_size);
> > +
> > + ptep = addr_gpa2hva(vm, guest_pgd) + ((nested_paddr >> 39) & 0x1ffu) * 8;
> > + if (!*ptep)
> > + *ptep = (vm_alloc_page_table(vm) & GENMASK(47, 12)) | PGD_TYPE_TABLE | PTE_VALID;
> > + ptep = addr_gpa2hva(vm, *ptep & GENMASK(47, 12)) + ((nested_paddr >> 30) & 0x1ffu) * 8;
> > + if (!*ptep)
> > + *ptep = (vm_alloc_page_table(vm) & GENMASK(47, 12)) | PUD_TYPE_TABLE | PTE_VALID;
> > + ptep = addr_gpa2hva(vm, *ptep & GENMASK(47, 12)) + ((nested_paddr >> 21) & 0x1ffu) * 8;
> > + if (!*ptep)
> > + *ptep = (vm_alloc_page_table(vm) & GENMASK(47, 12)) | PMD_TYPE_TABLE | PTE_VALID;
> > + ptep = addr_gpa2hva(vm, *ptep & GENMASK(47, 12)) + ((nested_paddr >> 12) & 0x1ffu) * 8;
> > +
> > + pg_attr = PTE_AF | PTE_ATTRINDX(attr_idx) | PTE_TYPE_PAGE | PTE_VALID;
> > + pg_attr |= PTE_SHARED;
> > +
> > + *ptep = (paddr & GENMASK(47, 12)) | pg_attr;
>
> Please use named constants, and write a page table generator that is
> independent of page, IA and OA sizes, as advertised to the guest.
Ack, and yes, I should absolutely consider what is advertised to the
guest...
Thanks,
Wei-Lin Chang
>
> Thanks,
>
> M.
>
> --
> Without deviation from the norm, progress is not possible.
^ permalink raw reply
* Re: [PATCH v2 0/3] Inline helpers into Rust without full LTO
From: Arnd Bergmann @ 2026-03-26 21:12 UTC (permalink / raw)
To: Miguel Ojeda, Marek Szyprowski, Robin Murphy, Danilo Krummrich,
Abdiel Janulgue, Daniel Almeida, Andreas Hindborg,
Christoph Hellwig
Cc: iommu, driver-core, acourbot, Andrew Morton, Alice Ryhl,
Anton Ivanov, Björn Roy Baron, Boqun Feng, David Gow,
Gary Guo, Johannes Berg, Justin Stitt, linux-arm-kernel,
linux-kbuild, linux-kernel, linux-mm, linux-um, Russell King,
llvm, Benno Lossin, Mark Rutland, mmaurer, Bill Wendling,
Nathan Chancellor, Nick Desaulniers, Nicolas Schier,
Nicolas Schier, Peter Zijlstra, Richard Weinberger,
rust-for-linux, Trevor Gross, Uladzislau Rezki (Sony),
Will Deacon, Geert Uytterhoeven
In-Reply-To: <20260322194616.89847-1-ojeda@kernel.org>
On Sun, Mar 22, 2026, at 20:46, Miguel Ojeda wrote:
> On Sun, 22 Mar 2026 20:21:59 +0100 Miguel Ojeda <ojeda@kernel.org> wrote:
>>
> BINDGEN rust/bindings/bindings_generated.rs - due to target
> missing
> In file included from rust/helpers/helpers.c:59:
> rust/helpers/dma.c:17:2: warning: static function 'dma_free_attrs'
> is used in an inline function with external linkage [-Wstatic-in-inline]
> 17 | dma_free_attrs(dev, size, cpu_addr, dma_handle,
> attrs);
> | ^
> rust/helpers/dma.c:12:1: note: use 'static' to give inline function
> 'rust_helper_dma_free_attrs' internal linkage
> 12 | __rust_helper void rust_helper_dma_free_attrs(struct device
> *dev, size_t size,
> | ^
> | static
>
> For some reason, `dma_free_attrs` is not marked `inline` in
> `include/linux/dma-mapping.h` to begin with, unlike the rest.
>
> Unless I am missing something and there is a reason for that, it looks
> like it has just been missing since it was added in commit ed6ccf10f24b
> ("dma-mapping: properly stub out the DMA API for !CONFIG_HAS_DMA").
>
> Do you want a patch?
I have an older patch to drop CONFIG_NO_DMA entirely, which
may be better here, since we know that nobody cares about the
empty stubs.
The only targets that 'select NO_DMA' today are m68k (sun3
and dragonball), sh2 and um, which are some of the targets
that don't have any DMA masters, but there is little downside
of enabling the DMA mapping interfaces on those as well.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
diff --git a/arch/m68k/Kconfig b/arch/m68k/Kconfig
index 11835eb59d94..19fb556357fc 100644
--- a/arch/m68k/Kconfig
+++ b/arch/m68k/Kconfig
@@ -38,7 +38,6 @@ config M68K
select MMU_GATHER_NO_RANGE if MMU
select MODULES_USE_ELF_REL
select MODULES_USE_ELF_RELA
- select NO_DMA if !MMU && !COLDFIRE
select OLD_SIGACTION
select OLD_SIGSUSPEND3
select UACCESS_MEMCPY if !MMU
diff --git a/arch/m68k/Kconfig.cpu b/arch/m68k/Kconfig.cpu
index c9a7e602d8a4..adc50396b87d 100644
--- a/arch/m68k/Kconfig.cpu
+++ b/arch/m68k/Kconfig.cpu
@@ -38,7 +38,6 @@ config SUN3
depends on MMU
select HAVE_ARCH_PFN_VALID
select LEGACY_TIMER_TICK
- select NO_DMA
select M68020
help
This option enables support for the Sun 3 series of workstations
@@ -558,4 +557,4 @@ config COLDFIRE_COHERENT_DMA
config M68K_NONCOHERENT_DMA
bool
default y
- depends on HAS_DMA && !COLDFIRE_COHERENT_DMA
+ depends on HAS_DMA && !COLDFIRE_COHERENT_DMA && !SUN3
diff --git a/arch/m68k/include/asm/pgtable_mm.h b/arch/m68k/include/asm/pgtable_mm.h
index 7501ff030c63..d095ae6c19f9 100644
--- a/arch/m68k/include/asm/pgtable_mm.h
+++ b/arch/m68k/include/asm/pgtable_mm.h
@@ -159,8 +159,10 @@ static inline void update_mmu_cache_range(struct vm_fault *vmf,
? (__pgprot((pgprot_val(prot) & _CACHEMASK040) | _PAGE_NOCACHE_S)) \
: (prot)))
+#ifndef CONFIG_SUN3
pgprot_t pgprot_dmacoherent(pgprot_t prot);
#define pgprot_dmacoherent(prot) pgprot_dmacoherent(prot)
+#endif
#endif /* CONFIG_COLDFIRE */
#endif /* !__ASSEMBLER__ */
diff --git a/arch/m68k/kernel/dma.c b/arch/m68k/kernel/dma.c
index 16063783aa80..c52584e024af 100644
--- a/arch/m68k/kernel/dma.c
+++ b/arch/m68k/kernel/dma.c
@@ -8,7 +8,7 @@
#include <linux/kernel.h>
#include <asm/cacheflush.h>
-#ifndef CONFIG_COLDFIRE
+#if !defined(CONFIG_COLDFIRE) && !defined(CONFIG_SUN3)
void arch_dma_prep_coherent(struct page *page, size_t size)
{
cache_push(page_to_phys(page), size);
diff --git a/arch/sh/Kconfig b/arch/sh/Kconfig
index d5795067befa..e246f295ec48 100644
--- a/arch/sh/Kconfig
+++ b/arch/sh/Kconfig
@@ -63,7 +63,6 @@ config SUPERH
select LOCK_MM_AND_FIND_VMA
select MODULES_USE_ELF_RELA
select NEED_SG_DMA_LENGTH
- select NO_DMA if !MMU && !DMA_COHERENT
select NO_GENERIC_PCI_IOPORT_MAP if PCI
select OLD_SIGACTION
select OLD_SIGSUSPEND
@@ -133,10 +132,10 @@ config SWAP_IO_SPACE
bool
config DMA_COHERENT
- bool
+ def_bool !MMU
config DMA_NONCOHERENT
- def_bool !NO_DMA && !DMA_COHERENT
+ def_bool !DMA_COHERENT
select ARCH_HAS_DMA_PREP_COHERENT
select ARCH_HAS_SYNC_DMA_FOR_DEVICE
select DMA_DIRECT_REMAP
diff --git a/arch/um/Kconfig b/arch/um/Kconfig
index 098cda44db22..dd3428a49614 100644
--- a/arch/um/Kconfig
+++ b/arch/um/Kconfig
@@ -25,7 +25,6 @@ config UML
select HAVE_DEBUG_KMEMLEAK
select HAVE_DEBUG_BUGVERBOSE
select HAVE_PAGE_SIZE_4KB
- select NO_DMA if !UML_DMA_EMULATION
select OF_EARLY_FLATTREE if OF
select GENERIC_IRQ_SHOW
select GENERIC_CPU_DEVICES
diff --git a/include/linux/dma-mapping.h b/include/linux/dma-mapping.h
index 677c51ab7510..a96a22f857f1 100644
--- a/include/linux/dma-mapping.h
+++ b/include/linux/dma-mapping.h
@@ -138,7 +138,6 @@ static inline void debug_dma_map_single(struct device *dev, const void *addr,
}
#endif /* CONFIG_DMA_API_DEBUG */
-#ifdef CONFIG_HAS_DMA
static inline int dma_mapping_error(struct device *dev, dma_addr_t dma_addr)
{
debug_dma_mapping_error(dev, dma_addr);
@@ -200,146 +199,6 @@ void *dma_vmap_noncontiguous(struct device *dev, size_t size,
void dma_vunmap_noncontiguous(struct device *dev, void *vaddr);
int dma_mmap_noncontiguous(struct device *dev, struct vm_area_struct *vma,
size_t size, struct sg_table *sgt);
-#else /* CONFIG_HAS_DMA */
-static inline dma_addr_t dma_map_page_attrs(struct device *dev,
- struct page *page, size_t offset, size_t size,
- enum dma_data_direction dir, unsigned long attrs)
-{
- return DMA_MAPPING_ERROR;
-}
-static inline void dma_unmap_page_attrs(struct device *dev, dma_addr_t addr,
- size_t size, enum dma_data_direction dir, unsigned long attrs)
-{
-}
-static inline dma_addr_t dma_map_phys(struct device *dev, phys_addr_t phys,
- size_t size, enum dma_data_direction dir, unsigned long attrs)
-{
- return DMA_MAPPING_ERROR;
-}
-static inline void dma_unmap_phys(struct device *dev, dma_addr_t addr,
- size_t size, enum dma_data_direction dir, unsigned long attrs)
-{
-}
-static inline unsigned int dma_map_sg_attrs(struct device *dev,
- struct scatterlist *sg, int nents, enum dma_data_direction dir,
- unsigned long attrs)
-{
- return 0;
-}
-static inline void dma_unmap_sg_attrs(struct device *dev,
- struct scatterlist *sg, int nents, enum dma_data_direction dir,
- unsigned long attrs)
-{
-}
-static inline int dma_map_sgtable(struct device *dev, struct sg_table *sgt,
- enum dma_data_direction dir, unsigned long attrs)
-{
- return -EOPNOTSUPP;
-}
-static inline dma_addr_t dma_map_resource(struct device *dev,
- phys_addr_t phys_addr, size_t size, enum dma_data_direction dir,
- unsigned long attrs)
-{
- return DMA_MAPPING_ERROR;
-}
-static inline void dma_unmap_resource(struct device *dev, dma_addr_t addr,
- size_t size, enum dma_data_direction dir, unsigned long attrs)
-{
-}
-static inline int dma_mapping_error(struct device *dev, dma_addr_t dma_addr)
-{
- return -ENOMEM;
-}
-static inline void *dma_alloc_attrs(struct device *dev, size_t size,
- dma_addr_t *dma_handle, gfp_t flag, unsigned long attrs)
-{
- return NULL;
-}
-static inline void dma_free_attrs(struct device *dev, size_t size,
- void *cpu_addr, dma_addr_t dma_handle, unsigned long attrs)
-{
-}
-static inline void *dmam_alloc_attrs(struct device *dev, size_t size,
- dma_addr_t *dma_handle, gfp_t gfp, unsigned long attrs)
-{
- return NULL;
-}
-static inline void dmam_free_coherent(struct device *dev, size_t size,
- void *vaddr, dma_addr_t dma_handle)
-{
-}
-static inline int dma_get_sgtable_attrs(struct device *dev,
- struct sg_table *sgt, void *cpu_addr, dma_addr_t dma_addr,
- size_t size, unsigned long attrs)
-{
- return -ENXIO;
-}
-static inline int dma_mmap_attrs(struct device *dev, struct vm_area_struct *vma,
- void *cpu_addr, dma_addr_t dma_addr, size_t size,
- unsigned long attrs)
-{
- return -ENXIO;
-}
-static inline bool dma_can_mmap(struct device *dev)
-{
- return false;
-}
-static inline bool dma_pci_p2pdma_supported(struct device *dev)
-{
- return false;
-}
-static inline int dma_set_mask(struct device *dev, u64 mask)
-{
- return -EIO;
-}
-static inline int dma_set_coherent_mask(struct device *dev, u64 mask)
-{
- return -EIO;
-}
-static inline u64 dma_get_required_mask(struct device *dev)
-{
- return 0;
-}
-static inline bool dma_addressing_limited(struct device *dev)
-{
- return false;
-}
-static inline size_t dma_max_mapping_size(struct device *dev)
-{
- return 0;
-}
-static inline size_t dma_opt_mapping_size(struct device *dev)
-{
- return 0;
-}
-static inline unsigned long dma_get_merge_boundary(struct device *dev)
-{
- return 0;
-}
-static inline struct sg_table *dma_alloc_noncontiguous(struct device *dev,
- size_t size, enum dma_data_direction dir, gfp_t gfp,
- unsigned long attrs)
-{
- return NULL;
-}
-static inline void dma_free_noncontiguous(struct device *dev, size_t size,
- struct sg_table *sgt, enum dma_data_direction dir)
-{
-}
-static inline void *dma_vmap_noncontiguous(struct device *dev, size_t size,
- struct sg_table *sgt)
-{
- return NULL;
-}
-static inline void dma_vunmap_noncontiguous(struct device *dev, void *vaddr)
-{
-}
-static inline int dma_mmap_noncontiguous(struct device *dev,
- struct vm_area_struct *vma, size_t size, struct sg_table *sgt)
-{
- return -EINVAL;
-}
-#endif /* CONFIG_HAS_DMA */
#ifdef CONFIG_IOMMU_DMA
/**
diff --git a/kernel/dma/Kconfig b/kernel/dma/Kconfig
index 0748091339f7..228a3566d344 100644
--- a/kernel/dma/Kconfig
+++ b/kernel/dma/Kconfig
@@ -1,12 +1,7 @@
# SPDX-License-Identifier: GPL-2.0-only
-config NO_DMA
- bool
-
config HAS_DMA
- bool
- depends on !NO_DMA
- default y
+ def_bool y
config DMA_OPS_HELPERS
bool
^ permalink raw reply related
* [PATCH v4 8/9] wifi: mt76: mt7925: use irq_map for chip-specific interrupt handling
From: Javier Tia @ 2026-03-26 21:12 UTC (permalink / raw)
To: Felix Fietkau, Lorenzo Bianconi, Ryder Lee, Shayne Chen,
Sean Wang, Matthias Brugger, AngeloGioacchino Del Regno,
Ming Yen Hsieh, Deren Wu
Cc: linux-wireless, linux-kernel, linux-arm-kernel, linux-mediatek,
Marcin FM, Cristian-Florin Radoi, George Salukvadze,
Evgeny Kapusta, Samu Toljamo, Ariel Rosenfeld, Chapuis Dario,
Thibaut François, 张旭涵
In-Reply-To: <20260326-mt7927-wifi-support-v4-v4-0-8ab465addcfe@jetm.me>
The mac_reset and resume paths use the hardcoded MT_INT_RX_DONE_ALL
constant (bits 0-2) to re-enable RX interrupts. This is correct for
MT7925 (RX rings 0, 1, 2) but wrong for chips using different ring
indices.
Define a per-chip irq_map with the correct RX interrupt enable bits and
replace hardcoded MT_INT_RX_DONE_ALL with irq_map field reads in the
resume and mac_reset paths. Add the MT7927 irq_map with interrupt bits
matching its RX ring layout (rings 4, 6, 7), selected at probe time
based on PCI device ID.
This ensures the correct interrupt bits are enabled regardless of the
chip variant.
Tested-by: Marcin FM <marcin@lgic.pl>
Tested-by: Cristian-Florin Radoi <radoi.chris@gmail.com>
Tested-by: George Salukvadze <giosal90@gmail.com>
Tested-by: Evgeny Kapusta <3193631@gmail.com>
Tested-by: Samu Toljamo <samu.toljamo@gmail.com>
Tested-by: Ariel Rosenfeld <ariel.rosenfeld.750@gmail.com>
Tested-by: Chapuis Dario <chapuisdario4@gmail.com>
Tested-by: Thibaut François <tibo@humeurlibre.fr>
Tested-by: 张旭涵 <Loong.0x00@gmail.com>
Signed-off-by: Javier Tia <floss@jetm.me>
---
drivers/net/wireless/mediatek/mt76/mt7925/pci.c | 21 +++++++++++++++++++--
drivers/net/wireless/mediatek/mt76/mt7925/pci_mac.c | 5 ++++-
drivers/net/wireless/mediatek/mt76/mt792x_regs.h | 3 +++
3 files changed, 26 insertions(+), 3 deletions(-)
diff --git a/drivers/net/wireless/mediatek/mt76/mt7925/pci.c b/drivers/net/wireless/mediatek/mt76/mt7925/pci.c
index f820d5aeb723..604c0e9ae7ba 100644
--- a/drivers/net/wireless/mediatek/mt76/mt7925/pci.c
+++ b/drivers/net/wireless/mediatek/mt76/mt7925/pci.c
@@ -266,6 +266,18 @@ static int mt7925_dma_init(struct mt792x_dev *dev)
return mt792x_dma_enable(dev);
}
+static const struct mt792x_irq_map mt7927_irq_map = {
+ .host_irq_enable = MT_WFDMA0_HOST_INT_ENA,
+ .tx = {
+ .all_complete_mask = MT_INT_TX_DONE_ALL,
+ .mcu_complete_mask = MT_INT_TX_DONE_MCU,
+ },
+ .rx = {
+ .data_complete_mask = MT7927_RX_DONE_INT_ENA4,
+ .wm_complete_mask = MT7927_RX_DONE_INT_ENA6,
+ .wm2_complete_mask = MT7927_RX_DONE_INT_ENA7,
+ },
+};
static int mt7925_pci_probe(struct pci_dev *pdev,
const struct pci_device_id *id)
{
@@ -310,6 +322,7 @@ static int mt7925_pci_probe(struct pci_dev *pdev,
struct mt76_bus_ops *bus_ops;
struct mt792x_dev *dev;
struct mt76_dev *mdev;
+ bool is_mt7927_hw;
u8 features;
int ret;
u16 cmd;
@@ -358,7 +371,8 @@ static int mt7925_pci_probe(struct pci_dev *pdev,
dev = container_of(mdev, struct mt792x_dev, mt76);
dev->fw_features = features;
dev->hif_ops = &mt7925_pcie_ops;
- dev->irq_map = &irq_map;
+ is_mt7927_hw = (pdev->device == 0x6639 || pdev->device == 0x7927);
+ dev->irq_map = is_mt7927_hw ? &mt7927_irq_map : &irq_map;
mt76_mmio_init(&dev->mt76, pcim_iomap_table(pdev)[0]);
tasklet_init(&mdev->irq_tasklet, mt792x_irq_tasklet, (unsigned long)dev);
@@ -549,7 +563,10 @@ static int _mt7925_pci_resume(struct device *device, bool restore)
mt76_wr(dev, MT_PCIE_MAC_INT_ENABLE, 0xff);
mt76_connac_irq_enable(&dev->mt76,
dev->irq_map->tx.all_complete_mask |
- MT_INT_RX_DONE_ALL | MT_INT_MCU_CMD);
+ dev->irq_map->rx.data_complete_mask |
+ dev->irq_map->rx.wm_complete_mask |
+ dev->irq_map->rx.wm2_complete_mask |
+ MT_INT_MCU_CMD);
mt76_set(dev, MT_MCU2HOST_SW_INT_ENA, MT_MCU_CMD_WAKE_RX_PCIE);
/* put dma enabled */
diff --git a/drivers/net/wireless/mediatek/mt76/mt7925/pci_mac.c b/drivers/net/wireless/mediatek/mt76/mt7925/pci_mac.c
index 3072850c2752..1626a3684082 100644
--- a/drivers/net/wireless/mediatek/mt76/mt7925/pci_mac.c
+++ b/drivers/net/wireless/mediatek/mt76/mt7925/pci_mac.c
@@ -118,7 +118,10 @@ int mt7925e_mac_reset(struct mt792x_dev *dev)
mt76_wr(dev, dev->irq_map->host_irq_enable,
dev->irq_map->tx.all_complete_mask |
- MT_INT_RX_DONE_ALL | MT_INT_MCU_CMD);
+ dev->irq_map->rx.data_complete_mask |
+ dev->irq_map->rx.wm_complete_mask |
+ dev->irq_map->rx.wm2_complete_mask |
+ MT_INT_MCU_CMD);
mt76_wr(dev, MT_PCIE_MAC_INT_ENABLE, 0xff);
err = mt792xe_mcu_fw_pmctrl(dev);
diff --git a/drivers/net/wireless/mediatek/mt76/mt792x_regs.h b/drivers/net/wireless/mediatek/mt76/mt792x_regs.h
index acf627aed609..a8c8d7d6f565 100644
--- a/drivers/net/wireless/mediatek/mt76/mt792x_regs.h
+++ b/drivers/net/wireless/mediatek/mt76/mt792x_regs.h
@@ -308,6 +308,9 @@
#define HOST_RX_DONE_INT_ENA1 BIT(1)
#define HOST_RX_DONE_INT_ENA2 BIT(2)
#define HOST_RX_DONE_INT_ENA3 BIT(3)
+#define MT7927_RX_DONE_INT_ENA4 BIT(12)
+#define MT7927_RX_DONE_INT_ENA6 BIT(14)
+#define MT7927_RX_DONE_INT_ENA7 BIT(15)
#define HOST_TX_DONE_INT_ENA0 BIT(4)
#define HOST_TX_DONE_INT_ENA1 BIT(5)
#define HOST_TX_DONE_INT_ENA2 BIT(6)
--
2.53.0
^ permalink raw reply related
* [PATCH v4 4/9] wifi: mt76: mt7925: populate EHT 320MHz MCS map in sta_rec
From: Javier Tia @ 2026-03-26 21:12 UTC (permalink / raw)
To: Felix Fietkau, Lorenzo Bianconi, Ryder Lee, Shayne Chen,
Sean Wang, Matthias Brugger, AngeloGioacchino Del Regno,
Ming Yen Hsieh, Deren Wu
Cc: linux-wireless, linux-kernel, linux-arm-kernel, linux-mediatek,
Marcin FM, Cristian-Florin Radoi, George Salukvadze,
Evgeny Kapusta, Samu Toljamo, Ariel Rosenfeld, Chapuis Dario,
Thibaut François, 张旭涵
In-Reply-To: <20260326-mt7927-wifi-support-v4-v4-0-8ab465addcfe@jetm.me>
The sta_rec_eht structure has a mcs_map_bw320 field, and the channel
width mapping includes NL80211_CHAN_WIDTH_320, but the 320MHz MCS/NSS
map was never copied from the station's EHT capabilities to the MCU TLV.
This prevents negotiation of 320MHz channel width even when both the
hardware and firmware advertise support for it.
Add the missing memcpy for the 320MHz MCS map, matching the existing
pattern for BW20, BW80, and BW160.
Tested-by: Marcin FM <marcin@lgic.pl>
Tested-by: Cristian-Florin Radoi <radoi.chris@gmail.com>
Tested-by: George Salukvadze <giosal90@gmail.com>
Tested-by: Evgeny Kapusta <3193631@gmail.com>
Tested-by: Samu Toljamo <samu.toljamo@gmail.com>
Tested-by: Ariel Rosenfeld <ariel.rosenfeld.750@gmail.com>
Tested-by: Chapuis Dario <chapuisdario4@gmail.com>
Tested-by: Thibaut François <tibo@humeurlibre.fr>
Tested-by: 张旭涵 <Loong.0x00@gmail.com>
Signed-off-by: Javier Tia <floss@jetm.me>
---
drivers/net/wireless/mediatek/mt76/mt7925/mcu.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/wireless/mediatek/mt76/mt7925/mcu.c b/drivers/net/wireless/mediatek/mt76/mt7925/mcu.c
index dd5ecb07947b..a7f27c5014d5 100644
--- a/drivers/net/wireless/mediatek/mt76/mt7925/mcu.c
+++ b/drivers/net/wireless/mediatek/mt76/mt7925/mcu.c
@@ -1683,6 +1683,7 @@ mt7925_mcu_sta_eht_tlv(struct sk_buff *skb, struct ieee80211_link_sta *link_sta)
memcpy(eht->mcs_map_bw20, &mcs_map->only_20mhz, sizeof(eht->mcs_map_bw20));
memcpy(eht->mcs_map_bw80, &mcs_map->bw._80, sizeof(eht->mcs_map_bw80));
memcpy(eht->mcs_map_bw160, &mcs_map->bw._160, sizeof(eht->mcs_map_bw160));
+ memcpy(eht->mcs_map_bw320, &mcs_map->bw._320, sizeof(eht->mcs_map_bw320));
}
static void
--
2.53.0
^ permalink raw reply related
* [PATCH v4 6/9] wifi: mt76: mt7925: add MT7927 chip ID helpers
From: Javier Tia @ 2026-03-26 21:12 UTC (permalink / raw)
To: Felix Fietkau, Lorenzo Bianconi, Ryder Lee, Shayne Chen,
Sean Wang, Matthias Brugger, AngeloGioacchino Del Regno,
Ming Yen Hsieh, Deren Wu
Cc: linux-wireless, linux-kernel, linux-arm-kernel, linux-mediatek,
Marcin FM, Cristian-Florin Radoi, George Salukvadze,
Evgeny Kapusta, Samu Toljamo, Ariel Rosenfeld, Chapuis Dario,
Thibaut François, 张旭涵
In-Reply-To: <20260326-mt7927-wifi-support-v4-v4-0-8ab465addcfe@jetm.me>
The MediaTek MT7927 (Filogic 380) combo chip uses MT7927 WiFi silicon
that is architecturally compatible with MT7925. Extend is_mt7925() to
match chip ID 0x7927, and add is_mt7927() for code paths that need
MT7927-specific handling.
Also add 0x7927 to is_mt76_fw_txp() to match MT7925's TXP format.
Tested-by: Marcin FM <marcin@lgic.pl>
Tested-by: Cristian-Florin Radoi <radoi.chris@gmail.com>
Tested-by: George Salukvadze <giosal90@gmail.com>
Tested-by: Evgeny Kapusta <3193631@gmail.com>
Tested-by: Samu Toljamo <samu.toljamo@gmail.com>
Tested-by: Ariel Rosenfeld <ariel.rosenfeld.750@gmail.com>
Tested-by: Chapuis Dario <chapuisdario4@gmail.com>
Tested-by: Thibaut François <tibo@humeurlibre.fr>
Tested-by: 张旭涵 <Loong.0x00@gmail.com>
Signed-off-by: Javier Tia <floss@jetm.me>
---
drivers/net/wireless/mediatek/mt76/mt76_connac.h | 8 +++++++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/mediatek/mt76/mt76_connac.h b/drivers/net/wireless/mediatek/mt76/mt76_connac.h
index 393a7952f86b..4a63ef4e5c34 100644
--- a/drivers/net/wireless/mediatek/mt76/mt76_connac.h
+++ b/drivers/net/wireless/mediatek/mt76/mt76_connac.h
@@ -174,7 +174,12 @@ extern const struct wiphy_wowlan_support mt76_connac_wowlan_support;
static inline bool is_mt7925(struct mt76_dev *dev)
{
- return mt76_chip(dev) == 0x7925;
+ return mt76_chip(dev) == 0x7925 || mt76_chip(dev) == 0x7927;
+}
+
+static inline bool is_mt7927(struct mt76_dev *dev)
+{
+ return mt76_chip(dev) == 0x7927;
}
static inline bool is_320mhz_supported(struct mt76_dev *dev)
@@ -277,6 +282,7 @@ static inline bool is_mt76_fw_txp(struct mt76_dev *dev)
case 0x7920:
case 0x7922:
case 0x7925:
+ case 0x7927:
case 0x7663:
case 0x7622:
return false;
--
2.53.0
^ permalink raw reply related
* [PATCH v4 9/9] wifi: mt76: mt7925: disable ASPM and runtime PM for MT7927
From: Javier Tia @ 2026-03-26 21:12 UTC (permalink / raw)
To: Felix Fietkau, Lorenzo Bianconi, Ryder Lee, Shayne Chen,
Sean Wang, Matthias Brugger, AngeloGioacchino Del Regno,
Ming Yen Hsieh, Deren Wu
Cc: linux-wireless, linux-kernel, linux-arm-kernel, linux-mediatek
In-Reply-To: <20260326-mt7927-wifi-support-v4-v4-0-8ab465addcfe@jetm.me>
Disable PCIe ASPM unconditionally for MT7927. The CONNINFRA power
domain and WFDMA register access are unreliable with PCIe L1 active,
causing throughput to drop from 1+ Gbps to ~200 Mbps.
Disable runtime PM and deep sleep for MT7927. The combo chip shares
a CONNINFRA power domain between WiFi (PCIe) and BT (USB).
SET_OWN/CLR_OWN transitions on the LPCTL register crash the BT
firmware, requiring a full power cycle to recover. PM enablement will
be addressed in a follow-up once safe power state transitions are
determined.
Signed-off-by: Javier Tia <floss@jetm.me>
---
drivers/net/wireless/mediatek/mt76/mt7925/init.c | 3 ++-
drivers/net/wireless/mediatek/mt76/mt7925/pci.c | 6 ++++--
2 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/net/wireless/mediatek/mt76/mt7925/init.c b/drivers/net/wireless/mediatek/mt76/mt7925/init.c
index 3ce5d6fcc69d..4766b9343953 100644
--- a/drivers/net/wireless/mediatek/mt76/mt7925/init.c
+++ b/drivers/net/wireless/mediatek/mt76/mt7925/init.c
@@ -230,7 +230,8 @@ int mt7925_register_device(struct mt792x_dev *dev)
dev->pm.idle_timeout = MT792x_PM_TIMEOUT;
dev->pm.stats.last_wake_event = jiffies;
dev->pm.stats.last_doze_event = jiffies;
- if (!mt76_is_usb(&dev->mt76)) {
+ /* MT7927: runtime PM crashes BT firmware on the shared CONNINFRA domain */
+ if (!mt76_is_usb(&dev->mt76) && !is_mt7927(&dev->mt76)) {
dev->pm.enable_user = true;
dev->pm.enable = true;
dev->pm.ds_enable_user = true;
diff --git a/drivers/net/wireless/mediatek/mt76/mt7925/pci.c b/drivers/net/wireless/mediatek/mt76/mt7925/pci.c
index 604c0e9ae7ba..1f05c212be02 100644
--- a/drivers/net/wireless/mediatek/mt76/mt7925/pci.c
+++ b/drivers/net/wireless/mediatek/mt76/mt7925/pci.c
@@ -350,7 +350,10 @@ static int mt7925_pci_probe(struct pci_dev *pdev,
if (ret)
goto err_free_pci_vec;
- if (mt7925_disable_aspm)
+ is_mt7927_hw = (pdev->device == 0x6639 || pdev->device == 0x7927);
+
+ /* MT7927: ASPM L1 causes unreliable WFDMA register access */
+ if (mt7925_disable_aspm || is_mt7927_hw)
mt76_pci_disable_aspm(pdev);
ops = mt792x_get_mac80211_ops(&pdev->dev, &mt7925_ops,
@@ -371,7 +374,6 @@ static int mt7925_pci_probe(struct pci_dev *pdev,
dev = container_of(mdev, struct mt792x_dev, mt76);
dev->fw_features = features;
dev->hif_ops = &mt7925_pcie_ops;
- is_mt7927_hw = (pdev->device == 0x6639 || pdev->device == 0x7927);
dev->irq_map = is_mt7927_hw ? &mt7927_irq_map : &irq_map;
mt76_mmio_init(&dev->mt76, pcim_iomap_table(pdev)[0]);
tasklet_init(&mdev->irq_tasklet, mt792x_irq_tasklet, (unsigned long)dev);
--
2.53.0
^ permalink raw reply related
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