* [PATCH v2] ARM: OMAP2+: Add CFI type for omap4_finish_suspend
From: Mithil Bavishi @ 2026-05-22 23:30 UTC (permalink / raw)
To: Aaro Koskinen, Andreas Kemnade, Kevin Hilman, Roger Quadros,
Tony Lindgren, Russell King
Cc: Sami Tolvanen, Kees Cook, Nathan Chancellor, linux-arm-kernel,
linux-omap, llvm, linux-kernel, Mithil Bavishi
With CONFIG_CFI enabled, OMAP4 can trap in omap4_enter_lowpower()
because omap_pm_ops.finish_suspend points directly to the assembly
routine omap4_finish_suspend, which lacks the expected KCFI type
metadata.
Annotate omap4_finish_suspend with SYM_TYPED_FUNC_START so the assembly
routine carries the KCFI type metadata.
Signed-off-by: Mithil Bavishi <bavishimithil@gmail.com>
---
arch/arm/mach-omap2/sleep44xx.S | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/sleep44xx.S b/arch/arm/mach-omap2/sleep44xx.S
index f09c91978..0b48df6fc 100644
--- a/arch/arm/mach-omap2/sleep44xx.S
+++ b/arch/arm/mach-omap2/sleep44xx.S
@@ -58,7 +58,7 @@
* stack frame and it expects the caller to take care of it. Hence the entire
* stack frame is saved to avoid possible stack corruption.
*/
-ENTRY(omap4_finish_suspend)
+SYM_TYPED_FUNC_START(omap4_finish_suspend)
stmfd sp!, {r4-r12, lr}
cmp r0, #0x0
beq do_WFI @ No lowpower state, jump to WFI
@@ -223,7 +223,7 @@ skip_scu_gp_clear:
isb
dsb
ldmfd sp!, {r4-r12, pc}
-ENDPROC(omap4_finish_suspend)
+SYM_FUNC_END(omap4_finish_suspend)
/*
* ============================
--
2.43.0
^ permalink raw reply related
* [PATCH v4 05/12] crypto: atmel - rename atmel_ecc_driver_data to atmel_i2c_client_mgmt
From: Lothar Rubusch @ 2026-05-22 23:01 UTC (permalink / raw)
To: thorsten.blum, herbert, davem, nicolas.ferre, alexandre.belloni,
claudiu.beznea, tudor.ambarus, ardb, linusw, krzk+dt
Cc: linux-crypto, linux-arm-kernel, linux-kernel, l.rubusch
In-Reply-To: <20260522230134.32414-1-l.rubusch@gmail.com>
Rename struct atmel_ecc_driver_data to atmel_i2c_client_mgmt to reflect its
generic role in shared I2C client tracking and locking. A subsequent change
will move the client management infrastructure into the atmel-i2c core
driver.
No functional changes intended.
Signed-off-by: Lothar Rubusch <l.rubusch@gmail.com>
---
drivers/crypto/atmel-ecc.c | 2 +-
drivers/crypto/atmel-i2c.h | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/crypto/atmel-ecc.c b/drivers/crypto/atmel-ecc.c
index d12a9dbe45a7..d6ae113c45df 100644
--- a/drivers/crypto/atmel-ecc.c
+++ b/drivers/crypto/atmel-ecc.c
@@ -28,7 +28,7 @@ static int atmel_ecc_kpp_refcnt;
DECLARE_COMPLETION(atmel_ecc_unreg_done);
static bool atmel_ecc_unreg_active;
-static struct atmel_ecc_driver_data atmel_i2c_mgmt;
+static struct atmel_i2c_client_mgmt atmel_i2c_mgmt;
/**
* struct atmel_ecdh_ctx - transformation context
diff --git a/drivers/crypto/atmel-i2c.h b/drivers/crypto/atmel-i2c.h
index b320559e50eb..660ca861b705 100644
--- a/drivers/crypto/atmel-i2c.h
+++ b/drivers/crypto/atmel-i2c.h
@@ -115,7 +115,7 @@ struct atmel_i2c_cmd {
#define ECDH_PREFIX_MODE 0x00
/* Used for binding tfm objects to i2c clients. */
-struct atmel_ecc_driver_data {
+struct atmel_i2c_client_mgmt {
struct list_head i2c_client_list;
spinlock_t i2c_list_lock;
} ____cacheline_aligned;
--
2.39.5
^ permalink raw reply related
* [PATCH v4 09/12] crypto: atmel-i2c - move shared client allocation logic to core
From: Lothar Rubusch @ 2026-05-22 23:01 UTC (permalink / raw)
To: thorsten.blum, herbert, davem, nicolas.ferre, alexandre.belloni,
claudiu.beznea, tudor.ambarus, ardb, linusw, krzk+dt
Cc: linux-crypto, linux-arm-kernel, linux-kernel, l.rubusch
In-Reply-To: <20260522230134.32414-1-l.rubusch@gmail.com>
Migrate the I2C client allocation and runtime load-balancing routines out
of the ECC driver code and into the central atmel-i2c core library module.
Export the symmetric lifecycle helper interfaces atmel_i2c_client_alloc()
and atmel_i2c_client_free() using EXPORT_SYMBOL_GPL() to expose a unified
client management API. This consolidation enables the dynamic selection
subsystem (which chooses the least-loaded client device based on the active
transformation count) to be shared by both the ECC driver and upcoming
Atmel crypto modules.
Refactor the ECC driver's transformation context initialization (init_tfm)
and teardown (exit_tfm) paths to use this centralized core API.
No functional change is intended.
Signed-off-by: Lothar Rubusch <l.rubusch@gmail.com>
---
drivers/crypto/atmel-ecc.c | 51 +++-----------------------------------
drivers/crypto/atmel-i2c.c | 47 +++++++++++++++++++++++++++++++++++
drivers/crypto/atmel-i2c.h | 3 +++
3 files changed, 53 insertions(+), 48 deletions(-)
diff --git a/drivers/crypto/atmel-ecc.c b/drivers/crypto/atmel-ecc.c
index d2490693a198..16e607cd06c4 100644
--- a/drivers/crypto/atmel-ecc.c
+++ b/drivers/crypto/atmel-ecc.c
@@ -205,51 +205,6 @@ static int atmel_ecdh_compute_shared_secret(struct kpp_request *req)
return ret;
}
-static struct i2c_client *atmel_ecc_i2c_client_alloc(void)
-{
- struct atmel_i2c_client_priv *i2c_priv, *min_i2c_priv = NULL;
- struct i2c_client *client = ERR_PTR(-ENODEV);
- int min_tfm_cnt = INT_MAX;
- int tfm_cnt;
-
- spin_lock(&atmel_i2c_mgmt.i2c_list_lock);
-
- if (list_empty(&atmel_i2c_mgmt.i2c_client_list)) {
- spin_unlock(&atmel_i2c_mgmt.i2c_list_lock);
- return ERR_PTR(-ENODEV);
- }
-
- list_for_each_entry(i2c_priv, &atmel_i2c_mgmt.i2c_client_list,
- i2c_client_list_node) {
- if (!i2c_priv->ready)
- continue;
- tfm_cnt = atomic_read(&i2c_priv->tfm_count);
- if (tfm_cnt < min_tfm_cnt) {
- min_tfm_cnt = tfm_cnt;
- min_i2c_priv = i2c_priv;
- }
- if (!min_tfm_cnt)
- break;
- }
-
- if (min_i2c_priv) {
- atomic_inc(&min_i2c_priv->tfm_count);
- client = min_i2c_priv->client;
- }
-
- spin_unlock(&atmel_i2c_mgmt.i2c_list_lock);
-
- return client;
-}
-
-static void atmel_ecc_i2c_client_free(struct i2c_client *client)
-{
- struct atmel_i2c_client_priv *i2c_priv = i2c_get_clientdata(client);
-
- if (atomic_dec_and_test(&i2c_priv->tfm_count))
- complete(&i2c_priv->remove_done);
-}
-
static int atmel_ecdh_init_tfm(struct crypto_kpp *tfm)
{
const char *alg = kpp_alg_name(tfm);
@@ -257,7 +212,7 @@ static int atmel_ecdh_init_tfm(struct crypto_kpp *tfm)
struct atmel_ecdh_ctx *ctx = kpp_tfm_ctx(tfm);
ctx->curve_id = ECC_CURVE_NIST_P256;
- ctx->client = atmel_ecc_i2c_client_alloc();
+ ctx->client = atmel_i2c_client_alloc();
if (IS_ERR(ctx->client)) {
pr_err("tfm - i2c_client binding failed\n");
return PTR_ERR(ctx->client);
@@ -267,7 +222,7 @@ static int atmel_ecdh_init_tfm(struct crypto_kpp *tfm)
if (IS_ERR(fallback)) {
dev_err(&ctx->client->dev, "Failed to allocate transformation for '%s': %ld\n",
alg, PTR_ERR(fallback));
- atmel_ecc_i2c_client_free(ctx->client);
+ atmel_i2c_client_free(ctx->client);
return PTR_ERR(fallback);
}
@@ -284,7 +239,7 @@ static void atmel_ecdh_exit_tfm(struct crypto_kpp *tfm)
kfree(ctx->public_key);
if (ctx->fallback)
crypto_free_kpp(ctx->fallback);
- atmel_ecc_i2c_client_free(ctx->client);
+ atmel_i2c_client_free(ctx->client);
}
static unsigned int atmel_ecdh_max_size(struct crypto_kpp *tfm)
diff --git a/drivers/crypto/atmel-i2c.c b/drivers/crypto/atmel-i2c.c
index db818ce55033..92d3e28f9d9a 100644
--- a/drivers/crypto/atmel-i2c.c
+++ b/drivers/crypto/atmel-i2c.c
@@ -57,6 +57,53 @@ static void atmel_i2c_checksum(struct atmel_i2c_cmd *cmd)
*__crc16 = cpu_to_le16(bitrev16(crc16(0, data, len)));
}
+struct i2c_client *atmel_i2c_client_alloc(void)
+{
+ struct atmel_i2c_client_priv *i2c_priv, *min_i2c_priv = NULL;
+ struct i2c_client *client = ERR_PTR(-ENODEV);
+ int min_tfm_cnt = INT_MAX;
+ int tfm_cnt;
+
+ spin_lock(&atmel_i2c_mgmt.i2c_list_lock);
+
+ if (list_empty(&atmel_i2c_mgmt.i2c_client_list)) {
+ spin_unlock(&atmel_i2c_mgmt.i2c_list_lock);
+ return ERR_PTR(-ENODEV);
+ }
+
+ list_for_each_entry(i2c_priv, &atmel_i2c_mgmt.i2c_client_list,
+ i2c_client_list_node) {
+ if (!i2c_priv->ready)
+ continue;
+ tfm_cnt = atomic_read(&i2c_priv->tfm_count);
+ if (tfm_cnt < min_tfm_cnt) {
+ min_tfm_cnt = tfm_cnt;
+ min_i2c_priv = i2c_priv;
+ }
+ if (!min_tfm_cnt)
+ break;
+ }
+
+ if (min_i2c_priv) {
+ atomic_inc(&min_i2c_priv->tfm_count);
+ client = min_i2c_priv->client;
+ }
+
+ spin_unlock(&atmel_i2c_mgmt.i2c_list_lock);
+
+ return client;
+}
+EXPORT_SYMBOL_GPL(atmel_i2c_client_alloc);
+
+void atmel_i2c_client_free(struct i2c_client *client)
+{
+ struct atmel_i2c_client_priv *i2c_priv = i2c_get_clientdata(client);
+
+ if (atomic_dec_and_test(&i2c_priv->tfm_count))
+ complete(&i2c_priv->remove_done);
+}
+EXPORT_SYMBOL_GPL(atmel_i2c_client_free);
+
void atmel_i2c_init_read_config_cmd(struct atmel_i2c_cmd *cmd)
{
cmd->word_addr = COMMAND;
diff --git a/drivers/crypto/atmel-i2c.h b/drivers/crypto/atmel-i2c.h
index 07fd2248e20b..ddab80bc1a72 100644
--- a/drivers/crypto/atmel-i2c.h
+++ b/drivers/crypto/atmel-i2c.h
@@ -193,6 +193,9 @@ void atmel_i2c_init_genkey_cmd(struct atmel_i2c_cmd *cmd, u16 keyid);
int atmel_i2c_init_ecdh_cmd(struct atmel_i2c_cmd *cmd,
struct scatterlist *pubkey);
+struct i2c_client *atmel_i2c_client_alloc(void);
+void atmel_i2c_client_free(struct i2c_client *client);
+
void atmel_i2c_deactivate_client(struct atmel_i2c_client_priv *i2c_priv);
void atmel_i2c_unregister_client(struct atmel_i2c_client_priv *i2c_priv);
--
2.39.5
^ permalink raw reply related
* [PATCH] ARM: mm: fix kexec and hibernation with CONFIG_CPU_TTBR0_PAN
From: Florian Fainelli @ 2026-05-23 0:08 UTC (permalink / raw)
To: linux-arm-kernel
Cc: bcm-kernel-feedback-list, Florian Fainelli, Catalin Marinas,
Linus Walleij, Russell King, Linus Walleij, Russell King (Oracle),
Kees Cook, open list
Commit 7af5b901e847 ("ARM: 9358/2: Implement PAN for LPAE by TTBR0
page table walks disablement") implemented PAN for LPAE kernels by
setting TTBCR.EPD0 on every kernel entry, disabling TTBR0 page-table
walks while running in kernel mode. The commit correctly updated
cpu_suspend() in arch/arm/kernel/suspend.c, but missed two other code
paths that switch the CPU to the identity mapping before jumping to
low-PA (TTBR0-range) physical addresses:
1. setup_mm_for_reboot() in arch/arm/mm/idmap.c, used by the kexec
reboot path. With TTBCR.EPD0 still set, the subsequent branch to
the identity-mapped cpu_v7_reset causes a PrefetchAbort because the
TTBR0 page-table walk needed to resolve the identity-mapped address
is disabled. This manifests as a hard hang or "bad PC value" panic
on LPAE kernels booted on CPUs that strictly enforce EPD0 for
instruction fetch (e.g. Cortex-A53 in AArch32 mode) while the same
image may accidentally work on Cortex-A15 due to microarchitectural
differences in EPD0 enforcement.
2. arch_restore_image() in arch/arm/kernel/hibernate.c, which calls
cpu_switch_mm(idmap_pgd, &init_mm) directly without going through
setup_mm_for_reboot(), leaving TTBCR.EPD0 set while the identity
mapping is active.
Fix both sites by calling uaccess_save_and_enable() before switching
to the identity mapping, mirroring what the original commit did for
cpu_suspend().
Fixes: 7af5b901e847 ("ARM: 9358/2: Implement PAN for LPAE by TTBR0 page table walks disablement")
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Linus Walleij <linus.walleij@linaro.org>
Assisted-by: Cursor:claude-sonnet-4.6
Signed-off-by: Florian Fainelli <florian.fainelli@broadcom.com>
---
arch/arm/kernel/hibernate.c | 10 ++++++++++
arch/arm/mm/idmap.c | 12 ++++++++++++
2 files changed, 22 insertions(+)
diff --git a/arch/arm/kernel/hibernate.c b/arch/arm/kernel/hibernate.c
index 38a90a3d12b2..231a76af09a0 100644
--- a/arch/arm/kernel/hibernate.c
+++ b/arch/arm/kernel/hibernate.c
@@ -21,6 +21,7 @@
#include <asm/suspend.h>
#include <asm/page.h>
#include <asm/sections.h>
+#include <asm/uaccess.h>
#include "reboot.h"
int pfn_is_nosave(unsigned long pfn)
@@ -82,6 +83,15 @@ static void notrace arch_restore_image(void *unused)
{
struct pbe *pbe;
+ /*
+ * With CONFIG_CPU_TTBR0_PAN enabled, TTBCR.EPD0 is set to block
+ * TTBR0 page-table walks. The identity mapping used here lives at
+ * low (user-space) virtual addresses and is only reachable via
+ * TTBR0, so re-enable those walks before switching page tables.
+ * On non-PAN kernels this is a no-op.
+ */
+ if (IS_ENABLED(CONFIG_CPU_TTBR0_PAN))
+ uaccess_save_and_enable();
cpu_switch_mm(idmap_pgd, &init_mm);
for (pbe = restore_pblist; pbe; pbe = pbe->next)
copy_page(pbe->orig_address, pbe->address);
diff --git a/arch/arm/mm/idmap.c b/arch/arm/mm/idmap.c
index 4a833e89782a..70403e968d2a 100644
--- a/arch/arm/mm/idmap.c
+++ b/arch/arm/mm/idmap.c
@@ -11,6 +11,7 @@
#include <asm/pgalloc.h>
#include <asm/sections.h>
#include <asm/system_info.h>
+#include <asm/uaccess.h>
/*
* Note: accesses outside of the kernel image and the identity map area
@@ -133,6 +134,17 @@ early_initcall(init_static_idmap);
*/
void setup_mm_for_reboot(void)
{
+ /*
+ * With CONFIG_CPU_TTBR0_PAN enabled, TTBCR.EPD0 is set whenever
+ * user-space access is disabled in order to block TTBR0 page-table
+ * walks. The identity mapping lives at low (user-space) virtual
+ * addresses and can only be reached via TTBR0, so we must re-enable
+ * those walks before switching page tables. On non-PAN kernels this
+ * is a no-op.
+ */
+ if (IS_ENABLED(CONFIG_CPU_TTBR0_PAN))
+ uaccess_save_and_enable();
+
/* Switch to the identity mapping. */
cpu_switch_mm(idmap_pgd, &init_mm);
local_flush_bp_all();
--
2.34.1
^ permalink raw reply related
* Re: [PATCH 2/4] firmware: arm_ffa: Register core as a platform driver
From: Nathan Chancellor @ 2026-05-23 0:11 UTC (permalink / raw)
To: Sudeep Holla
Cc: linux-security-module, linux-kernel, linux-integrity,
linux-arm-kernel, kvmarm, Yeoreum Yun
In-Reply-To: <20260508-b4-ffa_plat_dev-v1-2-c5a30f8cf7b8@kernel.org>
Hi Sudeep,
On Fri, May 08, 2026 at 06:54:16PM +0100, Sudeep Holla wrote:
> Move the FF-A core bring-up and teardown paths into platform driver
> probe and remove callbacks, and register a synthetic arm-ffa platform
> device to bind the driver.
>
> This makes the FF-A core lifetime follow the driver model while keeping
> the device creation internal to the FF-A core. Use normal platform driver
> registration so the probe path has standard driver-core semantics.
>
> The synthetic platform device is a temporary bridge until ACPI and
> devicetree describe the FF-A core device or object. Once those firmware
> description paths are defined, the internal platform device creation can
> be dropped and the driver can bind to the firmware-described device
> directly.
>
> Since the transport selection now happens from the platform probe path,
> drop the __init annotation from ffa_transport_init().
>
> Signed-off-by: Sudeep Holla <sudeep.holla@kernel.org>
I am seeing
arm-ffa arm-ffa: probe with driver arm-ffa failed with error -95
on my two arm64 test machines after this change landed in -next as
commit e659fc8e537c ("firmware: arm_ffa: Register core as a platform
driver"), is this expected? If so, perhaps it should be silenced?
Cheers,
Nathan
# bad: [c1ecb239fa3456529a32255359fc78b69eb9d847] Add linux-next specific files for 20260522
# good: [6779b50faa562e6cca1aa6a4649a4d764c6c7e28] Merge tag 'pci-v7.1-fixes-2' of git://git.kernel.org/pub/scm/linux/kernel/git/pci/pci
git bisect start 'c1ecb239fa3456529a32255359fc78b69eb9d847' '6779b50faa562e6cca1aa6a4649a4d764c6c7e28'
# bad: [c09bb0d7c56d56daed51e374409472c3fece9931] Merge branch 'for-next' of https://git.kernel.org/pub/scm/linux/kernel/git/ath/ath.git
git bisect bad c09bb0d7c56d56daed51e374409472c3fece9931
# bad: [42b0664d6f7b3d04f961e0709811280e52d4d39c] Merge branch 'for-next' of https://git.kernel.org/pub/scm/linux/kernel/git/geert/linux-m68k.git
git bisect bad 42b0664d6f7b3d04f961e0709811280e52d4d39c
# good: [63775c4b77cf7ac5863ae0e76f8626b80d217562] Merge branch 'mm-nonmm-unstable' of https://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm
git bisect good 63775c4b77cf7ac5863ae0e76f8626b80d217562
# good: [f437936af5c74fddfdfcd2388a5f1eec2f9a105b] Merge branch 'for-next' of https://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap.git
git bisect good f437936af5c74fddfdfcd2388a5f1eec2f9a105b
# good: [01bf3f256f1ed15fa3884e4893e5a9d78fdfb2d6] Merge branch 'for-next' of https://git.kernel.org/pub/scm/linux/kernel/git/mmind/linux-rockchip.git
git bisect good 01bf3f256f1ed15fa3884e4893e5a9d78fdfb2d6
# bad: [bee649097c8de82d9dccd3660c41163a6507e3d4] Merge branch 'next' of https://git.kernel.org/pub/scm/linux/kernel/git/jenswi/linux-tee.git
git bisect bad bee649097c8de82d9dccd3660c41163a6507e3d4
# bad: [82ccfdd8dd1e29229a3ed7c95a76578706fc4a1d] Merge branch 'for-next' of https://github.com/sophgo/linux.git
git bisect bad 82ccfdd8dd1e29229a3ed7c95a76578706fc4a1d
# good: [32bc5496b48174dbca1f187f710955ee4d9527a1] firmware: arm_scmi: Validate SENSOR_UPDATE payload size
git bisect good 32bc5496b48174dbca1f187f710955ee4d9527a1
# bad: [64251369d33884b431a52b89c60fabf466f3913c] Merge branches 'for-next/scmi/updates' and 'for-next/ffa/updates' of ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux into for-linux-next
git bisect bad 64251369d33884b431a52b89c60fabf466f3913c
# bad: [70492cfce2a4d41e87bf46989028a90f4bc6b38f] firmware: smccc: Fix Arm SMCCC SOC_ID name call
git bisect bad 70492cfce2a4d41e87bf46989028a90f4bc6b38f
# bad: [7fe2ec9fb8e9a78dad8d6b1e551cb4d126e36f1e] firmware: arm_ffa: Set the core device as FF-A device parent
git bisect bad 7fe2ec9fb8e9a78dad8d6b1e551cb4d126e36f1e
# bad: [e659fc8e537c7a21d5d693d6f30d8852f2fa8d91] firmware: arm_ffa: Register core as a platform driver
git bisect bad e659fc8e537c7a21d5d693d6f30d8852f2fa8d91
# good: [cc7e8f21b9f0c229d68cf19a837cba82b5ac2d87] Revert "firmware: arm_ffa: Change initcall level of ffa_init() to rootfs_initcall"
git bisect good cc7e8f21b9f0c229d68cf19a837cba82b5ac2d87
# first bad commit: [e659fc8e537c7a21d5d693d6f30d8852f2fa8d91] firmware: arm_ffa: Register core as a platform driver
^ permalink raw reply
* Re: [PATCH v2] net: stmmac: mmc: Remove duplicate mmc_rx crc
From: patchwork-bot+netdevbpf @ 2026-05-23 0:40 UTC (permalink / raw)
To: Abid Ali
Cc: andrew+netdev, davem, edumazet, kuba, pabeni, mcoquelin.stm32,
alexandre.torgue, netdev, linux-stm32, linux-arm-kernel,
linux-kernel
In-Reply-To: <20260521-xgmac-mmc_rx_crc-cleanup-v2-1-7d9de09f5898@gmail.com>
Hello:
This patch was applied to netdev/net-next.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Thu, 21 May 2026 16:32:46 +0000 you wrote:
> From: Abid Ali <dev.taqnialabs@gmail.com>
>
> MMC_XGMAC_RX_CRC_ERR is clear-on-read, and just a single read would
> update the mmc_rx_crc_error counter.
>
> [1] commit b6cdf09 ("net: stmmac: xgmac: Implement MMC counters").
> The duplicate read appears to have been unintentionally introduced in
> the intial MMC counter implementation. The databook does not mention
> MMC_XGMAC_RX_CRC_ERR needing the additional read.
>
> [...]
Here is the summary with links:
- [v2] net: stmmac: mmc: Remove duplicate mmc_rx crc
https://git.kernel.org/netdev/net-next/c/fd1cdeddd7bc
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [PATCH v2] ARM: OMAP2+: Add CFI type for omap4_finish_suspend
From: Nathan Chancellor @ 2026-05-23 1:17 UTC (permalink / raw)
To: Mithil Bavishi
Cc: Aaro Koskinen, Andreas Kemnade, Kevin Hilman, Roger Quadros,
Tony Lindgren, Russell King, Sami Tolvanen, Kees Cook,
linux-arm-kernel, linux-omap, llvm, linux-kernel
In-Reply-To: <20260522233036.12277-1-bavishimithil@gmail.com>
On Fri, May 22, 2026 at 04:30:36PM -0700, Mithil Bavishi wrote:
> With CONFIG_CFI enabled, OMAP4 can trap in omap4_enter_lowpower()
> because omap_pm_ops.finish_suspend points directly to the assembly
> routine omap4_finish_suspend, which lacks the expected KCFI type
> metadata.
>
> Annotate omap4_finish_suspend with SYM_TYPED_FUNC_START so the assembly
> routine carries the KCFI type metadata.
>
> Signed-off-by: Mithil Bavishi <bavishimithil@gmail.com>
Reviewed-by: Nathan Chancellor <nathan@kernel.org>
> ---
> arch/arm/mach-omap2/sleep44xx.S | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/sleep44xx.S b/arch/arm/mach-omap2/sleep44xx.S
> index f09c91978..0b48df6fc 100644
> --- a/arch/arm/mach-omap2/sleep44xx.S
> +++ b/arch/arm/mach-omap2/sleep44xx.S
> @@ -58,7 +58,7 @@
> * stack frame and it expects the caller to take care of it. Hence the entire
> * stack frame is saved to avoid possible stack corruption.
> */
> -ENTRY(omap4_finish_suspend)
> +SYM_TYPED_FUNC_START(omap4_finish_suspend)
> stmfd sp!, {r4-r12, lr}
> cmp r0, #0x0
> beq do_WFI @ No lowpower state, jump to WFI
> @@ -223,7 +223,7 @@ skip_scu_gp_clear:
> isb
> dsb
> ldmfd sp!, {r4-r12, pc}
> -ENDPROC(omap4_finish_suspend)
> +SYM_FUNC_END(omap4_finish_suspend)
>
> /*
> * ============================
> --
> 2.43.0
>
--
Cheers,
Nathan
^ permalink raw reply
* Re: [PATCH net-next v5 08/13] net: lan966x: add shutdown callback to stop FDMA on reboot
From: Jakub Kicinski @ 2026-05-23 1:45 UTC (permalink / raw)
To: Daniel Machon
Cc: Andrew Lunn, David S. Miller, Eric Dumazet, Paolo Abeni,
Horatiu Vultur, Steen Hegelund, UNGLinuxDriver,
Alexei Starovoitov, Daniel Borkmann, Jesper Dangaard Brouer,
John Fastabend, Stanislav Fomichev, Herve Codina, Arnd Bergmann,
Greg Kroah-Hartman, Mohsin Bashir, netdev, linux-kernel, bpf,
linux-arm-kernel
In-Reply-To: <20260520-lan966x-pci-fdma-v5-8-ca56197ae05b@microchip.com>
On Wed, 20 May 2026 10:12:20 +0200 Daniel Machon wrote:
> + napi_synchronize(&lan966x->napi);
> + napi_disable(&lan966x->napi);
Why the synchronize() before disable() ?
napi_synchronize() is a simplistic disable() + enable()
^ permalink raw reply
* Re: [PATCH net-next v5 09/13] net: lan966x: add PCIe FDMA support
From: Jakub Kicinski @ 2026-05-23 1:56 UTC (permalink / raw)
To: Daniel Machon
Cc: Andrew Lunn, David S. Miller, Eric Dumazet, Paolo Abeni,
Horatiu Vultur, Steen Hegelund, UNGLinuxDriver,
Alexei Starovoitov, Daniel Borkmann, Jesper Dangaard Brouer,
John Fastabend, Stanislav Fomichev, Herve Codina, Arnd Bergmann,
Greg Kroah-Hartman, Mohsin Bashir, netdev, linux-kernel, bpf,
linux-arm-kernel
In-Reply-To: <20260520-lan966x-pci-fdma-v5-9-ca56197ae05b@microchip.com>
On Wed, 20 May 2026 10:12:21 +0200 Daniel Machon wrote:
> Add PCIe FDMA support for lan966x. The PCIe FDMA path uses contiguous
> DMA buffers mapped through the endpoint's ATU, with memcpy-based frame
> transfer instead of per-page DMA mappings.
>
> With PCIe FDMA, throughput increases from ~33 Mbps (register-based I/O)
> to ~620 Mbps on an Intel x86 host with a lan966x PCIe card.
> diff --git a/drivers/net/ethernet/microchip/lan966x/Makefile b/drivers/net/ethernet/microchip/lan966x/Makefile
> index 4cdbe263502c..ac0beceb2a0d 100644
> --- a/drivers/net/ethernet/microchip/lan966x/Makefile
> +++ b/drivers/net/ethernet/microchip/lan966x/Makefile
> @@ -18,6 +18,10 @@ lan966x-switch-objs := lan966x_main.o lan966x_phylink.o lan966x_port.o \
> lan966x-switch-$(CONFIG_LAN966X_DCB) += lan966x_dcb.o
> lan966x-switch-$(CONFIG_DEBUG_FS) += lan966x_vcap_debugfs.o
>
> +ifdef CONFIG_MCHP_LAN966X_PCI
ifeq ()
would be more common in a Makefile?
> +lan966x-switch-y += lan966x_fdma_pci.o
> +endif
> +
> diff --git a/drivers/net/ethernet/microchip/lan966x/lan966x_main.c b/drivers/net/ethernet/microchip/lan966x/lan966x_main.c
> index cc3c7b6c65ae..7036b1d937d5 100644
> --- a/drivers/net/ethernet/microchip/lan966x/lan966x_main.c
> +++ b/drivers/net/ethernet/microchip/lan966x/lan966x_main.c
> @@ -7,6 +7,7 @@
> #include <linux/ip.h>
> #include <linux/of.h>
> #include <linux/of_net.h>
> +#include <linux/pci.h>
> #include <linux/phy/phy.h>
> #include <linux/platform_device.h>
> #include <linux/reset.h>
> @@ -49,6 +50,9 @@ struct lan966x_main_io_resource {
> static const struct lan966x_main_io_resource lan966x_main_iomap[] = {
> { TARGET_CPU, 0xc0000, 0 }, /* 0xe00c0000 */
> { TARGET_FDMA, 0xc0400, 0 }, /* 0xe00c0400 */
> +#if IS_ENABLED(CONFIG_MCHP_LAN966X_PCI)
why config option being enabled changes the targets?
Can someone with a non-PCI device enable that option too
(sure it would be useless but given that/if they can guarding
with an #if seems like a waste of LoC)
> + { TARGET_PCIE_DBI, 0x400000, 0 }, /* 0xe0400000 */
> +#endif
> { TARGET_ORG, 0, 1 }, /* 0xe2000000 */
> { TARGET_GCB, 0x4000, 1 }, /* 0xe2004000 */
> { TARGET_QS, 0x8000, 1 }, /* 0xe2008000 */
> @@ -1100,6 +1104,13 @@ static int lan966x_reset_switch(struct lan966x *lan966x)
>
> static const struct lan966x_fdma_ops *lan966x_get_fdma_ops(struct device *dev)
> {
> +#if IS_ENABLED(CONFIG_MCHP_LAN966X_PCI)
> + for (struct device *p = dev->parent; p; p = p->parent) {
> + if (dev_is_pci(p))
If the PCIe devices also use an intermediate platform device for
probing, can't they explicitly have some flag / state to indicate
they are PCIe? The device walk in such a constrained env seems
like an overkill
> + return &lan966x_fdma_pci_ops;
> + }
> +#endif
> +
> return &lan966x_fdma_ops;
> }
>
> diff --git a/drivers/net/ethernet/microchip/lan966x/lan966x_main.h b/drivers/net/ethernet/microchip/lan966x/lan966x_main.h
> index 5f4dbeda17cd..e7fdd4447fb6 100644
> --- a/drivers/net/ethernet/microchip/lan966x/lan966x_main.h
> +++ b/drivers/net/ethernet/microchip/lan966x/lan966x_main.h
> @@ -17,6 +17,9 @@
> #include <net/xdp.h>
>
> #include <fdma_api.h>
> +#if IS_ENABLED(CONFIG_MCHP_LAN966X_PCI)
> +#include <fdma_pci.h>
> +#endif
Conditional #includes make build testing harder, better to avoid them
> #include <vcap_api.h>
> #include <vcap_api_client.h>
>
> @@ -288,6 +291,10 @@ struct lan966x {
>
> void __iomem *regs[NUM_TARGETS];
>
> +#if IS_ENABLED(CONFIG_MCHP_LAN966X_PCI)
> + struct fdma_pci_atu atu;
> +#endif
> +
> int shared_queue_sz;
>
> u8 base_mac[ETH_ALEN];
> @@ -586,6 +593,10 @@ void lan966x_fdma_wakeup_netdev(struct lan966x *lan966x);
> int lan966x_fdma_get_max_frame(struct lan966x *lan966x);
> int lan966x_qsys_sw_status(struct lan966x *lan966x);
>
> +#if IS_ENABLED(CONFIG_MCHP_LAN966X_PCI)
> +extern const struct lan966x_fdma_ops lan966x_fdma_pci_ops;
> +#endif
There should be no need to wrap extern in an #if
^ permalink raw reply
* Re: [PATCH net-next v5 11/13] net: lan966x: add PCIe FDMA XDP support
From: Jakub Kicinski @ 2026-05-23 2:01 UTC (permalink / raw)
To: Daniel Machon
Cc: Andrew Lunn, David S. Miller, Eric Dumazet, Paolo Abeni,
Horatiu Vultur, Steen Hegelund, UNGLinuxDriver,
Alexei Starovoitov, Daniel Borkmann, Jesper Dangaard Brouer,
John Fastabend, Stanislav Fomichev, Herve Codina, Arnd Bergmann,
Greg Kroah-Hartman, Mohsin Bashir, netdev, linux-kernel, bpf,
linux-arm-kernel
In-Reply-To: <20260520-lan966x-pci-fdma-v5-11-ca56197ae05b@microchip.com>
On Wed, 20 May 2026 10:12:23 +0200 Daniel Machon wrote:
> #if IS_ENABLED(CONFIG_MCHP_LAN966X_PCI)
> extern const struct lan966x_fdma_ops lan966x_fdma_pci_ops;
> +
> +static inline bool lan966x_is_pci(struct lan966x *lan966x)
> +{
> + return lan966x->ops == &lan966x_fdma_pci_ops;
return IS_ENABLED(CONFIG_MCHP_LAN966X_PCI) &&
lan966x->ops == &lan966x_fdma_pci_ops;
compiler will eliminate the reference to the ops as dead code
and linker will not complain that its object is missing.
> +}
> +#else
> +static inline bool lan966x_is_pci(struct lan966x *lan966x)
> +{
> + return false;
> +}
> #endif
>
> int lan966x_lag_port_join(struct lan966x_port *port,
> diff --git a/drivers/net/ethernet/microchip/lan966x/lan966x_xdp.c b/drivers/net/ethernet/microchip/lan966x/lan966x_xdp.c
> index 9ee61db8690b..b470f731e25c 100644
> --- a/drivers/net/ethernet/microchip/lan966x/lan966x_xdp.c
> +++ b/drivers/net/ethernet/microchip/lan966x/lan966x_xdp.c
> @@ -24,6 +24,16 @@ static int lan966x_xdp_setup(struct net_device *dev, struct netdev_bpf *xdp)
> old_prog = xchg(&port->xdp_prog, xdp->prog);
> new_xdp = lan966x_xdp_present(lan966x);
>
> + /* PCIe FDMA uses contiguous buffers, so no page_pool reload
> + * is needed. Drain NAPI before freeing the old program so
> + * no in-flight poll holds a stale pointer.
> + */
Not sure what this does. BPF programs are under RCU, they are not
immediately freed (if that's that you mean..)
> + if (lan966x_is_pci(lan966x)) {
> + if (old_prog)
> + napi_synchronize(&lan966x->napi);
> + goto out;
> + }
^ permalink raw reply
* Re: [PATCH net-next v5 12/13] misc: lan966x-pci: dts: extend cpu reg to cover PCIE DBI space
From: Jakub Kicinski @ 2026-05-23 2:01 UTC (permalink / raw)
To: Daniel Machon
Cc: Andrew Lunn, David S. Miller, Eric Dumazet, Paolo Abeni,
Horatiu Vultur, Steen Hegelund, UNGLinuxDriver,
Alexei Starovoitov, Daniel Borkmann, Jesper Dangaard Brouer,
John Fastabend, Stanislav Fomichev, Herve Codina, Arnd Bergmann,
Greg Kroah-Hartman, Mohsin Bashir, netdev, linux-kernel, bpf,
linux-arm-kernel
In-Reply-To: <20260520-lan966x-pci-fdma-v5-12-ca56197ae05b@microchip.com>
On Wed, 20 May 2026 10:12:24 +0200 Daniel Machon wrote:
> The ATU outbound windows used by the FDMA engine are programmed through
> registers at offset 0x400000+, which falls outside the current cpu reg
> mapping. Extend the cpu reg size from 0x100000 (1MB) to 0x800000 (8MB)
> to cover the full PCIE DBI and iATU register space.
Are we supposed to take these to net-next ?
^ permalink raw reply
* [PATCH 0/2] ARM: dts: aspeed: sanmiguel: Update DTS file
From: Potin Lai @ 2026-05-23 2:28 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Joel Stanley,
Andrew Jeffery, Patrick Williams
Cc: devicetree, linux-arm-kernel, linux-aspeed, linux-kernel,
Cosmo Chou, Mike Hsieh, Potin Lai, Potin Lai
Update the SanMiguel DTS configuration to fix incorrect GPIO
linenames and resolve the IOEXP interrupt handling issue.
Signed-off-by: Potin Lai <potin.lai@quantatw.com>
---
Potin Lai (2):
ARM: dts: aspeed: sanmiguel: Add IOEXP interrupt pin settings
ARM: dts: aspeed: sanmiguel: Fix the CPU_CHIPTHROT linename
arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-sanmiguel.dts | 8 ++++++--
1 file changed, 6 insertions(+), 2 deletions(-)
---
base-commit: 6e22b9e818d68d7b8ce6680aede0c80a9355929a
change-id: 20260522-potin-update-sanmiguel-dts-20260522-7b3d280e63f8
Best regards,
--
Potin Lai <potin.lai@quantatw.com>
^ permalink raw reply
* [PATCH 1/2] ARM: dts: aspeed: sanmiguel: Add IOEXP interrupt pin settings
From: Potin Lai @ 2026-05-23 2:28 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Joel Stanley,
Andrew Jeffery, Patrick Williams
Cc: devicetree, linux-arm-kernel, linux-aspeed, linux-kernel,
Cosmo Chou, Mike Hsieh, Potin Lai, Potin Lai
In-Reply-To: <20260523-potin-update-sanmiguel-dts-20260522-v1-0-169f5fceb5f9@quantatw.com>
Kernel dmesg reports IRQ #44 being disabled due to unhandled
interrupts from multiple PCA953x IO expanders:
```
[ 447.047861] irq 44: nobody cared (try booting with the "irqpoll" option)
[ 447.063124] handlers:
[ 447.068176] [<2ab869ad>] irq_default_primary_handler threaded [<b8adc310>] pca953x_irq_handler
[ 447.087268] [<2ab869ad>] irq_default_primary_handler threaded [<b8adc310>] pca953x_irq_handler
[ 447.106344] [<2ab869ad>] irq_default_primary_handler threaded [<b8adc310>] pca953x_irq_handler
[ 447.125421] [<2ab869ad>] irq_default_primary_handler threaded [<b8adc310>] pca953x_irq_handler
[ 447.144513] [<2ab869ad>] irq_default_primary_handler threaded [<b8adc310>] pca953x_irq_handler
[ 447.163587] [<2ab869ad>] irq_default_primary_handler threaded [<b8adc310>] pca953x_irq_handler
[ 447.182663] [<2ab869ad>] irq_default_primary_handler threaded [<b8adc310>] pca953x_irq_handler
[ 447.201756] [<2ab869ad>] irq_default_primary_handler threaded [<b8adc310>] pca953x_irq_handler
[ 447.220837] Disabling IRQ #44
```
The affected IOEXP nodes are missing interrupt pin configuration in
the device tree, causing the interrupt line to remain asserted and
resulting in repeated unhandled IRQ events.
Add the required interrupt-related properties for the affected IOEXP
devices to ensure proper interrupt handling and prevent the IRQ from
being disabled.
Signed-off-by: Potin Lai <potin.lai@quantatw.com>
---
arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-sanmiguel.dts | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-sanmiguel.dts b/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-sanmiguel.dts
index 74c8c1772109..61dbef45f8b0 100644
--- a/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-sanmiguel.dts
+++ b/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-sanmiguel.dts
@@ -334,6 +334,8 @@ hmc_ioexp: gpio@20 {
reg = <0x20>;
gpio-controller;
#gpio-cells = <2>;
+ interrupt-parent = <&gpio1>;
+ interrupts = <ASPEED_GPIO(B, 6) IRQ_TYPE_LEVEL_LOW>;
gpio-line-names =
"", "", "HMC_EROT_FATAL_ERROR_L-I", "",
@@ -552,6 +554,8 @@ smm_ext_ioexp: gpio@38 {
reg = <0x38>;
gpio-controller;
#gpio-cells = <2>;
+ interrupt-parent = <&gpio1>;
+ interrupts = <ASPEED_GPIO(B, 6) IRQ_TYPE_LEVEL_LOW>;
gpio-line-names =
"SSD0_PRSNT_L-I", "E1S_PWR_EN-O",
--
2.52.0
^ permalink raw reply related
* [PATCH 2/2] ARM: dts: aspeed: sanmiguel: Fix the CPU_CHIPTHROT linename
From: Potin Lai @ 2026-05-23 2:28 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Joel Stanley,
Andrew Jeffery, Patrick Williams
Cc: devicetree, linux-arm-kernel, linux-aspeed, linux-kernel,
Cosmo Chou, Mike Hsieh, Potin Lai, Potin Lai
In-Reply-To: <20260523-potin-update-sanmiguel-dts-20260522-v1-0-169f5fceb5f9@quantatw.com>
Fix the GPIO linenames for CPU_CHIPTHROT signals.
The signals were incorrectly marked as output ("-O") while they are
actually input signals ("-I").
- B0_M0_CPU_CHIPTHROT_L-O -> B0_M0_CPU_CHIPTHROT_L-I
- B1_M0_CPU_CHIPTHROT_L-O -> B1_M0_CPU_CHIPTHROT_L-I
Signed-off-by: Potin Lai <potin.lai@quantatw.com>
---
arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-sanmiguel.dts | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-sanmiguel.dts b/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-sanmiguel.dts
index 61dbef45f8b0..d7ed497d7227 100644
--- a/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-sanmiguel.dts
+++ b/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-sanmiguel.dts
@@ -224,7 +224,7 @@ hpm0_ioexp_20: gpio@20 {
"B0_M0_LEAK_DETECT_ALERT_L-I",
"B0_M0_RUN_POWER_EN-O",
"B0_M0_RUN_POWER_PG-I",
- "B0_M0_CPU_CHIPTHROT_L-O",
+ "B0_M0_CPU_CHIPTHROT_L-I",
"B0_M0_SHDN_REQ_L-O",
"B0_M0_CPU_SHDN_OK_L-I",
"B0_M0_CPLD_READY-I",
@@ -398,7 +398,7 @@ hpm1_ioexp_20: gpio@20 {
"B1_M0_LEAK_DETECT_ALERT_L-I",
"B1_M0_RUN_POWER_EN-O",
"B1_M0_RUN_POWER_PG-I",
- "B1_M0_CPU_CHIPTHROT_L-O",
+ "B1_M0_CPU_CHIPTHROT_L-I",
"B1_M0_SHDN_REQ_L-O",
"B1_M0_CPU_SHDN_OK_L-I",
"B1_M0_CPLD_READY-I",
--
2.52.0
^ permalink raw reply related
* Re: [PATCH 14/16] media: sun6i-isp: Use V4L2 subdev active state
From: arash golgol @ 2026-05-23 3:15 UTC (permalink / raw)
To: Paul Kocialkowski
Cc: linux-media, linux-arm-kernel, linux-sunxi, linux-kernel,
linux-staging, Mauro Carvalho Chehab, Chen-Yu Tsai,
Jernej Skrabec, Samuel Holland, Greg Kroah-Hartman,
Laurent Pinchart, Nicolas Dufresne
In-Reply-To: <ahA61YIGM4Bqipu7@collins>
Hi Paul,
On Fri, May 22, 2026 at 2:45 PM Paul Kocialkowski <paulk@sys-base.io> wrote:
>
> Hi Arash,
>
> Le Thu 21 May 26, 12:53, arash golgol a écrit :
> > I used LicheePi Zero Dock (V3s) with the following pipeline as test setup.
> >
> > ov5647 -> sun6i-mipi-csi2 -> sun6i-csi-bridge -> sun6i-isp-proc ->
> > sun6i-isp-capture
> >
> > I verified TRY and ACTIVE state handling, including changing TRY
> > formats without affecting ACTIVE state. Format propagation from the
> > sink (csi) pad to the source pad was also tested.
> >
> > I also tested streaming with the sensor test pattern enabled and
> > verified the captured output was correct.
> >
> > Tested-by: Arash Golgol <arash.golgol@gmail.com>
>
> Thanks a lot for testing this! Did you test just this patch or the other
> ones (especially sun6i-csi format enumeration) as well?
>
Happy to help.
I only tested patch 14 for now, but I plan to test the other patches
as well when I get some more time, especially the sun6i-csi changes.
> Also if you have an opinion on the code itself feel free to drop a
> Reviewed-by tag, a lot of this work is very similar to what you did for
> sun6i-csi and other drivers.
>
From a code perspective, the changes look good to me.
Reviewed-by: Arash Golgol <arash.golgol@gmail.com>
--
Regards,
Arash Golgol
^ permalink raw reply
* Re: [PATCH v5 2/4] kernel: param: initialize module_kset in a pure_initcall
From: Shashank Balaji @ 2026-05-23 3:24 UTC (permalink / raw)
To: Petr Pavlu
Cc: Suzuki K Poulose, James Clark, Alexander Shishkin,
Greg Kroah-Hartman, Rafael J. Wysocki, Danilo Krummrich,
Miguel Ojeda, Boqun Feng, Gary Guo, Björn Roy Baron,
Benno Lossin, Andreas Hindborg, Alice Ryhl, Trevor Gross,
Jonathan Corbet, Shuah Khan, Luis Chamberlain, Daniel Gomez,
Sami Tolvanen, Aaron Tomlin, Mike Leach, Leo Yan, Thierry Reding,
Jonathan Hunter, Rahul Bukte, linux-kernel, coresight,
linux-arm-kernel, driver-core, rust-for-linux, linux-doc,
Daniel Palmer, Tim Bird, linux-modules, linux-tegra, Sumit Gupta
In-Reply-To: <a0b17be8-f7dd-4d05-bc6f-28b32d0b0785@suse.com>
Hi Petr,
Thanks for the feedback!
On Fri, May 22, 2026 at 03:06:04PM +0200, Petr Pavlu wrote:
> On 5/18/26 12:19 PM, Shashank Balaji wrote:
> > Commit "driver core: platform: set mod_name in driver registration" will set
> > struct device_driver's mod_name member for platform driver registration. For a
> > driver to be registered with its mod_name set, module_kset needs to be
> > initialized, which currently happens in a subsys_initcall in param_sysfs_init().
> > The tegra cbb drivers register themselves before module_kset init, in a
> > core_initcall. This works currently because lookup_or_create_module_kobject(),
> > which dereferences module_kset via kset_find_obj(), is not called if mod_name
> > is not set, which is the case now.
> >
> > So in preparation for the commit "driver core: platform: set mod_name in driver registration",
> > move module_kset init to pure_initcall level, ensuring it happens before tegra
> > cbb driver registration.
> >
> > Suggested-by: Gary Guo <gary@garyguo.net>
> > Co-developed-by: Rahul Bukte <rahul.bukte@sony.com>
> > Signed-off-by: Rahul Bukte <rahul.bukte@sony.com>
> > Signed-off-by: Shashank Balaji <shashank.mahadasyam@sony.com>
> > ---
> > Patch 4 depends on this patch
> > ---
> > kernel/params.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/kernel/params.c b/kernel/params.c
> > index 74d620bc2521..ac088d4b09a9 100644
> > --- a/kernel/params.c
> > +++ b/kernel/params.c
> > @@ -957,7 +957,7 @@ static int __init param_sysfs_init(void)
> >
> > return 0;
> > }
> > -subsys_initcall(param_sysfs_init);
> > +pure_initcall(param_sysfs_init);
> >
> > /*
> > * param_sysfs_builtin_init - add sysfs version and parameter
> >
>
> The change looks ok to me functionality-wise. Sysfs is initialized
> earlier in do_basic_setup() and other code, such as classes_init(),
> calls kset_create_and_add() similarly early.
>
> One minor issue is that pure_initcall() was originally intended for
> static variable initialization. The file include/linux/init.h says:
>
> | /*
> | * A "pure" initcall has no dependencies on anything else, and purely
> | * initializes variables that couldn't be statically initialized.
> | *
> | * This only exists for built-in code, not for modules.
> | * Keep main.c:initcall_level_names[] in sync.
> | */
> | #define pure_initcall(fn) __define_initcall(fn, 0)
>
> The patch stretches the intended use of pure_initcall() somewhat in this
> regard. However, other code already appears to do the same, so I guess
> this is ok.
Ah yeah, I thought of this too, but it seems like everyone else is doing
it. Linus introduced pure_initcall in b3438f8266cb
("Add "pure_initcall" for static variable initialization") with the
comment, and he introduced another user of it in 140d0b2108fa
("Do 'shm_init_ns()' in an early pure_initcall") which already stretches
the intended use as per the comment.
Given that it's just being used for "run me before core_initcall;
early_initcall is too early for me" without any "pureness" requirements, I
suppose the comment is due for a revision?
> Additionally, I think it would be good to update the comment preceding
> param_sysfs_init(). It currently says:
>
> | /*
> | * param_sysfs_init - create "module" kset
> | *
> | * This must be done before the initramfs is unpacked and
> | * request_module() thus becomes possible, because otherwise the
> | * module load would fail in mod_sysfs_init.
> | */
>
> I suggest changing it to something like follows:
>
> This must be done before any driver registration so that when a driver comes
> from a built-in module, the driver core can add the module under /sys/module
> and create the associated driver symlinks.
Thanks for catching this! I'll add it in the next revision.
Thanks,
Shashank
^ permalink raw reply
* Re: [PATCH 16/16] media: sun6i-isp: Add support for frame size enumeration
From: arash golgol @ 2026-05-23 4:34 UTC (permalink / raw)
To: Paul Kocialkowski
Cc: linux-media, linux-arm-kernel, linux-sunxi, linux-kernel,
linux-staging, Mauro Carvalho Chehab, Chen-Yu Tsai,
Jernej Skrabec, Samuel Holland, Greg Kroah-Hartman,
Laurent Pinchart, Nicolas Dufresne
In-Reply-To: <20260518102451.417971-17-paulk@sys-base.io>
Hi Paul,
On Mon, May 18, 2026 at 2:02 PM Paul Kocialkowski <paulk@sys-base.io> wrote:
>
> This implements the enum_framesizes operation, which reports support for
> even sizes.
>
> Signed-off-by: Paul Kocialkowski <paulk@sys-base.io>
> ---
> .../media/sunxi/sun6i-isp/sun6i_isp_capture.c | 22 +++++++++++++++++++
> 1 file changed, 22 insertions(+)
>
> diff --git a/drivers/staging/media/sunxi/sun6i-isp/sun6i_isp_capture.c b/drivers/staging/media/sunxi/sun6i-isp/sun6i_isp_capture.c
> index 372b9331bd6d..e638ec32c7cd 100644
> --- a/drivers/staging/media/sunxi/sun6i-isp/sun6i_isp_capture.c
> +++ b/drivers/staging/media/sunxi/sun6i-isp/sun6i_isp_capture.c
> @@ -452,6 +452,26 @@ static int sun6i_isp_capture_enum_fmt(struct file *file, void *priv,
> return 0;
> }
>
> +static int sun6i_isp_capture_enum_framesizes(struct file *file, void *fh,
> + struct v4l2_frmsizeenum *frmsize)
> +{
> + if (frmsize->index)
> + return -EINVAL;
> +
> + if (!sun6i_isp_capture_format_find(frmsize->pixel_format))
> + return -EINVAL;
> +
> + frmsize->type = V4L2_FRMSIZE_TYPE_STEPWISE;
> + frmsize->stepwise.min_width = SUN6I_ISP_CAPTURE_WIDTH_MIN;
> + frmsize->stepwise.max_width = SUN6I_ISP_CAPTURE_WIDTH_MAX;
> + frmsize->stepwise.min_height = SUN6I_ISP_CAPTURE_HEIGHT_MIN;
> + frmsize->stepwise.max_height = SUN6I_ISP_CAPTURE_HEIGHT_MAX;
> + frmsize->stepwise.step_width = 2;
> + frmsize->stepwise.step_height = 2;
> +
> + return 0;
> +}
> +
> static int sun6i_isp_capture_g_fmt(struct file *file, void *priv,
> struct v4l2_format *format)
> {
> @@ -522,6 +542,8 @@ static const struct v4l2_ioctl_ops sun6i_isp_capture_ioctl_ops = {
> .vidioc_s_fmt_vid_cap = sun6i_isp_capture_s_fmt,
> .vidioc_try_fmt_vid_cap = sun6i_isp_capture_try_fmt,
>
> + .vidioc_enum_framesizes = sun6i_isp_capture_enum_framesizes,
> +
> .vidioc_enum_input = sun6i_isp_capture_enum_input,
> .vidioc_g_input = sun6i_isp_capture_g_input,
> .vidioc_s_input = sun6i_isp_capture_s_input,
> --
> 2.54.0
>
Tested on a LicheePi Zero Dock (V3s) with the ov5647 camera setup.
The enum_framesizes implementation behaves as expected and reports the
supported even frame sizes correctly.
Tested-by: Arash Golgol <arash.golgol@gmail.com>
Reviewed-by: Arash Golgol <arash.golgol@gmail.com>
--
Regards,
Arash Golgol
^ permalink raw reply
* Re: [PATCH 2/4] firmware: arm_ffa: Register core as a platform driver
From: Yeoreum Yun @ 2026-05-23 4:50 UTC (permalink / raw)
To: Nathan Chancellor
Cc: Sudeep Holla, yeoreum.yun, linux-security-module, linux-kernel,
linux-integrity, linux-arm-kernel, kvmarm
In-Reply-To: <20260523001148.GA1319283@ax162>
Hi Nathan,
> Hi Sudeep,
>
> On Fri, May 08, 2026 at 06:54:16PM +0100, Sudeep Holla wrote:
> > Move the FF-A core bring-up and teardown paths into platform driver
> > probe and remove callbacks, and register a synthetic arm-ffa platform
> > device to bind the driver.
> >
> > This makes the FF-A core lifetime follow the driver model while keeping
> > the device creation internal to the FF-A core. Use normal platform driver
> > registration so the probe path has standard driver-core semantics.
> >
> > The synthetic platform device is a temporary bridge until ACPI and
> > devicetree describe the FF-A core device or object. Once those firmware
> > description paths are defined, the internal platform device creation can
> > be dropped and the driver can bind to the firmware-described device
> > directly.
> >
> > Since the transport selection now happens from the platform probe path,
> > drop the __init annotation from ffa_transport_init().
> >
> > Signed-off-by: Sudeep Holla <sudeep.holla@kernel.org>
>
> I am seeing
>
> arm-ffa arm-ffa: probe with driver arm-ffa failed with error -95
>
> on my two arm64 test machines after this change landed in -next as
> commit e659fc8e537c ("firmware: arm_ffa: Register core as a platform
> driver"), is this expected? If so, perhaps it should be silenced?
>
> Cheers,
> Nathan
>
Could you share the .config file you used for this?
Thanks!
[...]
--
Sincerely,
Yeoreum Yun
^ permalink raw reply
* [PATCH v2 1/2] usb: dwc3: xilinx: fix missing space before closing comment delimiter
From: Radhey Shyam Pandey @ 2026-05-23 7:08 UTC (permalink / raw)
To: Thinh.Nguyen, gregkh, michal.simek, p.zabel
Cc: linux-usb, linux-arm-kernel, linux-kernel, git,
Radhey Shyam Pandey
In-Reply-To: <cover.1779518171.git.radhey.shyam.pandey@amd.com>
Add missing space before '*/' in an inline comment to follow
the kernel coding style.
Acked-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com>
Signed-off-by: Radhey Shyam Pandey <radhey.shyam.pandey@amd.com>
---
Changes for v2:
- Add Thinh Nguyen acked by tag.
---
drivers/usb/dwc3/dwc3-xilinx.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/dwc3/dwc3-xilinx.c b/drivers/usb/dwc3/dwc3-xilinx.c
index 9b9525592a85..02dc35e110b9 100644
--- a/drivers/usb/dwc3/dwc3-xilinx.c
+++ b/drivers/usb/dwc3/dwc3-xilinx.c
@@ -194,7 +194,7 @@ static int dwc3_xlnx_init_zynqmp(struct dwc3_xlnx *priv_data)
}
if (priv_data->usb3_phy) {
- /* Set PIPE Power Present signal in FPD Power Present Register*/
+ /* Set PIPE Power Present signal in FPD Power Present Register */
writel(FPD_POWER_PRSNT_OPTION, priv_data->regs + XLNX_USB_FPD_POWER_PRSNT);
/* Set the PIPE Clock Select bit in FPD PIPE Clock register */
writel(PIPE_CLK_SELECT, priv_data->regs + XLNX_USB_FPD_PIPE_CLK);
--
2.43.0
^ permalink raw reply related
* [PATCH v2 0/2] minor cleanup for dwc3-xilinx glue driver
From: Radhey Shyam Pandey @ 2026-05-23 7:08 UTC (permalink / raw)
To: Thinh.Nguyen, gregkh, michal.simek, p.zabel
Cc: linux-usb, linux-arm-kernel, linux-kernel, git,
Radhey Shyam Pandey
Minor cleanups for the dwc3-xilinx glue driver:
- Fix a comment style violation (missing space before closing delimiter).
- Use reset_control_reset in versal init.
Changes for v2:
- Rephrased commit description for 2/2 patch.
- Drop functional fix (usb: dwc3: xilinx: fix error handling in zynqmp
init error paths) from this series.
Radhey Shyam Pandey (2):
usb: dwc3: xilinx: fix missing space before closing comment delimiter
usb: dwc3: xilinx: use reset_control_reset() in versal init
drivers/usb/dwc3/dwc3-xilinx.c | 18 +++++-------------
1 file changed, 5 insertions(+), 13 deletions(-)
base-commit: c1ecb239fa3456529a32255359fc78b69eb9d847
--
2.43.0
^ permalink raw reply
* [PATCH v2 2/2] usb: dwc3: xilinx: use reset_control_reset() in versal init
From: Radhey Shyam Pandey @ 2026-05-23 7:08 UTC (permalink / raw)
To: Thinh.Nguyen, gregkh, michal.simek, p.zabel
Cc: linux-usb, linux-arm-kernel, linux-kernel, git,
Radhey Shyam Pandey
In-Reply-To: <cover.1779518171.git.radhey.shyam.pandey@amd.com>
Replace reset_control_assert()/deassert() with reset_control_reset().
For dwc3-xilinx, reset_control_reset() routes via the zynqmp reset
driver and uses PM_RESET_ACTION_PULSE, which performs assert and
deassert in firmware. This results in a single SMC call issuing a
reset pulse and taking the IP out of reset.
Signed-off-by: Radhey Shyam Pandey <radhey.shyam.pandey@amd.com>
---
Changes for v2:
- As suggested by Thinh rephrased commit description to explain
firmware driven reset sequence.
---
drivers/usb/dwc3/dwc3-xilinx.c | 16 ++++------------
1 file changed, 4 insertions(+), 12 deletions(-)
diff --git a/drivers/usb/dwc3/dwc3-xilinx.c b/drivers/usb/dwc3/dwc3-xilinx.c
index 02dc35e110b9..b832505e1b04 100644
--- a/drivers/usb/dwc3/dwc3-xilinx.c
+++ b/drivers/usb/dwc3/dwc3-xilinx.c
@@ -98,18 +98,10 @@ static int dwc3_xlnx_init_versal(struct dwc3_xlnx *priv_data)
dwc3_xlnx_mask_phy_rst(priv_data, false);
- /* Assert and De-assert reset */
- ret = reset_control_assert(crst);
- if (ret < 0) {
- dev_err_probe(dev, ret, "failed to assert Reset\n");
- return ret;
- }
-
- ret = reset_control_deassert(crst);
- if (ret < 0) {
- dev_err_probe(dev, ret, "failed to De-assert Reset\n");
- return ret;
- }
+ /* assert and deassert reset */
+ ret = reset_control_reset(crst);
+ if (ret)
+ return dev_err_probe(dev, ret, "failed to assert and deassert reset\n");
dwc3_xlnx_mask_phy_rst(priv_data, true);
dwc3_xlnx_set_coherency(priv_data, XLNX_USB2_TRAFFIC_ROUTE_CONFIG);
--
2.43.0
^ permalink raw reply related
* Re: [PATCH 2/4] firmware: arm_ffa: Register core as a platform driver
From: Yeoreum Yun @ 2026-05-23 6:27 UTC (permalink / raw)
To: Nathan Chancellor
Cc: Sudeep Holla, linux-security-module, linux-kernel,
linux-integrity, linux-arm-kernel, kvmarm
In-Reply-To: <20260523050555.GA1121518@ax162>
On Fri, May 22, 2026 at 10:05:55PM -0700, Nathan Chancellor wrote:
> On Sat, May 23, 2026 at 05:50:14AM +0100, Yeoreum Yun wrote:
> > Hi Nathan,
> >
> > > Hi Sudeep,
> > >
> > > On Fri, May 08, 2026 at 06:54:16PM +0100, Sudeep Holla wrote:
> > > > Move the FF-A core bring-up and teardown paths into platform driver
> > > > probe and remove callbacks, and register a synthetic arm-ffa platform
> > > > device to bind the driver.
> > > >
> > > > This makes the FF-A core lifetime follow the driver model while keeping
> > > > the device creation internal to the FF-A core. Use normal platform driver
> > > > registration so the probe path has standard driver-core semantics.
> > > >
> > > > The synthetic platform device is a temporary bridge until ACPI and
> > > > devicetree describe the FF-A core device or object. Once those firmware
> > > > description paths are defined, the internal platform device creation can
> > > > be dropped and the driver can bind to the firmware-described device
> > > > directly.
> > > >
> > > > Since the transport selection now happens from the platform probe path,
> > > > drop the __init annotation from ffa_transport_init().
> > > >
> > > > Signed-off-by: Sudeep Holla <sudeep.holla@kernel.org>
> > >
> > > I am seeing
> > >
> > > arm-ffa arm-ffa: probe with driver arm-ffa failed with error -95
> > >
> > > on my two arm64 test machines after this change landed in -next as
> > > commit e659fc8e537c ("firmware: arm_ffa: Register core as a platform
> > > driver"), is this expected? If so, perhaps it should be silenced?
> >
> > Could you share the .config file you used for this?
>
> Sure thing! It is attached. If you need anything else, please let me
> know.
Thanks! unless there was other error log from ff-a driver,
I think this happens because your environment either doesn’t
support FF-A or is using an SMCCC version earlier than 1.2 from
ffa_version_check() or ffa_transport_init().
If that’s the case, You can ignore this log since this behavior is
expected, and the dd core should print an error log.
Before this patch, the error was not shown because all FF-A initialization
was done during the initcall phase, and nothing was printed
even when the initcall function returned an error from caller of initcall.
[...]
--
Sincerely,
Yeoreum Yun
^ permalink raw reply
* Re: [PATCH v3 6/6] mm/vmalloc: align vm_area so vmap() can batch mappings
From: Uladzislau Rezki @ 2026-05-23 7:53 UTC (permalink / raw)
To: Wen Jiang
Cc: linux-mm, linux-arm-kernel, catalin.marinas, will, akpm, urezki,
baohua, Xueyuan.chen21, dev.jain, rppt, david, ryan.roberts,
anshuman.khandual, ajd, linux-kernel, jiangwen6
In-Reply-To: <20260522053146.83209-7-jiangwenxiaomi@gmail.com>
On Fri, May 22, 2026 at 01:31:46PM +0800, Wen Jiang wrote:
> From: "Barry Song (Xiaomi)" <baohua@kernel.org>
>
> Try to align the vmap virtual address to PMD_SHIFT or a
> larger PTE mapping size hinted by the architecture, so
> contiguous pages can be batch-mapped when setting PMD or
> PTE entries.
>
> Signed-off-by: Barry Song (Xiaomi) <baohua@kernel.org>
> Signed-off-by: Wen Jiang <jiangwen6@xiaomi.com>
> Tested-by: Xueyuan Chen <xueyuan.chen21@gmail.com>
> ---
> mm/vmalloc.c | 33 ++++++++++++++++++++++++++++++++-
> 1 file changed, 32 insertions(+), 1 deletion(-)
>
> diff --git a/mm/vmalloc.c b/mm/vmalloc.c
> index 50642246f4d40..040d400928aab 100644
> --- a/mm/vmalloc.c
> +++ b/mm/vmalloc.c
> @@ -3620,6 +3620,37 @@ static int vmap_batched(unsigned long addr, unsigned long end,
> return err;
> }
>
> +static struct vm_struct *get_aligned_vm_area(unsigned long size,
> + unsigned long flags, const void *caller)
> +{
> + struct vm_struct *vm_area;
> + unsigned int shift;
> +
> + /* Try PMD alignment for large sizes */
> + if (size >= PMD_SIZE) {
> + vm_area = __get_vm_area_node(size, PMD_SIZE, PAGE_SHIFT, flags,
> + VMALLOC_START, VMALLOC_END,
> + NUMA_NO_NODE, GFP_KERNEL, caller);
> + if (vm_area)
> + return vm_area;
> + }
> +
> + /* Try CONT_PTE alignment */
> + shift = arch_vmap_pte_supported_shift(size);
> + if (shift > PAGE_SHIFT) {
> + vm_area = __get_vm_area_node(size, 1UL << shift, PAGE_SHIFT, flags,
> + VMALLOC_START, VMALLOC_END,
> + NUMA_NO_NODE, GFP_KERNEL, caller);
> + if (vm_area)
> + return vm_area;
> + }
> +
> + /* Fall back to page alignment */
> + return __get_vm_area_node(size, PAGE_SIZE, PAGE_SHIFT, flags,
> + VMALLOC_START, VMALLOC_END,
> + NUMA_NO_NODE, GFP_KERNEL, caller);
> +}
> +
> /**
> * vmap - map an array of pages into virtually contiguous space
> * @pages: array of page pointers
> @@ -3658,7 +3689,7 @@ void *vmap(struct page **pages, unsigned int count,
> return NULL;
>
> size = (unsigned long)count << PAGE_SHIFT;
> - area = get_vm_area_caller(size, flags, __builtin_return_address(0));
> + area = get_aligned_vm_area(size, flags, __builtin_return_address(0));
> if (!area)
> return NULL;
>
> --
> 2.34.1
>
This one LGTM:
Reviewed-by: Uladzislau Rezki (Sony) <urezki@gmail.com>
--
Uladzislau Rezki
^ permalink raw reply
* Re: [GIT PULL] KVM/arm64 fixes for 7.1, take #3
From: Paolo Bonzini @ 2026-05-23 8:03 UTC (permalink / raw)
To: Marc Zyngier
Cc: Michael Bommarito, Vincent Donnefort, Will Deacon, Yuan Yao,
Steffen Eiden, Joey Gouly, Suzuki K Poulose, Oliver Upton,
Zenghui Yu, kvmarm, linux-arm-kernel, kvm
In-Reply-To: <20260520072518.504865-1-maz@kernel.org>
On Wed, May 20, 2026 at 9:25 AM Marc Zyngier <maz@kernel.org> wrote:
>
> Paolo,
>
> Here's the next set of KVM/arm64 fixes for 7.1. Continuing the trend,
> we have two AI-fuelled fixes, both of which are stable candidates.
> Additionally, a minor tidying-up of the hypervisor tracing descriptor
> validation.
>
> Please pull,
>
> M.
>
> The following changes since commit effc0a39b8e0f30670fe24f51e44329d4324e566:
>
> KVM: arm64: Pre-check vcpu memcache for host->guest donate (2026-05-07 14:12:42 +0100)
>
> are available in the Git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/kvmarm/kvmarm.git tags/kvmarm-fixes-7.1-3
>
> for you to fetch changes up to 1702da76e017ae0fbe1a92b07bc332972c293e89:
>
> KVM: arm64: Fix nVHE/pKVM hyp tracing error on invalid desc (2026-05-20 08:08:37 +0100)
Done, thanks.
Paolo
> ----------------------------------------------------------------
> KVM/arm64 fixes for 7.1, take #3
>
> - Fix ITS EventID sanitisation when restoring an interrupt translation
> table.
>
> - Fix PPI memory leak when failing to initialise a vcpu.
>
> - Correctly return an error when the validation of a hypervisor trace
> descriptor fails, and limit this validation to protected mode only.
>
> ----------------------------------------------------------------
> Michael Bommarito (2):
> KVM: arm64: vgic-its: Reject restored DTE with out-of-range num_eventid_bits
> KVM: arm64: vgic: Free private_irqs when init fails after allocation
>
> Vincent Donnefort (1):
> KVM: arm64: Fix nVHE/pKVM hyp tracing error on invalid desc
>
> arch/arm64/kvm/arm.c | 4 +++-
> arch/arm64/kvm/hyp/nvhe/trace.c | 9 +++++++--
> arch/arm64/kvm/vgic/vgic-its.c | 4 ++++
> 3 files changed, 14 insertions(+), 3 deletions(-)
>
^ permalink raw reply
* Re: [PATCH v3 0/6] mm/vmalloc: Speed up ioremap, vmalloc and vmap with contiguous memory
From: Wen Jiang @ 2026-05-23 8:26 UTC (permalink / raw)
To: Andrew Morton
Cc: linux-mm, linux-arm-kernel, catalin.marinas, will, urezki, baohua,
Xueyuan.chen21, dev.jain, rppt, david, ryan.roberts,
anshuman.khandual, ajd, linux-kernel, jiangwen6
In-Reply-To: <20260522110727.fc7dccf90bc8513abd1fdbf1@linux-foundation.org>
On Sat, 23 May 2026 at 02:07, Andrew Morton <akpm@linux-foundation.org> wrote:
>
> On Fri, 22 May 2026 13:31:40 +0800 Wen Jiang <jiangwenxiaomi@gmail.com> wrote:
>
> > This patchset accelerates ioremap, vmalloc, and vmap when the memory
> > is physically fully or partially contiguous.
>
> Thanks. AI review asked a few things and might have found an existing
> 32-bit bug in vmap():
>
> https://sashiko.dev/#/patchset/20260522053146.83209-1-jiangwenxiaomi@gmail.com
Hi Andrew,
I've gone through the Sashiko findings:
- Patch 5 (arch_vmap_pte_supported_shift on x86): Over-interpretation.
This targets ARM64 CONT_PTE. x86 falls through with PAGE_SHIFT
same as before.
- Patch 5 (1 << order overflow at order=31): Over-interpretation.
Reaching order=31 requires 8TB contiguous in a single vmap()
not a realistic usage pattern.
- Patch 6 (GFP_KERNEL triggering purge): The purge only triggers
when vmalloc space is already under pressure, and benefits the
subsequent PAGE_SIZE fallback as well, not wasted work.
- Patch 6 (32-bit count << PAGE_SHIFT overflow): Pre-existing.
Will send a separate fix.
- Patch 6 (unconditional alignment without checking contiguity):
The main vmap() users typically pass contiguous pages
(e.g. system_heap order 8 -> 4 -> 0).
Thanks,
Wen
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox