Linux-RISC-V Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Paul Walmsley <pjw@kernel.org>
To: Aleksa Paunovic <aleksa.paunovic@htecgroup.com>
Cc: "conor.dooley@microchip.com" <conor.dooley@microchip.com>,
	 Djordje Todorovic <Djordje.Todorovic@htecgroup.com>,
	 "alex@ghiti.fr" <alex@ghiti.fr>,
	 "aou@eecs.berkeley.edu" <aou@eecs.berkeley.edu>,
	 "cfu@wavecomp.com" <cfu@wavecomp.com>,
	 "conor@kernel.org" <conor@kernel.org>,
	 "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	 "linux-riscv@lists.infradead.org"
	<linux-riscv@lists.infradead.org>,
	 "palmer@dabbelt.com" <palmer@dabbelt.com>,
	 "pjw@kernel.org" <pjw@kernel.org>
Subject: Re: [PATCH] riscv: Update MIPS vendor id to 0x127.
Date: Tue, 18 Nov 2025 20:26:27 -0700 (MST)	[thread overview]
Message-ID: <cfa1cbf8-da6c-3ad1-e8d8-1a11ae5619a2@kernel.org> (raw)
In-Reply-To: <bb3a2237-6dde-4231-a016-faf190f9a877@htecgroup.com>

[-- Attachment #1: Type: text/plain, Size: 2322 bytes --]

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

[-- Attachment #2: Type: text/plain, Size: 161 bytes --]

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

  parent reply	other threads:[~2025-11-19  3:26 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-11-03 15:05 [PATCH] riscv: Update MIPS vendor id to 0x127 Aleksa Paunovic via B4 Relay
2025-11-03 22:07 ` Conor Dooley
2025-11-04 11:53   ` Aleksa Paunovic
2025-11-04 13:18     ` Conor Dooley
2025-11-04 14:06       ` Aleksa Paunovic
2025-11-04 14:09         ` Conor Dooley
2025-11-13 16:07           ` Aleksa Paunovic
2025-11-19  3:26         ` Paul Walmsley [this message]
2025-11-20 10:05           ` Aleksa Paunovic

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=cfa1cbf8-da6c-3ad1-e8d8-1a11ae5619a2@kernel.org \
    --to=pjw@kernel.org \
    --cc=Djordje.Todorovic@htecgroup.com \
    --cc=aleksa.paunovic@htecgroup.com \
    --cc=alex@ghiti.fr \
    --cc=aou@eecs.berkeley.edu \
    --cc=cfu@wavecomp.com \
    --cc=conor.dooley@microchip.com \
    --cc=conor@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-riscv@lists.infradead.org \
    --cc=palmer@dabbelt.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox