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

[Krzysztof Kozlowski]

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!

Best regards,
Krzysztof