You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
A SoC vendor buys a CPU IP from another CPU IP vendor with some modification to CPU RTL and then fills marchid with itself mvendorid
A SoC vendor uses multiple CPU IPs from different vendors for their SoC and customizes the CPU IP to have the same vendor extension, which multiple CPU IPs have different mvendorid
So we might need to make the __riscv_vendor_feature_bits not guarded by mvendorid. Since this hasn't been specified in the c-api-doc currently, it's not too late to make this change.
The text was updated successfully, but these errors were encountered:
cyyself
changed the title
[FMV] Expilicit allows different vendor share the bit defination of __riscv_vendor_feature_bits
[FMV] Explicit allows different vendor share the bit definition of __riscv_vendor_feature_bits
Nov 14, 2024
cyyself
changed the title
[FMV] Explicit allows different vendor share the bit definition of __riscv_vendor_feature_bits
[FMV] Explicit allows different vendors share the bit definition of __riscv_vendor_feature_bits
Nov 14, 2024
In PR #74, we design vendor extension is guarded by vendorID. However, here we missed some cases like:
These cases are discussed from Linux Kernel mailing list on hwprobe support for T-HEAD vendor extensions thread. I think their concerns are right.
So we might need to make the
__riscv_vendor_feature_bits
not guarded bymvendorid
. Since this hasn't been specified in the c-api-doc currently, it's not too late to make this change.The text was updated successfully, but these errors were encountered: