[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <995e093f-7b6c-4701-87af-2f4d21b08ada@arm.com>
Date: Fri, 15 Aug 2025 13:59:37 +0100
From: Robin Murphy <robin.murphy@....com>
To: Koichi Okuno <fj2767dz@...itsu.com>, Will Deacon <will@...nel.org>,
Mark Rutland <mark.rutland@....com>, Jonathan Corbet <corbet@....net>,
Catalin Marinas <catalin.marinas@....com>,
Gowthami Thiagarajan <gthiagarajan@...vell.com>,
Linu Cherian <lcherian@...vell.com>, linux-arm-kernel@...ts.infradead.org,
Bjorn Andersson <quic_bjorande@...cinc.com>,
Geert Uytterhoeven <geert+renesas@...der.be>,
Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>,
Konrad Dybcio <konradybcio@...nel.org>,
Neil Armstrong <neil.armstrong@...aro.org>, Arnd Bergmann <arnd@...db.de>,
NĂcolas F. R. A. Prado <nfraprado@...labora.com>,
Thomas Gleixner <tglx@...utronix.de>, Peter Zijlstra <peterz@...radead.org>,
Jonathan Cameron <Jonathan.Cameron@...wei.com>, linux-doc@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH v7 2/2] perf: Fujitsu: Add the Uncore PCI PMU driver
On 2025-08-15 4:47 am, Koichi Okuno wrote:
> This adds a new dynamic PMU to the Perf Events framework to program and
> control the Uncore PCI PMUs in Fujitsu chips.
>
> This driver was created with reference to drivers/perf/qcom_l3_pmu.c.
>
> This driver exports formatting and event information to sysfs so it can
> be used by the perf user space tools with the syntaxes:
>
> perf stat -e pci_iod0_pci0/ea-pci/ ls
> perf stat -e pci_iod0_pci0/event=0x80/ ls
>
> FUJITSU-MONAKA PMU Events Specification v1.1 URL:
> https://github.com/fujitsu/FUJITSU-MONAKA
>
> Signed-off-by: Koichi Okuno <fj2767dz@...itsu.com>
> ---
> .../admin-guide/perf/fujitsu_pci_pmu.rst | 50 ++
> Documentation/admin-guide/perf/index.rst | 1 +
> drivers/perf/Kconfig | 9 +
> drivers/perf/Makefile | 1 +
> drivers/perf/fujitsu_pci_pmu.c | 536 ++++++++++++++++++
From a quick side-by-side skim, this is a copy-paste of the exact same
driver from patch #1 with s/mac/pci/g applied. Please don't do that. If
the hardware is functionally the same, then it should just be a single
driver that can then pick which PMU name and set of event alias
attributes to use for a given instance based on the ACPI HID match
(and/or any other ID register info you may have.)
Thanks,
Robin.
Powered by blists - more mailing lists