* Re: [PATCH 2/3] drm: lcdif: Use dedicated set/clr registers for polarity/edge
From: Lucas Stach @ 2026-03-31 16:04 UTC (permalink / raw)
To: Paul Kocialkowski
Cc: dri-devel, imx, linux-arm-kernel, linux-kernel, Marek Vasut,
Stefan Agner, Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
David Airlie, Simona Vetter, Frank Li, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam, Krzysztof Hałasa,
Marco Felsch, Liu Ying
In-Reply-To: <acvllbRTHyVFTgmS@collins>
Am Dienstag, dem 31.03.2026 um 17:17 +0200 schrieb Paul Kocialkowski:
> Hi Lucas,
>
> Le Tue 31 Mar 26, 11:09, Lucas Stach a écrit :
> > Hi Paul,
> >
> > Am Dienstag, dem 31.03.2026 um 00:46 +0200 schrieb Paul Kocialkowski:
> > > The lcdif v3 hardware comes with dedicated registers to set and clear
> > > polarity bits in the CTRL register. It is unclear if there is a
> > > difference with writing to the CTRL register directly.
> > >
> > > Follow the NXP BSP reference by using these registers, in case there is
> > > a subtle difference caused by using them.
> > >
> > I don't really like that patch, as it blows up what is currently a
> > single register access to three separate ones. If there is no clear
> > benefit (as in it has been shown to fix any issue), I would prefer this
> > code to stay as-is.
>
> Well I guess the cost of a few writes vs a single one is rather
> negligible.
>
Yea, a few writes don't really hurt. But I don't think there is a very
good reason to set this register this way, see below.
> I'm rather worried that there might be an undocumented
> reason why these registers exist in the first place and why they are
> used in the BSP.
>
> But yes this is only speculation and I could not witness any actual
> issue. My setup (lcdif3 with hdmi) uses all positive polarities which is
> the default state, so not a good way to check.
>
> It would be great if somebody from NXP could confirm whether this is
> needed or not. In the meantime I guess we can drop the patch. It'll stay
> on the list in case someone has polarity issues later :)
The separate clr/set registers are a rather common design feat found on
Freescale/NXP IP blocks from the MXS era. On some of those IP blocks
_all_ registers are presented as a base/clr/set triplet in the
registers space. As far as I can tell they are mostly useful when you
want to set/clear individual bits from a register without having to
remember or executing a readback of the current state.
In cases like the one changed in this patch, where the full register
state is set in one go, directly writing to the base register is the
right thing to do.
Regards,
Lucas
^ permalink raw reply
* Re: [PATCH] pmdomain: imx8mp-blk-ctrl: Keep the NOC_HDCP clock enabled
From: Ulf Hansson @ 2026-03-31 16:03 UTC (permalink / raw)
To: Jacky Bai
Cc: Frank Li, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
Shawn Guo, Peng Fan, linux-pm, imx, linux-arm-kernel,
linux-kernel
In-Reply-To: <20260320-imx8mp_hdmi_hang-v1-1-ccfce0517999@nxp.com>
On Fri, 20 Mar 2026 at 09:41, Jacky Bai <ping.bai@nxp.com> wrote:
>
> Keep the NOC_HDCP clock always enabled to fix the potential hang
> caused by the NoC ADB400 port power down handshake.
>
> Fixes: 77b0ddb42add ("soc: imx: add i.MX8MP HDMI blk ctrl HDCP/HRV_MWR")
> Signed-off-by: Jacky Bai <ping.bai@nxp.com>
Applied for fixes and by adding a stable tag, thanks!
Kind regards
Uffe
> ---
> drivers/pmdomain/imx/imx8mp-blk-ctrl.c | 8 +-------
> 1 file changed, 1 insertion(+), 7 deletions(-)
>
> diff --git a/drivers/pmdomain/imx/imx8mp-blk-ctrl.c b/drivers/pmdomain/imx/imx8mp-blk-ctrl.c
> index 8fc79f9723f07e34fd3f5162f2c9c549dcdaeb5b..3f5b9499d30a0c8fb8ad8ba3b638d7de1fc55ab6 100644
> --- a/drivers/pmdomain/imx/imx8mp-blk-ctrl.c
> +++ b/drivers/pmdomain/imx/imx8mp-blk-ctrl.c
> @@ -352,9 +352,6 @@ static void imx8mp_hdmi_blk_ctrl_power_on(struct imx8mp_blk_ctrl *bc,
> regmap_set_bits(bc->regmap, HDMI_RTX_RESET_CTL0, BIT(12));
> regmap_clear_bits(bc->regmap, HDMI_TX_CONTROL0, BIT(3));
> break;
> - case IMX8MP_HDMIBLK_PD_HDCP:
> - regmap_set_bits(bc->regmap, HDMI_RTX_CLK_CTL0, BIT(11));
> - break;
> case IMX8MP_HDMIBLK_PD_HRV:
> regmap_set_bits(bc->regmap, HDMI_RTX_CLK_CTL1, BIT(3) | BIT(4) | BIT(5));
> regmap_set_bits(bc->regmap, HDMI_RTX_RESET_CTL0, BIT(15));
> @@ -408,9 +405,6 @@ static void imx8mp_hdmi_blk_ctrl_power_off(struct imx8mp_blk_ctrl *bc,
> regmap_clear_bits(bc->regmap, HDMI_RTX_CLK_CTL0, BIT(7));
> regmap_clear_bits(bc->regmap, HDMI_RTX_CLK_CTL1, BIT(22) | BIT(24));
> break;
> - case IMX8MP_HDMIBLK_PD_HDCP:
> - regmap_clear_bits(bc->regmap, HDMI_RTX_CLK_CTL0, BIT(11));
> - break;
> case IMX8MP_HDMIBLK_PD_HRV:
> regmap_clear_bits(bc->regmap, HDMI_RTX_RESET_CTL0, BIT(15));
> regmap_clear_bits(bc->regmap, HDMI_RTX_CLK_CTL1, BIT(3) | BIT(4) | BIT(5));
> @@ -439,7 +433,7 @@ static int imx8mp_hdmi_power_notifier(struct notifier_block *nb,
> regmap_write(bc->regmap, HDMI_RTX_CLK_CTL0, 0x0);
> regmap_write(bc->regmap, HDMI_RTX_CLK_CTL1, 0x0);
> regmap_set_bits(bc->regmap, HDMI_RTX_CLK_CTL0,
> - BIT(0) | BIT(1) | BIT(10));
> + BIT(0) | BIT(1) | BIT(10) | BIT(11));
> regmap_set_bits(bc->regmap, HDMI_RTX_RESET_CTL0, BIT(0));
>
> /*
>
> ---
> base-commit: b84a0ebe421ca56995ff78b66307667b62b3a900
> change-id: 20260122-imx8mp_hdmi_hang-e7c5b4bdf1bb
>
> Best regards,
> --
> Jacky Bai <ping.bai@nxp.com>
>
^ permalink raw reply
* Re: [PATCH v4 5/9] mfd: mt6397: Add support for MT6392 PMIC
From: kernel test robot @ 2026-03-31 16:01 UTC (permalink / raw)
To: Luca Leonardo Scorcia, linux-mediatek
Cc: llvm, oe-kbuild-all, Fabien Parent, Val Packett,
Luca Leonardo Scorcia, AngeloGioacchino Del Regno,
Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Sen Chu, Sean Wang, Macpaul Lin, Lee Jones, Matthias Brugger,
Linus Walleij, Liam Girdwood, Mark Brown, Gary Bisson,
Julien Massot, Louis-Alexis Eyraud, Chen Zhong, linux-input,
devicetree, linux-kernel, linux-pm, linux-arm-kernel, linux-gpio
In-Reply-To: <20260330083429.359819-6-l.scorcia@gmail.com>
Hi Luca,
kernel test robot noticed the following build warnings:
[auto build test WARNING on lee-mfd/for-mfd-next]
[also build test WARNING on broonie-regulator/for-next linusw-pinctrl/devel linusw-pinctrl/for-next lee-mfd/for-mfd-fixes linus/master v7.0-rc6 next-20260330]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]
url: https://github.com/intel-lab-lkp/linux/commits/Luca-Leonardo-Scorcia/dt-bindings-mfd-mt6397-Add-MT6392-PMIC/20260331-081127
base: https://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd.git for-mfd-next
patch link: https://lore.kernel.org/r/20260330083429.359819-6-l.scorcia%40gmail.com
patch subject: [PATCH v4 5/9] mfd: mt6397: Add support for MT6392 PMIC
config: s390-randconfig-002-20260331 (https://download.01.org/0day-ci/archive/20260331/202603312339.CMJpqhEq-lkp@intel.com/config)
compiler: clang version 17.0.6 (https://github.com/llvm/llvm-project 6009708b4367171ccdbf4b5905cb6a803753fe18)
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20260331/202603312339.CMJpqhEq-lkp@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202603312339.CMJpqhEq-lkp@intel.com/
All warnings (new ones prefixed by >>):
>> drivers/mfd/mt6397-core.c:421:16: warning: cast to smaller integer type 'enum mfd_match_data' from 'const void *' [-Wvoid-pointer-to-enum-cast]
421 | device_data = (enum mfd_match_data)of_device_get_match_data(&pdev->dev);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1 warning generated.
vim +421 drivers/mfd/mt6397-core.c
398
399 static int mt6397_probe(struct platform_device *pdev)
400 {
401 int ret;
402 unsigned int id = 0;
403 struct mt6397_chip *pmic;
404 const struct chip_data *pmic_core;
405 enum mfd_match_data device_data;
406
407 pmic = devm_kzalloc(&pdev->dev, sizeof(*pmic), GFP_KERNEL);
408 if (!pmic)
409 return -ENOMEM;
410
411 pmic->dev = &pdev->dev;
412
413 /*
414 * mt6397 MFD is child device of soc pmic wrapper.
415 * Regmap is set from its parent.
416 */
417 pmic->regmap = dev_get_regmap(pdev->dev.parent, NULL);
418 if (!pmic->regmap)
419 return -ENODEV;
420
> 421 device_data = (enum mfd_match_data)of_device_get_match_data(&pdev->dev);
422 switch (device_data) {
423 case MATCH_DATA_MT6323:
424 pmic_core = &mt6323_core;
425 break;
426 case MATCH_DATA_MT6328:
427 pmic_core = &mt6328_core;
428 break;
429 case MATCH_DATA_MT6331:
430 pmic_core = &mt6331_mt6332_core;
431 break;
432 case MATCH_DATA_MT6357:
433 pmic_core = &mt6357_core;
434 break;
435 case MATCH_DATA_MT6358:
436 pmic_core = &mt6358_core;
437 break;
438 case MATCH_DATA_MT6359:
439 pmic_core = &mt6359_core;
440 break;
441 case MATCH_DATA_MT6392:
442 pmic_core = &mt6392_core;
443 break;
444 case MATCH_DATA_MT6397:
445 pmic_core = &mt6397_core;
446 break;
447 default:
448 dev_err(&pdev->dev, "Unknown device match data %u\n", device_data);
449 return -ENODEV;
450 }
451
452 ret = regmap_read(pmic->regmap, pmic_core->cid_addr, &id);
453 if (ret) {
454 dev_err(&pdev->dev, "Failed to read chip id: %d\n", ret);
455 return ret;
456 }
457
458 pmic->chip_id = (id >> pmic_core->cid_shift) & 0xff;
459
460 platform_set_drvdata(pdev, pmic);
461
462 pmic->irq = platform_get_irq(pdev, 0);
463 if (pmic->irq <= 0)
464 return pmic->irq;
465
466 ret = pmic_core->irq_init(pmic);
467 if (ret)
468 return ret;
469
470 ret = devm_mfd_add_devices(&pdev->dev, PLATFORM_DEVID_NONE,
471 pmic_core->cells, pmic_core->cell_size,
472 NULL, 0, pmic->irq_domain);
473 if (ret) {
474 irq_domain_remove(pmic->irq_domain);
475 dev_err(&pdev->dev, "failed to add child devices: %d\n", ret);
476 }
477
478 return ret;
479 }
480
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* Re: [PATCH 12/15] KVM: arm64: Remove evaluation of timer state in kvm_cpu_has_pending_timer()
From: Sascha Bischoff @ 2026-03-31 15:44 UTC (permalink / raw)
To: maz@kernel.org, kvmarm@lists.linux.dev, kvm@vger.kernel.org,
linux-arm-kernel@lists.infradead.org
Cc: Joey Gouly, yuzenghui@huawei.com, Suzuki Poulose,
oupton@kernel.org, broonie@kernel.org, nd
In-Reply-To: <20260326153530.3981879-13-maz@kernel.org>
On Thu, 2026-03-26 at 15:35 +0000, Marc Zyngier wrote:
> The vgic-v5 code added some evaluations of the timers in a helper
> funtion
> (kvm_cpu_has_pending_timer()) that is called to determine whether
> the vcpu can wake-up.
>
> But looking at the timer there is wrong:
>
> - we want to see timers that are signalling an interrupt to the
> vcpu, and not just that have a pending interrupt
>
> - we already have kvm_arch_vcpu_runnable() that evaluates the
> state of interrupts
>
> - kvm_cpu_has_pending_timer() really is about WFIT, as the timeout
> does not generate an interrupt, and is therefore distinct from
> the point above
>
> As a consequence, revert these changes.
>
> Fixes: 9491c63b6cd7b ("KVM: arm64: gic-v5: Enlighten arch timer for
> GICv5")
> Link:
> https://sashiko.dev/#/patchset/20260319154937.3619520-1-sascha.bischoff%40arm.com
> Signed-off-by: Marc Zyngier <maz@kernel.org>
> ---
> arch/arm64/kvm/arch_timer.c | 6 +-----
> 1 file changed, 1 insertion(+), 5 deletions(-)
>
> diff --git a/arch/arm64/kvm/arch_timer.c
> b/arch/arm64/kvm/arch_timer.c
> index 37279f8748695..6608c47d1f628 100644
> --- a/arch/arm64/kvm/arch_timer.c
> +++ b/arch/arm64/kvm/arch_timer.c
> @@ -402,11 +402,7 @@ static bool kvm_timer_should_fire(struct
> arch_timer_context *timer_ctx)
>
> int kvm_cpu_has_pending_timer(struct kvm_vcpu *vcpu)
> {
> - struct arch_timer_context *vtimer = vcpu_vtimer(vcpu);
> - struct arch_timer_context *ptimer = vcpu_ptimer(vcpu);
> -
> - return kvm_timer_should_fire(vtimer) ||
> kvm_timer_should_fire(ptimer) ||
> - (vcpu_has_wfit_active(vcpu) && wfit_delay_ns(vcpu) ==
> 0);
> + return vcpu_has_wfit_active(vcpu) && wfit_delay_ns(vcpu) ==
> 0;
> }
>
> /*
Hi Marc,
It appears that I'd misunderstood the intent of this function when I
originally wrote this bit code. That is: I agree that these checks
shouldn't be here.
However, said checks are needed somewhere. With GICv5, we directly
inject the timer state (when possible, at least) which means that we
never see the timer interrupt firing on the host, and don't track if it
is pending or not in struct vgic_irq as the pending state is driven by
the hardware itself. The result of this is that we explicitly need to
check if the timer interrupt would be pending if the guest were running
somewhere.
I've run with this complete series and have tested the following
change. It is sufficient to catch this case, and does it as part of
checking if there are pending interrupts, i.e., a more appropriate
place called via kvm_arch_vcpu_runnable(). It is yet-another GICv5
special case, however. I'd love to hear your thoughts.
diff --git a/arch/arm64/kvm/arch_timer.c b/arch/arm64/kvm/arch_timer.c
index cbea4d9ee9552..f8b95721857c3 100644
--- a/arch/arm64/kvm/arch_timer.c
+++ b/arch/arm64/kvm/arch_timer.c
@@ -400,6 +400,14 @@ static bool kvm_timer_should_fire(struct arch_timer_context *timer_ctx)
return cval <= now;
}
+int kvm_cpu_timer_should_fire(struct kvm_vcpu *vcpu)
+{
+ struct arch_timer_context *vtimer = vcpu_vtimer(vcpu);
+ struct arch_timer_context *ptimer = vcpu_ptimer(vcpu);
+
+ return kvm_timer_should_fire(vtimer) || kvm_timer_should_fire(ptimer);
+}
+
int kvm_cpu_has_pending_timer(struct kvm_vcpu *vcpu)
{
return vcpu_has_wfit_active(vcpu) && wfit_delay_ns(vcpu) == 0;
diff --git a/arch/arm64/kvm/vgic/vgic.c b/arch/arm64/kvm/vgic/vgic.c
index 7680ced92f715..ffb91f535efe8 100644
--- a/arch/arm64/kvm/vgic/vgic.c
+++ b/arch/arm64/kvm/vgic/vgic.c
@@ -1238,6 +1238,9 @@ int kvm_vgic_vcpu_pending_irq(struct kvm_vcpu *vcpu)
if (READ_ONCE(vcpu->arch.vgic_cpu.vgic_v5.gicv5_vpe.db_fired))
return true;
+ if (kvm_cpu_timer_should_fire(vcpu))
+ return true;
+
return vgic_v5_has_pending_ppi(vcpu);
}
diff --git a/include/kvm/arm_vgic.h b/include/kvm/arm_vgic.h
index f0e56ad36bf1f..1bd6f23979837 100644
--- a/include/kvm/arm_vgic.h
+++ b/include/kvm/arm_vgic.h
@@ -825,6 +825,7 @@ int kvm_vgic_get_map(struct kvm_vcpu *vcpu, unsigned int vintid);
bool kvm_vgic_map_is_active(struct kvm_vcpu *vcpu, unsigned int vintid);
int kvm_vgic_vcpu_pending_irq(struct kvm_vcpu *vcpu);
+int kvm_cpu_timer_should_fire(struct kvm_vcpu *vcpu);
void kvm_vgic_load(struct kvm_vcpu *vcpu);
void kvm_vgic_put(struct kvm_vcpu *vcpu);
^ permalink raw reply related
* [PATCH 3/3] KVM: arm64: Don't hold 'vm_table_lock' across guest page reclaim
From: Will Deacon @ 2026-03-31 15:50 UTC (permalink / raw)
To: kvmarm
Cc: linux-arm-kernel, Will Deacon, Marc Zyngier, Oliver Upton,
Joey Gouly, Suzuki K Poulose, Zenghui Yu, Catalin Marinas,
Quentin Perret, Fuad Tabba, Vincent Donnefort, Mostafa Saleh,
Alexandru Elisei
In-Reply-To: <20260331155056.28220-1-will@kernel.org>
Now that the teardown of a VM cannot be finalised as long as a reference
is held on the VM, rework __pkvm_reclaim_dying_guest_page() to hold a
reference to the dying VM rather than take the global 'vm_table_lock'
during the reclaim operation.
Signed-off-by: Will Deacon <will@kernel.org>
---
arch/arm64/kvm/hyp/nvhe/pkvm.c | 13 +++++++------
1 file changed, 7 insertions(+), 6 deletions(-)
diff --git a/arch/arm64/kvm/hyp/nvhe/pkvm.c b/arch/arm64/kvm/hyp/nvhe/pkvm.c
index b955da0e50bc..7ed96d64d611 100644
--- a/arch/arm64/kvm/hyp/nvhe/pkvm.c
+++ b/arch/arm64/kvm/hyp/nvhe/pkvm.c
@@ -918,15 +918,16 @@ teardown_donated_memory(struct kvm_hyp_memcache *mc, void *addr, size_t size)
int __pkvm_reclaim_dying_guest_page(pkvm_handle_t handle, u64 gfn)
{
- struct pkvm_hyp_vm *hyp_vm;
+ struct pkvm_hyp_vm *hyp_vm = get_pkvm_hyp_vm(handle);
int ret = -EINVAL;
- hyp_spin_lock(&vm_table_lock);
- hyp_vm = get_vm_by_handle(handle);
- if (hyp_vm && hyp_vm->kvm.arch.pkvm.is_dying)
- ret = __pkvm_host_reclaim_page_guest(gfn, hyp_vm);
- hyp_spin_unlock(&vm_table_lock);
+ if (!hyp_vm)
+ return ret;
+ if (hyp_vm->kvm.arch.pkvm.is_dying)
+ ret = __pkvm_host_reclaim_page_guest(gfn, hyp_vm);
+
+ put_pkvm_hyp_vm(hyp_vm);
return ret;
}
--
2.53.0.1118.gaef5881109-goog
^ permalink raw reply related
* [PATCH 2/3] KVM: arm64: Allow get_pkvm_hyp_vm() to take a reference to a dying VM
From: Will Deacon @ 2026-03-31 15:50 UTC (permalink / raw)
To: kvmarm
Cc: linux-arm-kernel, Will Deacon, Marc Zyngier, Oliver Upton,
Joey Gouly, Suzuki K Poulose, Zenghui Yu, Catalin Marinas,
Quentin Perret, Fuad Tabba, Vincent Donnefort, Mostafa Saleh,
Alexandru Elisei
In-Reply-To: <20260331155056.28220-1-will@kernel.org>
Now that completion of the teardown path requires a refcount of zero for
the target VM, we can allow get_pkvm_hyp_vm() to take a reference on a
dying VM, which is necessary to unshare pages with a non-protected VM
during the teardown process itself.
Note that vCPUs belonging to a dying VM cannot be loaded and pages can
only be reclaimed from a protected VM (via
__pkvm_reclaim_dying_guest_page()) if the target VM is in the dying
state.
Signed-off-by: Will Deacon <will@kernel.org>
---
arch/arm64/kvm/hyp/nvhe/pkvm.c | 8 +-------
1 file changed, 1 insertion(+), 7 deletions(-)
diff --git a/arch/arm64/kvm/hyp/nvhe/pkvm.c b/arch/arm64/kvm/hyp/nvhe/pkvm.c
index 3fd3b930beeb..b955da0e50bc 100644
--- a/arch/arm64/kvm/hyp/nvhe/pkvm.c
+++ b/arch/arm64/kvm/hyp/nvhe/pkvm.c
@@ -309,14 +309,8 @@ struct pkvm_hyp_vm *get_pkvm_hyp_vm(pkvm_handle_t handle)
hyp_spin_lock(&vm_table_lock);
hyp_vm = get_vm_by_handle(handle);
- if (!hyp_vm)
- goto unlock;
-
- if (hyp_vm->kvm.arch.pkvm.is_dying)
- hyp_vm = NULL;
- else
+ if (hyp_vm)
hyp_page_ref_inc(hyp_virt_to_page(hyp_vm));
-unlock:
hyp_spin_unlock(&vm_table_lock);
return hyp_vm;
--
2.53.0.1118.gaef5881109-goog
^ permalink raw reply related
* [PATCH 1/3] KVM: arm64: Prevent teardown finalisation of referenced 'hyp_vm'
From: Will Deacon @ 2026-03-31 15:50 UTC (permalink / raw)
To: kvmarm
Cc: linux-arm-kernel, Will Deacon, Marc Zyngier, Oliver Upton,
Joey Gouly, Suzuki K Poulose, Zenghui Yu, Catalin Marinas,
Quentin Perret, Fuad Tabba, Vincent Donnefort, Mostafa Saleh,
Alexandru Elisei
In-Reply-To: <20260331155056.28220-1-will@kernel.org>
Destroying a 'hyp_vm' with an elevated referenced count in
__pkvm_finalize_teardown_vm() is only going to lead to tears.
In preparation for allowing limited references to be acquired on dying
VMs during the teardown process, factor out the handle-to-vm logic for
the teardown path and reuse it for both the 'start' and 'finalise'
stages of the teardown process.
Signed-off-by: Will Deacon <will@kernel.org>
---
arch/arm64/kvm/hyp/nvhe/pkvm.c | 32 ++++++++++++++++++--------------
1 file changed, 18 insertions(+), 14 deletions(-)
diff --git a/arch/arm64/kvm/hyp/nvhe/pkvm.c b/arch/arm64/kvm/hyp/nvhe/pkvm.c
index 8b906217c4c3..3fd3b930beeb 100644
--- a/arch/arm64/kvm/hyp/nvhe/pkvm.c
+++ b/arch/arm64/kvm/hyp/nvhe/pkvm.c
@@ -936,20 +936,27 @@ int __pkvm_reclaim_dying_guest_page(pkvm_handle_t handle, u64 gfn)
return ret;
}
+static struct pkvm_hyp_vm *get_pkvm_unref_hyp_vm_locked(pkvm_handle_t handle)
+{
+ struct pkvm_hyp_vm *hyp_vm;
+
+ hyp_assert_lock_held(&vm_table_lock);
+
+ hyp_vm = get_vm_by_handle(handle);
+ if (!hyp_vm || hyp_page_count(hyp_vm))
+ return NULL;
+
+ return hyp_vm;
+}
+
int __pkvm_start_teardown_vm(pkvm_handle_t handle)
{
struct pkvm_hyp_vm *hyp_vm;
int ret = 0;
hyp_spin_lock(&vm_table_lock);
- hyp_vm = get_vm_by_handle(handle);
- if (!hyp_vm) {
- ret = -ENOENT;
- goto unlock;
- } else if (WARN_ON(hyp_page_count(hyp_vm))) {
- ret = -EBUSY;
- goto unlock;
- } else if (hyp_vm->kvm.arch.pkvm.is_dying) {
+ hyp_vm = get_pkvm_unref_hyp_vm_locked(handle);
+ if (!hyp_vm || hyp_vm->kvm.arch.pkvm.is_dying) {
ret = -EINVAL;
goto unlock;
}
@@ -971,12 +978,9 @@ int __pkvm_finalize_teardown_vm(pkvm_handle_t handle)
int err;
hyp_spin_lock(&vm_table_lock);
- hyp_vm = get_vm_by_handle(handle);
- if (!hyp_vm) {
- err = -ENOENT;
- goto err_unlock;
- } else if (!hyp_vm->kvm.arch.pkvm.is_dying) {
- err = -EBUSY;
+ hyp_vm = get_pkvm_unref_hyp_vm_locked(handle);
+ if (!hyp_vm || !hyp_vm->kvm.arch.pkvm.is_dying) {
+ err = -EINVAL;
goto err_unlock;
}
--
2.53.0.1118.gaef5881109-goog
^ permalink raw reply related
* [PATCH 0/3] KVM: arm64: Fix teardown of non-protected VMs with pKVM
From: Will Deacon @ 2026-03-31 15:50 UTC (permalink / raw)
To: kvmarm
Cc: linux-arm-kernel, Will Deacon, Marc Zyngier, Oliver Upton,
Joey Gouly, Suzuki K Poulose, Zenghui Yu, Catalin Marinas,
Quentin Perret, Fuad Tabba, Vincent Donnefort, Mostafa Saleh,
Alexandru Elisei
Hi folks,
Sashiko continues to throw rocks at me.
This time, it spotted that my fix (introduced in v5 [1] of the pKVM
series) to prevent taking a reference on a VM in the 'is_dying' state
also prevents unsharing of pages shared with a non-protected VM if that
VM is torn down by its VM fd being destroyed, rather than the usual path
via the MMU notifiers.
Rather than send a v6 of the whole series, here are three patches that
apply on top of v5 and fix the issue by (a) preventing teardown of a
referenced VM and (b) allowing some references to be taken on a dying
VM. As an added bonus, this simplifies the locking on the reclaim path
because now a VM reference is enough to stop the page-tables from going
away.
Cheers,
Will
[1] https://lore.kernel.org/kvmarm/20260330144841.26181-1-will@kernel.org
Cc: Marc Zyngier <maz@kernel.org>
Cc: Oliver Upton <oupton@kernel.org>
Cc: Joey Gouly <joey.gouly@arm.com>
Cc: Suzuki K Poulose <suzuki.poulose@arm.com>
Cc: Zenghui Yu <yuzenghui@huawei.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Quentin Perret <qperret@google.com>
Cc: Fuad Tabba <tabba@google.com>
Cc: Vincent Donnefort <vdonnefort@google.com>
Cc: Mostafa Saleh <smostafa@google.com>
Cc: Alexandru Elisei <alexandru.elisei@arm.com>
--->8
Will Deacon (3):
KVM: arm64: Prevent teardown finalisation of referenced 'hyp_vm'
KVM: arm64: Allow get_pkvm_hyp_vm() to take a reference to a dying VM
KVM: arm64: Don't hold 'vm_table_lock' across guest page reclaim
arch/arm64/kvm/hyp/nvhe/pkvm.c | 53 +++++++++++++++++-----------------
1 file changed, 26 insertions(+), 27 deletions(-)
--
2.53.0.1118.gaef5881109-goog
^ permalink raw reply
* Re: [PATCH] dmaengine: st_fdma: simplify allocation
From: Gustavo A. R. Silva @ 2026-03-31 15:33 UTC (permalink / raw)
To: Rosen Penev, dmaengine
Cc: Patrice Chotard, Vinod Koul, Frank Li, Kees Cook,
Gustavo A. R. Silva, moderated list:ARM/STI ARCHITECTURE,
open list,
open list:KERNEL HARDENING (not covered by other areas):Keyword:b__counted_by(_le|_be)?b
In-Reply-To: <20260330211555.13974-1-rosenp@gmail.com>
On 3/30/26 15:15, Rosen Penev wrote:
> Use a flexible array member to combine kzalloc and kcalloc to a single
> allocation.
>
> Add __counted_by for extra runtime analysis.
Assign counting variable
> after allocation as required by __counted_by.
This is misinformation and should be phrased differently[1]
-Gustavo
[1] https://lore.kernel.org/linux-hardening/37378f49-437f-438b-ad6c-d60480feb306@embeddedor.com/
>
> Signed-off-by: Rosen Penev <rosenp@gmail.com>
> ---
> drivers/dma/st_fdma.c | 27 ++++++++-------------------
> drivers/dma/st_fdma.h | 4 ++--
> 2 files changed, 10 insertions(+), 21 deletions(-)
>
> diff --git a/drivers/dma/st_fdma.c b/drivers/dma/st_fdma.c
> index d9547017f3bd..3ec0d6731b8d 100644
> --- a/drivers/dma/st_fdma.c
> +++ b/drivers/dma/st_fdma.c
> @@ -710,16 +710,6 @@ static const struct of_device_id st_fdma_match[] = {
> };
> MODULE_DEVICE_TABLE(of, st_fdma_match);
>
> -static int st_fdma_parse_dt(struct platform_device *pdev,
> - const struct st_fdma_driverdata *drvdata,
> - struct st_fdma_dev *fdev)
> -{
> - snprintf(fdev->fw_name, FW_NAME_SIZE, "fdma_%s_%d.elf",
> - drvdata->name, drvdata->id);
> -
> - return of_property_read_u32(pdev->dev.of_node, "dma-channels",
> - &fdev->nr_channels);
> -}
> #define FDMA_DMA_BUSWIDTHS (BIT(DMA_SLAVE_BUSWIDTH_1_BYTE) | \
> BIT(DMA_SLAVE_BUSWIDTH_2_BYTES) | \
> BIT(DMA_SLAVE_BUSWIDTH_3_BYTES) | \
> @@ -742,27 +732,26 @@ static int st_fdma_probe(struct platform_device *pdev)
> struct st_fdma_dev *fdev;
> struct device_node *np = pdev->dev.of_node;
> const struct st_fdma_driverdata *drvdata;
> + u32 nr_channels;
> int ret, i;
>
> drvdata = device_get_match_data(&pdev->dev);
>
> - fdev = devm_kzalloc(&pdev->dev, sizeof(*fdev), GFP_KERNEL);
> - if (!fdev)
> - return -ENOMEM;
> -
> - ret = st_fdma_parse_dt(pdev, drvdata, fdev);
> + ret = of_property_read_u32(pdev->dev.of_node, "dma-channels", &nr_channels);
> if (ret) {
> dev_err(&pdev->dev, "unable to find platform data\n");
> - goto err;
> + return ret;
> }
>
> - fdev->chans = devm_kcalloc(&pdev->dev, fdev->nr_channels,
> - sizeof(struct st_fdma_chan), GFP_KERNEL);
> - if (!fdev->chans)
> + fdev = devm_kzalloc(&pdev->dev, struct_size(fdev, chans, nr_channels), GFP_KERNEL);
> + if (!fdev)
> return -ENOMEM;
>
> + fdev->nr_channels = nr_channels;
> fdev->dev = &pdev->dev;
> fdev->drvdata = drvdata;
> + snprintf(fdev->fw_name, FW_NAME_SIZE, "fdma_%s_%d.elf", drvdata->name, drvdata->id);
> +
> platform_set_drvdata(pdev, fdev);
>
> fdev->irq = platform_get_irq(pdev, 0);
> diff --git a/drivers/dma/st_fdma.h b/drivers/dma/st_fdma.h
> index f1e746f7bc7d..27ded555879f 100644
> --- a/drivers/dma/st_fdma.h
> +++ b/drivers/dma/st_fdma.h
> @@ -136,13 +136,13 @@ struct st_fdma_dev {
>
> int irq;
>
> - struct st_fdma_chan *chans;
> -
> spinlock_t dreq_lock;
> unsigned long dreq_mask;
>
> u32 nr_channels;
> char fw_name[FW_NAME_SIZE];
> +
> + struct st_fdma_chan chans[] __counted_by(nr_channels);
> };
>
> /* Peripheral Registers*/
^ permalink raw reply
* Re: [PATCH v9 3/3] drm/v3d: Introduce Runtime Power Management
From: Florian Fainelli @ 2026-03-31 15:33 UTC (permalink / raw)
To: Maíra Canal, Stefan Wahren, Maxime Ripard, Melissa Wen,
Iago Toral Quiroga, Dave Stevenson
Cc: dri-devel, linux-rpi-kernel, linux-arm-kernel,
Broadcom internal kernel review list, kernel-dev
In-Reply-To: <20260331-v3d-power-management-v9-3-f52ff87bfd36@igalia.com>
On 3/31/26 05:35, Maíra Canal wrote:
> Commit 90a64adb0876 ("drm/v3d: Get rid of pm code") removed the last
> bits of power management code that V3D had, which were actually never
> hooked. Therefore, currently, the GPU clock is enabled during probe
> and only disabled when removing the driver.
>
> Implement proper power management using the kernel's Runtime PM
> framework.
>
> Reviewed-by: Melissa Wen <mwen@igalia.com>
> Signed-off-by: Maíra Canal <mcanal@igalia.com>
Reviewed-by: Florian Fainelli <florian.fainelli@broadcom.com>
--
Florian
^ permalink raw reply
* Re: [PATCHv2] clk: kirkwood: use kzalloc_flex
From: Gustavo A. R. Silva @ 2026-03-31 15:27 UTC (permalink / raw)
To: Brian Masney, Rosen Penev
Cc: linux-clk, Andrew Lunn, Gregory Clement, Sebastian Hesselbarth,
Michael Turquette, Stephen Boyd, Kees Cook, Gustavo A. R. Silva,
moderated list:ARM/Marvell Kirkwood and Armada 370, 375, 38x,...,
open list,
open list:KERNEL HARDENING (not covered by other areas):Keyword:b__counted_by(_le|_be)?b
In-Reply-To: <acvUoSOOF_9UQC75@redhat.com>
On 3/31/26 08:05, Brian Masney wrote:
> On Mon, Mar 30, 2026 at 01:55:04PM -0700, Rosen Penev wrote:
>> Simplify allocation by using a flexible array member and kzalloc_flex to
>> combine allocations.
>>
>> Add __counted_by for extra runtime analysis. Move counting variable
>> assignment to right after allocation as required by __counted_by.
This is misinformation and should be phrased differently[1]
-Gustavo
[1] https://lore.kernel.org/linux-hardening/37378f49-437f-438b-ad6c-d60480feb306@embeddedor.com/
>>
>> Signed-off-by: Rosen Penev <rosenp@gmail.com>
>> ---
>> v2: remove unused goto.
>
> Reviewed-by: Brian Masney <bmasney@redhat.com>
>
> For the future, if someone asks for changes in a previous version, then
> be sure to CC them on the next revision.
>
^ permalink raw reply
* Re: [PATCH v2 0/5] xor/arm: Replace vectorized version with intrinsics
From: Christoph Hellwig @ 2026-03-31 15:28 UTC (permalink / raw)
To: Ard Biesheuvel
Cc: Christoph Hellwig, Ard Biesheuvel, linux-raid, linux-arm-kernel,
linux-crypto, Russell King, Arnd Bergmann, Eric Biggers
In-Reply-To: <2176aab5-2167-4cdf-9090-0f8e0a6fb5a0@app.fastmail.com>
On Tue, Mar 31, 2026 at 05:26:33PM +0200, Ard Biesheuvel wrote:
> The RAID pieces are going through akpm's tree, right?
Yes.
^ permalink raw reply
* Re: [PATCH v2 0/5] xor/arm: Replace vectorized version with intrinsics
From: Ard Biesheuvel @ 2026-03-31 15:26 UTC (permalink / raw)
To: Christoph Hellwig, Ard Biesheuvel
Cc: linux-raid, linux-arm-kernel, linux-crypto, Russell King,
Arnd Bergmann, Eric Biggers
In-Reply-To: <20260331151653.GA8011@lst.de>
On Tue, 31 Mar 2026, at 17:16, Christoph Hellwig wrote:
> Looks good:
>
> Reviewed-by: Christoph Hellwig <hch@lst.de>
>
Thanks.
> I think some of the intrinsics patches were also in your crc64 series,
> so I'm not sure how to be merge this.
The first patch is used by both series, yes. If this is good to go, we might as well just merge it, and defer the crc work (or at least the 32-bit ARM specific changes) to the next cycle. I am in no particular hurry with any of this, so whatever works for other people is fine with me.
The RAID pieces are going through akpm's tree, right?
Eric, any preferences? (assuming you are on board with the CRC64 changes in the first place)
^ permalink raw reply
* Re: [PATCH 1/2] reset: amlogic: t7: Fix null reset ops
From: Philipp Zabel @ 2026-03-31 15:25 UTC (permalink / raw)
To: Ronald Claveau, Neil Armstrong, Kevin Hilman, Jerome Brunet,
Martin Blumenstingl, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: linux-arm-kernel, linux-amlogic, linux-kernel, devicetree
In-Reply-To: <20260331-fix-aml-t7-null-reset-v1-1-eb95b625234c@aliel.fr>
On Di, 2026-03-31 at 16:24 +0200, Ronald Claveau wrote:
> Fix missing reset ops causing kernel null pointer dereference.
> This SOC's reset is currently not used yet.
>
> Signed-off-by: Ronald Claveau <linux-kernel-dev@aliel.fr>
Applied to reset/fixes, thanks!
[1/2] reset: amlogic: t7: Fix null reset ops
https://git.pengutronix.de/cgit/pza/linux/commit/?id=9797524ef2b6
regards
Philipp
^ permalink raw reply
* Re: [PATCH v1] media: rkisp1: Add support for CAC
From: Barnabás Pőcze @ 2026-03-31 15:24 UTC (permalink / raw)
To: Laurent Pinchart, Jacopo Mondi
Cc: Dafna Hirschfeld, Mauro Carvalho Chehab, Heiko Stuebner,
linux-media, linux-rockchip, linux-arm-kernel, linux-kernel
In-Reply-To: <20260331133934.GC3357297@killaraus.ideasonboard.com>
2026. 03. 31. 15:39 keltezéssel, Laurent Pinchart írta:
> On Tue, Mar 31, 2026 at 02:42:33PM +0200, Jacopo Mondi wrote:
>> On Mon, Mar 30, 2026 at 04:40:18PM +0200, Barnabás Pőcze wrote:
>>> 2026. 03. 25. 16:21 keltezéssel, Jacopo Mondi írta:
>>>> On Mon, Mar 23, 2026 at 03:02:16PM +0100, Barnabás Pőcze wrote:
>>>>> The CAC block implements chromatic aberration correction. Expose it to
>>>>> userspace using the extensible parameters format. This was tested on the
>>>>> i.MX8MP platform, but based on available documentation it is also present
>>>>> in the RK3399 variant (V10). Thus presumably also in later versions,
>>>>> so no feature flag is introduced.
>>>>>
>>>>> Signed-off-by: Barnabás Pőcze <barnabas.pocze@ideasonboard.com>
>>>>
>>>> Only minors..
>>>>
>>>>> ---
>>>>> .../platform/rockchip/rkisp1/rkisp1-params.c | 69 ++++++++++++
>>>>> .../platform/rockchip/rkisp1/rkisp1-regs.h | 21 +++-
>>>>> include/uapi/linux/rkisp1-config.h | 106 +++++++++++++++++-
>>>>> 3 files changed, 193 insertions(+), 3 deletions(-)
>>>>>
>>>>> diff --git a/drivers/media/platform/rockchip/rkisp1/rkisp1-params.c b/drivers/media/platform/rockchip/rkisp1/rkisp1-params.c
>>>>> index 6442436a5e428..b889af9dcee45 100644
>>>>> --- a/drivers/media/platform/rockchip/rkisp1/rkisp1-params.c
>>>>> +++ b/drivers/media/platform/rockchip/rkisp1/rkisp1-params.c
>>>>> @@ -64,6 +64,7 @@ union rkisp1_ext_params_config {
>>>>> struct rkisp1_ext_params_compand_bls_config compand_bls;
>>>>> struct rkisp1_ext_params_compand_curve_config compand_curve;
>>>>> struct rkisp1_ext_params_wdr_config wdr;
>>>>> + struct rkisp1_ext_params_cac_config cac;
>>>>> };
>>>>>
>>>>> enum rkisp1_params_formats {
>>>>> @@ -1413,6 +1414,48 @@ static void rkisp1_wdr_config(struct rkisp1_params *params,
>>>>> RKISP1_CIF_ISP_WDR_TONE_CURVE_YM_MASK);
>>>>> }
>>>>>
>>>>> +static void
>>>>> +rkisp1_cac_config(struct rkisp1_params *params,
>>>>> + const struct rkisp1_cif_isp_cac_config *arg)
>>>>
>>>> Fits in one line without going over 80 cols
>>>
>>> This is what the other functions looks like, so went this this.
>>
>> It seems to me not all of them are broken, but only the ones that go
>> over 80 cols
I think I misunderstood initially. Adjusted now.
>>
>> in example:
>>
>> static void rkisp1_dpf_config(struct rkisp1_params *params,
>> const struct rkisp1_cif_isp_dpf_config *arg)
>>
>> A detail anyway, up to you
>>
>>>>> +{
>>>>> + u32 regval;
>
> All other functions in this file name similar variables "val", "value"
> or "reg_val". Let's not introduce a fourth one. I have a small
> preference for "val", but that's not mandatory.
Adjusted.
>
>>>>> +
>>>>> + /*
>>>>> + * The enable bit is in the same register (RKISP1_CIF_ISP_CAC_CTRL),
>>>>> + * so only set the clipping mode, and do not modify the other bits.
>>>>> + */
>>>>> + regval = rkisp1_read(params->rkisp1, RKISP1_CIF_ISP_CAC_CTRL);
>>>>> + regval &= ~(RKISP1_CIF_ISP_CAC_CTRL_H_CLIP_MODE |
>>>>> + RKISP1_CIF_ISP_CAC_CTRL_V_CLIP_MODE);
>>>>> + regval |= FIELD_PREP(RKISP1_CIF_ISP_CAC_CTRL_H_CLIP_MODE, arg->h_clip_mode) |
>>>>> + FIELD_PREP(RKISP1_CIF_ISP_CAC_CTRL_V_CLIP_MODE, arg->v_clip_mode);
>>>>> + rkisp1_write(params->rkisp1, RKISP1_CIF_ISP_CAC_CTRL, regval);
>>>>> +
>>>>> + regval = FIELD_PREP(RKISP1_CIF_ISP_CAC_COUNT_START_H_MASK, arg->h_count_start) |
>>>>> + FIELD_PREP(RKISP1_CIF_ISP_CAC_COUNT_START_V_MASK, arg->v_count_start);
>>>>> + rkisp1_write(params->rkisp1, RKISP1_CIF_ISP_CAC_COUNT_START, regval);
>>>>> +
>>>>> + regval = FIELD_PREP(RKISP1_CIF_ISP_CAC_A_RED_MASK, arg->red[0]) |
>>>>> + FIELD_PREP(RKISP1_CIF_ISP_CAC_A_BLUE_MASK, arg->blue[0]);
>>>>> + rkisp1_write(params->rkisp1, RKISP1_CIF_ISP_CAC_A, regval);
>>>>> +
>>>>> + regval = FIELD_PREP(RKISP1_CIF_ISP_CAC_B_RED_MASK, arg->red[1]) |
>>>>> + FIELD_PREP(RKISP1_CIF_ISP_CAC_B_BLUE_MASK, arg->blue[1]);
>>>>> + rkisp1_write(params->rkisp1, RKISP1_CIF_ISP_CAC_B, regval);
>>>>> +
>>>>> + regval = FIELD_PREP(RKISP1_CIF_ISP_CAC_C_RED_MASK, arg->red[2]) |
>>>>> + FIELD_PREP(RKISP1_CIF_ISP_CAC_C_BLUE_MASK, arg->blue[2]);
>>>>> + rkisp1_write(params->rkisp1, RKISP1_CIF_ISP_CAC_C, regval);
>>>>> +
>>>>> + regval = FIELD_PREP(RKISP1_CIF_ISP_CAC_X_NORM_NF_MASK, arg->x_nf) |
>>>>> + FIELD_PREP(RKISP1_CIF_ISP_CAC_X_NORM_NS_MASK, arg->x_ns);
>>>>> + rkisp1_write(params->rkisp1, RKISP1_CIF_ISP_CAC_X_NORM, regval);
>>>>> +
>>>>> + regval = FIELD_PREP(RKISP1_CIF_ISP_CAC_Y_NORM_NF_MASK, arg->y_nf) |
>>>>> + FIELD_PREP(RKISP1_CIF_ISP_CAC_Y_NORM_NS_MASK, arg->y_ns);
>>>>> + rkisp1_write(params->rkisp1, RKISP1_CIF_ISP_CAC_Y_NORM, regval);
>>>>> +}
>>>>> +
>>>>> static void
>>>>> rkisp1_isp_isr_other_config(struct rkisp1_params *params,
>>>>> const struct rkisp1_params_cfg *new_params)
>>>>> @@ -2089,6 +2132,25 @@ static void rkisp1_ext_params_wdr(struct rkisp1_params *params,
>>>>> RKISP1_CIF_ISP_WDR_CTRL_ENABLE);
>>>>> }
>>>>>
>>>>> +static void rkisp1_ext_params_cac(struct rkisp1_params *params,
>>>>> + const union rkisp1_ext_params_config *block)
>>>>> +{
>>>>> + const struct rkisp1_ext_params_cac_config *cac = &block->cac;
>>>>> +
>>>>> + if (cac->header.flags & RKISP1_EXT_PARAMS_FL_BLOCK_DISABLE) {
>>>>> + rkisp1_param_clear_bits(params, RKISP1_CIF_ISP_CAC_CTRL,
>>>>> + RKISP1_CIF_ISP_CAC_CTRL_ENABLE);
>>>>> + return;
>>>>> + }
>>>>> +
>>>>> + rkisp1_cac_config(params, &cac->config);
>>>>> +
>>>>> + if ((cac->header.flags & RKISP1_EXT_PARAMS_FL_BLOCK_ENABLE) &&
>>>>> + !(params->enabled_blocks & BIT(cac->header.type)))
>>>>> + rkisp1_param_set_bits(params, RKISP1_CIF_ISP_CAC_CTRL,
>>>>> + RKISP1_CIF_ISP_CAC_CTRL_ENABLE);
>>>>> +}
>>>>> +
>>>>> typedef void (*rkisp1_block_handler)(struct rkisp1_params *params,
>>>>> const union rkisp1_ext_params_config *config);
>>>>>
>>>>> @@ -2185,6 +2247,10 @@ static const struct rkisp1_ext_params_handler {
>>>>> .handler = rkisp1_ext_params_wdr,
>>>>> .group = RKISP1_EXT_PARAMS_BLOCK_GROUP_OTHERS,
>>>>> },
>>>>> + [RKISP1_EXT_PARAMS_BLOCK_TYPE_CAC] = {
>>>>> + .handler = rkisp1_ext_params_cac,
>>>>> + .group = RKISP1_EXT_PARAMS_BLOCK_GROUP_OTHERS,
>>>>> + },
>>>>> };
>>>>>
>>>>> #define RKISP1_PARAMS_BLOCK_INFO(block, data) \
>>>>> @@ -2215,6 +2281,7 @@ rkisp1_ext_params_block_types_info[] = {
>>>>> RKISP1_PARAMS_BLOCK_INFO(COMPAND_EXPAND, compand_curve),
>>>>> RKISP1_PARAMS_BLOCK_INFO(COMPAND_COMPRESS, compand_curve),
>>>>> RKISP1_PARAMS_BLOCK_INFO(WDR, wdr),
>>>>> + RKISP1_PARAMS_BLOCK_INFO(CAC, cac),
>>>>> };
>>>>>
>>>>> static_assert(ARRAY_SIZE(rkisp1_ext_params_handlers) ==
>>>>> @@ -2474,6 +2541,8 @@ void rkisp1_params_disable(struct rkisp1_params *params)
>>>>> rkisp1_ie_enable(params, false);
>>>>> rkisp1_param_clear_bits(params, RKISP1_CIF_ISP_DPF_MODE,
>>>>> RKISP1_CIF_ISP_DPF_MODE_EN);
>>>>> + rkisp1_param_clear_bits(params, RKISP1_CIF_ISP_CAC_CTRL,
>>>>> + RKISP1_CIF_ISP_CAC_CTRL_ENABLE);
>>>>> }
>>>>>
>>>>> static const struct rkisp1_params_ops rkisp1_v10_params_ops = {
>>>>> diff --git a/drivers/media/platform/rockchip/rkisp1/rkisp1-regs.h b/drivers/media/platform/rockchip/rkisp1/rkisp1-regs.h
>>>>> index fbeb186cde0d5..8e25537459bbd 100644
>>>>> --- a/drivers/media/platform/rockchip/rkisp1/rkisp1-regs.h
>>>>> +++ b/drivers/media/platform/rockchip/rkisp1/rkisp1-regs.h
>>>>> @@ -724,6 +724,23 @@
>>>>> #define RKISP1_CIF_ISP_WDR_DMIN_STRENGTH_MASK GENMASK(20, 16)
>>>>> #define RKISP1_CIF_ISP_WDR_DMIN_STRENGTH_MAX 16U
>>>>>
>>>>> +/* CAC */
>>>>> +#define RKISP1_CIF_ISP_CAC_CTRL_ENABLE BIT(0)
>>>>> +#define RKISP1_CIF_ISP_CAC_CTRL_V_CLIP_MODE GENMASK(2, 1)
>>>>> +#define RKISP1_CIF_ISP_CAC_CTRL_H_CLIP_MODE GENMASK(3, 3)
>
> I'd go for BIT(3) as you use BIT(0) for the enable bit.
Adjusted.
>
>>>>> +#define RKISP1_CIF_ISP_CAC_COUNT_START_H_MASK GENMASK(12, 0)
>>>>> +#define RKISP1_CIF_ISP_CAC_COUNT_START_V_MASK GENMASK(28, 16)
>>>>> +#define RKISP1_CIF_ISP_CAC_A_RED_MASK GENMASK(8, 0)
>>>>> +#define RKISP1_CIF_ISP_CAC_A_BLUE_MASK GENMASK(24, 16)
>>>>> +#define RKISP1_CIF_ISP_CAC_B_RED_MASK GENMASK(8, 0)
>>>>> +#define RKISP1_CIF_ISP_CAC_B_BLUE_MASK GENMASK(24, 16)
>>>>> +#define RKISP1_CIF_ISP_CAC_C_RED_MASK GENMASK(8, 0)
>>>>> +#define RKISP1_CIF_ISP_CAC_C_BLUE_MASK GENMASK(24, 16)
>>>>
>>>> All these masks for coefficients 0, 1 and 2 are identical. Maybe
>>>> #define RKISP1_CIF_ISP_CAC_RED_MASK GENMASK(8, 0)
>>>> #define RKISP1_CIF_ISP_CAC_BLUE_MASK GENMASK(24, 16)
>>>>
>>>> is enough
>>>
>>> Adjusted.
>>>
>>>>> +#define RKISP1_CIF_ISP_CAC_X_NORM_NF_MASK GENMASK(4, 0)
>>>>> +#define RKISP1_CIF_ISP_CAC_X_NORM_NS_MASK GENMASK(19, 16)
>>>>> +#define RKISP1_CIF_ISP_CAC_Y_NORM_NF_MASK GENMASK(4, 0)
>>>>> +#define RKISP1_CIF_ISP_CAC_Y_NORM_NS_MASK GENMASK(19, 16)
>>>
>>> Did the same with these as well.
>>
>> Ah thanks!
>>
>>>>> +
>>>>> /* =================================================================== */
>>>>> /* CIF Registers */
>>>>> /* =================================================================== */
>>>>> @@ -1196,8 +1213,8 @@
>>>>> #define RKISP1_CIF_ISP_CAC_A (RKISP1_CIF_ISP_CAC_BASE + 0x00000008)
>>>>> #define RKISP1_CIF_ISP_CAC_B (RKISP1_CIF_ISP_CAC_BASE + 0x0000000c)
>>>>> #define RKISP1_CIF_ISP_CAC_C (RKISP1_CIF_ISP_CAC_BASE + 0x00000010)
>>>>> -#define RKISP1_CIF_ISP_X_NORM (RKISP1_CIF_ISP_CAC_BASE + 0x00000014)
>>>>> -#define RKISP1_CIF_ISP_Y_NORM (RKISP1_CIF_ISP_CAC_BASE + 0x00000018)
>>>>> +#define RKISP1_CIF_ISP_CAC_X_NORM (RKISP1_CIF_ISP_CAC_BASE + 0x00000014)
>>>>> +#define RKISP1_CIF_ISP_CAC_Y_NORM (RKISP1_CIF_ISP_CAC_BASE + 0x00000018)
>>>>>
>>>>> #define RKISP1_CIF_ISP_EXP_BASE 0x00002600
>>>>> #define RKISP1_CIF_ISP_EXP_CTRL (RKISP1_CIF_ISP_EXP_BASE + 0x00000000)
>>>>> diff --git a/include/uapi/linux/rkisp1-config.h b/include/uapi/linux/rkisp1-config.h
>>>>> index b2d2a71f7baff..d8acccaddd0e9 100644
>>>>> --- a/include/uapi/linux/rkisp1-config.h
>>>>> +++ b/include/uapi/linux/rkisp1-config.h
>>>>> @@ -967,6 +967,92 @@ struct rkisp1_cif_isp_wdr_config {
>>>>> __u8 use_iref;
>>>>> };
>>>>>
>>>>> +/*
>>>>> + * enum rkisp1_cif_isp_cac_h_clip_mode - horizontal clipping mode
>>>>> + *
>>>>> + * @RKISP1_CIF_ISP_CAC_H_CLIP_MODE_4PX: +/- 4 pixels
>>>>> + * @RKISP1_CIF_ISP_CAC_H_CLIP_MODE_4_5PX: +/- 4/5 pixels depending on bayer position
>>>>> + */
>>>>> +enum rkisp1_cif_isp_cac_h_clip_mode {
>>>>> + RKISP1_CIF_ISP_CAC_H_CLIP_MODE_4PX = 0,
>>>>> + RKISP1_CIF_ISP_CAC_H_CLIP_MODE_4_5PX = 1,
>>>>> +};
>>>>> +
>>>>> +/**
>>>>> + * enum rkisp1_cif_isp_cac_v_clip_mode - vertical clipping mode
>>>>> + *
>>>>> + * @RKISP1_CIF_ISP_CAC_V_CLIP_MODE_2PX: +/- 2 pixels
>>>>> + * @RKISP1_CIF_ISP_CAC_V_CLIP_MODE_3PX: +/- 3 pixels
>>>>> + * @RKISP1_CIF_ISP_CAC_V_CLIP_MODE_3_4PX: +/- 3/4 pixels depending on bayer position
>>>>> + */
>>>>> +enum rkisp1_cif_isp_cac_v_clip_mode {
>>>>> + RKISP1_CIF_ISP_CAC_V_CLIP_MODE_2PX = 0,
>>>>> + RKISP1_CIF_ISP_CAC_V_CLIP_MODE_3PX = 1,
>>>>> + RKISP1_CIF_ISP_CAC_V_CLIP_MODE_3_4PX = 2,
>>>>> +};
>>>>> +
>>>>> +/**
>>>>> + * struct rkisp1_cif_isp_cac_config - chromatic aberration correction configuration
>>>>> + *
>>>>> + * The correction is carried out by shifting the red and blue pixels relative
>>>>> + * to the green ones, depending on the distance from the optical center:
>>>>
>>>> Yes, the distance to the center is one parameter, but the shifting
>>>> amount depends on other things. I would drop the last part of the
>>>> sentence and move the description of the two below fields after the
>>>> text
>>>
>>> That's true, but within a specific image, the only varying quantity
>>> is the distance, so I think it is important to emphasize that.
>>>
>>> And I also quite like this structure of
>>> - description of step
>>> - parameters of step
>>> - description of step
>>> ...
>>>
>>> so I would love to keep it like this, if that's ok?
>>
>> Ok!
>
> Ack.
>
>>>>> + *
>>>>> + * @h_count_start: horizontal coordinate of the optical center (13-bit unsigned integer; [1,8191])
>>>>> + * @v_count_start: vertical coordinate of the optical center (13-bit unsigned integer; [1,8191])
>>>>
>>>> so these could go just before @x_nf
>>>>
>>>>> + *
>>>>> + * For each pixel, the x/y distances from the optical center are calculated and
>>>>
>>>> I forgot: did we establish that the correction is applied to the
>>>> euclidean distance or to x and y separately ?
>>>
>>> Given that there are two sets of "normalization" parameters, the assumption is that
>>> at least the x/y distances are transformed separately. I see two reasonable choices
>>> after that: (a) use the two distances separately, (b) use the radial distance. The
>>> documentation says (b). However, testing with sensor test patterns suggests that
>>> it is not the case (a horizontal/vertical boundary between appropriately colored
>>> regions should have a curvature after the transformation with appropriate parameters).
>>
>> I now recall that you have been able to shift just one plan when using
>> the sensor's test pattern
>
> I agree about the normalization, but it sounds really weird that the
> hardware would then shift separately in the X and Y directions. Below
> you document the radial correction formula, which looks correct to me.
I think so, too. But if it uses the radial distance, I would expect the shifting to happen
along the radius. But that does not appear to be the case (e.g. y_nf=0 removes all vertical
correction). This could be explained by saying that the shifting actually happens along the
direction determined by the sum of the normalized distance vectors, but that seemed a bit
far fetched to me. And even with that, I would expect to be able to turn a straight line
into a curve. Maybe I'm doing something wrong, but I can't recall ever being able to.
>
>>>>> + * then transformed into the [0,255] range based on the following formula:
>>>>
>>>> s/transformed/normalized ?
>>>
>>> To be honest I vastly prefer "transform" / "map" over "normalize" here.
>>
>> You're right here, the below formula doesn't normalize the
>> distance in an interval but just re-scale it
>>
>>>>> + *
>>>>> + * (((d << 4) >> s) * f) >> 5
>>>>> + *
>>>>> + * where `d` is the distance, `s` and `f` are the normalization parameters:
>>>>
>>>> Can you use 'ns' and 'nf' to match the below ?
>>>
>>> Adjusted.
>>
>> Thanks!
>>
>>>>> + *
>>>>> + * @x_nf: horizontal normalization scale parameter (5-bit unsigned integer; [0,31])
>>>>> + * @x_ns: horizontal normalization shift parameter (4-bit unsigned integer; [0,15])
>>>>> + *
>>>>> + * @y_nf: vertical normalization scale parameter (5-bit unsigned integer; [0,31])
>>>>> + * @y_ns: vertical normalization shift parameter (4-bit unsigned integer; [0,15])
>>>>> + *
>>>>> + * These parameters should be chosen based on the image resolution, the position
>>>>> + * of the optical center, and the shape of pixels: so that no normalized distance
>>>>
>>>> s/pixels:/pixels/
>>>
>>> Replaced `:` with `,`.
>>>
>>>>> + * is larger than 255. If the pixels have square shape, the two sets of parameters
>>>>> + * should be equal.
>
> I wonder if we could have anisotropic lenses (from the point of view of
> chromatic aberrations) with square pixels. We can deal with it later.
Right, this is what the documentation suggests, and I believe it is probably "correct enough"
most of the time. But should I remove it?
>
>>>>> + *
>>>>> + * The actual amount of correction is calculated with a third degree polynomial:
>>>>> + *
>>>>> + * c[0] * r + c[1] * r^2 + c[2] * r^3
>>>>> + *
>>>>> + * where `c` is the set of coefficients for the given color, and `r` is distance:
>>>>> + *
>>>>> + * @red: red coefficients (5.4 two's complement; [-16,15.9375])
>>>>> + * @blue: blue coefficients (5.4 two's complement; [-16,15.9375])
>>>>> + *
>>>>> + * Finally, the amount is clipped as requested:
>>>>> + *
>>>>> + * @h_clip_mode: maximum horizontal shift (from enum rkisp1_cif_isp_cac_h_clip_mode)
>>>>> + * @v_clip_mode: maximum vertical shift (from enum rkisp1_cif_isp_cac_v_clip_mode)
>>>>> + *
>>>>> + * A positive result will shift away from the optical center, while a negative
>>>>> + * one will shift towards the optical center. In the latter case, the pixel
>>>>> + * values at the edges are duplicated.
>>>>> + */
>>>>> +struct rkisp1_cif_isp_cac_config {
>>>>> + __u8 h_clip_mode;
>>>>> + __u8 v_clip_mode;
>>>>> +
>>>>> + __u16 h_count_start;
>>>>> + __u16 v_count_start;
>>>>> +
>>>>> + __u16 red[3];
>>>>> + __u16 blue[3];
>>>>> +
>>>>> + __u8 x_nf;
>>>>> + __u8 x_ns;
>>>>> +
>>>>> + __u8 y_nf;
>>>>> + __u8 y_ns;
>>>>> +};
>>>>> +
>>>>> /*---------- PART2: Measurement Statistics ------------*/
>>>>>
>>>>> /**
>>>>> @@ -1161,6 +1247,7 @@ enum rkisp1_ext_params_block_type {
>>>>> RKISP1_EXT_PARAMS_BLOCK_TYPE_COMPAND_EXPAND,
>>>>> RKISP1_EXT_PARAMS_BLOCK_TYPE_COMPAND_COMPRESS,
>>>>> RKISP1_EXT_PARAMS_BLOCK_TYPE_WDR,
>>>>> + RKISP1_EXT_PARAMS_BLOCK_TYPE_CAC,
>>>>> };
>>>>>
>>>>> /* For backward compatibility */
>>>>> @@ -1507,6 +1594,22 @@ struct rkisp1_ext_params_wdr_config {
>>>>> struct rkisp1_cif_isp_wdr_config config;
>>>>> } __attribute__((aligned(8)));
>>>>>
>>>>> +/**
>>>>> + * struct rkisp1_ext_params_cac_config - RkISP1 extensible params CAC config
>>>>> + *
>>>>> + * RkISP1 extensible parameters CAC block.
>>>>> + * Identified by :c:type:`RKISP1_EXT_PARAMS_BLOCK_TYPE_CAC`.
>>>>> + *
>>>>> + * @header: The RkISP1 extensible parameters header, see
>>>>> + * :c:type:`rkisp1_ext_params_block_header`
>>>>> + * @config: CAC configuration, see
>>>>> + * :c:type:`rkisp1_cif_isp_cac_config`
>>>>> + */
>>>>> +struct rkisp1_ext_params_cac_config {
>>>>> + struct rkisp1_ext_params_block_header header;
>>>>> + struct rkisp1_cif_isp_cac_config config;
>>>>> +} __attribute__((aligned(8)));
>>>>> +
>>>>> /*
>>>>> * The rkisp1_ext_params_compand_curve_config structure is counted twice as it
>>>>> * is used for both the COMPAND_EXPAND and COMPAND_COMPRESS block types.
>>>>> @@ -1532,7 +1635,8 @@ struct rkisp1_ext_params_wdr_config {
>>>>> sizeof(struct rkisp1_ext_params_compand_bls_config) +\
>>>>> sizeof(struct rkisp1_ext_params_compand_curve_config) +\
>>>>> sizeof(struct rkisp1_ext_params_compand_curve_config) +\
>>>>> - sizeof(struct rkisp1_ext_params_wdr_config))
>>>>> + sizeof(struct rkisp1_ext_params_wdr_config) +\
>>>>> + sizeof(struct rkisp1_ext_params_cac_config))
>>>>
>>>> All minors, please add
>>>> Reviewed-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com>
>
> and
>
> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
>
>>>>>
>>>>> /**
>>>>> * enum rksip1_ext_param_buffer_version - RkISP1 extensible parameters version
>
^ permalink raw reply
* Re: [PATCH 2/3] drm: lcdif: Use dedicated set/clr registers for polarity/edge
From: Paul Kocialkowski @ 2026-03-31 15:17 UTC (permalink / raw)
To: Lucas Stach
Cc: dri-devel, imx, linux-arm-kernel, linux-kernel, Marek Vasut,
Stefan Agner, Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
David Airlie, Simona Vetter, Frank Li, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam, Krzysztof Hałasa,
Marco Felsch, Liu Ying
In-Reply-To: <f5b628f50def756da356184ff6febb11cc9aaa68.camel@pengutronix.de>
[-- Attachment #1: Type: text/plain, Size: 3463 bytes --]
Hi Lucas,
Le Tue 31 Mar 26, 11:09, Lucas Stach a écrit :
> Hi Paul,
>
> Am Dienstag, dem 31.03.2026 um 00:46 +0200 schrieb Paul Kocialkowski:
> > The lcdif v3 hardware comes with dedicated registers to set and clear
> > polarity bits in the CTRL register. It is unclear if there is a
> > difference with writing to the CTRL register directly.
> >
> > Follow the NXP BSP reference by using these registers, in case there is
> > a subtle difference caused by using them.
> >
> I don't really like that patch, as it blows up what is currently a
> single register access to three separate ones. If there is no clear
> benefit (as in it has been shown to fix any issue), I would prefer this
> code to stay as-is.
Well I guess the cost of a few writes vs a single one is rather
negligible. I'm rather worried that there might be an undocumented
reason why these registers exist in the first place and why they are
used in the BSP.
But yes this is only speculation and I could not witness any actual
issue. My setup (lcdif3 with hdmi) uses all positive polarities which is
the default state, so not a good way to check.
It would be great if somebody from NXP could confirm whether this is
needed or not. In the meantime I guess we can drop the patch. It'll stay
on the list in case someone has polarity issues later :)
All the best,
Paul
> Regards,
> Lucas
>
> > Signed-off-by: Paul Kocialkowski <paulk@sys-base.io>
> > ---
> > drivers/gpu/drm/mxsfb/lcdif_kms.c | 23 ++++++++++++++++-------
> > 1 file changed, 16 insertions(+), 7 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/mxsfb/lcdif_kms.c b/drivers/gpu/drm/mxsfb/lcdif_kms.c
> > index a00c4f6d63f4..1aac354041c7 100644
> > --- a/drivers/gpu/drm/mxsfb/lcdif_kms.c
> > +++ b/drivers/gpu/drm/mxsfb/lcdif_kms.c
> > @@ -296,18 +296,27 @@ static void lcdif_set_formats(struct lcdif_drm_private *lcdif,
> > static void lcdif_set_mode(struct lcdif_drm_private *lcdif, u32 bus_flags)
> > {
> > struct drm_display_mode *m = &lcdif->crtc.state->adjusted_mode;
> > - u32 ctrl = 0;
> > + u32 ctrl;
> >
> > if (m->flags & DRM_MODE_FLAG_NHSYNC)
> > - ctrl |= CTRL_INV_HS;
> > + writel(CTRL_INV_HS, lcdif->base + LCDC_V8_CTRL + REG_SET);
> > + else
> > + writel(CTRL_INV_HS, lcdif->base + LCDC_V8_CTRL + REG_CLR);
> > +
> > if (m->flags & DRM_MODE_FLAG_NVSYNC)
> > - ctrl |= CTRL_INV_VS;
> > + writel(CTRL_INV_VS, lcdif->base + LCDC_V8_CTRL + REG_SET);
> > + else
> > + writel(CTRL_INV_VS, lcdif->base + LCDC_V8_CTRL + REG_CLR);
> > +
> > if (bus_flags & DRM_BUS_FLAG_DE_LOW)
> > - ctrl |= CTRL_INV_DE;
> > - if (bus_flags & DRM_BUS_FLAG_PIXDATA_DRIVE_NEGEDGE)
> > - ctrl |= CTRL_INV_PXCK;
> > + writel(CTRL_INV_DE, lcdif->base + LCDC_V8_CTRL + REG_SET);
> > + else
> > + writel(CTRL_INV_DE, lcdif->base + LCDC_V8_CTRL + REG_CLR);
> >
> > - writel(ctrl, lcdif->base + LCDC_V8_CTRL);
> > + if (bus_flags & DRM_BUS_FLAG_PIXDATA_DRIVE_NEGEDGE)
> > + writel(CTRL_INV_PXCK, lcdif->base + LCDC_V8_CTRL + REG_SET);
> > + else
> > + writel(CTRL_INV_PXCK, lcdif->base + LCDC_V8_CTRL + REG_CLR);
> >
> > writel(DISP_SIZE_DELTA_Y(m->vdisplay) |
> > DISP_SIZE_DELTA_X(m->hdisplay),
>
--
Paul Kocialkowski,
Independent contractor - sys-base - https://www.sys-base.io/
Free software developer - https://www.paulk.fr/
Expert in multimedia, graphics and embedded hardware support with Linux.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH v2 0/5] xor/arm: Replace vectorized version with intrinsics
From: Christoph Hellwig @ 2026-03-31 15:16 UTC (permalink / raw)
To: Ard Biesheuvel
Cc: linux-raid, linux-arm-kernel, linux-crypto, Ard Biesheuvel,
Christoph Hellwig, Russell King, Arnd Bergmann, Eric Biggers
In-Reply-To: <20260331074940.55502-7-ardb+git@google.com>
Looks good:
Reviewed-by: Christoph Hellwig <hch@lst.de>
I think some of the intrinsics patches were also in your crc64 series,
so I'm not sure how to be merge this.
^ permalink raw reply
* Re: [PATCH 1/4] KVM: arm64: nv: Avoid full shadow s2 unmap
From: kernel test robot @ 2026-03-31 15:16 UTC (permalink / raw)
To: Wei-Lin Chang, linux-arm-kernel, kvmarm, linux-kernel
Cc: llvm, oe-kbuild-all, Marc Zyngier, Oliver Upton, Joey Gouly,
Suzuki K Poulose, Zenghui Yu, Catalin Marinas, Will Deacon,
Wei-Lin Chang
In-Reply-To: <20260330100633.2817076-2-weilin.chang@arm.com>
Hi Wei-Lin,
kernel test robot noticed the following build errors:
[auto build test ERROR on next-20260327]
[cannot apply to kvmarm/next arm64/for-next/core arm/for-next arm/fixes soc/for-next v7.0-rc6 v7.0-rc5 v7.0-rc4 linus/master v7.0-rc6]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]
url: https://github.com/intel-lab-lkp/linux/commits/Wei-Lin-Chang/KVM-arm64-nv-Avoid-full-shadow-s2-unmap/20260330-230122
base: next-20260327
patch link: https://lore.kernel.org/r/20260330100633.2817076-2-weilin.chang%40arm.com
patch subject: [PATCH 1/4] KVM: arm64: nv: Avoid full shadow s2 unmap
config: arm64-randconfig-002-20260331 (https://download.01.org/0day-ci/archive/20260331/202603312322.Bli3MO76-lkp@intel.com/config)
compiler: clang version 18.1.8 (https://github.com/llvm/llvm-project 3b5b5c1ec4a3095ab096dd780e84d7ab81f3d7ff)
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20260331/202603312322.Bli3MO76-lkp@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202603312322.Bli3MO76-lkp@intel.com/
All errors (new ones prefixed by >>):
>> arch/arm64/kvm/nested.c:792:2: error: member reference type 'rwlock_t' (aka 'struct rwlock') is not a pointer; did you mean to use '.'?
792 | lockdep_assert_held_write(kvm_s2_mmu_to_kvm(mmu)->mmu_lock);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
include/linux/lockdep.h:291:22: note: expanded from macro 'lockdep_assert_held_write'
291 | do { lockdep_assert(lockdep_is_held_type(l, 0)); __assume_ctx_lock(l); } while (0)
| ~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~
include/linux/lockdep.h:253:64: note: expanded from macro 'lockdep_is_held_type'
253 | #define lockdep_is_held_type(lock, r) lock_is_held_type(&(lock)->dep_map, (r))
| ^
include/linux/lockdep.h:279:32: note: expanded from macro 'lockdep_assert'
279 | do { WARN_ON(debug_locks && !(cond)); } while (0)
| ~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~
include/asm-generic/bug.h:110:25: note: expanded from macro 'WARN_ON'
110 | int __ret_warn_on = !!(condition); \
| ^~~~~~~~~
>> arch/arm64/kvm/nested.c:792:2: error: cannot take the address of an rvalue of type 'struct lockdep_map'
792 | lockdep_assert_held_write(kvm_s2_mmu_to_kvm(mmu)->mmu_lock);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
include/linux/lockdep.h:291:22: note: expanded from macro 'lockdep_assert_held_write'
291 | do { lockdep_assert(lockdep_is_held_type(l, 0)); __assume_ctx_lock(l); } while (0)
| ~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~
include/linux/lockdep.h:253:57: note: expanded from macro 'lockdep_is_held_type'
253 | #define lockdep_is_held_type(lock, r) lock_is_held_type(&(lock)->dep_map, (r))
| ^
include/linux/lockdep.h:279:32: note: expanded from macro 'lockdep_assert'
279 | do { WARN_ON(debug_locks && !(cond)); } while (0)
| ~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~
include/asm-generic/bug.h:110:25: note: expanded from macro 'WARN_ON'
110 | int __ret_warn_on = !!(condition); \
| ^~~~~~~~~
2 errors generated.
vim +792 arch/arm64/kvm/nested.c
782
783 int kvm_record_nested_revmap(gpa_t ipa, struct kvm_s2_mmu *mmu,
784 gpa_t fault_ipa, size_t map_size)
785 {
786 struct maple_tree *mt = &mmu->nested_revmap_mt;
787 gpa_t start = ipa;
788 gpa_t end = ipa + map_size - 1;
789 u64 entry, new_entry = 0;
790 int r = 0;
791
> 792 lockdep_assert_held_write(kvm_s2_mmu_to_kvm(mmu)->mmu_lock);
793
794 MA_STATE(mas, mt, start, end);
795 entry = (u64)mas_find_range(&mas, end);
796
797 if (entry) {
798 /* maybe just a perm update... */
799 if (!(entry & UNKNOWN_IPA) && mas.index == start &&
800 mas.last == end &&
801 fault_ipa == (entry & NESTED_IPA_MASK))
802 goto out;
803 /*
804 * Remove every overlapping range, then create a "polluted"
805 * range that spans all these ranges and store it.
806 */
807 while (entry && mas.index <= end) {
808 start = min(mas.index, start);
809 end = max(mas.last, end);
810 mas_erase(&mas);
811 entry = (u64)mas_find_range(&mas, end);
812 }
813 new_entry |= UNKNOWN_IPA;
814 } else {
815 new_entry |= fault_ipa;
816 }
817
818 mas_set_range(&mas, start, end);
819 r = mas_store_gfp(&mas, (void *)new_entry, GFP_KERNEL_ACCOUNT);
820 out:
821 return r;
822 }
823
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* Re: [PATCH 09/15] KVM: arm64: vgic-v5: align priority comparison with other GICs
From: Sascha Bischoff @ 2026-03-31 15:09 UTC (permalink / raw)
To: maz@kernel.org, kvmarm@lists.linux.dev, kvm@vger.kernel.org,
linux-arm-kernel@lists.infradead.org
Cc: Joey Gouly, yuzenghui@huawei.com, Suzuki Poulose,
oupton@kernel.org, broonie@kernel.org, nd
In-Reply-To: <20260326153530.3981879-10-maz@kernel.org>
On Thu, 2026-03-26 at 15:35 +0000, Marc Zyngier wrote:
> The way the effective priority mask is computed, and then compared
> to the priority of an interrupt to decide whether to wake-up or not,
> is slightly odd, and breaks at the limits.
>
> This could result in spurious wake-ups that are undesirable.
>
> Adopt the GICv[23] logic instead, which checks that the priority
> value
> is strictly lower than the mask.
>
> Fixes: 933e5288fa971 ("KVM: arm64: gic-v5: Check for pending PPIs")
> Link:
> https://sashiko.dev/#/patchset/20260319154937.3619520-1-sascha.bischoff%40arm.com
> Signed-off-by: Marc Zyngier <maz@kernel.org>
> ---
> arch/arm64/kvm/vgic/vgic-v5.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm64/kvm/vgic/vgic-v5.c
> b/arch/arm64/kvm/vgic/vgic-v5.c
> index 0f269321ece4b..75372bbfb6a6a 100644
> --- a/arch/arm64/kvm/vgic/vgic-v5.c
> +++ b/arch/arm64/kvm/vgic/vgic-v5.c
> @@ -238,7 +238,7 @@ static u32
> vgic_v5_get_effective_priority_mask(struct kvm_vcpu *vcpu)
> */
> priority_mask = FIELD_GET(FEAT_GCIE_ICH_VMCR_EL2_VPMR,
> cpu_if->vgic_vmcr);
>
> - return min(highest_ap, priority_mask + 1);
> + return min(highest_ap, priority_mask);
Hi Marc,
This part of your change (dropping the `- 1`) is not correct for GICv5.
The GICv[23] PMR works differently to the GICv5 PCR.
For GICv[23] the mask is exclusive, i.e., only higher priority (lower
numerical value) interrupts are of sufficient priority to be signalled.
For GICv5, the priority of an interrupt can be equal to or higher than
(numerically lower than) the mask. See DMSQKF in the GICv5 spec:
A physical interrupt has Sufficient priority to be signaled when all of
the following are true:
* The priority of the interrupt is higher than the physical running
priority for the Physical Interrupt Domain.
* The priority of the interrupt is equal to or higher than the
Physical Priority Mask for the Physical Interrupt Domain.
Therefore, we require this `+ 1` for the priority_mask in order to allow
us to combine the active priority and priority mask. Else, they operate on
different scales.
I'd tried to explain this in a comment that lies just outside the diff,
but hadn't explicitly called out that GICv5 operates differently to
GICv[23] in this regard. Apologies.
> }
>
> /*
> @@ -367,7 +367,7 @@ bool vgic_v5_has_pending_ppi(struct kvm_vcpu
> *vcpu)
>
> scoped_guard(raw_spinlock_irqsave, &irq->irq_lock)
> has_pending = (irq->enabled &&
> irq_is_pending(irq) &&
> - irq->priority <=
> priority_mask);
> + irq->priority <
> priority_mask);
I agree that this was wrong and should never have included the
equality. This was definitely a bug!
Thanks,
Sascha
>
> vgic_put_irq(vcpu->kvm, irq);
>
^ permalink raw reply
* Re: [PATCH v2] ARM: module: fix unwind section relocation out of range error
From: Ard Biesheuvel @ 2026-03-31 14:56 UTC (permalink / raw)
To: William Zhang, linux-arm-kernel
Cc: Song Liu, linus.walleij, florian.fainelli, anand.gore,
Broadcom Kernel List, kursad.oney, Sebastian Andrzej Siewior,
Peter Zijlstra, Luis Chamberlain, linux-kernel, Thomas Gleixner,
Christophe Leroy, Petr Pavlu, Russell King
In-Reply-To: <CAHi4H7EC9+7yBofXE=AabeHtHFsrzOQA9kAq4of8Eu0CG2dfnA@mail.gmail.com>
Hi,
On Mon, 23 Feb 2026, at 03:30, William Zhang wrote:
> Hi,
>
> On Mon, Sep 22, 2025 at 1:24 PM William Zhang
> <william.zhang@broadcom.com> wrote:
>>
>> In an armv7 system that uses non-3G/1G split and with more than 512MB
>> physical memory, driver load may fail with following error:
>> section 29 reloc 0 sym '': relocation 42 out of range (0xc2ab9be8 ->
>> 0x7fad5998)
>>
>> This happens when relocation R_ARM_PREL31 from the unwind section
>> .ARM.extab and .ARM.exidx are allocated from the VMALLOC space while
>> .text section is from MODULES_VADDR space. It exceeds the +/-1GB
>> relocation requirement of R_ARM_PREL31 hence triggers the error.
>>
>> The fix is to mark .ARM.extab and .ARM.exidx sections as executable so
>> they can be allocated along with .text section and always meet range
>> requirement.
>>
>> Fixes: ac3b43283923 ("module: replace module_layout with module_memory")
>>
>> Co-developed-by: Ard Biesheuvel <ardb@kernel.org>
>> Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
>> Signed-off-by: William Zhang <william.zhang@broadcom.com>
>>
>> ---
>>
>> Changes in v2:
>> - Fix the comment in code and commit message regarding the unwind
>> section location
>> - Add fix tag for more visibility
>>
>> arch/arm/kernel/module-plts.c | 12 ++++++++++++
>> 1 file changed, 12 insertions(+)
>>
>> diff --git a/arch/arm/kernel/module-plts.c b/arch/arm/kernel/module-plts.c
>> index 354ce16d83cb..b5338fe59706 100644
>> --- a/arch/arm/kernel/module-plts.c
>> +++ b/arch/arm/kernel/module-plts.c
>> @@ -225,6 +225,18 @@ int module_frob_arch_sections(Elf_Ehdr *ehdr, Elf_Shdr *sechdrs,
>> mod->arch.init.plt = s;
>> else if (s->sh_type == SHT_SYMTAB)
>> syms = (Elf32_Sym *)s->sh_addr;
>> +#if defined(CONFIG_ARM_UNWIND) && !defined(CONFIG_VMSPLIT_3G)
>> + else if (s->sh_type == ELF_SECTION_UNWIND ||
>> + (strncmp(".ARM.extab", secstrings + s->sh_name, 10) == 0)) {
>> + /*
>> + * To avoid the possible relocation out of range issue for
>> + * R_ARM_PREL31, mark unwind section .ARM.extab and .ARM.exidx as
>> + * executable so they will be allocated along with .text section to
>> + * meet +/-1GB range requirement of the R_ARM_PREL31 relocation
>> + */
>> + s->sh_flags |= SHF_EXECINSTR;
>> + }
>> +#endif
>> }
>>
>> if (!mod->arch.core.plt || !mod->arch.init.plt) {
>> --
>> 2.43.7
>>
>
> Is this version okay to be accepted?
>
Please put it in Russell's patch tracker.
https://www.arm.linux.org.uk/developer/patches/
^ permalink raw reply
* Re: [PATCH 1/2] reset: amlogic: t7: Fix null reset ops
From: Philipp Zabel @ 2026-03-31 14:54 UTC (permalink / raw)
To: Ronald Claveau, Neil Armstrong, Kevin Hilman, Jerome Brunet,
Martin Blumenstingl, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: linux-arm-kernel, linux-amlogic, linux-kernel, devicetree
In-Reply-To: <20260331-fix-aml-t7-null-reset-v1-1-eb95b625234c@aliel.fr>
On Di, 2026-03-31 at 16:24 +0200, Ronald Claveau wrote:
> Fix missing reset ops causing kernel null pointer dereference.
> This SOC's reset is currently not used yet.
>
> Signed-off-by: Ronald Claveau <linux-kernel-dev@aliel.fr>
This is
Fixes: fb4c31587adf ("reset: amlogic: add auxiliary reset driver support")
Reviewed-by: Philipp Zabel <p.zabel@pengutronix.de>
regards
Philipp
^ permalink raw reply
* Re: [RFC PATCH 1/7] media: v4l2-ctrls: Add V4L2_CID_MEMORY_USAGE control
From: Nicolas Dufresne @ 2026-03-31 14:54 UTC (permalink / raw)
To: Frank Li, ming.qian
Cc: linux-media, mchehab, hverkuil-cisco, sebastian.fricke, shawnguo,
s.hauer, kernel, festevam, linux-imx, xiahong.bao, eagle.zhou,
imx, linux-kernel, linux-arm-kernel
In-Reply-To: <acvbOo17tU-s20BS@lizhi-Precision-Tower-5810>
[-- Attachment #1: Type: text/plain, Size: 3043 bytes --]
Le mardi 31 mars 2026 à 10:33 -0400, Frank Li a écrit :
> On Tue, Mar 31, 2026 at 03:23:11PM +0800, ming.qian@oss.nxp.com wrote:
> > From: Ming Qian <ming.qian@oss.nxp.com>
> >
> > Add a new read-only control V4L2_CID_MEMORY_USAGE that allows
> > applications to query the total amount of memory currently used
> > by a device instance.
> >
> > This control reports the memory consumption in bytes, including
> > internal buffers, intermediate processing data, and other
> > driver-managed allocations. Applications can use this information
> > for debugging, resource monitoring, or making informed decisions
> > about buffer allocation strategies.
> >
> > Signed-off-by: Ming Qian <ming.qian@oss.nxp.com>
> > ---
>
> Not sure why not export these information by debugfs, or any benefit vs
> debugfs?
There is also a on-going proposal that uses fdinfo.
Nicolas
>
> Generanlly document should be first patch, then driver change.
>
> Frank
>
> > drivers/media/v4l2-core/v4l2-ctrls-defs.c | 8 ++++++++
> > include/uapi/linux/v4l2-controls.h | 4 +++-
> > 2 files changed, 11 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/media/v4l2-core/v4l2-ctrls-defs.c b/drivers/media/v4l2-core/v4l2-ctrls-defs.c
> > index 551426c4cd01..053db78ff661 100644
> > --- a/drivers/media/v4l2-core/v4l2-ctrls-defs.c
> > +++ b/drivers/media/v4l2-core/v4l2-ctrls-defs.c
> > @@ -831,6 +831,7 @@ const char *v4l2_ctrl_get_name(u32 id)
> > case V4L2_CID_ALPHA_COMPONENT: return "Alpha Component";
> > case V4L2_CID_COLORFX_CBCR: return "Color Effects, CbCr";
> > case V4L2_CID_COLORFX_RGB: return "Color Effects, RGB";
> > + case V4L2_CID_MEMORY_USAGE: return "Memory Usage";
> >
> > /*
> > * Codec controls
> > @@ -1476,6 +1477,13 @@ void v4l2_ctrl_fill(u32 id, const char **name, enum v4l2_ctrl_type *type,
> > *min = 0;
> > *max = 0xffff;
> > break;
> > + case V4L2_CID_MEMORY_USAGE:
> > + *type = V4L2_CTRL_TYPE_INTEGER64;
> > + *flags |= V4L2_CTRL_FLAG_READ_ONLY;
> > + *min = 0;
> > + *max = S64_MAX;
> > + *step = 1;
> > + break;
> > case V4L2_CID_FLASH_FAULT:
> > case V4L2_CID_JPEG_ACTIVE_MARKER:
> > case V4L2_CID_3A_LOCK:
> > diff --git a/include/uapi/linux/v4l2-controls.h b/include/uapi/linux/v4l2-controls.h
> > index 68dd0c4e47b2..02c6f960d38e 100644
> > --- a/include/uapi/linux/v4l2-controls.h
> > +++ b/include/uapi/linux/v4l2-controls.h
> > @@ -110,8 +110,10 @@ enum v4l2_colorfx {
> > #define V4L2_CID_COLORFX_CBCR (V4L2_CID_BASE+42)
> > #define V4L2_CID_COLORFX_RGB (V4L2_CID_BASE+43)
> >
> > +#define V4L2_CID_MEMORY_USAGE (V4L2_CID_BASE+44)
> > +
> > /* last CID + 1 */
> > -#define V4L2_CID_LASTP1 (V4L2_CID_BASE+44)
> > +#define V4L2_CID_LASTP1 (V4L2_CID_BASE+45)
> >
> > /* USER-class private control IDs */
> >
> > --
> > 2.53.0
> >
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH v7 1/5] clk: bcm: rpi: Manage clock rate in prepare/unprepare callbacks
From: Mark Brown @ 2026-03-31 14:44 UTC (permalink / raw)
To: Maíra Canal
Cc: Michael Turquette, Stephen Boyd, Nicolas Saenz Julienne,
Florian Fainelli, Stefan Wahren, Maxime Ripard, Melissa Wen,
Iago Toral Quiroga, Chema Casanova, Dave Stevenson, Philipp Zabel,
linux-clk, dri-devel, linux-rpi-kernel, linux-arm-kernel,
Broadcom internal kernel review list, kernel-dev
In-Reply-To: <d251c380-f2f5-4daf-9661-bbb6dc6c959e@igalia.com>
[-- Attachment #1: Type: text/plain, Size: 1938 bytes --]
On Tue, Mar 31, 2026 at 11:32:07AM -0300, Maíra Canal wrote:
> On 31/03/26 09:49, Mark Brown wrote:
> > On Thu, Mar 12, 2026 at 06:34:23PM -0300, Maíra Canal wrote:
> > > Rather than pushing rate management to clock consumers, handle it
> > > directly in the clock framework's prepare/unprepare callbacks. In
> > > unprepare, set the rate to the minimum before disabling the clock.
> > > In prepare, for clocks marked with `maximize` (currently v3d),
> > > restore the rate to the maximum after enabling.
> > I'm seeing boot regressions in -next with NFS root on Raspberry Pi 3B+
> > which bisect to this commit. We get a likely unrelated oops from the
> > firmware interface and the boot grinds to a halt some time later since
> > the ethernet never comes up:
> I've managed to address this issue locally with the following diff:
> diff --git a/drivers/clk/bcm/clk-raspberrypi.c
> b/drivers/clk/bcm/clk-raspberrypi.c
> index df2d246eb6ef..ef5ae3b4adca 100644
> --- a/drivers/clk/bcm/clk-raspberrypi.c
> +++ b/drivers/clk/bcm/clk-raspberrypi.c
> @@ -160,6 +160,7 @@ raspberrypi_clk_variants[RPI_FIRMWARE_NUM_CLK_ID] = {
> [RPI_FIRMWARE_VEC_CLK_ID] = {
> .export = true,
> .minimize = true,
> + .flags = CLK_IGNORE_UNUSED,
> },
> [RPI_FIRMWARE_DISP_CLK_ID] = {
> .export = true,
> It looks like the VEC_CLK can't be disabled at boot time. Otherwise, a
> bus lookup will happen (similar what happens to other RPi firmware
> clocks).
> Is it possible for me to test this change in LAVA CI before sending it
> to the list? Just to double check that this patch indeed fixes the
> issue on your side as well.
I can give you access to submit jobs easily enough, if you're already
familiar with LAVA and have somewhere to host the binaries that'd work.
It might be more straightforward for me to just test it.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH v12 2/3] of: Factor arguments passed to of_map_id() into a struct
From: Frank Li @ 2026-03-31 14:43 UTC (permalink / raw)
To: Vijayanand Jitta
Cc: Nipun Gupta, Nikhil Agarwal, Joerg Roedel, Will Deacon,
Robin Murphy, Marc Zyngier, Lorenzo Pieralisi, Thomas Gleixner,
Saravana Kannan, Richard Zhu, Lucas Stach,
Krzysztof Wilczyński, Manivannan Sadhasivam, Bjorn Helgaas,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
Juergen Gross, Stefano Stabellini, Oleksandr Tyshchenko,
Dmitry Baryshkov, Konrad Dybcio, Bjorn Andersson, Rob Herring,
Conor Dooley, Krzysztof Kozlowski, Prakash Gupta, Vikash Garodia,
linux-kernel, iommu, linux-arm-kernel, devicetree, linux-pci, imx,
xen-devel, linux-arm-msm, Charan Teja Kalla
In-Reply-To: <20260331-parse_iommu_cells-v12-2-decfd305eea9@oss.qualcomm.com>
On Tue, Mar 31, 2026 at 07:34:47PM +0530, Vijayanand Jitta wrote:
> From: Charan Teja Kalla <charan.kalla@oss.qualcomm.com>
>
> Change of_map_id() to take a pointer to struct of_phandle_args
> instead of passing target device node and translated IDs separately.
> Update all callers accordingly.
>
> Add an explicit filter_np parameter to of_map_id() and of_map_msi_id()
> to separate the filter input from the output. Previously, the target
> parameter served dual purpose: as an input filter (if non-NULL, only
> match entries targeting that node) and as an output (receiving the
> matched node with a reference held). Now filter_np is the explicit
> input filter and arg->np is the pure output.
>
> Previously, of_map_id() would call of_node_put() on the matched node
> when a filter was provided, making reference ownership inconsistent.
> Remove this internal of_node_put() call so that of_map_id() now always
> transfers ownership of the matched node reference to the caller via
> arg->np. Callers are now consistently responsible for releasing this
> reference with of_node_put(arg->np) when done.
>
> Suggested-by: Rob Herring (Arm) <robh@kernel.org>
> Suggested-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
> Signed-off-by: Charan Teja Kalla <charan.kalla@oss.qualcomm.com>
> Signed-off-by: Vijayanand Jitta <vijayanand.jitta@oss.qualcomm.com>
> ---
> drivers/cdx/cdx_msi.c | 7 ++--
> drivers/iommu/of_iommu.c | 4 +-
> drivers/irqchip/irq-gic-its-msi-parent.c | 11 ++++--
> drivers/of/base.c | 68 +++++++++++++++++---------------
> drivers/of/irq.c | 10 ++++-
> drivers/pci/controller/dwc/pci-imx6.c | 32 +++++++--------
>
> for imx part.
>
> Reviewed-by: Frank Li <Frank.Li@nxp.com>
^ permalink raw reply
* Re: [PATCH v2 1/3] arm64: mm: Fix rodata=full block mapping support for realm guests
From: Suzuki K Poulose @ 2026-03-31 14:35 UTC (permalink / raw)
To: Ryan Roberts, Catalin Marinas, Will Deacon,
David Hildenbrand (Arm), Dev Jain, Yang Shi, Jinjiang Tu,
Kevin Brodsky
Cc: linux-arm-kernel, linux-kernel, stable
In-Reply-To: <20260330161705.3349825-2-ryan.roberts@arm.com>
On 30/03/2026 17:17, Ryan Roberts wrote:
> Commit a166563e7ec37 ("arm64: mm: support large block mapping when
> rodata=full") enabled the linear map to be mapped by block/cont while
> still allowing granular permission changes on BBML2_NOABORT systems by
> lazily splitting the live mappings. This mechanism was intended to be
> usable by realm guests since they need to dynamically share dma buffers
> with the host by "decrypting" them - which for Arm CCA, means marking
> them as shared in the page tables.
>
> However, it turns out that the mechanism was failing for realm guests
> because realms need to share their dma buffers (via
> __set_memory_enc_dec()) much earlier during boot than
> split_kernel_leaf_mapping() was able to handle. The report linked below
> showed that GIC's ITS was one such user. But during the investigation I
> found other callsites that could not meet the
> split_kernel_leaf_mapping() constraints.
>
> The problem is that we block map the linear map based on the boot CPU
> supporting BBML2_NOABORT, then check that all the other CPUs support it
> too when finalizing the caps. If they don't, then we stop_machine() and
> split to ptes. For safety, split_kernel_leaf_mapping() previously
> wouldn't permit splitting until after the caps were finalized. That
> ensured that if any secondary cpus were running that didn't support
> BBML2_NOABORT, we wouldn't risk breaking them.
>
> I've fix this problem by reducing the black-out window where we refuse
> to split; there are now 2 windows. The first is from T0 until the page
> allocator is inititialized. Splitting allocates memory for the page
> allocator so it must be in use. The second covers the period between
> starting to online the secondary cpus until the system caps are
> finalized (this is a very small window).
>
> All of the problematic callers are calling __set_memory_enc_dec() before
> the secondary cpus come online, so this solves the problem. However, one
> of these callers, swiotlb_update_mem_attributes(), was trying to split
> before the page allocator was initialized. So I have moved this call
> from arch_mm_preinit() to mem_init(), which solves the ordering issue.
>
> I've added warnings and return an error if any attempt is made to split
> in the black-out windows.
>
> Note there are other issues which prevent booting all the way to user
> space, which will be fixed in subsequent patches.
>
> Reported-by: Jinjiang Tu <tujinjiang@huawei.com>
> Closes: https://lore.kernel.org/all/0b2a4ae5-fc51-4d77-b177-b2e9db74f11d@huawei.com/
> Fixes: a166563e7ec37 ("arm64: mm: support large block mapping when rodata=full")
> Cc: stable@vger.kernel.org
> Reviewed-by: Kevin Brodsky <kevin.brodsky@arm.com>
I have tested with a hacked cpufeature code to enable BBML2_NOABORT
for FVP MIDRs.
Reviewed-by: Suzuki K Poulose <suzuki.poulose@arm.com>
Tested-by: Suzuki K Poulose <suzuki.poulose@arm.com>
Suzuki
> Signed-off-by: Ryan Roberts <ryan.roberts@arm.com>
> ---
> arch/arm64/include/asm/mmu.h | 2 ++
> arch/arm64/mm/init.c | 9 +++++++-
> arch/arm64/mm/mmu.c | 45 +++++++++++++++++++++++++-----------
> 3 files changed, 42 insertions(+), 14 deletions(-)
>
> diff --git a/arch/arm64/include/asm/mmu.h b/arch/arm64/include/asm/mmu.h
> index 137a173df1ff8..472610433aaea 100644
> --- a/arch/arm64/include/asm/mmu.h
> +++ b/arch/arm64/include/asm/mmu.h
> @@ -112,5 +112,7 @@ void kpti_install_ng_mappings(void);
> static inline void kpti_install_ng_mappings(void) {}
> #endif
>
> +extern bool page_alloc_available;
> +
> #endif /* !__ASSEMBLER__ */
> #endif
> diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
> index 96711b8578fd0..b9b248d24fd10 100644
> --- a/arch/arm64/mm/init.c
> +++ b/arch/arm64/mm/init.c
> @@ -350,7 +350,6 @@ void __init arch_mm_preinit(void)
> }
>
> swiotlb_init(swiotlb, flags);
> - swiotlb_update_mem_attributes();
>
> /*
> * Check boundaries twice: Some fundamental inconsistencies can be
> @@ -377,6 +376,14 @@ void __init arch_mm_preinit(void)
> }
> }
>
> +bool page_alloc_available __ro_after_init;
> +
> +void __init mem_init(void)
> +{
> + page_alloc_available = true;
> + swiotlb_update_mem_attributes();
> +}
> +
> void free_initmem(void)
> {
> void *lm_init_begin = lm_alias(__init_begin);
> diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
> index a6a00accf4f93..223947487a223 100644
> --- a/arch/arm64/mm/mmu.c
> +++ b/arch/arm64/mm/mmu.c
> @@ -768,30 +768,51 @@ static inline bool force_pte_mapping(void)
> }
>
> static DEFINE_MUTEX(pgtable_split_lock);
> +static bool linear_map_requires_bbml2;
>
> int split_kernel_leaf_mapping(unsigned long start, unsigned long end)
> {
> int ret;
>
> - /*
> - * !BBML2_NOABORT systems should not be trying to change permissions on
> - * anything that is not pte-mapped in the first place. Just return early
> - * and let the permission change code raise a warning if not already
> - * pte-mapped.
> - */
> - if (!system_supports_bbml2_noabort())
> - return 0;
> -
> /*
> * If the region is within a pte-mapped area, there is no need to try to
> * split. Additionally, CONFIG_DEBUG_PAGEALLOC and CONFIG_KFENCE may
> * change permissions from atomic context so for those cases (which are
> * always pte-mapped), we must not go any further because taking the
> - * mutex below may sleep.
> + * mutex below may sleep. Do not call force_pte_mapping() here because
> + * it could return a confusing result if called from a secondary cpu
> + * prior to finalizing caps. Instead, linear_map_requires_bbml2 gives us
> + * what we need.
> */
> - if (force_pte_mapping() || is_kfence_address((void *)start))
> + if (!linear_map_requires_bbml2 || is_kfence_address((void *)start))
> return 0;
>
> + if (!system_supports_bbml2_noabort()) {
> + /*
> + * !BBML2_NOABORT systems should not be trying to change
> + * permissions on anything that is not pte-mapped in the first
> + * place. Just return early and let the permission change code
> + * raise a warning if not already pte-mapped.
> + */
> + if (system_capabilities_finalized())
> + return 0;
> +
> + /*
> + * Boot-time: split_kernel_leaf_mapping_locked() allocates from
> + * page allocator. Can't split until it's available.
> + */
> + if (WARN_ON(!page_alloc_available))
> + return -EBUSY;
> +
> + /*
> + * Boot-time: Started secondary cpus but don't know if they
> + * support BBML2_NOABORT yet. Can't allow splitting in this
> + * window in case they don't.
> + */
> + if (WARN_ON(num_online_cpus() > 1))
> + return -EBUSY;
> + }
> +
> /*
> * Ensure start and end are at least page-aligned since this is the
> * finest granularity we can split to.
> @@ -891,8 +912,6 @@ static int range_split_to_ptes(unsigned long start, unsigned long end, gfp_t gfp
> return ret;
> }
>
> -static bool linear_map_requires_bbml2 __initdata;
> -
> u32 idmap_kpti_bbml2_flag;
>
> static void __init init_idmap_kpti_bbml2_flag(void)
^ 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