[PATCH v4 0/2] perf: Add Raspberry Pi AXI PMU driver
Ian Rogers
irogers at google.com
Thu Aug 13 06:44:48 PDT 2026
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.
"""
That discusses pinging or resending the same patch version. It also
lacks language around AI reviews where a response in less than an hour
is now the norm, but anyway. Spending 3 months on this series would be
ridiculous.
> > The changes are sent in reply to each other because the entire series
> > is visible in one mailbox (b4 mbox), which I find easier to work with
> > and provides me better context. Others use semcode to do something
> > similar, but I've not explored that.
>
> Unfortunately, this tends to confuse b4 when applying the patches and
> makes it really hard to manage on the maintainers' side. I think this
> is also documented in Documentation/process/submitting-patches.rst so
> please do what everybody else does.
I work with b4 without issue using this approach.
> > Let me know if I should drop you from the cc, I placed you there as
> > Mark and you were the only suggested reviewers from
> > scripts/get_maintainer.pl but I don't want to spam uninterested
> > people.
>
> It depends if you want the patches merged...
>
> For now, I'm ctrl+d'ing the thread.
Tbh, this seems to be a theme so I'm not surprised. I guess thank you
for noticing I sent a patch.
Ian
> Will
More information about the linux-arm-kernel
mailing list