From: Stafford Horne <shorne@gmail.com>
To: Segher Boessenkool <segher@kernel.crashing.org>
Cc: Rob Herring <robh@kernel.org>, Rich Felker <dalias@libc.org>,
"Rafael J. Wysocki" <rafael@kernel.org>,
linux-kernel@vger.kernel.org, Guo Ren <guoren@kernel.org>,
"H. Peter Anvin" <hpa@zytor.com>,
linux-riscv@lists.infradead.org, Will Deacon <will@kernel.org>,
Jonas Bonn <jonas@southpole.se>,
Florian Fainelli <f.fainelli@gmail.com>,
Yoshinori Sato <ysato@users.osdn.me>,
linux-sh@vger.kernel.org, x86@kernel.org,
Russell King <linux@armlinux.org.uk>,
linux-csky@vger.kernel.org, Ingo Molnar <mingo@redhat.com>,
bcm-kernel-feedback-list@broadcom.com,
Catalin Marinas <catalin.marinas@arm.com>,
Palmer Dabbelt <palmer@dabbelt.com>,
devicetree@vger.kernel.org, Albert Ou <aou@eecs.berkeley.edu>,
Ray Jui <rjui@broadcom.com>,
Stefan Kristiansson <stefan.kristiansson@saunalahti.fi>,
openrisc@lists.librecores.org, Borislav Petkov <bp@alien8.de>,
Paul Walmsley <paul.walmsley@sifive.com>,
Thomas Gleixner <tglx@linutronix.de>,
linux-arm-kernel@lists.infradead.org,
Scott Branden <sbranden@broadcom.com>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Frank Rowand <frowand.list@gmail.com>,
James Morse <james.morse@arm.com>,
Paul Mackerras <paulus@samba.org>,
linuxppc-dev@lists.ozlabs.org
Subject: Re: [PATCH 06/12] openrisc: Use of_get_cpu_hwid()
Date: Thu, 7 Oct 2021 07:37:39 +0900 [thread overview]
Message-ID: <YV4lM/YJ4V4EAlZb@antec> (raw)
In-Reply-To: <20211006212728.GM10333@gate.crashing.org>
Hi Segher,
On Wed, Oct 06, 2021 at 04:27:28PM -0500, Segher Boessenkool wrote:
> On Thu, Oct 07, 2021 at 05:44:00AM +0900, Stafford Horne wrote:
> > You have defined of_get_cpu_hwid to return u64, will this create compiler
> > warnings when since we are storing a u64 into a u32?
> >
> > It seems only if we make with W=3.
>
> Yes. This is done by -Wconversion, "Warn for implicit conversions that
> may alter a value."
Yeah, that is what I found out when I looked into it.
> > I thought we usually warned on this.
>
> This warning is not in -Wall or -Wextra either, it suffers too much from
> false positives. It is very natural to just ignore the high bits of
> modulo types (which is what "unsigned" types *are*). Or the bits that
> "fall off" on a conversion. The C standard makes this required
> behaviour, it is useful, and it is the only convenient way of getting
> this!
Thanks for the background, It does make sense. I guess I was confused with java
which requires casting when you store to a smaller size. I.e.
Test.java:5: error: incompatible types: possible lossy conversion from int to short
s = i;
-Stafford
WARNING: multiple messages have this Message-ID (diff)
From: Stafford Horne <shorne@gmail.com>
To: Segher Boessenkool <segher@kernel.crashing.org>
Cc: Rob Herring <robh@kernel.org>, Rich Felker <dalias@libc.org>,
"Rafael J. Wysocki" <rafael@kernel.org>,
linux-kernel@vger.kernel.org, Guo Ren <guoren@kernel.org>,
"H. Peter Anvin" <hpa@zytor.com>,
linux-riscv@lists.infradead.org, Will Deacon <will@kernel.org>,
Jonas Bonn <jonas@southpole.se>,
Florian Fainelli <f.fainelli@gmail.com>,
Yoshinori Sato <ysato@users.osdn.me>,
linux-sh@vger.kernel.org, x86@kernel.org,
Russell King <linux@armlinux.org.uk>,
linux-csky@vger.kernel.org, Ingo Molnar <mingo@redhat.com>,
bcm-kernel-feedback-list@broadcom.com,
Catalin Marinas <catalin.marinas@arm.com>,
Palmer Dabbelt <palmer@dabbelt.com>,
devicetree@vger.kernel.org, Albert Ou <aou@eecs.berkeley.edu>,
Ray Jui <rjui@broadcom.com>,
Stefan Kristiansson <stefan.kristiansson@saunalahti.fi>,
openrisc@lists.librecores.org, Borislav Petkov <bp@alien8.de>,
Paul Walmsley <paul.walmsley@sifive.com>,
Thomas Gleixner <tglx@linutronix.de>,
linux-arm-kernel@lists.infradead.org,
Scott Branden <sbranden@broadcom.com>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Frank Rowand <frowand.list@gmail.com>,
James Morse <james.morse@arm.com>,
Paul Mackerras <paulus@samba.org>,
linuxppc-dev@lists.ozlabs.org
Subject: Re: [PATCH 06/12] openrisc: Use of_get_cpu_hwid()
Date: Thu, 7 Oct 2021 07:37:39 +0900 [thread overview]
Message-ID: <YV4lM/YJ4V4EAlZb@antec> (raw)
In-Reply-To: <20211006212728.GM10333@gate.crashing.org>
Hi Segher,
On Wed, Oct 06, 2021 at 04:27:28PM -0500, Segher Boessenkool wrote:
> On Thu, Oct 07, 2021 at 05:44:00AM +0900, Stafford Horne wrote:
> > You have defined of_get_cpu_hwid to return u64, will this create compiler
> > warnings when since we are storing a u64 into a u32?
> >
> > It seems only if we make with W=3.
>
> Yes. This is done by -Wconversion, "Warn for implicit conversions that
> may alter a value."
Yeah, that is what I found out when I looked into it.
> > I thought we usually warned on this.
>
> This warning is not in -Wall or -Wextra either, it suffers too much from
> false positives. It is very natural to just ignore the high bits of
> modulo types (which is what "unsigned" types *are*). Or the bits that
> "fall off" on a conversion. The C standard makes this required
> behaviour, it is useful, and it is the only convenient way of getting
> this!
Thanks for the background, It does make sense. I guess I was confused with java
which requires casting when you store to a smaller size. I.e.
Test.java:5: error: incompatible types: possible lossy conversion from int to short
s = i;
-Stafford
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
WARNING: multiple messages have this Message-ID (diff)
From: Stafford Horne <shorne@gmail.com>
To: openrisc@lists.librecores.org
Subject: [OpenRISC] [PATCH 06/12] openrisc: Use of_get_cpu_hwid()
Date: Thu, 7 Oct 2021 07:37:39 +0900 [thread overview]
Message-ID: <YV4lM/YJ4V4EAlZb@antec> (raw)
In-Reply-To: <20211006212728.GM10333@gate.crashing.org>
Hi Segher,
On Wed, Oct 06, 2021 at 04:27:28PM -0500, Segher Boessenkool wrote:
> On Thu, Oct 07, 2021 at 05:44:00AM +0900, Stafford Horne wrote:
> > You have defined of_get_cpu_hwid to return u64, will this create compiler
> > warnings when since we are storing a u64 into a u32?
> >
> > It seems only if we make with W=3.
>
> Yes. This is done by -Wconversion, "Warn for implicit conversions that
> may alter a value."
Yeah, that is what I found out when I looked into it.
> > I thought we usually warned on this.
>
> This warning is not in -Wall or -Wextra either, it suffers too much from
> false positives. It is very natural to just ignore the high bits of
> modulo types (which is what "unsigned" types *are*). Or the bits that
> "fall off" on a conversion. The C standard makes this required
> behaviour, it is useful, and it is the only convenient way of getting
> this!
Thanks for the background, It does make sense. I guess I was confused with java
which requires casting when you store to a smaller size. I.e.
Test.java:5: error: incompatible types: possible lossy conversion from int to short
s = i;
-Stafford
WARNING: multiple messages have this Message-ID (diff)
From: Stafford Horne <shorne@gmail.com>
To: Segher Boessenkool <segher@kernel.crashing.org>
Cc: Rich Felker <dalias@libc.org>,
"Rafael J. Wysocki" <rafael@kernel.org>,
Catalin Marinas <catalin.marinas@arm.com>,
x86@kernel.org, Guo Ren <guoren@kernel.org>,
"H. Peter Anvin" <hpa@zytor.com>,
linux-riscv@lists.infradead.org, Will Deacon <will@kernel.org>,
Jonas Bonn <jonas@southpole.se>, Rob Herring <robh@kernel.org>,
Florian Fainelli <f.fainelli@gmail.com>,
Frank Rowand <frowand.list@gmail.com>,
linux-sh@vger.kernel.org, Russell King <linux@armlinux.org.uk>,
linux-csky@vger.kernel.org, Ingo Molnar <mingo@redhat.com>,
bcm-kernel-feedback-list@broadcom.com,
James Morse <james.morse@arm.com>,
devicetree@vger.kernel.org, Albert Ou <aou@eecs.berkeley.edu>,
Ray Jui <rjui@broadcom.com>,
Stefan Kristiansson <stefan.kristiansson@saunalahti.fi>,
openrisc@lists.librecores.org, Borislav Petkov <bp@alien8.de>,
Paul Walmsley <paul.walmsley@sifive.com>,
Thomas Gleixner <tglx@linutronix.de>,
linux-arm-kernel@lists.infradead.org,
Scott Branden <sbranden@broadcom.com>,
Yoshinori Sato <ysato@users.osdn.me>,
linux-kernel@vger.kernel.org, Palmer Dabbelt <palmer@dabbelt.com>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Paul Mackerras <paulus@samba.org>,
linuxppc-dev@lists.ozlabs.org
Subject: Re: [PATCH 06/12] openrisc: Use of_get_cpu_hwid()
Date: Thu, 7 Oct 2021 07:37:39 +0900 [thread overview]
Message-ID: <YV4lM/YJ4V4EAlZb@antec> (raw)
In-Reply-To: <20211006212728.GM10333@gate.crashing.org>
Hi Segher,
On Wed, Oct 06, 2021 at 04:27:28PM -0500, Segher Boessenkool wrote:
> On Thu, Oct 07, 2021 at 05:44:00AM +0900, Stafford Horne wrote:
> > You have defined of_get_cpu_hwid to return u64, will this create compiler
> > warnings when since we are storing a u64 into a u32?
> >
> > It seems only if we make with W=3.
>
> Yes. This is done by -Wconversion, "Warn for implicit conversions that
> may alter a value."
Yeah, that is what I found out when I looked into it.
> > I thought we usually warned on this.
>
> This warning is not in -Wall or -Wextra either, it suffers too much from
> false positives. It is very natural to just ignore the high bits of
> modulo types (which is what "unsigned" types *are*). Or the bits that
> "fall off" on a conversion. The C standard makes this required
> behaviour, it is useful, and it is the only convenient way of getting
> this!
Thanks for the background, It does make sense. I guess I was confused with java
which requires casting when you store to a smaller size. I.e.
Test.java:5: error: incompatible types: possible lossy conversion from int to short
s = i;
-Stafford
WARNING: multiple messages have this Message-ID (diff)
From: Stafford Horne <shorne@gmail.com>
To: Segher Boessenkool <segher@kernel.crashing.org>
Cc: Rob Herring <robh@kernel.org>, Rich Felker <dalias@libc.org>,
"Rafael J. Wysocki" <rafael@kernel.org>,
linux-kernel@vger.kernel.org, Guo Ren <guoren@kernel.org>,
"H. Peter Anvin" <hpa@zytor.com>,
linux-riscv@lists.infradead.org, Will Deacon <will@kernel.org>,
Jonas Bonn <jonas@southpole.se>,
Florian Fainelli <f.fainelli@gmail.com>,
Yoshinori Sato <ysato@users.osdn.me>,
linux-sh@vger.kernel.org, x86@kernel.org,
Russell King <linux@armlinux.org.uk>,
linux-csky@vger.kernel.org, Ingo Molnar <mingo@redhat.com>,
bcm-kernel-feedback-list@broadcom.com,
Catalin Marinas <catalin.marinas@arm.com>,
Palmer Dabbelt <palmer@dabbelt.com>,
devicetree@vger.kernel.org, Albert Ou <aou@eecs.berkeley.edu>,
Ray Jui <rjui@broadcom.com>,
Stefan Kristiansson <stefan.kristiansson@saunalahti.fi>,
openrisc@lists.librecores.org, Borislav Petkov <bp@alien8.de>,
Paul Walmsley <paul.walmsley@sifive.com>,
Thomas Gleixner <tglx@linutronix.de>,
linux-arm-kernel@lists.infradead.org,
Scott Branden <sbranden@broadcom.com>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Frank Rowand <frowand.list@gmail.com>,
James Morse <james.morse@arm.com>,
Paul Mackerras <paulus@samba.org>,
linuxppc-dev@lists.ozlabs.org
Subject: Re: [PATCH 06/12] openrisc: Use of_get_cpu_hwid()
Date: Thu, 7 Oct 2021 07:37:39 +0900 [thread overview]
Message-ID: <YV4lM/YJ4V4EAlZb@antec> (raw)
In-Reply-To: <20211006212728.GM10333@gate.crashing.org>
Hi Segher,
On Wed, Oct 06, 2021 at 04:27:28PM -0500, Segher Boessenkool wrote:
> On Thu, Oct 07, 2021 at 05:44:00AM +0900, Stafford Horne wrote:
> > You have defined of_get_cpu_hwid to return u64, will this create compiler
> > warnings when since we are storing a u64 into a u32?
> >
> > It seems only if we make with W=3.
>
> Yes. This is done by -Wconversion, "Warn for implicit conversions that
> may alter a value."
Yeah, that is what I found out when I looked into it.
> > I thought we usually warned on this.
>
> This warning is not in -Wall or -Wextra either, it suffers too much from
> false positives. It is very natural to just ignore the high bits of
> modulo types (which is what "unsigned" types *are*). Or the bits that
> "fall off" on a conversion. The C standard makes this required
> behaviour, it is useful, and it is the only convenient way of getting
> this!
Thanks for the background, It does make sense. I guess I was confused with java
which requires casting when you store to a smaller size. I.e.
Test.java:5: error: incompatible types: possible lossy conversion from int to short
s = i;
-Stafford
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2021-10-06 22:38 UTC|newest]
Thread overview: 145+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-10-06 16:43 [PATCH 00/12] DT: CPU h/w id parsing clean-ups and cacheinfo id support Rob Herring
2021-10-06 16:43 ` Rob Herring
2021-10-06 16:43 ` Rob Herring
2021-10-06 16:43 ` [OpenRISC] " Rob Herring
2021-10-06 16:43 ` Rob Herring
2021-10-06 16:43 ` [PATCH 01/12] of: Add of_get_cpu_hwid() to read hardware ID from CPU nodes Rob Herring
2021-10-06 16:43 ` Rob Herring
2021-10-06 16:43 ` Rob Herring
2021-10-06 16:43 ` [OpenRISC] " Rob Herring
2021-10-06 16:43 ` Rob Herring
2021-10-18 13:26 ` Sudeep Holla
2021-10-18 13:26 ` Sudeep Holla
2021-10-18 13:26 ` Sudeep Holla
2021-10-18 13:26 ` [OpenRISC] " Sudeep Holla
2021-10-18 13:26 ` Sudeep Holla
2021-10-06 16:43 ` [PATCH 02/12] ARM: Use of_get_cpu_hwid() Rob Herring
2021-10-06 16:43 ` Rob Herring
2021-10-06 16:43 ` Rob Herring
2021-10-06 16:43 ` [OpenRISC] " Rob Herring
2021-10-06 16:43 ` Rob Herring
2021-10-06 16:43 ` [PATCH 03/12] ARM: broadcom: " Rob Herring
2021-10-06 16:43 ` Rob Herring
2021-10-06 16:43 ` Rob Herring
2021-10-06 16:43 ` [OpenRISC] " Rob Herring
2021-10-06 16:43 ` Rob Herring
2021-10-07 2:24 ` Florian Fainelli
2021-10-07 2:24 ` Florian Fainelli
2021-10-07 2:24 ` Florian Fainelli
2021-10-07 2:24 ` [OpenRISC] " Florian Fainelli
2021-10-07 2:24 ` Florian Fainelli
2021-10-06 16:43 ` [PATCH 04/12] arm64: " Rob Herring
2021-10-06 16:43 ` Rob Herring
2021-10-06 16:43 ` Rob Herring
2021-10-06 16:43 ` [OpenRISC] " Rob Herring
2021-10-06 16:43 ` Rob Herring
2021-10-07 8:07 ` Will Deacon
2021-10-07 8:07 ` Will Deacon
2021-10-07 8:07 ` Will Deacon
2021-10-07 8:07 ` [OpenRISC] " Will Deacon
2021-10-07 8:07 ` Will Deacon
2021-10-18 13:27 ` Sudeep Holla
2021-10-18 13:27 ` Sudeep Holla
2021-10-18 13:27 ` Sudeep Holla
2021-10-18 13:27 ` [OpenRISC] " Sudeep Holla
2021-10-18 13:27 ` Sudeep Holla
2021-10-06 16:43 ` [PATCH 05/12] csky: " Rob Herring
2021-10-06 16:43 ` Rob Herring
2021-10-06 16:43 ` Rob Herring
2021-10-06 16:43 ` [OpenRISC] " Rob Herring
2021-10-06 16:43 ` Rob Herring
2021-10-06 16:43 ` [PATCH 06/12] openrisc: " Rob Herring
2021-10-06 16:43 ` Rob Herring
2021-10-06 16:43 ` Rob Herring
2021-10-06 16:43 ` [OpenRISC] " Rob Herring
2021-10-06 16:43 ` Rob Herring
2021-10-06 20:44 ` Stafford Horne
2021-10-06 20:44 ` Stafford Horne
2021-10-06 20:44 ` Stafford Horne
2021-10-06 20:44 ` [OpenRISC] " Stafford Horne
2021-10-06 20:44 ` Stafford Horne
2021-10-06 21:08 ` Rob Herring
2021-10-06 21:08 ` Rob Herring
2021-10-06 21:08 ` Rob Herring
2021-10-06 21:08 ` [OpenRISC] " Rob Herring
2021-10-06 21:08 ` Rob Herring
2021-10-06 21:25 ` Stafford Horne
2021-10-06 21:25 ` Stafford Horne
2021-10-06 21:25 ` Stafford Horne
2021-10-06 21:25 ` [OpenRISC] " Stafford Horne
2021-10-06 21:25 ` Stafford Horne
2021-10-06 21:27 ` Segher Boessenkool
2021-10-06 21:27 ` Segher Boessenkool
2021-10-06 21:27 ` Segher Boessenkool
2021-10-06 21:27 ` [OpenRISC] " Segher Boessenkool
2021-10-06 21:27 ` Segher Boessenkool
2021-10-06 22:37 ` Stafford Horne [this message]
2021-10-06 22:37 ` Stafford Horne
2021-10-06 22:37 ` Stafford Horne
2021-10-06 22:37 ` [OpenRISC] " Stafford Horne
2021-10-06 22:37 ` Stafford Horne
2021-10-07 7:53 ` David Laight
2021-10-07 7:53 ` David Laight
2021-10-07 7:53 ` David Laight
2021-10-07 7:53 ` [OpenRISC] " David Laight
2021-10-07 7:53 ` David Laight
2021-10-06 16:43 ` [PATCH 07/12] powerpc: " Rob Herring
2021-10-06 16:43 ` Rob Herring
2021-10-06 16:43 ` Rob Herring
2021-10-06 16:43 ` [OpenRISC] " Rob Herring
2021-10-06 16:43 ` Rob Herring
2021-10-08 11:01 ` Michael Ellerman
2021-10-08 11:01 ` Michael Ellerman
2021-10-08 11:01 ` Michael Ellerman
2021-10-08 11:01 ` [OpenRISC] " Michael Ellerman
2021-10-08 11:01 ` Michael Ellerman
2021-10-06 16:43 ` [PATCH 08/12] riscv: " Rob Herring
2021-10-06 16:43 ` Rob Herring
2021-10-06 16:43 ` Rob Herring
2021-10-06 16:43 ` [OpenRISC] " Rob Herring
2021-10-06 16:43 ` Rob Herring
2021-10-06 16:43 ` [PATCH 09/12] sh: " Rob Herring
2021-10-06 16:43 ` Rob Herring
2021-10-06 16:43 ` Rob Herring
2021-10-06 16:43 ` [OpenRISC] " Rob Herring
2021-10-06 16:43 ` Rob Herring
2021-10-27 14:26 ` Rich Felker
2021-10-27 14:26 ` Rich Felker
2021-10-27 14:26 ` Rich Felker
2021-10-27 14:26 ` [OpenRISC] " Rich Felker
2021-10-27 14:26 ` Rich Felker
2021-10-06 16:43 ` [PATCH 10/12] x86: dt: " Rob Herring
2021-10-06 16:43 ` Rob Herring
2021-10-06 16:43 ` Rob Herring
2021-10-06 16:43 ` [OpenRISC] " Rob Herring
2021-10-06 16:43 ` Rob Herring
2021-10-06 16:43 ` [PATCH 11/12] cacheinfo: Allow for >32-bit cache 'id' Rob Herring
2021-10-06 16:43 ` Rob Herring
2021-10-06 16:43 ` Rob Herring
2021-10-06 16:43 ` [OpenRISC] " Rob Herring
2021-10-06 16:43 ` Rob Herring
2021-10-18 13:30 ` Sudeep Holla
2021-10-18 13:30 ` Sudeep Holla
2021-10-18 13:30 ` Sudeep Holla
2021-10-18 13:30 ` [OpenRISC] " Sudeep Holla
2021-10-18 13:30 ` Sudeep Holla
2021-10-06 16:43 ` [PATCH 12/12] cacheinfo: Set cache 'id' based on DT data Rob Herring
2021-10-06 16:43 ` Rob Herring
2021-10-06 16:43 ` Rob Herring
2021-10-06 16:43 ` [OpenRISC] " Rob Herring
2021-10-06 16:43 ` Rob Herring
2021-10-18 13:31 ` Sudeep Holla
2021-10-18 13:31 ` Sudeep Holla
2021-10-18 13:31 ` Sudeep Holla
2021-10-18 13:31 ` [OpenRISC] " Sudeep Holla
2021-10-18 13:31 ` Sudeep Holla
2021-10-07 2:24 ` [PATCH 00/12] DT: CPU h/w id parsing clean-ups and cacheinfo id support Florian Fainelli
2021-10-07 2:24 ` Florian Fainelli
2021-10-07 2:24 ` Florian Fainelli
2021-10-07 2:24 ` [OpenRISC] " Florian Fainelli
2021-10-07 2:24 ` Florian Fainelli
2021-10-20 18:47 ` Rob Herring
2021-10-20 18:47 ` Rob Herring
2021-10-20 18:47 ` Rob Herring
2021-10-20 18:47 ` [OpenRISC] " Rob Herring
2021-10-20 18:47 ` Rob Herring
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=YV4lM/YJ4V4EAlZb@antec \
--to=shorne@gmail.com \
--cc=aou@eecs.berkeley.edu \
--cc=bcm-kernel-feedback-list@broadcom.com \
--cc=bp@alien8.de \
--cc=catalin.marinas@arm.com \
--cc=dalias@libc.org \
--cc=devicetree@vger.kernel.org \
--cc=f.fainelli@gmail.com \
--cc=frowand.list@gmail.com \
--cc=gregkh@linuxfoundation.org \
--cc=guoren@kernel.org \
--cc=hpa@zytor.com \
--cc=james.morse@arm.com \
--cc=jonas@southpole.se \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-csky@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-riscv@lists.infradead.org \
--cc=linux-sh@vger.kernel.org \
--cc=linux@armlinux.org.uk \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=mingo@redhat.com \
--cc=openrisc@lists.librecores.org \
--cc=palmer@dabbelt.com \
--cc=paul.walmsley@sifive.com \
--cc=paulus@samba.org \
--cc=rafael@kernel.org \
--cc=rjui@broadcom.com \
--cc=robh@kernel.org \
--cc=sbranden@broadcom.com \
--cc=segher@kernel.crashing.org \
--cc=stefan.kristiansson@saunalahti.fi \
--cc=tglx@linutronix.de \
--cc=will@kernel.org \
--cc=x86@kernel.org \
--cc=ysato@users.osdn.me \
/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.