Re: [PATCH v1.1 4/7] dt-bindings: iommu: Add spacemit/t100 features

[Robin Murphy <robin.murphy@arm.com>]

On 29/01/2026 4:41 pm, Conor Dooley wrote:
> On Thu, Jan 29, 2026 at 06:43:03PM +0800, 郑律 wrote:
>>> From: "Conor Dooley"<conor@kernel.org>
>>> Date:  Thu, Jan 29, 2026, 18:08
>>> Subject:  Re: [PATCH v1.1 4/7] dt-bindings: iommu: Add spacemit/t100 features
>>> To: "Lv Zheng"<lv.zheng@spacemit.com>
>>> Cc: "Tomasz Jeznach"<tjeznach@rivosinc.com>, "Joerg Roedel"<joro@8bytes.org>, "Will Deacon"<will@kernel.org>, "Robin Murphy"<robin.murphy@arm.com>, "Rob Herring"<robh@kernel.org>, "Krzysztof Kozlowski"<krzk+dt@kernel.org>, "Conor Dooley"<conor+dt@kernel.org>, "Paul Walmsley"<pjw@kernel.org>, "Palmer Dabbelt"<palmer@dabbelt.com>, "Albert Ou"<aou@eecs.berkeley.edu>, "Alexandre Ghiti"<alex@ghiti.fr>, "Jingyu Li"<joey.li@spacemit.com>, "Zhijian Chen"<zhijian@spacemit.com>, <iommu@lists.linux.dev>, <linux-perf-users@vger.kernel.org>, <linux-riscv@lists.infradead.org>, <spacemit@lists.linux.dev>, <devicetree@vger.kernel.org>
>>> On Thu, Jan 29, 2026 at 02:09:13PM +0800, Lv Zheng wrote:
>>>> Adds device tree bindings for SpacemiT T100 specific features.
>>>>   
>>>> vendor-hpm-events: Allow vendor events to be customized in the device
>>>>                     tree.
>>>> global-filter: The feature saves silicon area by reducing filters to
>>>>                 one and use it as a global filter across all events.
>>>>                 This usually is sufficient for real applications.
>>>   
>>> Why can these not be determined from a device specific compatible?
>>
>> The specification only defines less than 10 standard event types while the
>> real silicons should have implemented many other event types based on
>> their micro-architecture. I tried to provide a common mechanism for all
>> vendor specific event types across different vendors.
> 
> Given that the variance is based on uarch, it sounds like it can be
> determined from the compatible.
> 
>> It is similar for the global filter, the global filter mechanism actually
>> complies to the IOMMU specification, users can alter the iohpmevt
>> registers as is what is specified in the IOMMU specification. It only
>> provides slight application difference between the final effection. Thus
>> this could also be a non-device specific option.
> 
> What is a "user" in this context? Given you're talking about reducing
> silicon area, it sounds like this will be set in stone for each SoC, and
> therefore can be determined by compatible. If other devices do this,
> they can also determine it from their compatible.
> 
> Properties for things that can be determined based on compatible are
> generally not permitted, so you'll need to provide a compelling
> rationale. Common mechanism isn't one, since determining based on
> compatible would be a common mechanism based on match data that people
> can tack onto for their devices.

Also, reinventing jevents via devicetree is pretty grim anyway - the PMU 
can simply expose an "identifier" attribute that uniquely identifies the 
vendor implementation, and perf tooling can match that to a set of event 
definitions in userspace, with the added bonus that jevents can also 
encode meaningful descriptions, metrics and suchlike. There doesn't 
*need* to be a sysfs alias for every possible event. I see the RISC-V 
CPU PMUs are already on-board with this approach - note the 
"Unit"/"Compat" matching for system/uncore PMUs is a little different 
from the mapfile used for CPUs, but see other architectures for examples.

Thanks,
Robin.