[PATCH v2] perf/arm-cmn: Fix multi-filter encoding

[Robin Murphy]

On 16/09/2026 10:31 am, Leo Yan wrote:
> On Tue, Sep 15, 2026 at 01:24:22PM +0100, Robin Murphy wrote:
>> The current special-case for EVICT_STATE_SEL filtering effectively
>> assigns the "filter" and "filter2" controls in the opposite order from
>> how the CMN S3 r2 TRM states "Filtering is programmed in pmu_hbt_lbt_sel
>> and pmu_evict_state_sel". On reflection, not only does this seem
>> unnecessarily non-obvious to users, but it's also likely to be a problem
>> for scaling to a full multi-filter abstraction in future. There is a
>> logical order to filters based on their bitfield positions in the
>> pmu_event_sel register, which the TRM descriptions allude to, and the
>> cmn_filter_select enum already (almost) follows, so let's fix the UABI
>> to follow suit while it's still unreleased.
>>
>> Fixes: 09178f536bb9 ("perf/arm-cmn: Plumb in new filter types")
>> Signed-off-by: Robin Murphy <robin.murphy at arm.com>
> 
> It's hard to say how useful my review is, but I went through the patch
> and also asked AI to explain the rationale. It makes sense to me:
> 
> Reviewed-by: Leo Yan <leo.yan at arm.com>
> 
> Seems we could implement a generic way to navigate filters based on
> the hardware bitfield ordering, e.g. filter_next(sel) and
> filter_prev(sel). This can be deferred until we have more combined
> filters.

Yup, that's the direction this was always heading - in the (near-ish) 
future we definitely are going to have to support different events 
having overlapping combinations of multiple filters, and even more cases 
of one event having different filters per CMN model. Thus one option I 
realised I'd like to keep open, in case arrays get too clunky, is to 
encode cmn_filter_select values in a bitmap, wherein a mapping of bits 
to CMN_EVENT_FILTER*() fields could always be implied based on this 
consistent ordering.

Thanks,
Robin.