* [RFC PATCH 4/6] Drivers: hv: Mark shared memory as decrypted for CCA Realms
From: Kameron Carr @ 2026-06-09 18:10 UTC (permalink / raw)
To: kys, haiyangz, wei.liu, decui, longli
Cc: catalin.marinas, will, mark.rutland, lpieralisi, sudeep.holla,
arnd, thuth, linux-hyperv, linux-arm-kernel, linux-kernel,
linux-arch, mhklinux
In-Reply-To: <20260609181030.2378391-1-kameroncarr@linux.microsoft.com>
In hv_common_cpu_init(), the per-CPU hypercall input/output pages need
to be marked as decrypted (shared) for confidential VM isolation types.
This is already done for SNP and TDX isolation; extend the same handling
to Arm CCA Realm guests so that the host hypervisor can access the
shared hypercall buffers.
is_realm_world() is only declared in arch/arm64/include/asm/rsi.h, so
using it directly in the arch-neutral drivers/hv/hv_common.c would
break the x86 build. Introduce a Hyper-V-specific helper following the
established hv_isolation_type_snp() / hv_isolation_type_tdx() pattern.
On architectures other than arm64 the weak default keeps the existing
behaviour.
Signed-off-by: Kameron Carr <kameroncarr@linux.microsoft.com>
---
arch/arm64/hyperv/mshyperv.c | 5 +++++
drivers/hv/hv_common.c | 9 ++++++++-
include/asm-generic/mshyperv.h | 1 +
3 files changed, 14 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/hyperv/mshyperv.c b/arch/arm64/hyperv/mshyperv.c
index 08fec82691683..b595b2b9bdbbb 100644
--- a/arch/arm64/hyperv/mshyperv.c
+++ b/arch/arm64/hyperv/mshyperv.c
@@ -208,3 +208,8 @@ bool hv_is_hyperv_initialized(void)
return hyperv_initialized;
}
EXPORT_SYMBOL_GPL(hv_is_hyperv_initialized);
+
+bool hv_isolation_type_cca(void)
+{
+ return is_realm_world();
+}
diff --git a/drivers/hv/hv_common.c b/drivers/hv/hv_common.c
index 6b67ac6167891..010c7d98b5de1 100644
--- a/drivers/hv/hv_common.c
+++ b/drivers/hv/hv_common.c
@@ -499,7 +499,8 @@ int hv_common_cpu_init(unsigned int cpu)
}
if (!ms_hyperv.paravisor_present &&
- (hv_isolation_type_snp() || hv_isolation_type_tdx())) {
+ (hv_isolation_type_snp() || hv_isolation_type_tdx() ||
+ hv_isolation_type_cca())) {
ret = set_memory_decrypted((unsigned long)mem, pgcount);
if (ret) {
/* It may be unsafe to free 'mem' */
@@ -666,6 +667,12 @@ bool __weak hv_isolation_type_tdx(void)
}
EXPORT_SYMBOL_GPL(hv_isolation_type_tdx);
+bool __weak hv_isolation_type_cca(void)
+{
+ return false;
+}
+EXPORT_SYMBOL_GPL(hv_isolation_type_cca);
+
void __weak hv_setup_vmbus_handler(void (*handler)(void))
{
}
diff --git a/include/asm-generic/mshyperv.h b/include/asm-generic/mshyperv.h
index bf601d67cecb9..1fa79abce743c 100644
--- a/include/asm-generic/mshyperv.h
+++ b/include/asm-generic/mshyperv.h
@@ -79,6 +79,7 @@ u64 hv_do_fast_hypercall16(u16 control, u64 input1, u64 input2);
bool hv_isolation_type_snp(void);
bool hv_isolation_type_tdx(void);
+bool hv_isolation_type_cca(void);
/*
* On architectures where Hyper-V doesn't support AEOI (e.g., ARM64),
--
2.45.4
^ permalink raw reply related
* [RFC PATCH 1/6] arm64: rsi: Add RSI host call structure and helper function
From: Kameron Carr @ 2026-06-09 18:10 UTC (permalink / raw)
To: kys, haiyangz, wei.liu, decui, longli
Cc: catalin.marinas, will, mark.rutland, lpieralisi, sudeep.holla,
arnd, thuth, linux-hyperv, linux-arm-kernel, linux-kernel,
linux-arch, mhklinux
In-Reply-To: <20260609181030.2378391-1-kameroncarr@linux.microsoft.com>
Add struct rsi_host_call to rsi_smc.h, which represents the host call
data structure used by the Realm Management Monitor (RMM) for the
RSI_HOST_CALL interface. The structure contains a 16-bit immediate field
and 31 general-purpose register values, aligned to 256 bytes as required
by the CCA RMM specification.
Add rsi_host_call() static inline wrapper in rsi_cmds.h that invokes
SMC_RSI_HOST_CALL with the physical address of the host call structure.
This will be used by Hyper-V guest code to route hypercalls through the
RSI interface when running inside an Arm CCA Realm.
Signed-off-by: Kameron Carr <kameroncarr@linux.microsoft.com>
---
arch/arm64/include/asm/rsi_cmds.h | 9 +++++++++
arch/arm64/include/asm/rsi_smc.h | 6 ++++++
2 files changed, 15 insertions(+)
diff --git a/arch/arm64/include/asm/rsi_cmds.h b/arch/arm64/include/asm/rsi_cmds.h
index 2c8763876dfb7..83b4b1f598454 100644
--- a/arch/arm64/include/asm/rsi_cmds.h
+++ b/arch/arm64/include/asm/rsi_cmds.h
@@ -159,4 +159,13 @@ static inline unsigned long rsi_attestation_token_continue(phys_addr_t granule,
return res.a0;
}
+static inline long rsi_host_call(phys_addr_t host_call_struct)
+{
+ struct arm_smccc_res res;
+
+ arm_smccc_smc(SMC_RSI_HOST_CALL, host_call_struct, 0, 0, 0, 0, 0, 0,
+ &res);
+ return res.a0;
+}
+
#endif /* __ASM_RSI_CMDS_H */
diff --git a/arch/arm64/include/asm/rsi_smc.h b/arch/arm64/include/asm/rsi_smc.h
index e19253f96c940..ffea93340ed7f 100644
--- a/arch/arm64/include/asm/rsi_smc.h
+++ b/arch/arm64/include/asm/rsi_smc.h
@@ -142,6 +142,12 @@ struct realm_config {
*/
} __aligned(0x1000);
+struct rsi_host_call {
+ u16 immediate;
+ u64 gprs[31];
+} __aligned(256);
+static_assert(sizeof(struct rsi_host_call) == 256);
+
#endif /* __ASSEMBLER__ */
/*
--
2.45.4
^ permalink raw reply related
* [RFC PATCH 6/6] arm64: hyperv: Implement hv_is_isolation_supported() for CCA Realms
From: Kameron Carr @ 2026-06-09 18:10 UTC (permalink / raw)
To: kys, haiyangz, wei.liu, decui, longli
Cc: catalin.marinas, will, mark.rutland, lpieralisi, sudeep.holla,
arnd, thuth, linux-hyperv, linux-arm-kernel, linux-kernel,
linux-arch, mhklinux
In-Reply-To: <20260609181030.2378391-1-kameroncarr@linux.microsoft.com>
Provide an arm64 implementation of hv_is_isolation_supported() that
overrides the __weak default in drivers/hv/hv_common.c.
The implementation deliberately does not depend on
hv_is_hyperv_initialized() because hv_common_init() consults
hv_is_isolation_supported() before hyperv_initialized is set.
Signed-off-by: Kameron Carr <kameroncarr@linux.microsoft.com>
---
arch/arm64/hyperv/mshyperv.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/arch/arm64/hyperv/mshyperv.c b/arch/arm64/hyperv/mshyperv.c
index b595b2b9bdbbb..b9b1c2f8e3ec7 100644
--- a/arch/arm64/hyperv/mshyperv.c
+++ b/arch/arm64/hyperv/mshyperv.c
@@ -213,3 +213,8 @@ bool hv_isolation_type_cca(void)
{
return is_realm_world();
}
+
+bool hv_is_isolation_supported(void)
+{
+ return is_realm_world();
+}
--
2.45.4
^ permalink raw reply related
* [RFC PATCH 0/6] arm64: hyperv: Add Realm support for Hyper-V
From: Kameron Carr @ 2026-06-09 18:10 UTC (permalink / raw)
To: kys, haiyangz, wei.liu, decui, longli
Cc: catalin.marinas, will, mark.rutland, lpieralisi, sudeep.holla,
arnd, thuth, linux-hyperv, linux-arm-kernel, linux-kernel,
linux-arch, mhklinux
From: Kameron Carr <kameroncarr@microsoft.com>
Realms (CoCo VMs on ARM) require host calls to be routed through the RMM
(Realm Management Monitor) via the RSI (Realm Service Interface). This
series implements most of the necessary changes to support Realms on
Hyper-V.
One required change is not included in this series. The two buffers
allocated via vzalloc() in netvsc_init_buf() cannot be decrypted in
vmbus_establish_gpadl(). Currently only linearly mapped memory can be
decrypted. See my RFC patch [1]. I will implement the accompanying netvsc
changes based on the feedback I receive on that patch.
This patch series was tested by booting a Realm on Cobalt 200 running
Windows. I decreased the buffer size and used kzalloc() in
netvsc_init_buf() in my testing as a workaround for the issue mentioned
above.
[1] https://lore.kernel.org/all/20260521205834.1012925-1-kameroncarr@linux.microsoft.com/
Kameron Carr (6):
arm64: rsi: Add RSI host call structure and helper function
firmware: smccc: Detect hypervisor via RSI host call in CCA Realms
arm64: hyperv: Add per-CPU RSI host call infrastructure for CCA Realms
Drivers: hv: Mark shared memory as decrypted for CCA Realms
arm64: hyperv: Route hypercalls through RSI host call in CCA Realms
arm64: hyperv: Implement hv_is_isolation_supported() for CCA Realms
arch/arm64/hyperv/hv_core.c | 175 ++++++++++++++++++++++++------
arch/arm64/hyperv/mshyperv.c | 88 ++++++++++++++-
arch/arm64/include/asm/mshyperv.h | 3 +
arch/arm64/include/asm/rsi_cmds.h | 9 ++
arch/arm64/include/asm/rsi_smc.h | 6 +
drivers/firmware/smccc/smccc.c | 41 ++++++-
drivers/hv/hv_common.c | 9 +-
include/asm-generic/mshyperv.h | 1 +
8 files changed, 294 insertions(+), 38 deletions(-)
base-commit: 7a035678fc2bdee81881170764ef08a91a076147
--
2.45.4
^ permalink raw reply
* [RFC PATCH 3/6] arm64: hyperv: Add per-CPU RSI host call infrastructure for CCA Realms
From: Kameron Carr @ 2026-06-09 18:10 UTC (permalink / raw)
To: kys, haiyangz, wei.liu, decui, longli
Cc: catalin.marinas, will, mark.rutland, lpieralisi, sudeep.holla,
arnd, thuth, linux-hyperv, linux-arm-kernel, linux-kernel,
linux-arch, mhklinux
In-Reply-To: <20260609181030.2378391-1-kameroncarr@linux.microsoft.com>
Arm CCA Realms cannot issue Hyper-V hypercalls via HVC; the guest must
route them through the RSI_HOST_CALL interface, which takes the IPA of a
per-CPU rsi_host_call structure as its argument.
Add hyperv_pcpu_hostcall_struct as a per-CPU pointer to that buffer and
allocate it for the boot CPU during hyperv_init() and for each secondary
CPU in hv_cpu_init(). The allocation is gated on is_realm_world() so
non-Realm arm64 Hyper-V guests pay no memory cost.
Signed-off-by: Kameron Carr <kameroncarr@linux.microsoft.com>
---
arch/arm64/hyperv/mshyperv.c | 78 ++++++++++++++++++++++++++++++-
arch/arm64/include/asm/mshyperv.h | 3 ++
2 files changed, 79 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/hyperv/mshyperv.c b/arch/arm64/hyperv/mshyperv.c
index 4fdc26ade1d74..08fec82691683 100644
--- a/arch/arm64/hyperv/mshyperv.c
+++ b/arch/arm64/hyperv/mshyperv.c
@@ -15,10 +15,16 @@
#include <linux/errno.h>
#include <linux/version.h>
#include <linux/cpuhotplug.h>
+#include <linux/slab.h>
+#include <linux/percpu.h>
#include <asm/mshyperv.h>
+#include <asm/rsi.h>
static bool hyperv_initialized;
+void * __percpu *hyperv_pcpu_hostcall_struct;
+EXPORT_SYMBOL_GPL(hyperv_pcpu_hostcall_struct);
+
int hv_get_hypervisor_version(union hv_hypervisor_version_info *info)
{
hv_get_vpreg_128(HV_REGISTER_HYPERVISOR_VERSION,
@@ -60,6 +66,46 @@ static bool __init hyperv_detect_via_acpi(void)
#endif
+static void hv_hostcall_free(void)
+{
+ int cpu;
+
+ if (!hyperv_pcpu_hostcall_struct)
+ return;
+
+ for_each_possible_cpu(cpu)
+ kfree(*per_cpu_ptr(hyperv_pcpu_hostcall_struct, cpu));
+ free_percpu(hyperv_pcpu_hostcall_struct);
+ hyperv_pcpu_hostcall_struct = NULL;
+}
+
+static int hv_cpu_init(unsigned int cpu)
+{
+ void **hostcall_struct;
+ gfp_t flags;
+ void *mem;
+
+ if (hyperv_pcpu_hostcall_struct) {
+ /* hv_cpu_init() can be called with IRQs disabled from hv_resume() */
+ flags = irqs_disabled() ? GFP_ATOMIC : GFP_KERNEL;
+
+ hostcall_struct = (void **)this_cpu_ptr(hyperv_pcpu_hostcall_struct);
+ /*
+ * The hostcall_struct memory is not freed when the CPU
+ * goes offline. If a previously offlined CPU is brought
+ * back online, the memory is reused here.
+ */
+ if (!*hostcall_struct) {
+ mem = kzalloc_obj(struct rsi_host_call, flags);
+ if (!mem)
+ return -ENOMEM;
+ *hostcall_struct = mem;
+ }
+ }
+
+ return hv_common_cpu_init(cpu);
+}
+
static bool __init hyperv_detect_via_smccc(void)
{
uuid_t hyperv_uuid = UUID_INIT(
@@ -73,6 +119,8 @@ static bool __init hyperv_detect_via_smccc(void)
static int __init hyperv_init(void)
{
struct hv_get_vp_registers_output result;
+ void **hostcall_struct;
+ void *mem;
u64 guest_id;
int ret;
@@ -85,6 +133,27 @@ static int __init hyperv_init(void)
if (!hyperv_detect_via_acpi() && !hyperv_detect_via_smccc())
return 0;
+ /*
+ * The RSI host-call buffer is only ever used when
+ * is_realm_world() is true. Skip the per-CPU allocation on
+ * non-Realm guests.
+ */
+ if (is_realm_world()) {
+ hyperv_pcpu_hostcall_struct = alloc_percpu(void *);
+ if (!hyperv_pcpu_hostcall_struct)
+ return -ENOMEM;
+
+ hostcall_struct = (void **)this_cpu_ptr(hyperv_pcpu_hostcall_struct);
+ if (!*hostcall_struct) {
+ mem = kzalloc_obj(struct rsi_host_call);
+ if (!mem) {
+ ret = -ENOMEM;
+ goto free_hostcall_mem;
+ }
+ *hostcall_struct = mem;
+ }
+ }
+
/* Setup the guest ID */
guest_id = hv_generate_guest_id(LINUX_VERSION_CODE);
hv_set_vpreg(HV_REGISTER_GUEST_OS_ID, guest_id);
@@ -106,12 +175,13 @@ static int __init hyperv_init(void)
ret = hv_common_init();
if (ret)
- return ret;
+ goto free_hostcall_mem;
ret = cpuhp_setup_state(CPUHP_AP_HYPERV_ONLINE, "arm64/hyperv_init:online",
- hv_common_cpu_init, hv_common_cpu_die);
+ hv_cpu_init, hv_common_cpu_die);
if (ret < 0) {
hv_common_free();
+ hv_hostcall_free();
return ret;
}
@@ -125,6 +195,10 @@ static int __init hyperv_init(void)
hyperv_initialized = true;
return 0;
+
+free_hostcall_mem:
+ hv_hostcall_free();
+ return ret;
}
early_initcall(hyperv_init);
diff --git a/arch/arm64/include/asm/mshyperv.h b/arch/arm64/include/asm/mshyperv.h
index b721d3134ab66..65a00bd14c6cb 100644
--- a/arch/arm64/include/asm/mshyperv.h
+++ b/arch/arm64/include/asm/mshyperv.h
@@ -63,4 +63,7 @@ static inline u64 hv_get_non_nested_msr(unsigned int reg)
#include <asm-generic/mshyperv.h>
+/* Per-CPU RSI host call structure for CCA Realms */
+extern void *__percpu *hyperv_pcpu_hostcall_struct;
+
#endif
--
2.45.4
^ permalink raw reply related
* Re: [PATCH 1/2] dt-bindings: usb: Add Rockchip RK3568 compatible for EHCI and OHCI
From: Jonas Karlman @ 2026-06-09 18:06 UTC (permalink / raw)
To: Diederik de Haas
Cc: Heiko Stuebner, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Greg Kroah-Hartman, devicetree@vger.kernel.org,
linux-rockchip@lists.infradead.org, linux-usb@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
In-Reply-To: <DJ4NVA328NUV.LSPMVBFE0PD8@cknow-tech.com>
Hi Diederik,
On 6/9/2026 6:32 PM, Diederik de Haas wrote:
> Hi Jonas,
>
> On Tue Jun 9, 2026 at 5:41 PM CEST, Jonas Karlman wrote:
>> The Rockchip RK3568 EHCI/OHCI controller depends on clk_usbphy1_480m
>> being enabled, or the system may freeze when registers are accessed.
>>
>> Add Rockchip RK3568 EHCI and OHCI compatibles with a similar four-clock
>> constraint as RK3588.
>>
>> Signed-off-by: Jonas Karlman <jonas@kwiboo.se>
>> ---
>> Existing DTs for RK3568 use the plain generic-ehci/ohci compatible,
>> next patch make use of these new compatibles and adds the missing
>> clk_usbphy1_480m clock references.
>> ---
>> .../devicetree/bindings/usb/generic-ehci.yaml | 10 ++++++++++
>> .../devicetree/bindings/usb/generic-ohci.yaml | 5 ++++-
>> 2 files changed, 14 insertions(+), 1 deletion(-)
>>
>> diff --git a/Documentation/devicetree/bindings/usb/generic-ehci.yaml b/Documentation/devicetree/bindings/usb/generic-ehci.yaml
>> index 55a5aa7d7a54..c49a1bbc8cfd 100644
>> --- a/Documentation/devicetree/bindings/usb/generic-ehci.yaml
>> +++ b/Documentation/devicetree/bindings/usb/generic-ehci.yaml
>> @@ -52,6 +52,7 @@ properties:
>> - ibm,476gtr-ehci
>> - nxp,lpc1850-ehci
>> - qca,ar7100-ehci
>> + - rockchip,rk3568-ehci
>> - rockchip,rk3588-ehci
>> - snps,hsdk-v1.0-ehci
>> - socionext,uniphier-ehci
>> @@ -186,6 +187,15 @@ allOf:
>> required:
>> - clocks
>> - clock-names
>> + - if:
>> + properties:
>> + compatible:
>> + contains:
>> + const: rockchip,rk3568-ehci
>> + then:
>> + properties:
>> + clocks:
>> + minItems: 4
>
> I think that the constraint for rk3588 is this:
> - minItems: 1
> - maxItems: 4
>
> Like ~ every other compatible; there's no 'branch' for rk3588-ehci.
>
> That's different from what you add for rk3568. Is that deliberate?
> Because from the commit message I assumed they should be the same.
It was deliberate, the intention is to use min/maxItems: 4 for rk3568
for both EHCI and OHCI. I left out anything related to k3588 to keep
existing behavior and avoid any possible breakage, and why I used
'similar' and not 'same' in the commit message ;-)
Did a check and the rk3588 variant also uses 4 clocks so I will add same
constraint for the rk3588 variant and address Sashiko's concern in v2.
Regards,
Jonas
>
>> unevaluatedProperties: false
>>
>> diff --git a/Documentation/devicetree/bindings/usb/generic-ohci.yaml b/Documentation/devicetree/bindings/usb/generic-ohci.yaml
>> index d42f448fa204..5f1b4d2bff89 100644
>> --- a/Documentation/devicetree/bindings/usb/generic-ohci.yaml
>> +++ b/Documentation/devicetree/bindings/usb/generic-ohci.yaml
>> @@ -47,6 +47,7 @@ properties:
>> - hpe,gxp-ohci
>> - ibm,476gtr-ohci
>> - ingenic,jz4740-ohci
>> + - rockchip,rk3568-ohci
>> - rockchip,rk3588-ohci
>> - snps,hsdk-v1.0-ohci
>> - const: generic-ohci
>> @@ -198,7 +199,9 @@ allOf:
>> properties:
>> compatible:
>> contains:
>> - const: rockchip,rk3588-ohci
>> + enum:
>> + - rockchip,rk3568-ohci
>> + - rockchip,rk3588-ohci
>
> Here they clearly do have the same constraint.
>
> Cheers,
> Diederik
>
>> then:
>> properties:
>> clocks:
>
^ permalink raw reply
* Re: [PATCH v3] cpu/hotplug: Fix NULL kobject warning in cpuhp_smt_enable()
From: Catalin Marinas @ 2026-06-09 17:58 UTC (permalink / raw)
To: Jinjie Ruan
Cc: Will Deacon, corbet, skhan, punit.agrawal, jic23,
osama.abdelkader, chenl311, fengchengwen, suzuki.poulose, maz,
lpieralisi, timothy.hayes, sascha.bischoff, arnd,
mrigendra.chaubey, pierre.gondois, dietmar.eggemann, yangyicong,
sudeep.holla, linux-arm-kernel, linux-doc, linux-kernel
In-Reply-To: <02932ef7-5819-4cf5-8e78-8fd3fd40274f@huawei.com>
Hi Jinjie,
On Wed, Jun 03, 2026 at 02:38:11PM +0800, Jinjie Ruan wrote:
> On 6/2/2026 7:09 PM, Will Deacon wrote:
> > On Wed, May 20, 2026 at 10:20:23AM +0800, Jinjie Ruan wrote:
> >> When booting with ACPI, arm64 smp_prepare_cpus() currently sets all
> >> enumerated CPUs as "present" regardless of their status in the MADT. This
> >> causes issues with SMT hotplug control. For instance, with QEMU's
> >> "-smp 4,maxcpus=8" configuration, the MADT GICC entries are populated as
> >> follows: the first four CPUs are marked Enabled while the remaining four
> >> are marked Online Capable to support potential hot-plugging.
> >>
> >> Fix this by:
> >>
> >> 1. When booting with ACPI, checking the ACPI_MADT_ENABLED flag in the GICC
> >> entry before calling set_cpu_present() during SMP initialization.
> >>
> >> 2. Properly managing the present mask in acpi_map_cpu() and
> >> acpi_unmap_cpu() to support actual CPU hotplug events, This aligns with
> >> other architectures like x86 and LoongArch.
> >>
> >> 3. Update the arm64 CPU hotplug documentation to no longer state that all
> >> online-capable vCPUs are marked as present by the kernel at boot time.
> >>
> >> This ensures that only physically available or explicitly enabled CPUs
> >> are in the present mask, keeping the SMT control logic consistent with
> >> the actual hardware state.
> >
> > Please can you check the Sashiko review comment?
> >
> > https://sashiko.dev/#/patchset/20260520022023.126670-1-ruanjinjie@huawei.com
>
> I think commit eba4675008a6 ("arm64: arch_register_cpu() variant to
> check if an ACPI handle is now available.") introduced this bug.
>
> It introduced an architectural safety block inside
> arch_unregister_cpu(). If a hot-unplug operation is determined to be a
> physical hardware removal (where _STA evaluates to
> !ACPI_STA_DEVICE_PRESENT), it aborts the unregistration transaction
> early to protect unreadied arm64 infrastructure, thereby skipping
> unregister_cpu().
>
> However, the generic ACPI processor driver path in
> acpi_processor_post_eject() currently treats arch_unregister_cpu() as
> an unconditional void operation. When arch_unregister_cpu() bails out
> early, the subsequent cleanup flow blindly proceeds to call
> acpi_unmap_cpu(), clears global per-cpu processor arrays, and
> unconditionally free the 'struct acpi_processor' object.
>
> I think we can fix this by:
>
> 1. Refactoring arch_unregister_cpu() to return an integer
> transaction status. It returns -EOPNOTSUPP when aborting due to physical
> hot-remove blocking, -EINVAL/-EIO on firmware failures, and 0 only upon
> successful unregistration.
>
> 2. Guarding the downstream execution flow in
> acpi_processor_post_eject(). If arch_unregister_cpu() returns a error
> code, the hot-unplug transaction is considered aborted.
I wonder whether we need all this guarding. In the worst case, we could
rewrite the function, something like below, to always unregister and
only warn:
void arch_unregister_cpu(int cpu)
{
acpi_handle acpi_handle = acpi_get_processor_handle(cpu);
struct cpu *c = &per_cpu(cpu_devices, cpu);
acpi_status status;
unsigned long long sta;
if (!acpi_handle) {
pr_err_once("Removing a CPU without associated ACPI handle\n");
} else {
status = acpi_evaluate_integer(acpi_handle, "_STA", NULL, &sta);
if (!ACPI_FAILURE(status) &&
cpu_present(cpu) && !(sta & ACPI_STA_DEVICE_PRESENT))
pr_err_once("Changing CPU present bit is not supported\n");
}
unregister_cpu(c);
}
However, on the first condition, can we actually trigger !acpi_handle?
If not, we could just drop it. I tried to look up the paths and I don't
think we'd ever end up in this function with !acpi_handle. So this
leaves us with the next checks.
On the second/third conditions, it's more about preventing physical CPU
hotplug as we haven't properly defined it for arm yet but we could just
add a WARN_ONCE() to make it more visible and still proceed with the
unregistering. I think with your proposal, we don't fully unroll the
state anyway just by returning an error in arch_unregister_cpu(), so I'd
rather continue here.
What does firmware do for virtual CPU hotplug w.r.t. _STA? I noticed a
slight change in wording in the cpu-hotplug.rst doc with your patch from
On virtual systems the _STA method must always report the CPU as
``present``
to
On virtual systems the _STA method must report the CPU as ``present``
when it is activated by the firmware
Was your intention that _STA.PRESENT can become 0 when hot-unplugging
virtual CPUs?
--
Catalin
^ permalink raw reply
* Re: [PATCH] KVM: arm64: Hold kvm->mmu_lock while initialising vcpu->arch.vncr_tlb
From: Yosry Ahmed @ 2026-06-09 17:57 UTC (permalink / raw)
To: Marc Zyngier
Cc: kvmarm, kvm, linux-arm-kernel, Steffen Eiden, Joey Gouly,
Suzuki K Poulose, Oliver Upton, Zenghui Yu
In-Reply-To: <86ldcotbub.wl-maz@kernel.org>
> > If yes, I think the code looks confusing, at least to a layman like
> > myself. It initially seems like the lock protects against concurrent
> > initializations, but then the NULL check is not done again under the
> > lock. The goal of the lock is not clear without the original report.
> >
> > Mayeb it's clearer to explicitly use barriers if the goal is preventing
> > reordering?
>
> This would require both the initialisation of vncr_tlb to use a store
> release, *and* all the other call sites to use a load acquire.
>
> I really don't think it is worth the churn, nor the (very small)
> burden on the readers.
That's fair. I was mainly just pointing out my initial confusion and
that others may share it. Avoiding the churn on the readers' side is
understandable. Maybe a comment here would help explain why the lock
needs to be held?
^ permalink raw reply
* Re: [PATCH v2 1/4] dt-bindings: remoteproc: imx_rproc: document optional "memory-region-names"
From: Frank Li @ 2026-06-09 17:06 UTC (permalink / raw)
To: Mathieu Poirier
Cc: Laurentiu Mihalcea, Bjorn Andersson, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Sascha Hauer, Peng Fan,
Fabio Estevam, Daniel Baluta, Francesco Dolcini, linux-remoteproc,
devicetree, imx, linux-arm-kernel, linux-kernel
In-Reply-To: <aihB5rVLsVqzg6cb@p14s>
On Tue, Jun 09, 2026 at 10:40:06AM -0600, Mathieu Poirier wrote:
> [You don't often get email from mathieu.poirier@linaro.org. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ]
>
> On Fri, Jun 05, 2026 at 04:36:18AM -0700, Laurentiu Mihalcea wrote:
> > From: Laurentiu Mihalcea <laurentiu.mihalcea@nxp.com>
> >
> > The names of the carveout regions are derived using the names of the
> > reserved memory devicetree nodes, which are referenced using the
> > "memory-region" property. This adds a restriction on the names of said
> > devicetree nodes, often bearing specific names such as: "vdevbuffer",
> > "vdev0vring0", "rsc-table", etc... This goes against the devicetree
> > specification's recommendation, which states that the devicetree node
> > names should be generic.
>
> I don't see what is so restrictive in using the node name of the reserved-memory
> regions. Function of_reserved_mem_region_to_resource() is already doing all the
> parsing, packaging everything in a neat and easy to use "struct resource". What
> will you gain with this new "memory-region-names" that can't be done with the
> current solution?
DT Binding check can't find such wrong if node name is not what expected.
Binding can't restrict memory's node name because there ware not specific
compatible string for it.
Frank
>
> >
> > Fix this by documenting an additional, optional property:
> > "memory-region-names". This way, the carveout names can use the values
> > passed via "memory-region-names", while keeping the devicetree node
> > names of the reserved memory regions generic.
> >
> > There are no restrictions imposed on the values of the strings passed via
> > the new property since the software allows any name to be used, with some
> > names (e.g. "vdev%dbuffer", "vdev%dvring%d", "rsc-table") bearing a
> > special meaning.
> >
> > Signed-off-by: Laurentiu Mihalcea <laurentiu.mihalcea@nxp.com>
> > ---
> > .../devicetree/bindings/remoteproc/fsl,imx-rproc.yaml | 4 ++++
> > 1 file changed, 4 insertions(+)
> >
> > diff --git a/Documentation/devicetree/bindings/remoteproc/fsl,imx-rproc.yaml b/Documentation/devicetree/bindings/remoteproc/fsl,imx-rproc.yaml
> > index c18f71b64889..8e3e6676a95e 100644
> > --- a/Documentation/devicetree/bindings/remoteproc/fsl,imx-rproc.yaml
> > +++ b/Documentation/devicetree/bindings/remoteproc/fsl,imx-rproc.yaml
> > @@ -62,6 +62,10 @@ properties:
> > minItems: 1
> > maxItems: 32
> >
> > + memory-region-names:
> > + minItems: 1
> > + maxItems: 32
> > +
> > power-domains:
> > minItems: 2
> > maxItems: 8
> > --
> > 2.43.0
> >
>
^ permalink raw reply
* [PATCH v5 4/6] soc: samsung: exynos-pmu: add Exynos850 CPU hotplug support
From: Alexey Klimov @ 2026-06-09 17:39 UTC (permalink / raw)
To: Sam Protsenko, linux-samsung-soc, Krzysztof Kozlowski,
Peter Griffin
Cc: linux-samsung-soc, André Draszik, Tudor Ambarus, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Alim Akhtar, Henrik Grimler,
linux-arm-kernel, devicetree, linux-kernel
In-Reply-To: <20260609-exynos850-cpuhotplug-v5-0-8422cf80d43b@linaro.org>
Add cpuhotplug support for Exynos850 platforms. This SoC requires
its own specific set of writes/updates to PMU and PMU interrupts
generation block in order to put a CPU or a group of CPUs into
a different sleep states or prepare these entities for a CPU_OFF
or wake-up out of idle state or after CPU online.
Without these writes/updates the CPU(s) wake-up or online fails.
This also requires syscon regmap with raw spinlocks, so add
its initialisation to main exynos pmu probe() routine.
Signed-off-by: Alexey Klimov <alexey.klimov@linaro.org>
---
drivers/soc/samsung/Makefile | 2 +-
drivers/soc/samsung/exynos-pmu.c | 24 ++++++++
drivers/soc/samsung/exynos-pmu.h | 1 +
drivers/soc/samsung/exynos850-pmu.c | 95 +++++++++++++++++++++++++++++
include/linux/soc/samsung/exynos-regs-pmu.h | 5 ++
5 files changed, 126 insertions(+), 1 deletion(-)
diff --git a/drivers/soc/samsung/Makefile b/drivers/soc/samsung/Makefile
index 636a762608c9..7f544e3c1fcc 100644
--- a/drivers/soc/samsung/Makefile
+++ b/drivers/soc/samsung/Makefile
@@ -7,7 +7,7 @@ exynos_chipid-y += exynos-chipid.o exynos-asv.o
obj-$(CONFIG_EXYNOS_USI) += exynos-usi.o
obj-$(CONFIG_EXYNOS_PMU) += exynos_pmu.o
-exynos_pmu-y += exynos-pmu.o gs101-pmu.o
+exynos_pmu-y += exynos-pmu.o gs101-pmu.o exynos850-pmu.o
obj-$(CONFIG_EXYNOS_PMU_ARM_DRIVERS) += exynos3250-pmu.o exynos4-pmu.o \
exynos5250-pmu.o exynos5420-pmu.o
diff --git a/drivers/soc/samsung/exynos-pmu.c b/drivers/soc/samsung/exynos-pmu.c
index f170abe08ef1..cec0a7211c93 100644
--- a/drivers/soc/samsung/exynos-pmu.c
+++ b/drivers/soc/samsung/exynos-pmu.c
@@ -92,6 +92,14 @@ static const struct regmap_config regmap_smccfg = {
.use_raw_spinlock = true,
};
+static const struct regmap_config regmap_pmu = {
+ .name = "pmu_regs",
+ .reg_bits = 32,
+ .val_bits = 32,
+ .reg_stride = 4,
+ .use_raw_spinlock = true,
+};
+
static const struct regmap_config regmap_pmu_intr = {
.name = "pmu_intr_gen",
.reg_bits = 32,
@@ -133,6 +141,7 @@ static const struct of_device_id exynos_pmu_of_device_ids[] = {
.compatible = "samsung,exynos7-pmu",
}, {
.compatible = "samsung,exynos850-pmu",
+ .data = &exynos850_pmu_data,
},
{ /*sentinel*/ },
};
@@ -488,6 +497,21 @@ static int exynos_pmu_probe(struct platform_device *pdev)
ret = of_syscon_register_regmap(dev->of_node, regmap);
if (ret)
return ret;
+ /*
+ * For SoCs that support cpuhotplug/cpuidle via PMU updates callbacks.
+ * Such callbacks are executed under raw_spinlock so we need a custom
+ * regmap too.
+ */
+ } else if (pmu_context->pmu_data && pmu_context->pmu_data->pmu_cpuhp) {
+ regmap = devm_regmap_init_mmio(dev, pmu_base_addr, ®map_pmu);
+ if (IS_ERR(regmap))
+ return dev_err_probe(dev, PTR_ERR(regmap),
+ "hotplug regmap init failed\n");
+
+ ret = of_syscon_register_regmap(dev->of_node, regmap);
+ if (ret)
+ return dev_err_probe(dev, ret,
+ "failed to register hotplug regmap with syscon\n");
} else {
/* let syscon create mmio regmap */
regmap = syscon_node_to_regmap(dev->of_node);
diff --git a/drivers/soc/samsung/exynos-pmu.h b/drivers/soc/samsung/exynos-pmu.h
index 733e188fa2b1..4ecbf53cd4f7 100644
--- a/drivers/soc/samsung/exynos-pmu.h
+++ b/drivers/soc/samsung/exynos-pmu.h
@@ -104,6 +104,7 @@ extern const struct exynos_pmu_data exynos5250_pmu_data;
extern const struct exynos_pmu_data exynos5420_pmu_data;
#endif
extern const struct exynos_pmu_data gs101_pmu_data;
+extern const struct exynos_pmu_data exynos850_pmu_data;
extern void pmu_raw_writel(u32 val, u32 offset);
extern u32 pmu_raw_readl(u32 offset);
diff --git a/drivers/soc/samsung/exynos850-pmu.c b/drivers/soc/samsung/exynos850-pmu.c
new file mode 100644
index 000000000000..0503c54d6363
--- /dev/null
+++ b/drivers/soc/samsung/exynos850-pmu.c
@@ -0,0 +1,95 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright 2026 Linaro Ltd.
+ *
+ * Exynos850 PMU support
+ */
+
+#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
+
+#include <linux/bits.h>
+#include <linux/printk.h>
+#include <linux/regmap.h>
+#include <linux/soc/samsung/exynos-pmu.h>
+#include <linux/soc/samsung/exynos-regs-pmu.h>
+#include <linux/topology.h>
+#include <asm/cputype.h>
+
+#include "exynos-pmu.h"
+
+static int exynos850_cpu_pmu_offline(struct exynos_pmu_context *pmu_context, unsigned int cpu)
+ __must_hold(&pmu_context->cpupm_lock)
+{
+ int cluster_id, core_id;
+ u32 reg, mask;
+
+ cluster_id = topology_cluster_id(cpu);
+ if (cluster_id < 0) {
+ pr_err_ratelimited("invalid cluster ID for cpu: %u\n", cpu);
+ return -EINVAL;
+ }
+
+ core_id = topology_core_id(cpu);
+ if (core_id < 0) {
+ pr_err_ratelimited("invalid core ID for cpu: %u\n", cpu);
+ return -EINVAL;
+ }
+
+ /* set cpu inform hint */
+ regmap_write(pmu_context->pmureg, EXYNOS850_CPU_INFORM(cpu), CPU_INFORM_C2);
+
+ mask = BIT(cpu);
+ regmap_update_bits(pmu_context->pmuintrgen, EXYNOS_GRP2_INTR_BID_ENABLE,
+ mask, BIT(cpu));
+
+ regmap_read(pmu_context->pmuintrgen, EXYNOS_GRP1_INTR_BID_UPEND, ®);
+ regmap_write(pmu_context->pmuintrgen, EXYNOS_GRP1_INTR_BID_CLEAR, reg & mask);
+
+ mask = (BIT(cpu + 8));
+ regmap_read(pmu_context->pmuintrgen, EXYNOS_GRP1_INTR_BID_UPEND, ®);
+ regmap_write(pmu_context->pmuintrgen, EXYNOS_GRP1_INTR_BID_CLEAR, reg & mask);
+
+ regmap_update_bits(pmu_context->pmureg,
+ EXYNOS850_CLUSTER_CPU_INT_EN(cluster_id, core_id), 1 << 3, 1 << 3);
+ return 0;
+}
+
+static int exynos850_cpu_pmu_online(struct exynos_pmu_context *pmu_context, unsigned int cpu)
+ __must_hold(&pmu_context->cpupm_lock)
+{
+ int cluster_id, core_id;
+ u32 reg, mask;
+
+ cluster_id = topology_cluster_id(cpu);
+ if (cluster_id < 0) {
+ pr_err_ratelimited("invalid cluster ID for cpu: %u\n", cpu);
+ return -EINVAL;
+ }
+
+ core_id = topology_core_id(cpu);
+ if (core_id < 0) {
+ pr_err_ratelimited("invalid core ID for cpu: %u\n", cpu);
+ return -EINVAL;
+ }
+
+ /* clear cpu inform hint */
+ regmap_write(pmu_context->pmureg, EXYNOS850_CPU_INFORM(cpu), CPU_INFORM_CLEAR);
+
+ mask = BIT(cpu);
+ regmap_update_bits(pmu_context->pmuintrgen, EXYNOS_GRP2_INTR_BID_ENABLE,
+ mask, (0 << cpu));
+
+ regmap_read(pmu_context->pmuintrgen, EXYNOS_GRP2_INTR_BID_UPEND, ®);
+
+ regmap_write(pmu_context->pmuintrgen, EXYNOS_GRP2_INTR_BID_CLEAR, reg & mask);
+
+ regmap_update_bits(pmu_context->pmureg,
+ EXYNOS850_CLUSTER_CPU_INT_EN(cluster_id, core_id), 1 << 3, 0 << 3);
+ return 0;
+}
+
+const struct exynos_pmu_data exynos850_pmu_data = {
+ .pmu_cpuhp = true,
+ .cpu_pmu_offline = exynos850_cpu_pmu_offline,
+ .cpu_pmu_online = exynos850_cpu_pmu_online,
+};
diff --git a/include/linux/soc/samsung/exynos-regs-pmu.h b/include/linux/soc/samsung/exynos-regs-pmu.h
index 9c4d3da41dbf..c7a82635fc36 100644
--- a/include/linux/soc/samsung/exynos-regs-pmu.h
+++ b/include/linux/soc/samsung/exynos-regs-pmu.h
@@ -1015,6 +1015,11 @@
#define EXYNOS_GRP2_INTR_BID_UPEND (0x0208)
#define EXYNOS_GRP2_INTR_BID_CLEAR (0x020c)
+/* Exynos850 PMU Alive */
+#define EXYNOS850_CPU_INFORM(cpu) (0x0860 + ((cpu) & 7) * 4)
+#define EXYNOS850_CLUSTER_CPU_OFFSET(cl, cpu) (0x1000 + (((cl) * 0x400) + ((cpu) * 0x80)))
+#define EXYNOS850_CLUSTER_CPU_INT_EN(cl, cpu) (EXYNOS850_CLUSTER_CPU_OFFSET(cl, cpu) + 0x44)
+
/* exynosautov920 */
#define EXYNOSAUTOV920_PHY_CTRL_USB20 (0x0710)
#define EXYNOSAUTOV920_PHY_CTRL_USB31 (0x0714)
--
2.51.0
^ permalink raw reply related
* [PATCH v5 6/6] arm64: dts: exynos850: add PMU interrupt generation node
From: Alexey Klimov @ 2026-06-09 17:39 UTC (permalink / raw)
To: Sam Protsenko, linux-samsung-soc, Krzysztof Kozlowski,
Peter Griffin
Cc: linux-samsung-soc, André Draszik, Tudor Ambarus, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Alim Akhtar, Henrik Grimler,
linux-arm-kernel, devicetree, linux-kernel
In-Reply-To: <20260609-exynos850-cpuhotplug-v5-0-8422cf80d43b@linaro.org>
Add pmu_intr_gen node for Exynos850. This hw block is required
for different power management routines like CPU hotplug and
different sleep and idle states.
Also reference this node from main PMU node.
Reviewed-by: Peter Griffin <peter.griffin@linaro.org>
Signed-off-by: Alexey Klimov <alexey.klimov@linaro.org>
---
arch/arm64/boot/dts/exynos/exynos850.dtsi | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/arch/arm64/boot/dts/exynos/exynos850.dtsi b/arch/arm64/boot/dts/exynos/exynos850.dtsi
index 3881f573ec08..04662b1c5458 100644
--- a/arch/arm64/boot/dts/exynos/exynos850.dtsi
+++ b/arch/arm64/boot/dts/exynos/exynos850.dtsi
@@ -214,6 +214,7 @@ gic: interrupt-controller@12a01000 {
pmu_system_controller: system-controller@11860000 {
compatible = "samsung,exynos850-pmu", "syscon";
reg = <0x11860000 0x10000>;
+ google,pmu-intr-gen-syscon = <&pmu_intr_gen>;
poweroff: syscon-poweroff {
compatible = "syscon-poweroff";
@@ -231,6 +232,11 @@ reboot: syscon-reboot {
};
};
+ pmu_intr_gen: syscon@11870000 {
+ compatible = "samsung,exynos850-pmu-intr-gen", "syscon";
+ reg = <0x11870000 0x10000>;
+ };
+
watchdog_cl0: watchdog@10050000 {
compatible = "samsung,exynos850-wdt";
reg = <0x10050000 0x100>;
--
2.51.0
^ permalink raw reply related
* [PATCH v5 5/6] MAINTAINERS: add Exynos850 PMU entry
From: Alexey Klimov @ 2026-06-09 17:39 UTC (permalink / raw)
To: Sam Protsenko, linux-samsung-soc, Krzysztof Kozlowski,
Peter Griffin
Cc: linux-samsung-soc, André Draszik, Tudor Ambarus, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Alim Akhtar, Henrik Grimler,
linux-arm-kernel, devicetree, linux-kernel
In-Reply-To: <20260609-exynos850-cpuhotplug-v5-0-8422cf80d43b@linaro.org>
Add Exynos850 PMU entry describing new file
drivers/soc/samsung/exynos850-pmu.c.
Add myself as M there since I contributed Exynos850
PMU support and intend to maintain that.
Signed-off-by: Alexey Klimov <alexey.klimov@linaro.org>
---
MAINTAINERS | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 498ca30a00c5..60c25fed8ffa 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -23645,6 +23645,13 @@ F: arch/arm64/boot/dts/exynos/exynos2200*
F: drivers/clk/samsung/clk-exynos2200.c
F: include/dt-bindings/clock/samsung,exynos2200-cmu.h
+SAMSUNG EXYNOS850 PMU SUPPORT
+M: Alexey Klimov <alexey.klimov@linaro.org>
+L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
+L: linux-samsung-soc@vger.kernel.org
+S: Maintained
+F: drivers/soc/samsung/exynos850-pmu.c
+
SAMSUNG EXYNOS850 SoC SUPPORT
M: Sam Protsenko <semen.protsenko@linaro.org>
L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
--
2.51.0
^ permalink raw reply related
* [PATCH v5 3/6] soc: samsung: exynos-pmu: generalise gs101-specific cpu{idle,hotplug} for Exynos SoCs
From: Alexey Klimov @ 2026-06-09 17:39 UTC (permalink / raw)
To: Sam Protsenko, linux-samsung-soc, Krzysztof Kozlowski,
Peter Griffin
Cc: linux-samsung-soc, André Draszik, Tudor Ambarus, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Alim Akhtar, Henrik Grimler,
linux-arm-kernel, devicetree, linux-kernel
In-Reply-To: <20260609-exynos850-cpuhotplug-v5-0-8422cf80d43b@linaro.org>
The cpuhotplug and cpuidle support for GS101-based SoCs which
utilizes GS101 PMU interrupts generation block can be generalised
to be (re)used for other Exynos-based SoCs. Also, the GS101 PMU
interrupts generation block is not exclusive to Google GS101 SoCs
and should be made more Exynos-generic.
Specifically, apply the following changes:
- rename gs101-specific calls, structs, names to be exynos-prefixed;
- move exynos_pmu_context and CPU_INFORM_* defines into exynos-pmu.h;
- introduce cpu_pmu_{offline,online} callbacks in driver-specific
exynos_pmu_data which can be used to hold PMU and PMU intr gen
update routines for different platforms and update cpuidle and cpuhotplug
support to use them;
- add checks for the presense of cpu_pmu_{offline,online} callbacks;
- move and rename gs101-specific cpu{offline,online} PMU updates
routines into gs101-pmu.c file, also removing underscore prefix;
- update gs101_pmu_data to use newly introduced callbacks;
- rename PMU interrupts generation GS101_INTR_* regs to EXYNOS_INTR_*.
This allows other platforms to add cpuhotplug and cpuidle support in
a similar manner, using their own platform-specific PMU and
PMU intr gen update routines.
Reviewed-by: Peter Griffin <peter.griffin@linaro.org>
Tested-by: Peter Griffin <peter.griffin@linaro.org>
Signed-off-by: Alexey Klimov <alexey.klimov@linaro.org>
---
drivers/soc/samsung/exynos-pmu.c | 122 ++++++----------------------
drivers/soc/samsung/exynos-pmu.h | 33 ++++++++
drivers/soc/samsung/gs101-pmu.c | 49 +++++++++++
include/linux/soc/samsung/exynos-regs-pmu.h | 10 +--
4 files changed, 112 insertions(+), 102 deletions(-)
diff --git a/drivers/soc/samsung/exynos-pmu.c b/drivers/soc/samsung/exynos-pmu.c
index 846313a28e9a..f170abe08ef1 100644
--- a/drivers/soc/samsung/exynos-pmu.c
+++ b/drivers/soc/samsung/exynos-pmu.c
@@ -24,24 +24,6 @@
#include "exynos-pmu.h"
-struct exynos_pmu_context {
- struct device *dev;
- const struct exynos_pmu_data *pmu_data;
- struct regmap *pmureg;
- struct regmap *pmuintrgen;
- /*
- * Serialization lock for CPU hot plug and cpuidle ACPM hint
- * programming. Also protects in_cpuhp, sys_insuspend & sys_inreboot
- * flags.
- */
- raw_spinlock_t cpupm_lock;
- unsigned long *in_cpuhp;
- bool sys_insuspend;
- bool sys_inreboot;
- int cpuhp_prepare_state;
- int cpuhp_online_state;
-};
-
void __iomem *pmu_base_addr;
static struct exynos_pmu_context *pmu_context;
/* forward declaration */
@@ -221,43 +203,8 @@ struct regmap *exynos_get_pmu_regmap_by_phandle(struct device_node *np,
}
EXPORT_SYMBOL_GPL(exynos_get_pmu_regmap_by_phandle);
-/*
- * CPU_INFORM register "hint" values are required to be programmed in addition to
- * the standard PSCI calls to have functional CPU hotplug and CPU idle states.
- * This is required to workaround limitations in the el3mon/ACPM firmware.
- */
-#define CPU_INFORM_CLEAR 0
-#define CPU_INFORM_C2 1
-
-/*
- * __gs101_cpu_pmu_ prefix functions are common code shared by CPU PM notifiers
- * (CPUIdle) and CPU hotplug callbacks. Functions should be called with IRQs
- * disabled and cpupm_lock held.
- */
-static int __gs101_cpu_pmu_online(unsigned int cpu)
- __must_hold(&pmu_context->cpupm_lock)
-{
- u32 reg, mask;
-
- /* clear cpu inform hint */
- regmap_write(pmu_context->pmureg, GS101_CPU_INFORM(cpu),
- CPU_INFORM_CLEAR);
-
- mask = BIT(cpu);
-
- regmap_update_bits(pmu_context->pmuintrgen, GS101_GRP2_INTR_BID_ENABLE,
- mask, (0 << cpu));
-
- regmap_read(pmu_context->pmuintrgen, GS101_GRP2_INTR_BID_UPEND, ®);
-
- regmap_write(pmu_context->pmuintrgen, GS101_GRP2_INTR_BID_CLEAR,
- reg & mask);
-
- return 0;
-}
-
/* Called from CPU PM notifier (CPUIdle code path) with IRQs disabled */
-static int gs101_cpu_pmu_online(void)
+static int exynos_cpu_pmu_online(void)
{
int cpu;
@@ -269,20 +216,20 @@ static int gs101_cpu_pmu_online(void)
}
cpu = smp_processor_id();
- __gs101_cpu_pmu_online(cpu);
+ pmu_context->pmu_data->cpu_pmu_online(pmu_context, cpu);
raw_spin_unlock(&pmu_context->cpupm_lock);
return NOTIFY_OK;
}
/* Called from CPU hot plug callback with IRQs enabled */
-static int gs101_cpuhp_pmu_online(unsigned int cpu)
+static int exynos_cpuhp_pmu_online(unsigned int cpu)
{
unsigned long flags;
raw_spin_lock_irqsave(&pmu_context->cpupm_lock, flags);
- __gs101_cpu_pmu_online(cpu);
+ pmu_context->pmu_data->cpu_pmu_online(pmu_context, cpu);
/*
* Mark this CPU as having finished the hotplug.
* This means this CPU can now enter C2 idle state.
@@ -293,33 +240,8 @@ static int gs101_cpuhp_pmu_online(unsigned int cpu)
return 0;
}
-/* Common function shared by both CPU hot plug and CPUIdle */
-static int __gs101_cpu_pmu_offline(unsigned int cpu)
- __must_hold(&pmu_context->cpupm_lock)
-{
- u32 reg, mask;
-
- /* set cpu inform hint */
- regmap_write(pmu_context->pmureg, GS101_CPU_INFORM(cpu), CPU_INFORM_C2);
-
- mask = BIT(cpu);
- regmap_update_bits(pmu_context->pmuintrgen, GS101_GRP2_INTR_BID_ENABLE,
- mask, BIT(cpu));
-
- regmap_read(pmu_context->pmuintrgen, GS101_GRP1_INTR_BID_UPEND, ®);
- regmap_write(pmu_context->pmuintrgen, GS101_GRP1_INTR_BID_CLEAR,
- reg & mask);
-
- mask = (BIT(cpu + 8));
- regmap_read(pmu_context->pmuintrgen, GS101_GRP1_INTR_BID_UPEND, ®);
- regmap_write(pmu_context->pmuintrgen, GS101_GRP1_INTR_BID_CLEAR,
- reg & mask);
-
- return 0;
-}
-
/* Called from CPU PM notifier (CPUIdle code path) with IRQs disabled */
-static int gs101_cpu_pmu_offline(void)
+static int exynos_cpu_pmu_offline(void)
{
int cpu;
@@ -337,14 +259,14 @@ static int gs101_cpu_pmu_offline(void)
return NOTIFY_OK;
}
- __gs101_cpu_pmu_offline(cpu);
+ pmu_context->pmu_data->cpu_pmu_offline(pmu_context, cpu);
raw_spin_unlock(&pmu_context->cpupm_lock);
return NOTIFY_OK;
}
/* Called from CPU hot plug callback with IRQs enabled */
-static int gs101_cpuhp_pmu_offline(unsigned int cpu)
+static int exynos_cpuhp_pmu_offline(unsigned int cpu)
{
unsigned long flags;
@@ -354,29 +276,29 @@ static int gs101_cpuhp_pmu_offline(unsigned int cpu)
* ACPM the CPU entering hotplug should not enter C2 idle state.
*/
set_bit(cpu, pmu_context->in_cpuhp);
- __gs101_cpu_pmu_offline(cpu);
+ pmu_context->pmu_data->cpu_pmu_offline(pmu_context, cpu);
raw_spin_unlock_irqrestore(&pmu_context->cpupm_lock, flags);
return 0;
}
-static int gs101_cpu_pm_notify_callback(struct notifier_block *self,
+static int exynos_cpu_pm_notify_callback(struct notifier_block *self,
unsigned long action, void *v)
{
switch (action) {
case CPU_PM_ENTER:
- return gs101_cpu_pmu_offline();
+ return exynos_cpu_pmu_offline();
case CPU_PM_EXIT:
- return gs101_cpu_pmu_online();
+ return exynos_cpu_pmu_online();
}
return NOTIFY_OK;
}
-static struct notifier_block gs101_cpu_pm_notifier = {
- .notifier_call = gs101_cpu_pm_notify_callback,
+static struct notifier_block exynos_cpu_pm_notifier = {
+ .notifier_call = exynos_cpu_pm_notify_callback,
/*
* We want to be called first, as the ACPM hint and handshake is what
* puts the CPU into C2.
@@ -408,7 +330,7 @@ static struct notifier_block exynos_cpupm_reboot_nb = {
static void destroy_cpuhp_and_cpuidle(void)
{
- cpu_pm_unregister_notifier(&gs101_cpu_pm_notifier);
+ cpu_pm_unregister_notifier(&exynos_cpu_pm_notifier);
unregister_reboot_notifier(&exynos_cpupm_reboot_nb);
if (pmu_context->cpuhp_prepare_state != CPUHP_INVALID)
@@ -424,6 +346,12 @@ static int setup_cpuhp_and_cpuidle(struct device *dev)
void __iomem *virt_addr;
int ret, cpu;
+ if (!pmu_context->pmu_data->cpu_pmu_offline || !pmu_context->pmu_data->cpu_pmu_online) {
+ dev_err(dev,
+ "PMU write/update sequence is not present for cpuhotplug and cpuidle\n");
+ return -ENODEV;
+ }
+
intr_gen_node = of_parse_phandle(dev->of_node,
"google,pmu-intr-gen-syscon", 0);
if (!intr_gen_node) {
@@ -475,28 +403,28 @@ static int setup_cpuhp_and_cpuidle(struct device *dev)
/* set PMU to power on */
for_each_online_cpu(cpu)
- gs101_cpuhp_pmu_online(cpu);
+ exynos_cpuhp_pmu_online(cpu);
/* register CPU hotplug callbacks */
pmu_context->cpuhp_prepare_state = CPUHP_INVALID;
pmu_context->cpuhp_online_state = CPUHP_INVALID;
ret = cpuhp_setup_state(CPUHP_BP_PREPARE_DYN, "soc/exynos-pmu:prepare",
- gs101_cpuhp_pmu_online, NULL);
+ exynos_cpuhp_pmu_online, NULL);
if (ret < 0)
return ret;
pmu_context->cpuhp_prepare_state = ret;
ret = cpuhp_setup_state(CPUHP_AP_ONLINE_DYN, "soc/exynos-pmu:online",
- NULL, gs101_cpuhp_pmu_offline);
+ NULL, exynos_cpuhp_pmu_offline);
if (ret < 0)
goto clean_cpuhp_states;
pmu_context->cpuhp_online_state = ret;
/* register CPU PM notifiers for cpuidle */
- ret = cpu_pm_register_notifier(&gs101_cpu_pm_notifier);
+ ret = cpu_pm_register_notifier(&exynos_cpu_pm_notifier);
if (ret)
goto clean_cpuhp_states;
@@ -505,7 +433,7 @@ static int setup_cpuhp_and_cpuidle(struct device *dev)
/* Success */
return ret;
- cpu_pm_unregister_notifier(&gs101_cpu_pm_notifier);
+ cpu_pm_unregister_notifier(&exynos_cpu_pm_notifier);
clean_cpuhp_states:
if (pmu_context->cpuhp_prepare_state != CPUHP_INVALID)
diff --git a/drivers/soc/samsung/exynos-pmu.h b/drivers/soc/samsung/exynos-pmu.h
index fbe381e2a2e1..733e188fa2b1 100644
--- a/drivers/soc/samsung/exynos-pmu.h
+++ b/drivers/soc/samsung/exynos-pmu.h
@@ -13,6 +13,14 @@
#define PMU_TABLE_END (-1U)
+/*
+ * CPU_INFORM register "hint" values are required to be programmed in addition to
+ * the standard PSCI calls to have functional CPU hotplug and CPU idle states.
+ * This is required to workaround limitations in the el3mon/ACPM firmware.
+ */
+#define CPU_INFORM_CLEAR 0
+#define CPU_INFORM_C2 1
+
struct regmap_access_table;
struct exynos_pmu_conf {
@@ -20,6 +28,24 @@ struct exynos_pmu_conf {
u8 val[NUM_SYS_POWERDOWN];
};
+struct exynos_pmu_context {
+ struct device *dev;
+ const struct exynos_pmu_data *pmu_data;
+ struct regmap *pmureg;
+ struct regmap *pmuintrgen;
+ /*
+ * Serialization lock for CPU hot plug and cpuidle ACPM hint
+ * programming. Also protects in_cpuhp, sys_insuspend & sys_inreboot
+ * flags.
+ */
+ raw_spinlock_t cpupm_lock;
+ unsigned long *in_cpuhp;
+ bool sys_insuspend;
+ bool sys_inreboot;
+ int cpuhp_prepare_state;
+ int cpuhp_online_state;
+};
+
/**
* struct exynos_pmu_data - of_device_id (match) data
*
@@ -44,6 +70,10 @@ struct exynos_pmu_conf {
* used (i.e. when @pmu_secure is @true).
* @wr_table: A table of writable register ranges in case a custom regmap is
* used (i.e. when @pmu_secure is @true).
+ * @cpu_pmu_offline: Optional callback to be called before entering CPU offline
+ * or idle state. Only valid when pmu_cpuhp set to true.
+ * @cpu_pmu_online: Optional callback to be called after CPU onlined or after
+ * exiting idle state. Only valid when pmu_cpuhp set to true.
*/
struct exynos_pmu_data {
const struct exynos_pmu_conf *pmu_config;
@@ -57,6 +87,9 @@ struct exynos_pmu_data {
const struct regmap_access_table *rd_table;
const struct regmap_access_table *wr_table;
+
+ int (*cpu_pmu_offline)(struct exynos_pmu_context *pmu_context, unsigned int cpu);
+ int (*cpu_pmu_online)(struct exynos_pmu_context *pmu_context, unsigned int cpu);
};
extern void __iomem *pmu_base_addr;
diff --git a/drivers/soc/samsung/gs101-pmu.c b/drivers/soc/samsung/gs101-pmu.c
index 17dadc1b9c6e..ec75ff062ce0 100644
--- a/drivers/soc/samsung/gs101-pmu.c
+++ b/drivers/soc/samsung/gs101-pmu.c
@@ -322,11 +322,60 @@ static const struct regmap_access_table gs101_pmu_wr_table = {
.n_no_ranges = ARRAY_SIZE(gs101_pmu_ro_registers),
};
+/*
+ * gs101_cpu_pmu_ prefix functions are common code shared by CPU PM notifiers
+ * (CPUIdle) and CPU hotplug callbacks. Functions should be called with IRQs
+ * disabled and cpupm_lock held.
+ */
+static int gs101_cpu_pmu_online(struct exynos_pmu_context *pmu_context, unsigned int cpu)
+ __must_hold(&pmu_context->cpupm_lock)
+{
+ u32 reg, mask;
+
+ /* clear cpu inform hint */
+ regmap_write(pmu_context->pmureg, GS101_CPU_INFORM(cpu), CPU_INFORM_CLEAR);
+
+ mask = BIT(cpu);
+ regmap_update_bits(pmu_context->pmuintrgen, EXYNOS_GRP2_INTR_BID_ENABLE,
+ mask, (0 << cpu));
+
+ regmap_read(pmu_context->pmuintrgen, EXYNOS_GRP2_INTR_BID_UPEND, ®);
+
+ regmap_write(pmu_context->pmuintrgen, EXYNOS_GRP2_INTR_BID_CLEAR, reg & mask);
+
+ return 0;
+}
+
+/* Common function shared by both CPU hot plug and CPUIdle */
+static int gs101_cpu_pmu_offline(struct exynos_pmu_context *pmu_context, unsigned int cpu)
+ __must_hold(&pmu_context->cpupm_lock)
+{
+ u32 reg, mask;
+
+ /* set cpu inform hint */
+ regmap_write(pmu_context->pmureg, GS101_CPU_INFORM(cpu), CPU_INFORM_C2);
+
+ mask = BIT(cpu);
+ regmap_update_bits(pmu_context->pmuintrgen, EXYNOS_GRP2_INTR_BID_ENABLE,
+ mask, BIT(cpu));
+
+ regmap_read(pmu_context->pmuintrgen, EXYNOS_GRP1_INTR_BID_UPEND, ®);
+ regmap_write(pmu_context->pmuintrgen, EXYNOS_GRP1_INTR_BID_CLEAR, reg & mask);
+
+ mask = (BIT(cpu + 8));
+ regmap_read(pmu_context->pmuintrgen, EXYNOS_GRP1_INTR_BID_UPEND, ®);
+ regmap_write(pmu_context->pmuintrgen, EXYNOS_GRP1_INTR_BID_CLEAR, reg & mask);
+
+ return 0;
+}
+
const struct exynos_pmu_data gs101_pmu_data = {
.pmu_secure = true,
.pmu_cpuhp = true,
.rd_table = &gs101_pmu_rd_table,
.wr_table = &gs101_pmu_wr_table,
+ .cpu_pmu_offline = gs101_cpu_pmu_offline,
+ .cpu_pmu_online = gs101_cpu_pmu_online,
};
/*
diff --git a/include/linux/soc/samsung/exynos-regs-pmu.h b/include/linux/soc/samsung/exynos-regs-pmu.h
index db8a7ca81080..9c4d3da41dbf 100644
--- a/include/linux/soc/samsung/exynos-regs-pmu.h
+++ b/include/linux/soc/samsung/exynos-regs-pmu.h
@@ -1009,11 +1009,11 @@
#define GS101_PHY_CTRL_UFS 0x3ec8
/* PMU INTR GEN */
-#define GS101_GRP1_INTR_BID_UPEND (0x0108)
-#define GS101_GRP1_INTR_BID_CLEAR (0x010c)
-#define GS101_GRP2_INTR_BID_ENABLE (0x0200)
-#define GS101_GRP2_INTR_BID_UPEND (0x0208)
-#define GS101_GRP2_INTR_BID_CLEAR (0x020c)
+#define EXYNOS_GRP1_INTR_BID_UPEND (0x0108)
+#define EXYNOS_GRP1_INTR_BID_CLEAR (0x010c)
+#define EXYNOS_GRP2_INTR_BID_ENABLE (0x0200)
+#define EXYNOS_GRP2_INTR_BID_UPEND (0x0208)
+#define EXYNOS_GRP2_INTR_BID_CLEAR (0x020c)
/* exynosautov920 */
#define EXYNOSAUTOV920_PHY_CTRL_USB20 (0x0710)
--
2.51.0
^ permalink raw reply related
* [PATCH v5 2/6] dt-bindings: soc: samsung: exynos-pmu: Require pmu-intr-gen-syscon for Exynos850
From: Alexey Klimov @ 2026-06-09 17:39 UTC (permalink / raw)
To: Sam Protsenko, linux-samsung-soc, Krzysztof Kozlowski,
Peter Griffin
Cc: linux-samsung-soc, André Draszik, Tudor Ambarus, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Alim Akhtar, Henrik Grimler,
linux-arm-kernel, devicetree, linux-kernel
In-Reply-To: <20260609-exynos850-cpuhotplug-v5-0-8422cf80d43b@linaro.org>
Update the Exynos PMU schema to mandate the 'google,pmu-intr-gen-syscon'
property for the 'samsung,exynos850-pmu' compatible so the driver can
obtain the necessary syscon regmap.
The Exynos850 PMU relies on a separate system controller block to handle
interrupts generation, similar to the hardware design of the GS101
SoC. To ensure the hardware is correctly described, this syscon phandle
must be explicitly provided.
Reviewed-by: Peter Griffin <peter.griffin@linaro.org>
Acked-by: Rob Herring (Arm) <robh@kernel.org>
Signed-off-by: Alexey Klimov <alexey.klimov@linaro.org>
---
Documentation/devicetree/bindings/soc/samsung/exynos-pmu.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/soc/samsung/exynos-pmu.yaml b/Documentation/devicetree/bindings/soc/samsung/exynos-pmu.yaml
index 76ce7e98c10f..6550c3736a3b 100644
--- a/Documentation/devicetree/bindings/soc/samsung/exynos-pmu.yaml
+++ b/Documentation/devicetree/bindings/soc/samsung/exynos-pmu.yaml
@@ -182,6 +182,7 @@ allOf:
contains:
enum:
- google,gs101-pmu
+ - samsung,exynos850-pmu
then:
required:
- google,pmu-intr-gen-syscon
--
2.51.0
^ permalink raw reply related
* [PATCH v5 1/6] dt-bindings: soc: move,rename google,gs101-pmu-intr-gen and add exynos850
From: Alexey Klimov @ 2026-06-09 17:39 UTC (permalink / raw)
To: Sam Protsenko, linux-samsung-soc, Krzysztof Kozlowski,
Peter Griffin
Cc: linux-samsung-soc, André Draszik, Tudor Ambarus, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Alim Akhtar, Henrik Grimler,
linux-arm-kernel, devicetree, linux-kernel
In-Reply-To: <20260609-exynos850-cpuhotplug-v5-0-8422cf80d43b@linaro.org>
The PMU interrupt generation block introduced for the Google GS101 is
actually a standard Samsung Exynos IP block found in older SoCs, such
as the Exynos850, and is not exclusive to Google SoCs. To accurately
reflect its origin, move the schema file to under soc/samsung/
directory and rename it.
Concurrently, add the new "samsung,exynos850-pmu-intr-gen" compatible
string to the bindings. Support for this block is required to enable
power management features like CPU hotplug and idle states on Exynos850
platforms.
Also, move this file under Exynos850 SoC in MAINTAINERS entry.
Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
Signed-off-by: Alexey Klimov <alexey.klimov@linaro.org>
---
.../samsung,exynos850-pmu-intr-gen.yaml} | 8 +++++---
MAINTAINERS | 2 +-
2 files changed, 6 insertions(+), 4 deletions(-)
diff --git a/Documentation/devicetree/bindings/soc/google/google,gs101-pmu-intr-gen.yaml b/Documentation/devicetree/bindings/soc/samsung/samsung,exynos850-pmu-intr-gen.yaml
similarity index 70%
rename from Documentation/devicetree/bindings/soc/google/google,gs101-pmu-intr-gen.yaml
rename to Documentation/devicetree/bindings/soc/samsung/samsung,exynos850-pmu-intr-gen.yaml
index 2be022ca6a7d..df23467d0e0e 100644
--- a/Documentation/devicetree/bindings/soc/google/google,gs101-pmu-intr-gen.yaml
+++ b/Documentation/devicetree/bindings/soc/samsung/samsung,exynos850-pmu-intr-gen.yaml
@@ -1,10 +1,10 @@
# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
%YAML 1.2
---
-$id: http://devicetree.org/schemas/soc/google/google,gs101-pmu-intr-gen.yaml#
+$id: http://devicetree.org/schemas/soc/samsung/samsung,exynos850-pmu-intr-gen.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Google Power Management Unit (PMU) Interrupt Generation
+title: Samsung Power Management Unit (PMU) Interrupt Generation
description: |
PMU interrupt generator for handshaking between PMU through interrupts.
@@ -15,7 +15,9 @@ maintainers:
properties:
compatible:
items:
- - const: google,gs101-pmu-intr-gen
+ - enum:
+ - google,gs101-pmu-intr-gen
+ - samsung,exynos850-pmu-intr-gen
- const: syscon
reg:
diff --git a/MAINTAINERS b/MAINTAINERS
index 86ca9297edab..498ca30a00c5 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -10952,7 +10952,6 @@ P: Documentation/process/maintainer-soc-clean-dts.rst
C: irc://irc.oftc.net/pixel6-kernel-dev
F: Documentation/devicetree/bindings/clock/google,gs101-clock.yaml
F: Documentation/devicetree/bindings/phy/google,lga-usb-phy.yaml
-F: Documentation/devicetree/bindings/soc/google/google,gs101-pmu-intr-gen.yaml
F: Documentation/devicetree/bindings/usb/google,lga-dwc3.yaml
F: arch/arm64/boot/dts/exynos/google/
F: drivers/clk/samsung/clk-gs101.c
@@ -23652,6 +23651,7 @@ L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
L: linux-samsung-soc@vger.kernel.org
S: Maintained
F: Documentation/devicetree/bindings/clock/samsung,exynos850-clock.yaml
+F: Documentation/devicetree/bindings/soc/samsung/samsung,exynos850-pmu-intr-gen.yaml
F: arch/arm64/boot/dts/exynos/exynos850*
F: drivers/clk/samsung/clk-exynos850.c
F: include/dt-bindings/clock/exynos850.h
--
2.51.0
^ permalink raw reply related
* [PATCH v5 0/6] Exynos-pmu: Generalise cpu{hotplug,idle},PMU intr gen and add Exynos850 CPU hotplug
From: Alexey Klimov @ 2026-06-09 17:39 UTC (permalink / raw)
To: Sam Protsenko, linux-samsung-soc, Krzysztof Kozlowski,
Peter Griffin
Cc: linux-samsung-soc, André Draszik, Tudor Ambarus, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Alim Akhtar, Henrik Grimler,
linux-arm-kernel, devicetree, linux-kernel
Series generalises the GS101-specific cpuhotplug, cpuidle and PMU interrupt
generation block support, which is currently implemented specifically for
the google GS101 SoC, to make it reusable by other Samsung Exynos SoCs.
The PMU interrupt generation IP block introduced for google GS101 is a
standard Samsung Exynos block found in other SoCs, including Exynos850,
and it is not strictly exclusive to google Exynos-based platforms.
Access to this block is required to implement and enable cpuhotplug
on Exynos850-based boards.
As a next steps it will be possible to enable idle states on top of it
(if we get our hands on corrected firmware).
First patches work on DT bindings to reflect that Exynos850 SoC predates
gs101 one and adding mandatory property 'google,pmu-intr-gen-syscon'
for exynos850-pmu.
Then series generalises ("Exynosizes") cpuhotplug/cpuidle routines by
deferring platform-specific PMU and PMU-intr-gen updates to platform-
specific callbacks and then finally introduces new file exynos850-pmu.c
where such callbacks are implemented for Exynos850. Last commit adds
pmu_intr_gen DT node to exynos850.dtsi.
This series wants Exynos PMU "fixes" series first to make Sashiko bot
happy. This "dependency" describes sequential order of commits.
https://lore.kernel.org/linux-samsung-soc/20260605-exynos-pmu-cpuhp-idle-fixes-v1-0-0cd05c81a82d@linaro.org/
The main updates are custom regmap for pmu regs to support PREEMPT_RT
cases -- we need raw_spinlocks there, minor adjustments in exynos850-pmu.c
and "fixes" series mostly reported by Sashiko bot here:
https://sashiko.dev/#/patchset/20260513-exynos850-cpuhotplug-v4-0-54fec5f65362@linaro.org?part=4
This series was re-tested on Exynos850 WinLink E850-96 board:
-- by spinning "chcpu -d 1-7; chcpu -e 1-7" in a loop for a few hours;
-- by running script [1] that randomly offlines or onlines random cpus
for a few hours.
I tried to implement it in way to not break anything for gs101, thanks to
Peter for testing.
Thanks,
Alexey
[1]: https://github.com/laklimov/xlam/blob/main/e850_cpuhotplug_random.sh
Signed-off-by: Alexey Klimov <alexey.klimov@linaro.org>
---
Changes in v5:
- updated the commit message of ("soc: samsung: exynos-pmu: add Exynos850
CPU hotplug support");
- the if-check for the presense of pmu_data->cpu_pmu_{offline,online}
callbacks in setup_cpuhp_and_cpuidle() was moved to before acquiring ref
counter to intr_gen_node (the initial issue was reported by Sashiko);
- added pr_fmt to exynos850-pmu.c to have more meaningful error
messages;
- added parentheses around the `cl` in `EXYNOS850_CLUSTER_CPU_OFFSET` macro
(as suggested by Sashiko bot);
- custom syscon regmap with raw_spinlocks for pmu offline/online callbacks
(the initial issue was reported by Sashiko);
- using topology_cluster_id() and topology_core_id() in exynos850-pmu.c
(the initial issue was reported by Sashiko);
- removed smp_processor_id() usage fomr pmu offline/online callbacks
(the initial issue was reported by Sashiko);
- added/resorted headers in exynos850-pmu.c;
- Link to v4: https://lore.kernel.org/r/20260513-exynos850-cpuhotplug-v4-0-54fec5f65362@linaro.org
Changes in v4:
- remove blank line in file exynos850-pmu.c, commit (as suggested by Krzysztof);
- only update trailers/tags in commit messages;
- Link to v3: https://lore.kernel.org/r/20260430-exynos850-cpuhotplug-v3-0-fd6251d02a17@linaro.org
Changes in v3:
- dropped two commits where samsung,pmu-intr-gen phandle is introduced and
where google,pmu-intr-gen-syscon is deprecated (as suggested by Rob Herring);
- addtion to maintainers file was moved to separate entry, change commit message;
- commit message in "generalise gs101-specific cpu{idle,hotplug} for Exynos SoCs"
was updated since it no longer touches samsung,pmu-intr-gen-syscon;
- added missing asm/cputype.h header to exynos850-pmu.h
(reported by Henrik Grimler);
- new commit "dt-bindings: soc: samsung: exynos-pmu: Require
pmu-intr-gen-syscon for Exynos850";
- Link to v2: https://lore.kernel.org/r/20260401-exynos850-cpuhotplug-v2-0-c5a760a3e259@linaro.org
Changes in v2:
- moved gs101 cpu {offline,online} callbacks to gs101-pmu.c, updated MAINTAINERS;
- added new file exynos850-pmu.c with cpu {offline,online} callbacks and
exynos850 pmu data;
- new patch that adds exynos850-pmu.c to MAINTAINERS;
- moved pmu_intr_gen to right after pmu_system_controller@11860000;
- merged two patches that update google,gs101-pmu-intr-gen.yaml together,
now rename and adding exynos850 entry goes in a single patch;
- commits 5 and 6 from RFC series are merged together and reworked,
cpu_pmu_{offline,online} callbacks are moved into pmu_data struct, and
callbacks now need pmu_context as an argument, exynos_pmu_context and
CPU_INFORM defines are moved to exynos-pmu.h, gs101 callbacks
renamed. It is really better to check commit description.
- Link to RFC (v1 from b4 point of view):
https://lore.kernel.org/r/20260226-exynos850-cpuhotplug-v1-0-71d7c4063382@linaro.org
---
Alexey Klimov (6):
dt-bindings: soc: move,rename google,gs101-pmu-intr-gen and add exynos850
dt-bindings: soc: samsung: exynos-pmu: Require pmu-intr-gen-syscon for Exynos850
soc: samsung: exynos-pmu: generalise gs101-specific cpu{idle,hotplug} for Exynos SoCs
soc: samsung: exynos-pmu: add Exynos850 CPU hotplug support
MAINTAINERS: add Exynos850 PMU entry
arm64: dts: exynos850: add PMU interrupt generation node
.../bindings/soc/samsung/exynos-pmu.yaml | 1 +
.../samsung,exynos850-pmu-intr-gen.yaml} | 8 +-
MAINTAINERS | 9 +-
arch/arm64/boot/dts/exynos/exynos850.dtsi | 6 +
drivers/soc/samsung/Makefile | 2 +-
drivers/soc/samsung/exynos-pmu.c | 146 +++++++--------------
drivers/soc/samsung/exynos-pmu.h | 34 +++++
drivers/soc/samsung/exynos850-pmu.c | 95 ++++++++++++++
drivers/soc/samsung/gs101-pmu.c | 49 +++++++
include/linux/soc/samsung/exynos-regs-pmu.h | 15 ++-
10 files changed, 258 insertions(+), 107 deletions(-)
---
base-commit: e98d21c170b01ddef366f023bbfcf6b31509fa83
change-id: 20260226-exynos850-cpuhotplug-69f1976eefa8
prerequisite-message-id: 20260605-exynos-pmu-cpuhp-idle-fixes-v1-0-0cd05c81a82d@linaro.org
prerequisite-patch-id: a36b838f6524b89818ead01648e27177f002b1b1
prerequisite-patch-id: 85901b4ed10abf67809a9f28bd2be52356f93526
prerequisite-patch-id: 6e4d2217a7231375df85a12910badb8b2b8e1fd6
Best regards,
--
Alexey Klimov <alexey.klimov@linaro.org>
^ permalink raw reply
* Re: [GIT PULL] ARM: mvebu: dt64 for v7.2 (#1)
From: Aleksander Jan Bajkowski @ 2026-06-09 17:35 UTC (permalink / raw)
To: Arnd Bergmann, Gregory Clement, arm, soc
Cc: Andrew Lunn, Sebastian Hesselbarth, linux-arm-kernel
In-Reply-To: <bf8092a3-d037-44ee-8e08-8b2204e5cc95@app.fastmail.com>
Hi Arnd,
On 09/06/2026 18:11, Arnd Bergmann wrote:
> On Fri, Jun 5, 2026, at 17:20, Gregory CLEMENT wrote:
>> ----------------------------------------------------------------
>> mvebu dt64 for 7.2 (part 1)
>>
>> Mark EIP97 as dma-coherent for Armada 3720
>>
>> ----------------------------------------------------------------
>> Aleksander Jan Bajkowski (1):
>> arm64: dts: marvell: armada-37xx: mark EIP97 as dma-coherent
> Hi Gregory and Aleksander,
>
> I'm a bit surprised by this oneline change. Since you successfully tested
> this, I assume the change is correct, but I have two questions that
> I would like to have an answer for before I pull it.
By the way, the upstream safexcel driver works correctly only on coherent
platforms. On non-coherent platforms (MediaTek), the SHA-384 and SHA-512
selftests fail. Since the selftests pass on Armada's SoC, I assume I'm
right.
I have a plan to send a patch upstream, which has long been maintained
downstream in OpenWRT[1]. But I need to think a bit more about how to do
this properly.
[1]
https://github.com/openwrt/openwrt/blob/main/target/linux/mediatek/patches-6.18/401-crypto-fix-eip97-cache-incoherent.patch
>
> - I would expect a missing 'dma-coherent' property to cause data
> corruption, as the DMA master may write directly into the L2
> cache, which is then invalidated before the CPU accesses it.
> Do you have any idea how this one ends up working even when
> the property is missing?
No idea. Don't have access the Armada SoC TRM. Maybe the folks at
Marvel will be able to explain it.
>
> - I see that the Product Brief for Armada 37xx mentions that it
> has a "High-bandwidth, low-latency IO Cache Coherency" interconnect,
> which also indicates that the patch is correct. However I don't
> see why it's only the crypto engine that needs it. What about
> the other high-speed DMA masters (neta, xhci, pcie, sata, ...)?
I didn't test to determine whether the other DMA masters are coherent.
But I'm assuming you're correct and they are also coherent. My recent
work has been focused on improving the Rambus/Verimatrix/Safenet crypto
drivers :)
Best regards,
Aleksander
^ permalink raw reply
* Re: [PATCH v2 1/4] dt-bindings: remoteproc: imx_rproc: document optional "memory-region-names"
From: Mathieu Poirier @ 2026-06-09 17:33 UTC (permalink / raw)
To: Frank Li
Cc: Laurentiu Mihalcea, Bjorn Andersson, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Sascha Hauer, Peng Fan,
Fabio Estevam, Daniel Baluta, Francesco Dolcini, linux-remoteproc,
devicetree, imx, linux-arm-kernel, linux-kernel
In-Reply-To: <aihIIwt_9T7yYxP3@SMW015318>
On Tue, 9 Jun 2026 at 11:06, Frank Li <Frank.li@oss.nxp.com> wrote:
>
> On Tue, Jun 09, 2026 at 10:40:06AM -0600, Mathieu Poirier wrote:
> > [You don't often get email from mathieu.poirier@linaro.org. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ]
> >
> > On Fri, Jun 05, 2026 at 04:36:18AM -0700, Laurentiu Mihalcea wrote:
> > > From: Laurentiu Mihalcea <laurentiu.mihalcea@nxp.com>
> > >
> > > The names of the carveout regions are derived using the names of the
> > > reserved memory devicetree nodes, which are referenced using the
> > > "memory-region" property. This adds a restriction on the names of said
> > > devicetree nodes, often bearing specific names such as: "vdevbuffer",
> > > "vdev0vring0", "rsc-table", etc... This goes against the devicetree
> > > specification's recommendation, which states that the devicetree node
> > > names should be generic.
> >
> > I don't see what is so restrictive in using the node name of the reserved-memory
> > regions. Function of_reserved_mem_region_to_resource() is already doing all the
> > parsing, packaging everything in a neat and easy to use "struct resource". What
> > will you gain with this new "memory-region-names" that can't be done with the
> > current solution?
>
> DT Binding check can't find such wrong if node name is not what expected.
> Binding can't restrict memory's node name because there ware not specific
> compatible string for it.
>
But what "wrong" could that be, and what kind of restriction are you
hoping to enforce? What specific problem are you hoping to solve?
I'll wait to see what the DT people think about this - I personally
don't see the value in it.
> Frank
>
> >
> > >
> > > Fix this by documenting an additional, optional property:
> > > "memory-region-names". This way, the carveout names can use the values
> > > passed via "memory-region-names", while keeping the devicetree node
> > > names of the reserved memory regions generic.
> > >
> > > There are no restrictions imposed on the values of the strings passed via
> > > the new property since the software allows any name to be used, with some
> > > names (e.g. "vdev%dbuffer", "vdev%dvring%d", "rsc-table") bearing a
> > > special meaning.
> > >
> > > Signed-off-by: Laurentiu Mihalcea <laurentiu.mihalcea@nxp.com>
> > > ---
> > > .../devicetree/bindings/remoteproc/fsl,imx-rproc.yaml | 4 ++++
> > > 1 file changed, 4 insertions(+)
> > >
> > > diff --git a/Documentation/devicetree/bindings/remoteproc/fsl,imx-rproc.yaml b/Documentation/devicetree/bindings/remoteproc/fsl,imx-rproc.yaml
> > > index c18f71b64889..8e3e6676a95e 100644
> > > --- a/Documentation/devicetree/bindings/remoteproc/fsl,imx-rproc.yaml
> > > +++ b/Documentation/devicetree/bindings/remoteproc/fsl,imx-rproc.yaml
> > > @@ -62,6 +62,10 @@ properties:
> > > minItems: 1
> > > maxItems: 32
> > >
> > > + memory-region-names:
> > > + minItems: 1
> > > + maxItems: 32
> > > +
> > > power-domains:
> > > minItems: 2
> > > maxItems: 8
> > > --
> > > 2.43.0
> > >
> >
^ permalink raw reply
* Re: [PATCH v2 1/4] dt-bindings: iio: adc: mediatek,mt6359-auxadc: add mt6323 PMIC AUXADC
From: Roman Vivchar @ 2026-06-09 17:29 UTC (permalink / raw)
To: Conor Dooley
Cc: Jonathan Cameron, David Lechner, Nuno Sá, Andy Shevchenko,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Matthias Brugger,
AngeloGioacchino Del Regno, Lee Jones, linux-iio, devicetree,
linux-kernel, linux-arm-kernel, linux-mediatek, Ben Grisdale
In-Reply-To: <20260609-gangway-frayed-366f6d3cc867@spud>
Hi Conor,
On Tuesday, June 9th, 2026 at 7:01 PM, Conor Dooley <conor@kernel.org> wrote:
> On Tue, Jun 09, 2026 at 04:31:58PM +0300, Roman Vivchar via B4 Relay wrote:
> > properties:
> > compatible:
> > enum:
> > + - mediatek,mt6323-auxadc
>
> Commit message needs to explain why a fallback is not suitable.
> pw-bot: changes-requested
Ack.
>
> > - mediatek,mt6357-auxadc
> > - mediatek,mt6358-auxadc
> > - mediatek,mt6359-auxadc
> > diff --git a/MAINTAINERS b/MAINTAINERS
> > index d1cc0e12fe1f..2551c8cd9e9d 100644
> > --- a/MAINTAINERS
> > +++ b/MAINTAINERS
> > @@ -16256,6 +16256,12 @@ S: Maintained
> > F: Documentation/devicetree/bindings/mmc/mtk-sd.yaml
> > F: drivers/mmc/host/mtk-sd.c
> >
> > +MEDIATEK MT6323 PMIC AUXADC DRIVER
> > +M: Roman Vivchar <rva333@protonmail.com>
> > +L: linux-iio@vger.kernel.org
> > +S: Maintained
> > +F: include/dt-bindings/iio/adc/mediatek,mt6323-auxadc.h
>
> Why is the binding not being included here?
>
The binding is shared across multiple PMIC ADCs and maintained by
Angelo. Since I'm only familiar with mt6323 and not others like mt6358,
I decided to not include it in the mt6323 entry.
Best regards,
Roman
^ permalink raw reply
* [PATCH] media: bcm2835-unicam: Fix asc leaked in error/remove path
From: Eugen Hristev @ 2026-06-09 17:05 UTC (permalink / raw)
To: Raspberry Pi Kernel Maintenance, Mauro Carvalho Chehab,
Florian Fainelli, Broadcom internal kernel review list, Ray Jui,
Scott Branden, Hans Verkuil, Naushir Patuck, Sakari Ailus,
Dave Stevenson, Jean-Michel Hautbois
Cc: Laurent Pinchart, linux-media, linux-rpi-kernel, linux-arm-kernel,
linux-kernel, Eugen Hristev
v4l2_async_nf_add_fwnode_remote() allocates the asc, which is freed when
v4l2_async_nf_cleanup() is called.
Call v4l2_async_nf_cleanup() properly in the driver paths.
Discovered with kmemleak after rmmod:
unreferenced object 0xffff000084526b80 (size 64):
comm "modprobe", pid 185, jiffies 4295013512
hex dump (first 32 bytes):
01 00 00 00 00 00 00 00 e8 0d ff bf 00 00 ff ff ................
40 83 bc 84 00 00 ff ff 60 83 bc 84 00 00 ff ff @.......`.......
backtrace (crc ac584083):
[<00000000ffb081a7>] kmemleak_alloc+0x38/0x44
[<00000000d2fd9301>] __kmalloc+0x1b0/0x250
[<000000004dd5354d>] __v4l2_async_nf_add_fwnode+0x28/0x9c
[<0000000067587657>] __v4l2_async_nf_add_fwnode_remote+0x3c/0x64
Fixes: 392cd78d495f ("media: bcm2835-unicam: Add support for CCP2/CSI2 camera interface")
Signed-off-by: Eugen Hristev <ehristev@kernel.org>
---
drivers/media/platform/broadcom/bcm2835-unicam.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/media/platform/broadcom/bcm2835-unicam.c b/drivers/media/platform/broadcom/bcm2835-unicam.c
index 8d28ba0b59a3..1508843ae58c 100644
--- a/drivers/media/platform/broadcom/bcm2835-unicam.c
+++ b/drivers/media/platform/broadcom/bcm2835-unicam.c
@@ -2613,6 +2613,7 @@ static int unicam_async_nf_init(struct unicam_device *unicam)
return 0;
error:
+ v4l2_async_nf_cleanup(&unicam->notifier);
fwnode_handle_put(ep_handle);
return ret;
}
@@ -2745,6 +2746,7 @@ static void unicam_remove(struct platform_device *pdev)
v4l2_device_unregister(&unicam->v4l2_dev);
media_device_unregister(&unicam->mdev);
v4l2_async_nf_unregister(&unicam->notifier);
+ v4l2_async_nf_cleanup(&unicam->notifier);
unicam_subdev_cleanup(unicam);
---
base-commit: a87737435cfa134f9cdcc696ba3080759d04cf72
change-id: 20260609-bcmpiclean-69a8ee3192b0
Best regards,
--
Eugen Hristev <ehristev@kernel.org>
^ permalink raw reply related
* Re: (subset) [PATCH 1/2] PCI: dwc: Guard RAS DES debugfs deinit
From: Manivannan Sadhasivam @ 2026-06-09 16:44 UTC (permalink / raw)
To: Jingoo Han, Lorenzo Pieralisi, Krzysztof Wilczyński,
Bjorn Helgaas, Yue Wang, Neil Armstrong, Shuvam Pandey
Cc: Rob Herring, Kevin Hilman, Jerome Brunet, Martin Blumenstingl,
Fan Ni, Shradha Todi, Hanjie Lin, linux-pci, linux-amlogic,
linux-arm-kernel, linux-kernel
In-Reply-To: <0f97352506d8d813f70f441de4d63fcd5b7d1c3e.1779123847.git.shuvampandey1@gmail.com>
On Mon, 18 May 2026 22:44:17 +0545, Shuvam Pandey wrote:
> dwc_pcie_rasdes_debugfs_init() returns success when the controller has
> no RAS DES capability, leaving pci->debugfs->rasdes_info unset. The
> common debugfs teardown path still calls
> dwc_pcie_rasdes_debugfs_deinit(), which dereferences rasdes_info
> unconditionally.
>
> Return early when no RAS DES state was allocated. In that case no RAS DES
> mutex was initialized, so there is nothing to destroy.
>
> [...]
Applied, thanks!
[1/2] PCI: dwc: Guard RAS DES debugfs deinit
commit: a5ee214bb36f43b4d8bb2615b30d3b5c0ea80826
Best regards,
--
Manivannan Sadhasivam <mani@kernel.org>
^ permalink raw reply
* Re: [PATCH RFC v3 0/5] ZTE zx297520v3 clock bindings and driver
From: Stefan Dösinger @ 2026-06-09 16:42 UTC (permalink / raw)
To: Michael Turquette, Stephen Boyd, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Brian Masney, Philipp Zabel
Cc: linux-clk, devicetree, linux-kernel, linux-arm-kernel
In-Reply-To: <f92114a3658185b57bffe546c0f4079a9d39afce.camel@pengutronix.de>
[-- Attachment #1: Type: text/plain, Size: 3484 bytes --]
Hi Philipp,
I did some more reading and checked past clock driver submissions. This email
is to check if I understood it right.
Am Donnerstag, 4. Juni 2026, 18:23:01 Ostafrikanische Zeit schrieb Philipp
Zabel:
> > The register lock because all LSP and at least one TOP register contains
> > both clocks and resets.
>
> That could be solved with regmap.
This will require me to change the clk component to use regmaps too. There's
no regmap equivalent to clk-{div,gate,mux}.c, so I'll need my own. qcom and
meson have similar drivers already, so I'd likely copy one of them. Is there a
particular reason why there isn't a regmap equivalent of clk-{div,gate,mux}.c?
Another hypothetical solution is a custom regmap implementation that locks my
clk driver's lock. I see that only in imx/clk-imx8ulp-sim-lpav.c.
However, the topclk region also has a stray register that controls if a
watchdog timeout resets the board. So there's no good way past a syscon
compatible and syscon generated regmap anyway.
Afaics syscon regmaps only support a single IO region, so I'd likely revert
back to the topclk/matrixclk split with different bindings, bite the other
bullet and list all 50 or so PLL outputs as clocks passed from top to matrix.
Which gives a device tree setup like this:
topcrm: something@13b000 {
compatible = "zte,zx297520v3-topcrm", "syscon", "simple-mfd";
reg = <0x0013b000 0x400>;
#address-cells = <1>;
#size-cells = <1>;
ranges;
topclk: clock-controller@0 {
compatible = "zte,zx297520v3-topclk";
reg = <0x0 0x400>;
#clock-cells = <1>;
#reset-cells = <1>;
clocks = <&osc26m>, <&osc32k>;
clock-names = "osc26m", "osc32k";
};
reboot {
compatible = "syscon-reboot";
offset = <0x0>;
mask = <0x1>;
};
};
watchdog_t18: watchdog@148000 {
compatible = "zte,zx297520-wdt";
reg = <0x00148000 0x20>;
clocks = <&topclk ZX297520V3_WDT_T18_WCLK>, <&topclk
ZX297520V3_WDT_T18_PCLK>;
clock-names = "wclk", "pclk";
resets = <&topclk ZX297520V3_WDT_T18_RESET>;
zte,wdt-reset-sysctrl = <&topcrm 0x2c 0x3 0x3>;
};
(I did not attempt to build this, might have typos)
And the reset controller will be an aux-bus child of the clock controller. I
could make the reset controller its own device with its own bindings, but that
would misrepresent the hardware.
Did I understand this correctly?
For some reason in my dev tree the reset sysctrl works even though my clock
driver does not use the syscon compatible nor manually create a regmap.
> > Shared register definition: in the case of the LSP clocks breaking up the
> > composite definition would sacrifice readability.
>
> That is a matter of perspective.
>
> I had a harder time validating that the resets[] array is properly
> initialized from the two different composite arrays because of the
> unordered reset_ids, and some remaining resets[] being filled via code.
I do have a sanity check loop for that.
> It would be much simpler if you split the reset definitions out into a
> single, separate, const array, indexed by reset id. In fact,
> I would suggest this even if you don't intend to move the reset code.
I had to collect the clocks and resets from all over ZTE's kernel and U-Boot
sources plus manual testing, so maybe I am a bit too attached to seeing all
controls for a given device in one place. If the reset controls move to a
different file, the composite structure becomes less useful, so I'll probably
split it up and just list single div, gates and regs.
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 870 bytes --]
^ permalink raw reply
* Re: (subset) [PATCH 2/2] PCI: meson: Add missing remove callback
From: Manivannan Sadhasivam @ 2026-06-09 16:41 UTC (permalink / raw)
To: Jingoo Han, Lorenzo Pieralisi, Krzysztof Wilczyński,
Bjorn Helgaas, Yue Wang, Neil Armstrong, Shuvam Pandey
Cc: Rob Herring, Kevin Hilman, Jerome Brunet, Martin Blumenstingl,
Fan Ni, Shradha Todi, Hanjie Lin, linux-pci, linux-amlogic,
linux-arm-kernel, linux-kernel
In-Reply-To: <1a0c86ab264cdc1c79c917e984b90991af51d827.1779123847.git.shuvampandey1@gmail.com>
On Mon, 18 May 2026 22:44:18 +0545, Shuvam Pandey wrote:
> meson_pcie_probe() powers on the PHY and registers the DesignWare host
> bridge with dw_pcie_host_init(), but the driver has no remove callback.
> On driver unbind or module unload, the driver core therefore proceeds to
> devres cleanup without first unregistering the host bridge or powering off
> the PHY.
>
> Add a remove callback that deinitializes the DesignWare host bridge and
> powers off the PHY while device-managed resources are still valid.
>
> [...]
Applied, thanks!
[2/2] PCI: meson: Add missing remove callback
commit: 4b0dc84b293984f75598881809fb2d3daf54a2a8
Best regards,
--
Manivannan Sadhasivam <mani@kernel.org>
^ permalink raw reply
* Re: [PATCH v2 1/4] dt-bindings: remoteproc: imx_rproc: document optional "memory-region-names"
From: Mathieu Poirier @ 2026-06-09 16:40 UTC (permalink / raw)
To: Laurentiu Mihalcea
Cc: Bjorn Andersson, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Sascha Hauer, Peng Fan, Fabio Estevam, Daniel Baluta,
Francesco Dolcini, linux-remoteproc, devicetree, imx,
linux-arm-kernel, linux-kernel
In-Reply-To: <20260605113621.1479-2-laurentiumihalcea111@gmail.com>
On Fri, Jun 05, 2026 at 04:36:18AM -0700, Laurentiu Mihalcea wrote:
> From: Laurentiu Mihalcea <laurentiu.mihalcea@nxp.com>
>
> The names of the carveout regions are derived using the names of the
> reserved memory devicetree nodes, which are referenced using the
> "memory-region" property. This adds a restriction on the names of said
> devicetree nodes, often bearing specific names such as: "vdevbuffer",
> "vdev0vring0", "rsc-table", etc... This goes against the devicetree
> specification's recommendation, which states that the devicetree node
> names should be generic.
I don't see what is so restrictive in using the node name of the reserved-memory
regions. Function of_reserved_mem_region_to_resource() is already doing all the
parsing, packaging everything in a neat and easy to use "struct resource". What
will you gain with this new "memory-region-names" that can't be done with the
current solution?
>
> Fix this by documenting an additional, optional property:
> "memory-region-names". This way, the carveout names can use the values
> passed via "memory-region-names", while keeping the devicetree node
> names of the reserved memory regions generic.
>
> There are no restrictions imposed on the values of the strings passed via
> the new property since the software allows any name to be used, with some
> names (e.g. "vdev%dbuffer", "vdev%dvring%d", "rsc-table") bearing a
> special meaning.
>
> Signed-off-by: Laurentiu Mihalcea <laurentiu.mihalcea@nxp.com>
> ---
> .../devicetree/bindings/remoteproc/fsl,imx-rproc.yaml | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/remoteproc/fsl,imx-rproc.yaml b/Documentation/devicetree/bindings/remoteproc/fsl,imx-rproc.yaml
> index c18f71b64889..8e3e6676a95e 100644
> --- a/Documentation/devicetree/bindings/remoteproc/fsl,imx-rproc.yaml
> +++ b/Documentation/devicetree/bindings/remoteproc/fsl,imx-rproc.yaml
> @@ -62,6 +62,10 @@ properties:
> minItems: 1
> maxItems: 32
>
> + memory-region-names:
> + minItems: 1
> + maxItems: 32
> +
> power-domains:
> minItems: 2
> maxItems: 8
> --
> 2.43.0
>
^ permalink raw reply
* Re: [PATCH v3 3/3] ARM: dts: ti: Add specific compatibles for SCM conf nodes
From: Conor Dooley @ 2026-06-09 16:34 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Lee Jones, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Matthias Brugger, AngeloGioacchino Del Regno, Jacky Huang,
Shan-Chun Hung, Geert Uytterhoeven, Magnus Damm, Heiko Stuebner,
Aaro Koskinen, Andreas Kemnade, Kevin Hilman, Roger Quadros,
Tony Lindgren, devicetree, linux-kernel, linux-arm-kernel,
linux-mediatek, linux-renesas-soc, linux-rockchip, linux-omap
In-Reply-To: <20260608-n-dt-bindings-simple-bus-syscon-v3-3-4eba9ec1212a@oss.qualcomm.com>
[-- Attachment #1: Type: text/plain, Size: 56 bytes --]
Reviewed-by: Conor Dooley <conor.dooley@microchip.com>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ 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