* [PATCH v3 2/7] KVM: arm64: Forward FFA_NOTIFICATION_BITMAP calls to Trustzone
From: Sebastian Ene @ 2026-06-16 10:54 UTC (permalink / raw)
To: catalin.marinas, maz, oupton, will
Cc: joey.gouly, korneld, kvmarm, linux-arm-kernel, linux-kernel,
android-kvm, mrigendra.chaubey, perlarsen, sebastianene,
suzuki.poulose, vdonnefort, yuzenghui
In-Reply-To: <20260616105417.2578670-1-sebastianene@google.com>
Allow FF-A notification bitmap messages to be forwarded to
Trustzone from the host kernel driver enforce checking for
SBZ fields.
Signed-off-by: Sebastian Ene <sebastianene@google.com>
---
arch/arm64/kvm/hyp/nvhe/ffa.c | 28 ++++++++++++++++++++++++++--
1 file changed, 26 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/kvm/hyp/nvhe/ffa.c b/arch/arm64/kvm/hyp/nvhe/ffa.c
index c723a21006aa..dc7496ec295f 100644
--- a/arch/arm64/kvm/hyp/nvhe/ffa.c
+++ b/arch/arm64/kvm/hyp/nvhe/ffa.c
@@ -713,8 +713,6 @@ static bool ffa_call_supported(u64 func_id)
case FFA_MEM_DONATE:
case FFA_MEM_RETRIEVE_REQ:
/* Optional notification interfaces added in FF-A 1.1 */
- case FFA_NOTIFICATION_BITMAP_CREATE:
- case FFA_NOTIFICATION_BITMAP_DESTROY:
case FFA_NOTIFICATION_BIND:
case FFA_NOTIFICATION_UNBIND:
case FFA_NOTIFICATION_SET:
@@ -909,6 +907,28 @@ static void do_ffa_part_get(struct arm_smccc_1_2_regs *res,
hyp_spin_unlock(&host_buffers.lock);
}
+static void do_ffa_notif_bitmap(struct arm_smccc_1_2_regs *res,
+ struct kvm_cpu_context *ctxt)
+{
+ DECLARE_REG(u32, func_id, ctxt, 0);
+ DECLARE_REG(u32, vmid, ctxt, 1);
+ struct arm_smccc_1_2_regs *args;
+ u32 idx_unused_args = func_id == FFA_NOTIFICATION_BITMAP_CREATE ? 3 : 2;
+
+ if (ffa_check_unused_args_sbz(ctxt, idx_unused_args)) {
+ ffa_to_smccc_res(res, FFA_RET_INVALID_PARAMETERS);
+ return;
+ }
+
+ if (vmid != HOST_FFA_ID) {
+ ffa_to_smccc_res(res, FFA_RET_INVALID_PARAMETERS);
+ return;
+ }
+
+ args = (void *)&ctxt->regs.regs[0];
+ hyp_smccc_1_2_smc(args, res);
+}
+
bool kvm_host_ffa_handler(struct kvm_cpu_context *host_ctxt, u32 func_id)
{
struct arm_smccc_1_2_regs res;
@@ -967,6 +987,10 @@ bool kvm_host_ffa_handler(struct kvm_cpu_context *host_ctxt, u32 func_id)
case FFA_PARTITION_INFO_GET:
do_ffa_part_get(&res, host_ctxt);
goto out_handled;
+ case FFA_NOTIFICATION_BITMAP_CREATE:
+ case FFA_NOTIFICATION_BITMAP_DESTROY:
+ do_ffa_notif_bitmap(&res, host_ctxt);
+ goto out_handled;
}
if (ffa_call_supported(func_id))
--
2.54.0.1136.gdb2ca164c4-goog
^ permalink raw reply related
* [PATCH v3 1/7] KVM: arm64: Support FFA_NOTIFICATION_BITMAP_CREATE in host handler
From: Sebastian Ene @ 2026-06-16 10:54 UTC (permalink / raw)
To: catalin.marinas, maz, oupton, will
Cc: joey.gouly, korneld, kvmarm, linux-arm-kernel, linux-kernel,
android-kvm, mrigendra.chaubey, perlarsen, sebastianene,
suzuki.poulose, vdonnefort, yuzenghui
In-Reply-To: <20260616105417.2578670-1-sebastianene@google.com>
Allow FF-A notification bitmap creation messages to be forwarded to
Trustzone from the host and introduce a helper to check for SBZ
register fields.
Signed-off-by: Sebastian Ene <sebastianene@google.com>
---
arch/arm64/kvm/hyp/nvhe/ffa.c | 36 ++++++++++++++++++++++++++++++++++-
1 file changed, 35 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/kvm/hyp/nvhe/ffa.c b/arch/arm64/kvm/hyp/nvhe/ffa.c
index 1af722771178..b1e5f9ee86ef 100644
--- a/arch/arm64/kvm/hyp/nvhe/ffa.c
+++ b/arch/arm64/kvm/hyp/nvhe/ffa.c
@@ -71,6 +71,18 @@ static u32 hyp_ffa_version;
static bool has_version_negotiated;
static hyp_spinlock_t version_lock;
+static bool ffa_check_unused_args_sbz(struct kvm_cpu_context *ctxt, int first_reg)
+{
+ int reg;
+
+ for (reg = first_reg; reg < 17; reg++) {
+ if (cpu_reg(ctxt, reg))
+ return true;
+ }
+
+ return false;
+}
+
static void ffa_to_smccc_error(struct arm_smccc_1_2_regs *res, u64 ffa_errno)
{
*res = (struct arm_smccc_1_2_regs) {
@@ -676,7 +688,6 @@ static bool ffa_call_supported(u64 func_id)
case FFA_MEM_DONATE:
case FFA_MEM_RETRIEVE_REQ:
/* Optional notification interfaces added in FF-A 1.1 */
- case FFA_NOTIFICATION_BITMAP_CREATE:
case FFA_NOTIFICATION_BITMAP_DESTROY:
case FFA_NOTIFICATION_BIND:
case FFA_NOTIFICATION_UNBIND:
@@ -862,6 +873,26 @@ static void do_ffa_part_get(struct arm_smccc_1_2_regs *res,
hyp_spin_unlock(&host_buffers.lock);
}
+static void do_ffa_notif_bitmap(struct arm_smccc_1_2_regs *res,
+ struct kvm_cpu_context *ctxt)
+{
+ DECLARE_REG(u32, vmid, ctxt, 1);
+ struct arm_smccc_1_2_regs *args;
+
+ if (ffa_check_unused_args_sbz(ctxt, 3)) {
+ ffa_to_smccc_res(res, FFA_RET_INVALID_PARAMETERS);
+ return;
+ }
+
+ if (vmid != HOST_FFA_ID) {
+ ffa_to_smccc_res(res, FFA_RET_INVALID_PARAMETERS);
+ return;
+ }
+
+ args = (void *)&ctxt->regs.regs[0];
+ hyp_smccc_1_2_smc(args, res);
+}
+
bool kvm_host_ffa_handler(struct kvm_cpu_context *host_ctxt, u32 func_id)
{
struct arm_smccc_1_2_regs res;
@@ -920,6 +951,9 @@ bool kvm_host_ffa_handler(struct kvm_cpu_context *host_ctxt, u32 func_id)
case FFA_PARTITION_INFO_GET:
do_ffa_part_get(&res, host_ctxt);
goto out_handled;
+ case FFA_NOTIFICATION_BITMAP_CREATE:
+ do_ffa_notif_bitmap(&res, host_ctxt);
+ goto out_handled;
}
if (ffa_call_supported(func_id))
--
2.54.0.1099.g489fc7bff1-goog
^ permalink raw reply related
* [PATCH v3 2/7] KVM: arm64: Support FFA_NOTIFICATION_BITMAP_DESTROY in host handler
From: Sebastian Ene @ 2026-06-16 10:54 UTC (permalink / raw)
To: catalin.marinas, maz, oupton, will
Cc: joey.gouly, korneld, kvmarm, linux-arm-kernel, linux-kernel,
android-kvm, mrigendra.chaubey, perlarsen, sebastianene,
suzuki.poulose, vdonnefort, yuzenghui
In-Reply-To: <20260616105417.2578670-1-sebastianene@google.com>
Allow FF-A notification bitmap destruction messages to be forwarded to
Trustzone from the host.
Signed-off-by: Sebastian Ene <sebastianene@google.com>
---
arch/arm64/kvm/hyp/nvhe/ffa.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/kvm/hyp/nvhe/ffa.c b/arch/arm64/kvm/hyp/nvhe/ffa.c
index b1e5f9ee86ef..49a43c38a931 100644
--- a/arch/arm64/kvm/hyp/nvhe/ffa.c
+++ b/arch/arm64/kvm/hyp/nvhe/ffa.c
@@ -688,7 +688,6 @@ static bool ffa_call_supported(u64 func_id)
case FFA_MEM_DONATE:
case FFA_MEM_RETRIEVE_REQ:
/* Optional notification interfaces added in FF-A 1.1 */
- case FFA_NOTIFICATION_BITMAP_DESTROY:
case FFA_NOTIFICATION_BIND:
case FFA_NOTIFICATION_UNBIND:
case FFA_NOTIFICATION_SET:
@@ -876,10 +875,12 @@ static void do_ffa_part_get(struct arm_smccc_1_2_regs *res,
static void do_ffa_notif_bitmap(struct arm_smccc_1_2_regs *res,
struct kvm_cpu_context *ctxt)
{
+ DECLARE_REG(u32, func_id, ctxt, 0);
DECLARE_REG(u32, vmid, ctxt, 1);
struct arm_smccc_1_2_regs *args;
+ u32 idx_unused_args = func_id == FFA_NOTIFICATION_BITMAP_CREATE ? 3 : 2;
- if (ffa_check_unused_args_sbz(ctxt, 3)) {
+ if (ffa_check_unused_args_sbz(ctxt, idx_unused_args)) {
ffa_to_smccc_res(res, FFA_RET_INVALID_PARAMETERS);
return;
}
@@ -952,6 +953,7 @@ bool kvm_host_ffa_handler(struct kvm_cpu_context *host_ctxt, u32 func_id)
do_ffa_part_get(&res, host_ctxt);
goto out_handled;
case FFA_NOTIFICATION_BITMAP_CREATE:
+ case FFA_NOTIFICATION_BITMAP_DESTROY:
do_ffa_notif_bitmap(&res, host_ctxt);
goto out_handled;
}
--
2.54.0.1099.g489fc7bff1-goog
^ permalink raw reply related
* [PATCH v3 1/7] KVM: arm64: Enforce strict SBZ checks in the FF-A proxy
From: Sebastian Ene @ 2026-06-16 10:54 UTC (permalink / raw)
To: catalin.marinas, maz, oupton, will
Cc: joey.gouly, korneld, kvmarm, linux-arm-kernel, linux-kernel,
android-kvm, mrigendra.chaubey, perlarsen, sebastianene,
suzuki.poulose, vdonnefort, yuzenghui
In-Reply-To: <20260616105417.2578670-1-sebastianene@google.com>
Introduce a helper method ffa_check_unused_args_sbz to enforce strict
arguments checking when the hypervisor acts as a relayer between the
host and Trustzone.
Signed-off-by: Sebastian Ene <sebastianene@google.com>
---
arch/arm64/kvm/hyp/nvhe/ffa.c | 47 +++++++++++++++++++++++++++++++++++
1 file changed, 47 insertions(+)
diff --git a/arch/arm64/kvm/hyp/nvhe/ffa.c b/arch/arm64/kvm/hyp/nvhe/ffa.c
index 1af722771178..c723a21006aa 100644
--- a/arch/arm64/kvm/hyp/nvhe/ffa.c
+++ b/arch/arm64/kvm/hyp/nvhe/ffa.c
@@ -71,6 +71,18 @@ static u32 hyp_ffa_version;
static bool has_version_negotiated;
static hyp_spinlock_t version_lock;
+static bool ffa_check_unused_args_sbz(struct kvm_cpu_context *ctxt, int first_reg)
+{
+ int reg;
+
+ for (reg = first_reg; reg < 17; reg++) {
+ if (cpu_reg(ctxt, reg))
+ return true;
+ }
+
+ return false;
+}
+
static void ffa_to_smccc_error(struct arm_smccc_1_2_regs *res, u64 ffa_errno)
{
*res = (struct arm_smccc_1_2_regs) {
@@ -239,6 +251,11 @@ static void do_ffa_rxtx_map(struct arm_smccc_1_2_regs *res,
int ret = 0;
void *rx_virt, *tx_virt;
+ if (ffa_check_unused_args_sbz(ctxt, 4)) {
+ ret = FFA_RET_INVALID_PARAMETERS;
+ goto out;
+ }
+
if (npages != (KVM_FFA_MBOX_NR_PAGES * PAGE_SIZE) / FFA_PAGE_SIZE) {
ret = FFA_RET_INVALID_PARAMETERS;
goto out;
@@ -315,6 +332,11 @@ static void do_ffa_rxtx_unmap(struct arm_smccc_1_2_regs *res,
DECLARE_REG(u32, id, ctxt, 1);
int ret = 0;
+ if (ffa_check_unused_args_sbz(ctxt, 2)) {
+ ret = FFA_RET_INVALID_PARAMETERS;
+ goto out;
+ }
+
if (id != HOST_FFA_ID) {
ret = FFA_RET_INVALID_PARAMETERS;
goto out;
@@ -421,6 +443,11 @@ static void do_ffa_mem_frag_tx(struct arm_smccc_1_2_regs *res,
int ret = FFA_RET_INVALID_PARAMETERS;
u32 nr_ranges;
+ if (ffa_check_unused_args_sbz(ctxt, 5)) {
+ ffa_to_smccc_res(res, FFA_RET_INVALID_PARAMETERS);
+ return;
+ }
+
if (fraglen > KVM_FFA_MBOX_NR_PAGES * PAGE_SIZE)
goto out;
@@ -482,6 +509,11 @@ static void __do_ffa_mem_xfer(const u64 func_id,
u32 offset, nr_ranges, checked_offset;
int ret = 0;
+ if (ffa_check_unused_args_sbz(ctxt, 5)) {
+ ret = FFA_RET_INVALID_PARAMETERS;
+ goto out;
+ }
+
if (addr_mbz || npages_mbz || fraglen > len ||
fraglen > KVM_FFA_MBOX_NR_PAGES * PAGE_SIZE) {
ret = FFA_RET_INVALID_PARAMETERS;
@@ -581,6 +613,11 @@ static void do_ffa_mem_reclaim(struct arm_smccc_1_2_regs *res,
int ret = 0;
u64 handle;
+ if (ffa_check_unused_args_sbz(ctxt, 4)) {
+ ffa_to_smccc_res(res, FFA_RET_INVALID_PARAMETERS);
+ return;
+ }
+
handle = PACK_HANDLE(handle_lo, handle_hi);
hyp_spin_lock(&host_buffers.lock);
@@ -769,6 +806,11 @@ static void do_ffa_version(struct arm_smccc_1_2_regs *res,
{
DECLARE_REG(u32, ffa_req_version, ctxt, 1);
+ if (ffa_check_unused_args_sbz(ctxt, 2)) {
+ res->a0 = FFA_RET_NOT_SUPPORTED;
+ return;
+ }
+
if (FFA_MAJOR_VERSION(ffa_req_version) != 1) {
res->a0 = FFA_RET_NOT_SUPPORTED;
return;
@@ -818,6 +860,11 @@ static void do_ffa_part_get(struct arm_smccc_1_2_regs *res,
DECLARE_REG(u32, flags, ctxt, 5);
u32 count, partition_sz, copy_sz;
+ if (ffa_check_unused_args_sbz(ctxt, 6)) {
+ ffa_to_smccc_res(res, FFA_RET_INVALID_PARAMETERS);
+ return;
+ }
+
hyp_spin_lock(&host_buffers.lock);
if (!host_buffers.rx) {
ffa_to_smccc_res(res, FFA_RET_BUSY);
--
2.54.0.1136.gdb2ca164c4-goog
^ permalink raw reply related
* [PATCH v3 0/7] KVM: arm64: Forward FFA_NOTIFICATION* calls to TrustZone
From: Sebastian Ene @ 2026-06-16 10:54 UTC (permalink / raw)
To: catalin.marinas, maz, oupton, will
Cc: joey.gouly, korneld, kvmarm, linux-arm-kernel, linux-kernel,
android-kvm, mrigendra.chaubey, perlarsen, sebastianene,
suzuki.poulose, vdonnefort, yuzenghui
Remove the FFA_NOTIFICATION* calls from the blocklist used by the pKVM
FF-A proxy. This restriction was preventing the use of asynchronous
signaling mechanisms defined by the Arm FF-A specification to
communicate with the secure services.
While these calls are markes as optional, there is no reason why the
hypervisor proxy would block them because:
1. Host is the Sole Non-Secure Endpoint: The Host operates as the
only Non-Secure VM ID (VM ID 0) recognized by the Secure World.
Because all forwarded notifications are inherently attributed to
the Host by the SPMC, there is no risk of VM ID spoofing
originating from the Normal World.
2. No Memory Pointers or Addresses: The FFA_NOTIFICATION_* ABIs
operate strictly via register-based parameters, passing only
VM IDs, VCPU IDs, flags, and bitmaps. Because these calls do
not contain memory addresses, offsets, or pointers, forwarding
them doesn't pose a risk of memory-based confused deputy attack
(e.g., tricking the SPMC into overwriting protected memory).
While the pKVM proxy behaves as a relayer, it doesn't currently have its
own FF-A ID(only the host has the ID 0). The behavior of the setup
flow is covered by the spec in the: '10.9 Notification support without
a Hypervisor'.
---
Changes in v3:
- applied Will's suggestion to use the introduced method
ffa_check_unused_args_sbz for existing calls and added a new
patch in the beggining of the series to do this.
- merged the handling of
FFA_NOTIFICATION_BITMAP_CREATE/FFA_NOTIFICATION_BITMAP_DESTROY into
one patch as Vincent suggested and create one handler for both.
Changes in v2:
- enforce the MBZ/SBZ fields
- split the calls into separate patches
- rebase on 7.1-rc7
Link to v2:
https://lore.kernel.org/all/20260608165549.1479409-1-sebastianene@google.com/
Link to v1:
https://lore.kernel.org/all/20260501114447.2389222-2-sebastianene@google.com/
Sebastian Ene (7):
KVM: arm64: Enforce strict SBZ checks in the FF-A proxy
KVM: arm64: Forward FFA_NOTIFICATION_BITMAP calls to Trustzone
KVM: arm64: Support FFA_NOTIFICATION_BIND in host handler
KVM: arm64: Support FFA_NOTIFICATION_UNBIND in host handler
KVM: arm64: Support FFA_NOTIFICATION_SET in host handler
KVM: arm64: Support FFA_NOTIFICATION_GET in host handler
KVM: arm64: Support FFA_NOTIFICATION_INFO_GET in host handler
arch/arm64/kvm/hyp/nvhe/ffa.c | 205 ++++++++++++++++++++++++++++++++--
1 file changed, 197 insertions(+), 8 deletions(-)
--
2.54.0.1136.gdb2ca164c4-goog
^ permalink raw reply
* [PATCH] net: airoha: Fix QoS counter configuration for Tx-fwd channels
From: Wayen Yan @ 2026-06-16 10:50 UTC (permalink / raw)
To: netdev
Cc: lorenzo, horms, pabeni, kuba, edumazet, andrew+netdev,
angelogioacchino.delregno, matthias.bgg, linux-arm-kernel,
linux-mediatek
In airoha_qdma_init_qos_stats(), the Tx-fwd counter was incorrectly
using register index (i << 1) instead of ((i << 1) + 1). This caused
the Tx-fwd configuration to overwrite the Tx-cpu configuration for
each QoS channel, resulting in incorrect QoS statistics.
Fix by using the correct register index ((i << 1) + 1) for Tx-fwd
counter configuration.
Fixes: 20bf7d07c956 ("net: airoha: add QDMA support for Airoha EN7581 Ethernet")
Signed-off-by: Wayen Yan <win847@gmail.com>
---
drivers/net/ethernet/airoha/airoha_eth.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/airoha/airoha_eth.c b/drivers/net/ethernet/airoha/airoha_eth.c
index 31cdb11cd7..329988a840 100644
--- a/drivers/net/ethernet/airoha/airoha_eth.c
+++ b/drivers/net/ethernet/airoha/airoha_eth.c
@@ -1256,7 +1256,7 @@ static void airoha_qdma_init_qos_stats(struct airoha_qdma *qdma)
FIELD_PREP(CNTR_CHAN_MASK, i));
/* Tx-fwd transferred count */
airoha_qdma_wr(qdma, REG_CNTR_VAL((i << 1) + 1), 0);
- airoha_qdma_wr(qdma, REG_CNTR_CFG(i << 1),
+ airoha_qdma_wr(qdma, REG_CNTR_CFG((i << 1) + 1),
CNTR_EN_MASK | CNTR_ALL_QUEUE_EN_MASK |
CNTR_ALL_DSCP_RING_EN_MASK |
FIELD_PREP(CNTR_SRC_MASK, 1) |
--
2.51.0
^ permalink raw reply related
* [PATCH V1] arm64: dts: imx8mq-evk: add uart3 and bluetooth node
From: Sherry Sun (OSS) @ 2026-06-16 10:52 UTC (permalink / raw)
To: robh, krzk+dt, conor+dt, Frank.Li, s.hauer, kernel, festevam
Cc: imx, devicetree, linux-arm-kernel, linux-kernel, sherry.sun
From: Sherry Sun <sherry.sun@nxp.com>
Add uart3 and bluetooth node.
Signed-off-by: Sherry Sun <sherry.sun@nxp.com>
---
arch/arm64/boot/dts/freescale/imx8mq-evk.dts | 22 ++++++++++++++++++++
1 file changed, 22 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/imx8mq-evk.dts b/arch/arm64/boot/dts/freescale/imx8mq-evk.dts
index e7d87ea81b69..b9b03416aa39 100644
--- a/arch/arm64/boot/dts/freescale/imx8mq-evk.dts
+++ b/arch/arm64/boot/dts/freescale/imx8mq-evk.dts
@@ -498,6 +498,19 @@ &uart1 {
status = "okay";
};
+&uart3 { /* BT */
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_uart3>;
+ assigned-clocks = <&clk IMX8MQ_CLK_UART3>;
+ assigned-clock-parents = <&clk IMX8MQ_SYS1_PLL_80M>;
+ uart-has-rtscts;
+ status = "okay";
+
+ bluetooth {
+ compatible = "nxp,88w8987-bt";
+ };
+};
+
&usb3_phy1 {
status = "okay";
};
@@ -657,6 +670,15 @@ MX8MQ_IOMUXC_UART1_TXD_UART1_DCE_TX 0x49
>;
};
+ pinctrl_uart3: uart3grp {
+ fsl,pins = <
+ MX8MQ_IOMUXC_UART3_TXD_UART3_DCE_TX 0x49
+ MX8MQ_IOMUXC_UART3_RXD_UART3_DCE_RX 0x49
+ MX8MQ_IOMUXC_ECSPI1_MISO_UART3_DCE_CTS_B 0x49
+ MX8MQ_IOMUXC_ECSPI1_SS0_UART3_DCE_RTS_B 0x49
+ >;
+ };
+
pinctrl_usdhc1: usdhc1grp {
fsl,pins = <
MX8MQ_IOMUXC_SD1_CLK_USDHC1_CLK 0x83
base-commit: 8d6dbbbe3ba62de0a63e962ee004afb848c8e3ac
--
2.50.1
^ permalink raw reply related
* [PATCH] arm64: dts: imx93-kontron: Fix memory node
From: Frieder Schrempf @ 2026-06-16 10:43 UTC (permalink / raw)
To: Conor Dooley, devicetree, Frank Li, Frieder Schrempf, imx,
Krzysztof Kozlowski, linux-arm-kernel, linux-kernel, Rob Herring,
Sascha Hauer, Shawn Guo
Cc: Fabio Estevam, Pengutronix Kernel Team
From: Frieder Schrempf <frieder.schrempf@kontron.de>
The start address of the DRAM area is 0x80000000. The minimal
size of the DDR on the SoM is 1 GiB. Fix this.
Fixes: 2b52fd6035b7 ("arm64: dts: Add support for Kontron i.MX93 OSM-S SoM and BL carrier board")
Signed-off-by: Frieder Schrempf <frieder.schrempf@kontron.de>
---
arch/arm64/boot/dts/freescale/imx93-kontron-osm-s.dtsi | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/boot/dts/freescale/imx93-kontron-osm-s.dtsi b/arch/arm64/boot/dts/freescale/imx93-kontron-osm-s.dtsi
index c79b1df339db..f881912cde46 100644
--- a/arch/arm64/boot/dts/freescale/imx93-kontron-osm-s.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx93-kontron-osm-s.dtsi
@@ -15,9 +15,9 @@ aliases {
rtc1 = &bbnsm_rtc;
};
- memory@40000000 {
+ memory@80000000 {
device_type = "memory";
- reg = <0x0 0x40000000 0 0x80000000>;
+ reg = <0x0 0x80000000 0 0x40000000>;
};
chosen {
--
2.54.0
^ permalink raw reply related
* [PATCH] net: airoha: fix foe_check_time allocation size
From: Wayen Yan @ 2026-06-16 9:49 UTC (permalink / raw)
To: netdev
Cc: lorenzo, horms, pabeni, kuba, edumazet, andrew+netdev,
angelogioacchino.delregno, matthias.bgg, linux-arm-kernel,
linux-mediatek
foe_check_time is declared as u16 pointer but was allocated with
only ppe_num_entries bytes instead of ppe_num_entries * sizeof(u16).
When airoha_ppe_foe_verify_entry() is called with hash >= ppe_num_entries/2,
it writes beyond the allocated buffer, causing heap buffer overflow and
potential kernel crash.
Signed-off-by: Wayen Yan <win847@gmail.com>
---
drivers/net/ethernet/airoha/airoha_ppe.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/airoha/airoha_ppe.c b/drivers/net/ethernet/airoha/airoha_ppe.c
index 5c9dff6bcc..8fb8ecf909 100644
--- a/drivers/net/ethernet/airoha/airoha_ppe.c
+++ b/drivers/net/ethernet/airoha/airoha_ppe.c
@@ -1578,7 +1578,8 @@ int airoha_ppe_init(struct airoha_eth *eth)
return -ENOMEM;
}
- ppe->foe_check_time = devm_kzalloc(eth->dev, ppe_num_entries,
+ ppe->foe_check_time = devm_kzalloc(eth->dev,
+ ppe_num_entries * sizeof(*ppe->foe_check_time),
GFP_KERNEL);
if (!ppe->foe_check_time)
return -ENOMEM;
--
2.51.0
^ permalink raw reply related
* Re: [PATCH v3 3/3] arm64: dts: imx93-11x11-evk: Add DY1212W-4856 LVDS panel
From: Marco Felsch @ 2026-06-16 10:05 UTC (permalink / raw)
To: Liu Ying
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Frank Li,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam, Peng Fan,
devicetree, imx, linux-arm-kernel, linux-kernel
In-Reply-To: <20260610-imx93-ldb-v3-3-c9b65d742753@nxp.com>
On 26-06-10, Liu Ying wrote:
> DY1212W-4856 [1] is a 12.1" (WXGA) TFT LCD panel with LVDS interface.
> The panel's 40-pin connector allows it to be directly connected to
> i.MX93 11x11 EVK board.
>
> Link: https://www.nxp.com/design/design-center/development-boards-and-designs/dy1212w-4856-tft-lcd-panel-with-lvds-interface:DY1212W-4856 [1]
> Signed-off-by: Liu Ying <victor.liu@nxp.com>
> ---
> arch/arm64/boot/dts/freescale/Makefile | 4 ++
> .../freescale/imx93-11x11-evk-dy1212w-4856.dtso | 81 ++++++++++++++++++++++
> 2 files changed, 85 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/freescale/Makefile b/arch/arm64/boot/dts/freescale/Makefile
> index 8ddaab127ab9..dbe27d757c86 100644
> --- a/arch/arm64/boot/dts/freescale/Makefile
> +++ b/arch/arm64/boot/dts/freescale/Makefile
> @@ -588,6 +588,10 @@ dtb-$(CONFIG_ARCH_MXC) += imx93-9x9-qsb-ontat-kd50g21-40nt-a1.dtb
> dtb-$(CONFIG_ARCH_MXC) += imx93-9x9-qsb-tianma-tm050rdh03.dtb
>
> dtb-$(CONFIG_ARCH_MXC) += imx93-11x11-evk.dtb
> +
> +imx93-11x11-evk-dy1212w-4856-dtbs += imx93-11x11-evk.dtb imx93-11x11-evk-dy1212w-4856.dtbo
> +dtb-$(CONFIG_ARCH_MXC) += imx93-11x11-evk-dy1212w-4856.dtb
> +
> dtb-$(CONFIG_ARCH_MXC) += imx93-11x11-frdm.dtb
>
> imx93-11x11-frdm-pixpaper-dtbs += imx93-11x11-frdm.dtb imx93-11x11-frdm-pixpaper.dtbo
> diff --git a/arch/arm64/boot/dts/freescale/imx93-11x11-evk-dy1212w-4856.dtso b/arch/arm64/boot/dts/freescale/imx93-11x11-evk-dy1212w-4856.dtso
> new file mode 100644
> index 000000000000..35f7c5699e3a
> --- /dev/null
> +++ b/arch/arm64/boot/dts/freescale/imx93-11x11-evk-dy1212w-4856.dtso
> @@ -0,0 +1,81 @@
> +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> +/*
> + * Copyright 2026 NXP
> + */
> +
> +/dts-v1/;
> +/plugin/;
> +
> +#include <dt-bindings/clock/imx93-clock.h>
> +
> +&{/} {
> + panel-lvds {
> + compatible = "boe,ev121wxm-n10-1850";
> + backlight = <&backlight_lvds>;
> + power-supply = <&buck4>;
> +
> + panel-timing {
> + /*
> + * Set clock frequency to 71142858Hz to accommodate
> + * IMX93_CLK_VIDEO_PLL rate at 498000000Hz in a rate
> + * table.
> + */
> + clock-frequency = <71142858>;
> + hactive = <1280>;
> + vactive = <800>;
> + hfront-porch = <48>;
> + hback-porch = <80>;
> + hsync-len = <32>;
> + vfront-porch = <3>;
> + vback-porch = <14>;
> + vsync-len = <6>;
> + };
> +
> + port {
> + panel_lvds_in: endpoint {
> + remote-endpoint = <&ldb_lvds_ch0>;
> + };
> + };
> + };
> +};
> +
> +&backlight_lvds {
> + status = "okay";
> +};
> +
> +&lcdif {
> + status = "okay";
> +};
> +
> +&lvds_bridge {
> + status = "okay";
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port@1 {
> + reg = <1>;
> +
> + ldb_lvds_ch0: endpoint {
> + remote-endpoint = <&panel_lvds_in>;
> + };
> + };
> + };
You could just make use of the ldb_lvds_ch0 phandle you added previously
and drop the complete override.
Regards,
Marco
> +};
> +
> +&media_blk_ctrl {
> + assigned-clocks = <&clk IMX93_CLK_MEDIA_AXI>,
> + <&clk IMX93_CLK_MEDIA_APB>,
> + <&clk IMX93_CLK_MEDIA_DISP_PIX>,
> + <&clk IMX93_CLK_VIDEO_PLL>;
> + assigned-clock-parents = <&clk IMX93_CLK_SYS_PLL_PFD1>,
> + <&clk IMX93_CLK_SYS_PLL_PFD1_DIV2>,
> + <&clk IMX93_CLK_VIDEO_PLL>;
> + /*
> + * Set IMX93_CLK_MEDIA_DISP_PIX rate to 71142858Hz to accommodate
> + * IMX93_CLK_VIDEO_PLL rate at 498000000Hz in a rate table.
> + */
> + assigned-clock-rates = <400000000>, <133333333>, <71142858>, <498000000>;
> + status = "okay";
> +};
>
> --
> 2.43.0
>
>
--
#gernperDu
#CallMeByMyFirstName
Pengutronix e.K. | |
Steuerwalder Str. 21 | https://www.pengutronix.de/ |
31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-9 |
^ permalink raw reply
* Re: [PATCH 1/3] dt-bindings: phy: nuvoton,ma35d1-usb2-phy: extend for dual-port OTG support
From: Joey Lu @ 2026-06-16 10:01 UTC (permalink / raw)
To: Rob Herring (Arm)
Cc: Hui-Ping Chen, Neil Armstrong, Conor Dooley, Vinod Koul,
devicetree, Catalin Marinas, linux-arm-kernel,
Krzysztof Kozlowski, linux-kernel, Joey Lu, Jacky Huang,
Arnd Bergmann, linux-phy, Shan-Chun Hung
In-Reply-To: <178153082322.1456470.14205688450934768854.robh@kernel.org>
On 6/15/2026 9:40 PM, Rob Herring (Arm) wrote:
> On Mon, 15 Jun 2026 13:49:09 +0800, Joey Lu wrote:
>> The MA35D1 has two USB PHY ports managed by the same hardware block:
>>
>> - PHY0 (index 0): OTG port shared between the DWC2 gadget controller
>> and EHCI0/OHCI0 host controllers. A hardware mux follows the USB
>> ID pin automatically.
>>
>> - PHY1 (index 1): dedicated host-only port for EHCI1/OHCI1.
>>
>> Extend the existing binding to cover both ports:
>>
>> - The PHY node is now a child of the system-management syscon node
>> with a reg property. The nuvoton,sys phandle and clocks
>> properties are removed; the driver derives the regmap from its
>> parent, and clock gating is owned by each individual USB controller.
>>
>> - #phy-cells changes from 0 to 1: the cell selects the PHY port.
>>
>> - Two optional board-tuning properties are added: nuvoton,rcalcode
>> for per-port resistor trim and nuvoton,oc-active-high for
>> over-current polarity.
>>
>> Signed-off-by: Joey Lu <a0987203069@gmail.com>
>> ---
>> .../bindings/phy/nuvoton,ma35d1-usb2-phy.yaml | 62 ++++++++++++++-----
>> 1 file changed, 48 insertions(+), 14 deletions(-)
>>
> My bot found errors running 'make dt_binding_check' on your patch:
>
> yamllint warnings/errors:
>
> dtschema/dtc warnings/errors:
> /builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/phy/nuvoton,ma35d1-usb2-phy.example.dtb: system-management@40460000 (nuvoton,ma35d1-reset): '#address-cells', '#size-cells', 'usb-phy@60' do not match any of the regexes: '^pinctrl-[0-9]+$'
> from schema $id: http://devicetree.org/schemas/reset/nuvoton,ma35d1-reset.yaml
> /builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/phy/nuvoton,ma35d1-usb2-phy.example.dtb: system-management@40460000 (nuvoton,ma35d1-reset): compatible: ['nuvoton,ma35d1-reset', 'syscon', 'simple-mfd'] is too long
> from schema $id: http://devicetree.org/schemas/reset/nuvoton,ma35d1-reset.yaml
> /builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/phy/nuvoton,ma35d1-usb2-phy.example.dtb: system-management@40460000 (nuvoton,ma35d1-reset): reg: [[0, 1078329344], [0, 512]] is too long
> from schema $id: http://devicetree.org/schemas/reset/nuvoton,ma35d1-reset.yaml
>
> doc reference errors (make refcheckdocs):
>
> See https://patchwork.kernel.org/project/devicetree/patch/20260615054911.48821-2-a0987203069@gmail.com
>
> The base for the series is generally the latest rc1. A different dependency
> should be noted in *this* patch.
>
> If you already ran 'make dt_binding_check' and didn't see the above
> error(s), then make sure 'yamllint' is installed and dt-schema is up to
> date:
>
> pip3 install dtschema --upgrade
>
> Please check and re-submit after running the above command yourself. Note
> that DT_SCHEMA_FILES can be set to your schema file to speed up checking
> your schema. However, it must be unset to test all examples with your schema.
I will fix it.
^ permalink raw reply
* Re: [PATCH v2 0/7] KVM: arm64: Forward FFA_NOTIFICATION* calls to TrustZone
From: Sebastian Ene @ 2026-06-16 9:59 UTC (permalink / raw)
To: Vincent Donnefort
Cc: Will Deacon, catalin.marinas, maz, oupton, joey.gouly, korneld,
kvmarm, linux-arm-kernel, linux-kernel, android-kvm,
mrigendra.chaubey, perlarsen, suzuki.poulose, yuzenghui
In-Reply-To: <ailtCAcEaJIgZ5Ap@google.com>
On Wed, Jun 10, 2026 at 02:56:24PM +0100, Vincent Donnefort wrote:
> On Wed, Jun 10, 2026 at 01:23:04PM +0100, Will Deacon wrote:
> > On Wed, Jun 10, 2026 at 01:15:44PM +0100, Vincent Donnefort wrote:
> > > On Wed, Jun 10, 2026 at 11:15:14AM +0100, Will Deacon wrote:
> > > > On Wed, Jun 10, 2026 at 10:26:59AM +0100, Vincent Donnefort wrote:
> > > > > On Mon, Jun 08, 2026 at 04:55:42PM +0000, Sebastian Ene wrote:
> > > > > > Remove the FFA_NOTIFICATION* calls from the blocklist used by the pKVM
> > > > > > FF-A proxy. This restriction was preventing the use of asynchronous
> > > > > > signaling mechanisms defined by the Arm FF-A specification to
> > > > > > communicate with the secure services.
> > > > > > While these calls are markes as optional, there is no reason why the
> > > > > > hypervisor proxy would block them because:
> > > > > >
> > > > > > 1. Host is the Sole Non-Secure Endpoint: The Host operates as the
> > > > > > only Non-Secure VM ID (VM ID 0) recognized by the Secure World.
> > > > > > Because all forwarded notifications are inherently attributed to
> > > > > > the Host by the SPMC, there is no risk of VM ID spoofing
> > > > > > originating from the Normal World.
> > > > > >
> > > > > > 2. No Memory Pointers or Addresses: The FFA_NOTIFICATION_* ABIs
> > > > > > operate strictly via register-based parameters, passing only
> > > > > > VM IDs, VCPU IDs, flags, and bitmaps. Because these calls do
> > > > > > not contain memory addresses, offsets, or pointers, forwarding
> > > > > > them doesn't pose a risk of memory-based confused deputy attack
> > > > > > (e.g., tricking the SPMC into overwriting protected memory).
> > > > > >
> > > > > > While the pKVM proxy behaves as a relayer, it doesn't currently have its
> > > > > > own FF-A ID(only the host has the ID 0). The behavior of the setup
> > > > > > flow is covered by the spec in the: '10.9 Notification support without
> > > > > > a Hypervisor'.
> > > > >
> > > > > As it is only a relayer. Is it really important to check SBZ arguments and
> > > > > fields on behalf of Trustzone? It doesn't feel it brings any security. If the
> > > > > host passes broken arguments, I don't believe this puts pKVM at risk. Does it?
> > > >
> > > > I think the problem would be if an update to FF-A allocated some of the
> > > > currently SBZ bits to implement some functionality that we would want
> > > > to filter at EL2.
> > >
> > > I suppose that would bump the FF-A version and the proxy would reject it?
> >
> > Maybe? I don't think they'd _have_ to bump the version number.
> >
> > > If we really want to check for those arguments to be 0:
> > >
> > > * Shouldn't we extend this check to other FF-A invocations?
> >
> > yes, that's what the diff was doing in the reply here:
> >
> > https://lore.kernel.org/all/af3fW468-f1KXCrC@google.com/
> >
> > but, as I said here:
> >
> > https://lore.kernel.org/all/ahmxiFXXTupafbXw@willie-the-truck/
> >
> > I don't particularly like the table-driven indirection (the checks
> > should just be inlined).
>
> Ha, sorry I'm late to the party.
>
> Perhaps this series should start with adding ffa_check_unused_args_sbz() to the
> existing allowed FF-A invocations?
Right, after talking to Will a bit more on this I will add
ffa_check_unused_args_sbz() to the existing calls in the first part of
the series.
>
> >
> > > * Do we really want to also look into the !SBZ arguments to verify what we can?
> > > (I'm thinking about the checks on flags)
> >
> > For known arguments, we only need to verify things that can affect EL2.
> > I suspect we don't care about a bunch of it.
> >
> > Will
Thanks,
Sebastian
^ permalink raw reply
* Re: [PATCH v2 0/7] KVM: arm64: Forward FFA_NOTIFICATION* calls to TrustZone
From: Sebastian Ene @ 2026-06-16 9:57 UTC (permalink / raw)
To: Will Deacon
Cc: Vincent Donnefort, catalin.marinas, maz, oupton, joey.gouly,
korneld, kvmarm, linux-arm-kernel, linux-kernel, android-kvm,
mrigendra.chaubey, perlarsen, suzuki.poulose, yuzenghui
In-Reply-To: <ai_KQTJj4n1dZS6F@willie-the-truck>
On Mon, Jun 15, 2026 at 10:47:45AM +0100, Will Deacon wrote:
> On Mon, Jun 15, 2026 at 07:43:55AM +0000, Sebastian Ene wrote:
> > On Sun, Jun 14, 2026 at 10:29:34AM +0100, Will Deacon wrote:
> > > Yes, that part now seems to be missing.
> >
> > I am a bit worried to apply for all of them the check from the relayer
> > (ffa_check_unused_args_sbz) because of how it's written in the spec in
> > (11.2 Reserved parameter convention). To be more specific, there is no
> > mention of what the relayer is expected to do here (which is what hyp
> > does). It says 2 things:
> > 1. the caller (in this case the host driver) is expected to zero out
> > unused args
> > 2. the callee (Trustzone) ignores the values in these registers.
> >
> > If we enforce SBZ in the relayer but (1) doesn't comply with it, we will
> > introduce a regression. I left it on purpose without enforcing
> > ffa_check_unused_args_sbz for the others.
>
> I think that's ok -- if the caller isn't passing zeroes when it should,
> then it's already on borrowed (no pun intended!) time and it will need
> to be fixed.
Ok, thanks for the confirmation. Will include this and then spin a new
version of the patches.
>
> Will
Thanks,
Sebastian
^ permalink raw reply
* Re: [PATCH RFC 8/9] arm64: dts: qcom: shikra-cqs-evk: Enable ethernet0
From: Konrad Dybcio @ 2026-06-16 9:50 UTC (permalink / raw)
To: Mohd Ayaan Anwar, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Richard Cochran, Bjorn Andersson, Konrad Dybcio,
Maxime Coquelin, Alexandre Torgue, Russell King
Cc: linux-arm-msm, netdev, devicetree, linux-kernel, linux-stm32,
linux-arm-kernel
In-Reply-To: <20260612-shikra_ethernet-v1-8-f0f4a1d19929@oss.qualcomm.com>
On 6/11/26 8:37 PM, Mohd Ayaan Anwar wrote:
> Enable the first Gigabit Ethernet controller. The board layout is
> identical to the CQM EVK.
>
> Signed-off-by: Mohd Ayaan Anwar <mohd.anwar@oss.qualcomm.com>
> ---
> arch/arm64/boot/dts/qcom/shikra-cqs-evk.dts | 119 ++++++++++++++++++++++++++++
> 1 file changed, 119 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/qcom/shikra-cqs-evk.dts b/arch/arm64/boot/dts/qcom/shikra-cqs-evk.dts
> index 26ff8007a819e46bbc9ffa3dddc6fee6530a4a7a..1f2e4f6dd7cca436f62ba9f09cd328e5a2079095 100644
> --- a/arch/arm64/boot/dts/qcom/shikra-cqs-evk.dts
> +++ b/arch/arm64/boot/dts/qcom/shikra-cqs-evk.dts
> @@ -7,6 +7,7 @@
>
> #include "shikra-cqm-som.dtsi"
> #include "shikra-evk.dtsi"
> +#include <dt-bindings/net/ti-dp83867.h>
>
> / {
> model = "Qualcomm Technologies, Inc. Shikra CQS EVK";
> @@ -60,6 +61,92 @@ vreg_pmu_ch1: ldo4 {
> };
> };
>
> +ðernet0 {
> + status = "okay";
'status' should go last, with a \n before it
> + phy-handle = <ðphy0>;
> + phy-mode = "rgmii-id";
> +
> + pinctrl-names = "default";
> + pinctrl-0 = <ðernet0_defaults>;
property-n
property-names
in this order, please
[...]
> +&tlmm {
> + ethernet0_defaults: ethernet0-defaults-state {
s/defaults/default
Please move this definition to shikra.dtsi
> + rgmii-rx-pins {
> + pins = "gpio121", "gpio122", "gpio123",
> + "gpio124", "gpio125", "gpio126";
> + function = "rgmii";
> + bias-disable;
> + drive-strength = <16>;
Let's move drive-strength before bias (that's the order used in other
places)
> + };
> + rgmii-tx-pins {
Please separate subsequent subnodes with \n
> + pins = "gpio127", "gpio128", "gpio129",
> + "gpio130", "gpio131", "gpio132";
> + function = "rgmii";
> + bias-pull-up;
> + drive-strength = <16>;
> + };
> + rgmii-mdio-pins {
> + pins = "gpio133", "gpio134";
> + function = "rgmii";
> + bias-pull-up;
> + drive-strength = <16>;
> + };
> + };
> +
> + emac0_phy_en_hog: emac0-phy-en-hog {
> + gpio-hog;
> + gpios = <149 GPIO_ACTIVE_HIGH>;
> + output-high;
> + line-name = "emac0-phy-en";
> + };
This looks like a hack - what does this pin actually do?
Konrad
^ permalink raw reply
* Re: [PATCH v2 1/5] arm64: Rename page table BSS section to .bss..pgtbl
From: Ard Biesheuvel @ 2026-06-16 9:38 UTC (permalink / raw)
To: Frank Li, Ard Biesheuvel
Cc: linux-arm-kernel, linux-kernel, Will Deacon, Catalin Marinas,
Kevin Brodsky, Mark Brown, Marc Zyngier
In-Reply-To: <ajBcE3qfT7ldBNKG@lizhi-Precision-Tower-5810>
On Mon, 15 Jun 2026, at 22:09, Frank Li wrote:
> On Thu, Jun 04, 2026 at 05:11:53PM +0200, Ard Biesheuvel wrote:
>> From: Ard Biesheuvel <ardb@kernel.org>
>>
>> Rename the .pgdir.bss section to .bss..pgtbl so that the compiler will
>> notice the leading ".bss" and mark it as NOBITS by default (rather than
>> PROGBITS, which would take up space in Image binary, forcing all of the
>> preceding BSS to be emitted into the image as well). This supersedes the
>> NOLOAD linker directive, which achieves the same thing, and can be
>> therefore be dropped.
>>
>> Also, rename .pgdir to .pgtbl to be more generic, as page tables of
>> various levels will reside here.
>>
>> Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
>> ---
>
> I met boot failure for i.MX8QXP by this patch
>
> [ 0.823515] Unable to handle kernel paging request at virtual
> address ffff00000328f000
> [ 0.831116] Mem abort info:
> [ 0.833886] ESR = 0x0000000096000147
> [ 0.837622] EC = 0x25: DABT (current EL), IL = 32 bits
> [ 0.842923] SET = 0, FnV = 0
> [ 0.845961] EA = 0, S1PTW = 0
> [ 0.849088] FSC = 0x07: level 3 translation fault
> [ 0.853952] Data abort info:
> [ 0.856809] ISV = 0, ISS = 0x00000147, ISS2 = 0x00000000
> [ 0.862296] CM = 1, WnR = 1, TnD = 0, TagAccess = 0
> [ 0.867330] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0
> [ 0.872633] swapper pgtable: 4k pages, 48-bit VAs,
> pgdp=000000008211f000
> [ 0.879321] [ffff00000328f000] pgd=0000000000000000,
> p4d=18000008bffff403, pud=18000008bfffe403, pmd=18000008bffea403,
> pte=00e800008328ff06
> [ 0.891834] Internal error: Oops: 0000000096000147 [#1] SMP
> [ 0.897469] Modules linked in:
> [ 0.900514] CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Not tainted
> 7.1.0-rc1-00016-g63e0b6a5b693 #834 PREEMPT
> [ 0.909978] Hardware name: Freescale i.MX8QXP MEK (DT)
> [ 0.915104] pstate: 80000005 (Nzcv daif -PAN -UAO -TCO -DIT -SSBS
> BTYPE=--)
> [ 0.922053] pc : dcache_clean_inval_poc+0x24/0x48
> [ 0.926742] lr : kvm_arm_init+0xa78/0x1638
> [ 0.930828] sp : ffff80008318bd10
> [ 0.934127] x29: ffff80008318bd50 x28: 0000000000000000 x27:
> ffff00000328f000
> [ 0.941251] x26: 0000000000002000 x25: ffff80008219e000 x24:
> 0000000001002222
> [ 0.948374] x23: 0000000000000030 x22: ffff800081e850c0 x21:
> ffff800082b790d0
> [ 0.955498] x20: 0000000000000004 x19: ffff8000830a0000 x18:
> 0000000000000000
> [ 0.962622] x17: ffff800082f938b8 x16: ffff800082b8b4e0 x15:
> ffff800082b8b4b8
> [ 0.969746] x14: ffff80008308f0a0 x13: ffff800082b8b490 x12:
> ffff800082b8b530
> [ 0.976869] x11: ffff800082b8b508 x10: ffff80008308f140 x9 :
> ffff80008308f118
> [ 0.983993] x8 : ffff80008308f0f0 x7 : ffff80008308f0c8 x6 :
> ffff80008308f078
> [ 0.991117] x5 : ffff80008308f050 x4 : ffff800082b8b468 x3 :
> 000000000000003f
> [ 0.998240] x2 : 0000000000000040 x1 : ffff000003291000 x0 :
> ffff00000328f000
> [ 1.005367] Call trace:
> [ 1.007800] dcache_clean_inval_poc+0x24/0x48 (P)
> [ 1.012490] do_one_initcall+0x80/0x1c8
> [ 1.016310] kernel_init_freeable+0x208/0x2f0
> [ 1.020654] kernel_init+0x24/0x1e0
> [ 1.024131] ret_from_fork+0x10/0x20
> [ 1.027700] Code: 9ac32042 d1000443 8a230000 d503201f (d50b7e20)
> [ 1.033779] ---[ end trace 0000000000000000 ]---
> [ 1.038428] Kernel panic - not syncing: Attempted to kill init!
> exitcode=0x0000000b
> [ 1.046026] SMP: stopping secondary CPUs
> [ 1.049943] Kernel Offset: disabled
> [ 1.053408] CPU features: 0x00000000,00000008,00040021,0400421b
> [ 1.059316] Memory Limit: none
> [ 1.062359] ---[ end Kernel panic - not syncing: Attempted to kill
> init! exitcode=0x0000000b ]---
>
>
> Any idea?
>
Which tree is this based on?
^ permalink raw reply
* Re: [PATCH] arm64: futex: Consolidate 'old == new' check in __lsui_cmpxchg32()
From: Yeoreum Yun @ 2026-06-16 9:26 UTC (permalink / raw)
To: Will Deacon; +Cc: Catalin Marinas, linux-arm-kernel
In-Reply-To: <ah7md1ha86Anr7nb@willie-the-truck>
> On Tue, May 19, 2026 at 04:09:02PM +0100, Catalin Marinas wrote:
> > On Tue, May 19, 2026 at 10:08:22AM +0100, Will Deacon wrote:
> > > The LSUI futex implementation relies on a cmpxchg() loop to implement
> > > FUTEX_OP_XOR, as the architecture doesn't provide unprivileged *EOR
> > > atomics. Since the unprivileged 'CAST' instructions used to implement
> > > the cmpxchg() can only operate on 64-bit memory locations, the
> > > __lsui_cmpxchg32() helper function performs a song and dance to marshall
> > > the 32-bit futex value into the correct part of a 64-bit register and
> > > fill the remaining bytes with the neighbouring data.
> >
> > IIRC, the reason for the current __lsui_cmpxchg32() was not EOR but the
> > expected futex_atomic_cmpxchg_inatomic() semantics. Looking at it again,
> > we have wake_futex_pi() that does something else if the ret is 0 but the
> > value differs. Looking at it again, the caller of wake_futex_pi()
> > retries on -EAGAIN anyway, so I don't see a correctness issue, it will
> > eventually hit the condition.
>
> Hmm, but I think that means my patch does change the behaviour of
> wake_futex_pi() in an undesirable way. For example, futex_unlock_pi()
> will go round the retry loop for any change in the futex value, whereas
> before we would go back to userspace only if the TID changed.
>
> So I think we should swallow the -EAGAIN for the CAS-based cmpxchg() if
> the futex word has changed, along the lines of the diff below.
>
> Will
>
> --->8
>
> diff --git a/arch/arm64/include/asm/futex.h b/arch/arm64/include/asm/futex.h
> index db84a7b2de74..79c6d86c38a9 100644
> --- a/arch/arm64/include/asm/futex.h
> +++ b/arch/arm64/include/asm/futex.h
> @@ -215,14 +215,14 @@ __lsui_futex_atomic_eor(int oparg, u32 __user *uaddr, int *oval)
> static __always_inline int
> __lsui_futex_cmpxchg(u32 __user *uaddr, u32 oldval, u32 newval, u32 *oval)
> {
> + u32 curval = oldval;
> int ret;
>
> - /*
> - * Callers of futex_atomic_cmpxchg_inatomic() already retry on
> - * -EAGAIN, no need for another loop of max retries.
> - */
> - ret = __lsui_cmpxchg32(uaddr, &oldval, newval);
> - *oval = oldval;
> + ret = __lsui_cmpxchg32(uaddr, &curval, newval);
> + if (ret == -EAGAIN && curval != oldval)
> + ret = 0;
> +
> + *oval = curval;
> return ret;
> }
> #endif /* CONFIG_ARM64_LSUI */
Agree. It is good that this additional patch does not change
the existing behavior.
@Catalin, Could you check this please?
Thanks!
--
Sincerely,
Yeoreum Yun
^ permalink raw reply
* Re: [PATCH net-next v5 0/3] airoha: add the capability to configure GDM3/GDM4 as WAN/LAN on demand
From: Lorenzo Bianconi @ 2026-06-16 9:12 UTC (permalink / raw)
To: Jakub Kicinski
Cc: Andrew Lunn, David S. Miller, Eric Dumazet, Paolo Abeni,
linux-arm-kernel, linux-mediatek, netdev, Madhur Agrawal,
Alexander Lobakin
In-Reply-To: <20260615163713.665271a2@kernel.org>
[-- Attachment #1: Type: text/plain, Size: 435 bytes --]
> On Thu, 11 Jun 2026 23:55:50 +0200 Lorenzo Bianconi wrote:
> > net: airoha: use int instead of atomic_t for qdma users counter
> > net: airoha: refactor QDMA start/stop into reusable helpers
> > net: airoha: defer GDM3/GDM4 WAN mode and GDM2 loopback to QoS offload
>
> only the first patch applies cleanly right now
ack, I will repost missing ones as soon as net-next is open again.
Regards,
Lorenzo
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH v7 11/20] KVM: arm64: Enforce PMU event filter at vcpu_load()
From: wuyifan @ 2026-06-16 9:07 UTC (permalink / raw)
To: Colton Lewis, kvm
Cc: Alexandru Elisei, Paolo Bonzini, Jonathan Corbet, Russell King,
Catalin Marinas, Will Deacon, Marc Zyngier, Oliver Upton,
Mingwei Zhang, Joey Gouly, Suzuki K Poulose, Zenghui Yu,
Mark Rutland, Shuah Khan, Ganapatrao Kulkarni, James Clark,
linux-doc, linux-kernel, linux-arm-kernel, kvmarm,
linux-perf-users, linux-kselftest, wangyushan, fanghao11,
Zhou Wang, prime.zeng, xuwei5
In-Reply-To: <20260504211813.1804997-12-coltonlewis@google.com>
Hi Colton,
On 5/5/2026 5:18 AM, Colton Lewis wrote:
> + for_each_set_bit(i, &guest_counters, ARMPMU_MAX_HWEVENTS) {
> + if (i == ARMV8_PMU_CYCLE_IDX) {
> + val = __vcpu_sys_reg(vcpu, PMCCFILTR_EL0);
> + evsel = ARMV8_PMUV3_PERFCTR_CPU_CYCLES;
> + } else {
> + val = __vcpu_sys_reg(vcpu, PMEVTYPER0_EL0 + i);
> + evsel = val & kvm_pmu_event_mask(vcpu->kvm);
> + }
> +
> + guest_include_el2 = (val & ARMV8_PMU_INCLUDE_EL2);
> + val &= ~evtyper_clr;
> +
> + if (unlikely(is_hyp_ctxt(vcpu)) && guest_include_el2)
> + val &= ~ARMV8_PMU_EXCLUDE_EL1;
> +
> + if (vcpu->kvm->arch.pmu_filter &&
> + !test_bit(evsel, vcpu->kvm->arch.pmu_filter))
> + val |= evtyper_set;
> +
> + if (i == ARMV8_PMU_CYCLE_IDX) {
> + write_sysreg(val, pmccntr_el0);
This should be pmccfiltr_el0.
Writing the filter bits to pmccntr_el0 would corrupt the cycle count value.
> + } else {
> + write_sysreg(i, pmselr_el0);
> + write_sysreg(val, pmxevtyper_el0);
> + }
> + }
> +}
Thanks,
Yifan
^ permalink raw reply
* Re: [PATCH v2 2/2] iio: adc: add Axiado SARADC driver
From: Petar Stepanovic @ 2026-06-16 8:47 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Akhila Kavi, Prasad Bolisetty, Jonathan Cameron, David Lechner,
Nuno Sá, Andy Shevchenko, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Harshit Shah, linux-iio, devicetree,
linux-arm-kernel, linux-kernel
In-Reply-To: <aisPbXOB6cofF4_r@ashevche-desk.local>
On 6/11/2026 9:41 PM, Andy Shevchenko wrote:
>> +struct axiado_saradc {
>> + void __iomem *regs;
>> + struct clk *clk;
>> + unsigned long clk_rate;
>> + int vref_uV;
>> + struct mutex lock; /* Serializes ADC conversions. */
>> +};
> Is `pahole` satisfied with the chosen layout?
Thanks, Andy.
I checked it and found that the current layout can be improved. I will rearrange the structure members in v3 to avoid the layout issue.
I will also address the other comments in v3.
Regards,
Petar
^ permalink raw reply
* Re: [PATCH v2 2/2] iio: adc: add Axiado SARADC driver
From: Petar Stepanovic @ 2026-06-16 8:45 UTC (permalink / raw)
To: Jonathan Cameron
Cc: Akhila Kavi, Prasad Bolisetty, David Lechner, Nuno Sá,
Andy Shevchenko, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Harshit Shah, linux-iio, devicetree, linux-arm-kernel,
linux-kernel
In-Reply-To: <20260611110923.2f55d280@jic23-huawei>
On 6/11/2026 12:09 PM, Jonathan Cameron wrote:
>> +
>> +#define AX_SARADC_MANUAL_CTRL_EN(ch) \
>> + (AX_SARADC_MANUAL_CTRL_ENABLE | \
> Why tabs to place the \ above and spaces here? I don't mind
> that much which you use, but aim for consistency.
Thanks, Jonathan.
The indentation issue was not intentional. It was probably my mistake while copying and adjusting that code, and it looks like my editor replaced some tabs with spaces during the copy.
I will address all of these comments in v3 and clean up the formatting consistently across the driver.
[...]
>> +
>> + regval = FIELD_PREP(AX_SARADC_GLOBAL_CTRL_CH_EN_MASK,
>> + GENMASK(soc_data->num_channels - 1, 0)) |
> For readability that G should be under the a of the line above so it's
> obvious this line starts with a parameter of FIELD_PREP.
>
> The particular form of indentation you have here with an effective 8 spaces
> after the start of the function call seems to be something I'm commenting
> on a lot at the moment. Is some tool defaulting to that?
Yes, that was the same indentation issue. I will fix the |FIELD_PREP()|alignment in v3 and check the rest of the driver for the same pattern.
Regards,
Petar
^ permalink raw reply
* Re: [PATCH RFC v7 0/9] firmware: arm_scmi: vendors: Qualcomm Generic Vendor Extensions
From: Sudeep Holla @ 2026-06-16 8:27 UTC (permalink / raw)
To: Pragnesh Papaniya
Cc: Cristian Marussi, Rob Herring, Krzysztof Kozlowski, Sudeep Holla,
Conor Dooley, Sibi Sankar, MyungJoo Ham, Kyungmin Park,
Chanwoo Choi, Dmitry Osipenko, Thierry Reding, Jonathan Hunter,
Bjorn Andersson, Konrad Dybcio, Rajendra Nayak, Pankaj Patil,
linux-arm-msm, linux-kernel, arm-scmi, linux-arm-kernel,
devicetree, linux-pm, linux-tegra, Amir Vajid,
Ramakrishna Gottimukkula
In-Reply-To: <20260610-rfc_v7_scmi_memlat-v7-0-f3f68c608f25@oss.qualcomm.com>
On Wed, Jun 10, 2026 at 02:21:27PM +0530, Pragnesh Papaniya wrote:
> The QCOM SCMI vendor protocol provides a generic way of exposing a number of
> Qualcomm SoC specific features (like memory bus scaling) through a mixture of
> pre-determined algorithm strings and param_id pairs hosted on the SCMI
> controller. On Qualcomm Glymur and Hamoa SoCs, the memlat governor and the
> mechanism to control the various caches and RAM is hosted on the CPU Control
> Processor (CPUCP) and the method to tweak and start the governor is exposed
> through the QCOM SCMI Generic Extension Protocol.
>
> This series introduces the devfreq SCMI client driver that uses the MEMLAT
> algorithm string hosted on the QCOM SCMI Generic Extension Protocol to detect
> memory latency workloads and control frequency/level of the various memory
> buses (DDR/LLCC/DDR_QOS). DDR/LLCC/DDR_QOS are modelled as devfreq devices
> using the remote devfreq governor. This provides basic insight into device
> operation via trans_stat and lets userspace further tweak the parameters of
> the remote governor.
>
> trans_stat data for DDR/LLCC/DDR_QOS is now available with this series:
>
> From : To
> 315000000 479000000 545000000 725000000 840000000 959000000 1090000000 1211000000 time(ms)
> 315000000: 0 3 6 6 6 7 0 30 143956
> 479000000: 2 0 7 1 1 1 0 3 356
> 545000000: 7 6 0 5 5 0 0 10 1200
> 725000000: 3 0 5 0 6 1 0 6 2172
> 840000000: 8 2 3 2 0 4 0 12 1188
> 959000000: 3 0 1 2 2 0 0 13 272
> 1090000000: 0 0 0 0 0 0 0 0 0
> 1211000000: 35 4 11 5 11 8 0 0 21684
> Total transition : 253
>
> QCOM SCMI Generic Vendor protocol background:
> A lot of the vendor protocol numbers used internally were for
> debug/internal development purposes that were either highly SoC-specific
> or had to be disabled because some features were fused out during
> production. This led to a large number of vendor protocol numbers being
> quickly consumed and never released. Using a single generic vendor
> protocol with functionality abstracted behind algorithm strings gives us
> the flexibility of letting such functionality exist during initial
> development/debugging while still being able to expose mature features
> (like MEMLAT) once they have stabilised. The param_ids are expected to
> act as ABI for algorithm strings like MEMLAT.
>
Not sure if it was discussed in the previous versions or not, it would be
good if you can capture why some of bus scaling doesn't work with the existing
SCMI performance protocol and the monitors don't fit the MPAM mode.
Please capture them in 1/9 as a motivation for this vendor protocol. It will
then help to understand it better as I am still struggling to. Sorry for that.
--
Regards,
Sudeep
^ permalink raw reply
* [GIT PULL 3/4] soc: defconfig updates for 7.2
From: Arnd Bergmann @ 2026-06-16 8:18 UTC (permalink / raw)
To: Linus Torvalds
Cc: soc, linux-arm-kernel, Krzysztof Kozlowski, Linus Walleij,
linux-kernel
In-Reply-To: <40c8ebc3-d681-4dcf-b3f2-ce0d780c539e@app.fastmail.com>
The following changes since commit 7fd2df204f342fc17d1a0bfcd474b24232fb0f32:
Linux 7.1-rc2 (2026-05-03 14:21:25 -0700)
are available in the Git repository at:
https://git.kernel.org/pub/scm/linux/kernel/git/soc/soc.git tags/soc-defconfig-7.2
for you to fetch changes up to cccde8de2c72068051ff8351ae6f1e2a12718aa0:
Merge tag 'bst-arm64-emmc-driver-defconfig-for-v7.2' of https://github.com/BlackSesame-SoC/linux into soc/defconfig (2026-06-12 09:03:41 +0200)
----------------------------------------------------------------
soc: defconfig updates for 7.2
The main change this time is a cleanup series from Krzysztof Kozlowski
that updates the defconfig files to be more in sync with changes to
the Kconfig files that moved options around or removed the completely.
In addition, a number of drivers get enabled, in order to support
more hardware out of the box, as usual.
----------------------------------------------------------------
I originally sent this as 0/4, which was obviously a mistake.
Albert Yang (1):
arm64: defconfig: enable BST SDHCI controller
Arnd Bergmann (5):
Merge tag 'v7.2-qcom-pinctrl-defconfigs' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl into soc/defconfig
Merge tag 'cix-defconfig-v7.2-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/peter.chen/cix into soc/defconfig
Merge tag 'at91-defconfig-7.2' of https://git.kernel.org/pub/scm/linux/kernel/git/at91/linux into soc/defconfig
Merge tag 'imx-defconfig-7.2' of git://git.kernel.org/pub/scm/linux/kernel/git/frank.li/linux into soc/defconfig
Merge tag 'bst-arm64-emmc-driver-defconfig-for-v7.2' of https://github.com/BlackSesame-SoC/linux into soc/defconfig
Krzysztof Kozlowski (12):
pinctrl: qcom: Make important drivers default (2)
arm64: defconfig: Move entries to match savedefconfig
arm64: defconfig: Drop unused legacy netfilter options
arm64: defconfig: Drop default or selected drivers
arm64: defconfig: Drop unused Ethernet vendors
arm64: defconfig: Switch Ethernet drivers to modules
ARM: multi_v7_defconfig: Move entries to match savedefconfig
ARM: configs: Drop redundant I2C_DESIGNWARE_PLATFORM
ARM: configs: Drop redundant SND_ATMEL_SOC
ARM: multi_v7_defconfig: Cleanup redundant options
ARM: multi_v7_defconfig: Correct QCOM_RPMH and QCOM_RPMHPD
ARM: configs: Drop duplicated CONFIG_EXT4_FS
Manikandan Muralidharan (1):
ARM: configs: at91: sama7: add sama7d65 i3c-hci
Manivannan Sadhasivam (1):
arm64: defconfig: Enable PCI M.2 power sequencing driver
Maxime Ripard (1):
ARM: multi_v7_defconfig: Enable dma-buf heaps
Peter Chen (1):
arm64: defconfig: Enable CIX Sky1 pinctrl, PCIe host, and Cadence GPIO
Ryan Chen (1):
arm64: configs: Update defconfig for AST2700 platform support
Stefan Wahren (1):
arm64: defconfig: Enable DP83822 PHY driver
arch/arm/configs/at91_dt_defconfig | 1 -
arch/arm/configs/axm55xx_defconfig | 1 -
arch/arm/configs/dove_defconfig | 1 -
arch/arm/configs/ep93xx_defconfig | 1 -
arch/arm/configs/hisi_defconfig | 1 -
arch/arm/configs/mmp2_defconfig | 1 -
arch/arm/configs/multi_v5_defconfig | 1 -
arch/arm/configs/multi_v7_defconfig | 106 ++++-----
arch/arm/configs/mv78xx0_defconfig | 1 -
arch/arm/configs/pxa_defconfig | 2 -
arch/arm/configs/qcom_defconfig | 15 --
arch/arm/configs/sama5_defconfig | 1 -
arch/arm/configs/sama7_defconfig | 3 +-
arch/arm/configs/socfpga_defconfig | 1 -
arch/arm/configs/spear13xx_defconfig | 1 -
arch/arm/configs/spear3xx_defconfig | 1 -
arch/arm/configs/spear6xx_defconfig | 1 -
arch/arm64/configs/defconfig | 423 +++++++++++++++++------------------
18 files changed, 250 insertions(+), 312 deletions(-)
^ permalink raw reply
* Re: [PATCH v2] spi: uniphier: Fix completion initialization order before devm_request_irq()
From: Masami Hiramatsu @ 2026-06-16 8:16 UTC (permalink / raw)
To: Kunihiko Hayashi
Cc: Mark Brown, linux-spi, linux-arm-kernel, linux-kernel,
Sangyun Kim, Kyungwook Boo, stable, Masami Hiramatsu
In-Reply-To: <20260616011223.201357-1-hayashi.kunihiko@socionext.com>
On Tue, 16 Jun 2026 10:12:23 +0900
Kunihiko Hayashi <hayashi.kunihiko@socionext.com> wrote:
> The driver calls devm_request_irq() before initializing the completion
> used by the interrupt handler. Because the interrupt may occur immediately
> after devm_request_irq(), the handler may execute before init_completion().
>
> This may result in calling complete() on an uninitialized completion,
> causing undefined behavior. This has been observed with KASAN.
>
> Fix this by initializing the completion before registering the IRQ.
>
> Reported-by: Sangyun Kim <sangyun.kim@snu.ac.kr>
> Reported-by: Kyungwook Boo <bookyungwook@gmail.com>
> Fixes: 5ba155a4d4cc ("spi: add SPI controller driver for UniPhier SoC")
> Cc: stable@vger.kernel.org
> Cc: Masami Hiramatsu <mhiramat@kernel.org>
> Signed-off-by: Kunihiko Hayashi <hayashi.kunihiko@socionext.com>
Looks good to me.
Reviewed-by: Masami Hiramatsu (Google) <mhiramat@kernel.org>
> ---
> Changes in v2:
> - Rebase onto latest, no functional changes
BTW, please clarify the actual branch name instead of "latest".
Thanks,
>
> drivers/spi/spi-uniphier.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/spi/spi-uniphier.c b/drivers/spi/spi-uniphier.c
> index cc20fd11f03f..86fce9a571da 100644
> --- a/drivers/spi/spi-uniphier.c
> +++ b/drivers/spi/spi-uniphier.c
> @@ -656,6 +656,8 @@ static int uniphier_spi_probe(struct platform_device *pdev)
> priv->host = host;
> priv->is_save_param = false;
>
> + init_completion(&priv->xfer_done);
> +
> priv->base = devm_platform_get_and_ioremap_resource(pdev, 0, &res);
> if (IS_ERR(priv->base))
> return PTR_ERR(priv->base);
> @@ -679,8 +681,6 @@ static int uniphier_spi_probe(struct platform_device *pdev)
> return ret;
> }
>
> - init_completion(&priv->xfer_done);
> -
> clk_rate = clk_get_rate(priv->clk);
>
> host->max_speed_hz = DIV_ROUND_UP(clk_rate, SSI_MIN_CLK_DIVIDER);
> --
> 2.34.1
>
--
Masami Hiramatsu (Google) <mhiramat@kernel.org>
^ permalink raw reply
* [soc:for-next] BUILD SUCCESS 972ea78305bddb6a1db0586357914f125e913ffe
From: kernel test robot @ 2026-06-16 8:02 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: linux-arm-kernel, arm
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/soc/soc.git for-next
branch HEAD: 972ea78305bddb6a1db0586357914f125e913ffe soc: document merges
elapsed time: 835m
configs tested: 258
configs skipped: 3
The following configs have been built successfully.
More configs may be tested in the coming days.
tested configs:
alpha allnoconfig gcc-16.1.0
alpha allyesconfig gcc-16.1.0
alpha defconfig gcc-16.1.0
arc allmodconfig clang-23
arc allmodconfig gcc-16.1.0
arc allnoconfig gcc-16.1.0
arc allyesconfig clang-23
arc allyesconfig gcc-16.1.0
arc defconfig gcc-16.1.0
arc randconfig-001-20260616 gcc-9.5.0
arc randconfig-002-20260616 gcc-9.5.0
arm allnoconfig clang-23
arm allnoconfig gcc-16.1.0
arm allyesconfig clang-23
arm allyesconfig gcc-16.1.0
arm defconfig gcc-16.1.0
arm randconfig-001-20260616 gcc-9.5.0
arm randconfig-002-20260616 gcc-9.5.0
arm randconfig-003-20260616 gcc-9.5.0
arm randconfig-004-20260616 gcc-9.5.0
arm64 allmodconfig clang-23
arm64 allnoconfig gcc-16.1.0
arm64 defconfig gcc-16.1.0
arm64 randconfig-001-20260616 gcc-13.4.0
arm64 randconfig-001-20260616 gcc-8.5.0
arm64 randconfig-002-20260616 gcc-13.4.0
arm64 randconfig-002-20260616 gcc-15.2.0
arm64 randconfig-003-20260616 gcc-13.4.0
arm64 randconfig-004-20260616 gcc-11.5.0
arm64 randconfig-004-20260616 gcc-13.4.0
csky allmodconfig gcc-16.1.0
csky allnoconfig gcc-16.1.0
csky defconfig gcc-16.1.0
csky randconfig-001-20260616 gcc-13.4.0
csky randconfig-001-20260616 gcc-15.2.0
csky randconfig-002-20260616 gcc-13.4.0
hexagon allmodconfig gcc-16.1.0
hexagon allnoconfig clang-23
hexagon allnoconfig gcc-16.1.0
hexagon defconfig gcc-16.1.0
hexagon randconfig-001 gcc-11.5.0
hexagon randconfig-001-20260616 clang-23
hexagon randconfig-001-20260616 gcc-11.5.0
hexagon randconfig-002 gcc-11.5.0
hexagon randconfig-002-20260616 clang-23
hexagon randconfig-002-20260616 gcc-11.5.0
i386 allmodconfig clang-22
i386 allmodconfig gcc-14
i386 allnoconfig gcc-14
i386 allnoconfig gcc-16.1.0
i386 allyesconfig clang-22
i386 allyesconfig gcc-14
i386 buildonly-randconfig-001-20260616 clang-22
i386 buildonly-randconfig-002-20260616 clang-22
i386 buildonly-randconfig-003-20260616 clang-22
i386 buildonly-randconfig-004-20260616 clang-22
i386 buildonly-randconfig-005-20260616 clang-22
i386 buildonly-randconfig-006-20260616 clang-22
i386 defconfig gcc-16.1.0
i386 randconfig-001-20260616 gcc-14
i386 randconfig-002-20260616 gcc-14
i386 randconfig-003-20260616 gcc-14
i386 randconfig-004-20260616 gcc-14
i386 randconfig-005-20260616 gcc-14
i386 randconfig-006-20260616 gcc-14
i386 randconfig-007-20260616 gcc-14
i386 randconfig-011 clang-22
i386 randconfig-011-20260616 clang-22
i386 randconfig-011-20260616 gcc-14
i386 randconfig-012 clang-22
i386 randconfig-012-20260616 clang-22
i386 randconfig-012-20260616 gcc-14
i386 randconfig-013 gcc-14
i386 randconfig-013-20260616 clang-22
i386 randconfig-013-20260616 gcc-14
i386 randconfig-014 clang-22
i386 randconfig-014-20260616 clang-22
i386 randconfig-014-20260616 gcc-14
i386 randconfig-015 gcc-14
i386 randconfig-015-20260616 clang-22
i386 randconfig-015-20260616 gcc-14
i386 randconfig-016 gcc-14
i386 randconfig-016-20260616 clang-22
i386 randconfig-017 gcc-14
i386 randconfig-017-20260616 clang-22
loongarch allmodconfig clang-19
loongarch allmodconfig clang-23
loongarch allnoconfig clang-20
loongarch allnoconfig gcc-16.1.0
loongarch defconfig clang-23
loongarch loongson64_defconfig clang-23
loongarch randconfig-001 gcc-11.5.0
loongarch randconfig-001-20260616 clang-23
loongarch randconfig-001-20260616 gcc-11.5.0
loongarch randconfig-002 gcc-11.5.0
loongarch randconfig-002-20260616 clang-23
loongarch randconfig-002-20260616 gcc-11.5.0
m68k allmodconfig gcc-16.1.0
m68k allnoconfig gcc-16.1.0
m68k allyesconfig clang-23
m68k allyesconfig gcc-16.1.0
m68k defconfig clang-23
microblaze allnoconfig gcc-16.1.0
microblaze allyesconfig gcc-16.1.0
microblaze defconfig clang-23
mips allmodconfig gcc-16.1.0
mips allnoconfig gcc-16.1.0
mips allyesconfig gcc-16.1.0
nios2 allmodconfig clang-20
nios2 allmodconfig gcc-11.5.0
nios2 allnoconfig clang-23
nios2 allnoconfig gcc-11.5.0
nios2 defconfig clang-23
nios2 randconfig-001 gcc-11.5.0
nios2 randconfig-001-20260616 clang-23
nios2 randconfig-001-20260616 gcc-11.5.0
nios2 randconfig-002 gcc-11.5.0
nios2 randconfig-002-20260616 clang-23
nios2 randconfig-002-20260616 gcc-11.5.0
openrisc allmodconfig clang-20
openrisc allnoconfig clang-23
openrisc allnoconfig gcc-16.1.0
openrisc defconfig gcc-16.1.0
parisc allmodconfig gcc-16.1.0
parisc allnoconfig clang-23
parisc allnoconfig gcc-16.1.0
parisc allyesconfig clang-17
parisc allyesconfig gcc-16.1.0
parisc defconfig gcc-16.1.0
parisc randconfig-001 gcc-8.5.0
parisc randconfig-001-20260616 gcc-8.5.0
parisc randconfig-002 gcc-8.5.0
parisc randconfig-002-20260616 gcc-8.5.0
parisc64 defconfig clang-23
powerpc allmodconfig gcc-16.1.0
powerpc allnoconfig clang-23
powerpc allnoconfig gcc-16.1.0
powerpc ep88xc_defconfig gcc-16.1.0
powerpc pmac32_defconfig clang-23
powerpc randconfig-001 gcc-8.5.0
powerpc randconfig-001-20260616 gcc-8.5.0
powerpc randconfig-002 gcc-8.5.0
powerpc randconfig-002-20260616 gcc-8.5.0
powerpc64 randconfig-001 gcc-8.5.0
powerpc64 randconfig-001-20260616 gcc-8.5.0
powerpc64 randconfig-002 gcc-8.5.0
powerpc64 randconfig-002-20260616 gcc-8.5.0
riscv allmodconfig clang-23
riscv allnoconfig clang-23
riscv allnoconfig gcc-16.1.0
riscv allyesconfig clang-23
riscv defconfig gcc-16.1.0
riscv randconfig-001 gcc-16.1.0
riscv randconfig-001-20260616 gcc-16.1.0
riscv randconfig-001-20260616 gcc-9.5.0
riscv randconfig-002 gcc-16.1.0
riscv randconfig-002-20260616 clang-23
riscv randconfig-002-20260616 gcc-16.1.0
s390 allmodconfig clang-17
s390 allmodconfig clang-23
s390 allnoconfig clang-23
s390 allyesconfig gcc-16.1.0
s390 defconfig gcc-16.1.0
s390 randconfig-001 gcc-16.1.0
s390 randconfig-001-20260616 clang-23
s390 randconfig-001-20260616 gcc-16.1.0
s390 randconfig-002 gcc-16.1.0
s390 randconfig-002-20260616 clang-18
s390 randconfig-002-20260616 gcc-16.1.0
sh allmodconfig gcc-16.1.0
sh allnoconfig clang-23
sh allnoconfig gcc-16.1.0
sh allyesconfig clang-17
sh allyesconfig gcc-16.1.0
sh defconfig gcc-14
sh randconfig-001 gcc-16.1.0
sh randconfig-001-20260616 gcc-16.1.0
sh randconfig-002 gcc-16.1.0
sh randconfig-002-20260616 gcc-13.4.0
sh randconfig-002-20260616 gcc-16.1.0
sh se7721_defconfig gcc-16.1.0
sparc allnoconfig clang-23
sparc allnoconfig gcc-16.1.0
sparc defconfig gcc-16.1.0
sparc randconfig-001-20260616 gcc-8.5.0
sparc randconfig-002-20260616 gcc-8.5.0
sparc64 allmodconfig clang-20
sparc64 defconfig gcc-14
sparc64 randconfig-001-20260616 gcc-8.5.0
sparc64 randconfig-002-20260616 gcc-8.5.0
um allmodconfig clang-17
um allmodconfig clang-23
um allnoconfig clang-16
um allnoconfig clang-23
um allyesconfig gcc-14
um allyesconfig gcc-16.1.0
um defconfig gcc-14
um i386_defconfig gcc-14
um randconfig-001-20260616 gcc-8.5.0
um randconfig-002-20260616 gcc-8.5.0
um x86_64_defconfig gcc-14
x86_64 allmodconfig clang-22
x86_64 allnoconfig clang-22
x86_64 allnoconfig clang-23
x86_64 allyesconfig clang-22
x86_64 buildonly-randconfig-001-20260616 gcc-14
x86_64 buildonly-randconfig-002-20260616 gcc-14
x86_64 buildonly-randconfig-003-20260616 gcc-14
x86_64 buildonly-randconfig-004-20260616 gcc-14
x86_64 buildonly-randconfig-005-20260616 gcc-14
x86_64 buildonly-randconfig-006-20260616 gcc-14
x86_64 defconfig gcc-14
x86_64 kexec clang-22
x86_64 randconfig-001 gcc-14
x86_64 randconfig-001-20260616 clang-22
x86_64 randconfig-002 gcc-14
x86_64 randconfig-002-20260616 clang-22
x86_64 randconfig-003 clang-22
x86_64 randconfig-003-20260616 clang-22
x86_64 randconfig-004 clang-22
x86_64 randconfig-004-20260616 clang-22
x86_64 randconfig-004-20260616 gcc-14
x86_64 randconfig-005 gcc-14
x86_64 randconfig-005-20260616 clang-22
x86_64 randconfig-006 clang-22
x86_64 randconfig-006-20260616 clang-22
x86_64 randconfig-011-20260616 clang-22
x86_64 randconfig-012-20260616 clang-22
x86_64 randconfig-013-20260616 clang-22
x86_64 randconfig-014-20260616 clang-22
x86_64 randconfig-015-20260616 clang-22
x86_64 randconfig-016-20260616 clang-22
x86_64 randconfig-071 gcc-13
x86_64 randconfig-071-20260616 gcc-14
x86_64 randconfig-072 gcc-13
x86_64 randconfig-072-20260616 clang-22
x86_64 randconfig-072-20260616 gcc-14
x86_64 randconfig-073 gcc-13
x86_64 randconfig-073-20260616 gcc-14
x86_64 randconfig-074 gcc-13
x86_64 randconfig-074-20260616 gcc-14
x86_64 randconfig-075 gcc-13
x86_64 randconfig-075-20260616 gcc-12
x86_64 randconfig-075-20260616 gcc-14
x86_64 randconfig-076 gcc-13
x86_64 randconfig-076-20260616 gcc-14
x86_64 rhel-9.4 clang-22
x86_64 rhel-9.4-bpf gcc-14
x86_64 rhel-9.4-func clang-22
x86_64 rhel-9.4-kselftests clang-22
x86_64 rhel-9.4-kunit gcc-14
x86_64 rhel-9.4-ltp gcc-14
x86_64 rhel-9.4-rust clang-22
xtensa allnoconfig clang-23
xtensa allnoconfig gcc-16.1.0
xtensa allyesconfig clang-20
xtensa randconfig-001-20260616 gcc-8.5.0
xtensa randconfig-002-20260616 gcc-8.5.0
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* [PATCH] media: mediatek: vcodec: fix use-after-free in decoder release path
From: Doruk Tan Ozturk @ 2026-06-16 7:56 UTC (permalink / raw)
To: tiffany.lin, andrew-ct.chen, yunfei.dong, mchehab, matthias.bgg,
angelogioacchino.delregno
Cc: hverkuil+cisco, linux-media, linux-mediatek, linux-arm-kernel,
linux-kernel, Doruk Tan Ozturk, stable
fops_vcodec_release() frees the decoder context with kfree(ctx) but
never cancels the per-context decode_work worker first. Although
v4l2_m2m_ctx_release() waits for any in-flight m2m job to finish, the
workqueue handler (mtk_vdec_worker) may still be running and accessing
the context after v4l2_m2m_job_finish() returns. Once kfree(ctx) runs,
that worker dereferences freed memory, resulting in a use-after-free.
Cancel the pending decode work with cancel_work_sync(&ctx->decode_work)
after the controls and m2m context are torn down and before kfree(ctx),
mirroring the fix already applied to the encoder release path in
commit 76e35091ffc7 ("media: mediatek: vcodec: fix use-after-free in
encoder release path").
decode_work is always initialised before release can run:
fops_vcodec_open() calls mtk_vcodec_dec_set_default_params() (its only
caller) unconditionally after a successful v4l2_m2m_ctx_init(), and that
function runs INIT_WORK(&ctx->decode_work, ...). A context can only reach
fops_vcodec_release() via an open() that returned 0, i.e. one that passed
that INIT_WORK. cancel_work_sync() on a properly initialised work_struct
is therefore always safe, even if the work was never queued. This is
unlike the 2023 msg_queue->core_work regression, where the work item
could be uninitialised at cancel time.
Fixes: 590577a4e525 ("[media] vcodec: mediatek: Add Mediatek V4L2 Video Decoder Driver")
Cc: stable@vger.kernel.org
Signed-off-by: Doruk Tan Ozturk <doruk@0sec.ai>
---
v2: reword the commit message to stay within 75 columns (no functional
change; checkpatch).
v1: https://lore.kernel.org/linux-media/20260615140526.52617-1-doruk@0sec.ai/
.../mediatek/vcodec/decoder/mtk_vcodec_dec_drv.c | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_drv.c b/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_drv.c
index e936ed8dffbaf..30906b24c608a 100644
--- a/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_drv.c
+++ b/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_drv.c
@@ -313,6 +313,15 @@ static int fops_vcodec_release(struct file *file)
v4l2_fh_exit(&ctx->fh);
v4l2_ctrl_handler_free(&ctx->ctrl_hdl);
+ /*
+ * Cancel any pending decode work before freeing the context.
+ * Although v4l2_m2m_ctx_release() waits for m2m job completion,
+ * the workqueue handler (mtk_vdec_worker) may still be accessing
+ * the context after v4l2_m2m_job_finish() returns. Without this,
+ * a use-after-free occurs when the worker accesses ctx after kfree.
+ */
+ cancel_work_sync(&ctx->decode_work);
+
mtk_vcodec_dbgfs_remove(dev, ctx->id);
spin_lock_irqsave(&dev->dev_ctx_lock, flags);
list_del_init(&ctx->list);
--
2.43.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