-
Notifications
You must be signed in to change notification settings - Fork 262
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
RISC-V devicetree "riscv,isa" comment is no longer accurate #301
Comments
Hmm, in addition to that you're talking about the riscv,isa devicetree string, but that's not actually what get's put into /proc/cpuinfo - only the bits of it that the kernel actually supports are put in, and in an order that the kernel, rather than devicetree, decides. IIRC, we never put zicsr or zifencei into /proc/cpuinfo. |
|
Sorry for the lag here, I'll look into it. |
No worries chief.
FWIW, whether they agree or not doesn't really matter at this point, since it is in that uabi doc it is set in stone. The order does at least match some version of the RISC-V ISA spec though 😂 |
Since I wrote this issue, this has changed. We will likely start showing Zicsr and Zifencei in /proc/cpuinfo from 6.5 onwards. Similarly, there is a new syscall added for RISC-V that can be used to get cpufeatures without parsing /proc/cpuinfo. Perhaps some folk care about it: https://docs.kernel.org/riscv/hwprobe.html |
The comment about RISC-V devicetree extension order is not aligned with the URL in the comment.
This is mea culpa, because I initially got it wrong & came back and changed it.
In your comment, the order is
^rv(?:64|32)imaf?d?q?c?b?v?k?h?(?:_[hsxz](?:[a-z])+)*$
The pattern was changed to
^rv(?:64|32)imaf?d?q?c?b?k?j?p?v?h?(?:[hsxz](?:[a-z])+)?(?:_[hsxz](?:[a-z])+)*$
which is more complicated than it was before, because the first multiletter extension doesn't have to have the leading _, sigh.Per my commit message, v (vector) was also resorted slightly and p (packed-simd) & j (dynamic languages) were added.
I don't think the re-order has any impact for you as you don't look for any of v, k, h or p - but allowing people to omit the leading may impact your acquisition of zicsr and zifencei.
On that note though, "riscv,isa" can't be used to tell whether zicsr/zifencei are present in the cpu.
Unfortunately, as they used to be part of i, there's no way of telling if a devicetree containing "i" also contains zicsr/zifencei.
Sure, if they're in the "riscv,isa" string, then they are there but if they're not in the string they may still be in the hardware :)
The text was updated successfully, but these errors were encountered: