From: Conor Dooley <conor@kernel.org>
To: Jisheng Zhang <jszhang@kernel.org>
Cc: Palmer Dabbelt <palmer@rivosinc.com>,
guoren@kernel.org, Heiko Stuebner <heiko@sntech.de>,
Charlie Jenkins <charlie@rivosinc.com>,
Conor Dooley <conor.dooley@microchip.com>,
linux-riscv@lists.infradead.org
Subject: Re: [PATCH v2] RISC-V: Don't trust V from the riscv,isa DT property on T-Head CPUs
Date: Thu, 13 Jul 2023 18:36:56 +0100 [thread overview]
Message-ID: <20230713-mushiness-runt-0797dbb761e8@spud> (raw)
In-Reply-To: <ZLAwgLNyTiK7jbwM@xhacker>
[-- Attachment #1.1: Type: text/plain, Size: 3010 bytes --]
On Fri, Jul 14, 2023 at 01:12:32AM +0800, Jisheng Zhang wrote:
> On Thu, Jul 13, 2023 at 06:04:22PM +0100, Conor Dooley wrote:
> > Jumping on top of Palmer's reply cos I had already started replying...
> > On Thu, Jul 13, 2023 at 09:56:34AM -0700, Palmer Dabbelt wrote:
> > > On Thu, 13 Jul 2023 09:36:49 PDT (-0700), jszhang@kernel.org wrote:
> > > > On Wed, Jul 12, 2023 at 06:48:02PM +0100, Conor Dooley wrote:
> > > > FWICT, new T-HEAD's riscv cores such as C908 support standard RVV-1.0,
> > > > this patch looks like a big hammer for T-HEAD. I do understand why
> > >
> > > Ya, it's a big hammer. There's no extant systems with the C908, though, and
> > > given that the C906 and C910 alias marchid/mimplid it's kind of hard to
> > > trust any of those values for T-Head systems. We could check for the 0s and
> > > hope T-Head starts setting something else, but I'm not sure that's a net win
> > > (we've also got the C920 in the Sophgo chip, which IIUC is V-0.7.1 too).
> >
> > (In reply to Jisheng mostly)
> > It is most definitely a big hammer. And yes, we did talk about the c908
> > & its standard implementation of vector before submitting this. Unless
> > Guo can confirm that the c908 (and later CPU cores) will start setting
> > mimpid & mvendorid, I don't really see what the alternatives are? *
>
> In mainline kernel, three SoCs which powered by T-HEAD cpu are
> supported: D1, D1s and TH1520, they don't contain the "v" in riscv,isa
> dt property.
Yup, and they will stay that way ;)
> > Whacking in a list of DT compatibles to blacklist? That doesn't seem
> > like something that would scale.
> > Open to ideas on that front for sure, smaller hammers are always better!
> >
> > @Palmer, from what I am told, the c920 does put zeros in those CSRs,
> > so we are okay on that front.
> >
> > * If they do do something other than 0s, the errata handling will need
> > an update anyway, so the big hammer could be revised in tandem...
> >
> > > > this patch is provided, but can we mitigate the situation by carefully
> > > > review the DTs? Per my understanding, dts is also part of linux kernel.
> > >
> > > That would break compatibility with existing firmware. It's certainly
> > > something that has happened before, but we try to avoid it where possible.
> >
> > (Mostly in reply to Jisheng again)
> > Sure, some devicetrees are part of the kernel, but not all are - they may
> > be passed up from U-Boot or OpenSBI etc & contain "v" in riscv,isa.
>
> If so this looks like a bug of u-boot and opensbi.
>
> PS: does u-boot/opensbi modify "riscv,isa" property dynamically? Or
> there's below usage case:
> mainline linux kernel + dtb which is built from u-boot/opensbi source
> code rather than linux kernel.
Its the latter I am thinking of. If someone wants to go and double check
that there are no vendors shipping T-Head cores with firmware that
behaves that way, then the patch could I suppose be dropped.
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
[-- 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
next prev parent reply other threads:[~2023-07-13 17:37 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-07-12 17:48 [PATCH v2] RISC-V: Don't trust V from the riscv,isa DT property on T-Head CPUs Conor Dooley
2023-07-13 16:36 ` Jisheng Zhang
2023-07-13 16:56 ` Palmer Dabbelt
2023-07-13 17:04 ` Conor Dooley
2023-07-13 17:12 ` Jisheng Zhang
2023-07-13 17:36 ` Conor Dooley [this message]
2023-07-13 18:20 ` Conor Dooley
2023-07-13 17:33 ` Guo Ren
2023-07-13 17:43 ` Palmer Dabbelt
2023-07-14 6:07 ` Guo Ren
2023-07-13 17:45 ` Conor Dooley
2023-07-14 6:14 ` Guo Ren
2023-07-14 11:10 ` Conor Dooley
2023-07-14 18:45 ` Conor Dooley
2023-07-15 6:11 ` Guo Ren
2023-07-15 6:07 ` Guo Ren
2023-07-13 18:47 ` Rémi Denis-Courmont
2023-07-13 18:50 ` Rémi Denis-Courmont
2023-07-14 19:21 ` Conor Dooley
2023-07-15 6:12 ` Guo Ren
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=20230713-mushiness-runt-0797dbb761e8@spud \
--to=conor@kernel.org \
--cc=charlie@rivosinc.com \
--cc=conor.dooley@microchip.com \
--cc=guoren@kernel.org \
--cc=heiko@sntech.de \
--cc=jszhang@kernel.org \
--cc=linux-riscv@lists.infradead.org \
--cc=palmer@rivosinc.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