* Re: [PATCH v2 3/4] perf/arm64: Add BRBE support for bpf_get_branch_snapshot()
From: Rob Herring @ 2026-04-10 19:23 UTC (permalink / raw)
To: Puranjay Mohan
Cc: bpf, Puranjay Mohan, Alexei Starovoitov, Andrii Nakryiko,
Daniel Borkmann, Martin KaFai Lau, Eduard Zingerman,
Kumar Kartikeya Dwivedi, Will Deacon, Mark Rutland,
Catalin Marinas, Leo Yan, Breno Leitao, linux-arm-kernel,
linux-perf-users, kernel-team
In-Reply-To: <20260318171706.2840512-4-puranjay@kernel.org>
On Wed, Mar 18, 2026 at 10:16:57AM -0700, Puranjay Mohan wrote:
> Enable the bpf_get_branch_snapshot() BPF helper on ARM64 by implementing
> the perf_snapshot_branch_stack static call for ARM's Branch Record Buffer
> Extension (BRBE).
>
> The BPF helper bpf_get_branch_snapshot() allows BPF programs to capture
> hardware branch records on-demand. This was previously only available on
> x86 (Intel LBR) but not on ARM64 despite BRBE being available since
> ARMv9.
>
> BRBE is paused before disabling interrupts because local_irq_save() can
> trigger trace_hardirqs_off() which performs stack walking and pollutes
> the branch buffer. The sysreg read/write and ISB used to pause BRBE are
> branchless, so pausing first avoids this pollution.
>
> All exceptions are masked after pausing BRBE using local_daif_save() to
> prevent pseudo-NMI from PMU counter overflow from interfering with the
> snapshot read. A PMU overflow arriving between the pause and
> local_daif_save() can re-enable BRBE via the interrupt handler; the
> snapshot detects this by re-checking BRBFCR_EL1.PAUSED and bailing out.
>
> Branch records are read using the existing perf_entry_from_brbe_regset()
> helper with a NULL event pointer, which bypasses event-specific filtering
> and captures all recorded branches. The BPF program is responsible for
> filtering entries based on its own criteria. The BRBE buffer is
> invalidated after reading to maintain contiguity for other consumers.
>
> On heterogeneous big.LITTLE systems, only some CPUs may implement
> FEAT_BRBE. The perf_snapshot_branch_stack static call is system-wide, so
> a per-CPU brbe_active flag is used to prevent BRBE sysreg access on CPUs
> that do not implement FEAT_BRBE, where such access would be UNDEFINED.
Is this something you've seen? IIRC, the existing assumption is all CPUs
have FEAT_BRBE or that perf has been limited to those CPUs. It is
allowed that the number of records can vary.
>
> Signed-off-by: Puranjay Mohan <puranjay@kernel.org>
> ---
> drivers/perf/arm_brbe.c | 79 +++++++++++++++++++++++++++++++++++++++-
> drivers/perf/arm_brbe.h | 9 +++++
> drivers/perf/arm_pmuv3.c | 5 ++-
> 3 files changed, 90 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/perf/arm_brbe.c b/drivers/perf/arm_brbe.c
> index ba554e0c846c..527c2d5ebba6 100644
> --- a/drivers/perf/arm_brbe.c
> +++ b/drivers/perf/arm_brbe.c
> @@ -8,9 +8,13 @@
> */
> #include <linux/types.h>
> #include <linux/bitmap.h>
> +#include <linux/percpu.h>
> #include <linux/perf/arm_pmu.h>
> +#include <asm/daifflags.h>
> #include "arm_brbe.h"
>
> +static DEFINE_PER_CPU(bool, brbe_active);
> +
> #define BRBFCR_EL1_BRANCH_FILTERS (BRBFCR_EL1_DIRECT | \
> BRBFCR_EL1_INDIRECT | \
> BRBFCR_EL1_RTN | \
> @@ -533,6 +537,8 @@ void brbe_enable(const struct arm_pmu *arm_pmu)
> /* Finally write SYS_BRBFCR_EL to unpause BRBE */
> write_sysreg_s(brbfcr, SYS_BRBFCR_EL1);
> /* Synchronization in PMCR write ensures ordering WRT PMU enabling */
> +
> + this_cpu_write(brbe_active, true);
> }
>
> void brbe_disable(void)
> @@ -544,6 +550,7 @@ void brbe_disable(void)
> */
> write_sysreg_s(BRBFCR_EL1_PAUSED, SYS_BRBFCR_EL1);
> write_sysreg_s(0, SYS_BRBCR_EL1);
> + this_cpu_write(brbe_active, false);
> }
>
> static const int brbe_type_to_perf_type_map[BRBINFx_EL1_TYPE_DEBUG_EXIT + 1][2] = {
> @@ -618,10 +625,10 @@ static bool perf_entry_from_brbe_regset(int index, struct perf_branch_entry *ent
>
> brbe_set_perf_entry_type(entry, brbinf);
>
> - if (!branch_sample_no_cycles(event))
> + if (!event || !branch_sample_no_cycles(event))
> entry->cycles = brbinf_get_cycles(brbinf);
>
> - if (!branch_sample_no_flags(event)) {
> + if (!event || !branch_sample_no_flags(event)) {
> /* Mispredict info is available for source only and complete branch records. */
> if (!brbe_record_is_target_only(brbinf)) {
> entry->mispred = brbinf_get_mispredict(brbinf);
> @@ -803,3 +810,71 @@ void brbe_read_filtered_entries(struct perf_branch_stack *branch_stack,
> done:
> branch_stack->nr = nr_filtered;
> }
> +
> +/*
> + * Best-effort BRBE snapshot for BPF tracing. Pause BRBE to avoid
> + * self-recording and return 0 if the snapshot state appears disturbed.
> + */
> +int arm_brbe_snapshot_branch_stack(struct perf_branch_entry *entries, unsigned int cnt)
> +{
> + unsigned long flags;
> + int nr_hw, nr_banks, nr_copied = 0;
> + u64 brbidr, brbfcr, brbcr;
> +
> + if (!cnt || !__this_cpu_read(brbe_active))
> + return 0;
> +
> + /* Pause BRBE first to avoid recording our own branches. */
> + brbfcr = read_sysreg_s(SYS_BRBFCR_EL1);
> + brbcr = read_sysreg_s(SYS_BRBCR_EL1);
> + write_sysreg_s(brbfcr | BRBFCR_EL1_PAUSED, SYS_BRBFCR_EL1);
> + isb();
Is there something that guarantees BRBE is enabled when you enter this
function and that it is not disabled in this window? A context switch
could disable it unless it's a global event for example.
> +
> + /* Block local exception delivery while reading the buffer. */
> + flags = local_daif_save();
> +
> + /*
> + * A PMU overflow before local_daif_save() could have re-enabled
> + * BRBE, clearing the PAUSED bit. The overflow handler already
> + * restored BRBE to its correct state, so just bail out.
> + */
> + if (!(read_sysreg_s(SYS_BRBFCR_EL1) & BRBFCR_EL1_PAUSED)) {
> + local_daif_restore(flags);
> + return 0;
> + }
> +
> + brbidr = read_sysreg_s(SYS_BRBIDR0_EL1);
> + if (!valid_brbidr(brbidr))
This is not possibly true if brbe_active is true. If BRBIDR is not
valid, then we would have rejected any event requesting branch stack.
> + goto out;
> +
> + nr_hw = FIELD_GET(BRBIDR0_EL1_NUMREC_MASK, brbidr);
> + nr_banks = DIV_ROUND_UP(nr_hw, BRBE_BANK_MAX_ENTRIES);
> +
> + for (int bank = 0; bank < nr_banks; bank++) {
> + int nr_remaining = nr_hw - (bank * BRBE_BANK_MAX_ENTRIES);
> + int nr_this_bank = min(nr_remaining, BRBE_BANK_MAX_ENTRIES);
> +
> + select_brbe_bank(bank);
> +
> + for (int i = 0; i < nr_this_bank; i++) {
I don't love all this being duplicated. Perhaps an iterator would help
here (and the other copy):
static void next_slot(int *bank, int *bank_idx, int nr_hw)
{
*bank_idx++;
if (*bank_idx + (*bank * BRBE_BANK_MAX_ENTRIES) == nr_hw)
bank = BRBE_MAX_BANKS;
else if ((*bank_idx % BRBE_BANK_MAX_ENTRIES) == 0) {
*bank_idx = 0;
select_brbe_bank(++(*bank));
}
}
#define for_each_bank_slot(i, nr_hw) \
for (int bank = 0, int i = 0; bank < BRBE_MAX_BANKS; next_slot(&bank,
&i))
Then here you just have:
for_each_bank_slot(i, FIELD_GET(BRBIDR0_EL1_NUMREC_MASK, brbidr)) {
...
}
Feel free to come up with better naming. :)
> + if (nr_copied >= cnt)
> + goto done;
> +
> + if (!perf_entry_from_brbe_regset(i, &entries[nr_copied], NULL))
> + goto done;
> +
> + nr_copied++;
> + }
> + }
> +
> +done:
> + brbe_invalidate();
> +out:
> + /* Restore BRBCR before unpausing via BRBFCR, matching brbe_enable(). */
> + write_sysreg_s(brbcr, SYS_BRBCR_EL1);
> + isb();
> + write_sysreg_s(brbfcr, SYS_BRBFCR_EL1);
> + local_daif_restore(flags);
> +
> + return nr_copied;
> +}
^ permalink raw reply
* Re: [PATCH v4 03/10] iommu/arm-smmu-v3: Store IOTLB cache tags in struct arm_smmu_attach_state
From: Nicolin Chen @ 2026-04-10 18:52 UTC (permalink / raw)
To: Jason Gunthorpe
Cc: will, robin.murphy, joro, jpb, praan, smostafa, linux-arm-kernel,
iommu, linux-kernel, linux-tegra, jonathan.cameron
In-Reply-To: <20260409234223.GX3357077@nvidia.com>
On Thu, Apr 09, 2026 at 08:42:23PM -0300, Jason Gunthorpe wrote:
> On Thu, Mar 19, 2026 at 12:51:49PM -0700, Nicolin Chen wrote:
> > So far, an IOTLB tag (ASID or VMID) has been stored in the arm_smmu_domain
> > +static int __arm_smmu_domain_find_iotlb_tag(struct arm_smmu_domain *smmu_domain,
> > + struct arm_smmu_inv *tag)
> > +{
> > + struct arm_smmu_invs *invs = rcu_dereference_protected(
> > + smmu_domain->invs, lockdep_is_held(&arm_smmu_asid_lock));
> > + size_t i;
> > +
> > + arm_smmu_inv_assert_iotlb_tag(tag);
> > +
> > + for (i = 0; i != invs->num_invs; i++) {
> > + if (invs->inv[i].type == tag->type &&
> > + invs->inv[i].smmu == tag->smmu &&
> > + READ_ONCE(invs->inv[i].users)) {
> > + *tag = invs->inv[i];
>
> This users thing has become to hard to understand and it isn't how it
> should be.
>
> All writers *with the possibility of concurrent access* need to use
> WRITE_ONCE since there is a RCU reader. IIRC that is just
> arm_smmu_invs_unref()
>
> The one in arm_smmu_invs_merge() is just writing to newly allocated
> memory so it shouldn't be marked.
>
> Only readers *with the possibility of concurrent access* should be
> marked with READ_ONCE. IIRC this is just the invalidation walker.
I added a cleanup patch to the beginning of the series and corrected
all the new reads/writes too.
> Places like this have to be protected by a lock or the whole thing is
> wrong, so it should have a lockdep annoation.
Hmm, is the lockdep_is_held() in rcu_dereference_protected() enough?
> Now what is the locking supposed to be? It looks wrong, it probably
> wants to be arm_smmu_asid_lock, but arm_smmu_mm_release() doesn't grab
> it.
>
> But why does arm_smmu_mm_release() need a tag in the first place? ASID
> isn't going to be used when EPD0|EPD1 is set, so the tag can just be
> 0. Probably make a patch with that change early on..
I see. I added a cleanup patch.
> All the locking is important because this:
>
> > +/* Find an existing IOTLB cache tag in smmu_domain->invs (users counter != 0) */
>
> Must be held as an invarient into the caller, meaning the caller must
> hold arm_smmu_asid_lock while it has an active tag on the stack, and
> that should be documented here. As well as a lockdep of course.
>
> From what I can tell the final result is correct (aside from
> arm_smmu_mm_release), just under documented.
Re-checking the locking in these functions and updating the kdocs.
Thanks
Nicolin
^ permalink raw reply
* Re: [PATCH v5 0/4] arm64: Work around C1-Pro erratum 4193714 (CVE-2026-0995)
From: Catalin Marinas @ 2026-04-10 18:47 UTC (permalink / raw)
To: linux-arm-kernel; +Cc: Will Deacon, James Morse, Mark Rutland, Mark Brown
In-Reply-To: <20260407102848.2266988-1-catalin.marinas@arm.com>
On Tue, 07 Apr 2026 11:28:40 +0100, Catalin Marinas wrote:
> That's version 5 of the C1-Pro workaround. Version 3 here:
>
> https://lore.kernel.org/r/20260402101246.3870036-1-catalin.marinas@arm.com
>
> Changes since v4:
>
> - Static sme_dvmsync_cpus mask to avoid allocating under stop_machine().
> Sashiko was right, even GFP_ATOMIC won't work under a raw_spin_lock()
>
> [...]
Applied to arm64 (for-next/c1-pro-erratum-4193714). I won't push it to
Linus in the first round, waiting for a bit more testing from Will. If
all goes well, I'll send it in the second part of the merging window.
[1/4] arm64: tlb: Introduce __tlbi_sync_s1ish_{kernel,batch}() for TLB maintenance
https://git.kernel.org/arm64/c/6bfbf574a391
[2/4] arm64: tlb: Pass the corresponding mm to __tlbi_sync_s1ish()
https://git.kernel.org/arm64/c/d9fb08ba946a
[3/4] arm64: cputype: Add C1-Pro definitions
https://git.kernel.org/arm64/c/2c99561016c5
[4/4] arm64: errata: Work around early CME DVMSync acknowledgement
https://git.kernel.org/arm64/c/0baba94a9779
^ permalink raw reply
* [PATCH] arm: Kconfig: fix duplicate words in help text
From: Michael Ugrin @ 2026-04-10 18:22 UTC (permalink / raw)
To: linux-arm-kernel; +Cc: linux-kernel, Michael Ugrin
Remove two instances of duplicate 'the'.
Signed-off-by: Michael Ugrin <mugrinphoto@gmail.com>
---
arch/arm/Kconfig | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index ec33376f8e2ba..e62af2a34f59f 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -1486,7 +1486,7 @@ config ARM_ATAG_DTB_COMPAT_CMDLINE_EXTEND
bool "Extend with bootloader kernel arguments"
help
The command-line arguments provided by the boot loader will be
- appended to the the device tree bootargs property.
+ appended to the device tree bootargs property.
endchoice
@@ -1628,7 +1628,7 @@ config DMI
continue to boot on existing non-UEFI platforms.
NOTE: This does *NOT* enable or encourage the use of DMI quirks,
- i.e., the the practice of identifying the platform via DMI to
+ i.e., the practice of identifying the platform via DMI to
decide whether certain workarounds for buggy hardware and/or
firmware need to be enabled. This would require the DMI subsystem
to be enabled much earlier than we do on ARM, which is non-trivial.
--
2.51.2.windows.1
^ permalink raw reply related
* Re: [PATCH v2 2/4] perf: Fix uninitialized bitfields in perf_clear_branch_entry_bitfields()
From: Rob Herring @ 2026-04-10 18:17 UTC (permalink / raw)
To: Leo Yan
Cc: Puranjay Mohan, bpf, Puranjay Mohan, Alexei Starovoitov,
Andrii Nakryiko, Daniel Borkmann, Martin KaFai Lau,
Eduard Zingerman, Kumar Kartikeya Dwivedi, Will Deacon,
Mark Rutland, Catalin Marinas, Breno Leitao, linux-arm-kernel,
linux-perf-users, kernel-team
In-Reply-To: <20260409162826.GX356832@e132581.arm.com>
On Thu, Apr 09, 2026 at 05:28:26PM +0100, Leo Yan wrote:
> On Wed, Mar 18, 2026 at 10:16:56AM -0700, Puranjay Mohan wrote:
>
> [...]
>
> > diff --git a/include/linux/perf_event.h b/include/linux/perf_event.h
> > index 48d851fbd8ea..d7f39b7e9cda 100644
> > --- a/include/linux/perf_event.h
> > +++ b/include/linux/perf_event.h
>
> BTW, I found you didn't include correct maintainers for perf core
> changes. You might need to loop them in the new version.
Yes. And use get_maintainers.pl please. b4 tool will do that for you.
That will get everyone including authors of commits in "Fixes". That
would be Marc Z in this case.
Rob
^ permalink raw reply
* ✅ PASS (MISSED 51 of 56): Test report for for-kernelci (7.0.0-rc7, upstream-arm-next, 5988aa32)
From: cki-project @ 2026-04-10 18:13 UTC (permalink / raw)
To: catalin.marinas, will, linux-arm-kernel
Hi, we tested your kernel and here are the results:
Overall result: PASSED
Merge: OK
Compile: OK
Test: OK
Tested-by: CKI Project <cki-project@redhat.com>
Kernel information:
Commit message: Merge branch 'for-next/c1-pro-erratum-4193714' into for-kernelci
You can find all the details about the test run at
https://datawarehouse.cki-project.org/kcidb/checkouts/redhat:2444539166
Tests that were not ran because of internal issues:
/distribution/check-install [aarch64]
/distribution/command [aarch64]
/test/misc/machineinfo [aarch64]
Boot test [aarch64]
CKI/restraint [aarch64]
Hardware - Firmware test suite [aarch64]
Reboot test [aarch64]
SELinux Custom Module Setup [aarch64]
selinux-policy: serge-testsuite [aarch64]
Storage - blktests - throtl [aarch64]
Storage - blktests - ublk [aarch64]
stress: stress-ng - cpu-cache [aarch64]
stress: stress-ng - memory [aarch64]
xfstests - btrfs [aarch64]
xfstests - ext4 [aarch64]
xfstests - xfs [aarch64]
If you find a failure unrelated to your changes, please ask the test maintainer to review it.
This will prevent the failures from being incorrectly reported in the future.
Please reply to this email if you have any questions about the tests that we
ran or if you have any suggestions on how to make future tests more effective.
,-. ,-.
( C ) ( K ) Continuous
`-',-.`-' Kernel
( I ) Integration
`-'
______________________________________________________________________________
^ permalink raw reply
* Re: [PATCH v2 2/3] pwm: rp1: Add RP1 PWM controller driver
From: Uwe Kleine-König @ 2026-04-10 17:31 UTC (permalink / raw)
To: Andrea della Porta
Cc: linux-pwm, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Florian Fainelli, Broadcom internal kernel review list,
devicetree, linux-rpi-kernel, linux-arm-kernel, linux-kernel,
Naushir Patuck, Stanimir Varbanov, mbrugger
In-Reply-To: <0d99317b9150310dfbd98de1cb2a890f0bffe7cd.1775829499.git.andrea.porta@suse.com>
[-- Attachment #1: Type: text/plain, Size: 14571 bytes --]
Hello Andrea,
nice work for a v2!
On Fri, Apr 10, 2026 at 04:09:58PM +0200, Andrea della Porta wrote:
> From: Naushir Patuck <naush@raspberrypi.com>
>
> The Raspberry Pi RP1 southbridge features an embedded PWM
> controller with 4 output channels, alongside an RPM interface
> to read the fan speed on the Raspberry Pi 5.
>
> Add the supporting driver.
>
> Signed-off-by: Naushir Patuck <naush@raspberrypi.com>
> Co-developed-by: Stanimir Varbanov <svarbanov@suse.de>
> Signed-off-by: Stanimir Varbanov <svarbanov@suse.de>
> Signed-off-by: Andrea della Porta <andrea.porta@suse.com>
> ---
> drivers/pwm/Kconfig | 9 ++
> drivers/pwm/Makefile | 1 +
> drivers/pwm/pwm-rp1.c | 344 ++++++++++++++++++++++++++++++++++++++++++
> 3 files changed, 354 insertions(+)
> create mode 100644 drivers/pwm/pwm-rp1.c
>
> diff --git a/drivers/pwm/Kconfig b/drivers/pwm/Kconfig
> index 6f3147518376a..32031f2af75af 100644
> --- a/drivers/pwm/Kconfig
> +++ b/drivers/pwm/Kconfig
> @@ -625,6 +625,15 @@ config PWM_ROCKCHIP
> Generic PWM framework driver for the PWM controller found on
> Rockchip SoCs.
>
> +config PWM_RASPBERRYPI_RP1
> + bool "RP1 PWM support"
> + depends on MISC_RP1 || COMPILE_TEST
> + depends on HAS_IOMEM
> + select REGMAP_MMIO
> + select MFD_SYSCON
> + help
> + PWM framework driver for Raspberry Pi RP1 controller.
> +
> config PWM_SAMSUNG
> tristate "Samsung PWM support"
> depends on PLAT_SAMSUNG || ARCH_S5PV210 || ARCH_EXYNOS || COMPILE_TEST
> diff --git a/drivers/pwm/Makefile b/drivers/pwm/Makefile
> index 0dc0d2b69025d..59f29f60f9123 100644
> --- a/drivers/pwm/Makefile
> +++ b/drivers/pwm/Makefile
> @@ -56,6 +56,7 @@ obj-$(CONFIG_PWM_RENESAS_RZG2L_GPT) += pwm-rzg2l-gpt.o
> obj-$(CONFIG_PWM_RENESAS_RZ_MTU3) += pwm-rz-mtu3.o
> obj-$(CONFIG_PWM_RENESAS_TPU) += pwm-renesas-tpu.o
> obj-$(CONFIG_PWM_ROCKCHIP) += pwm-rockchip.o
> +obj-$(CONFIG_PWM_RASPBERRYPI_RP1) += pwm-rp1.o
> obj-$(CONFIG_PWM_SAMSUNG) += pwm-samsung.o
> obj-$(CONFIG_PWM_SIFIVE) += pwm-sifive.o
> obj-$(CONFIG_PWM_SL28CPLD) += pwm-sl28cpld.o
> diff --git a/drivers/pwm/pwm-rp1.c b/drivers/pwm/pwm-rp1.c
> new file mode 100644
> index 0000000000000..b88c697d9567e
> --- /dev/null
> +++ b/drivers/pwm/pwm-rp1.c
> @@ -0,0 +1,344 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * pwm-rp1.c
> + *
> + * Raspberry Pi RP1 PWM.
> + *
> + * Copyright © 2026 Raspberry Pi Ltd.
> + *
> + * Author: Naushir Patuck (naush@raspberrypi.com)
> + *
> + * Based on the pwm-bcm2835 driver by:
> + * Bart Tanghe <bart.tanghe@thomasmore.be>
> + *
> + * Datasheet: https://pip-assets.raspberrypi.com/categories/892-raspberry-pi-5/documents/RP-008370-DS-1-rp1-peripherals.pdf?disposition=inline
> + *
> + * Limitations:
> + * - Channels can be enabled/disabled and their duty cycle and period can
> + * be updated glitchlessly. Update are synchronized with the next strobe
> + * at the end of the current period of the respective channel, once the
> + * update bit is set. The update flag is global, not per-channel.
> + * - Channels are phase-capable, but on RPi5, the firmware can use a channel
> + * phase register to report the RPM of the fan connected to that PWM
> + * channel. As a result, phase control will be ignored for now.
> + */
> +
> +#include <linux/bitops.h>
> +#include <linux/clk.h>
> +#include <linux/err.h>
> +#include <linux/io.h>
> +#include <linux/module.h>
> +#include <linux/of.h>
> +#include <linux/platform_device.h>
> +#include <linux/pwm.h>
> +#include <linux/regmap.h>
> +#include <linux/mfd/syscon.h>
> +
> +#define RP1_PWM_GLOBAL_CTRL 0x000
> +#define RP1_PWM_CHANNEL_CTRL(x) (0x014 + ((x) * 0x10))
> +#define RP1_PWM_RANGE(x) (0x018 + ((x) * 0x10))
> +#define RP1_PWM_PHASE(x) (0x01C + ((x) * 0x10))
> +#define RP1_PWM_DUTY(x) (0x020 + ((x) * 0x10))
> +
> +/* 8:FIFO_POP_MASK + 0:Trailing edge M/S modulation */
> +#define RP1_PWM_CHANNEL_DEFAULT (BIT(8) + BIT(0))
Please add a #define for BIT(8) and then use that and
FIELD_PREP(RP1_PWM_MODE, RP1_PWM_MODE_SOMENICENAME) to define the
constant. Also I would define it below the register defines.
> +#define RP1_PWM_CHANNEL_ENABLE(x) BIT(x)
> +#define RP1_PWM_POLARITY BIT(3)
> +#define RP1_PWM_SET_UPDATE BIT(31)
> +#define RP1_PWM_MODE_MASK GENMASK(1, 0)
s/_MASK// please
It would be great if the bitfield's names started with the register
name.
> +
> +#define RP1_PWM_NUM_PWMS 4
> +
> +struct rp1_pwm {
> + struct regmap *regmap;
> + struct clk *clk;
> + unsigned long clk_rate;
> + bool clk_enabled;
> +};
> +
> +struct rp1_pwm_waveform {
> + u32 period_ticks;
> + u32 duty_ticks;
> + bool enabled;
> + bool inverted_polarity;
> +};
> +
> +static const struct regmap_config rp1_pwm_regmap_config = {
> + .reg_bits = 32,
> + .val_bits = 32,
> + .reg_stride = 4,
> + .max_register = 0x60,
I'm not a fan of aligning the = in a struct, still more if it fails like
here. Please consistently align all =s, or even better, use a single
space before each =. (Same for the struct definitions above, but I won't
insist.)
> +};
> +
> +static void rp1_pwm_apply_config(struct pwm_chip *chip, struct pwm_device *pwm)
> +{
> + struct rp1_pwm *rp1 = pwmchip_get_drvdata(chip);
> + u32 value;
> +
> + /* update the changed registers on the next strobe to avoid glitches */
> + regmap_read(rp1->regmap, RP1_PWM_GLOBAL_CTRL, &value);
> + value |= RP1_PWM_SET_UPDATE;
> + regmap_write(rp1->regmap, RP1_PWM_GLOBAL_CTRL, value);
I assume there is a glitch if I update two channels and the old
configuration of the first channel ends while I'm in the middle of
configuring the second?
> +}
> +
> +static int rp1_pwm_request(struct pwm_chip *chip, struct pwm_device *pwm)
> +{
> + struct rp1_pwm *rp1 = pwmchip_get_drvdata(chip);
> +
> + /* init channel to reset defaults */
> + regmap_write(rp1->regmap, RP1_PWM_CHANNEL_CTRL(pwm->hwpwm), RP1_PWM_CHANNEL_DEFAULT);
> + return 0;
> +}
> +
> +static int rp1_pwm_round_waveform_tohw(struct pwm_chip *chip,
> + struct pwm_device *pwm,
> + const struct pwm_waveform *wf,
> + void *_wfhw)
> +{
> + struct rp1_pwm *rp1 = pwmchip_get_drvdata(chip);
> + struct rp1_pwm_waveform *wfhw = _wfhw;
> + u64 clk_rate = rp1->clk_rate;
> + u64 ticks;
if (!wf->period_length_ns)
wfhw->enabled = false
return 0;
> + ticks = mul_u64_u64_div_u64(wf->period_length_ns, clk_rate, NSEC_PER_SEC);
To ensure this doesn't overflow please fail to probe the driver if
clk_rate > 1 GHz with an explaining comment. (Or alternatively calculate
the length of period_ticks = U32_MAX and skip the calculation if
wf->period_length_ns is bigger.)
> + if (ticks > U32_MAX)
> + ticks = U32_MAX;
> + wfhw->period_ticks = ticks;
What happens if wf->period_length_ns > 0 but ticks == 0?
> + if (wf->duty_offset_ns + wf->duty_length_ns >= wf->period_length_ns) {
The maybe surprising effect here is that in the two cases
wf->duty_offset_ns == wf->period_length_ns and wf->duty_length_ns == 0
and
wf->duty_length_ns == wf->period_length_ns and wf->duty_offset_ns == 0
you're configuring inverted polarity. I doesn't matter technically
because the result is the same, but for consumers still using pwm_state
this is irritating. That's why pwm-stm32 uses inverted polarity only if
also wf->duty_length_ns and wf->duty_offset_ns are non-zero.
> + ticks = mul_u64_u64_div_u64(wf->period_length_ns - wf->duty_length_ns,
> + clk_rate, NSEC_PER_SEC);
The rounding is wrong here. You should pick the biggest duty_length not
bigger than wf->duty_length_ns, so you have to use
ticks = wfhw->period_ticks - mul_u64_u64_div_u64(wf->duty_length_ns, clk_rate, NSEC_PER_SEC):
. I see this is a hole in the pwmtestperf coverage.
> + wfhw->inverted_polarity = true;
> + } else {
> + ticks = mul_u64_u64_div_u64(wf->duty_length_ns, clk_rate, NSEC_PER_SEC);
> + wfhw->inverted_polarity = false;
> + }
> +
> + if (ticks > wfhw->period_ticks)
> + ticks = wfhw->period_ticks;
You can and should assume that wf->duty_length_ns <=
wf->period_length_ns. Then the if condition can never become true.
> + wfhw->duty_ticks = ticks;
> +
> + wfhw->enabled = !!wfhw->duty_ticks;
> +
> + return 0;
> +}
> +
> +static int rp1_pwm_round_waveform_fromhw(struct pwm_chip *chip,
> + struct pwm_device *pwm,
> + const void *_wfhw,
> + struct pwm_waveform *wf)
> +{
> + struct rp1_pwm *rp1 = pwmchip_get_drvdata(chip);
> + const struct rp1_pwm_waveform *wfhw = _wfhw;
> + u64 clk_rate = rp1->clk_rate;
> + u32 ticks;
> +
> + memset(wf, 0, sizeof(*wf));
wf = (struct pwm_waveform){ };
is usually more efficient.
> + if (!wfhw->enabled)
> + return 0;
> +
> + wf->period_length_ns = DIV_ROUND_UP_ULL((u64)wfhw->period_ticks * NSEC_PER_SEC, clk_rate);
> +
> + if (wfhw->inverted_polarity) {
> + wf->duty_length_ns = DIV_ROUND_UP_ULL((u64)wfhw->duty_ticks * NSEC_PER_SEC,
> + clk_rate);
> + } else {
> + wf->duty_offset_ns = DIV_ROUND_UP_ULL((u64)wfhw->duty_ticks * NSEC_PER_SEC,
> + clk_rate);
> + ticks = wfhw->period_ticks - wfhw->duty_ticks;
> + wf->duty_length_ns = DIV_ROUND_UP_ULL((u64)ticks * NSEC_PER_SEC, clk_rate);
> + }
This needs adaption after the rounding issue in tohw is fixed.
> + return 0;
> +}
> +
> +static int rp1_pwm_write_waveform(struct pwm_chip *chip,
> + struct pwm_device *pwm,
> + const void *_wfhw)
> +{
> + struct rp1_pwm *rp1 = pwmchip_get_drvdata(chip);
> + const struct rp1_pwm_waveform *wfhw = _wfhw;
> + u32 value;
> +
> + /* set period and duty cycle */
> + regmap_write(rp1->regmap,
> + RP1_PWM_RANGE(pwm->hwpwm), wfhw->period_ticks);
> + regmap_write(rp1->regmap,
> + RP1_PWM_DUTY(pwm->hwpwm), wfhw->duty_ticks);
> +
> + /* set polarity */
> + regmap_read(rp1->regmap, RP1_PWM_CHANNEL_CTRL(pwm->hwpwm), &value);
> + if (!wfhw->inverted_polarity)
> + value &= ~RP1_PWM_POLARITY;
> + else
> + value |= RP1_PWM_POLARITY;
> + regmap_write(rp1->regmap, RP1_PWM_CHANNEL_CTRL(pwm->hwpwm), value);
> +
> + /* enable/disable */
> + regmap_read(rp1->regmap, RP1_PWM_GLOBAL_CTRL, &value);
> + if (wfhw->enabled)
> + value |= RP1_PWM_CHANNEL_ENABLE(pwm->hwpwm);
> + else
> + value &= ~RP1_PWM_CHANNEL_ENABLE(pwm->hwpwm);
> + regmap_write(rp1->regmap, RP1_PWM_GLOBAL_CTRL, value);
You can exit early if wfhw->enabled is false after clearing the channel
enable bit.
> + rp1_pwm_apply_config(chip, pwm);
> +
> + return 0;
> +}
> +
> +static int rp1_pwm_read_waveform(struct pwm_chip *chip,
> + struct pwm_device *pwm,
> + void *_wfhw)
> +{
> + struct rp1_pwm *rp1 = pwmchip_get_drvdata(chip);
> + struct rp1_pwm_waveform *wfhw = _wfhw;
> + u32 value;
> +
> + regmap_read(rp1->regmap, RP1_PWM_GLOBAL_CTRL, &value);
> + wfhw->enabled = !!(value & RP1_PWM_CHANNEL_ENABLE(pwm->hwpwm));
> +
> + regmap_read(rp1->regmap, RP1_PWM_CHANNEL_CTRL(pwm->hwpwm), &value);
> + wfhw->inverted_polarity = !!(value & RP1_PWM_POLARITY);
> +
> + if (wfhw->enabled) {
> + regmap_read(rp1->regmap, RP1_PWM_RANGE(pwm->hwpwm), &wfhw->period_ticks);
> + regmap_read(rp1->regmap, RP1_PWM_DUTY(pwm->hwpwm), &wfhw->duty_ticks);
> + } else {
> + wfhw->period_ticks = 0;
> + wfhw->duty_ticks = 0;
> + }
> +
> + return 0;
> +}
> +
> +static const struct pwm_ops rp1_pwm_ops = {
> + .sizeof_wfhw = sizeof(struct rp1_pwm_waveform),
> + .request = rp1_pwm_request,
> + .round_waveform_tohw = rp1_pwm_round_waveform_tohw,
> + .round_waveform_fromhw = rp1_pwm_round_waveform_fromhw,
> + .read_waveform = rp1_pwm_read_waveform,
> + .write_waveform = rp1_pwm_write_waveform,
> +};
> +
> +static int rp1_pwm_probe(struct platform_device *pdev)
> +{
> + struct device *dev = &pdev->dev;
> + struct device_node *np = dev->of_node;
> + unsigned long clk_rate;
> + struct pwm_chip *chip;
> + void __iomem *base;
> + struct rp1_pwm *rp1;
> + int ret;
> +
> + chip = devm_pwmchip_alloc(dev, RP1_PWM_NUM_PWMS, sizeof(*rp1));
> + if (IS_ERR(chip))
> + return PTR_ERR(chip);
> +
> + rp1 = pwmchip_get_drvdata(chip);
> +
> + base = devm_platform_ioremap_resource(pdev, 0);
> + if (IS_ERR(base))
> + return PTR_ERR(base);
> +
> + rp1->regmap = devm_regmap_init_mmio(dev, base, &rp1_pwm_regmap_config);
> + if (IS_ERR(rp1->regmap))
> + return dev_err_probe(dev, PTR_ERR(rp1->regmap), "Cannot initialize regmap\n");
> +
> + ret = of_syscon_register_regmap(np, rp1->regmap);
> + if (ret)
> + return dev_err_probe(dev, ret, "Failed to register syscon\n");
> +
> + rp1->clk = devm_clk_get(dev, NULL);
> + if (IS_ERR(rp1->clk))
> + return dev_err_probe(dev, PTR_ERR(rp1->clk), "Clock not found\n");
> +
> + ret = clk_prepare_enable(rp1->clk);
> + if (ret)
> + return dev_err_probe(dev, ret, "Failed to enable clock\n");
> + rp1->clk_enabled = true;
> +
> + ret = devm_clk_rate_exclusive_get(dev, rp1->clk);
> + if (ret) {
> + dev_err_probe(dev, ret, "Fail to get exclusive rate\n");
s/Fail/Failed/
> + goto err_disable_clk;
> + }
> +
> + clk_rate = clk_get_rate(rp1->clk);
> + if (!clk_rate) {
> + ret = dev_err_probe(dev, -EINVAL, "Failed to get clock rate\n");
> + goto err_disable_clk;
> + }
> + rp1->clk_rate = clk_rate;
> +
> + chip->ops = &rp1_pwm_ops;
> +
> + platform_set_drvdata(pdev, chip);
> +
> + ret = devm_pwmchip_add(dev, chip);
> + if (ret) {
> + dev_err_probe(dev, ret, "Failed to register PWM chip\n");
> + goto err_disable_clk;
> + }
> +
> + return 0;
> +
> +err_disable_clk:
> + clk_disable_unprepare(rp1->clk);
> +
> + return ret;
> +}
On remove you miss to balance the call to clk_prepare_enable() (if no
failed call to clk_prepare_enable() in rp1_pwm_resume() happend).
> +
> +static int rp1_pwm_suspend(struct device *dev)
> +{
> + struct rp1_pwm *rp1 = dev_get_drvdata(dev);
> +
> + if (rp1->clk_enabled) {
> + clk_disable_unprepare(rp1->clk);
> + rp1->clk_enabled = false;
> + }
> +
> + return 0;
> +}
> +
> +static int rp1_pwm_resume(struct device *dev)
> +{
> + struct rp1_pwm *rp1 = dev_get_drvdata(dev);
> + int ret;
> +
> + ret = clk_prepare_enable(rp1->clk);
> + if (ret) {
> + dev_err(dev, "Failed to enable clock on resume: %d\n", ret);
Please use %pe for error codes.
> + return ret;
> + }
> +
> + rp1->clk_enabled = true;
> +
> + return 0;
> +}
Best regards
Uwe
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH 1/1] virt: arm-cca-guest: fix error check for RSI_INCOMPLETE
From: Suzuki K Poulose @ 2026-04-10 17:29 UTC (permalink / raw)
To: Sami Mujawar, linux-arm-kernel, linux-kernel
Cc: catalin.marinas, will, steven.price, gshan, YeoReum.Yun,
Jagdish Gediya
In-Reply-To: <20260410163636.259443-1-sami.mujawar@arm.com>
On 10/04/2026 17:36, Sami Mujawar wrote:
> The RSI interface can return RSI_INCOMPLETE when a report spans
> multiple granules. This is an expected condition and should not be
> treated as a fatal error.
>
> Currently, arm_cca_report_new() checks for `info.result != RSI_SUCCESS`
> and bails out, which incorrectly flags RSI_INCOMPLETE as a failure.
> Fix the check to only break out on results other than RSI_SUCCESS or
> RSI_INCOMPLETE.
>
> This ensures partial reports are handled correctly and avoids spurious
> -ENXIO errors when generating attestation reports.
>
> Fixes: 7999edc484ca ("virt: arm-cca-guest: TSM_REPORT support for realms")
> Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>
> Reported-by: Jagdish Gediya <Jagdish.Gediya@arm.com>
Reviewed-by: Suzuki K Poulose <suzuki.poulose@arm.com>
> ---
> drivers/virt/coco/arm-cca-guest/arm-cca-guest.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/virt/coco/arm-cca-guest/arm-cca-guest.c b/drivers/virt/coco/arm-cca-guest/arm-cca-guest.c
> index 0c9ea24a200c..66d00b6ceb78 100644
> --- a/drivers/virt/coco/arm-cca-guest/arm-cca-guest.c
> +++ b/drivers/virt/coco/arm-cca-guest/arm-cca-guest.c
> @@ -157,7 +157,8 @@ static int arm_cca_report_new(struct tsm_report *report, void *data)
> } while (info.result == RSI_INCOMPLETE &&
> info.offset < RSI_GRANULE_SIZE);
>
> - if (info.result != RSI_SUCCESS) {
> + /* Break out in case of failure */
> + if (info.result != RSI_SUCCESS && info.result != RSI_INCOMPLETE) {
> ret = -ENXIO;
> token_size = 0;
> goto exit_free_granule_page;
^ permalink raw reply
* [PATCH v5 4/4] arm64: defconfig: Enable ARCH_HPE
From: nick.hawkins @ 2026-04-10 17:16 UTC (permalink / raw)
To: catalin.marinas, will
Cc: robh, krzk+dt, conor+dt, krzysztof.kozlowski, devicetree,
linux-arm-kernel, linux-kernel, Nick Hawkins
In-Reply-To: <20260410171611.2547255-1-nick.hawkins@hpe.com>
From: Nick Hawkins <nick.hawkins@hpe.com>
Enable ARCH_HPE in the arm64 defconfig to include HPE GSC BMC SoC
support in the default build.
Signed-off-by: Nick Hawkins <nick.hawkins@hpe.com>
---
arch/arm64/configs/defconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index xxxxxxxxxxxxxxx..xxxxxxxxxxxxxxx 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@ -xx,6 +xx,7 @@
CONFIG_ARCH_HISI=y
+CONFIG_ARCH_HPE=y
CONFIG_ARCH_KEEMBAY=y
--
2.34.1
^ permalink raw reply
* [PATCH v5 3/4] arm64: dts: hpe: Add HPE GSC SoC and DL340 Gen12 board DTS
From: nick.hawkins @ 2026-04-10 17:16 UTC (permalink / raw)
To: catalin.marinas, will
Cc: robh, krzk+dt, conor+dt, krzysztof.kozlowski, devicetree,
linux-arm-kernel, linux-kernel, Nick Hawkins
In-Reply-To: <20260410171611.2547255-1-nick.hawkins@hpe.com>
From: Nick Hawkins <nick.hawkins@hpe.com>
Add SoC-level DTSI for the HPE GSC ARM64 BMC SoC, covering the CPU
cluster, GIC v3 interrupt controller, ARM64 generic timer, and console
UART.
Add the board-level DTS for the HPE DL340 Gen12, which includes
gsc.dtsi and adds memory and chosen nodes.
Signed-off-by: Nick Hawkins <nick.hawkins@hpe.com>
---
arch/arm64/boot/dts/hpe/Makefile | 2 +
arch/arm64/boot/dts/hpe/gsc-dl340gen12.dts | 18 ++++
arch/arm64/boot/dts/hpe/gsc.dtsi | 104 +++++++++++++++++++++
3 files changed, 124 insertions(+)
create mode 100644 arch/arm64/boot/dts/hpe/Makefile
create mode 100644 arch/arm64/boot/dts/hpe/gsc-dl340gen12.dts
create mode 100644 arch/arm64/boot/dts/hpe/gsc.dtsi
diff --git a/arch/arm64/boot/dts/hpe/Makefile b/arch/arm64/boot/dts/hpe/Makefile
new file mode 100644
index 000000000000..6b547b8a8154
--- /dev/null
+++ b/arch/arm64/boot/dts/hpe/Makefile
@@ -0,0 +1,2 @@
+# SPDX-License-Identifier: GPL-2.0-only
+dtb-$(CONFIG_ARCH_HPE) += gsc-dl340gen12.dtb
diff --git a/arch/arm64/boot/dts/hpe/gsc-dl340gen12.dts b/arch/arm64/boot/dts/hpe/gsc-dl340gen12.dts
new file mode 100644
index 000000000000..7a3d9f1c4b2e
--- /dev/null
+++ b/arch/arm64/boot/dts/hpe/gsc-dl340gen12.dts
@@ -0,0 +1,18 @@
+// SPDX-License-Identifier: GPL-2.0
+/dts-v1/;
+
+#include "gsc.dtsi"
+
+/ {
+ compatible = "hpe,gsc-dl340gen12", "hpe,gsc";
+ model = "HPE ProLiant DL340 Gen12";
+
+ chosen {
+ stdout-path = &uartc;
+ };
+
+ memory@0 {
+ device_type = "memory";
+ reg = <0x00000000 0x40000000>;
+ };
+};
diff --git a/arch/arm64/boot/dts/hpe/gsc.dtsi b/arch/arm64/boot/dts/hpe/gsc.dtsi
new file mode 100644
index 000000000000..1f4c2a7b3d91
--- /dev/null
+++ b/arch/arm64/boot/dts/hpe/gsc.dtsi
@@ -0,0 +1,104 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Device Tree file for HPE GSC
+ */
+
+#include <dt-bindings/interrupt-controller/arm-gic.h>
+
+/ {
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ osc: clock-33333333 {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-output-names = "osc";
+ clock-frequency = <33333333>;
+ };
+
+ cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ cpu@0 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a53";
+ reg = <0>;
+ enable-method = "spin-table";
+ cpu-release-addr = <0 0xa0008048>;
+ };
+
+ cpu@1 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a53";
+ reg = <1>;
+ enable-method = "spin-table";
+ cpu-release-addr = <0 0xa0008048>;
+ };
+ };
+
+ timer {
+ compatible = "arm,armv8-timer";
+ interrupt-parent = <&gic>;
+ interrupts = <GIC_PPI 13 IRQ_TYPE_LEVEL_LOW>,
+ <GIC_PPI 14 IRQ_TYPE_LEVEL_LOW>,
+ <GIC_PPI 11 IRQ_TYPE_LEVEL_LOW>,
+ <GIC_PPI 10 IRQ_TYPE_LEVEL_LOW>;
+ };
+
+ soc: soc@80000000 {
+ compatible = "simple-bus";
+ reg = <0x80000000 0x80000000>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+
+ uarta: serial@c00000e0 {
+ compatible = "ns16550a";
+ reg = <0xc00000e0 0x8>;
+ clock-frequency = <1846153>;
+ interrupt-parent = <&gic>;
+ interrupts = <GIC_SPI 17 IRQ_TYPE_LEVEL_HIGH>;
+ reg-shift = <0>;
+ };
+
+ uartb: serial@c00000e8 {
+ compatible = "ns16550a";
+ reg = <0xc00000e8 0x8>;
+ clock-frequency = <1846153>;
+ interrupt-parent = <&gic>;
+ interrupts = <GIC_SPI 18 IRQ_TYPE_LEVEL_HIGH>;
+ reg-shift = <0>;
+ };
+
+ uartc: serial@c00000f0 {
+ compatible = "ns16550a";
+ reg = <0xc00000f0 0x8>;
+ clock-frequency = <1846153>;
+ interrupt-parent = <&gic>;
+ interrupts = <GIC_SPI 19 IRQ_TYPE_LEVEL_HIGH>;
+ reg-shift = <0>;
+ };
+
+ uarte: serial@c00003e0 {
+ compatible = "ns16550a";
+ reg = <0xc00003e0 0x8>;
+ clock-frequency = <1846153>;
+ interrupt-parent = <&gic>;
+ interrupts = <GIC_SPI 12 IRQ_TYPE_LEVEL_HIGH>;
+ reg-shift = <0>;
+ };
+
+ gic: gic@ce000000 {
+ compatible = "arm,gic-v3";
+ reg = <0xce000000 0x10000>,
+ <0xce060000 0x40000>,
+ <0xce200000 0x40000>;
+ #address-cells = <0>;
+ #interrupt-cells = <3>;
+ #redistributor-regions = <1>;
+ interrupt-controller;
+ redistributor-stride = <0x0 0x20000>;
+ };
+ };
+};
--
2.34.1
^ permalink raw reply related
* [PATCH v5 2/4] arm64: Kconfig: Add ARCH_HPE platform
From: nick.hawkins @ 2026-04-10 17:16 UTC (permalink / raw)
To: catalin.marinas, will
Cc: robh, krzk+dt, conor+dt, krzysztof.kozlowski, devicetree,
linux-arm-kernel, linux-kernel, Nick Hawkins
In-Reply-To: <20260410171611.2547255-1-nick.hawkins@hpe.com>
From: Nick Hawkins <nick.hawkins@hpe.com>
Add the ARCH_HPE config for HPE ARM64 BMC SoCs to Kconfig.platforms.
Signed-off-by: Nick Hawkins <nick.hawkins@hpe.com>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
---
arch/arm64/Kconfig.platforms | 11 +++++++++++
1 file changed, 11 insertions(+)
diff --git a/arch/arm64/Kconfig.platforms b/arch/arm64/Kconfig.platforms
index 54eb1d7fd419..b4217809c774 100644
--- a/arch/arm64/Kconfig.platforms
+++ b/arch/arm64/Kconfig.platforms
@@ -168,6 +168,17 @@ config ARCH_HISI
help
This enables support for Hisilicon ARMv8 SoC family
+config ARCH_HPE
+ bool "HPE SoC Support"
+ select PINCTRL
+ select GENERIC_IRQ_CHIP
+ select CLKSRC_MMIO
+ help
+ This enables support for HPE ARM-based SoC chips used
+ on HPE servers. HPE SoCs serve as the Baseboard
+ Management Controller (BMC) providing out-of-band server
+ management.
+
config ARCH_KEEMBAY
bool "Keem Bay SoC"
help
--
2.34.1
^ permalink raw reply related
* [PATCH v5 1/4] dt-bindings: arm: hpe,gxp: Add HPE GSC platform compatible
From: nick.hawkins @ 2026-04-10 17:16 UTC (permalink / raw)
To: catalin.marinas, will
Cc: robh, krzk+dt, conor+dt, krzysztof.kozlowski, devicetree,
linux-arm-kernel, linux-kernel, Nick Hawkins
In-Reply-To: <20260410171611.2547255-1-nick.hawkins@hpe.com>
From: Nick Hawkins <nick.hawkins@hpe.com>
Add the HPE GSC ARM64 BMC SoC compatibles to the existing
hpe,gxp.yaml binding.
The initial board compatible is hpe,gsc-dl340gen12 for the DL340 Gen12
server platform.
Add the arm64 DTS path to the existing ARM/HPE GXP MAINTAINERS entry,
renamed to ARM/HPE GXP/GSC ARCHITECTURE.
Signed-off-by: Nick Hawkins <nick.hawkins@hpe.com>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
---
Documentation/devicetree/bindings/arm/hpe,gxp.yaml | 7 ++++++-
MAINTAINERS | 3 ++-
2 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/arm/hpe,gxp.yaml b/Documentation/devicetree/bindings/arm/hpe,gxp.yaml
index 224bbcb93f95..6f057cd58571 100644
--- a/Documentation/devicetree/bindings/arm/hpe,gxp.yaml
+++ b/Documentation/devicetree/bindings/arm/hpe,gxp.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/arm/hpe,gxp.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: HPE BMC GXP platforms
+title: HPE BMC GXP and GSC platforms
maintainers:
- Nick Hawkins <nick.hawkins@hpe.com>
@@ -15,6 +15,11 @@ properties:
oneOf:
+ - description: GSC Based Boards
+ items:
+ - enum:
+ - hpe,gsc-dl340gen12
+ - const: hpe,gsc
- description: GXP Based Boards
items:
- enum:
- hpe,gxp-dl360gen10
- const: hpe,gxp
required:
- compatible
diff --git a/MAINTAINERS b/MAINTAINERS
index 2265e2c9bfbe..80c66de5e342 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2859,7 +2859,7 @@ T: git git://git.kernel.org/pub/scm/linux/kernel/git/kristoffer/linux-hpc.git
F: arch/arm/mach-sa1100/include/mach/jornada720.h
F: arch/arm/mach-sa1100/jornada720.c
-ARM/HPE GXP ARCHITECTURE
+ARM/HPE GXP/GSC ARCHITECTURE
M: Jean-Marie Verdun <verdun@hpe.com>
M: Nick Hawkins <nick.hawkins@hpe.com>
S: Maintained
@@ -2870,6 +2870,7 @@ F: Documentation/devicetree/bindings/spi/hpe,gxp-spifi.yaml
F: Documentation/devicetree/bindings/timer/hpe,gxp-timer.yaml
F: Documentation/hwmon/gxp-fan-ctrl.rst
F: arch/arm/boot/dts/hpe/
+F: arch/arm64/boot/dts/hpe/
F: drivers/clocksource/timer-gxp.c
F: drivers/hwmon/gxp-fan-ctrl.c
F: drivers/i2c/busses/i2c-gxp.c
--
2.34.1
^ permalink raw reply related
* [PATCH v5 0/4] arm64: Add HPE GSC platform support
From: nick.hawkins @ 2026-04-10 17:16 UTC (permalink / raw)
To: catalin.marinas, will
Cc: robh, krzk+dt, conor+dt, krzysztof.kozlowski, devicetree,
linux-arm-kernel, linux-kernel, Nick Hawkins
From: Nick Hawkins <nick.hawkins@hpe.com>
Add initial platform support for the HPE GSC ARM64 BMC SoC.
Changes since v4:
- All patches: Removed duplicate From: field in commit message body
Changes since v3:
- Patch 1: Moved GSC entry before GXP in hpe,gxp.yaml to maintain
alphabetical ordering by fallback compatible (Krzysztof Kozlowski)
- Patch 2: Added Reviewed-by from Krzysztof Kozlowski
- Patch 3: Changed SPDX in gsc-dl340gen12.dts from GPL-2.0-only to
GPL-2.0 to be consistent with gsc.dtsi (Krzysztof Kozlowski);
reordered nodes within soc by ascending unit-address, placing UARTs
before GIC per DTS coding style (Krzysztof Kozlowski);
moved interrupt-parent before interrupts in timer and all UART nodes
per DTS coding style (Krzysztof Kozlowski);
reordered root-level nodes alphabetically: clock-33333333 before cpus
before timer per DTS coding style (Krzysztof Kozlowski);
reordered properties within all nodes to follow DTS coding style:
compatible, reg first, then remaining alphabetically (Krzysztof
Kozlowski)
- Patch 4: New patch adding CONFIG_ARCH_HPE=y to arm64 defconfig
(Krzysztof Kozlowski)
Changes since v2:
- Patch 1: Removed separate ARM64/HPE GSC MAINTAINERS entry; instead
renamed existing ARM/HPE GXP to ARM/HPE GXP/GSC and added arm64 DTS
path there (Conor Dooley)
- Patch 2: Replaced menuconfig ARCH_HPE + nested ARCH_HPE_GSC with a
single config ARCH_HPE; removed extra blank line (Krzysztof Kozlowski)
- Patch 3: Dropped clocks wrapper node, renamed fixed clock to
clock-33333333; renamed ahb bus node to soc; reordered UART nodes by
address for DTS coding style; replaced raw interrupt triplets with
GIC_SPI/IRQ_TYPE_LEVEL_HIGH defines (Krzysztof Kozlowski)
Nick Hawkins (4):
dt-bindings: arm: hpe,gxp: Add HPE GSC platform compatible
arm64: Kconfig: Add ARCH_HPE platform
arm64: dts: hpe: Add HPE GSC SoC and DL340 Gen12 board DTS
arm64: defconfig: Enable ARCH_HPE
.../devicetree/bindings/arm/hpe,gxp.yaml | 7 +-
MAINTAINERS | 3 +-
arch/arm64/Kconfig.platforms | 11 ++
arch/arm64/boot/dts/hpe/Makefile | 2 +
arch/arm64/boot/dts/hpe/gsc-dl340gen12.dts | 18 +++
arch/arm64/boot/dts/hpe/gsc.dtsi | 104 ++++++++++++++++++
arch/arm64/configs/defconfig | 1 +
7 files changed, 144 insertions(+), 2 deletions(-)
create mode 100644 arch/arm64/boot/dts/hpe/Makefile
create mode 100644 arch/arm64/boot/dts/hpe/gsc-dl340gen12.dts
create mode 100644 arch/arm64/boot/dts/hpe/gsc.dtsi
--
2.34.1
^ permalink raw reply
* Re: [PATCH] firmware: raspberrypi: Change dependency to ARCH_BCM2835 and COMPILE_TEST
From: Florian Fainelli @ 2026-04-10 17:15 UTC (permalink / raw)
To: Chen-Yu Tsai, Broadcom internal kernel review list
Cc: linux-rpi-kernel, linux-arm-kernel, linux-kernel
In-Reply-To: <20260408081150.1710717-1-wenst@chromium.org>
On 4/8/26 01:11, Chen-Yu Tsai wrote:
> The Raspberry Pi firmware driver has no compile dependencies on the
> BCM2835 mailbox driver. It's just a indirect runtime dependency: the
> driver only works on a Raspberry Pi.
>
> Change the dependency from BCM2835_MBOX to ARCH_BCM2835. Also allow
> compile tests. This allows drivers that have build time dependencies
> on this firmware driver to be compile tested as well.
>
> Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
No objection, however I think this should also have:
default ARCH_BRCM2835
because without the firmware driver there is effectively nothing that
works. See this patch series:
https://lists.infradead.org/pipermail/linux-arm-kernel/2024-May/927679.html
> ---
> drivers/firmware/Kconfig | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/firmware/Kconfig b/drivers/firmware/Kconfig
> index bbd2155d8483..f99d27c1f6a4 100644
> --- a/drivers/firmware/Kconfig
> +++ b/drivers/firmware/Kconfig
> @@ -114,7 +114,7 @@ config ISCSI_IBFT
>
> config RASPBERRYPI_FIRMWARE
> tristate "Raspberry Pi Firmware Driver"
> - depends on BCM2835_MBOX
> + depends on ARCH_BCM2835 || COMPILE_TEST
> help
> This option enables support for communicating with the firmware on the
> Raspberry Pi.
--
Florian
^ permalink raw reply
* Re: [PATCH 4/4] arm64: dts: amlogic: t7: Add clk measure support
From: Ronald Claveau @ 2026-04-10 16:58 UTC (permalink / raw)
To: Jian Hu
Cc: devicetree, linux-amlogic, linux-kernel, linux-arm-kernel,
Neil Armstrong, Jerome Brunet, Kevin Hilman, Michael Turquette,
Martin Blumenstingl, robh+dt, Rob Herring, Krzysztof Kozlowski
In-Reply-To: <20260410100329.3167482-5-jian.hu@amlogic.com>
Hello Jian,
On 4/10/26 12:03 PM, Jian Hu wrote:
> Add the clock measure device to the T7 SoC family.
>
> Signed-off-by: Jian Hu <jian.hu@amlogic.com>
> ---
> arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi b/arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi
> index 7fe72c94ed62..cec2ea74850d 100644
> --- a/arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi
> +++ b/arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi
> @@ -701,6 +701,11 @@ pwm_ao_cd: pwm@60000 {
> status = "disabled";
> };
>
> + clock-measurer@48000 {
> + compatible = "amlogic,t7-clk-measure";
> + reg = <0x0 0x48000 0x0 0x1c>;
> + };
> +
Can you please order by reg, it should be between pwm_ao_gh and pwm_ab.
Thank you.
> sd_emmc_a: mmc@88000 {
> compatible = "amlogic,t7-mmc", "amlogic,meson-axg-mmc";
> reg = <0x0 0x88000 0x0 0x800>;
--
Best regards,
Ronald
^ permalink raw reply
* Re: [PATCH 1/1] virt: arm-cca-guest: fix error check for RSI_INCOMPLETE
From: Yeoreum Yun @ 2026-04-10 16:51 UTC (permalink / raw)
To: Sami Mujawar
Cc: linux-arm-kernel, linux-kernel, catalin.marinas, will,
steven.price, suzuki.poulose, gshan, Jagdish Gediya
In-Reply-To: <20260410163636.259443-1-sami.mujawar@arm.com>
Look good to me.
Reviewed-by: Yeoreum Yun <yeoreum.yun@arm.com>
On Fri, Apr 10, 2026 at 05:36:36PM +0100, Sami Mujawar wrote:
> The RSI interface can return RSI_INCOMPLETE when a report spans
> multiple granules. This is an expected condition and should not be
> treated as a fatal error.
>
> Currently, arm_cca_report_new() checks for `info.result != RSI_SUCCESS`
> and bails out, which incorrectly flags RSI_INCOMPLETE as a failure.
> Fix the check to only break out on results other than RSI_SUCCESS or
> RSI_INCOMPLETE.
>
> This ensures partial reports are handled correctly and avoids spurious
> -ENXIO errors when generating attestation reports.
>
> Fixes: 7999edc484ca ("virt: arm-cca-guest: TSM_REPORT support for realms")
> Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>
> Reported-by: Jagdish Gediya <Jagdish.Gediya@arm.com>
> ---
> drivers/virt/coco/arm-cca-guest/arm-cca-guest.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/virt/coco/arm-cca-guest/arm-cca-guest.c b/drivers/virt/coco/arm-cca-guest/arm-cca-guest.c
> index 0c9ea24a200c..66d00b6ceb78 100644
> --- a/drivers/virt/coco/arm-cca-guest/arm-cca-guest.c
> +++ b/drivers/virt/coco/arm-cca-guest/arm-cca-guest.c
> @@ -157,7 +157,8 @@ static int arm_cca_report_new(struct tsm_report *report, void *data)
> } while (info.result == RSI_INCOMPLETE &&
> info.offset < RSI_GRANULE_SIZE);
>
> - if (info.result != RSI_SUCCESS) {
> + /* Break out in case of failure */
> + if (info.result != RSI_SUCCESS && info.result != RSI_INCOMPLETE) {
> ret = -ENXIO;
> token_size = 0;
> goto exit_free_granule_page;
> --
> SAMI:{C3F47F37-75D8-414A-A8BA-3980EC8A46D7}
>
--
Sincerely,
Yeoreum Yun
^ permalink raw reply
* Re: [PATCH v2 0/6] perf arm_spe: Dump IMPDEF events
From: Namhyung Kim @ 2026-04-10 16:50 UTC (permalink / raw)
To: James Clark
Cc: John Garry, Will Deacon, Mike Leach, Leo Yan, Peter Zijlstra,
Ingo Molnar, Arnaldo Carvalho de Melo, Mark Rutland,
Alexander Shishkin, Jiri Olsa, Ian Rogers, Adrian Hunter,
Al Grant, linux-arm-kernel, linux-perf-users, linux-kernel,
Leo Yan
In-Reply-To: <20260407-james-spe-impdef-decode-v2-0-55d3ef997c48@linaro.org>
Hi James,
On Tue, Apr 07, 2026 at 03:05:14PM +0100, James Clark wrote:
> In the Arm SPE raw data dump, IMPDEF events aren't printed. Add the
> ability to add names for some known events or print the raw event number
> for unknown events.
>
> For example:
>
> $ perf report -D
>
> ... ARM SPE data: size 0xd000 bytes
> 00000000: b0 18 c6 32 80 00 80 ff a0 PC 0xff80008032c618 el1 ns=1
> 00000009: 64 e7 42 00 00 CONTEXT 0x42e7 el1
> 0000000e: 00 00 00 00 00 PAD
> 00000013: 49 00 LD GP-REG
> 00000015: 52 16 10 EV RETIRED L1D-ACCESS TLB-ACCESS
>
> On N1 the event line becomes:
>
> 00000015: 52 16 10 EV RETIRED L1D-ACCESS TLB-ACCESS LATE-PREFETCH
>
> Or on other cores it becomes:
>
> 00000015: 52 16 10 EV RETIRED L1D-ACCESS TLB-ACCESS IMPDEF:12
>
> Signed-off-by: James Clark <james.clark@linaro.org>
> ---
> Changes in v2:
> - Put MIDR in arm_spe_pkt (Leo)
> - Use for_each_set_bit() (Leo)
> - Use BIT_ULL() to fix 32bit builds (Ian)
> - Don't call strtol() with NULL (Ian)
> - Link to v1: https://lore.kernel.org/r/20260401-james-spe-impdef-decode-v1-0-ad0d372c220c@linaro.org
I'm getting this on 32-bit build.
In file included from /linux/tools/include/linux/bitmap.h:8,
from util/arm-spe-decoder/arm-spe-pkt-decoder.c:11:
util/arm-spe-decoder/arm-spe-pkt-decoder.c: In function 'arm_spe_pkt_desc_event':
util/arm-spe-decoder/arm-spe-pkt-decoder.c:377:37: error: passing argument 1 of 'find_first_bit' from incompatible pointer type [-Werror=incompatible-pointer-types]
377 | for_each_set_bit(i, &payload, 64) {
/linux/tools/include/linux/bitops.h:55:38: note: in definition of macro 'for_each_set_bit'
55 | for ((bit) = find_first_bit((addr), (size)); \
| ^~~~
In file included from /linux/tools/include/linux/bitmap.h:9:
/linux/tools/include/linux/find.h:118:51: note: expected 'const long unsigned int *' but argument is of type 'u64 *' {aka 'long long unsigned int *'}
118 | unsigned long find_first_bit(const unsigned long *addr, unsigned long size)
| ~~~~~~~~~~~~~~~~~~~~~^~~~
Thanks,
Namhyung
>
> ---
> James Clark (6):
> perf arm_spe: Make a function to get the MIDR
> perf arm_spe: Handle missing CPU IDs
> perf arm_spe: Store MIDR in arm_spe_pkt
> perf arm_spe: Turn event name mappings into an array
> perf arm_spe: Decode Arm N1 IMPDEF events
> perf arm_spe: Print remaining IMPDEF event numbers
>
> tools/perf/util/arm-spe-decoder/Build | 2 +
> tools/perf/util/arm-spe-decoder/arm-spe-decoder.c | 17 ++-
> tools/perf/util/arm-spe-decoder/arm-spe-decoder.h | 3 +-
> .../util/arm-spe-decoder/arm-spe-pkt-decoder.c | 144 ++++++++++++++-------
> .../util/arm-spe-decoder/arm-spe-pkt-decoder.h | 5 +-
> tools/perf/util/arm-spe.c | 62 ++++++---
> 6 files changed, 158 insertions(+), 75 deletions(-)
> ---
> base-commit: 74e2dbe7be5037a5e5eed6bc1ad562747ac88566
> change-id: 20260331-james-spe-impdef-decode-d944f4fdcff7
>
> Best regards,
> --
> James Clark <james.clark@linaro.org>
>
^ permalink raw reply
* [PATCH 8/8] arm64: dts: amlogic: t7: khadas-vim4: Add fan cooling to thermal zones
From: Ronald Claveau @ 2026-04-10 16:48 UTC (permalink / raw)
To: Guillaume La Roque, Rafael J. Wysocki, Daniel Lezcano, Zhang Rui,
Lukasz Luba, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Neil Armstrong, Kevin Hilman, Jerome Brunet, Martin Blumenstingl
Cc: linux-pm, linux-amlogic, devicetree, linux-kernel,
linux-arm-kernel, Ronald Claveau
In-Reply-To: <20260410-add-thermal-t7-vim4-v1-0-19f2b8da74d7@aliel.fr>
Add an active trip at 50°C to all six thermal zones and map it to the
khadas_mcu fan controller, using cooling states 30 to 100.
Signed-off-by: Ronald Claveau <linux-kernel-dev@aliel.fr>
---
.../dts/amlogic/amlogic-t7-a311d2-khadas-vim4.dts | 102 +++++++++++++++++++++
1 file changed, 102 insertions(+)
diff --git a/arch/arm64/boot/dts/amlogic/amlogic-t7-a311d2-khadas-vim4.dts b/arch/arm64/boot/dts/amlogic/amlogic-t7-a311d2-khadas-vim4.dts
index 5d7f5390f3a66..ba9219073dd0a 100644
--- a/arch/arm64/boot/dts/amlogic/amlogic-t7-a311d2-khadas-vim4.dts
+++ b/arch/arm64/boot/dts/amlogic/amlogic-t7-a311d2-khadas-vim4.dts
@@ -157,6 +157,74 @@ wifi32k: wifi32k {
};
};
+&a53_thermal {
+ trips {
+ a53_active: a53-active {
+ temperature = <50000>; /* millicelsius */
+ hysteresis = <2000>; /* millicelsius */
+ type = "active";
+ };
+ };
+
+ cooling-maps {
+ map {
+ trip = <&a53_active>;
+ cooling-device = <&khadas_mcu 30 100>;
+ };
+ };
+};
+
+&a73_thermal {
+ trips {
+ a73_active: a73-active {
+ temperature = <50000>; /* millicelsius */
+ hysteresis = <2000>; /* millicelsius */
+ type = "active";
+ };
+ };
+
+ cooling-maps {
+ map {
+ trip = <&a73_active>;
+ cooling-device = <&khadas_mcu 30 100>;
+ };
+ };
+};
+
+&gpu_thermal {
+ trips {
+ gpu_active: gpu-active {
+ temperature = <50000>; /* millicelsius */
+ hysteresis = <2000>; /* millicelsius */
+ type = "active";
+ };
+ };
+
+ cooling-maps {
+ map {
+ trip = <&gpu_active>;
+ cooling-device = <&khadas_mcu 30 100>;
+ };
+ };
+};
+
+&hevc_thermal {
+ trips {
+ hevc_active: hevc-active {
+ temperature = <50000>; /* millicelsius */
+ hysteresis = <2000>; /* millicelsius */
+ type = "active";
+ };
+ };
+
+ cooling-maps {
+ map {
+ trip = <&hevc_active>;
+ cooling-device = <&khadas_mcu 30 100>;
+ };
+ };
+};
+
&i2c_m_ao_a {
status = "okay";
pinctrl-0 = <&i2c0_ao_d_pins>;
@@ -170,6 +238,23 @@ khadas_mcu: system-controller@18 {
};
};
+&nna_thermal {
+ trips {
+ nna_active: nna-active {
+ temperature = <50000>; /* millicelsius */
+ hysteresis = <2000>; /* millicelsius */
+ type = "active";
+ };
+ };
+
+ cooling-maps {
+ map {
+ trip = <&nna_active>;
+ cooling-device = <&khadas_mcu 30 100>;
+ };
+ };
+};
+
&pwm_ab {
status = "okay";
pinctrl-0 = <&pwm_a_pins>;
@@ -266,3 +351,20 @@ &uart_a {
clocks = <&xtal>, <&xtal>, <&xtal>;
clock-names = "xtal", "pclk", "baud";
};
+
+&vpu_thermal {
+ trips {
+ vpu_active: vpu-active {
+ temperature = <50000>; /* millicelsius */
+ hysteresis = <2000>; /* millicelsius */
+ type = "active";
+ };
+ };
+
+ cooling-maps {
+ map {
+ trip = <&vpu_active>;
+ cooling-device = <&khadas_mcu 30 100>;
+ };
+ };
+};
--
2.49.0
^ permalink raw reply related
* [PATCH 6/8] arm64: dts: amlogic: t7: Add thermal sensor nodes
From: Ronald Claveau @ 2026-04-10 16:48 UTC (permalink / raw)
To: Guillaume La Roque, Rafael J. Wysocki, Daniel Lezcano, Zhang Rui,
Lukasz Luba, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Neil Armstrong, Kevin Hilman, Jerome Brunet, Martin Blumenstingl
Cc: linux-pm, linux-amlogic, devicetree, linux-kernel,
linux-arm-kernel, Ronald Claveau
In-Reply-To: <20260410-add-thermal-t7-vim4-v1-0-19f2b8da74d7@aliel.fr>
Add six temperature sensor nodes using the amlogic,t7-thermal compatible:
a73, a53, gpu, nna, vpu, and hevc. Each sensor retrieves its calibration
data from the secure monitor via the amlogic,secure-monitor phandle with
the corresponding tsensor_id argument.
Signed-off-by: Ronald Claveau <linux-kernel-dev@aliel.fr>
---
arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi | 58 +++++++++++++++++++++++++++++
1 file changed, 58 insertions(+)
diff --git a/arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi b/arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi
index 7aec65f036a9c..62f259b2b17d2 100644
--- a/arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi
+++ b/arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi
@@ -656,6 +656,24 @@ sec_ao: ao-secure@10220 {
amlogic,has-chip-id;
};
+ a73_tsensor: temperature-sensor@20000 {
+ compatible = "amlogic,t7-thermal";
+ reg = <0x0 0x20000 0x0 0x50>;
+ interrupts = <GIC_SPI 31 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&clkc_periphs CLKID_TS>;
+ #thermal-sensor-cells = <0>;
+ amlogic,secure-monitor = <&sm 1>;
+ };
+
+ a53_tsensor: temperature-sensor@22000 {
+ compatible = "amlogic,t7-thermal";
+ reg = <0x0 0x22000 0x0 0x50>;
+ interrupts = <GIC_SPI 30 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&clkc_periphs CLKID_TS>;
+ #thermal-sensor-cells = <0>;
+ amlogic,secure-monitor = <&sm 2>;
+ };
+
pwm_ao_ef: pwm@30000 {
compatible = "amlogic,t7-pwm", "amlogic,meson-s4-pwm";
reg = <0x0 0x30000 0x0 0x24>;
@@ -770,6 +788,46 @@ sd_emmc_c: mmc@8c000 {
assigned-clock-parents = <&xtal>;
status = "disabled";
};
+
+ gpu_tsensor: temperature-sensor@94000 {
+ compatible = "amlogic,t7-thermal";
+ reg = <0x0 0x94000 0x0 0x50>;
+ interrupts = <GIC_SPI 83 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&clkc_periphs CLKID_TS>;
+ power-domains = <&pwrc PWRC_T7_MALI_TOP_ID>;
+ #thermal-sensor-cells = <0>;
+ amlogic,secure-monitor = <&sm 3>;
+ };
+
+ nna_tsensor: temperature-sensor@96000 {
+ compatible = "amlogic,t7-thermal";
+ reg = <0x0 0x96000 0x0 0x50>;
+ interrupts = <GIC_SPI 84 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&clkc_periphs CLKID_TS>;
+ power-domains = <&pwrc PWRC_T7_NNA_TOP_ID>;
+ #thermal-sensor-cells = <0>;
+ amlogic,secure-monitor = <&sm 4>;
+ };
+
+ vpu_tsensor: temperature-sensor@98000 {
+ compatible = "amlogic,t7-thermal";
+ reg = <0x0 0x98000 0x0 0x50>;
+ interrupts = <GIC_SPI 85 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&clkc_periphs CLKID_TS>;
+ power-domains = <&pwrc PWRC_T7_VPU_HDMI_ID>;
+ #thermal-sensor-cells = <0>;
+ amlogic,secure-monitor = <&sm 6>;
+ };
+
+ hevc_tsensor: temperature-sensor@9a000 {
+ compatible = "amlogic,t7-thermal";
+ reg = <0x0 0x9a000 0x0 0x50>;
+ interrupts = <GIC_SPI 86 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&clkc_periphs CLKID_TS>;
+ power-domains = <&pwrc PWRC_T7_DOS_HEVC_ID>;
+ #thermal-sensor-cells = <0>;
+ amlogic,secure-monitor = <&sm 5>;
+ };
};
};
--
2.49.0
^ permalink raw reply related
* [PATCH 4/8] thermal: amlogic: Add support for secure monitor calibration readout
From: Ronald Claveau @ 2026-04-10 16:48 UTC (permalink / raw)
To: Guillaume La Roque, Rafael J. Wysocki, Daniel Lezcano, Zhang Rui,
Lukasz Luba, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Neil Armstrong, Kevin Hilman, Jerome Brunet, Martin Blumenstingl
Cc: linux-pm, linux-amlogic, devicetree, linux-kernel,
linux-arm-kernel, Ronald Claveau
In-Reply-To: <20260410-add-thermal-t7-vim4-v1-0-19f2b8da74d7@aliel.fr>
Some SoCs (e.g. T7) expose thermal calibration data through the secure
monitor rather than a directly accessible eFuse register. Add a use_sm
flag to amlogic_thermal_data to select this path, and retrieve the
firmware handle and tsensor_id from the "amlogic,secure-monitor" DT
phandle with one fixed argument.
Also introduce the amlogic,t7-thermal compatible using this new path.
Signed-off-by: Ronald Claveau <linux-kernel-dev@aliel.fr>
---
drivers/thermal/amlogic_thermal.c | 58 +++++++++++++++++++++++++++++++++++----
1 file changed, 53 insertions(+), 5 deletions(-)
diff --git a/drivers/thermal/amlogic_thermal.c b/drivers/thermal/amlogic_thermal.c
index 5448d772db12a..11e3948cc0669 100644
--- a/drivers/thermal/amlogic_thermal.c
+++ b/drivers/thermal/amlogic_thermal.c
@@ -25,6 +25,7 @@
#include <linux/platform_device.h>
#include <linux/regmap.h>
#include <linux/thermal.h>
+#include <linux/firmware/meson/meson_sm.h>
#include "thermal_hwmon.h"
@@ -84,12 +85,14 @@ struct amlogic_thermal_soc_calib_data {
* @u_efuse_off: register offset to read fused calibration value
* @calibration_parameters: calibration parameters structure pointer
* @regmap_config: regmap config for the device
+ * @use_sm: read data from secure monitor instead of efuse
* This structure is required for configuration of amlogic thermal driver.
*/
struct amlogic_thermal_data {
int u_efuse_off;
const struct amlogic_thermal_soc_calib_data *calibration_parameters;
const struct regmap_config *regmap_config;
+ bool use_sm;
};
struct amlogic_thermal {
@@ -100,6 +103,8 @@ struct amlogic_thermal {
struct clk *clk;
struct thermal_zone_device *tzd;
u32 trim_info;
+ struct meson_sm_firmware *sm_fw;
+ u32 tsensor_id;
};
/*
@@ -138,6 +143,12 @@ static int amlogic_thermal_initialize(struct amlogic_thermal *pdata)
int ret = 0;
int ver;
+ if (pdata->data->use_sm) {
+ return meson_sm_get_thermal_calib(pdata->sm_fw,
+ &pdata->trim_info,
+ pdata->tsensor_id);
+ }
+
regmap_read(pdata->sec_ao_map, pdata->data->u_efuse_off,
&pdata->trim_info);
@@ -226,6 +237,12 @@ static const struct amlogic_thermal_data amlogic_thermal_a1_cpu_param = {
.regmap_config = &amlogic_thermal_regmap_config_g12a,
};
+static const struct amlogic_thermal_data amlogic_thermal_t7_param = {
+ .use_sm = true,
+ .calibration_parameters = &amlogic_thermal_g12a,
+ .regmap_config = &amlogic_thermal_regmap_config_g12a,
+};
+
static const struct of_device_id of_amlogic_thermal_match[] = {
{
.compatible = "amlogic,g12a-ddr-thermal",
@@ -239,6 +256,10 @@ static const struct of_device_id of_amlogic_thermal_match[] = {
.compatible = "amlogic,a1-cpu-thermal",
.data = &amlogic_thermal_a1_cpu_param,
},
+ {
+ .compatible = "amlogic,t7-thermal",
+ .data = &amlogic_thermal_t7_param,
+ },
{ /* sentinel */ }
};
MODULE_DEVICE_TABLE(of, of_amlogic_thermal_match);
@@ -271,11 +292,38 @@ static int amlogic_thermal_probe(struct platform_device *pdev)
if (IS_ERR(pdata->clk))
return dev_err_probe(dev, PTR_ERR(pdata->clk), "failed to get clock\n");
- pdata->sec_ao_map = syscon_regmap_lookup_by_phandle
- (pdev->dev.of_node, "amlogic,ao-secure");
- if (IS_ERR(pdata->sec_ao_map)) {
- dev_err(dev, "syscon regmap lookup failed.\n");
- return PTR_ERR(pdata->sec_ao_map);
+ if (pdata->data->use_sm) {
+ struct device_node *sm_np;
+ struct of_phandle_args ph_args;
+
+ ret = of_parse_phandle_with_fixed_args(pdev->dev.of_node,
+ "amlogic,secure-monitor",
+ 1, 0, &ph_args);
+ if (ret)
+ return ret;
+
+ sm_np = ph_args.np;
+ if (!sm_np) {
+ dev_err(dev,
+ "Failed to parse secure monitor phandle\n");
+ return -ENODEV;
+ }
+
+ pdata->sm_fw = meson_sm_get(sm_np);
+ of_node_put(sm_np);
+ if (!pdata->sm_fw) {
+ dev_err(dev, "Failed to get secure monitor firmware\n");
+ return -EPROBE_DEFER;
+ }
+
+ pdata->tsensor_id = ph_args.args[0];
+ } else {
+ pdata->sec_ao_map = syscon_regmap_lookup_by_phandle
+ (pdev->dev.of_node, "amlogic,ao-secure");
+ if (IS_ERR(pdata->sec_ao_map)) {
+ dev_err(dev, "syscon regmap lookup failed.\n");
+ return PTR_ERR(pdata->sec_ao_map);
+ }
}
pdata->tzd = devm_thermal_of_zone_register(&pdev->dev,
--
2.49.0
^ permalink raw reply related
* [PATCH 0/8] arm64: amlogic: T7 thermal support
From: Ronald Claveau @ 2026-04-10 16:48 UTC (permalink / raw)
To: Guillaume La Roque, Rafael J. Wysocki, Daniel Lezcano, Zhang Rui,
Lukasz Luba, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Neil Armstrong, Kevin Hilman, Jerome Brunet, Martin Blumenstingl
Cc: linux-pm, linux-amlogic, devicetree, linux-kernel,
linux-arm-kernel, Ronald Claveau
This series adds thermal monitoring support for the Amlogic T7 SoC,
used on the Khadas VIM4 board.
The T7 exposes six thermal sensors (a53, a73, gpu, nna, vpu, hevc),
each accessible through the secure monitor firmware interface rather
than a directly mapped eFuse register as on older SoCs.
The series is organized as follows:
- Patch 1 extends the amlogic,t7-thermal DT binding to describe the
new amlogic,secure-monitor property.
- Patches 2-3 extend the Meson secure monitor driver to expose a
thermal calibration read command (SMC ID 0x82000047).
- Patch 4 adds the secure monitor readout path to the amlogic thermal
driver and introduces the amlogic,t7-thermal compatible.
- Patches 5-7 wire up the T7 DTSI with CPU cooling cells, sensor
nodes, and thermal zones.
- Patch 8 extends the Khadas VIM4 DTS to map all thermal zones to the
on-board MCU fan controller (states 30–100, corresponding to the
FAN_CTRL register range 0x1E–0x64).
Signed-off-by: Ronald Claveau <linux-kernel-dev@aliel.fr>
---
Ronald Claveau (8):
dt-bindings: thermal: amlogic: Add support for T7
firmware: meson: sm: Thermal calibration read via secure monitor
firmware: meson: sm: Add thermal calibration SMC call
thermal: amlogic: Add support for secure monitor calibration readout
arm64: dts: amlogic: t7: Add cooling cells to all CPUs
arm64: dts: amlogic: t7: Add thermal sensor nodes
arm64: dts: amlogic: t7: Add thermal zones
arm64: dts: amlogic: t7: khadas-vim4: Add fan cooling to thermal zones
.../bindings/thermal/amlogic,thermal.yaml | 40 +++-
.../dts/amlogic/amlogic-t7-a311d2-khadas-vim4.dts | 102 +++++++++
arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi | 245 +++++++++++++++++++++
drivers/firmware/meson/meson_sm.c | 19 +-
drivers/thermal/amlogic_thermal.c | 58 ++++-
include/linux/firmware/meson/meson_sm.h | 3 +
6 files changed, 456 insertions(+), 11 deletions(-)
---
base-commit: f7b64ed948718290209074a50bb0df17e5944873
change-id: 20260410-add-thermal-t7-vim4-00e571badcc1
prerequisite-message-id: <20260326092645.1053261-1-jian.hu@amlogic.com>
prerequisite-patch-id: f03a086b4137158412b2d47b3de793b858de8dde
prerequisite-patch-id: 123970c9b29c2090440f2fd71c85d3c6fd8e36de
prerequisite-patch-id: 3e2e56b0926ba327b520f935df4ced5089bbe503
prerequisite-patch-id: 65a5d76ffdbc9b3aab3385bb65cb027004c30e7e
prerequisite-patch-id: 237269801826dd3ad7fb16eb4d7d6d4eab504278
prerequisite-patch-id: 57e9b08a968aedf543d3d0d56cf1ca4db20b2a16
prerequisite-change-id: 20260326-add-bcm43752-compatible-e264a4f7973a:v2
prerequisite-patch-id: cd98b74fa56af72af2553f391c400981d83cd4f4
prerequisite-patch-id: b730f5e42be1d89d193e63a0265495cdbf2c7d7b
prerequisite-change-id: 20260330-fix-invalid-property-bbe54d933f71:v2
prerequisite-patch-id: 8d675e7a239985c762843515b241f0a2f45f9c92
prerequisite-change-id: 20260331-fix-aml-t7-null-reset-2b608ebf9da4:v1
prerequisite-patch-id: 5b5de77af11747ce964404fb827d2ee2bff47ea5
prerequisite-patch-id: 1e37fc75fed1e533adee0f3e7e6ead1f8ff3c55c
prerequisite-patch-id: 65a5d76ffdbc9b3aab3385bb65cb027004c30e7e
prerequisite-patch-id: 2daf583fb5e7449a02bd217d8aca330171b598aa
prerequisite-patch-id: 237269801826dd3ad7fb16eb4d7d6d4eab504278
prerequisite-patch-id: d1ddf9b7710e91f8062de83bd7ba55afb2c4c112
prerequisite-patch-id: 57e9b08a968aedf543d3d0d56cf1ca4db20b2a16
prerequisite-patch-id: cd98b74fa56af72af2553f391c400981d83cd4f4
prerequisite-patch-id: b730f5e42be1d89d193e63a0265495cdbf2c7d7b
prerequisite-patch-id: 9debd88fa60febed9cd7208f86603b4c2d270520
prerequisite-patch-id: 314ef9ff0c4d1d15dab1dea9d92aa065f1eac3e9
prerequisite-change-id: 20260402-add-mcu-fan-khadas-vim4-ac1cbe553c9b:v2
prerequisite-patch-id: f03a086b4137158412b2d47b3de793b858de8dde
prerequisite-patch-id: 123970c9b29c2090440f2fd71c85d3c6fd8e36de
prerequisite-patch-id: 3e2e56b0926ba327b520f935df4ced5089bbe503
prerequisite-patch-id: 65a5d76ffdbc9b3aab3385bb65cb027004c30e7e
prerequisite-patch-id: 237269801826dd3ad7fb16eb4d7d6d4eab504278
prerequisite-patch-id: 57e9b08a968aedf543d3d0d56cf1ca4db20b2a16
prerequisite-patch-id: cd98b74fa56af72af2553f391c400981d83cd4f4
prerequisite-patch-id: b730f5e42be1d89d193e63a0265495cdbf2c7d7b
prerequisite-patch-id: 8d675e7a239985c762843515b241f0a2f45f9c92
prerequisite-patch-id: 9debd88fa60febed9cd7208f86603b4c2d270520
prerequisite-patch-id: 314ef9ff0c4d1d15dab1dea9d92aa065f1eac3e9
prerequisite-patch-id: 34a2bbfe3ce30c530e69af5083aa26534b2c2560
prerequisite-patch-id: 406f88d7dabd3a870b358fb53c21686f29eb32b7
prerequisite-patch-id: d7a75ae3be0f54e0a7e81ccb0043a2f05423c9d0
prerequisite-patch-id: 5e19dc5ace12b532284246f5c2ff3f214d8a9c4f
prerequisite-patch-id: d6a87ebcf5246eb67b94ca0908afa3df9f9383fe
prerequisite-patch-id: 4809bbedf79f59e1abc52c17cffc0b1bbb43d365
prerequisite-patch-id: c050e8bac4b5491f6c7008a5ccb26f20fad38b46
prerequisite-patch-id: 30677db8fc57270787245103c0d5acf8791307b0
Best regards,
--
Ronald Claveau <linux-kernel-dev@aliel.fr>
^ permalink raw reply
* [PATCH 7/8] arm64: dts: amlogic: t7: Add thermal zones
From: Ronald Claveau @ 2026-04-10 16:48 UTC (permalink / raw)
To: Guillaume La Roque, Rafael J. Wysocki, Daniel Lezcano, Zhang Rui,
Lukasz Luba, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Neil Armstrong, Kevin Hilman, Jerome Brunet, Martin Blumenstingl
Cc: linux-pm, linux-amlogic, devicetree, linux-kernel,
linux-arm-kernel, Ronald Claveau
In-Reply-To: <20260410-add-thermal-t7-vim4-v1-0-19f2b8da74d7@aliel.fr>
Add thermal zones for all six sensors: a53, a73, gpu, nna, vpu, and hevc.
Signed-off-by: Ronald Claveau <linux-kernel-dev@aliel.fr>
---
arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi | 179 ++++++++++++++++++++++++++++
1 file changed, 179 insertions(+)
diff --git a/arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi b/arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi
index 62f259b2b17d2..c6ea0f20a879f 100644
--- a/arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi
+++ b/arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi
@@ -9,6 +9,7 @@
#include <dt-bindings/clock/amlogic,t7-scmi.h>
#include <dt-bindings/clock/amlogic,t7-pll-clkc.h>
#include <dt-bindings/clock/amlogic,t7-peripherals-clkc.h>
+#include <dt-bindings/thermal/thermal.h>
/ {
interrupt-parent = <&gic>;
@@ -829,6 +830,184 @@ hevc_tsensor: temperature-sensor@9a000 {
amlogic,secure-monitor = <&sm 5>;
};
};
+ };
+
+ thermal-zones {
+ a53_thermal: a53-thermal {
+ polling-delay = <1000>;
+ polling-delay-passive = <100>;
+ thermal-sensors = <&a53_tsensor>;
+
+ trips {
+ a53_passive: a53-passive {
+ temperature = <85000>; /* millicelsius */
+ hysteresis = <2000>; /* millicelsius */
+ type = "passive";
+ };
+
+ a53_hot: a53-hot {
+ temperature = <95000>; /* millicelsius */
+ hysteresis = <2000>; /* millicelsius */
+ type = "hot";
+ };
+
+ a53_critical: a53-critical {
+ temperature = <110000>; /* millicelsius */
+ hysteresis = <2000>; /* millicelsius */
+ type = "critical";
+ };
+ };
+
+ cooling-maps {
+ map-a53 {
+ trip = <&a53_passive>;
+ cooling-device =
+ <&cpu100 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>,
+ <&cpu101 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>,
+ <&cpu102 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>,
+ <&cpu103 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>;
+ };
+ };
+ };
+
+ a73_thermal: a73-thermal {
+ polling-delay = <1000>;
+ polling-delay-passive = <100>;
+ thermal-sensors = <&a73_tsensor>;
+
+ trips {
+ a73_passive: a73-passive {
+ temperature = <85000>; /* millicelsius */
+ hysteresis = <2000>; /* millicelsius */
+ type = "passive";
+ };
+
+ a73_hot: a73-hot {
+ temperature = <95000>; /* millicelsius */
+ hysteresis = <2000>; /* millicelsius */
+ type = "hot";
+ };
+
+ a73_critical: a73-critical {
+ temperature = <110000>; /* millicelsius */
+ hysteresis = <2000>; /* millicelsius */
+ type = "critical";
+ };
+ };
+
+ cooling-maps {
+ map-a73 {
+ trip = <&a73_passive>;
+ cooling-device = <&cpu0 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>,
+ <&cpu1 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>,
+ <&cpu2 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>,
+ <&cpu3 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>;
+ };
+ };
+ };
+
+ gpu_thermal: gpu-thermal {
+ polling-delay = <1000>;
+ polling-delay-passive = <100>;
+ thermal-sensors = <&gpu_tsensor>;
+
+ trips {
+ gpu_passive: gpu-passive {
+ temperature = <95000>;
+ hysteresis = <5000>;
+ type = "passive";
+ };
+
+ gpu_hot: gpu-hot {
+ temperature = <105000>;
+ hysteresis = <5000>;
+ type = "passive";
+ };
+ gpu_critical: gpu-critical {
+ temperature = <115000>;
+ hysteresis = <1000>;
+ type = "critical";
+ };
+ };
+ };
+
+ hevc_thermal: hevc-thermal {
+ polling-delay = <1000>;
+ polling-delay-passive = <100>;
+ thermal-sensors = <&hevc_tsensor>;
+
+ trips {
+ hevc_passive: hevc-passive {
+ temperature = <95000>;
+ hysteresis = <5000>;
+ type = "passive";
+ };
+
+ hevc_hot: hevc-hot {
+ temperature = <105000>;
+ hysteresis = <5000>;
+ type = "passive";
+ };
+
+ hevc_critical: hevc-critical {
+ temperature = <115000>;
+ hysteresis = <1000>;
+ type = "critical";
+ };
+ };
+ };
+
+ nna_thermal: nna-thermal {
+ polling-delay = <1000>;
+ polling-delay-passive = <100>;
+ thermal-sensors = <&nna_tsensor>;
+
+ trips {
+ nna_passive: nna-passive {
+ temperature = <95000>;
+ hysteresis = <5000>;
+ type = "passive";
+ };
+
+ nna_hot: nna-hot {
+ temperature = <105000>;
+ hysteresis = <5000>;
+ type = "passive";
+ };
+
+ nna_critical: nna-critical {
+ temperature = <115000>;
+ hysteresis = <1000>;
+ type = "critical";
+ };
+ };
+ };
+
+ vpu_thermal: vpu-thermal {
+ polling-delay = <1000>;
+ polling-delay-passive = <100>;
+ thermal-sensors = <&vpu_tsensor>;
+
+ trips {
+ vpu_passive: vpu-passive {
+ temperature = <95000>;
+ hysteresis = <5000>;
+ type = "passive";
+ };
+
+ vpu_hot: vpu-hot {
+ temperature = <105000>;
+ hysteresis = <5000>;
+ type = "passive";
+ };
+
+ vpu_critical: vpu-critical {
+ temperature = <115000>;
+ hysteresis = <1000>;
+ type = "critical";
+ };
+ };
+ };
};
};
--
2.49.0
^ permalink raw reply related
* [PATCH 1/8] dt-bindings: thermal: amlogic: Add support for T7
From: Ronald Claveau @ 2026-04-10 16:48 UTC (permalink / raw)
To: Guillaume La Roque, Rafael J. Wysocki, Daniel Lezcano, Zhang Rui,
Lukasz Luba, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Neil Armstrong, Kevin Hilman, Jerome Brunet, Martin Blumenstingl
Cc: linux-pm, linux-amlogic, devicetree, linux-kernel,
linux-arm-kernel, Ronald Claveau
In-Reply-To: <20260410-add-thermal-t7-vim4-v1-0-19f2b8da74d7@aliel.fr>
Add the amlogic,t7-thermal compatible for the Amlogic T7 thermal sensor.
Unlike existing variants which use a phandle to the ao-secure syscon,
the T7 relies on a secure monitor interface described by a phandle and
a sensor index argument.
Introduce the amlogic,secure-monitor property as a phandle-array and
make amlogic,ao-secure or amlogic,secure-monitor conditionally required
depending on the compatible.
Signed-off-by: Ronald Claveau <linux-kernel-dev@aliel.fr>
---
.../bindings/thermal/amlogic,thermal.yaml | 40 +++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/thermal/amlogic,thermal.yaml b/Documentation/devicetree/bindings/thermal/amlogic,thermal.yaml
index 70b273271754b..85ee73c6e1161 100644
--- a/Documentation/devicetree/bindings/thermal/amlogic,thermal.yaml
+++ b/Documentation/devicetree/bindings/thermal/amlogic,thermal.yaml
@@ -22,6 +22,7 @@ properties:
- amlogic,g12a-ddr-thermal
- const: amlogic,g12a-thermal
- const: amlogic,a1-cpu-thermal
+ - const: amlogic,t7-thermal
reg:
maxItems: 1
@@ -42,12 +43,40 @@ properties:
'#thermal-sensor-cells':
const: 0
+ amlogic,secure-monitor:
+ description: phandle to the secure monitor
+ $ref: /schemas/types.yaml#/definitions/phandle-array
+ items:
+ - items:
+ - description: phandle to the secure monitor
+ - description: sensor index
+
required:
- compatible
- reg
- interrupts
- clocks
- - amlogic,ao-secure
+
+allOf:
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - amlogic,g12a-cpu-thermal
+ - amlogic,g12a-ddr-thermal
+ - amlogic,a1-cpu-thermal
+ then:
+ required:
+ - amlogic,ao-secure
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: amlogic,t7-thermal
+ then:
+ required:
+ - amlogic,secure-monitor
unevaluatedProperties: false
@@ -62,4 +91,13 @@ examples:
#thermal-sensor-cells = <0>;
amlogic,ao-secure = <&sec_AO>;
};
+ - |
+ a73_tsensor: temperature-sensor@20000 {
+ compatible = "amlogic,t7-thermal";
+ reg = <0x0 0x20000 0x0 0x50>;
+ interrupts = <GIC_SPI 31 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&clkc_periphs CLKID_TS>;
+ #thermal-sensor-cells = <0>;
+ amlogic,secure-monitor = <&sm 1>;
+ };
...
--
2.49.0
^ permalink raw reply related
* [PATCH 5/8] arm64: dts: amlogic: t7: Add cooling cells to all CPUs
From: Ronald Claveau @ 2026-04-10 16:48 UTC (permalink / raw)
To: Guillaume La Roque, Rafael J. Wysocki, Daniel Lezcano, Zhang Rui,
Lukasz Luba, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Neil Armstrong, Kevin Hilman, Jerome Brunet, Martin Blumenstingl
Cc: linux-pm, linux-amlogic, devicetree, linux-kernel,
linux-arm-kernel, Ronald Claveau
In-Reply-To: <20260410-add-thermal-t7-vim4-v1-0-19f2b8da74d7@aliel.fr>
Add #cooling-cells = <2> to all CPU nodes (both little and big cluster)
to allow them to be used as cooling devices in thermal zone mappings.
Signed-off-by: Ronald Claveau <linux-kernel-dev@aliel.fr>
---
arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi b/arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi
index 560c9dce35266..7aec65f036a9c 100644
--- a/arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi
+++ b/arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi
@@ -63,6 +63,7 @@ cpu100: cpu@100 {
i-cache-size = <0x8000>;
i-cache-sets = <32>;
next-level-cache = <&l2_cache_l>;
+ #cooling-cells = <2>;
};
cpu101: cpu@101 {
@@ -77,6 +78,7 @@ cpu101: cpu@101 {
i-cache-size = <0x8000>;
i-cache-sets = <32>;
next-level-cache = <&l2_cache_l>;
+ #cooling-cells = <2>;
};
cpu102: cpu@102 {
@@ -91,6 +93,7 @@ cpu102: cpu@102 {
i-cache-size = <0x8000>;
i-cache-sets = <32>;
next-level-cache = <&l2_cache_l>;
+ #cooling-cells = <2>;
};
cpu103: cpu@103 {
@@ -105,6 +108,7 @@ cpu103: cpu@103 {
i-cache-size = <0x8000>;
i-cache-sets = <32>;
next-level-cache = <&l2_cache_l>;
+ #cooling-cells = <2>;
};
cpu0: cpu@0 {
@@ -119,6 +123,7 @@ cpu0: cpu@0 {
i-cache-size = <0x10000>;
i-cache-sets = <64>;
next-level-cache = <&l2_cache_b>;
+ #cooling-cells = <2>;
};
cpu1: cpu@1 {
@@ -133,6 +138,7 @@ cpu1: cpu@1 {
i-cache-size = <0x10000>;
i-cache-sets = <64>;
next-level-cache = <&l2_cache_b>;
+ #cooling-cells = <2>;
};
cpu2: cpu@2 {
@@ -147,6 +153,7 @@ cpu2: cpu@2 {
i-cache-size = <0x10000>;
i-cache-sets = <64>;
next-level-cache = <&l2_cache_b>;
+ #cooling-cells = <2>;
};
cpu3: cpu@3 {
@@ -161,6 +168,7 @@ cpu3: cpu@3 {
i-cache-size = <0x10000>;
i-cache-sets = <64>;
next-level-cache = <&l2_cache_b>;
+ #cooling-cells = <2>;
};
l2_cache_l: l2-cache-cluster0 {
--
2.49.0
^ permalink raw reply related
* [PATCH 3/8] firmware: meson: sm: Add thermal calibration SMC call
From: Ronald Claveau @ 2026-04-10 16:48 UTC (permalink / raw)
To: Guillaume La Roque, Rafael J. Wysocki, Daniel Lezcano, Zhang Rui,
Lukasz Luba, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Neil Armstrong, Kevin Hilman, Jerome Brunet, Martin Blumenstingl
Cc: linux-pm, linux-amlogic, devicetree, linux-kernel,
linux-arm-kernel, Ronald Claveau
In-Reply-To: <20260410-add-thermal-t7-vim4-v1-0-19f2b8da74d7@aliel.fr>
Add SM_THERMAL_CALIB_READ at SMC ID 0x82000047 in the command
table and implement meson_sm_get_thermal_calib(), which forwards the
tsensor_id argument to the secure monitor and returns the calibration data.
Also realign the CMD() column to improve readability.
Signed-off-by: Ronald Claveau <linux-kernel-dev@aliel.fr>
---
drivers/firmware/meson/meson_sm.c | 19 ++++++++++++++-----
1 file changed, 14 insertions(+), 5 deletions(-)
diff --git a/drivers/firmware/meson/meson_sm.c b/drivers/firmware/meson/meson_sm.c
index 3ab67aaa9e5da..da0dbcd8a2ff2 100644
--- a/drivers/firmware/meson/meson_sm.c
+++ b/drivers/firmware/meson/meson_sm.c
@@ -41,12 +41,13 @@ static const struct meson_sm_chip gxbb_chip = {
.cmd_shmem_in_base = 0x82000020,
.cmd_shmem_out_base = 0x82000021,
.cmd = {
- CMD(SM_EFUSE_READ, 0x82000030),
- CMD(SM_EFUSE_WRITE, 0x82000031),
+ CMD(SM_EFUSE_READ, 0x82000030),
+ CMD(SM_EFUSE_WRITE, 0x82000031),
CMD(SM_EFUSE_USER_MAX, 0x82000033),
- CMD(SM_GET_CHIP_ID, 0x82000044),
- CMD(SM_A1_PWRC_SET, 0x82000093),
- CMD(SM_A1_PWRC_GET, 0x82000095),
+ CMD(SM_GET_CHIP_ID, 0x82000044),
+ CMD(SM_THERMAL_CALIB_READ, 0x82000047),
+ CMD(SM_A1_PWRC_SET, 0x82000093),
+ CMD(SM_A1_PWRC_GET, 0x82000095),
{ /* sentinel */ },
},
};
@@ -245,6 +246,14 @@ struct meson_sm_firmware *meson_sm_get(struct device_node *sm_node)
}
EXPORT_SYMBOL_GPL(meson_sm_get);
+int meson_sm_get_thermal_calib(struct meson_sm_firmware *fw, u32 *trim_info,
+ u32 tsensor_id)
+{
+ return meson_sm_call(fw, SM_THERMAL_CALIB_READ, trim_info, tsensor_id,
+ 0, 0, 0, 0);
+}
+EXPORT_SYMBOL_GPL(meson_sm_get_thermal_calib);
+
#define SM_CHIP_ID_LENGTH 119
#define SM_CHIP_ID_OFFSET 4
#define SM_CHIP_ID_SIZE 12
--
2.49.0
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox