All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Laight <David.Laight@ACULAB.COM>
To: 'Segher Boessenkool' <segher@kernel.crashing.org>,
	Stafford Horne <shorne@gmail.com>
Cc: Rich Felker <dalias@libc.org>,
	"Rafael J. Wysocki" <rafael@kernel.org>,
	Catalin Marinas <catalin.marinas@arm.com>,
	"x86@kernel.org" <x86@kernel.org>, Guo Ren <guoren@kernel.org>,
	"H. Peter Anvin" <hpa@zytor.com>,
	"linux-riscv@lists.infradead.org"
	<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" <linux-sh@vger.kernel.org>,
	Russell King <linux@armlinux.org.uk>,
	"linux-csky@vger.kernel.org" <linux-csky@vger.kernel.org>,
	Ingo Molnar <mingo@redhat.com>,
	"bcm-kernel-feedback-list@broadcom.com" 
	<bcm-kernel-feedback-list@broadcom.com>,
	James Morse <james.morse@arm.com>,
	"devicetree@vger.kernel.org" <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" <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" 
	<linux-arm-kernel@lists.infradead.org>,
	Scott Branden <sbranden@broadcom.com>,
	Yoshinori Sato <ysato@users.osdn.me>,
	"linux-kernel@vger.kernel.org" <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" <linuxppc-dev@lists.ozlabs.org>
Subject: RE: [PATCH 06/12] openrisc: Use of_get_cpu_hwid()
Date: Thu, 7 Oct 2021 07:53:01 +0000	[thread overview]
Message-ID: <c81b9c01650e487785b02f6562791556@AcuMS.aculab.com> (raw)
In-Reply-To: <20211006212728.GM10333@gate.crashing.org>

From: Segher Boessenkool
> Sent: 06 October 2021 22:27
> 
> 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."
> 
> > I thought we usually warned on this.

The microsoft compiler does - best to turn all those warnings off.

> 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!

I've also seen a compiler convert:
	struct->char_member = (char)(int_val & 0xff);
into:
	reg = int_val;
	reg &= 0xff; // for the & 0xff
	reg &= 0xff; // for the cast
	struct->char_member = low_8bits(reg);

You really don't want the extra noise.

I'll bet that (char)int_val is actually an arithmetic expression.
So its type will be 'int'.

	David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)


WARNING: multiple messages have this Message-ID (diff)
From: David Laight <David.Laight@ACULAB.COM>
To: 'Segher Boessenkool' <segher@kernel.crashing.org>,
	Stafford Horne <shorne@gmail.com>
Cc: Rich Felker <dalias@libc.org>,
	"Rafael J. Wysocki" <rafael@kernel.org>,
	Catalin Marinas <catalin.marinas@arm.com>,
	"x86@kernel.org" <x86@kernel.org>,  Guo Ren <guoren@kernel.org>,
	"H. Peter Anvin" <hpa@zytor.com>,
	"linux-riscv@lists.infradead.org"
	<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" <linux-sh@vger.kernel.org>,
	Russell King <linux@armlinux.org.uk>,
	"linux-csky@vger.kernel.org" <linux-csky@vger.kernel.org>,
	Ingo Molnar <mingo@redhat.com>,
	"bcm-kernel-feedback-list@broadcom.com"
	<bcm-kernel-feedback-list@broadcom.com>,
	James Morse <james.morse@arm.com>,
	"devicetree@vger.kernel.org" <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" <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"
	<linux-arm-kernel@lists.infradead.org>,
	Scott Branden <sbranden@broadcom.com>,
	Yoshinori Sato <ysato@users.osdn.me>,
	"linux-kernel@vger.kernel.org" <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" <linuxppc-dev@lists.ozlabs.org>
Subject: RE: [PATCH 06/12] openrisc: Use of_get_cpu_hwid()
Date: Thu, 7 Oct 2021 07:53:01 +0000	[thread overview]
Message-ID: <c81b9c01650e487785b02f6562791556@AcuMS.aculab.com> (raw)
In-Reply-To: <20211006212728.GM10333@gate.crashing.org>

From: Segher Boessenkool
> Sent: 06 October 2021 22:27
> 
> 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."
> 
> > I thought we usually warned on this.

The microsoft compiler does - best to turn all those warnings off.

> 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!

I've also seen a compiler convert:
	struct->char_member = (char)(int_val & 0xff);
into:
	reg = int_val;
	reg &= 0xff; // for the & 0xff
	reg &= 0xff; // for the cast
	struct->char_member = low_8bits(reg);

You really don't want the extra noise.

I'll bet that (char)int_val is actually an arithmetic expression.
So its type will be 'int'.

	David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)


_______________________________________________
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: David Laight <David.Laight@ACULAB.COM>
To: 'Segher Boessenkool' <segher@kernel.crashing.org>,
	Stafford Horne <shorne@gmail.com>
Cc: Rich Felker <dalias@libc.org>,
	"Rafael J. Wysocki" <rafael@kernel.org>,
	Catalin Marinas <catalin.marinas@arm.com>,
	"x86@kernel.org" <x86@kernel.org>, Guo Ren <guoren@kernel.org>,
	"H. Peter Anvin" <hpa@zytor.com>,
	"linux-riscv@lists.infradead.org"
	<linux-riscv@lists.infradead.org>,
	Frank Rowand <frowand.list@gmail.com>,
	Jonas Bonn <jonas@southpole.se>, Rob Herring <robh@kernel.org>,
	Florian Fainelli <f.fainelli@gmail.com>,
	Will Deacon <will@kernel.org>,
	"linux-sh@vger.kernel.org" <linux-sh@vger.kernel.org>,
	Russell King <linux@armlinux.org.uk>,
	"linux-csky@vger.kernel.org" <linux-csky@vger.kernel.org>,
	Ingo Molnar <mingo@redhat.com>,
	"bcm-kernel-feedback-list@broadcom.com"
	<bcm-kernel-feedback-list@broadcom.com>,
	Palmer Dabbelt <palmer@dabbelt.com>,
	"devicetree@vger.kernel.org" <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" <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"
	<linux-arm-kernel@lists.infradead.org>,
	Scott Branden <sbranden@broadcom.com>,
	Yoshinori Sato <ysato@users.osdn.me>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	James Morse <james.morse@arm.com>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Paul Mackerras <paulus@samba.org>,
	"linuxppc-dev@lists.ozlabs.org" <linuxppc-dev@lists.ozlabs.org>
Subject: RE: [PATCH 06/12] openrisc: Use of_get_cpu_hwid()
Date: Thu, 7 Oct 2021 07:53:01 +0000	[thread overview]
Message-ID: <c81b9c01650e487785b02f6562791556@AcuMS.aculab.com> (raw)
In-Reply-To: <20211006212728.GM10333@gate.crashing.org>

From: Segher Boessenkool
> Sent: 06 October 2021 22:27
> 
> 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."
> 
> > I thought we usually warned on this.

The microsoft compiler does - best to turn all those warnings off.

> 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!

I've also seen a compiler convert:
	struct->char_member = (char)(int_val & 0xff);
into:
	reg = int_val;
	reg &= 0xff; // for the & 0xff
	reg &= 0xff; // for the cast
	struct->char_member = low_8bits(reg);

You really don't want the extra noise.

I'll bet that (char)int_val is actually an arithmetic expression.
So its type will be 'int'.

	David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)


WARNING: multiple messages have this Message-ID (diff)
From: David Laight <David.Laight@ACULAB.COM>
To: 'Segher Boessenkool' <segher@kernel.crashing.org>,
	Stafford Horne <shorne@gmail.com>
Cc: Rich Felker <dalias@libc.org>,
	"Rafael J. Wysocki" <rafael@kernel.org>,
	Catalin Marinas <catalin.marinas@arm.com>,
	"x86@kernel.org" <x86@kernel.org>,  Guo Ren <guoren@kernel.org>,
	"H. Peter Anvin" <hpa@zytor.com>,
	"linux-riscv@lists.infradead.org"
	<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" <linux-sh@vger.kernel.org>,
	Russell King <linux@armlinux.org.uk>,
	"linux-csky@vger.kernel.org" <linux-csky@vger.kernel.org>,
	Ingo Molnar <mingo@redhat.com>,
	"bcm-kernel-feedback-list@broadcom.com"
	<bcm-kernel-feedback-list@broadcom.com>,
	James Morse <james.morse@arm.com>,
	"devicetree@vger.kernel.org" <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" <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"
	<linux-arm-kernel@lists.infradead.org>,
	Scott Branden <sbranden@broadcom.com>,
	Yoshinori Sato <ysato@users.osdn.me>,
	"linux-kernel@vger.kernel.org" <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" <linuxppc-dev@lists.ozlabs.org>
Subject: RE: [PATCH 06/12] openrisc: Use of_get_cpu_hwid()
Date: Thu, 7 Oct 2021 07:53:01 +0000	[thread overview]
Message-ID: <c81b9c01650e487785b02f6562791556@AcuMS.aculab.com> (raw)
In-Reply-To: <20211006212728.GM10333@gate.crashing.org>

From: Segher Boessenkool
> Sent: 06 October 2021 22:27
> 
> 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."
> 
> > I thought we usually warned on this.

The microsoft compiler does - best to turn all those warnings off.

> 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!

I've also seen a compiler convert:
	struct->char_member = (char)(int_val & 0xff);
into:
	reg = int_val;
	reg &= 0xff; // for the & 0xff
	reg &= 0xff; // for the cast
	struct->char_member = low_8bits(reg);

You really don't want the extra noise.

I'll bet that (char)int_val is actually an arithmetic expression.
So its type will be 'int'.

	David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)


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

WARNING: multiple messages have this Message-ID (diff)
From: David Laight <David.Laight@ACULAB.COM>
To: openrisc@lists.librecores.org
Subject: [OpenRISC] [PATCH 06/12] openrisc: Use of_get_cpu_hwid()
Date: Thu, 7 Oct 2021 07:53:01 +0000	[thread overview]
Message-ID: <c81b9c01650e487785b02f6562791556@AcuMS.aculab.com> (raw)
In-Reply-To: <20211006212728.GM10333@gate.crashing.org>

From: Segher Boessenkool
> Sent: 06 October 2021 22:27
> 
> 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."
> 
> > I thought we usually warned on this.

The microsoft compiler does - best to turn all those warnings off.

> 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!

I've also seen a compiler convert:
	struct->char_member = (char)(int_val & 0xff);
into:
	reg = int_val;
	reg &= 0xff; // for the & 0xff
	reg &= 0xff; // for the cast
	struct->char_member = low_8bits(reg);

You really don't want the extra noise.

I'll bet that (char)int_val is actually an arithmetic expression.
So its type will be 'int'.

	David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)


  parent reply	other threads:[~2021-10-07  7:53 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 ` [OpenRISC] " Rob Herring
2021-10-06 16:43 ` Rob Herring
2021-10-06 16:43 ` 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   ` [OpenRISC] " Rob Herring
2021-10-06 16:43   ` Rob Herring
2021-10-06 16:43   ` Rob Herring
2021-10-06 16:43   ` Rob Herring
2021-10-18 13:26   ` Sudeep Holla
2021-10-18 13:26     ` [OpenRISC] " Sudeep Holla
2021-10-18 13:26     ` Sudeep Holla
2021-10-18 13:26     ` 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   ` [OpenRISC] " Rob Herring
2021-10-06 16:43   ` Rob Herring
2021-10-06 16:43   ` 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   ` [OpenRISC] " Rob Herring
2021-10-06 16:43   ` Rob Herring
2021-10-06 16:43   ` Rob Herring
2021-10-06 16:43   ` Rob Herring
2021-10-07  2:24   ` Florian Fainelli
2021-10-07  2:24     ` [OpenRISC] " Florian Fainelli
2021-10-07  2:24     ` Florian Fainelli
2021-10-07  2:24     ` 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   ` [OpenRISC] " Rob Herring
2021-10-06 16:43   ` Rob Herring
2021-10-06 16:43   ` Rob Herring
2021-10-06 16:43   ` Rob Herring
2021-10-07  8:07   ` Will Deacon
2021-10-07  8:07     ` [OpenRISC] " Will Deacon
2021-10-07  8:07     ` Will Deacon
2021-10-07  8:07     ` Will Deacon
2021-10-07  8:07     ` Will Deacon
2021-10-18 13:27   ` Sudeep Holla
2021-10-18 13:27     ` [OpenRISC] " Sudeep Holla
2021-10-18 13:27     ` Sudeep Holla
2021-10-18 13:27     ` 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   ` [OpenRISC] " Rob Herring
2021-10-06 16:43   ` Rob Herring
2021-10-06 16:43   ` 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   ` [OpenRISC] " Rob Herring
2021-10-06 16:43   ` Rob Herring
2021-10-06 16:43   ` Rob Herring
2021-10-06 16:43   ` Rob Herring
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 20:44     ` Stafford Horne
2021-10-06 20:44     ` Stafford Horne
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:08       ` Rob Herring
2021-10-06 21:08       ` Rob Herring
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:25         ` Stafford Horne
2021-10-06 21:25         ` Stafford Horne
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 21:27       ` Segher Boessenkool
2021-10-06 21:27       ` Segher Boessenkool
2021-10-06 22:37       ` Stafford Horne
2021-10-06 22:37         ` [OpenRISC] " Stafford Horne
2021-10-06 22:37         ` Stafford Horne
2021-10-06 22:37         ` Stafford Horne
2021-10-06 22:37         ` Stafford Horne
2021-10-07  7:53       ` David Laight [this message]
2021-10-07  7:53         ` [OpenRISC] " David Laight
2021-10-07  7:53         ` David Laight
2021-10-07  7:53         ` 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   ` [OpenRISC] " Rob Herring
2021-10-06 16:43   ` Rob Herring
2021-10-06 16:43   ` Rob Herring
2021-10-06 16:43   ` Rob Herring
2021-10-08 11:01   ` Michael Ellerman
2021-10-08 11:01     ` [OpenRISC] " Michael Ellerman
2021-10-08 11:01     ` Michael Ellerman
2021-10-08 11:01     ` 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   ` [OpenRISC] " Rob Herring
2021-10-06 16:43   ` Rob Herring
2021-10-06 16:43   ` 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   ` [OpenRISC] " Rob Herring
2021-10-06 16:43   ` Rob Herring
2021-10-06 16:43   ` Rob Herring
2021-10-06 16:43   ` Rob Herring
2021-10-27 14:26   ` Rich Felker
2021-10-27 14:26     ` [OpenRISC] " Rich Felker
2021-10-27 14:26     ` Rich Felker
2021-10-27 14:26     ` 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   ` [OpenRISC] " Rob Herring
2021-10-06 16:43   ` Rob Herring
2021-10-06 16:43   ` 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   ` [OpenRISC] " Rob Herring
2021-10-06 16:43   ` Rob Herring
2021-10-06 16:43   ` Rob Herring
2021-10-06 16:43   ` Rob Herring
2021-10-18 13:30   ` Sudeep Holla
2021-10-18 13:30     ` [OpenRISC] " Sudeep Holla
2021-10-18 13:30     ` Sudeep Holla
2021-10-18 13:30     ` 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   ` [OpenRISC] " Rob Herring
2021-10-06 16:43   ` Rob Herring
2021-10-06 16:43   ` Rob Herring
2021-10-06 16:43   ` Rob Herring
2021-10-18 13:31   ` Sudeep Holla
2021-10-18 13:31     ` [OpenRISC] " Sudeep Holla
2021-10-18 13:31     ` Sudeep Holla
2021-10-18 13:31     ` 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   ` [OpenRISC] " Florian Fainelli
2021-10-07  2:24   ` Florian Fainelli
2021-10-07  2:24   ` Florian Fainelli
2021-10-07  2:24   ` Florian Fainelli
2021-10-20 18:47 ` Rob Herring
2021-10-20 18:47   ` [OpenRISC] " Rob Herring
2021-10-20 18:47   ` Rob Herring
2021-10-20 18:47   ` 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=c81b9c01650e487785b02f6562791556@AcuMS.aculab.com \
    --to=david.laight@aculab.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=shorne@gmail.com \
    --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.