[PATCH v4 0/2] perf: Add Raspberry Pi AXI PMU driver

[Ian Rogers]

On Thu, Aug 13, 2026 at 9:34 AM Florian Fainelli
<florian.fainelli at broadcom.com> wrote:
>
> On 8/13/26 06:48, Ian Rogers wrote:
> > On Thu, Aug 13, 2026 at 2:08 AM Peter Robinson <pbrobinson at gmail.com> wrote:
> >>
> >> On Wed, 12 Aug 2026 at 09:28, Will Deacon <will at kernel.org> wrote:
> >>>
> >>> On Tue, Aug 11, 2026 at 10:24:15PM -0700, Ian Rogers wrote:
> >>>> This patch series adds an uncore Performance Monitoring Unit (PMU) driver
> >>>> for Broadcom AXI system and VideoCore VPU performance monitors found on
> >>>> Raspberry Pi SoCs (BCM2835 through BCM2712 / Raspberry Pi 1 through 5).
> >>>
> >>> Why are you sending four versions of this patch series, at -rc7, each in
> >>> reply to the previous one? Nobody is going to review that.
> >>
> >> I'm also wondering why this is called rpi_axi_pmu where it very much
> >> looks like Broadcom IP, and is possibly used in other Broadcom SoCs,
> >> Florian can you confirm what this driver should be called?
> >
> > I'm somewhat agnostic regarding the naming, and having a more general
> > driver strikes me as a good thing. Fwiw, I based the name on a
> > somewhat similarly named non-perf-compliant driver:
> > https://github.com/raspberrypi/linux/blob/rpi-6.18.y/drivers/perf/raspberrypi_axi_monitor.c
>
> Given this uses the Raspberry Pi firmware interface, having
> rpi/rasbperrypi in the name is sensible IMHO, but the IP is technically
> from Broadcom AFAICT, so using a bcm2835 prefix wouldn't be far off.
>
> Ian, I am really having a hard time following all of your frequent
> submissions, would you mind waiting for feedback before spinning new
> versions?

Hi Florian,

I'm very happy someone from Broadcom is engaging with my driver :-) So
on linux-perf-users the norm is to address Sashiko's feedback, and
once that is down to an effective zero for humans to come in. For the
majority of the patches what Sashiko is complaining about are races
during teardown, potential hot plugging races, etc. Note that this
driver is more advanced than ARM's main PMU driver because it supports
hot plugging, thereby not breaking the perf tool were someone to hot
plug a CPU. Anyway, between versions, things are about 98% the same
and I explain the differences in the cover letter. For the v11 patches
Sashiko has 1 medium issue left regarding hot plugging:
https://sashiko.dev/#/patchset/20260813142608.2954099-1-irogers%40google.com
This is a substantial reduction from the v1 patch that had 13 issues
with 1 being critical:
https://sashiko.dev/#/patchset/20260811083828.2057695-1-irogers%40google.com
For the v11 review, since the boot CPU and the CPU hosting the PMU are
both CPU 0 and I don't believe it is hot-pluggable, this issue doesn't
really matter. However, having a robust driver in all respects is
still desirable, and I plan to address the feedback. I need to spend
most of today not having fun at the hospital, so I can hold off fixing
this and sending out a v12. My point is that v11 and v12 would be 98%
the same but v12 would likely include an "if" statement to address
Sashiko's feedback: "Does this early return leave the PMU permanently
bound to an offline CPU if a hotplug event occurs during probe?". I
suspect your review wouldn't focus on hot plugging races, I am much
more concerned that the counter reading logic is valid.

I'm on some sick leave and this work isn't part of my job. I am trying
to finish it before someone might misconstrue my sending Raspberry Pi
patches as me thinking this is a part of my job. While the mailing
list you are coming from may experience low volume, it is much more
the norm on linux-perf-users
(https://lore.kernel.org/linux-perf-users/), where I am a significant
contributor and Linux MAINTAINERS file reviewer. I do my best to avoid
Sashiko catching issues (bisect builds, hardware testing, scrutinizing
code, Chris Mason's review prompt analysis and local Sashiko runs) but
I think with the way models are the churn is something of a feature of
the moment. I expect that when the next level of AI agents (which I'm
using to assist in writing the code) emerges, the number of versions
and churn will reduce dramatically. I don't think we should ignore
Sashiko's points, and my own time constraints mean I want to send
things out ASAP in order for there to be the best driver I can see to
on the mailing list. Suggesting a week-long reply delay is so silly
that I was amazed it was made in this thread. I can only apologize for
the distress receiving an email is causing people. Please print out my
picture and abuse it. Come to Linux Plumbers in Prague and use one of
the 3 talks I'm giving as an opportunity to throw a microphone at the
back of my head and never issue an apology (fwiw, this happened to me
while hosting a perf related mini conference at LPC in Vienna and so
the abuse isn't just verbal).

Wrt will the code be merged, etc. You can bring a horse to water but
you can't make it drink. I believe there is significant enthusiasm for
the driver:
https://www.phoronix.com/news/Raspberry-Pi-AXI-PMU-Linux
But the number 1 refurbished laptop is a MacBook M1, which one would
think is an excellent candidate to run Linux, yet its PMU driver
appears to have little maintainer effort applied to help it land:
https://lore.kernel.org/linux-perf-users/20260101-apple-cpmu-v10-0-48812c529ffc@gmail.com/
Everyone is busy and I hope to be respectful of that, but this is work
I'm giving away for free that I genuinely think will improve things.
If you want to read the patch or email tomorrow I don't mind, it is
just an email. If you hate me and want all my emails in /dev/null,
that's your choice. Maybe the patch only ever ends up in the Raspberry
Pi's flavor of Linux, that's fine with me. Maybe it is just a driver
people have to pull from an email thread like for the Apple M1. I'm
genuinely trying to be helpful while doing my best to smile at the
"you don't know how to use email" and whitespace vigilantes*. I do try
to privately escalate issues with more senior members of the Linux
community when I think the goodness of Linux for users is being
impacted, such as drivers for popular hardware being ignored. I can
only do my best, but people I work with avoid engaging with LKML and
the "reviews" so far on this patch series are a good example of why.

Thanks,
Ian

* If you are upset by whitespace, why not add it to the Chris Mason
review prompts that Sashiko builds from and automate the process (you
can see my PRs doing similar things for things like musl libc):
https://github.com/masoncl/review-prompts/tree/main/kernel

> Thanks!

> --
> Florian