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

[Uwe Kleine-König]

On Thu, Aug 13, 2026 at 06:44:48AM -0700, Ian Rogers wrote:
> On Thu, Aug 13, 2026 at 1:41 AM Will Deacon <will at kernel.org> wrote:
> >
> > On Wed, Aug 12, 2026 at 06:38:24AM -0700, Ian Rogers wrote:
> > > On Wed, Aug 12, 2026 at 1:27 AM 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.
> > >
> > > See the cover letter for changes. They address the sashiko reviews,
> > > you may not see these reviews as they are only sent to me and
> > > linux-perf-users, which is somewhat customary in the sashiko setup.
> >
> > Have you considered running Sashiko locally given that you work at Google?
> 
> Yes I do. If you look at the changes you will notice that more issues
> are being resolved per version than the issues raised by Sashiko.
> Unfortunately, factors like the model, context window and just the
> inherent non-determinism of AI mean that AI reviews generate a
> firehose of suggestions that you can't reproduce either remotely or
> locally.
> 
> > > I don't see any relevance in rc7, I'm just mailing out a new driver
> > > now that I have the opportunity to look at it. Whether and when it
> > > gets pulled upstream is up to a maintainer.
> >
> > Right, as the maintainer for drivers/perf/ and I'm just asking you to
> > slow down a bit. I don't need 10 versions of a patch series in two days
> > when I'm focussed almost entirely on the upcoming merge window, which
> > this is too late for. You should read
> > Documentation/process/submitting-patches.rst which states:
> >
> >   | Wait for a minimum of one week before resubmitting
> 
> That's not what it says:
> https://www.kernel.org/doc/Documentation/process/submitting-patches.rst
> """
> Once upon a time, patches used to disappear into the void without comment,
> but the development process works more smoothly than that now.  You should
> receive comments within a few weeks (typically 2-3); if that does not
> happen, make sure that you have sent your patches to the right place.
> Wait for a minimum of one week before resubmitting or pinging reviewers
> - possibly longer during busy times like merge windows.
> """

I didn't care enough to check if respining a series more than once a
week is explicitly mentioned, but let me interpret the paragraph for
you:

Maintainers are busy people. Patch submitters who increase their inbox
size considerably without adding much value easily annoy them (and I can
read Will's annoyance between his lines). A maintainer being annoyed by
you isn't a good situation to get your patches merged, so better
consider to follow their advice. Once you made it to a procmail rule
that routes all your mail to /dev/null, it's hard to recover.

Are you aware that it's Will who judges your perf patches in the end and
picks them up for mainline inclusion (or doesn't)?

So yes, the documentation about sending patch revisions might be
incomplete, but if you're asked to slow down, practise some patience and
do slow down.

Also if Sashiko still finds relevant issues after 9 iterations, it might
be better to seek internal human(!) feedback by experienced people in
your company first. I recommend you to reach out to them, before they
reach out to you about annoying upstream folks and thus damaging your
reputation and Google's with it.

Best regards
Uwe
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20260813/03e872ea/attachment-0001.sig>