linux-kernel - Re: [PATCH] riscv: Update MIPS vendor id to 0x127.

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <b4ff764c-24d5-4187-8815-d505918e5d9f@htecgroup.com>
Date: Thu, 20 Nov 2025 10:05:36 +0000
From: Aleksa Paunovic <aleksa.paunovic@...cgroup.com>
To: "pjw@...nel.org" <pjw@...nel.org>
CC: Djordje Todorovic <Djordje.Todorovic@...cgroup.com>, Aleksa Paunovic
	<aleksa.paunovic@...cgroup.com>, "alex@...ti.fr" <alex@...ti.fr>,
	"aou@...s.berkeley.edu" <aou@...s.berkeley.edu>, "cfu@...ecomp.com"
	<cfu@...ecomp.com>, "conor.dooley@...rochip.com"
	<conor.dooley@...rochip.com>, "conor@...nel.org" <conor@...nel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-riscv@...ts.infradead.org" <linux-riscv@...ts.infradead.org>,
	"palmer@...belt.com" <palmer@...belt.com>
Subject: Re: [PATCH] riscv: Update MIPS vendor id to 0x127.

On 11/19/25 04:26, Paul Walmsley wrote:
> CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.
>
>
> On Tue, 4 Nov 2025, Aleksa Paunovic wrote:
>
>> On 11/4/25 14:18, Conor Dooley wrote:
>>
>>> On Tue, Nov 04, 2025 at 11:53:49AM +0000, Aleksa Paunovic wrote:
>>>
>>>>>> diff --git a/arch/riscv/include/asm/vendorid_list.h b/arch/riscv/include/asm/vendorid_list.h
>>>>>> index 3b09874d7a6dfb8f8aa45b0be41c20711d539e78..55205f7938055ba2b744dba5118bba935bcac008 100644
>>>>>> --- a/arch/riscv/include/asm/vendorid_list.h
>>>>>> +++ b/arch/riscv/include/asm/vendorid_list.h
>>>>>> @@ -9,6 +9,6 @@
>>>>>>  #define MICROCHIP_VENDOR_ID     0x029
>>>>>>  #define SIFIVE_VENDOR_ID        0x489
>>>>>>  #define THEAD_VENDOR_ID         0x5b7
>>>>>> -#define MIPS_VENDOR_ID          0x722
>>>>>> +#define MIPS_VENDOR_ID          0x127
>>>>> How was this ever wrong? Do devices exist with this old ID? Do we need
>>>>> to support both as vendor IDs for MIPS?
>>>> I'm not sure how it first started, but since we worked on qemu as well, we never noticed any issues while testing.
>>>> It shouldn't cause any problems in the future though.
>>> So all the hardware uses the 0x127 id? Where did 0x722 come from?
>>> I recall qemu defaults to 0x0, so were none of the mips code paths
>>> tested, or were they tested with a qemu modified to use 0x722?
>>
>> That is correct, all hardware uses the 0x127 id.
>>
>> I'm not sure where we got 0x722 from - perhaps I or someone else misread the value
>>
>> (0x27 and 0x2 are both mentioned in the Programmer's Guide mvendorid bit descriptions).
>>
>>
>> Everything was tested with qemu modified to use 0x722. Please see [1], for example.
>>
>>
>> [1] https://patchew.org/QEMU/20250717093833.402237-1-djordje.todorovic@htecgroup.com/20250717093833.402237-4-djordje.todorovic@htecgroup.com/
> Something that would really help: when you post patches, please
> describe how they were tested.  Something like "Functionality tested on
> MIPS Boston with a P8700 bitstream" or "Boot-tested on upstream QEMU
> vx.y.z" or whatever.  This should go either in the series cover letter or
> below the line in the patch description.  At least then we know if the
> testing was done on something that's likely to resemble the final
> hardware product.
>
> This goes for everyone else on the list, too, by the way.  Some people are
> really good about doing this.  For those of you who have been doing this
> already, please keep up the great work.

Hi Paul,
 
Thanks a lot for the feedback and clarifications!
 
The kernel does successfully boot on our FPGA even with an incorrect vendor ID 
(0x722 came from an older/legacy source) —
we only noticed the errata issue on the FPGA, and while debugging with printk() we identified what was wrong,
and why with qemu we have not had issues...
 
We’re currently setting up a public CI/CD infrastructure
that will automatically test against both riscv-next and pjw/riscv trees on our FPGA and QEMU. 
Once it’s live, we’ll share the public link so others can follow the results as well.
 
Best regards,
Aleksa