From: Charlie Jenkins <charlie@rivosinc.com>
To: Conor Dooley <conor@kernel.org>
Cc: linux-riscv@lists.infradead.org, linux-kernel@vger.kernel.org,
Paul Walmsley <paul.walmsley@sifive.com>,
Palmer Dabbelt <palmer@dabbelt.com>,
Albert Ou <aou@eecs.berkeley.edu>,
Jonathan Corbet <corbet@lwn.net>,
evan@rivosinc.com, heiko@sntech.de, linux-doc@vger.kernel.org
Subject: Re: [PATCH 2/3] RISC-V: Add T-Head 0.7.1 vector extension to hwprobe
Date: Thu, 6 Jul 2023 13:00:52 -0700 [thread overview]
Message-ID: <ZKcddDAbpdCtRevP@ghost> (raw)
In-Reply-To: <20230706-unwed-aeration-d8c7b71eac5e@spud>
On Thu, Jul 06, 2023 at 06:38:17PM +0100, Conor Dooley wrote:
> Hey,
>
> On Wed, Jul 05, 2023 at 08:30:18PM -0700, Charlie Jenkins wrote:
> > Using vendor extensions in hwprobe, add the ability to query if the
> > 0.7.1 vector extension is available. It is determined to be available
> > only if the kernel is compiled with vector support,
>
> > and the user is
> > using the c906.
>
> Heh, unfortunately your patch doesn't apply this limitation.
>
> I'm not really sure where this series is intended to sit in relation to
> Heiko's series that adds support for the actual T-Head vector stuff:
> https://lore.kernel.org/linux-riscv/20230622231305.631331-1-heiko@sntech.de/
>
> Is this intended to complement that? If so, these patches don't really
> seem to integrate with it (and have some of the same flaws unfortunately
> as that series does).
>
> Firstly, to my knowledge, all T-Head cpu cores report 0 for impid &
> archid. Stefan pointed out:
> C906 supports t-head/0.7.1 vectors as a configuration option. The C906 in
> the D1 and BL808 has vectors, the recently announced CV1800B has one C906
> with vectors and one without, and I vaguely remember seeing a chip with only
> a non-vector C906.
>
> C908 (announced, no manual yet) claims V 1.0 support. Presumably it will
> not support 0.7.1.
>
> C910 (exists on evaluation boards) lacks vector support.
>
> C920 (TH1520, SG2042, etc) has 0.7.1 support, at least superficially
> compatible with C906-with-vectors. Hopefully we can share errata.
>
> This probably needs to be handled as an orthogonal "xtheadv" or "v0p7p1"
> extension in whatever replaces riscv,isa.
>
> This makes an approach that does anything w/ their vector implementation
> not discernible based on the m*id CSRs. IMO, the only way to make this
> stuff work properly is to detect based on a DT or ACPI property whether
> this stuff is supported on a given core.
>
> Since the approach just cannot work, I don't have any detailed comments
> to make, just a few small ones below.
>
It would be beneficial to use Heiko's vector support patch. I can look
into using that. The main purpose of this patch is to propose a method
of vendor extension support and since T-Head has hardware I have used
their hardware as an example of how to implement vendor extensions.
That is the reason for the kind of awkward patch segmentation.
> > Signed-off-by: Charlie Jenkins <charlie@rivosinc.com>
> > ---
> > arch/riscv/Kconfig.vendor | 11 +++++++++++
> > arch/riscv/include/asm/extensions.h | 16 ++++++++++++++++
> > arch/riscv/kernel/sys_riscv.c | 20 ++++++++++++++++++++
> > arch/riscv/vendor_extensions/Makefile | 2 ++
> > arch/riscv/vendor_extensions/thead/Makefile | 8 ++++++++
> > arch/riscv/vendor_extensions/thead/extensions.c | 24 ++++++++++++++++++++++++
> > 6 files changed, 81 insertions(+)
> >
> > diff --git a/arch/riscv/Kconfig.vendor b/arch/riscv/Kconfig.vendor
> > index 213ac3e6fed5..b8b9d15153eb 100644
> > --- a/arch/riscv/Kconfig.vendor
> > +++ b/arch/riscv/Kconfig.vendor
> > @@ -1,3 +1,14 @@
> > menu "Vendor extensions selection"
> >
> > +config VENDOR_EXTENSIONS_THEAD
> > + bool "T-HEAD vendor extensions"
>
> > + depends on RISCV_ALTERNATIVE
>
> Why do you need this?
>
Thanks for pointing that out, I meant to remove that.
> > + default n
> > + help
> > + All T-HEAD vendor extensions Kconfig depend on this Kconfig. Disabling
> > + this Kconfig will disable all T-HEAD vendor extensions. Please say "Y"
> > + here if your platform uses T-HEAD vendor extensions.
>
> I don't really like this Kconfig entry. We should just use the one in
> Kconfig.errata that enables the actual vector stuff.
>
The purpose of this is to support more than just the T-Head vector
extension. The vector extension is just the vendor extension I selected
to support first. The purpose of this file is for all vendors to have
their own Kconfig entries to enable the vector extension which I didn't
feel that it properly fit into the errata.
> > +
> > + Otherwise, please say "N" here to avoid unnecessary overhead.
> > +
> > endmenu # "Vendor extensions selection"
> > diff --git a/arch/riscv/include/asm/extensions.h b/arch/riscv/include/asm/extensions.h
> > new file mode 100644
> > index 000000000000..27ce294a3d65
> > --- /dev/null
> > +++ b/arch/riscv/include/asm/extensions.h
> > @@ -0,0 +1,16 @@
> > +/* SPDX-License-Identifier: GPL-2.0-only */
> > +/*
> > + * Copyright (C) 2023 by Rivos Inc.
> > + */
> > +#ifndef __ASM_EXTENSIONS_H
> > +#define __ASM_EXTENSIONS_H
> > +
> > +#include <asm/hwprobe.h>
> > +#include <linux/cpumask.h>
> > +
> > +#define THEAD_ISA_EXT0 (RISCV_HWPROBE_VENDOR_EXTENSION_SPACE)
> > +#define THEAD_ISA_EXT0_V0_7_1 (1 << 0)
> > +
> > +int hwprobe_thead(__u64 marchid, __u64 mimpid, struct riscv_hwprobe *pair,
> > + const struct cpumask *cpus);
> > +#endif
> > diff --git a/arch/riscv/kernel/sys_riscv.c b/arch/riscv/kernel/sys_riscv.c
> > index 2351a5f7b8b1..58b12eaeaf46 100644
> > --- a/arch/riscv/kernel/sys_riscv.c
> > +++ b/arch/riscv/kernel/sys_riscv.c
> > @@ -13,6 +13,7 @@
> > #include <asm/vector.h>
> > #include <asm/switch_to.h>
> > #include <asm/uaccess.h>
> > +#include <asm/extensions.h>
> > #include <asm/unistd.h>
> > #include <asm-generic/mman-common.h>
> > #include <vdso/vsyscall.h>
> > @@ -192,6 +193,25 @@ static int hwprobe_vendor(__u64 mvendorid, struct riscv_hwprobe *pair,
> > const struct cpumask *cpus)
> > {
> > switch (mvendorid) {
> > +#ifdef CONFIG_VENDOR_EXTENSIONS_THEAD
>
> Please use IS_ENABLED() in code where possible, so that we get compile
> time coverage of the code it disables. IMO, this kinda overcomplicates
> the switch anyway, and it should be as simple as:
> case THEAD_VENDOR_ID:
> return hwprobe_thead(pair, cpus);
>
> and deal with the specific stuff (like impid etc) inside that function.
>
> > + case THEAD_VENDOR_ID:
> > + struct riscv_hwprobe marchid = {
> > + .key = RISCV_HWPROBE_KEY_MARCHID,
> > + .value = 0
> > + };
> > + struct riscv_hwprobe mimpid = {
> > + .key = RISCV_HWPROBE_KEY_MIMPID,
> > + .value = 0
> > + };
> > +
> > + hwprobe_arch_id(&marchid, cpus);
> > + hwprobe_arch_id(&mimpid, cpus);
> > + if (marchid.value != -1ULL && mimpid.value != -1ULL)
> > + hwprobe_thead(marchid.value, mimpid.value, pair, cpus);
> > + else
> > + return -1;
> > + break;
> > +#endif
> > default:
> > return -1;
> > }
> > diff --git a/arch/riscv/vendor_extensions/Makefile b/arch/riscv/vendor_extensions/Makefile
> > index e815895e9372..38c3e80469fd 100644
> > --- a/arch/riscv/vendor_extensions/Makefile
> > +++ b/arch/riscv/vendor_extensions/Makefile
> > @@ -1,3 +1,5 @@
> > ifdef CONFIG_RELOCATABLE
> > KBUILD_CFLAGS += -fno-pie
> > endif
>
> Again, why do you need this, or...
This file is properly filled out in the next patch in the series but I
wanted to break it up. I saw this in the errata Makefiles so I assumed
it would be needed here.
> > +
> > +obj-$(CONFIG_VENDOR_EXTENSIONS_THEAD) += thead/
> > diff --git a/arch/riscv/vendor_extensions/thead/Makefile b/arch/riscv/vendor_extensions/thead/Makefile
> > new file mode 100644
> > index 000000000000..7cf43c629b66
> > --- /dev/null
> > +++ b/arch/riscv/vendor_extensions/thead/Makefile
> > @@ -0,0 +1,8 @@
> > +ifdef CONFIG_FTRACE
> > +CFLAGS_REMOVE_extensions.o = $(CC_FLAGS_FTRACE)
> > +endif
> > +ifdef CONFIG_KASAN
> > +KASAN_SANITIZE_extensions.o := n
> > +endif
>
> ...any of this? Not saying you don't, but I think it should be explained.
>
Same reasoning as above, I can remove it if it's not needed.
> > +
> > +obj-y += extensions.o
> > diff --git a/arch/riscv/vendor_extensions/thead/extensions.c b/arch/riscv/vendor_extensions/thead/extensions.c
> > new file mode 100644
> > index 000000000000..a177501bc99c
> > --- /dev/null
> > +++ b/arch/riscv/vendor_extensions/thead/extensions.c
> > @@ -0,0 +1,24 @@
> > +// SPDX-License-Identifier: GPL-2.0-only
> > +/*
> > + * Copyright (C) 2023 by Rivos Inc.
> > + */
> > +
> > +#include <asm/extensions.h>
> > +
> > +int hwprobe_thead(__u64 marchid, __u64 mimpid, struct riscv_hwprobe *pair,
> > + const struct cpumask *cpus)
> > +{
> > + pair->value = 0;
> > + switch (pair->key) {
> > + case THEAD_ISA_EXT0:
> > +#ifdef CONFIG_RISCV_ISA_V
>
> As pointed out by Remi, this doesn't work either.
> You should not claim this is supported, just because V is, you also need
> the support for their vector "flavour" from Heiko's series.
>
> Plus, it should be IS_ENABLED() too.
>
> Cheers,
> Conor.
>
The thought process was that it should only matter if they care about
V. However since they are different versions of V I could see it being
better to not depend on the same config.
> > + if (marchid == 0 && mimpid == 0)
> > + pair->value |= THEAD_ISA_EXT0_V0_7_1;
> > +#endif
> > + break;
> > + default:
> > + return -1;
> > + }
> > +
> > + return 0;
> > +}
> >
> > --
> > 2.41.0
> >
WARNING: multiple messages have this Message-ID (diff)
From: Charlie Jenkins <charlie@rivosinc.com>
To: Conor Dooley <conor@kernel.org>
Cc: linux-riscv@lists.infradead.org, linux-kernel@vger.kernel.org,
Paul Walmsley <paul.walmsley@sifive.com>,
Palmer Dabbelt <palmer@dabbelt.com>,
Albert Ou <aou@eecs.berkeley.edu>,
Jonathan Corbet <corbet@lwn.net>,
evan@rivosinc.com, heiko@sntech.de, linux-doc@vger.kernel.org
Subject: Re: [PATCH 2/3] RISC-V: Add T-Head 0.7.1 vector extension to hwprobe
Date: Thu, 6 Jul 2023 13:00:52 -0700 [thread overview]
Message-ID: <ZKcddDAbpdCtRevP@ghost> (raw)
In-Reply-To: <20230706-unwed-aeration-d8c7b71eac5e@spud>
On Thu, Jul 06, 2023 at 06:38:17PM +0100, Conor Dooley wrote:
> Hey,
>
> On Wed, Jul 05, 2023 at 08:30:18PM -0700, Charlie Jenkins wrote:
> > Using vendor extensions in hwprobe, add the ability to query if the
> > 0.7.1 vector extension is available. It is determined to be available
> > only if the kernel is compiled with vector support,
>
> > and the user is
> > using the c906.
>
> Heh, unfortunately your patch doesn't apply this limitation.
>
> I'm not really sure where this series is intended to sit in relation to
> Heiko's series that adds support for the actual T-Head vector stuff:
> https://lore.kernel.org/linux-riscv/20230622231305.631331-1-heiko@sntech.de/
>
> Is this intended to complement that? If so, these patches don't really
> seem to integrate with it (and have some of the same flaws unfortunately
> as that series does).
>
> Firstly, to my knowledge, all T-Head cpu cores report 0 for impid &
> archid. Stefan pointed out:
> C906 supports t-head/0.7.1 vectors as a configuration option. The C906 in
> the D1 and BL808 has vectors, the recently announced CV1800B has one C906
> with vectors and one without, and I vaguely remember seeing a chip with only
> a non-vector C906.
>
> C908 (announced, no manual yet) claims V 1.0 support. Presumably it will
> not support 0.7.1.
>
> C910 (exists on evaluation boards) lacks vector support.
>
> C920 (TH1520, SG2042, etc) has 0.7.1 support, at least superficially
> compatible with C906-with-vectors. Hopefully we can share errata.
>
> This probably needs to be handled as an orthogonal "xtheadv" or "v0p7p1"
> extension in whatever replaces riscv,isa.
>
> This makes an approach that does anything w/ their vector implementation
> not discernible based on the m*id CSRs. IMO, the only way to make this
> stuff work properly is to detect based on a DT or ACPI property whether
> this stuff is supported on a given core.
>
> Since the approach just cannot work, I don't have any detailed comments
> to make, just a few small ones below.
>
It would be beneficial to use Heiko's vector support patch. I can look
into using that. The main purpose of this patch is to propose a method
of vendor extension support and since T-Head has hardware I have used
their hardware as an example of how to implement vendor extensions.
That is the reason for the kind of awkward patch segmentation.
> > Signed-off-by: Charlie Jenkins <charlie@rivosinc.com>
> > ---
> > arch/riscv/Kconfig.vendor | 11 +++++++++++
> > arch/riscv/include/asm/extensions.h | 16 ++++++++++++++++
> > arch/riscv/kernel/sys_riscv.c | 20 ++++++++++++++++++++
> > arch/riscv/vendor_extensions/Makefile | 2 ++
> > arch/riscv/vendor_extensions/thead/Makefile | 8 ++++++++
> > arch/riscv/vendor_extensions/thead/extensions.c | 24 ++++++++++++++++++++++++
> > 6 files changed, 81 insertions(+)
> >
> > diff --git a/arch/riscv/Kconfig.vendor b/arch/riscv/Kconfig.vendor
> > index 213ac3e6fed5..b8b9d15153eb 100644
> > --- a/arch/riscv/Kconfig.vendor
> > +++ b/arch/riscv/Kconfig.vendor
> > @@ -1,3 +1,14 @@
> > menu "Vendor extensions selection"
> >
> > +config VENDOR_EXTENSIONS_THEAD
> > + bool "T-HEAD vendor extensions"
>
> > + depends on RISCV_ALTERNATIVE
>
> Why do you need this?
>
Thanks for pointing that out, I meant to remove that.
> > + default n
> > + help
> > + All T-HEAD vendor extensions Kconfig depend on this Kconfig. Disabling
> > + this Kconfig will disable all T-HEAD vendor extensions. Please say "Y"
> > + here if your platform uses T-HEAD vendor extensions.
>
> I don't really like this Kconfig entry. We should just use the one in
> Kconfig.errata that enables the actual vector stuff.
>
The purpose of this is to support more than just the T-Head vector
extension. The vector extension is just the vendor extension I selected
to support first. The purpose of this file is for all vendors to have
their own Kconfig entries to enable the vector extension which I didn't
feel that it properly fit into the errata.
> > +
> > + Otherwise, please say "N" here to avoid unnecessary overhead.
> > +
> > endmenu # "Vendor extensions selection"
> > diff --git a/arch/riscv/include/asm/extensions.h b/arch/riscv/include/asm/extensions.h
> > new file mode 100644
> > index 000000000000..27ce294a3d65
> > --- /dev/null
> > +++ b/arch/riscv/include/asm/extensions.h
> > @@ -0,0 +1,16 @@
> > +/* SPDX-License-Identifier: GPL-2.0-only */
> > +/*
> > + * Copyright (C) 2023 by Rivos Inc.
> > + */
> > +#ifndef __ASM_EXTENSIONS_H
> > +#define __ASM_EXTENSIONS_H
> > +
> > +#include <asm/hwprobe.h>
> > +#include <linux/cpumask.h>
> > +
> > +#define THEAD_ISA_EXT0 (RISCV_HWPROBE_VENDOR_EXTENSION_SPACE)
> > +#define THEAD_ISA_EXT0_V0_7_1 (1 << 0)
> > +
> > +int hwprobe_thead(__u64 marchid, __u64 mimpid, struct riscv_hwprobe *pair,
> > + const struct cpumask *cpus);
> > +#endif
> > diff --git a/arch/riscv/kernel/sys_riscv.c b/arch/riscv/kernel/sys_riscv.c
> > index 2351a5f7b8b1..58b12eaeaf46 100644
> > --- a/arch/riscv/kernel/sys_riscv.c
> > +++ b/arch/riscv/kernel/sys_riscv.c
> > @@ -13,6 +13,7 @@
> > #include <asm/vector.h>
> > #include <asm/switch_to.h>
> > #include <asm/uaccess.h>
> > +#include <asm/extensions.h>
> > #include <asm/unistd.h>
> > #include <asm-generic/mman-common.h>
> > #include <vdso/vsyscall.h>
> > @@ -192,6 +193,25 @@ static int hwprobe_vendor(__u64 mvendorid, struct riscv_hwprobe *pair,
> > const struct cpumask *cpus)
> > {
> > switch (mvendorid) {
> > +#ifdef CONFIG_VENDOR_EXTENSIONS_THEAD
>
> Please use IS_ENABLED() in code where possible, so that we get compile
> time coverage of the code it disables. IMO, this kinda overcomplicates
> the switch anyway, and it should be as simple as:
> case THEAD_VENDOR_ID:
> return hwprobe_thead(pair, cpus);
>
> and deal with the specific stuff (like impid etc) inside that function.
>
> > + case THEAD_VENDOR_ID:
> > + struct riscv_hwprobe marchid = {
> > + .key = RISCV_HWPROBE_KEY_MARCHID,
> > + .value = 0
> > + };
> > + struct riscv_hwprobe mimpid = {
> > + .key = RISCV_HWPROBE_KEY_MIMPID,
> > + .value = 0
> > + };
> > +
> > + hwprobe_arch_id(&marchid, cpus);
> > + hwprobe_arch_id(&mimpid, cpus);
> > + if (marchid.value != -1ULL && mimpid.value != -1ULL)
> > + hwprobe_thead(marchid.value, mimpid.value, pair, cpus);
> > + else
> > + return -1;
> > + break;
> > +#endif
> > default:
> > return -1;
> > }
> > diff --git a/arch/riscv/vendor_extensions/Makefile b/arch/riscv/vendor_extensions/Makefile
> > index e815895e9372..38c3e80469fd 100644
> > --- a/arch/riscv/vendor_extensions/Makefile
> > +++ b/arch/riscv/vendor_extensions/Makefile
> > @@ -1,3 +1,5 @@
> > ifdef CONFIG_RELOCATABLE
> > KBUILD_CFLAGS += -fno-pie
> > endif
>
> Again, why do you need this, or...
This file is properly filled out in the next patch in the series but I
wanted to break it up. I saw this in the errata Makefiles so I assumed
it would be needed here.
> > +
> > +obj-$(CONFIG_VENDOR_EXTENSIONS_THEAD) += thead/
> > diff --git a/arch/riscv/vendor_extensions/thead/Makefile b/arch/riscv/vendor_extensions/thead/Makefile
> > new file mode 100644
> > index 000000000000..7cf43c629b66
> > --- /dev/null
> > +++ b/arch/riscv/vendor_extensions/thead/Makefile
> > @@ -0,0 +1,8 @@
> > +ifdef CONFIG_FTRACE
> > +CFLAGS_REMOVE_extensions.o = $(CC_FLAGS_FTRACE)
> > +endif
> > +ifdef CONFIG_KASAN
> > +KASAN_SANITIZE_extensions.o := n
> > +endif
>
> ...any of this? Not saying you don't, but I think it should be explained.
>
Same reasoning as above, I can remove it if it's not needed.
> > +
> > +obj-y += extensions.o
> > diff --git a/arch/riscv/vendor_extensions/thead/extensions.c b/arch/riscv/vendor_extensions/thead/extensions.c
> > new file mode 100644
> > index 000000000000..a177501bc99c
> > --- /dev/null
> > +++ b/arch/riscv/vendor_extensions/thead/extensions.c
> > @@ -0,0 +1,24 @@
> > +// SPDX-License-Identifier: GPL-2.0-only
> > +/*
> > + * Copyright (C) 2023 by Rivos Inc.
> > + */
> > +
> > +#include <asm/extensions.h>
> > +
> > +int hwprobe_thead(__u64 marchid, __u64 mimpid, struct riscv_hwprobe *pair,
> > + const struct cpumask *cpus)
> > +{
> > + pair->value = 0;
> > + switch (pair->key) {
> > + case THEAD_ISA_EXT0:
> > +#ifdef CONFIG_RISCV_ISA_V
>
> As pointed out by Remi, this doesn't work either.
> You should not claim this is supported, just because V is, you also need
> the support for their vector "flavour" from Heiko's series.
>
> Plus, it should be IS_ENABLED() too.
>
> Cheers,
> Conor.
>
The thought process was that it should only matter if they care about
V. However since they are different versions of V I could see it being
better to not depend on the same config.
> > + if (marchid == 0 && mimpid == 0)
> > + pair->value |= THEAD_ISA_EXT0_V0_7_1;
> > +#endif
> > + break;
> > + default:
> > + return -1;
> > + }
> > +
> > + return 0;
> > +}
> >
> > --
> > 2.41.0
> >
_______________________________________________
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-06 20:00 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-07-06 3:30 [PATCH 0/3] RISC-V: Support querying vendor extensions Charlie Jenkins
2023-07-06 3:30 ` Charlie Jenkins
2023-07-06 3:30 ` [PATCH 1/3] RISC-V: Framework for " Charlie Jenkins
2023-07-06 3:30 ` Charlie Jenkins
2023-07-06 16:29 ` Rémi Denis-Courmont
2023-07-06 16:29 ` Rémi Denis-Courmont
2023-07-06 19:44 ` Charlie Jenkins
2023-07-06 19:44 ` Charlie Jenkins
2023-07-06 20:04 ` Rémi Denis-Courmont
2023-07-06 20:04 ` Rémi Denis-Courmont
2023-07-06 17:15 ` Conor Dooley
2023-07-06 17:15 ` Conor Dooley
2023-07-06 19:51 ` Charlie Jenkins
2023-07-06 19:51 ` Charlie Jenkins
2023-07-06 20:43 ` Conor Dooley
2023-07-06 20:43 ` Conor Dooley
2023-07-06 3:30 ` [PATCH 2/3] RISC-V: Add T-Head 0.7.1 vector extension to hwprobe Charlie Jenkins
2023-07-06 3:30 ` Charlie Jenkins
2023-07-06 16:32 ` Rémi Denis-Courmont
2023-07-06 16:32 ` Rémi Denis-Courmont
2023-07-06 20:05 ` Charlie Jenkins
2023-07-06 20:05 ` Charlie Jenkins
2023-07-06 17:38 ` Conor Dooley
2023-07-06 17:38 ` Conor Dooley
2023-07-06 20:00 ` Charlie Jenkins [this message]
2023-07-06 20:00 ` Charlie Jenkins
2023-07-06 21:24 ` Conor Dooley
2023-07-06 21:24 ` Conor Dooley
2023-07-06 3:30 ` [PATCH 3/3] RISC-V: Include documentation for hwprobe vendor extensions Charlie Jenkins
2023-07-06 3:30 ` Charlie Jenkins
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=ZKcddDAbpdCtRevP@ghost \
--to=charlie@rivosinc.com \
--cc=aou@eecs.berkeley.edu \
--cc=conor@kernel.org \
--cc=corbet@lwn.net \
--cc=evan@rivosinc.com \
--cc=heiko@sntech.de \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-riscv@lists.infradead.org \
--cc=palmer@dabbelt.com \
--cc=paul.walmsley@sifive.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.