* Re: [GIT PULL] amlogic ARM64 DT updates for v7.1
From: Arnd Bergmann @ 2026-04-20 15:25 UTC (permalink / raw)
To: Krzysztof Kozlowski, Neil Armstrong
Cc: soc, arm, linux-amlogic, linux-arm-kernel
In-Reply-To: <4b2a319e-3292-4576-b5b9-4e7db8aebe87@kernel.org>
On Mon, Apr 13, 2026, at 09:30, Krzysztof Kozlowski wrote:
> On 13/04/2026 09:17, Krzysztof Kozlowski wrote:
>> On 13/04/2026 09:10, Neil Armstrong wrote:
>>>>
>>>> I will wait with this. It might miss the merge window if v7.0 is
>>>> released this weekend.
>>>
>>> Ok wow, just like that... I mean the amlogic DT is stable, all patches
>>> patches bindings checks and none is critical since it mainly touches
>>
>> You sent your pull very late, just before v7.1, and skipping late
>> posting is not a new rule. It was always going late pulls, which might
>> make it or might not make it.
>>
>>> new platforms and the incriminated commit is a low priority fix for
>>> 10y old development boards...
>>
>> I did not check which commit was not in next. You can provide feedback
>> to my reply with actual argument, because such explanation was missing
>> in tag. Instead you decided to be surprised that patches needs to be in
>> next...
>>
>
> And to clarify, I did not say that pull will not make it. Considering
> the timeline:
> 1. You sent the pull on 10th April, Friday
> 2. v7.1 is released on 13th April, Sunday
>
> and that people are allowed to take weekends off, then there is simply
> almost no way that pull can be merged before v7.1 is released, so by
> definition it is a *late pull*. The policy for late pulls, like that,
> did not change.
>
> Lack of exposure of a few commits to linux-next is only the explanation
> why I did not pull it while doing last round of pulls.
I'm looking through the backlog for any missing fixes that should
still make it into -rc1 or -rc2. Just a few more points to add
from my end:
- I had in the past always trusted platform maintainers to only
send pull requests when they felt the contents had spent enough
time in linux-next already, but I did not have any scripting
to ensure this was done correctly.
- I see that only a few of the patches in the branch got applied
during the fineal days before the merge window, while the rest
had been part of next-20260330 or earlier. Aside from just
sending the bulk of the contents earlier, I think the best
solution on Neil's side would have been to send two separate
pull requests, for the earlier and the later contents
respectively, even if sending them on the same day
- I see that some of the late commits are clear bugfixes that
we should still merge as soon as possible. Neil, can you go
through the branch and send another PR for anything that
qualifies as a bugfix? While by now it's clearly too late
for any of the new features, there is no need to delay those
any further.
Arnd
^ permalink raw reply
* Re: [PATCH 11/11] Drivers: hv: Kconfig: Add ARM64 support for MSHV_VTL
From: Naman Jain @ 2026-04-20 15:24 UTC (permalink / raw)
To: Michael Kelley, K . Y . Srinivasan, Haiyang Zhang, Wei Liu,
Dexuan Cui, Long Li, Catalin Marinas, Will Deacon,
Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen,
x86@kernel.org, H . Peter Anvin, Arnd Bergmann, Paul Walmsley,
Palmer Dabbelt, Albert Ou, Alexandre Ghiti
Cc: Marc Zyngier, Timothy Hayes, Lorenzo Pieralisi, mrigendrachaubey,
ssengar@linux.microsoft.com, linux-hyperv@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, linux-arch@vger.kernel.org,
linux-riscv@lists.infradead.org
In-Reply-To: <SN6PR02MB4157FEE5578344625418BFDBD450A@SN6PR02MB4157.namprd02.prod.outlook.com>
On 4/1/2026 10:28 PM, Michael Kelley wrote:
> From: Naman Jain <namjain@linux.microsoft.com> Sent: Monday, March 16, 2026 5:13 AM
>>
>
> Nit: In keeping with past practice, the "Subject" prefix for this patch could
> just be "Drivers: hv:"
Acked.
I am also planning to change other subject line prefixes, based on your
earlier suggestion:
mshv_vtl_main changes - "mshv_vtl: "
arch/arm64 Hyper-V changes - "arm64: hyperv: "
arch/x86 Hyper-V changes - "x86/hyperv: "
Thank you so much for doing such a thorough review. I really appreciate
all the help and guidance.
Regards,
Naman
^ permalink raw reply
* Re: [PATCH 10/11] Drivers: hv: Add support for arm64 in MSHV_VTL
From: Naman Jain @ 2026-04-20 15:24 UTC (permalink / raw)
To: Michael Kelley, K . Y . Srinivasan, Haiyang Zhang, Wei Liu,
Dexuan Cui, Long Li, Catalin Marinas, Will Deacon,
Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen,
x86@kernel.org, H . Peter Anvin, Arnd Bergmann, Paul Walmsley,
Palmer Dabbelt, Albert Ou, Alexandre Ghiti
Cc: Marc Zyngier, Timothy Hayes, Lorenzo Pieralisi, mrigendrachaubey,
ssengar@linux.microsoft.com, linux-hyperv@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, linux-arch@vger.kernel.org,
linux-riscv@lists.infradead.org
In-Reply-To: <SN6PR02MB41576766C5FB291952CC58E8D450A@SN6PR02MB4157.namprd02.prod.outlook.com>
On 4/1/2026 10:28 PM, Michael Kelley wrote:
> From: Naman Jain <namjain@linux.microsoft.com> Sent: Monday, March 16, 2026 5:13 AM
>>
>> Add necessary support to make MSHV_VTL work for arm64 architecture.
>> * Add stub implementation for mshv_vtl_return_call_init(): not required
>> for arm64
>> * Remove fpu/legacy.h header inclusion, as this is not required
>> * handle HV_REGISTER_VSM_CODE_PAGE_OFFSETS register: not supported
>> in arm64
>> * Configure custom percpu_vmbus_handler by using
>> hv_setup_percpu_vmbus_handler()
>> * Handle hugepage functions by config checks
>>
>> Signed-off-by: Roman Kisel <romank@linux.microsoft.com>
>> Signed-off-by: Naman Jain <namjain@linux.microsoft.com>
>> ---
>> arch/arm64/include/asm/mshyperv.h | 2 ++
>> drivers/hv/mshv_vtl_main.c | 21 ++++++++++++++-------
>> 2 files changed, 16 insertions(+), 7 deletions(-)
>>
>> diff --git a/arch/arm64/include/asm/mshyperv.h
>> b/arch/arm64/include/asm/mshyperv.h
>> index 36803f0386cc..027a7f062d70 100644
>> --- a/arch/arm64/include/asm/mshyperv.h
>> +++ b/arch/arm64/include/asm/mshyperv.h
>> @@ -83,6 +83,8 @@ static inline int hv_vtl_get_set_reg(struct hv_register_assoc *regs, bool set, u
>> return 1;
>> }
>>
>> +static inline void mshv_vtl_return_call_init(u64 vtl_return_offset) {}
>> +
>> void mshv_vtl_return_call(struct mshv_vtl_cpu_context *vtl0);
>> bool hv_vtl_configure_reg_page(struct mshv_vtl_per_cpu *per_cpu);
>> #endif
>> diff --git a/drivers/hv/mshv_vtl_main.c b/drivers/hv/mshv_vtl_main.c
>> index 4c9ae65ad3e8..5702fe258500 100644
>> --- a/drivers/hv/mshv_vtl_main.c
>> +++ b/drivers/hv/mshv_vtl_main.c
>> @@ -23,8 +23,6 @@
>> #include <trace/events/ipi.h>
>> #include <uapi/linux/mshv.h>
>> #include <hyperv/hvhdk.h>
>> -
>> -#include "../../kernel/fpu/legacy.h"
>
> Was there a particular code change that made this unnecessary? Or was it
> unnecessary from the start of this source code file? Just curious ....
This was present in initial driver changes when the assembly code was
part of this driver. Then it moved to arch files and this was left here.
Just cleaning it up.
>
>> #include "mshv.h"
>> #include "mshv_vtl.h"
>> #include "hyperv_vmbus.h"
>> @@ -206,18 +204,21 @@ static void mshv_vtl_synic_enable_regs(unsigned int cpu)
>> static int mshv_vtl_get_vsm_regs(void)
>> {
>> struct hv_register_assoc registers[2];
>> - int ret, count = 2;
>> + int ret, count = 0;
>>
>> - registers[0].name = HV_REGISTER_VSM_CODE_PAGE_OFFSETS;
>> - registers[1].name = HV_REGISTER_VSM_CAPABILITIES;
>> + registers[count++].name = HV_REGISTER_VSM_CAPABILITIES;
>> + /* Code page offset register is not supported on ARM */
>> + if (IS_ENABLED(CONFIG_X86_64))
>> + registers[count++].name = HV_REGISTER_VSM_CODE_PAGE_OFFSETS;
>>
>> ret = hv_call_get_vp_registers(HV_VP_INDEX_SELF, HV_PARTITION_ID_SELF,
>> count, input_vtl_zero, registers);
>> if (ret)
>> return ret;
>>
>> - mshv_vsm_page_offsets.as_uint64 = registers[0].value.reg64;
>> - mshv_vsm_capabilities.as_uint64 = registers[1].value.reg64;
>> + mshv_vsm_capabilities.as_uint64 = registers[0].value.reg64;
>> + if (IS_ENABLED(CONFIG_X86_64))
>> + mshv_vsm_page_offsets.as_uint64 = registers[1].value.reg64;
>>
>> return ret;
>> }
>
> This function has gotten somewhat messy to handle the x86 and arm64
> differences. Let me suggest a different approach. Have this function only
> get the VSM capabilities register, as that is generic across x86 and
> arm64. Then, update x86 mshv_vtl_return_call_init() to get the
> PAGE_OFFSETS register and then immediately use the value to update
> the static call. The global variable mshv_vms_page_offsets is no longer
> necessary.
>
> My suggestion might be little more code because hv_call_get_vp_registers()
> is invoked in two different places. But it cleanly separates the two use
> cases, and keeps the x86 hackery under arch/x86.
>
I implemented this in my dev branch, and it works fine. Thanks for the
suggestion.
>> @@ -280,10 +281,13 @@ static int hv_vtl_setup_synic(void)
>>
>> /* Use our isr to first filter out packets destined for userspace */
>> hv_setup_vmbus_handler(mshv_vtl_vmbus_isr);
>> + /* hv_setup_vmbus_handler() is stubbed for ARM64, add per-cpu VMBus handlers instead */
>> + hv_setup_percpu_vmbus_handler(mshv_vtl_vmbus_isr);
>>
>> ret = cpuhp_setup_state(CPUHP_AP_ONLINE_DYN, "hyperv/vtl:online",
>> mshv_vtl_alloc_context, NULL);
>> if (ret < 0) {
>> + hv_setup_percpu_vmbus_handler(vmbus_isr);
>> hv_setup_vmbus_handler(vmbus_isr);
>> return ret;
>> }
>> @@ -296,6 +300,7 @@ static int hv_vtl_setup_synic(void)
>> static void hv_vtl_remove_synic(void)
>> {
>> cpuhp_remove_state(mshv_vtl_cpuhp_online);
>> + hv_setup_percpu_vmbus_handler(vmbus_isr);
hv_setup_percpu_vmbus_handler() calls will also be removed with the
redesign.
Regards,
Naman
^ permalink raw reply
* Re: [PATCH 08/11] Drivers: hv: mshv_vtl: Move register page config to arch-specific files
From: Naman Jain @ 2026-04-20 15:23 UTC (permalink / raw)
To: Michael Kelley, K . Y . Srinivasan, Haiyang Zhang, Wei Liu,
Dexuan Cui, Long Li, Catalin Marinas, Will Deacon,
Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen,
x86@kernel.org, H . Peter Anvin, Arnd Bergmann, Paul Walmsley,
Palmer Dabbelt, Albert Ou, Alexandre Ghiti
Cc: Marc Zyngier, Timothy Hayes, Lorenzo Pieralisi, mrigendrachaubey,
ssengar@linux.microsoft.com, linux-hyperv@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, linux-arch@vger.kernel.org,
linux-riscv@lists.infradead.org
In-Reply-To: <SN6PR02MB4157CF364DA2C0CC657A6DCBD450A@SN6PR02MB4157.namprd02.prod.outlook.com>
On 4/1/2026 10:28 PM, Michael Kelley wrote:
> From: Naman Jain <namjain@linux.microsoft.com> Sent: Monday, March 16, 2026 5:13 AM
>>
>> Move mshv_vtl_configure_reg_page() implementation from
>> drivers/hv/mshv_vtl_main.c to arch-specific files:
>> - arch/x86/hyperv/hv_vtl.c: full implementation with register page setup
>> - arch/arm64/hyperv/hv_vtl.c: stub implementation (unsupported)
>>
>> Move common type definitions to include/asm-generic/mshyperv.h:
>> - struct mshv_vtl_per_cpu
>> - union hv_synic_overlay_page_msr
>>
>> Move hv_call_get_vp_registers() and hv_call_set_vp_registers()
>> declarations to include/asm-generic/mshyperv.h since these functions
>> are used by multiple modules.
>>
>> While at it, remove the unnecessary stub implementations in #else
>> case for mshv_vtl_return* functions in arch/x86/include/asm/mshyperv.h.
>
> Seems like this patch is doing multiple things. The reg page configuration
> changes are more substantial and should probably be in a patch by
> themselves. The other changes are more trivial and maybe are OK
> grouped into a single patch, but you could also consider breaking them
> out.
I will split this patch into 3 patches.
>
>>
>> This is essential for adding support for ARM64 in MSHV_VTL.
>>
>> Signed-off-by: Naman Jain <namjain@linux.microsoft.com>
>> ---
>> arch/arm64/hyperv/hv_vtl.c | 8 +++++
>> arch/arm64/include/asm/mshyperv.h | 3 ++
>> arch/x86/hyperv/hv_vtl.c | 32 ++++++++++++++++++++
>> arch/x86/include/asm/mshyperv.h | 7 ++---
>> drivers/hv/mshv.h | 8 -----
>> drivers/hv/mshv_vtl_main.c | 49 +++----------------------------
>> include/asm-generic/mshyperv.h | 42 ++++++++++++++++++++++++++
>> 7 files changed, 92 insertions(+), 57 deletions(-)
>>
>> diff --git a/arch/arm64/hyperv/hv_vtl.c b/arch/arm64/hyperv/hv_vtl.c
>> index 66318672c242..d699138427c1 100644
>> --- a/arch/arm64/hyperv/hv_vtl.c
>> +++ b/arch/arm64/hyperv/hv_vtl.c
>> @@ -10,6 +10,7 @@
>> #include <asm/boot.h>
>> #include <asm/mshyperv.h>
>> #include <asm/cpu_ops.h>
>> +#include <linux/export.h>
>>
>> void mshv_vtl_return_call(struct mshv_vtl_cpu_context *vtl0)
>> {
>> @@ -142,3 +143,10 @@ void mshv_vtl_return_call(struct mshv_vtl_cpu_context *vtl0)
>> "v24", "v25", "v26", "v27", "v28", "v29", "v30", "v31");
>> }
>> EXPORT_SYMBOL(mshv_vtl_return_call);
>> +
>> +bool hv_vtl_configure_reg_page(struct mshv_vtl_per_cpu *per_cpu)
>> +{
>> + pr_debug("Register page not supported on ARM64\n");
>> + return false;
>> +}
>> +EXPORT_SYMBOL_GPL(hv_vtl_configure_reg_page);
>> diff --git a/arch/arm64/include/asm/mshyperv.h
>> b/arch/arm64/include/asm/mshyperv.h
>> index de7f3a41a8ea..36803f0386cc 100644
>> --- a/arch/arm64/include/asm/mshyperv.h
>> +++ b/arch/arm64/include/asm/mshyperv.h
>> @@ -61,6 +61,8 @@ static inline u64 hv_get_non_nested_msr(unsigned int reg)
>> ARM_SMCCC_OWNER_VENDOR_HYP, \
>> HV_SMCCC_FUNC_NUMBER)
>>
>> +struct mshv_vtl_per_cpu;
>> +
>> struct mshv_vtl_cpu_context {
>> /*
>> * NOTE: x18 is managed by the hypervisor. It won't be reloaded from this array.
>> @@ -82,6 +84,7 @@ static inline int hv_vtl_get_set_reg(struct hv_register_assoc *regs,
>> bool set, u
>> }
>>
>> void mshv_vtl_return_call(struct mshv_vtl_cpu_context *vtl0);
>> +bool hv_vtl_configure_reg_page(struct mshv_vtl_per_cpu *per_cpu);
>
> I think this declaration could be added in asm-generic/mshyperv.h so that it
> is shared by x86 and arm64. That also obviates the need for the forward
> ref to struct mshv_vtl_per_cpu that you've added here.
Acked.
>
>> #endif
>>
>> #include <asm-generic/mshyperv.h>
>> diff --git a/arch/x86/hyperv/hv_vtl.c b/arch/x86/hyperv/hv_vtl.c
>> index 72a0bb4ae0c7..ede290985d41 100644
>> --- a/arch/x86/hyperv/hv_vtl.c
>> +++ b/arch/x86/hyperv/hv_vtl.c
>> @@ -20,6 +20,7 @@
>> #include <uapi/asm/mtrr.h>
>> #include <asm/debugreg.h>
>> #include <linux/export.h>
>> +#include <linux/hyperv.h>
>> #include <../kernel/smpboot.h>
>> #include "../../kernel/fpu/legacy.h"
>>
>> @@ -259,6 +260,37 @@ int __init hv_vtl_early_init(void)
>> return 0;
>> }
>>
>> +static const union hv_input_vtl input_vtl_zero;
>> +
>> +bool hv_vtl_configure_reg_page(struct mshv_vtl_per_cpu *per_cpu)
>> +{
>> + struct hv_register_assoc reg_assoc = {};
>> + union hv_synic_overlay_page_msr overlay = {};
>> + struct page *reg_page;
>> +
>> + reg_page = alloc_page(GFP_KERNEL | __GFP_ZERO | __GFP_RETRY_MAYFAIL);
>> + if (!reg_page) {
>> + WARN(1, "failed to allocate register page\n");
>> + return false;
>> + }
>> +
>> + overlay.enabled = 1;
>> + overlay.pfn = page_to_hvpfn(reg_page);
>> + reg_assoc.name = HV_X64_REGISTER_REG_PAGE;
>> + reg_assoc.value.reg64 = overlay.as_uint64;
>> +
>> + if (hv_call_set_vp_registers(HV_VP_INDEX_SELF, HV_PARTITION_ID_SELF,
>> + 1, input_vtl_zero, ®_assoc)) {
>> + WARN(1, "failed to setup register page\n");
>> + __free_page(reg_page);
>> + return false;
>> + }
>> +
>> + per_cpu->reg_page = reg_page;
>> + return true;
>
> As Sashiko AI noted, the memory allocated for the reg_page never gets freed.
These are present in existing code, I'll address them in a separate series.
>
>> +}
>> +EXPORT_SYMBOL_GPL(hv_vtl_configure_reg_page);
>> +
>> DEFINE_STATIC_CALL_NULL(__mshv_vtl_return_hypercall, void (*)(void));
>>
>> void mshv_vtl_return_call_init(u64 vtl_return_offset)
>> diff --git a/arch/x86/include/asm/mshyperv.h b/arch/x86/include/asm/mshyperv.h
>> index d5355a5b7517..d592fea49cdb 100644
>> --- a/arch/x86/include/asm/mshyperv.h
>> +++ b/arch/x86/include/asm/mshyperv.h
>> @@ -271,6 +271,8 @@ static inline u64 hv_get_non_nested_msr(unsigned int reg) {
>> return 0; }
>> static inline int hv_apicid_to_vp_index(u32 apic_id) { return -EINVAL; }
>> #endif /* CONFIG_HYPERV */
>>
>> +struct mshv_vtl_per_cpu;
>> +
>> struct mshv_vtl_cpu_context {
>> union {
>> struct {
>> @@ -305,13 +307,10 @@ void mshv_vtl_return_call_init(u64 vtl_return_offset);
>> void mshv_vtl_return_hypercall(void);
>> void __mshv_vtl_return_call(struct mshv_vtl_cpu_context *vtl0);
>> int hv_vtl_get_set_reg(struct hv_register_assoc *regs, bool set, u64 shared);
>> +bool hv_vtl_configure_reg_page(struct mshv_vtl_per_cpu *per_cpu);
>
> Same as for arm64. Add a shared declaration in asm-generic/mshyperv.h.
Ditto.
>
>> #else
>> static inline void __init hv_vtl_init_platform(void) {}
>> static inline int __init hv_vtl_early_init(void) { return 0; }
>> -static inline void mshv_vtl_return_call(struct mshv_vtl_cpu_context *vtl0) {}
>> -static inline void mshv_vtl_return_call_init(u64 vtl_return_offset) {}
>> -static inline void mshv_vtl_return_hypercall(void) {}
>> -static inline void __mshv_vtl_return_call(struct mshv_vtl_cpu_context *vtl0) {}
>> #endif
>>
>> #include <asm-generic/mshyperv.h>
>> diff --git a/drivers/hv/mshv.h b/drivers/hv/mshv.h
>> index d4813df92b9c..0fcb7f9ba6a9 100644
>> --- a/drivers/hv/mshv.h
>> +++ b/drivers/hv/mshv.h
>> @@ -14,14 +14,6 @@
>> memchr_inv(&((STRUCT).MEMBER), \
>> 0, sizeof_field(typeof(STRUCT), MEMBER))
>>
>> -int hv_call_get_vp_registers(u32 vp_index, u64 partition_id, u16 count,
>> - union hv_input_vtl input_vtl,
>> - struct hv_register_assoc *registers);
>> -
>> -int hv_call_set_vp_registers(u32 vp_index, u64 partition_id, u16 count,
>> - union hv_input_vtl input_vtl,
>> - struct hv_register_assoc *registers);
>> -
>> int hv_call_get_partition_property(u64 partition_id, u64 property_code,
>> u64 *property_value);
>>
>> diff --git a/drivers/hv/mshv_vtl_main.c b/drivers/hv/mshv_vtl_main.c
>> index 91517b45d526..c79d24317b8e 100644
>> --- a/drivers/hv/mshv_vtl_main.c
>> +++ b/drivers/hv/mshv_vtl_main.c
>> @@ -78,21 +78,6 @@ struct mshv_vtl {
>> u64 id;
>> };
>>
>> -struct mshv_vtl_per_cpu {
>> - struct mshv_vtl_run *run;
>> - struct page *reg_page;
>> -};
>> -
>> -/* SYNIC_OVERLAY_PAGE_MSR - internal, identical to hv_synic_simp */
>> -union hv_synic_overlay_page_msr {
>> - u64 as_uint64;
>> - struct {
>> - u64 enabled: 1;
>> - u64 reserved: 11;
>> - u64 pfn: 52;
>> - } __packed;
>> -};
>> -
>> static struct mutex mshv_vtl_poll_file_lock;
>> static union hv_register_vsm_page_offsets mshv_vsm_page_offsets;
>> static union hv_register_vsm_capabilities mshv_vsm_capabilities;
>> @@ -201,34 +186,6 @@ static struct page *mshv_vtl_cpu_reg_page(int cpu)
>> return *per_cpu_ptr(&mshv_vtl_per_cpu.reg_page, cpu);
>> }
>>
>> -static void mshv_vtl_configure_reg_page(struct mshv_vtl_per_cpu *per_cpu)
>> -{
>> - struct hv_register_assoc reg_assoc = {};
>> - union hv_synic_overlay_page_msr overlay = {};
>> - struct page *reg_page;
>> -
>> - reg_page = alloc_page(GFP_KERNEL | __GFP_ZERO | __GFP_RETRY_MAYFAIL);
>> - if (!reg_page) {
>> - WARN(1, "failed to allocate register page\n");
>> - return;
>> - }
>> -
>> - overlay.enabled = 1;
>> - overlay.pfn = page_to_hvpfn(reg_page);
>> - reg_assoc.name = HV_X64_REGISTER_REG_PAGE;
>> - reg_assoc.value.reg64 = overlay.as_uint64;
>> -
>> - if (hv_call_set_vp_registers(HV_VP_INDEX_SELF, HV_PARTITION_ID_SELF,
>> - 1, input_vtl_zero, ®_assoc)) {
>> - WARN(1, "failed to setup register page\n");
>> - __free_page(reg_page);
>> - return;
>> - }
>> -
>> - per_cpu->reg_page = reg_page;
>> - mshv_has_reg_page = true;
>> -}
>> -
>> static void mshv_vtl_synic_enable_regs(unsigned int cpu)
>> {
>> union hv_synic_sint sint;
>> @@ -329,8 +286,10 @@ static int mshv_vtl_alloc_context(unsigned int cpu)
>> if (!per_cpu->run)
>> return -ENOMEM;
>>
>> - if (mshv_vsm_capabilities.intercept_page_available)
>> - mshv_vtl_configure_reg_page(per_cpu);
>> + if (mshv_vsm_capabilities.intercept_page_available) {
>> + if (hv_vtl_configure_reg_page(per_cpu))
>> + mshv_has_reg_page = true;
>
> As Sashiko AI noted, it doesn't work to use the global mshv_has_reg_page
> to indicate the success of configuring the reg page, which is a per-cpu
> operation. But this bug existed before this patch set, so maybe it should
> be fixed as a preliminary patch.
Acked. Will address them in a separate series.
>
>> + }
>>
>> mshv_vtl_synic_enable_regs(cpu);
>>
>> diff --git a/include/asm-generic/mshyperv.h b/include/asm-generic/mshyperv.h
>> index b147a12085e4..b53fcc071596 100644
>> --- a/include/asm-generic/mshyperv.h
>> +++ b/include/asm-generic/mshyperv.h
>> @@ -383,8 +383,50 @@ static inline int hv_deposit_memory(u64 partition_id, u64 status)
>> return hv_deposit_memory_node(NUMA_NO_NODE, partition_id, status);
>> }
>>
>> +#if IS_ENABLED(CONFIG_MSHV_ROOT) || IS_ENABLED(CONFIG_MSHV_VTL)
>> +int hv_call_get_vp_registers(u32 vp_index, u64 partition_id, u16 count,
>> + union hv_input_vtl input_vtl,
>> + struct hv_register_assoc *registers);
>> +
>> +int hv_call_set_vp_registers(u32 vp_index, u64 partition_id, u16 count,
>> + union hv_input_vtl input_vtl,
>> + struct hv_register_assoc *registers);
>> +#else
>> +static inline int hv_call_get_vp_registers(u32 vp_index, u64 partition_id,
>> + u16 count,
>> + union hv_input_vtl input_vtl,
>> + struct hv_register_assoc *registers)
>> +{
>> + return -EOPNOTSUPP;
>> +}
>> +
>> +static inline int hv_call_set_vp_registers(u32 vp_index, u64 partition_id,
>> + u16 count,
>> + union hv_input_vtl input_vtl,
>> + struct hv_register_assoc *registers)
>> +{
>> + return -EOPNOTSUPP;
>> +}
>> +#endif /* CONFIG_MSHV_ROOT || CONFIG_MSHV_VTL */
>> +
>> #define HV_VP_ASSIST_PAGE_ADDRESS_SHIFT 12
>> +
>> #if IS_ENABLED(CONFIG_HYPERV_VTL_MODE)
>> +struct mshv_vtl_per_cpu {
>> + struct mshv_vtl_run *run;
>> + struct page *reg_page;
>> +};
>> +
>> +/* SYNIC_OVERLAY_PAGE_MSR - internal, identical to hv_synic_simp */
>> +union hv_synic_overlay_page_msr {
>> + u64 as_uint64;
>> + struct {
>> + u64 enabled: 1;
>> + u64 reserved: 11;
>> + u64 pfn: 52;
>> + } __packed;
>> +};
>> +
>> u8 __init get_vtl(void);
>> #else
>> static inline u8 get_vtl(void) { return 0; }
>> --
>> 2.43.0
>>
>
> Sashiko AI noted another existing bug in mshv_vtl_init(), which is that
> the error path does kfree(mem_dev) when it should do
> put_device(mem_dev). See the comment in the header of
> device_initialize().
To avoid this series bloating up, I am thinking of taking up these fixes
in a separate series.
Regards,
Naman
^ permalink raw reply
* Re: [PATCH 02/11] Drivers: hv: Move hv_vp_assist_page to common files
From: Naman Jain @ 2026-04-20 15:22 UTC (permalink / raw)
To: Michael Kelley, K . Y . Srinivasan, Haiyang Zhang, Wei Liu,
Dexuan Cui, Long Li, Catalin Marinas, Will Deacon,
Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen,
x86@kernel.org, H . Peter Anvin, Arnd Bergmann, Paul Walmsley,
Palmer Dabbelt, Albert Ou, Alexandre Ghiti
Cc: Marc Zyngier, Timothy Hayes, Lorenzo Pieralisi, mrigendrachaubey,
ssengar@linux.microsoft.com, linux-hyperv@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, linux-arch@vger.kernel.org,
linux-riscv@lists.infradead.org
In-Reply-To: <SN6PR02MB415790977DA40BAD0822DA54D450A@SN6PR02MB4157.namprd02.prod.outlook.com>
On 4/1/2026 10:25 PM, Michael Kelley wrote:
> From: Naman Jain <namjain@linux.microsoft.com> Sent: Monday, March 16, 2026 5:13 AM
>>
>> Move the logic to initialize and export hv_vp_assist_page from x86
>> architecture code to Hyper-V common code to allow it to be used for
>> upcoming arm64 support in MSHV_VTL driver.
>> Note: This change also improves error handling - if VP assist page
>> allocation fails, hyperv_init() now returns early instead of
>> continuing with partial initialization.
>>
>> Signed-off-by: Roman Kisel <romank@linux.microsoft.com>
>> Signed-off-by: Naman Jain <namjain@linux.microsoft.com>
>> ---
>> arch/x86/hyperv/hv_init.c | 88 +---------------------------------
>> drivers/hv/hv_common.c | 88 ++++++++++++++++++++++++++++++++++
>> include/asm-generic/mshyperv.h | 4 ++
>> include/hyperv/hvgdk_mini.h | 2 +
>> 4 files changed, 95 insertions(+), 87 deletions(-)
>>
>> diff --git a/arch/x86/hyperv/hv_init.c b/arch/x86/hyperv/hv_init.c
>> index 323adc93f2dc..75a98b5e451b 100644
>> --- a/arch/x86/hyperv/hv_init.c
>> +++ b/arch/x86/hyperv/hv_init.c
>> @@ -81,9 +81,6 @@ union hv_ghcb * __percpu *hv_ghcb_pg;
>> /* Storage to save the hypercall page temporarily for hibernation */
>> static void *hv_hypercall_pg_saved;
>>
>> -struct hv_vp_assist_page **hv_vp_assist_page;
>> -EXPORT_SYMBOL_GPL(hv_vp_assist_page);
>> -
>> static int hyperv_init_ghcb(void)
>> {
>> u64 ghcb_gpa;
>> @@ -117,59 +114,12 @@ static int hyperv_init_ghcb(void)
>>
>> static int hv_cpu_init(unsigned int cpu)
>> {
>> - union hv_vp_assist_msr_contents msr = { 0 };
>> - struct hv_vp_assist_page **hvp;
>> int ret;
>>
>> ret = hv_common_cpu_init(cpu);
>> if (ret)
>> return ret;
>>
>> - if (!hv_vp_assist_page)
>> - return 0;
>> -
>> - hvp = &hv_vp_assist_page[cpu];
>> - if (hv_root_partition()) {
>> - /*
>> - * For root partition we get the hypervisor provided VP assist
>> - * page, instead of allocating a new page.
>> - */
>> - rdmsrq(HV_X64_MSR_VP_ASSIST_PAGE, msr.as_uint64);
>> - *hvp = memremap(msr.pfn << HV_X64_MSR_VP_ASSIST_PAGE_ADDRESS_SHIFT,
>> - PAGE_SIZE, MEMREMAP_WB);
>> - } else {
>> - /*
>> - * The VP assist page is an "overlay" page (see Hyper-V TLFS's
>> - * Section 5.2.1 "GPA Overlay Pages"). Here it must be zeroed
>> - * out to make sure we always write the EOI MSR in
>> - * hv_apic_eoi_write() *after* the EOI optimization is disabled
>> - * in hv_cpu_die(), otherwise a CPU may not be stopped in the
>> - * case of CPU offlining and the VM will hang.
>> - */
>> - if (!*hvp) {
>> - *hvp = __vmalloc(PAGE_SIZE, GFP_KERNEL | __GFP_ZERO);
>> -
>> - /*
>> - * Hyper-V should never specify a VM that is a Confidential
>> - * VM and also running in the root partition. Root partition
>> - * is blocked to run in Confidential VM. So only decrypt assist
>> - * page in non-root partition here.
>> - */
>> - if (*hvp && !ms_hyperv.paravisor_present && hv_isolation_type_snp()) {
>> - WARN_ON_ONCE(set_memory_decrypted((unsigned long)(*hvp), 1));
>> - memset(*hvp, 0, PAGE_SIZE);
>> - }
>> - }
>> -
>> - if (*hvp)
>> - msr.pfn = vmalloc_to_pfn(*hvp);
>> -
>> - }
>> - if (!WARN_ON(!(*hvp))) {
>> - msr.enable = 1;
>> - wrmsrq(HV_X64_MSR_VP_ASSIST_PAGE, msr.as_uint64);
>> - }
>> -
>> /* Allow Hyper-V stimer vector to be injected from Hypervisor. */
>> if (ms_hyperv.misc_features & HV_STIMER_DIRECT_MODE_AVAILABLE)
>> apic_update_vector(cpu, HYPERV_STIMER0_VECTOR, true);
>> @@ -286,23 +236,6 @@ static int hv_cpu_die(unsigned int cpu)
>>
>> hv_common_cpu_die(cpu);
>>
>> - if (hv_vp_assist_page && hv_vp_assist_page[cpu]) {
>> - union hv_vp_assist_msr_contents msr = { 0 };
>> - if (hv_root_partition()) {
>> - /*
>> - * For root partition the VP assist page is mapped to
>> - * hypervisor provided page, and thus we unmap the
>> - * page here and nullify it, so that in future we have
>> - * correct page address mapped in hv_cpu_init.
>> - */
>> - memunmap(hv_vp_assist_page[cpu]);
>> - hv_vp_assist_page[cpu] = NULL;
>> - rdmsrq(HV_X64_MSR_VP_ASSIST_PAGE, msr.as_uint64);
>> - msr.enable = 0;
>> - }
>> - wrmsrq(HV_X64_MSR_VP_ASSIST_PAGE, msr.as_uint64);
>> - }
>> -
>> if (hv_reenlightenment_cb == NULL)
>> return 0;
>>
>> @@ -460,21 +393,6 @@ void __init hyperv_init(void)
>> if (hv_common_init())
>> return;
>>
>> - /*
>> - * The VP assist page is useless to a TDX guest: the only use we
>> - * would have for it is lazy EOI, which can not be used with TDX.
>> - */
>> - if (hv_isolation_type_tdx())
>> - hv_vp_assist_page = NULL;
>> - else
>> - hv_vp_assist_page = kzalloc_objs(*hv_vp_assist_page, nr_cpu_ids);
>> - if (!hv_vp_assist_page) {
>> - ms_hyperv.hints &= ~HV_X64_ENLIGHTENED_VMCS_RECOMMENDED;
>> -
>> - if (!hv_isolation_type_tdx())
>> - goto common_free;
>> - }
>> -
>> if (ms_hyperv.paravisor_present && hv_isolation_type_snp()) {
>> /* Negotiate GHCB Version. */
>> if (!hv_ghcb_negotiate_protocol())
>> @@ -483,7 +401,7 @@ void __init hyperv_init(void)
>>
>> hv_ghcb_pg = alloc_percpu(union hv_ghcb *);
>> if (!hv_ghcb_pg)
>> - goto free_vp_assist_page;
>> + goto free_ghcb_page;
>> }
>>
>> cpuhp = cpuhp_setup_state(CPUHP_AP_HYPERV_ONLINE, "x86/hyperv_init:online",
>> @@ -613,10 +531,6 @@ void __init hyperv_init(void)
>> cpuhp_remove_state(CPUHP_AP_HYPERV_ONLINE);
>> free_ghcb_page:
>> free_percpu(hv_ghcb_pg);
>> -free_vp_assist_page:
>> - kfree(hv_vp_assist_page);
>> - hv_vp_assist_page = NULL;
>> -common_free:
>> hv_common_free();
>> }
>>
>> diff --git a/drivers/hv/hv_common.c b/drivers/hv/hv_common.c
>> index 6b67ac616789..d1ebc0ebd08f 100644
>> --- a/drivers/hv/hv_common.c
>> +++ b/drivers/hv/hv_common.c
>> @@ -28,7 +28,9 @@
>> #include <linux/slab.h>
>> #include <linux/dma-map-ops.h>
>> #include <linux/set_memory.h>
>> +#include <linux/vmalloc.h>
>> #include <hyperv/hvhdk.h>
>> +#include <hyperv/hvgdk.h>
>> #include <asm/mshyperv.h>
>
> Need to add
>
> #include <linux/io.h>
>
> because of the memremap() and related calls that have been added.
> io.h is probably being #include'd indirectly, but it is better to #include
> it directly.
>
Acked.
>>
>> u64 hv_current_partition_id = HV_PARTITION_ID_SELF;
>> @@ -78,6 +80,8 @@ static struct ctl_table_header *hv_ctl_table_hdr;
>> u8 * __percpu *hv_synic_eventring_tail;
>> EXPORT_SYMBOL_GPL(hv_synic_eventring_tail);
>>
>> +struct hv_vp_assist_page **hv_vp_assist_page;
>> +EXPORT_SYMBOL_GPL(hv_vp_assist_page);
>> /*
>> * Hyper-V specific initialization and shutdown code that is
>> * common across all architectures. Called from architecture
>> @@ -92,6 +96,9 @@ void __init hv_common_free(void)
>> if (ms_hyperv.misc_features & HV_FEATURE_GUEST_CRASH_MSR_AVAILABLE)
>> hv_kmsg_dump_unregister();
>>
>> + kfree(hv_vp_assist_page);
>> + hv_vp_assist_page = NULL;
>> +
>> kfree(hv_vp_index);
>> hv_vp_index = NULL;
>>
>> @@ -394,6 +401,23 @@ int __init hv_common_init(void)
>> for (i = 0; i < nr_cpu_ids; i++)
>> hv_vp_index[i] = VP_INVAL;
>>
>> + /*
>> + * The VP assist page is useless to a TDX guest: the only use we
>> + * would have for it is lazy EOI, which can not be used with TDX.
>> + */
>> + if (hv_isolation_type_tdx()) {
>> + hv_vp_assist_page = NULL;
>> + } else {
>> + hv_vp_assist_page = kzalloc_objs(*hv_vp_assist_page, nr_cpu_ids);
>> + if (!hv_vp_assist_page) {
>> +#ifdef CONFIG_X86_64
>> + ms_hyperv.hints &= ~HV_X64_ENLIGHTENED_VMCS_RECOMMENDED;
>> +#endif
>> + hv_common_free();
>> + return -ENOMEM;
>
> Given that "failure to allocate memory" now returns an error that is
> essentially fatal to hyperv_init(), is it still necessary to clear the flag in
> ms_hyperv.hints? I'd love to see that #ifdef go away. It's the only
> #ifdef in hv_common.c, and I had worked hard in the past to avoid
> such #ifdef's. :-)
Yes, this particular block can be removed, and I will remove it in v2.
The other thing pointed out in Sashiko's AI review was having this
if-def block in tdx case after setting hv_vp_assist_page to NULL. This
is to maintain parity with existing code. That's the reason, I will need
to add it back there.
>
>> + }
>> + }
>> +
>> return 0;
>> }
>>
>> @@ -471,6 +495,8 @@ void __init ms_hyperv_late_init(void)
>>
>> int hv_common_cpu_init(unsigned int cpu)
>> {
>> + union hv_vp_assist_msr_contents msr = { 0 };
>> + struct hv_vp_assist_page **hvp;
>> void **inputarg, **outputarg;
>> u8 **synic_eventring_tail;
>> u64 msr_vp_index;
>> @@ -542,6 +568,50 @@ int hv_common_cpu_init(unsigned int cpu)
>> ret = -ENOMEM;
>
> The Sashiko AI comment here about a bug when ret is set to -ENOMEM
> seems valid to me.
>
I'm planning to simply "return -ENOMEM" here.
>> }
>>
>> + if (!hv_vp_assist_page)
>> + return ret;
>> +
>> + hvp = &hv_vp_assist_page[cpu];
>> + if (hv_root_partition()) {
>> + /*
>> + * For root partition we get the hypervisor provided VP assist
>> + * page, instead of allocating a new page.
>> + */
>> + msr.as_uint64 = hv_get_msr(HV_SYN_REG_VP_ASSIST_PAGE);
>> + *hvp = memremap(msr.pfn << HV_VP_ASSIST_PAGE_ADDRESS_SHIFT,
>> + PAGE_SIZE, MEMREMAP_WB);
>
> The Sashiko AI comment about potentially memremap'ing 64K instead of 4K can
> be ignored. We know that the root partition can only run with a 4K page size,
> and that is enforced in drivers/hv/Kconfig.
>
I am thinking of adding this config dependency (PAGE_SIZE_4KB) in the
Kconfig patch in this series, to MSHV_VTL as well. We are also using
only 4KB as page size. This should prevent all of PAGE_SIZE Sachiko
issues. I am also replacing PAGE_SIZE with HV_HYP_PAGE_SIZE in all
places. Hope that is fine?
> HV_VP_ASSIST_PAGE_ADDRESS_SHIFT is defined in asm-generic/mshyperv.h.
> But there is also HV_X64_MSR_VP_ASSIST_PAGE_ADDRESS_SHIFT in hvgdk_mini.h.
> Is there a clean way to eliminate the duplication?
Although both these architectures are using same value - 12, I was
hesitant to use x64 register for ARM64. I will move arch based
definition of HV_VP_ASSIST_PAGE_ADDRESS_SHIFT to hvgdk_mini.h and remove
it from asm-generic/mshyperv.h.
>
>> + } else {
>> + /*
>> + * The VP assist page is an "overlay" page (see Hyper-V TLFS's
>> + * Section 5.2.1 "GPA Overlay Pages"). Here it must be zeroed
>> + * out to make sure we always write the EOI MSR in
>> + * hv_apic_eoi_write() *after* the EOI optimization is disabled
>> + * in hv_cpu_die(), otherwise a CPU may not be stopped in the
>> + * case of CPU offlining and the VM will hang.
>> + */
>
> Somewhere in the comment above, I'd suggest adding a short "on x86/x64"
> qualifier, as the comment doesn't apply on arm64 since it doesn't support
> the AutoEOI optimization. Maybe "Here it must be zeroed out to make sure
> that on x86/x64 we always write the EOI MSR in ....".
Acked. I will add it.
>
>> + if (!*hvp) {
>> + *hvp = __vmalloc(PAGE_SIZE, GFP_KERNEL | __GFP_ZERO);
>
> The Sashiko AI comment about using "flags" instead of GFP_KERNEL seems valid.
Acked.
>
>> +
>> + /*
>> + * Hyper-V should never specify a VM that is a Confidential
>> + * VM and also running in the root partition. Root partition
>> + * is blocked to run in Confidential VM. So only decrypt assist
>> + * page in non-root partition here.
>> + */
>> + if (*hvp && !ms_hyperv.paravisor_present && hv_isolation_type_snp()) {
>> + WARN_ON_ONCE(set_memory_decrypted((unsigned long)(*hvp), 1));
>> + memset(*hvp, 0, PAGE_SIZE);
>> + }
>> + }
>> +
>> + if (*hvp)
>> + msr.pfn = vmalloc_to_pfn(*hvp);
>
> The Sashiko AI comment about page size here seems valid. But what are the rules
> about arm64 page sizes that are supported for VTL2, and how does they relate
> to VTL0 allowing 4K, 16K, and 64K page size? What combinations are allowed?
> For example, can a VTL2 built with 4K page size run with a VTL0 built with
> 64K page size? It would be nice to have the rules recorded somewhere in a
> code comment, but I'm not sure of the best place.
>
VTL2 uses 4k page size only. This can be enforced with a Kconfig change
in next version. As and when other page size support is added in ARM64
for MSHV_VTL, this change can be removed.
Regarding support of VTL0 kernel page sizes, page size in VTL2 is of no
impact to it.
> But regardless of the rules, I'd suggest future-proofing by using
> "page_to_hvpfn(vmalloc_to_page(*hvp))" so that the PFN generated is always
> in terms of 4K page size as the Hyper-V host expects.
Acked. Will try this and make the changes.
>
>> + }
>> + if (!WARN_ON(!(*hvp))) {
>> + msr.enable = 1;
>> + hv_set_msr(HV_SYN_REG_VP_ASSIST_PAGE, msr.as_uint64);
>> + }
>> +
>> return ret;
>> }
>>
>> @@ -566,6 +636,24 @@ int hv_common_cpu_die(unsigned int cpu)
>> *synic_eventring_tail = NULL;
>> }
>>
>> + if (hv_vp_assist_page && hv_vp_assist_page[cpu]) {
>> + union hv_vp_assist_msr_contents msr = { 0 };
>> +
>> + if (hv_root_partition()) {
>> + /*
>> + * For root partition the VP assist page is mapped to
>> + * hypervisor provided page, and thus we unmap the
>> + * page here and nullify it, so that in future we have
>> + * correct page address mapped in hv_cpu_init.
>> + */
>> + memunmap(hv_vp_assist_page[cpu]);
>> + hv_vp_assist_page[cpu] = NULL;
>> + msr.as_uint64 = hv_get_msr(HV_SYN_REG_VP_ASSIST_PAGE);
>> + msr.enable = 0;
>> + }
>> + hv_set_msr(HV_SYN_REG_VP_ASSIST_PAGE, msr.as_uint64);
>> + }
>> +
>> return 0;
>> }
>>
>> diff --git a/include/asm-generic/mshyperv.h b/include/asm-generic/mshyperv.h
>> index d37b68238c97..108f135d4fd9 100644
>> --- a/include/asm-generic/mshyperv.h
>> +++ b/include/asm-generic/mshyperv.h
>> @@ -25,6 +25,7 @@
>> #include <linux/nmi.h>
>> #include <asm/ptrace.h>
>> #include <hyperv/hvhdk.h>
>> +#include <hyperv/hvgdk.h>
>>
>> #define VTPM_BASE_ADDRESS 0xfed40000
>>
>> @@ -299,6 +300,8 @@ do { \
>> #define hv_status_debug(status, fmt, ...) \
>> hv_status_printk(debug, status, fmt, ##__VA_ARGS__)
>>
>> +extern struct hv_vp_assist_page **hv_vp_assist_page;
>
> This "extern" statement is added here so it is visible to both x86/x64 and arm64.
> And that's correct.
>
> But there is still some VP assist page stuff that has been left in the arch/x86
> version of mshyperv.h. That other stuff, including the inline function
> hv_get_vp_assist_page(), should also be moved to asm-generic/mshyperv.h.
> Given that the VP assist page support is now fully generic and not x86/x64
> specific, it shouldn't occur anywhere in the arch/x86 version of mshyperv.h.
Will move the remaining code.
>
>> +
>> const char *hv_result_to_string(u64 hv_status);
>> int hv_result_to_errno(u64 status);
>> void hyperv_report_panic(struct pt_regs *regs, long err, bool in_die);
>> @@ -377,6 +380,7 @@ static inline int hv_deposit_memory(u64 partition_id, u64 status)
>> return hv_deposit_memory_node(NUMA_NO_NODE, partition_id, status);
>> }
>>
>> +#define HV_VP_ASSIST_PAGE_ADDRESS_SHIFT 12
>> #if IS_ENABLED(CONFIG_HYPERV_VTL_MODE)
>> u8 __init get_vtl(void);
>> #else
>> diff --git a/include/hyperv/hvgdk_mini.h b/include/hyperv/hvgdk_mini.h
>> index 056ef7b6b360..be697ddb211a 100644
>> --- a/include/hyperv/hvgdk_mini.h
>> +++ b/include/hyperv/hvgdk_mini.h
>> @@ -149,6 +149,7 @@ struct hv_u128 {
>> #define HV_X64_MSR_VP_ASSIST_PAGE_ADDRESS_SHIFT 12
>> #define HV_X64_MSR_VP_ASSIST_PAGE_ADDRESS_MASK \
>> (~((1ull << HV_X64_MSR_VP_ASSIST_PAGE_ADDRESS_SHIFT) - 1))
>> +#define HV_SYN_REG_VP_ASSIST_PAGE (HV_X64_MSR_VP_ASSIST_PAGE)
>>
>> /* Hyper-V Enlightened VMCS version mask in nested features CPUID */
>> #define HV_X64_ENLIGHTENED_VMCS_VERSION 0xff
>> @@ -1185,6 +1186,7 @@ enum hv_register_name {
>>
>> #define HV_MSR_STIMER0_CONFIG (HV_REGISTER_STIMER0_CONFIG)
>> #define HV_MSR_STIMER0_COUNT (HV_REGISTER_STIMER0_COUNT)
>> +#define HV_SYN_REG_VP_ASSIST_PAGE (HV_REGISTER_VP_ASSIST_PAGE)
>
> This defines a new register name prefix "HV_SYN_REG_" that isn't used
> anywhere else. The prefixes for Hyper-V register names are already complex
> to account to x86/x64 and arm64 differences, and the fact the x86/x64 has
> synthetic MSRs, while arm64 does not. So introducing another prefix is
> undesirable. Couldn't this just be HV_MSR_VP_ASSIST_PAGE using the
> same structure as HV_MSR_STIMER0_COUNT (for example)?
>
Will rename it to HV_MSR_VP_ASSIST_PAGE in all places.
>>
>> #endif /* CONFIG_ARM64 */
>>
>> --
>> 2.43.0
>>
Thank you so much for thoroughly reviwing this Michael.
Regards,
Naman
^ permalink raw reply
* Re: [PATCH] arm64: dts: exynos850: Add syscon-poweroff node
From: Krzysztof Kozlowski @ 2026-04-20 15:20 UTC (permalink / raw)
To: Alexey Klimov, Sam Protsenko, Krzysztof Kozlowski
Cc: linux-samsung-soc, linux-arm-kernel, devicetree, linux-kernel,
Rob Herring, Conor Dooley, Alim Akhtar
In-Reply-To: <b9117d52-1a12-480b-a762-31d3eab6b827@kernel.org>
On 20/04/2026 17:18, Krzysztof Kozlowski wrote:
> On 20/04/2026 17:04, Alexey Klimov wrote:
>> On Wed Mar 25, 2026 at 12:26 AM GMT, Alexey Klimov wrote:
>>> Without poweroff node Exynos850-based board continue to draw current
>>> (around ~60 mA with my test setup) after poweroff. Kernel also reports
>>> different lockup problems and RCU stalls warnings continuosly after
>>> last kernel messages about hardware being switched off.
>>> Turns out we missed a write to PMU's PS_HOLD_CONTROL (PMU + 0x30c)
>>> register that actually switches the SoC off.
>>>
>>> Add poweroff node that implements this.
>>>
>>> With this change the current draw after power off is in range of few
>>> milliampers and lockup messages are no more.
>>>
>>> Signed-off-by: Alexey Klimov <alexey.klimov@linaro.org>
>>> ---
>>> arch/arm64/boot/dts/exynos/exynos850.dtsi | 7 +++++++
>>
>> Any feedback on this?
>
> You posted it right before closing tree, so this was waiting for a few
> days for anyone to chime in and then tree is closed. It's merge window
> now, so I don't review anything. Nothing new here...
... and the pull to SoC actually happened before. It's public, so you
could check that.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH] arm64: dts: exynos850: Add syscon-poweroff node
From: Krzysztof Kozlowski @ 2026-04-20 15:18 UTC (permalink / raw)
To: Alexey Klimov, Sam Protsenko, Krzysztof Kozlowski
Cc: linux-samsung-soc, linux-arm-kernel, devicetree, linux-kernel,
Rob Herring, Conor Dooley, Alim Akhtar
In-Reply-To: <DHY2P02B6E6H.J79TDOADC4BS@linaro.org>
On 20/04/2026 17:04, Alexey Klimov wrote:
> On Wed Mar 25, 2026 at 12:26 AM GMT, Alexey Klimov wrote:
>> Without poweroff node Exynos850-based board continue to draw current
>> (around ~60 mA with my test setup) after poweroff. Kernel also reports
>> different lockup problems and RCU stalls warnings continuosly after
>> last kernel messages about hardware being switched off.
>> Turns out we missed a write to PMU's PS_HOLD_CONTROL (PMU + 0x30c)
>> register that actually switches the SoC off.
>>
>> Add poweroff node that implements this.
>>
>> With this change the current draw after power off is in range of few
>> milliampers and lockup messages are no more.
>>
>> Signed-off-by: Alexey Klimov <alexey.klimov@linaro.org>
>> ---
>> arch/arm64/boot/dts/exynos/exynos850.dtsi | 7 +++++++
>
> Any feedback on this?
You posted it right before closing tree, so this was waiting for a few
days for anyone to chime in and then tree is closed. It's merge window
now, so I don't review anything. Nothing new here...
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 05/40] arm64: dts: rockchip: Add frl-enable-gpios to rk3576-luckfox-core3576
From: Heiko Stuebner @ 2026-04-20 15:18 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Cristian Ciocaltea
Cc: kernel, devicetree, linux-arm-kernel, linux-rockchip,
linux-kernel
In-Reply-To: <401a020f-ca5d-4c7d-941e-f0288e144357@collabora.com>
Am Montag, 20. April 2026, 13:00:25 Mitteleuropäische Sommerzeit schrieb Cristian Ciocaltea:
> Hi Heiko,
>
> On 4/18/26 2:12 AM, Heiko Stuebner wrote:
> > Hi Cristian,
> >
> > Am Freitag, 17. April 2026, 18:34:17 Mitteleuropäische Sommerzeit schrieb Cristian Ciocaltea:
> >> On 4/17/26 2:32 PM, Heiko Stuebner wrote:
> >>> the comments below apply sort of to all patches in that series.
> >>>
> >>> Am Freitag, 17. April 2026, 11:24:39 Mitteleuropäische Sommerzeit schrieb Cristian Ciocaltea:
> >>>> The board exposes the GPIO4_C6 line to control the voltage bias on the
> >>>> HDMI data lines. It must be asserted when operating in HDMI 2.1 FRL
> >>>> mode and deasserted for HDMI 1.4/2.0 TMDS mode.
> >>>>
> >>>> Wire up the HDMI node to the GPIO line using the frl-enable-gpios
> >>>> property and drop the line from the vcc_5v0_hdmi regulator to allow
> >>>> adjusting the bias when transitioning between TMDS and FRL operating
> >>>> modes.
>
> [...]
>
> >>>
> >>>
> >>>> @@ -231,6 +228,8 @@ &gpu {
> >>>> };
> >>>>
> >>>> &hdmi {
> >>>> + pinctrl-0 = <&hdmi_txm0_pins &hdmi_tx_scl &hdmi_tx_sda &hdmi_frl_en>;
> >>>> + frl-enable-gpios = <&gpio4 RK_PC6 GPIO_ACTIVE_LOW>;
> >>>
> >>> this should be sorted the other way around I think.
> >>>
> >>> Also please provide a pinctrl-names property too. If for whatever reason
> >>> the dw-hdmi aquires a 2nd pinctrl state in the future, this makes sure
> >>> board DTs are staying in the "old" compatible mode until they are adapted.
> >>
> >> Just to make sure I fully understand, the convention is that
> >>
> >> pinctrl-names = "default";
> >>
> >> should be always provided, even when the node overrides an existing pinctrl-0
> >> property?
> >>
> >> E.g. in rk3576.dtsi we have:
> >>
> >> hdmi: hdmi@27da0000 {
> >> ...
> >> pinctrl-names = "default";
> >> pinctrl-0 = <&hdmi_txm0_pins &hdmi_tx_scl &hdmi_tx_sda>;
> >> ...
> >> }
> >>
> >> Hence I omitted pinctrl-names which doesn't change and just appended
> >> &hdmi_frl_en to pinctrl-0's original value.
> >
> > correct, please always provide a pinctrl-names entry when setting a new
> > pinctrl-0 .
> >
> > The background is, imagine you have a base:
> >
> > pinctrl-names = "default";
> > pinstrl-0 = <....>;
> >
> > and override pinctrl-0 in a board.
> >
> > Now a newer binding introduces a 2nd pinctrl state "foo". Of course
> > we're backwards compatible, and both are valid and the driver checks
> > what states are defined.
> >
> > So the base sets:
> > pinctrl-names = "default", "foo";
> > pinctrl-0 = <...>;
> > pinctrl-1 = <...>;
> >
> > in your (old) board you override pinctrl-0, but the driver still sees
> > the new variant with 2 pinctrl states, where it should've stayed with
> > the legacy 1-state, until the board-dts might get adapted in the future.
> >
> >
> > And I know, we're likely not doing that everywhere, and also in most
> > cases it won't really matter, but still it is safer and sets the better
> > precedent :-) .
>
> Thanks for the detailed explanation, that clears things up!
>
> There are several other nodes (e.g. i2c, pwm, uart) that also lack
> pinctrl-names despite providing pinctrl-0 - I can address those in a
> separate patch.
As said above it is an ideal to aspire to (having -names together with
defining states), but if you want to add the "missing" -names,
go ahead :-) .
> I also noticed an inconsistency in property ordering: some nodes place
> pinctrl-names before pinctrl-<n> and others after. I have always used
> the former, but we should probably prefer the latter to stay consistent
> with how clocks, resets, phys, etc. are ordered.
>
> Thoughts?
There is sort of a "conflict" between regular ordering and possibly
better readability. I.e. the dt-writing guidelines propose alphabetical
ordering which I guess puts numbers before letters.
On the other hand the semantic definition of list the states and then
define them (names first, -0, -1, etc second) looks more sensible from
a understanding standpoint.
But there we'd end up with special rules, so just sticking to the
base sorting will cause less friction in the long run I think.
Aka, -0, -1 first; -names after, follows the main sorting suggestions
so it's easy to explain to newcomers.
But please don't re-sort existing entries :-)
Heiko
^ permalink raw reply
* Re: [PATCH] ACPI: arm64: cpuidle: Tolerate platforms with no deep PSCI idle states
From: Sudeep Holla @ 2026-04-20 15:12 UTC (permalink / raw)
To: Breno Leitao
Cc: Lorenzo Pieralisi, Hanjun Guo, Sudeep Holla, Catalin Marinas,
Will Deacon, Rafael J. Wysocki, Len Brown, Huisong Li,
Rafael J. Wysocki, linux-acpi, linux-arm-kernel, linux-kernel,
pjaroszynski, rmikey, kernel-team, stable
In-Reply-To: <20260420-ffh-v1-1-6b4c10fec442@debian.org>
On Mon, Apr 20, 2026 at 02:27:13AM -0700, Breno Leitao wrote:
> Commit cac173bea57d ("ACPI: processor: idle: Rework the handling of
> acpi_processor_ffh_lpi_probe()") moved the acpi_processor_ffh_lpi_probe()
> call from acpi_processor_setup_cpuidle_dev(), where its return value was
> ignored, to acpi_processor_get_power_info(), where it is now treated as
> a hard failure. As a result, platforms where psci_acpi_cpu_init_idle()
> returned -ENODEV stopped registering any cpuidle states, forcing CPUs to
> busy-poll when idle.
>
> On NVIDIA Grace (aarch64) systems with PSCIv1.1, pr->power.count is 1
> (only WFI, no deep PSCI states beyond it), so the previous
> "count = pr->power.count - 1; if (count <= 0) return -ENODEV;" check
> returned -ENODEV for all 72 CPUs and disabled cpuidle entirely.
>
> The lpi_states count is already validated in acpi_processor_get_lpi_info(),
> so the check here is redundant. Simplify the loop to iterate over
> lpi_states[1..power.count). When only WFI is present, the loop body
> simply does not execute and the function returns 0, which is the correct
> outcome: there is nothing to validate for FFH and no error to report.
>
> Suggested-by: Huisong Li <lihuisong@huawei.com>
> Cc: stable@vger.kernel.org
> Fixes: cac173bea57d ("ACPI: processor: idle: Rework the handling of acpi_processor_ffh_lpi_probe()")
> Signed-off-by: Breno Leitao <leitao@debian.org>
> ---
> drivers/acpi/arm64/cpuidle.c | 10 +++-------
> 1 file changed, 3 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/acpi/arm64/cpuidle.c b/drivers/acpi/arm64/cpuidle.c
> index 801f9c4501425..c68a5db8ebba8 100644
> --- a/drivers/acpi/arm64/cpuidle.c
> +++ b/drivers/acpi/arm64/cpuidle.c
> @@ -16,7 +16,7 @@
>
> static int psci_acpi_cpu_init_idle(unsigned int cpu)
> {
> - int i, count;
> + int i;
> struct acpi_lpi_state *lpi;
> struct acpi_processor *pr = per_cpu(processors, cpu);
>
> @@ -30,14 +30,10 @@ static int psci_acpi_cpu_init_idle(unsigned int cpu)
> if (!psci_ops.cpu_suspend)
> return -EOPNOTSUPP;
>
> - count = pr->power.count - 1;
> - if (count <= 0)
> - return -ENODEV;
> -
Does it make sense to retain this check like
if (pr->power.count < 1)
return -EINVAL;
Though I see the assignment to pr->power.count in drivers/acpi/processor_idle.c
is through unsigned int. So I am fine even without the above check.
Reviewed-by: Sudeep Holla <sudeep.holla@kernel.org>
--
Regards,
Sudeep
^ permalink raw reply
* Re: [PATCH 00/40] arm64: dts: rockchip: Wire up frl-enable-gpios for RK3576/RK3588 boards
From: Heiko Stuebner @ 2026-04-20 15:08 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Cristian Ciocaltea
Cc: kernel, devicetree, linux-arm-kernel, linux-rockchip,
linux-kernel
In-Reply-To: <66f9574c-8dff-4de2-bf54-20f1c1e64c24@collabora.com>
Hi Cristian,
Am Montag, 20. April 2026, 13:10:27 Mitteleuropäische Sommerzeit schrieb Cristian Ciocaltea:
> On 4/18/26 2:18 AM, Heiko Stuebner wrote:
> > Am Freitag, 17. April 2026, 19:55:17 Mitteleuropäische Sommerzeit schrieb Cristian Ciocaltea:
> >> On 4/17/26 2:34 PM, Heiko Stuebner wrote:
> >>> Am Freitag, 17. April 2026, 11:24:34 Mitteleuropäische Sommerzeit schrieb Cristian Ciocaltea:
> >>>
> >>> [...]
> >>>
> >>>> Cristian Ciocaltea (40):
> >>>> arm64: dts: rockchip: Add frl-enable-gpios to rk3576-100ask-dshanpi-a1
> >>>> arm64: dts: rockchip: Add frl-enable-gpios to rk3576-armsom-sige5
> >>>> arm64: dts: rockchip: Add frl-enable-gpios to rk3576-evb1-v10
> >>>> arm64: dts: rockchip: Add frl-enable-gpios to rk3576-evb2-v10
> >>>> arm64: dts: rockchip: Add frl-enable-gpios to rk3576-luckfox-core3576
> >>>> arm64: dts: rockchip: Add frl-enable-gpios to rk3576-nanopi-m5
> >>>> arm64: dts: rockchip: Add frl-enable-gpios to rk3576-nanopi-r76s
> >>>> arm64: dts: rockchip: Add frl-enable-gpios to rk3576-roc-pc
> >>>> arm64: dts: rockchip: Add frl-enable-gpios to rk3576-rock-4d
> >>>
> >>> I do think one patch per SoC (rk3576, rk3588, rk3588s) would make more
> >>> sense, because these patches really are mostly identical :-)
> >>
> >> Yeah, apologies for the large number of patches, I went this way to allow
> >> per-board reviews. As previously noted, I tried to identify the GPIO pins from
> >> multiple sources, so I'm not entirely sure about the accuracy in every case.
> >>
> >> Would it be preferable to squash the patches per SoC and board vendor, instead?
> >
> > I really would just do it per soc .. so 3 patches. That is a size that is
> > still reviewable for people, who can then check for their board.
> >
> > If the patch is labeled "Add frl-enable-gpios for all RK3588s boards", I
> > do expect people to notice it the same as "oh _my_ board gets changed".
> > ("all" could also be "most" :-) ).
>
> Ack.
>
> I would still keep the more invasive changes — such as those touching
> the regulator hacks — in separate patches, though.
sure, that sounds perfectly reasonable :-) .
Heiko
^ permalink raw reply
* Re: [RFC PATCH 4/4] firmware: arm_ffa: check pkvm initailised when initailise ffa driver
From: Yeoreum Yun @ 2026-04-20 15:04 UTC (permalink / raw)
To: Sebastian Ene
Cc: Marc Zyngier, linux-security-module, linux-kernel,
linux-integrity, linux-arm-kernel, kvmarm, paul, jmorris, serge,
zohar, roberto.sassu, dmitry.kasatkin, eric.snowberg, peterhuewe,
jarkko, jgg, sudeep.holla, oupton, joey.gouly, suzuki.poulose,
yuzenghui, catalin.marinas, will
In-Reply-To: <aeY2M3v97c00JjFe@google.com>
On Mon, Apr 20, 2026 at 02:20:35PM +0000, Sebastian Ene wrote:
> On Mon, Apr 20, 2026 at 01:46:47PM +0100, Marc Zyngier wrote:
> > On Mon, 20 Apr 2026 13:32:32 +0100,
> > Sebastian Ene <sebastianene@google.com> wrote:
> > >
> > > On Fri, Apr 17, 2026 at 06:57:59PM +0100, Yeoreum Yun wrote:
> > >
> > > Hello Yeoreum,
> > >
> > >
> > > > When pKVM is enabled, the FF-A driver must be initialized after pKVM.
> > > > Otherwise, pKVM cannot negotiate the FF-A version or
> > > > obtain RX/TX buffer information, leading to failures in FF-A calls.
> > >
> > > At the moment this already happens after you move back ffa_init() to
> > > device_initcall().
> >
> > But relying on this sort of ordering is just making things more
> > fragile.
> >
>
> Thanks for letting me know. Since this is not a solid construct we will have
> to change the driver init code to come after pKVM in this case.
>
> > >
> > > >
> > > > During FF-A driver initialization, check whether pKVM has been initialized.
> > > > If not, defer probing of the FF-A driver.
> > > >
> > >
> > > I don't think you need to add this dependency. pKVM is
> > > installed through KVM's module_init() which ends up calling hyp_ffa_init() to
> > > do the proxy initialization. The ARM-FFA driver comes after it (since
> > > pKVM is arch specific code). We don't have to call finalize_pkvm(..) to
> > > be able to handle smc(FF-A) calls in the hyp-proxy.
> >
> > You do. Without the finalisation, SMCs are not trapped by EL2.
> >
> > And even if it did, relying on such hack is just wrong.
> >
>
> That makes it an even stronger argument to move the driver init at a
> later stage. I was relying on this to trap early ff-a when the
> ARM FF-A driver was used.
I don’t think moving the FF-A driver initialization to a later stage is
a viable solution. For example, even if it is moved to device_initcall_sync,
it still relies on fragile ordering.
Similarly, moving it to late_initcall is problematic.
Since deferred_probe_initcall() runs at the same level, if it is invoked first,
devices that depend on FF-A (e.g. tpm_ffa_crb) may not be probed correctly,
leading to deferred devices not being handled properly.
Therefore, the FF-A driver should be able to detect when pKVM has been
initialized and perform its initialization accordingly otherwise,
just relying on the trap after kvm_arm_initialised.
--
Sincerely,
Yeoreum Yun
^ permalink raw reply
* Re: [PATCH] arm64: dts: exynos850: Add syscon-poweroff node
From: Alexey Klimov @ 2026-04-20 15:04 UTC (permalink / raw)
To: Sam Protsenko, Krzysztof Kozlowski
Cc: linux-samsung-soc, linux-arm-kernel, devicetree, linux-kernel,
Rob Herring, Conor Dooley, Alim Akhtar
In-Reply-To: <20260325-exynos850-poweroff-v1-1-34c19c06e74d@linaro.org>
On Wed Mar 25, 2026 at 12:26 AM GMT, Alexey Klimov wrote:
> Without poweroff node Exynos850-based board continue to draw current
> (around ~60 mA with my test setup) after poweroff. Kernel also reports
> different lockup problems and RCU stalls warnings continuosly after
> last kernel messages about hardware being switched off.
> Turns out we missed a write to PMU's PS_HOLD_CONTROL (PMU + 0x30c)
> register that actually switches the SoC off.
>
> Add poweroff node that implements this.
>
> With this change the current draw after power off is in range of few
> milliampers and lockup messages are no more.
>
> Signed-off-by: Alexey Klimov <alexey.klimov@linaro.org>
> ---
> arch/arm64/boot/dts/exynos/exynos850.dtsi | 7 +++++++
Any feedback on this?
BR,
Alexey
^ permalink raw reply
* Re: [PATCH v5 4/4] Input: charlieplex_keypad: add GPIO charlieplex keypad
From: Hugo Villeneuve @ 2026-04-20 15:01 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: robin, andy, geert, robh, krzk+dt, conor+dt, hvilleneuve,
mkorpershoek, matthias.bgg, angelogioacchino.delregno, lee,
alexander.sverdlin, marek.vasut, akurz, devicetree, linux-kernel,
linux-input, linux-arm-kernel, linux-mediatek
In-Reply-To: <aeWtDA7snjJmiF9K@google.com>
Hi Dmitry,
On Sun, 19 Apr 2026 21:47:40 -0700
Dmitry Torokhov <dmitry.torokhov@gmail.com> wrote:
> Hi Hugo,
>
> On Thu, Mar 12, 2026 at 02:00:58PM -0400, Hugo Villeneuve wrote:
> > +
> > +static void charlieplex_keypad_report_key(struct input_dev *input)
> > +{
> > + struct charlieplex_keypad *keypad = input_get_drvdata(input);
> > + const unsigned short *keycodes = input->keycode;
> > +
> > + if (keypad->current_code > 0) {
> > + input_event(input, EV_MSC, MSC_SCAN, keypad->current_code);
> > + input_report_key(input, keycodes[keypad->current_code], 0);
>
> This needs input_sync() as otherwise userspace is free to only recognize
> the last MSC_SCAN event.
Ok, now I get it, my code would have been be working only if it was an
if/else.
>
> > + }
> > +
> > + if (keypad->debounce_code) {
> > + input_event(input, EV_MSC, MSC_SCAN, keypad->debounce_code);
> > + input_report_key(input, keycodes[keypad->debounce_code], 1);
> > + }
> > +
> > + input_sync(input);
> > + keypad->current_code = keypad->debounce_code;
> > +}
> > +
> > +static void charlieplex_keypad_check_switch_change(struct input_dev *input,
> > + int code)
> > +{
> > + struct charlieplex_keypad *keypad = input_get_drvdata(input);
> > +
> > + if (code != keypad->debounce_code) {
> > + keypad->debounce_count = 0;
> > + keypad->debounce_code = code;
> > + } else if (keypad->debounce_count < keypad->debounce_threshold) {
>
> This does not work if debouncing is disabled (debounce threshold is 0).
Yes.
>
> > + keypad->debounce_count++;
> > +
> > + if (keypad->debounce_count >= keypad->debounce_threshold &&
> > + keypad->debounce_code != keypad->current_code)
> > + charlieplex_keypad_report_key(input);
> > + }
> > +}
> > +
> > +static void charlieplex_keypad_poll(struct input_dev *input)
> > +{
> > + struct charlieplex_keypad *keypad = input_get_drvdata(input);
> > + int code;
> > +
> > + code = 0;
> > + for (unsigned int oline = 0; oline < keypad->nlines; oline++) {
> > + DECLARE_BITMAP(values, MATRIX_MAX_ROWS);
> > + int err;
> > +
> > + /* Activate only one line as output at a time. */
> > + gpiod_direction_output(keypad->line_gpios->desc[oline], 1);
> > +
> > + if (keypad->settling_time_us)
> > + fsleep(keypad->settling_time_us);
> > +
> > + /* Read input on all other lines. */
> > + err = gpiod_get_array_value_cansleep(keypad->line_gpios->ndescs,
> > + keypad->line_gpios->desc,
> > + keypad->line_gpios->info, values);
> > + if (err)
> > + return;
>
> We need to deactivate the line on error too.
Yer, good catch.
>
> > +
> > + for (unsigned int iline = 0; iline < keypad->nlines; iline++) {
> > + if (iline == oline)
> > + continue; /* Do not read active output line. */
> > +
> > + /* Check if GPIO is asserted. */
> > + if (test_bit(iline, values)) {
> > + code = MATRIX_SCAN_CODE(oline, iline,
> > + get_count_order(keypad->nlines));
> > + /*
> > + * Exit loop immediately since we cannot detect
> > + * more than one key press at a time.
> > + */
> > + break;
> > + }
> > + }
> > +
> > + gpiod_direction_input(keypad->line_gpios->desc[oline]);
> > +
> > + if (code)
> > + break;
> > + }
> > +
> > + charlieplex_keypad_check_switch_change(input, code);
> > +}
> > +
> > +static int charlieplex_keypad_init_gpio(struct platform_device *pdev,
> > + struct charlieplex_keypad *keypad)
> > +{
> > + char **pin_names;
> > + char label[32];
> > +
> > + snprintf(label, sizeof(label), "%s-pin", pdev->name);
> > +
> > + keypad->line_gpios = devm_gpiod_get_array(&pdev->dev, "line", GPIOD_IN);
> > + if (IS_ERR(keypad->line_gpios))
> > + return PTR_ERR(keypad->line_gpios);
> > +
> > + keypad->nlines = keypad->line_gpios->ndescs;
> > +
> > + if (keypad->nlines > MATRIX_MAX_ROWS)
> > + return -EINVAL;
> > +
> > + pin_names = devm_kasprintf_strarray(&pdev->dev, label, keypad->nlines);
> > + if (IS_ERR(pin_names))
> > + return PTR_ERR(pin_names);
> > +
> > + for (unsigned int i = 0; i < keypad->line_gpios->ndescs; i++)
> > + gpiod_set_consumer_name(keypad->line_gpios->desc[i], pin_names[i]);
> > +
> > + return 0;
> > +}
> > +
> > +static int charlieplex_keypad_probe(struct platform_device *pdev)
> > +{
> > + struct charlieplex_keypad *keypad;
> > + unsigned int debounce_interval_ms;
> > + unsigned int poll_interval_ms;
> > + struct input_dev *input_dev;
> > + int err;
> > +
> > + keypad = devm_kzalloc(&pdev->dev, sizeof(*keypad), GFP_KERNEL);
> > + if (!keypad)
> > + return -ENOMEM;
> > +
> > + input_dev = devm_input_allocate_device(&pdev->dev);
> > + if (!input_dev)
> > + return -ENOMEM;
> > +
> > + keypad->input_dev = input_dev;
> > +
> > + device_property_read_u32(&pdev->dev, "poll-interval", &poll_interval_ms);
> > + device_property_read_u32(&pdev->dev, "debounce-delay-ms", &debounce_interval_ms);
> > + device_property_read_u32(&pdev->dev, "settling-time-us", &keypad->settling_time_us);
>
> Not all of these are required properties. If they are missing the driver
> will operate on garbage values.
Yes.
>
> > +
> > + keypad->current_code = -1;
> > + keypad->debounce_code = -1;
> > + keypad->debounce_threshold = DIV_ROUND_UP(debounce_interval_ms, poll_interval_ms);
>
> This will bomb if poll interval is 0.
Yes.
>
> > +
> > + err = charlieplex_keypad_init_gpio(pdev, keypad);
> > + if (err)
> > + return err;
> > +
> > + input_dev->name = pdev->name;
> > + input_dev->id.bustype = BUS_HOST;
> > +
> > + err = matrix_keypad_build_keymap(NULL, NULL, keypad->nlines,
> > + keypad->nlines, NULL, input_dev);
> > + if (err)
> > + dev_err_probe(&pdev->dev, -ENOMEM, "failed to build keymap\n");
>
> Missing "return".
>
> > +
> > + if (device_property_read_bool(&pdev->dev, "autorepeat"))
> > + __set_bit(EV_REP, input_dev->evbit);
> > +
> > + input_set_capability(input_dev, EV_MSC, MSC_SCAN);
> > +
> > + err = input_setup_polling(input_dev, charlieplex_keypad_poll);
> > + if (err)
> > + dev_err_probe(&pdev->dev, err, "unable to set up polling\n");
>
> Missing "return".
Ok for both.
> I fixed it up and applied, please take a look in my 'next' branch and
> tell me if I messed up.
Thank you for the review and the fixes.
I tested it on the real hardware and all is good.
So I imagine that it can still go into 7.1 since it is a new driver
and not a modification of an existing one?
--
Hugo Villeneuve
^ permalink raw reply
* Re: [PATCH v3 1/2] dt-bindings: rng: mtk-rng: add SMC-based TRNG variants
From: Daniel Golle @ 2026-04-20 14:48 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Olivia Mackall, Herbert Xu, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Matthias Brugger, AngeloGioacchino Del Regno,
Sean Wang, linux-crypto, devicetree, linux-kernel,
linux-arm-kernel, linux-mediatek
In-Reply-To: <e747a3c5-1c43-412b-8ff6-f447ee33995c@kernel.org>
On Mon, Apr 20, 2026 at 04:43:00PM +0200, Krzysztof Kozlowski wrote:
> On 20/04/2026 16:24, Daniel Golle wrote:
> > On Mon, Apr 20, 2026 at 04:07:33PM +0200, Krzysztof Kozlowski wrote:
> >> On Sun, Apr 19, 2026 at 01:05:01PM +0100, Daniel Golle wrote:
> >>> + rng {
> >>> + compatible = "mediatek,mt7981-rng";
> >>
> >> I asked at v1. Reminded at v2. Nothing serious, but repeating myself is
> >> pointless and kind of waste of time.
> >
> > Replying *once* telling what you would actually want, or replying to
> > me asking back would have helped enormously:
> > https://patchwork.kernel.org/comment/26880354/
> >
> > All I can see is that you concluded "no improvements" without telling
> > *what it is you would like to see improved*.
> >
>
> Yes, and then you should go to v1 and read the review. There was only
> single comment in this spot, so trivial to find.
>
> AGAIN:
>
> Use four spaces for indentation.
Thank you, that IS helpful.
I've read the "no improvements" statement as an overall conclusion and
not even considered it to be specific to any *place* without further
context.
Is that the only remaining problem you see in the binding right now?
^ permalink raw reply
* Re: [RFC PATCH 4/4] firmware: arm_ffa: check pkvm initailised when initailise ffa driver
From: Yeoreum Yun @ 2026-04-20 14:47 UTC (permalink / raw)
To: Sebastian Ene
Cc: linux-security-module, linux-kernel, linux-integrity,
linux-arm-kernel, kvmarm, paul, jmorris, serge, zohar,
roberto.sassu, dmitry.kasatkin, eric.snowberg, peterhuewe, jarkko,
jgg, sudeep.holla, maz, oupton, joey.gouly, suzuki.poulose,
yuzenghui, catalin.marinas, will
In-Reply-To: <aeYypF4lv6LMH2ch@google.com>
Hi Sebastian,
> On Mon, Apr 20, 2026 at 02:00:57PM +0100, Yeoreum Yun wrote:
>
> Hi,
>
> >
> > Hi Sebastian,
> > > On Fri, Apr 17, 2026 at 06:57:59PM +0100, Yeoreum Yun wrote:
> > >
> > > Hello Yeoreum,
> > >
> > >
> > > > When pKVM is enabled, the FF-A driver must be initialized after pKVM.
> > > > Otherwise, pKVM cannot negotiate the FF-A version or
> > > > obtain RX/TX buffer information, leading to failures in FF-A calls.
> > >
> > > At the moment this already happens after you move back ffa_init() to
> > > device_initcall().
> >
> > How? the kvm_arm_init() is device_initcall() if both built as built-in.
> >
> > >
> > > >
> > > > During FF-A driver initialization, check whether pKVM has been initialized.
> > > > If not, defer probing of the FF-A driver.
> > > >
> > >
> > > I don't think you need to add this dependency. pKVM is
> > > installed through KVM's module_init() which ends up calling hyp_ffa_init() to
> > > do the proxy initialization. The ARM-FFA driver comes after it (since
> > > pKVM is arch specific code). We don't have to call finalize_pkvm(..) to
> > > be able to handle smc(FF-A) calls in the hyp-proxy.
> > >
> >
> > As Marc said, the before finalised_pkvm(), smc wouldn't be trapped
> > to pKVM. IOW, in case when both built as built-in,
>
> They are, I tested before replying to this thread. The HCR_EL2 is
> 0x480080000 so HCR_EL2 TSC bit is set so SMC/FF-A and trapping is enabled.
Oh. I've missed cpu_init_hyp_mode() sets up HCR_EL2. So you're right.
Thanks to correct me ;)
>
> In __pkvm_prot_finalize it sets the HCR_VM bit which enables stage-2 and
> then write the HCR_EL2 from params->hcr_el2. However I wasn't sure that
> this is seen as a 'hack' and not expected to work.
>
> > if ffa_init() is called before finalised_pkvm(),
> > it couldn't proxy the FFA_VERSION, FFA_RXTX_MAP and FFA_PARTITION_INFO_GET
> > called by ffa_init().
> >
> > How can you gurantee hyp_ffa_init() which is called by kvm_arm_init()
> > comes first even kvm_arm_init() and ffa_init() are on device_initcall?
> >
>
> While they are both on device_initcall, the only difference is that
> kvm_arm_init is arch code which appears before the driver/ code in the
> linker. That's why Marc said it is not a solid construct to rely on
> this.
Then I think the origin one -- just check kvm_arm_initialised
is enough to check in ffa_driver. since I misunderstood TSC bit
is setup after finalised_pkvm().
or Am I missing something?
Thanks.
--
Sincerely,
Yeoreum Yun
^ permalink raw reply
* Re: [PATCH v3 1/2] dt-bindings: rng: mtk-rng: add SMC-based TRNG variants
From: Krzysztof Kozlowski @ 2026-04-20 14:43 UTC (permalink / raw)
To: Daniel Golle
Cc: Olivia Mackall, Herbert Xu, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Matthias Brugger, AngeloGioacchino Del Regno,
Sean Wang, linux-crypto, devicetree, linux-kernel,
linux-arm-kernel, linux-mediatek
In-Reply-To: <aeY3HuP01VYl5x6X@makrotopia.org>
On 20/04/2026 16:24, Daniel Golle wrote:
> On Mon, Apr 20, 2026 at 04:07:33PM +0200, Krzysztof Kozlowski wrote:
>> On Sun, Apr 19, 2026 at 01:05:01PM +0100, Daniel Golle wrote:
>>> + rng {
>>> + compatible = "mediatek,mt7981-rng";
>>
>> I asked at v1. Reminded at v2. Nothing serious, but repeating myself is
>> pointless and kind of waste of time.
>
> Replying *once* telling what you would actually want, or replying to
> me asking back would have helped enormously:
> https://patchwork.kernel.org/comment/26880354/
>
> All I can see is that you concluded "no improvements" without telling
> *what it is you would like to see improved*.
>
Yes, and then you should go to v1 and read the review. There was only
single comment in this spot, so trivial to find.
AGAIN:
Use four spaces for indentation.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH RFC] arm64/irqflags: force inline of arch_local_irq_enable()
From: Breno Leitao @ 2026-04-20 14:37 UTC (permalink / raw)
To: Mark Rutland
Cc: Catalin Marinas, Will Deacon, leo.bras, leo.yan, linux-arm-kernel,
linux-kernel, palmer, paulmck, puranjay, usama.arif, kernel-team
In-Reply-To: <aeY02X5MDWPhGPCK@J2N7QTR9R3>
On Mon, Apr 20, 2026 at 03:14:49PM +0100, Mark Rutland wrote:
> On Mon, Apr 20, 2026 at 06:15:24AM -0700, Breno Leitao wrote:
> > On Mon, Apr 20, 2026 at 02:06:23PM +0100, Mark Rutland wrote:
> > >
> > > Are you happy to try that?
> >
> > Absolutely, I'll work on testing it that and put together a patch
> > addressing all of them.
> >
> > Should this be targeted for stable backports as well? If so, which
> > commit should I reference in the Fixes tag?
>
> I don't think we need to worry about backporting, and can do this as a
> cleanup for now unless someone shouts that they're seeing brokenness in
> a stable kernel.
>
> There's no specific commit for a fixes tag; this has always been a bit
> dodgy, but we've evidently been getting away with it in practice.
Ack. I'll run this through production testing for approximately 24
hours, then submit the patch.
Thanks,
--breno
^ permalink raw reply
* Re: [PATCH RFC bpf-next 1/8] kasan: expose generic kasan helpers
From: Alexis Lothoré @ 2026-04-20 14:27 UTC (permalink / raw)
To: Alexei Starovoitov, Andrey Konovalov
Cc: Alexis Lothoré, Alexei Starovoitov, Daniel Borkmann,
Andrii Nakryiko, Martin KaFai Lau, Eduard Zingerman,
Kumar Kartikeya Dwivedi, Song Liu, Yonghong Song, Jiri Olsa,
John Fastabend, David S. Miller, David Ahern, Thomas Gleixner,
Ingo Molnar, Borislav Petkov, Dave Hansen, X86 ML, H. Peter Anvin,
Shuah Khan, Maxime Coquelin, Alexandre Torgue, Andrey Ryabinin,
Alexander Potapenko, Dmitry Vyukov, Vincenzo Frascino,
Andrew Morton, ebpf, Bastien Curutchet, Thomas Petazzoni,
Xu Kuohai, bpf, LKML, Network Development,
open list:KERNEL SELFTEST FRAMEWORK, linux-stm32,
linux-arm-kernel, kasan-dev, linux-mm
In-Reply-To: <CAADnVQKuptG_opA12O=Xb9_+cHf3f=ycAZdfUp17P2HBYQzdsg@mail.gmail.com>
On Mon Apr 20, 2026 at 12:51 AM CEST, Alexei Starovoitov wrote:
> On Sun, Apr 19, 2026 at 2:49 PM Andrey Konovalov <andreyknvl@gmail.com> wrote:
>>
>> On Tue, Apr 14, 2026 at 5:58 PM Alexei Starovoitov
>> <alexei.starovoitov@gmail.com> wrote:
>> >
>> > I think we're talking past each other.
>> > We're not interested in KASAN_SW_TAGS or KASAN_HW_TAGS.
>> > We're not going to modify arm64 JIT at all.
>> >
>> > This is purely KASAN_GENRIC and only on x86-64.
>> > JIT will emit exactly what compilers emit for generic
>> > which is __asan_load/store. This is as stable ABI as it can get
>> > and we don't want to deviate from it.
>>
>> OK, I supposed that's fair. You did throw me off point with your
>> performance comment. But if you decide to add SW_TAGS support at some
>> point, I think this discussion needs to be revisited.
>>
>> But please add a comment saying that those functions are only exposed
>> for BPF JIT and they are not supposed to be used by other parts of the
>> kernel. And in case you do end up adding a new config option, guard
>> the public declarations by a corresponding ifdef.
>
> I feel concerns of misuse are overblown.
> Being in include/linux/kasan.h doesn't make them free-for-all
> all of a sudden, but if you prefer we can just copy paste:
> +void __asan_load1(void *p);
> +void __asan_store1(void *p);
> into bpf_jit_comp.c
That's actually what I initially went with when working on this, but it
did look a bit fragile, and suspected that I would rather be asked to export
them properly through a dedicated header. I'm fine with putting back the
manual declarations in jit comp, though.
>
>> > The goal here is to find bugs in the verifier.
>> > If something got past it, that shouldn't have,
>> > kasan generic on x86-64 is enough.
>>
>> FWIW, I suspect HW_TAGS KASAN already just works with JITed BPF code.
>
> Ohh. Good point. Looks like modern arm64 cpus in public clouds
> don't have that enabled, so one would need pixel phone to
> catch verifier bugs via hw_tags.
> So we still need this x86-specific jit kasan.
> I guess eventually it can be removed when hw_tags support is widespread.
--
Alexis Lothoré, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* Re: [PATCH v3 1/2] dt-bindings: rng: mtk-rng: add SMC-based TRNG variants
From: Daniel Golle @ 2026-04-20 14:24 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Olivia Mackall, Herbert Xu, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Matthias Brugger, AngeloGioacchino Del Regno,
Sean Wang, linux-crypto, devicetree, linux-kernel,
linux-arm-kernel, linux-mediatek
In-Reply-To: <20260420-flat-rook-of-hail-bbede5@quoll>
On Mon, Apr 20, 2026 at 04:07:33PM +0200, Krzysztof Kozlowski wrote:
> On Sun, Apr 19, 2026 at 01:05:01PM +0100, Daniel Golle wrote:
> > + rng {
> > + compatible = "mediatek,mt7981-rng";
>
> I asked at v1. Reminded at v2. Nothing serious, but repeating myself is
> pointless and kind of waste of time.
Replying *once* telling what you would actually want, or replying to
me asking back would have helped enormously:
https://patchwork.kernel.org/comment/26880354/
All I can see is that you concluded "no improvements" without telling
*what it is you would like to see improved*.
You want me to drop the whole example? Drop the compatible?
I did drop (and replace) the negative list with a positive list, and
thought that was what you have asked me for
https://patchwork.kernel.org/comment/26817847/
This binding is dead simple: It's a compatible, describing the identical
hardware now hidden behind and SMC call.
^ permalink raw reply
* Re: [RFC PATCH 4/4] firmware: arm_ffa: check pkvm initailised when initailise ffa driver
From: Sebastian Ene @ 2026-04-20 14:20 UTC (permalink / raw)
To: Marc Zyngier
Cc: Yeoreum Yun, linux-security-module, linux-kernel, linux-integrity,
linux-arm-kernel, kvmarm, paul, jmorris, serge, zohar,
roberto.sassu, dmitry.kasatkin, eric.snowberg, peterhuewe, jarkko,
jgg, sudeep.holla, oupton, joey.gouly, suzuki.poulose, yuzenghui,
catalin.marinas, will
In-Reply-To: <86mryx2408.wl-maz@kernel.org>
On Mon, Apr 20, 2026 at 01:46:47PM +0100, Marc Zyngier wrote:
> On Mon, 20 Apr 2026 13:32:32 +0100,
> Sebastian Ene <sebastianene@google.com> wrote:
> >
> > On Fri, Apr 17, 2026 at 06:57:59PM +0100, Yeoreum Yun wrote:
> >
> > Hello Yeoreum,
> >
> >
> > > When pKVM is enabled, the FF-A driver must be initialized after pKVM.
> > > Otherwise, pKVM cannot negotiate the FF-A version or
> > > obtain RX/TX buffer information, leading to failures in FF-A calls.
> >
> > At the moment this already happens after you move back ffa_init() to
> > device_initcall().
>
> But relying on this sort of ordering is just making things more
> fragile.
>
Thanks for letting me know. Since this is not a solid construct we will have
to change the driver init code to come after pKVM in this case.
> >
> > >
> > > During FF-A driver initialization, check whether pKVM has been initialized.
> > > If not, defer probing of the FF-A driver.
> > >
> >
> > I don't think you need to add this dependency. pKVM is
> > installed through KVM's module_init() which ends up calling hyp_ffa_init() to
> > do the proxy initialization. The ARM-FFA driver comes after it (since
> > pKVM is arch specific code). We don't have to call finalize_pkvm(..) to
> > be able to handle smc(FF-A) calls in the hyp-proxy.
>
> You do. Without the finalisation, SMCs are not trapped by EL2.
>
> And even if it did, relying on such hack is just wrong.
>
That makes it an even stronger argument to move the driver init at a
later stage. I was relying on this to trap early ff-a when the
ARM FF-A driver was used.
> M.
>
> --
> Without deviation from the norm, progress is not possible.
Thanks,
Sebastian
^ permalink raw reply
* Re: [PATCH 0/4] Add hstimer support for H616 and T113-S3
From: Andre Przywara @ 2026-04-20 14:14 UTC (permalink / raw)
To: Michal Piekos
Cc: Daniel Lezcano, Thomas Gleixner, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Chen-Yu Tsai, Jernej Skrabec, Samuel Holland,
Maxime Ripard, linux-kernel, devicetree, linux-arm-kernel,
linux-sunxi
In-Reply-To: <xlvldmapdoql7nt3swube5vd6fdiosq7rt5afg246xertko5fa@4irmzupkar23>
Hi Michal,
On 4/20/26 13:27, Michal Piekos wrote:
> On Sun, Apr 19, 2026 at 10:55:39PM +0200, Andre Przywara wrote:
>> On Sun, 19 Apr 2026 14:46:06 +0200
>> Michal Piekos <michal.piekos@mmpsystems.pl> wrote:
>>
>> Hi Michal,
>>
>>> Add support for Allwinner H616 high speed timer in sun5i hstimer driver
>>> and describe corresponding nodes in dts for H616 and T113-S3.
>>>
>>> H616 uses same model as existing driver except register shift compared
>>> to older variants.
>>>
>>> Added register layout abstraction in the driver, extended the binding
>>> with new compatibles and wired up dts nodes for H616 and T113-S3 which
>>> uses H616 as fallback compatible.
>>
>> Can you say *why* we need this? IIUC Linux only ever uses one clock
>> source, and selects the (non-optional) Generic Timer (aka arch timer)
>> for that? So can you say what this hstimer clock source adds? I guess
>> higher resolution, but what is your use case, so why would you need the
>> 200 MHz? And does this offset the higher access cost of an MMIO
>> access, compared to the arch timer's sysreg based access? Also, IIUC,
>> people would need to manually select this as the clocksource, why and
>> when would they do so? (Given they even know about it in the first
>> place).
>> Also the hstimer hasn't been used since the A20, so nobody seemed to
>> have missed it meanwhile?
>>
>> Cheers,
>> Andre
>>
> I took the table from https://linux-sunxi.org/Linux_mainlining_effort as
> a todo list and wanted to help with it. I do not have own use case for
> this timer. If it is not needed then I will spin v2 to include your
> comments and abandon it.
Ah, that's good to know, and thanks for picking things from that list! I
don't think there is a particular need to abandon your work, we could as
well upstream it. At least the DT changes should be added, so that other
DT users could make use of the timers - after all it's a Linux
implementation choice to utilise just one timer. But please go ahead and
post a complete v2, I don't think it hurts to have HSTIMER support in
the kernel.
And while you are at it: can you figure out what the need is for using
two timers? One is a clock source, the other is for clock events? And
why do we limit the counters and timers to 32 bit? Even the A13 manual
lists them as 56 bits, and a wraparound time of roughly 21 seconds (with
32 bit counters) does not sound very long to me.
Not sure what your primary motivation for fixing Allwinner support is,
but we could probably find more worthwhile targets. Do you have
Allwinner boards other than the OrangePi Zero 3? There are not many low
hanging fruits on the H616 left (MBUS and LDOs(?) maybe), but the A523
has quite some missing drivers still, some of them probably more on the
easy side.
If you are stuck with the OpiZero3, then you could just look and check
the existing devices, and verify their operation. For instance I think
USB-OTG is still broken - across most Allwinner SoCs actually, so it's a
sunxi driver issue.
Thanks,
Andre
>
> Michal
>
>>>
>>> Signed-off-by: Michal Piekos <michal.piekos@mmpsystems.pl>
>>> ---
>>> Michal Piekos (4):
>>> dt-bindings: timer: allwinner,sun5i-a13-hstimer: add H616 and T113-S3
>>> clocksource/drivers/sun5i: add H616 hstimer support
>>> arm64: dts: allwinner: h616: add hstimer node
>>> arm: dts: allwinner: t113s: add hstimer node
>>>
>>> .../timer/allwinner,sun5i-a13-hstimer.yaml | 8 +++-
>>> arch/arm/boot/dts/allwinner/sun8i-t113s.dtsi | 12 +++++
>>> arch/arm64/boot/dts/allwinner/sun50i-h616.dtsi | 9 ++++
>>> drivers/clocksource/timer-sun5i.c | 56 +++++++++++++++++++---
>>> 4 files changed, 78 insertions(+), 7 deletions(-)
>>> ---
>>> base-commit: faeab166167f5787719eb8683661fd41a3bb1514
>>> change-id: 20260413-h616-t113s-hstimer-62939948f91c
>>>
>>> Best regards,
>>
>>
^ permalink raw reply
* Re: [RESEND PATCH 0/3] arm_mpam: resctrl: Fixes for v7.1-rc1
From: Catalin Marinas @ 2026-04-20 14:15 UTC (permalink / raw)
To: James Morse; +Cc: linux-arm-kernel, will, Ben Horgan, Gavin Shan, Zeng Heng
In-Reply-To: <20260420140516.3892820-1-james.morse@arm.com>
Hi James,
On Mon, Apr 20, 2026 at 03:05:13PM +0100, James Morse wrote:
> This series is the collected fixes for MPAM series in arm64/for-next/core.
>
> These fix a unmount->remount problem with the CDP emulation,
> an uninitialised variable and a checker warning.
>
> If its easier, there is a branch here:
> https://git.kernel.org/pub/scm/linux/kernel/git/morse/linux.git mpam/glue/v7.0-rc3
I pulled the mpam/glue/v7.0-rc3+fixes into arm64 for-next/core.
Thanks!
--
Catalin
^ permalink raw reply
* Re: [PATCH RFC] arm64/irqflags: force inline of arch_local_irq_enable()
From: Mark Rutland @ 2026-04-20 14:14 UTC (permalink / raw)
To: Breno Leitao
Cc: Catalin Marinas, Will Deacon, leo.bras, leo.yan, linux-arm-kernel,
linux-kernel, palmer, paulmck, puranjay, usama.arif, kernel-team
In-Reply-To: <aeYmHr_lgPJbBoL_@gmail.com>
On Mon, Apr 20, 2026 at 06:15:24AM -0700, Breno Leitao wrote:
> On Mon, Apr 20, 2026 at 02:06:23PM +0100, Mark Rutland wrote:
> > On Mon, Apr 20, 2026 at 05:42:11AM -0700, Breno Leitao wrote:
> > > arch_local_irq_enable() is a small wrapper that dispatches between two
> > > unmask paths: __daif_local_irq_enable() on most systems, and
> > > __pmr_local_irq_enable() on builds that use GIC PMR-based masking
> > > (Pseudo-NMI). Both leaf primitives are already __always_inline; the
> > > wrapper itself is plain "static inline".
> > >
> > > In practice the compiler does not always inline the wrapper.
> >
> > I think this was my mistake, and we should have marked all the helpers
> > as __always_inline for noinstr safety, as x86 did in commit:
> >
> > 7a745be1cc90 ("x86/entry: __always_inline irqflags for noinstr")
> >
> > I think we should mark all of the following as __always_inline in one
> > go:
> >
> > * arch_local_irq_enable()
> > * arch_local_irq_disable()
> > * arch_local_save_flags()
> > * arch_irqs_disabled_flags()
> > * arch_irqs_disabled()
> > * arch_local_irq_save()
> > * arch_local_irq_restore()
> >
> > ... which then ensures noinstr safety, and has the side benefit of
> > giving nicer traces as you're suggesting here.
> >
> > Are you happy to try that?
>
> Absolutely, I'll work on testing it that and put together a patch
> addressing all of them.
>
> Should this be targeted for stable backports as well? If so, which
> commit should I reference in the Fixes tag?
I don't think we need to worry about backporting, and can do this as a
cleanup for now unless someone shouts that they're seeing brokenness in
a stable kernel.
There's no specific commit for a fixes tag; this has always been a bit
dodgy, but we've evidently been getting away with it in practice.
Mark.
^ permalink raw reply
* Re: [PATCH v3 1/2] dt-bindings: rng: mtk-rng: add SMC-based TRNG variants
From: Krzysztof Kozlowski @ 2026-04-20 14:07 UTC (permalink / raw)
To: Daniel Golle
Cc: Olivia Mackall, Herbert Xu, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Matthias Brugger, AngeloGioacchino Del Regno,
Sean Wang, linux-crypto, devicetree, linux-kernel,
linux-arm-kernel, linux-mediatek
In-Reply-To: <585fc832e4e5d3656bd25ecee6bafb636993104a.1776600269.git.daniel@makrotopia.org>
On Sun, Apr 19, 2026 at 01:05:01PM +0100, Daniel Golle wrote:
> + rng {
> + compatible = "mediatek,mt7981-rng";
I asked at v1. Reminded at v2. Nothing serious, but repeating myself is
pointless and kind of waste of time.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [GIT PULL] ARM: mvebu: dt64 for v7.1 (#1)
From: Gregory CLEMENT @ 2026-04-20 14:05 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Arnd Bergmann, arm, soc, Andrew Lunn, Sebastian Hesselbarth,
linux-arm-kernel
In-Reply-To: <20260414-nifty-conscious-fox-973b65@quoll>
Hello Krzysztof,
> On Fri, Apr 10, 2026 at 03:25:39PM +0200, Gregory CLEMENT wrote:
>> Hi,
>>
>> Here is the first pull request for dt64 for mvebu for v7.1.
>>
>> Gregory
>>
>> The following changes since commit 6de23f81a5e08be8fbf5e8d7e9febc72a5b5f27f:
>>
>> Linux 7.0-rc1 (2026-02-22 13:18:59 -0800)
>>
>> are available in the Git repository at:
>>
>> git://git.kernel.org/pub/scm/linux/kernel/git/gclement/mvebu.git tags/mvebu-dt64-7.1-1
>>
>> for you to fetch changes up to 00e6d608fe80b0f68c325cb46862f78e9a8ec768:
>>
>> arm64: dts: marvell: armada-37xx: swap PHYs' order in USB3 controller node (2026-04-09 10:14:40 +0200)
>>
>> ----------------------------------------------------------------
>> mvebu dt64 for 7.1 (part 1)
>
> This was sent just 2 days before merge window open, thus I applied it as
> late branch.
Thanks for finally merging it.
Gregory
>
> Best regards,
> Krzysztof
>
--
Grégory CLEMENT, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
^ 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