All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Myria Sarvay" <myrialsarvay@gmail.com>
Cc: linux-perf-users@vger.kernel.org, devicetree@vger.kernel.org,
	robh@kernel.org, conor+dt@kernel.org
Subject: Re: [PATCH 05/13] drivers/perf: apple_m1: Use macros for per-implementation init functions
Date: Tue, 03 Nov 2026 10:31:56 +0000	[thread overview]
Message-ID: <sashiko-outbox-195055@kernel.org> (raw)
In-Reply-To: <20261103-m3-plus-pmu-events-v1-5-a8eb6c1139fe@gmail.com>

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Low] drivers/perf: apple_m1: unused macro m2_pmu_init_pmceid aliases removed symbol
- [Low] perf: apple_m1: redundant macro aliasing and duplication in APPLE_PMU_INIT()
--

commit b798f559facbfb19db0eef028f7f7e42ebc0042c
Author: Myria Sarvay <myrialsarvay@gmail.com>

drivers/perf: apple_m1: Use macros for per-implementation init functions

This commit replaces the per-core-family PMU initialization functions in
drivers/perf/apple_m1_cpu_pmu.c with an APPLE_PMU_INIT() macro and adds
compatibility macro aliases for M2 callbacks and attribute groups.

> diff --git a/drivers/perf/apple_m1_cpu_pmu.c b/drivers/perf/apple_m1_cpu_pmu.c
> index a14864263bf1f..e7e9b51ffadcc 100644
> --- a/drivers/perf/apple_m1_cpu_pmu.c
> +++ b/drivers/perf/apple_m1_cpu_pmu.c
> @@ -653,71 +653,40 @@ static int apple_pmu_init(struct arm_pmu *cpu_pmu)
>  }
>  
>  /* Device driver gunk */
> -static int m1_pmu_ice_init(struct arm_pmu *cpu_pmu)
> -{
> -	cpu_pmu->name = "apple_icestorm_pmu";
> -	cpu_pmu->enable		  = m1_pmu_enable_event;
> -	cpu_pmu->get_event_idx	  = m1_pmu_get_event_idx;
> -	cpu_pmu->map_event	  = m1_pmu_map_event;
> -	cpu_pmu->set_event_filter = m1_pmu_set_event_filter;
> -
> -	cpu_pmu->map_pmuv3_event  = m1_pmu_map_pmuv3_event;
> -
> -	cpu_pmu->attr_groups[ARMPMU_ATTR_GROUP_EVENTS] = &m1_pmu_events_attr_group;
> -	cpu_pmu->attr_groups[ARMPMU_ATTR_GROUP_FORMATS] = &m1_pmu_format_attr_group;
> -	return apple_pmu_init(cpu_pmu);
> -}

[ ... ]

> +#define APPLE_PMU_INIT(gen, family)								\
> +static int gen ## _pmu_ ## family ## _init(struct arm_pmu *cpu_pmu)				\
> +{												\
> +	cpu_pmu->name			= "apple_" #family "_pmu";				\
> +	cpu_pmu->enable			= gen ## _pmu_enable_event;				\
> +	cpu_pmu->get_event_idx		= gen ## _pmu_get_event_idx;				\
> +	cpu_pmu->map_event		= gen ## _pmu_map_event;				\
> +	cpu_pmu->set_event_filter	= gen ## _pmu_set_event_filter;				\
> +												\
> +	cpu_pmu->map_pmuv3_event	= gen ## _pmu_map_pmuv3_event;				\
> +												\
> +	cpu_pmu->attr_groups[ARMPMU_ATTR_GROUP_EVENTS] = &gen ## _pmu_events_attr_group;	\
> +	cpu_pmu->attr_groups[ARMPMU_ATTR_GROUP_FORMATS] = &gen ## _pmu_format_attr_group;	\
> +	return apple_pmu_init(cpu_pmu);								\
> +}

[Severity: Low]
This isn't a bug, but APPLE_PMU_INIT(gen, family) expands all seven callback
and attr_groups assignments into every per-family init function (such as
m1_pmu_icestorm_init() and m1_pmu_firestorm_init()), even though core
families within the same generation only differ in cpu_pmu->name.

Because APPLE_PMU_INIT() unconditionally token-pastes gen ## _pmu_* for
every field, any generation that shares callbacks or attribute groups with
an earlier generation also requires a block of #define aliases to satisfy
token pasting (including in subsequent patches for m4 and a18).

Would it be cleaner to follow the pattern in drivers/perf/arm_pmuv3.c
(PMUV3_INIT_SIMPLE calling armv8_pmu_init), or have per-generation init
helpers called by a small per-family wrapper that only sets cpu_pmu->name,
to avoid both the #define alias blocks and the repeated per-family
assignments?

> +
> +#define m2_pmu_enable_event		m1_pmu_enable_event
> +#define m2_pmu_get_event_idx		m1_pmu_get_event_idx
> +#define m2_pmu_set_event_filter		m1_pmu_set_event_filter
> +#define m2_pmu_map_pmuv3_event		m1_pmu_map_pmuv3_event
> +#define m2_pmu_init_pmceid		m1_pmu_init_pmceid

[Severity: Low]
Is m2_pmu_init_pmceid needed here?

Earlier in the series ("drivers/perf: apple_m1: Support per-implementation
event tables"), m1_pmu_init_pmceid() was replaced by apple_pmu_init_pmceid(),
which is called directly from apple_pmu_init():

static int apple_pmu_init(struct arm_pmu *cpu_pmu)
{
	...
	apple_pmu_init_pmceid(cpu_pmu);

	bitmap_set(cpu_pmu->cntr_mask, 0, M1_PMU_NR_COUNTERS);
	return 0;
}

APPLE_PMU_INIT() does not reference gen ## _pmu_init_pmceid, so
m2_pmu_init_pmceid (and a18_pmu_init_pmceid in "drivers/perf: apple_m1: Add
Apple A18 Support") is unused and aliases a non-existent symbol. Can this
macro definition be dropped?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261103-m3-plus-pmu-events-v1-0-a8eb6c1139fe@gmail.com?part=5

  reply	other threads:[~2026-11-03 10:31 UTC|newest]

Thread overview: 41+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-11-03 10:14 [PATCH 00/13] drivers/perf: apple_m1: Add M3/M4/A18 Pro Support Myria Sarvay via B4 Relay
2026-11-03 10:14 ` Myria Sarvay
2026-11-03 10:14 ` [PATCH 01/13] dt-bindings: arm: pmu: Add Apple M3/M4/A18 Pro SoC CPU PMU compatibles Myria Sarvay via B4 Relay
2026-11-03 10:14   ` Myria Sarvay
2026-11-03 10:19   ` sashiko-bot
2026-11-03 10:14 ` [PATCH 02/13] drivers/perf: apple_m1: Remove unused variables Myria Sarvay via B4 Relay
2026-11-03 10:14   ` Myria Sarvay
2026-11-03 10:21   ` sashiko-bot
2026-11-03 10:14 ` [PATCH 03/13] drivers/perf: apple_m1: Support per-implementation event tables Myria Sarvay via B4 Relay
2026-11-03 10:14   ` Myria Sarvay
2026-11-03 10:22   ` sashiko-bot
2026-11-03 10:14 ` [PATCH 04/13] drivers/perf: apple_m1: Support per-implementation event size Myria Sarvay via B4 Relay
2026-11-03 10:14   ` Myria Sarvay
2026-11-03 10:25   ` sashiko-bot
2026-11-03 10:14 ` [PATCH 05/13] drivers/perf: apple_m1: Use macros for per-implementation init functions Myria Sarvay via B4 Relay
2026-11-03 10:14   ` Myria Sarvay
2026-11-03 10:31   ` sashiko-bot [this message]
2026-11-03 10:14 ` [PATCH 06/13] drivers/perf: apple_m1: Add Apple M3 Series Support Myria Sarvay via B4 Relay
2026-11-03 10:14   ` Myria Sarvay
2026-11-03 10:37   ` sashiko-bot
2026-11-03 10:14 ` [PATCH 07/13] drivers/perf: apple_m1: Add Apple M4 " Myria Sarvay via B4 Relay
2026-11-03 10:14   ` Myria Sarvay
2026-11-03 10:43   ` sashiko-bot
2026-11-03 10:14 ` [PATCH 08/13] drivers/perf: apple_m1: Add Apple A18 Support Myria Sarvay via B4 Relay
2026-11-03 10:14   ` Myria Sarvay
2026-11-03 10:47   ` sashiko-bot
2026-11-03 10:14 ` [PATCH 09/13] arm64: dts: apple: t603x: Add PMU Device Nodes Myria Sarvay via B4 Relay
2026-11-03 10:14   ` Myria Sarvay
2026-11-03 10:54   ` sashiko-bot
2026-11-03 10:14 ` [PATCH 10/13] arm64: dts: apple: t8122: " Myria Sarvay via B4 Relay
2026-11-03 10:14   ` Myria Sarvay
2026-11-03 11:03   ` sashiko-bot
2026-11-03 10:14 ` [PATCH 11/13] arm64: dts: apple: t604x: " Myria Sarvay via B4 Relay
2026-11-03 10:14   ` Myria Sarvay
2026-11-03 11:12   ` sashiko-bot
2026-11-03 10:14 ` [PATCH 12/13] arm64: dts: apple: t8132: " Myria Sarvay via B4 Relay
2026-11-03 10:14   ` Myria Sarvay
2026-11-03 11:14   ` sashiko-bot
2026-11-03 10:14 ` [PATCH 13/13] arm64: dts: apple: t8140: " Myria Sarvay via B4 Relay
2026-11-03 10:14   ` Myria Sarvay
2026-11-03 11:23   ` sashiko-bot

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=sashiko-outbox-195055@kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=conor+dt@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=linux-perf-users@vger.kernel.org \
    --cc=myrialsarvay@gmail.com \
    --cc=robh@kernel.org \
    --cc=sashiko-reviews@lists.linux.dev \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.