kernel/linux.git/drivers/perf/arm-cmn.c, branch v7.1

perf/arm-cmn: Fix resource_size_t printk specifier in arm_cmn_init_dtc()

2026-03-26T15:25:21+00:00

When building for 32-bit ARM, there is a warning when using the %llx specifier to print a resource_size_t variable: drivers/perf/arm-cmn.c: In function 'arm_cmn_init_dtc': drivers/perf/arm-cmn.c:2149:73: error: format '%llx' expects argument of type 'long long unsigned int', but argument 4 has type 'resource_size_t' {aka 'unsigned int'} [-Werror=format=] 2149 | "Failed to request DTC region 0x%llx\n", base); | ~~~^ ~~~~ | | | | | resource_size_t {aka unsigned int} | long long unsigned int | %x Use the %pa specifier to handle the possible sizes of phys_addr_t properly. This requires passing the variable by reference. Fixes: 5394396ff548 ("perf/arm-cmn: Stop claiming entire iomem region") Signed-off-by: Nathan Chancellor Reviewed-by: Robin murphy Signed-off-by: Will Deacon

perf/arm-cmn: Fix incorrect error check for devm_ioremap()

2026-03-26T15:23:38+00:00

Check devm_ioremap() return value for NULL instead of ERR_PTR and return -ENOMEM on failure. devm_ioremap() never returns ERR_PTR, using IS_ERR() skips the error path and may cause a NULL pointer dereference. Fixes: 5394396ff548 ("perf/arm-cmn: Stop claiming entire iomem region") Signed-off-by: Chen Ni Signed-off-by: Will Deacon

perf/arm-cmn: Stop claiming entire iomem region

2026-03-24T12:34:38+00:00

So far, the PMU has been the only thing of interest in the vast mass of CMN registers, so we've gotten away with simply claiming the entire iomem region. However, now that we can support other features like MPAM controllers for the system caches, the PMU driver needs to stop being selfish and learn to share. Similarly to arm-ni, requesting just the DTC node(s) should suffice for staking our exclusive claim to the PMU features, as requesting hundreds of tiny regions for all the individual pmu_event_sel registers is definitely not worth the considerable bother. As a consequence, we can also streamline the annoying CMN-600 special cases even more. The ACPI binding has in fact always specified a strict order for all resources, so we can reasonably drop the ancient pretence of swapping base and cfg, which IIRC was more just a moment of doubt on my part than anything else. Cc: James Morse Signed-off-by: Robin Murphy Tested-by: Ben Horgan Reviewed-by: Ilkka Koskinen Signed-off-by: Will Deacon

Convert 'alloc_obj' family to use the new default GFP_KERNEL argument

2026-02-22T01:09:51+00:00

This was done entirely with mindless brute force, using git grep -l '\

treewide: Replace kmalloc with kmalloc_obj for non-scalar types

2026-02-21T09:02:28+00:00

This is the result of running the Coccinelle script from scripts/coccinelle/api/kmalloc_objs.cocci. The script is designed to avoid scalar types (which need careful case-by-case checking), and instead replace kmalloc-family calls that allocate struct or union object instances: Single allocations: kmalloc(sizeof(TYPE), ...) are replaced with: kmalloc_obj(TYPE, ...) Array allocations: kmalloc_array(COUNT, sizeof(TYPE), ...) are replaced with: kmalloc_objs(TYPE, COUNT, ...) Flex array allocations: kmalloc(struct_size(PTR, FAM, COUNT), ...) are replaced with: kmalloc_flex(*PTR, FAM, COUNT, ...) (where TYPE may also be *VAR) The resulting allocations no longer return "void *", instead returning "TYPE *". Signed-off-by: Kees Cook

perf/arm-cmn: Reject unsupported hardware configurations

2026-02-03T19:43:52+00:00

So far we've been fairly lax about accepting both unknown CMN models (at least with a warning), and unknown revisions of those which we do know, as although things do frequently change between releases, typically enough remains the same to be somewhat useful for at least some basic bringup checks. However, we also make assumptions of the maximum supported sizes and numbers of things in various places, and there's no guarantee that something new might not be bigger and lead to nasty array overflows. Make sure we only try to run on things that actually match our assumptions and so will not risk memory corruption. We have at least always failed on completely unknown node types, so update that error message for clarity and consistency too. Cc: stable@vger.kernel.org Fixes: 7819e05a0dce ("perf/arm-cmn: Revamp model detection") Reviewed-by: Ilkka Koskinen Signed-off-by: Robin Murphy Signed-off-by: Will Deacon

perf/arm-cmn: Support CMN-600AE

2026-01-05T16:49:00+00:00

The functional safety features of CMN-600AE have little to no impact on the PMU relative to the base CMN-600 design, so for simplicity we can reasonably just treat it as the same thing. The only obvious difference is that the revision numbers aren't aligned, so we may hide some aliases for events which do actually exist, but those can still be specified via the underlying "type,eventid" format so it's not too big a deal. Signed-off-by: Robin Murphy Reviewed-by: Ilkka Koskinen Tested-by: Michal Simek Signed-off-by: Will Deacon

perf/arm-cmn: Fix CMN S3 DTM offset

2025-09-18T19:18:24+00:00

CMN S3's DTM offset is different between r0px and r1p0, and it turns out this was not a error in the earlier documentation, but does actually exist in the design. Lovely. Cc: stable@vger.kernel.org Fixes: 0dc2f4963f7e ("perf/arm-cmn: Support CMN S3") Signed-off-by: Robin Murphy Signed-off-by: Will Deacon

perf/arm: Add missing .suppress_bind_attrs

2025-07-04T17:07:26+00:00

PMU drivers should set .suppress_bind_attrs so that userspace is denied the opportunity to pull the driver out from underneath an in-use PMU (with predictably unpleasant consequences). Somehow both the CMN and NI drivers have managed to miss this; put that right. Signed-off-by: Robin Murphy Reviewed-by: Leo Yan Link: https://lore.kernel.org/r/acd48c341b33b96804a3969ee00b355d40c546e2.1751465293.git.robin.murphy@arm.com Signed-off-by: Will Deacon

perf/arm-cmn: Reduce stack usage during discovery

2025-07-04T17:06:55+00:00

Arnd reports that Clang's aggressive inlining of arm_cmn_discover() can lead to stack frame size warnings, and while we could simply prevent such inlining to hide the issue, it seems more productive to actually heed the warning and do something about the overall stack footprint. The xp_region array is already rather large, and CMN_MAX_XPS might only grow larger in future, however it only serves as a convenience to save repeating the first level's worth of register reads in the second pass of discovery. There's no performance concern here, and it only takes a small tweak to the flow to re-extract the offsets instead of stashing them, so let's just do that and save several hundred bytes of stack. Reported-by: Arnd Bergmann Signed-off-by: Robin Murphy Reviewed-and-tested-by: Ilkka Koskinen Link: https://lore.kernel.org/r/e7dd41bf0f1b098e2e4b01ef91318a4b272abff8.1751046159.git.robin.murphy@arm.com Signed-off-by: Will Deacon