[PATCH v13 0/3] perf: Add Raspberry Pi AXI PMU driver

Ian Rogers irogers at google.com
Sun Aug 16 23:57:44 PDT 2026


On Sun, Aug 16, 2026 at 11:20 PM Krzysztof Kozlowski <krzk at kernel.org> wrote:
>
> On 15/08/2026 19:27, Ian Rogers wrote:
> > Motivation & Background
> > ==============================
> > Currently, Linux lacks a standard perf-API compatible driver for the
> > Broadcom AXI performance counter blocks on Raspberry Pi platforms. Prior
> > out-of-tree vendor solutions relied on custom debugfs nodes and ad-hoc
> > kthreads, preventing integration with standard Linux perf tooling (`perf stat`,
> > `perf list`, etc.).
> >
>
> Slow down!
>
> One version per 24h in normal cycle, not 13 patchsets in two days! (and
> even rarer during the merge window)

I'm familiar with perf-tools which was set up to follow BPF's example,
both have -next repos. The -next repos merge into linux-next for
testing. I agree that cherry-picking shouldn't be done straight into a
pull request to Linus. Is there a principle against using -next and
linux-next?

13 patch sets resulted from Sashiko reviews and subsequent addressing
of those comments. Yes, Sashiko was run internally before mailing the
changes. No, waiting a week between versions (a proposal on this
thread) doesn't make sense as addressing the feedback would take 3+
months. As already mentioned, the current churn simply reflects where
we are with the tooling. I apologize; I did what I could to reduce it
and you can see in the changes per version in the cover letter that
this addresses more than just the mailing list Sashiko review. Fwiw,
if you're not familiar with Sashiko's reviews it seems you should get
it enabled for your mailing list - Linus is positive on it and it
generally improves reviews and reduces reviewer/maintainer burden.

b4 handles reply-to git send-emails with `b4 am`, each reply-to gets a
fresh message-id and that's all the tools care about. I forgot to run
get-maintainers.pl for the Documentation change, sorry. Since more
important drivers (in particular Apple M1) are currently unaddressed
in drivers/perf, I don't hold out much hope of this driver landing or
receiving maintainer attention. I sent the patches merely to help the
ecosystem and encourage vendors to interface with perf. So far the
only constructive human review feedback I've addressed is from
Florian.

Thanks,
Ian

> Best regards,
> Krzysztof



More information about the linux-rpi-kernel mailing list