[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <cfa1cbf8-da6c-3ad1-e8d8-1a11ae5619a2@kernel.org>
Date: Tue, 18 Nov 2025 20:26:27 -0700 (MST)
From: Paul Walmsley <pjw@...nel.org>
To: Aleksa Paunovic <aleksa.paunovic@...cgroup.com>
cc: "conor.dooley@...rochip.com" <conor.dooley@...rochip.com>,
Djordje Todorovic <Djordje.Todorovic@...cgroup.com>,
"alex@...ti.fr" <alex@...ti.fr>,
"aou@...s.berkeley.edu" <aou@...s.berkeley.edu>,
"cfu@...ecomp.com" <cfu@...ecomp.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>,
"pjw@...nel.org" <pjw@...nel.org>
Subject: Re: [PATCH] riscv: Update MIPS vendor id to 0x127.
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.
- Paul
Powered by blists - more mailing lists