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

[Ian Rogers]

On Mon, Aug 17, 2026 at 12:54 AM Krzysztof Kozlowski <krzk at kernel.org> wrote:
>
> On 17/08/2026 09:46, Ian Rogers wrote:
> > On Mon, Aug 17, 2026 at 12:26 AM Krzysztof Kozlowski <krzk at kernel.org> wrote:
> >>
> >> On 17/08/2026 08:57, Ian Rogers wrote:
> >>> 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?
> >>
> >> How is this relevant? I don't think you read my comment.
> >
> > I think I addressed all the points in your email. The -next
> > development is relevant because it directly addresses your point about
> > not sending emails during a merge window. Except when the -next branch
> > is becoming the main branch, merging patches at will is acceptable and
> > you also benefit from the linux-next testing. Not sending patches 5
> > times a year during the two-week merge window, it is nice to think
> > that this timetable fits everybody.
>
> No, next is not relevant, because I am not even speaking about applying
> patches. I explained you the rule of one posting per 24h. Not 5!

So, when a patch series receives feedback from Sashiko indicating
issues, it's natural for the author to address those issues and assume
a human won't review further given the existing problems with the
series. For example, this series with 9 versions posted in 2 day:
https://lore.kernel.org/linux-perf-users/?q=%22perf+build%3A+Add+target+to+install+devel+packages+needed+to+build+perf%22
The author then requested human review once Sashiko was happy:
https://lore.kernel.org/linux-perf-users/anyrSMrYWJz-TpBE@x1/
Sashiko has an option to embargo/delay its review for a specified
number of hours and you can see the small number of mailing lists
using it:
https://github.com/sashiko-dev/sashiko/blob/main/sashiko.dev/email_policy.toml#L79
I sent the versions to the mailing lists suggested by
get-maintainers.pl plus RPi, the Sashiko reviews were only coming from
linux-perf-users as the others haven't set Sashiko up (their choice
but seems not desirable imo). As already shown, it is normal on
linux-perf-users to send >1 version per day, and I think this is
preferable than having mailing list people waiting for the next patch
version that fixes the already spotted issues. Waiting >24h per
version wasn't something I could do with this series, I didn't have 2
weeks to spread the emails over, so appologies for the inconvenience
receiving an email has caused you.

If you have constructive comments, particularly on the device tree,
I'm keen to incorporate them. At the moment I don't see anything
actionable and the feedback has been similar in quality to feedback
I've already chosen to stop paying attention to.

Thanks,
Ian

> Best regards,
> Krzysztof