[PATCH v4 0/7] iommu/riscv: Add HPM support for RISC-V IOMMU

[Lv Zheng]

On 2/6/2026 6:46 PM, Krzysztof Kozlowski wrote:
> On 05/02/2026 10:09, Lv Zheng wrote:
>> Includes HPM support for RISC-V IOMMU. The HPM hardware mechanism can be
>> found in the recent announced SpacemiT SoCs (K3, V100), where T100
>> (SpacemiT distributed IOMMU) is shipped.
>>
>> Revisions:
>> v1
>>   Initial release.
>> v2 (sent as v1.1)
>>   Split and cleanup DT-bindings.
>> v3
>>   1. Refactor using vendor specific compatible.
>>   2. Implement vendor events with a userspace identifier.
>> v4
> 
> And now also v4 is in the same thread? This is total mess!
> 
> How tools are supposed to handle this?

I'm using the tools I was using several years ago.

It's able to handle revisions using one single thread if a "msgid" is
provided via its command line:

# Prepare --in-reply-to argument of git-format-patch
if [ "x$1" != "x" -a "x$1" != "xnone" ]; then
         echo "Found Message-Id: <$msgid>."
         GFPFLAGS="$GFPFLAGS --in-reply-to=$msgid"
fi

And I have a configuration file in my $HOME collecting all patchsets'
first msgid:

         if [ "x$require_msgid" = "xno" ]; then
                 fatal "Invalid Message-Id: $1 shouldn't be specified 
for v${MAJOR}.${MINOR}."
         fi
         msgid=`cat $MSGIDS | grep $1 | cut -f2`
         if [ "x$msgid" = "x" ]; then
                 fatal "Invalid Message-Id: cannot find $1 in $MSGIDS."
         fi

That's the old fashion I was doing upstream related work, as some online
tools was able to update patchsets automatically if the thread top
matched and then showed the new revision up in their web portal.

Will stop using such single thread style as what you suggested.

Thanks,
Lv

> 
> Best regards,
> Krzysztof
>